IT Projects: Built to Last

There is a widespread perception that construction projects are inherently better managed than IT projects. Interestingly, it isn’t just the engineers that think this; often project managers within the IT profession guiltily believe the same thing.

In my work developing project management capabilities within organizations in both camps, it has become obvious that there is just as much opportunity to have a construction project go wrong, and for similar reasons. There are, however, some structural differences in how construction projects are managed that lessen this risk and, when applied to the IT field, can greatly improve the probability of success.

Design Required
One of the points of greatest perceived difference between the IT and construction worlds is the ability to bring projects in on time and on budget. Again, there are some structural reasons for this. The greatest cost of a construction project is the materials used in construction – steel, concrete, glass and the like. Once the design is complete, the quantities required are known and the costs are easy to calculate. The greatest point of variability in any project estimate is people – in IT projects, however, people represent a much larger proportion of the final cost.

So if the effort of people to get work done is so difficult to estimate, do we have any hope of improving our project estimates? The answer is a resounding yes. Here's the phrase that jumps out from the last paragraph – ‘once the design is complete.’ Construction projects don’t commit to a final cost until completion of the detailed design and construction drawings – the specifications of how, bolt by bolt, you are going to build the project. In the IT project world, however, costs are often committed to before the requirements are fully understood, and in many cases a detailed design is never even produced.

If we are going to get better at managing IT projects, valuable time needs to be spent in understanding requirements and detailed design planning. On projects that work well, up to 45 percent of the project effort can be expended in these two phases; one of the greatest reasons for IT project failure is glossing over requirements and design in order to get on with building. Many building contractors will not proceed with construction until they have detailed working drawings and specifications that explain exactly how construction is to be done – every join, every beam, every piece of construction is detailed out. So why will so many IT project teams launch forward without confirming that what they are contemplating can even be built?

Know Your Roles
And then there is the project team itself. One of the greatest differences between construction projects and IT projects is the structure of the team. Within the world of construction, the design team (the architect and consultants that design and specify the building) is completely separate from the construction team (the general contractor and trades that actually build the project). In addition to being separate teams, they have very different contractual obligations – the designers continue to be involved in the project throughout the lifecycle, managing scope changes, clarifying design questions and performing quality assurance to make sure that what was designed is actually built. The contractors’ responsibility is simply to build to the designs. This forces any design issues to be formally addressed, and the drawings to be updated when something must be changed. Even where there is a detailed design for an IT project, it is rarely updated to reflect changes or the resolution of problems. Instead, they are all too often just brushed under the carpet, hopefully to be forgotten about.

Scope changes, too, are often brushed under the IT project carpet. Again, the formal distinction between what was originally committed to and what will ultimately be produced is blurred by failing to produce a detailed scope, specification and plan. The contractual nature of the architect’s and general contractor’s roles force a formal approach to managing scope changes; any additional requests by the customer must be paid for by the customer; any flaws in design, however, become the responsibility of the architect. Imagine the impact on your next IT project if the designer was on the hook for paying for his mistakes.

Satisfaction Guaranteed
And finally, the process of quality assurance is formally managed in the construction world, whereas IT projects often view this as an expensive luxury--and the first cost to be sacrificed in meeting an unrealistic budget. The customer of a construction process would never accept the elimination of the commissioning phase – the acceptance period where a building is put through its paces to make sure that everything does what it was supposed to do. And warranties are taken very seriously indeed. In large construction projects, warranty periods of a year are not uncommon, and any flaws within that period are the responsibility of the general contractor to resolve.

Even with all of these strategies and techniques, there is no denying that construction projects still go badly, horribly wrong. Construction project managers still have to deal with unreasonable expectations, difficult customers, personnel problems and the tendency to ‘pass the buck.’ Yet with these approaches in place, the opportunity for project success is much greater than without them. By applying some of these techniques in the world of IT, the opportunities of your next project to be successful become that much greater as well.