I don’t know how many people realize that, but the roots of modern project management are in the early 20th century and stem from heavy industries, military logistics and… civil engineering. Gantt himself was working in the late 19th century steel industry, his chart (in its current form invented in fact by Karol Adamiecki) was used in the major construction projects of the New Deal (like the Hoover Dam). It was long before any software projects that it has become an icon of project management along with a whole set of methods, practices and theories.

There is no doubt that these methods were proven to work for the industries they were invented for. They got refined over the years, getting to the point where they could be considered scientific. A whole body of knowledge was gathered over time, institutionalized in bodies like the PMI, their PMBOK and certifications. Then all that was applied to software engineering, which someone erroneously mistook for another form of engineering or even manufacturing.

The problem is that a typical software project is very unlike an assembly line, but also differs very significantly form any civil engineering construction project. Let’s take my favorite example – building a bridge – and compare it to a software project.

When you build a bridge the environment (layout of the river, hills around it etc.) is largely known and very unlikely to change, as opposed to modern software projects. Also the requirements of the client are very simple, clear and not likely to change – no one sane will ask the bridge to be drastically changed midway into the project. The complexity level of the object being created is much lower than in an even small software project – depending on how you count even a simple software package contains hundreds of functions and thousands of variables.

The human side is also very different. In traditional industries, like civil engineering, organization is based on few knowledgeable individuals having a picture of the whole at the top and a command chain that transmits their design to the workers executing it. A typical construction worker doesn’t have to know the whole design of the bridge, nor is he required to be capable of understanding it. He has to be able to do well some specialized task (like pouring concrete or laying reinforcements) where directed. It doesn’t mean he is stupid – don’t get me wrong – but his training and knowledge are very different from that of the civil engineer who designed the whole structure.

This is quite contrary to a typical software developer who not only has to be capable of understanding the whole of the project he works on, but also has to know and understand the design to be able to effectively contribute. This is why organizing software development with command chains and “architects” leading the (largely ignorant) flock is wasteful and wrong. There is no doubt that developers with bigger experience are better at design and are better suited to lead juniors, but there is no fundamental difference between them.

There is nothing new going on here – humanity has always tried to apply methods from the past to the problems of today. It mostly worked, but sometimes it didn’t and the visible failure of existing methods or assumptions usually led to a positive change. The same is now happening with the software engineering. After realizing that the classical waterfall approach rooted in other industries from another time led to poor quality and even worse predictability the IT industry moves forward with the agile movement.

Agile is now quickly becoming mainstream because it reflects the reality of software creation. That’s why itn most cases it delivers on its promises of delivering better product and increasing teams effectiveness.

Building a bridge is my personal favorite example, because that’s what my father was doing before he moved into materials science.