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

You do not have flash or javascript support.

Average (2 votes)

Reply