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

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

There is a difference between software development and engineering or contruction industry - a specification always can be changed.

Walking on water and developing software from a specification are easy if both are frozen.

-- Edward V Berard (from here)

You can find more detailed explanation of differences in approach to project management at the beginning of the "Extreme Programming Applied" book.

Answer 2

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 3

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.

Answer 4

A lesson that can be learned from engineering: respect the non-functional requirements.

Functional requirements are hard enough, as they expect the users, developers, analysts and anyone else involved to be able to define what is needed to do business.

Non-functional requirements are the things engineers and technical people come up with that functional people may be blind to. It's very easy to overlook or downplay the non-functionals. Some PMs I've worked with in the past did not want to hear about non-functionals because they couldn't directly be tied to business needs and introduced tasks that would threaten the metrics of "on time and on budget".

Example

Functional requirement: Luxury ship must be able to carry X amount of passengers

Non-functional requirement: Ship big enough to carry X amount of passengers needs to have hull Y units thick to sustain integrity even upon impact with icebergs

Counting the Cost

Why don't software PMs respect non-functional requirements? Because the cost for such disrespect is different for engineering than it is for software development.

Cost of disregard for non-functional requirements in my ship example: loss of life.

Cost of disregard for non-functionals in software: some wimpy thing called technical debt, which will later be paid for by people long removed from the project team and the project team's completion bonuses.

Granted my examples are simplistic. Not all engineering foibles lead to death while some faulty software certainly can (avionics, medical, or traffic control systems being a few examples). But I think you get the idea.