This series of posts all has to do with the ways that engineering is critical for our economy, no matter whether you are in an advanced industrial country like Australia, or a developing and low-income country like Bangladesh.  Unfortunately, that link is hardly ever mentioned in engineering schools, let alone understood.

Also in earlier posts I mentioned our appalling and worsening record in completing major engineering projects, and how that is affecting the world’s economy right now, discouraging investors.  Why would anyone want to invest their money with engineers when there’s a good chance of losing all of it, and not much chance of making money?

In this post, I am going to advance another possible reason large projects can fail.  This time the root cause stems from engineering education.

In your first year of engineering, you probably learned about stress and strain. Even if you became an electrical engineer.  Maybe if you’re software engineer you missed out on the fun of playing with elastic beams and springs, noticing how they stretch in proportion to the applied load.

It’s fundamental knowledge for mechanical and civil engineers, and valuable for others.  In most engineering schools, you won’t graduate without having passed an exam on it.

Now, what would be the result if engineers had to pick up that knowledge on the job?

Well, apart from French and German engineering schools that adopted a rigorous curriculum from the start of the 19^th century onwards, if not earlier, most engineers did learn on the job until the early 20^th century.  After completing 10 years of school, they would be “indentured” as an apprentice to a practicing engineer to learn the profession, and often that meant that parents had to pay a substantial sum of money to the engineer for the privilege.  They spent years alongside a more experienced engineer, gradually picking up the ideas they would need in practice, often by trial and error.

To compensate for lack of theory in their education, engineers opted for cautious designs, knowing that even if they could calculate, materials were often of dubious quality, so you allowed much more material than calculations predicted.  Without calculators and computers, designs were usually based on “rules of thumb” or simple approximate formulae that had worked for engineers before. There were few uniform standards to provide guidance. And failures came frequently, but the 19^th century was a time when engineers were “heroes” and failures were seen as learning experiences on the path to later successes.

Now let’s take a look at engineering practice at the highest level.  This view came from my research on hundreds of engineers, and I was looking for the simplest ways to represent what they were doing.  (See Chapter 3 for more details)

The first diagram portrays engineering as an activity with two distinct threads. The upper thread is comprised of three phases. It starts with discerning, comprehending, and negotiating client and societal needs, and then discussing engineering possibilities with clients and the broader society through various means. The second phase is conceiving achievable and economic engineering solutions that would meet those needs. The third phase is performance prediction: working out the technical performance and the cost of those proposed solutions accurately enough to justify an investment decision.

The lower thread is all about delivering solutions that meet client and societal needs on time, on budget, safely, with the predicted performance, and with an acceptable environmental and social impact. Despite how commonly it is overlooked, this is where most of the work for an engineer lies. Without this second thread, engineering would not yield anything useful. Solutions on paper, no matter how elegant, provide little value until they can be translated into reality. Effective engineers are able to deliver: they get things done.

The large arrow represents the idea that delivery experience helps an engineer to improve performance in the top thread: better discerning client requirements, creating better ideas, and higher quality predictions. This is learning from experience.

Engineering education focuses almost entirely on analytical tools to support technical performance prediction, along with some basic design skills, shown in the dashed rectangles.

The diagram below illustrates how well different aspects of practice are learned in engineering schools.

Understanding and learning about client and societal needs is usually ignored in engineering schools, with the possible exception of requirements engineering in software engineering.

Why?  It seems obviously critical: if an engineer misunderstands what clients need, then it’s unlikely they will deliver a result that meets clients’ needs.

So it is not immediately clear why this critical step is overlooked in practically all engineering courses.  Not that it is easy to teach.  Ascertaining and understanding clients’ needs is usually a social and interactive approach requiring frequent conversations with clients and other relevant authorities.  It is a rare engineer who can then go on and eloquently capture the essence of clients’ needs in a short and succinct technical specification, and almost certainly it will evolve and change.

Conceiving the future is also overlooked in education, except to the extent that students study design.  Yet conceiving the future is much more than design, and may not need design if something already existing can do the job well enough, as often it can.

Students learn really useful analysis methods that can be used for predicting the future, but sadly without the context.  In practice, predictions are often needed really quickly and don’t have to be extremely accurate.

Unfortunately, students tend to spend most of their learning on really accurate methods, methods that are useful, but not always needed.  Really accurate and precise prediction is possible, but takes time and costs money.  So engineers need to decide carefully when really accurate prediction is needed.

It would be better if students could learn how to make predictions to different levels of precision, for example +/- 50%, +/- 20%, +/- 5% and within 1%.  Students learn analysis methods, often without understanding how these methods will normally be used for performance predictions.

Students also need to learn how to fill in the information gaps they will face in practice: how to make realistic assumptions and justify them.  Few of the variables they need will be easy to define.

Engineering students may take a course on project management, which when you look closely, tends to be a course on preparing project plans in the absence of real technical constraints.  But apart from that, engineering students learn next to nothing about actually delivering practical results in a project, large or small.  Many students do projects in small groups in their courses, but without any formal teaching [1].  Research shows that students ignore all the recommended best project management practices even when they receive specific teaching on those aspects.

It is assumed, somehow, that students will pick this up as they gain experience as engineers.

Now, what would you think of an engineering school that assumed that mechanical and civil engineers would pick up all they needed to know about stress and strain in the workplace, omitting it entirely from their courses.  Or an electrical engineering school that omitted fundamental circuit analysis methods?

We would expect frequent engineering failures that could have been avoided with a proper education, right?

Well, when it comes to project delivery today, that’s what we see.  Frequent failures.  When project delivery is missing from engineering education, we could expect that.

What is even more interesting is that, as I shall show in a future post, explanations for engineering value creation, particularly in the project delivery phase, are almost completely absent in the engineering and business research literature.  Engineering value creation is associated with innovation, hi-tech and inventions.  And most engineering projects avoid innovation.  More on that later.

The next interesting questions:

“Why is project delivery performance getting worse today?”  and

“Why did engineers do better at project delivery in the past?  Through much of the 20^th century?”

I will also address these questions in coming posts.

If you’re north of the equator enjoy your summer vacation, or your Eid holidays in the Muslim world. If you’re south of the equator, enjoy less email from the northern hemisphere!

Further Reading

[1] Sheppard, S. D., Macatangay, K., Colby, A., & Sullivan, W. (2009). Educating Engineers. Stanford, California: Jossey-Bass (Wiley).