There is significant discussion in CIO circles on moving more IT spend out of the maintenance and into either enhancement work, new product development, innovation, or even R&D. As I’ve explored this issue, there are a number of causes of high maintenance worth exploring:

1)    The product requires technologists to respond to customer issues, address service level deficiencies, investigate root causes to issues, manually ‘fix’ things in the database, investigate security concerns, respond to performance issues, and other activities that require significant effort or expertise. This may be because the product was poorly built up front, or its usage outgrew the intended design/architecture.

2)    Complex and/or outdated architectures can also lead to costly maintenance. If you’re running a proprietary database on a VAX, you can bet the maintenance costs will outweigh costs of running this same database on modern architectures.

3)    Similarly, outdated application architectures or integrations with third party products/systems can lead to high maintenance costs. Related to this are third party issues, let’s face it, if you’re system integrated with a poorly managed third party system, then your maintenance costs will be higher.

I have a couple of conceptually simple solutions to these issues and will present one in this post..

Funding Models and Terminology Issues

Traditionally, IT projects are funded as investments. Once the project completes (and if it completes) the technology effectively moves to a “day 2” maintenance model to allow for “minor” enhancement work. We can debate what constitute “minor” and what level of funding is needed for day 2 models – which is the heart of the issue – but its sole is in the terminology.

No to Maintenance, Yes to Agile Programs

Maintenance has a lot of negative connotations.It covers a lot of territory in terms of scope (see maintenance causes above) but also it implies minimal activity. My car needs some basic maintenance every 7500 miles and it's not an ongoing exercise. Maintenance also doesn't account for business driven changes where they are driven by functionality, performance needs, or competitive needs. In simple terms, "maintenance" is an 'old' model that doesn't work in today's fast paced competitive landscape.

So how can we turn this around. I'm not going to be too scientific here and guessing others have a more detailed methodology, but here it goes:

• Year 1 of a project delivers one or more product phases at cost $X.
• Fund year two no less than 40% of $X and more depending on business need
• Fund year three no less than 30% of $X and more depending on business need
• Assess a rebuild/port/platform integration in year four at no less than 80% of $X
• Total cost over four years: no less than 2.5 * $X.
• Governance should be applied when the business can't adequately fund products according to a defined model. (Another post?)

Basic hypothesis: A professional software shop charges customers approximately 20% of license costs as maintenance. An in house team is not likely to be efficient, so I doubled this for year two. If the business has few demands/needs on this project in year three, then the minimum can go down as the "team" (more on this later) becomes more efficient. But in year four, given the pace of technology and changes in customer needs, assume that the product needs rework. Since this product largely has a working model, the rework should be a fraction of the original investment unless new needs are also factored in.

Why is this important and how to implement
 

• As IT organizations, we get into the maintenance death spiral on products because we under-invest in them on an ongoing basis. This model presents a more holistic TCO for the technology/product.
• Don't want to fund it this way and leaning Buy before Build? Remember, vendors should be able to provide some economies, but only if they scale and have an operational model for whatever customizations they support. (Another post?). Guess what - many don't!
• This funding model leads to leveraging teams. Development teams get efficient by leveraging platforms and process, not by executing on individual projects. So instead of ramping up a team to build, then putting the asset into maintenance, we now can model an ongoing team that can take development into years two, three, four.
• Although the number of teams and their size will vary year to year, this is a continuous program. As a continuous program, I would simply apply an agile development process and call it an ongoing agile program. Why? Call it marketing. Call it better IT/Business alignment. But the scope of agile delivery is greater than just maintenrance activities and it provides significantly higher business value.... 

 Now that we've 'solved' the funding for this type of program....

It's been awhile since my last post. What can I say, the first 100 days of being CIO at a new job is busy. There's people to meet, the business to learn, and the technology to understand. Some things need immediate attention, others are things that can be dealt with later. It's easy to be overwhelmed.

So, almost halfway into my 100 days, I can give new CIOs some advice. This goes beyond building the 100 day plan which I think is critical to stay focused. This is my practical guidance to CIOs, but also anyone taking a new senior technology leadership position:

li { margin-bottom: 10px; }

• Ask lots of questions - The advantage of being the new guy is that people should expect it. I've been very fortunate in this new position and everyone's been a good sport. Questions not only help you build up your understanding, but also may help others see things from new perspectives. Occasionally, asking questions will expose an issue, but better then than later. And sometimes asking questions will help develop a culture of dialogue and collaboration
• Always be prioritizing - Your time now is at a huge premium. Set your schedule, but be prepared to change it as you recognize immediate vs. short term needs.
• Find ways to contribute early - Some call this quick wins, but even before that, relationship building is easier when it is two way. 
• Listen - Some of the 'books' on management strongly suggest setting expectations with your staff early. I think before you set structure with your team, set time to first engage, listen, and learn. 
• Slowly zero in on the priorities - I stress here on the word slowly. It means go broad and learn more before setting new priorities.
• Understand the business cycles and key dates - When are budgets done? When are the peak sales cycles? When are deployments scheduled? On my first week, I asked my directs to send me a list of key dates. All of this will help you prioritize your time and consider the timing of new initiatives.
• People come before Process and Technology - CIOs tend to think in this trio, but in the first 100 days, focus needs to be on people and relationships first, process second, and technology a distant third.
• Be prepared to run - Move fast. You have lots to learn, stuff to do, and plans to build.
• Look for burning platforms - If I put 100 CIOs in a room, I doubt anyone would say that everything was running well when they took the job. In addition to priorities, you have to hunt down the issues - the ones everyone tells you about, but more importantly, the ones that no one recognizes.
• Leadership starts early - Don't expect to sit in the back seat even though your the newbie. Your team, your colleagues, and your boss expect you to step up early. Will you be perceived as just the tech person, or as someone with a broader business understanding? Whether and how you participate is key to everyone's early perceptions.

I started a new position this week as VP Technology / CIO of McGraw-Hill Construction and have started to work on a 100 day plan. Poking around a little bit, I've found a number of good references on this subject:

• Forrester's new CIO 100 Day Plan - Advises building a personal checklist. Has a good starting list of major learning and action tasks. Recommends "let your business peers know you are listening" and "establish your management style early".
• What to Do in the First 100 Days of Your New Job - From CIO magazine. A good, simple list of questions to ask business leaders and staff as you meet them. Some great pieces of advice, such as "Remember some of your best decisions are made before you have all the facts because you instinctively know what needs to be done."
• 5 Tips for Charting Your 100 Day Plan - Also from CIO magazine. Assess, determine expectations, build alliances, understand the culture, get an early win.
• Advice for first time CIOs - Good for first time CIOs, but also a good refresher course for experienced CIOs looking to structure their first 100 days.
• 3 CIO Lessons from Obama’s First 100 Days - A good read. Kill a sacred cow. Be a problem solver.

My personal experiment; I've decided to Tweet my first 100 days. I plan to post a single tweet per day covering the highlights of each day. Obviously, I can't say very much in 140 characters, so call it an experiment. Here's a twitter search that you can use to follow these specific tweets, or you can just follow @nyike.

Last week I moderated a panel on Social Networking and Media to a group of approximately 50 CIOs at the Global CIO Forum sponsored by Telwares. We covered social networking from a number of perspectives:

• Integrating social networking functionality into products (example, Twitter, LinkedIn like Business Exchange has done or Facebook integration as others have done successfullt)
• Social media/networking used in Marketing and Sales functions - Harrah's reps tweet star findings in their Vegas hotels. Blood Systems uses tweet when blood donors are needed during a crisis. I saw a nice demo of SalesForce Chatter.
• Enterprise 2.0 capabilities - Several examples including a Sharepoint site used to coordinate social media messaging.
• A long discussion on the CIO role in developing social media policies - With some good insight from @MarkSilver.

It turned out to be a lively discussion which I find surprising since there were relatively few consumer oriented company CIOs in the mix. Virtually all the CIOs are on LinkedIn and Facebook, but relatively few participate on Twitter. Nonetheless, the majority of themselves see themselves playing a role enabling this technology if used in constructive ways rather than inhibiting it. 

I'm going to generalize a bit. These CIOs recognize that the current generation of workforce come in with expectations of openness and are well versed in collaboration tools. Although enterprise 2.0 tools may not be high on their project lists, they're not ignoring it either and taking steps opportunistically. When it comes to social media policy, many were in agreement that the real concern is code of conduct issues recognizing that social networking tools just increase the transparency of people's activity. They see HR and Legal taking on the roles of inhibitor and see their participation aiming to explain the technology and to insure an open dialogue. Afterall, all YouTube did is make it easy for someone to post video of 'bad' behavior; the behavior was probably there already just no one saw it. All acknowledged that social platforms were a feeding ground for scavenging legal dirt, so there is a general leadership need in making employees aware of the issues.

All in all, it was a very healthy discussion and a promising sign for those of us who promote proper usage of these tools in the enterprise.