It is a well known fact that IT projects fail with an alarming rate (some surveys suggest that the failure rate is more than 60%). Typically, project managers try to “recover” from these failures either by squeezing their resources to work extra hours or by compromising the quality of the deliverables (reduce testing effort, reduce scope etc.). Unfortunately, software quality is not deemed as very important by the business leaders.
I wonder if this is true about other professions as well ? How are projects managed, for example, in the construction industry where the cost of failures is very high and where a single mistake can be catastrophic ? Mega engineering projects like the Eurotunnel and Petronas towers required thousands of people and billions of dollars to construct and yet most of these projects were completed successfully within or sometimes even before time.
Are there some lessons we can learn on how projects are planned and managed in other industries ?
Let’s take a bridge as an example, and compare it with software.
The bridge will have fewer external specifications. It will have some pretty exacting specifications, but a lot of those will be internal (such as material strengths).
It will be designed by people who know that bridge design is not to be excessively rushed. In general, civil engineers will get more respect from their management than software developers. The civil engineers will in addition be working in a much more constrained problem space. There aren’t nearly as many ways to make a bridge as an inventory system.
When the design is done, one or more licensed professional engineers will sign off on it. This is accepting real responsibility. (Alternately, no PE will bet his or her license on its soundness, and the design won’t go anywhere.) This doesn’t happen in software, partly because the problem space is so unconstrained.
Finally, the bridge will be built, and this will take months and a lot of heavy equipment. Software will be built initially with a compiler and reproduced indefinitely with cheap tools. There is a great psychological significance here: people tend to think of projects as having significant design and significant manufacturing stages, and if manufacturing is too trivial tend to think of part of the design as manufacturing.
If software were to be more like civil engineering, we’d need standard practices, adequate and reliable, for most things. We’d need engineers to study those practices, and be willing to certify that software either was or was not designed properly, and in fact we’d need projects done according to those practices to be almost completely reliable. We’d need more formal assumption of responsibility there. We’d need more external respect, because managers that will not dare throw away a $10 million construction project by meddling will often have no qualms about messing up a $20 million software project.
In short, software is too immature a discipline to work like civil engineering.