What Project management lessons and best practices can we learn from the engineering and construction industry? [closed]

Question

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 ?

Answer 1

I think the biggest difference is that they would never consider starting a project with the same kind of shoddy requirements we are given. Maybe we should stop doing so as well and force people to actually define what they want before we start trying to code it.

I wanted to add that we as an industry to a lousy job of pushing back with a new timeline and budget when the requirements (such as they are) change. We started to do much more of this pushback here, telling the customer how many more hours (and more money) the requested change would take, adding the two extra days to do the the exisitng deadline and making them formally put in a request for change. The number of requested changes to intial requirments dropped drastically once we insisted there would be a cost for the change. This change also moved us from a cost center to a profit center in the company as we were doing a lot of extra work but not charging the customer more than the intial estimate.

Answer 2

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.