By Mark Mullaly, PMP
There is a widespread perception that construction projects are inherently better managed than IT projects. Interestingly, it isn’t only the engineers who 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 as an IT project, 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.
One of the greatest perceived differences between the IT world and the construction world is the ability to bring projects in on time and within budget. Again, there are some structural reasons for this. The greatest cost of a construction project is in 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 joint, 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?
Does the logic apply?
Is it possible to apply these lessons from the construction world to IT projects? Post your thoughts below.
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 the designs. This forces any design issues to be addressed formally 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, ideally 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 forces 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 effect on your next IT project if the designer were on the hook for paying for his mistakes.
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.
For more articles and downloads fromgantthead
For more information on this topic, check out these related downloads:
Follow these links to related articles:
NOTE: Bold itemsare available to gantthead premium members only.
Mark Mullaly is president of Interthink Consulting Incorporated, an organizational development and change firm specializing in the creation of effective organizational project management solutions. He writes gantthead’s monthly PMP: Project Management in Practice column.
This article was originally published on gantthead on Jan. 31, 2001.