Managing Systems Projects: We Can Fight Our Way Out Of Wet Paper Bags

Originally published in the PMI IT & Telecom SIG Newsletter

The faith of the average customer in the ability of the average systems development project team to bring in a project on time, on budget and to specification is about as strong as our collective belief that the Edsel will go down in history as a great car. Unfortunately, this is a well-earned criticism.

In a world where 75% of systems projects are delivered significantly over budget, over schedule and under specification – and 25% never actually get delivered at all – you do have to wonder about any commitment to timely, reliable delivery. Our track record is no sounder, and inspires no more trust, than your average politician with a smile on his face. And let’s face it, this is not good for our reputation.

It doesn’t have to be this way. Systems projects do get delivered on time. And on budget. Without creative reassessment of what was originally promised. Honest. I’ve seen it. It just doesn’t happen often. What’s important to understand is why.

If you look at your average construction project, it’s rarer that you run into major deviations of cost or schedule. So why can’t systems projects meet with the same degree of repeatability and success? There are three key reasons:

• For starters, the proportions are all wrong. If you look at the cost of materials and supplies relative to the cost of labour on a construction project, significantly more generally gets spent on stuff than on people. For systems projects, the reverse is true. It is not out of line for the budget for equipment to be a mere 10% of an overall systems project budget, and it is rare for this amount to exceed 25%. For both project types, the amount of stuff required is much easier to estimate than the overall effort.
• Secondly, it is easier to estimate the overall effort on a construction project. Construction materials and methods are known, the time it takes to lay a brick is relatively finite, and we have a much better handle on the size and complexity of one building relative to another. The size and complexity of an information system, however, is a much more difficult thing to measure reliably. The systems project is therefore hampered in its ability to compare and leverage the results of previous projects. What doesn’t help in this respect is that the tools and methods within the systems industry also change at the speed of light; even where projects are truly of similar size, the differences in approach makes any comparison almost meaningless.
• Finally, given the relative difference in the proportions of effort to stuff on construction projects versus systems projects that we have already explored, a 20% overrun in total effort will have a much larger impact on both the final cost and delivery date of a systems project than it will on a construction project. Even if both projects perform equally poorly, the construction project cannot help look better if the only measures are of cost and schedule.

While this is by no means an exhaustive assessment of the problems and pitfalls that plague the information systems industry, it certainly serves as a summary of those inherent things that systems project teams cannot control.

What it does not excuse is those things that can be controlled:

• Defining and finalizing requirements before you start to build it. After all, would you start building your house until you saw the plans of what it was going to look like?
• Managing the impact of changes to the requirements. Your builder is going to get uppity if you replace the linoleum in the kitchen with marble. Why expect your systems team to let you get away with it?
• Leveraging the results of previous projects. I said it was hard, but it isn’t impossible. What automatically rolls into this one is a commitment to a consistent process, to managing and measuring the project effectively, and to investing the effort in determining its functional size. All of which people generally hate to do. We don’t like cough syrup either, but hey, it works.
• Making sure the customer gets involved. This is an investment of time, patience and care. But for the same reason you don’t ignore the process of building your house until the day you move in, don’t ignore the building of your information system. You have to live with it for just as long a period.

While construction projects aren’t the same as information systems projects, the theories and principles of project management are. And while systems projects may have more uncertainty to them than we might necessarily like, it doesn’t mean we have to give up those certainties that we can have. Don’t.