How to Fund Software Maintenance Efforts

Part of the problem with funding projects is that, from a funding perspective, we treat software development as a one-time event.  When we create a new application I think we all expect that maintenance will need to be made over time, but this is not reflected in the funding model.  Each round of maintenance usually requires a project charter and funding approval.  In obtaining funding approval the maintenance project now has to compete with all other projects for funding approval.  This sounds sensible until you think of the implications.

If we have a building with a leaky roof, we know that we have to fix it or more damage will occur.  In software it is just the same: if the existing application supports the wrong business process, damage to the business occurs as long as the problem goes unaddressed. Forcing application maintenance into the project approval process can delay, sometimes indefinitely, the funding of needed maintenance, resulting in higher costs later on.

Some organizations resolve this problem by creating two pools of funding: one for "emergency fixes" and another for less critical maintenance.  The result of this is usually  a contentious relationship between the business and IT.  The size of the "emergency fix" pool is usually determined arbitrarily but assumed to be relatively small relative to the total amount of the maintenance backlog.  As a result, there is a natural tendency for the business and IT to get into arguments about whether a change is an emergency fix or whether it requires a project charter.  To the business, and in reality, the distinction is relatively arbitrary so, from the perspective of the business, IT appears to be bureaucratic and obstinate.  To IT the business appears to be unreasonable because they want everything and are willing to pay for nothing.

A better solution is to treat ongoing maintenance of a system as an ongoing expense of the business.  The business should determine, based on a percentage of the operating cost of running the business, how much it wants to spend on ongoing improvements in the systems supporting the business, just as it should budget for continuous improvement in its business processes.  In today's world the two cannot be separated: software systems are essential to implement business processes; businesses cannot run without the automated support, and a certain amount of change should always be expected and funded.

When it comes time to decide what work should be done, using a backlog and forcing the business to rank-order the work puts the responsibility for making decisions on them: it is their money and they get to decide how to spend it.  They may need an education on the value of spending money to reduce technical debt, but it is useful for them to understand that, too. They only get so much to spend, but they can spend it however they want.  It removes IT from having to be the one always saying "no".

This approach reduces the contentiousness of a large chunk of the IT planning process, and it ensures that needed work gets done.  It also has another benefit:  I have seen many projects sunk because the business insists on piling on many years worth of backlog when an enhancement project finally does get approved.  The weight of this pent-up backlog is often enough to weigh down even the best of projects, resulting in either unmet expectations, or worse, a failed project that collapsed under the weight of more work than it could sustain.

With maintenance work handled by this process, that leaves appropriate project work to be funded.  I have some thoughts on that, too, but I'll leave that to next time.