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….