Blog: Maintenance - Letting Go Of The M-Word

We've probably all seen the IT iceberg, the one with new projects rising majestically above the water line - and application maintenance submerged in the murky depths below. Well, since global warming is busy melting the icebergs up north, I hope it will soon come along and melt this particular one too.

The infamous iceberg view represents a fundamental misunderstanding of IT. The visible 20% is supposed to represent "good" spend on new projects and innovation, while the remaining 80% is supposed to represent "bad" spend on application maintenance and production. Being associated with new, sexy initiatives is good for your career. Working on maintenance and production however puts you are at the bottom of the food chain, even if they are essential to keep business-critical systems working.

The main reason for this unhealthy distinction between projects vs maintenance is that we equate IT to the construction industry, with the IT department the equivalent of a building contractor whose project managers, architects and engineers (all construction industry terms...) are supposed to deliver systems on time, on budget and to spec. Anything that happens afterwards is considered "maintenance" - and we all know that no self-respecting kid in the playground is going to puff out his chest and say "my dad works in maintenance!", hence the lowly status of those in IT who work on the submerged part of the iceberg.

In reality of course, the construction industry model doesn't map very well to IT. Not only are systems hardly ever delivered on time, budget and to spec, they also require ongoing maintenance funding over their lifetime which will account for up to 5 times the original project investment. When asked to explain this reality, most people usually quote poor requirements, lack of adherence to some methodology, inadequate business sponsorship, or any one of the usual suspects. In other words, the model is fine, it's just that we haven't yet learnt to apply it properly. Yeah, right - after 50 years of trying...

MODEL, MODEL ON THE WALL

An alternative view is that the construction model doesn't hold for IT, ie building software is not like building houses, despite the theory that says it is. As explained in a previous post, Benefits monitoring - the missing ingredient, building houses is about unambiguous requirements applied to the physical sciences to yield fairly predictable results - after all, no one ever took delivery of a house and said "this is not what I asked for! Where's that room I thought would be over there?!". Building software however is about human behaviour and business processes applied to things you're usually trying to do for the first time, which not surprisingly yields unpredictable results whose validity can only be established over time through actual usage. Hence the "rework" and "corrections" which we call maintenance, and which should hardly come as a surprise. In fact, the only surprise is that people should be surprised at all.

Far from being a mere philosophical discussion, accepting this reality changes the whole way you view things. And the most fundamental shift is that the delivery date of a project really represents the FIRST key milestone after which the rest of the work starts, rather than the end point of a sacrosanct project plan after which any additional work is considered an anomaly. Under the new model, it is an accepted fact of life that it is impossible to deliver fully functional software on day one, so there will always be "rework" and "corrections". This will result in a regular stream of new releases and versions, whose intervals and content will gradually decrease over time as processes stabilize and become institutionalized. There would be no more "maintenance" as such, and whatever you wanted to call it (ongoing releases or versions would be just fine) it would certainly not be viewed in a negative light.

Letting go of the M-word would also eliminate the sterile - and dangerous - comparison of new projects vs maintenance, as represented by the infamous iceberg. Sterile because ultimately all IT effort ends up supporting the business, otherwise we wouldn't be spending the money in the first place. Dangerous because it gives the impression to the CEO and CFO that only new projects are noble and have the potential to deliver business value, and that maintenance and production are somehow a necessary evil which represents money that could be better spent elsewhere. At a CIO event I once attended, the ubiquitous iceberg slide inevitably appeared, and one participant said that he would never ever show that vision of new projects vs maintenance to his CEO, because it could give the impression that he's somehow wasting 80% of the IT budget.

Once we understand and accept the essential differences between IT and the construction industry, we can then work to a new model which accepts that successful software is characterized by successive releases and versions over many years, each of which adds value - rather than a one-off delivery after which the maintenance crew has to clean up. A project would then be nothing more than the short development phase of a very long application life cycle. The application itself would be an asset which is managed from a cost-benefit perspective from cradle to grave. And then maybe the kids in the playground can brag to each other that "my dad builds software!" and be proud of it.

Michael Gentle (www.michaelgentle.com)

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email CIO
• Follow CIO on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark