In the quest for IT value, a commonly cited figure is that projects (new functionality) consume a mere 25% or so of IT spending, while "maintenance" consumes the balance.
This is argued by many (including me, in the 1st edition of my book) to be a Bad Thing. Some well known authors even propose that reducing maintenance & increasing projects should be measured as evidence of IT value delivery - i.e., a Key Performance Indicator.
Today, I started to wonder if this whole point of view might be misguided.
I am searching for generally applicable principles for IT management, and "project vs. maintenance %" as a KPI seems a little too context-dependent for my comfort:
- Organizations have differing approaches to funding work. "Project" and "maintenance" are simply different funding buckets, and do not in and of themselves determine the degree to which work is innovative or value add. For example, projects can fund routine compliance initiatives, required but not truly value-add in a Lean sense, while cutting edge work may be performed by senior staff funded through ongoing operational budgets.
Take the deployment of a major new framework (ERP or similar platform). Getting the basic foundation and first couple of modules in may comprise the high-visibility "project." But after that, important development may be covered under the guise of "maintenance" - this is again a question of the organization's funding model.
Or the areas of business intelligence and reporting, in which the core platform may be established via a project, but value is often delivered by the efforts of full time analysts who spend years deepening their familiarity with the data and its opportunities.
- The assumption is that the maintenance work is mundane: performance tuning, re-indexing data sets, break-fix, and so forth. But this assumption is largely incorrect in many of the environments I am familiar with. A good bit of actual development and implementation may also take place, depending on the organization's approach to demand management.
Demand management professionals may well argue that distinguishing value add, creative, implementation work from the truly mundane is essential for investment transparency. Project management professionals may argue that project methodology is essential to mitigate risk. But there are two major obstacles to this: first, the business sponsor may have been savvy enough to negotiate a defined headcount of "maintenance" staff who are not fungible. Why would they do this? Because if they accept that all project resources are fungible and must compete greenfield with the fair haired poster child project of the week, they may lose the ability to continuously improve their service.
The second obstacle is that even if incremental funding is assured for that application, too many PMOs have compliance-heavy processes that are rightly perceived as non-value-add, especially if everyone agrees that the system's architecture is sound and the #1 priority is to iteratively improve the functionality over the course of some period of time. (See: Agile vs. Waterfall.)
The concept of project to my mind adds value when the need is to choreograph resources (especially consultants, contractors and assets) and manage for critical path.
- Even if we assume that the most innovative work is performed through
large projects, the organization may have a limited capacity for
absorbing such disruptive change. A new ERP system or data warehouse simply can't be dropped in every year; even if the money were there no organization can handle that degree of change.
An extended period of more routine fine tuning and incremental development on the new platform is to be expected, and may well be essential to fully exploit the possibilities of the new technology. The actual constraint that the new technology targets may prove persistent, requiring ongoing iterations to correctly elevate and address. And again, that fine tuning may be funded under the guise of "maintenance." Is that source of funds by definition non value add?
Cautious people should avoid making that leap, IMHO.
I'm not suggesting that the traditional view is in all cases wrong. It is possible (I have seen it done) to rigorously distinguish truly mundane IT work from development. But the *only* place I have seen succeed in this was a corporation who had outsourced its entire IT organization, from architecture on down, to a third party whose profit margin depended on this distinction.
I don't like criticizing without providing alternatives - so what is the intent of this metric? It is at least an indirect attempt at distinguishing value add vs. non value add IT work, and also has some implications around IT portfolio complexity - more complex portfolios require more maintenance and may prevent IT innovation. So those would be the avenues to pursue in searching for a replacement...
