Learning From The Past: The History Of Structured Engineering

Structured Engineering; What is it? Where did it come from? How is it different from what we are doing now? This document attempts to shed some light on these questions by exploring the history of Structured Engineering.

Structured Engineering is a methodology for organizing engineering projects. It is the equivalent of Structured Programming. The core concept behind Structured Engineering is deciding exactly what your goal is, drawing up a plan for reaching that goal, then working to the plan. The alternative to Structured Engineering is to jump in and start building circuits or writing code with no plan.


Before examining Structured Engineering, it is instructive to examine it's predecessor, Intuitive Engineering. In our everyday life, we all have "projects" that we need to accomplish. Examples range from brushing our teeth to planning a vacation. All human beings have an instinctive ability to organize these day-to-day projects. We don't need to learn special methods - our method is simply doing what comes intuitively, and everything turns out all right.

Long before Structured Engineering was invented, Thomas Edison used these intuitive methods. Edison accomplished great things using these methods, but he also reached a hard limit to how complex his inventions could be, and he never overcame this limitation.

In the years since then, we have increased the complexity of electronics and software to the point where some children's toys are too complex to design using intuitive methods. Experience with the limits of Intuitive Engineering was the driving force behind the development of Structured Engineering. Alas, to this day, many engineering departments are still using the same intuitive methods that were in place when Edison started his career.


At the start of World War II, Intuitive Engineering methods proved inadequate to build huge numbers of cargo ships in a short amount of time. The introduction of what later evolved into structured Engineering methods saved the day and, in a very real sense, won the war.

The Allies needed to build a huge number of ships in order to move unprecedented amounts of material overseas, and to do so despite losses to enemy action. If they failed to do so, the war would have been lost. The project managers quickly came to the conclusion that such a shipbuilding effort could not succeed using then-current methods of designing and building ships.

Consider what they accomplished:

Cargo ship construction time dropped from a minimum of 10 months in 1917 to less than 16 days in 1943.

64 times as many cargo ships were built in 1943 than in 1939.

Tonnage production increased by a factor of 67 between 1938 and 1943.

The new ships were faster, cheaper, harder to sink, easier to operate, had more range, and carried more cargo.

The project management methods that accomplished this became the foundation for what eventually evolved into Structured Engineering.

Alas, to this day, many engineering departments have yet to apply the advances in project management that were developed during World War II. The managers of these departments need to be dragged kicking and screaming into the 1940s.


The methods developed in the 1940s provided a good foundation, but the 1960s brought forth a new problem: extreme complexity.

On May 25th of 1961, President John F. Kennedy announced to the nation a goal of sending a man to the moon before the end of the decade, thus starting the largest and most complex engineering project in history.

The complexity was not just a matter of designing a complex system. There was also a great deal of organizational complexity in dealing with the scientific and engineering portions of NASA as well as representatives from industry, universities, research facilities, and politicians. There were major disagreements about everything from overall approach to the finest design details. NASA had to meld these disparate institutional cultures and approaches into a unified organization moving along a single unified path.

In addition, the spacecraft and it's support system was extremely complex. The Apollo managers had to orchestrate more than 750 contractors providing millions of parts. All of the parts had to meet exacting specifications for performance and reliability, and every single part had to be engineered, built, and tested on time. If any part was late, the Apollo project would be late. NASA's procurement actions rose from roughly 44,000 in 1960 to almost 300,000 by 1965.

To bring order to the program, NASA took the program management concepts developed during World War II and refined during the Minuteman ICBM program to the next level. This required a rethinking of design, engineering, procurement, testing, construction, manufacturing, spare parts, logistics, training, and operations.

They succeeded. On July 20th of 1969, Neil Armstrong set foot on the surface of the Moon. The most complex task ever attempted by man was accomplished before the deadline.

Structured Engineering techniques were widely recognized as a critical component of Project Apollo's success. In November of 1968, Science magazine, the publication of the American Association for the Advancement of Science, observed: "In terms of numbers of dollars or of men, NASA has not been our largest national undertaking, but in terms of complexity, rate of growth, and technological sophistication it has been unique. It may turn out that [the space program's] most valuable spin-off of all will be human rather than technological: better knowledge of how to plan, coordinate, and monitor the multitudinous and varied activities of the organizations required to accomplish great social undertakings."

Understanding the management of complex structures for the successful completion of a major engineering project task was arguably the most important result of the Apollo effort.

Alas, to this day, many engineering departments have yet to apply the advances in project management that were developed during the Apollo project. They need to be dragged kicking and screaming into the 1960s.


Let's assume that the person reading this sees the benefit of abandoning unstructured, ad-hoc, garage shop engineering methods, and indeed has made some progress in the area of planning and organizing. The question then arises whether the resulting way of working is really Structured Engineering under another name.

The test is simple.

With Structured Engineering, every person who works on the project has a copy of written documents that answer in detail the following questions:

Who is working on this project?

What is each project member's role?

What is the definition of "done"?

How long will it take to finish?

How much will it cost to finish?

What has already been done?

How much time did it take to get this far?

How much money did it take to get this far?

If nobody is tracking the evolving answers to all of the above questions and distributing the answers on an ongoing basis to everyone concerned, then you are only fooling yourself if you think that the project is in control.


As shown above, history demonstrates the advantages of Structured Engineering methods. Without them, Edison was not able to advance beyond a certain point, but their use turned the otherwise "impossible" into "possible and done" in both the Liberty Ship and Apollo programs.

Today's "impossible" engineering projects can, with surprising regularity, also be transformed from "impossible" into "possible, done, and on time and under budget" using the same techniques.

Study after study has shown structured project management methods to be effective on small projects, large projects, low-tech projects, high-tech projects, garage shop projects, construction projects, hardware projects, and software projects. Experienced project managers (including myself) who have tried Structured Engineering techniques report large improvements in quality and large reduction in missed schedules.

There is a better way.