What Lessons Can We Learn Today From Mega-Project Management
1. Overview
Although many of the software development professionals visiting this website may not have participated in megaprojects, they will, as I have, find the challenges these projects face pretty familiar.
Therefore, we hope this article’s ideas might be useful when planning or executing your next project.
Bent Flyvbjerg has been studying megaprojects for 30 years and has published several papers and books on the topic. His work will form the basis of our subsequent analysis and discussion.
So, what are megaprojects?
Megaprojects include hydroelectric dams, chemical-processing plants, enterprise IT systems, nuclear power plants, space missions, and military invasions. Megaproject budgets typically span billions of dollars and can be business or government-sponsored.
Two characteristics set these initiatives apart from projects we are familiar with: they are monolithic and bespoke solutions generally relying on novel technology and design.
This article describes the main features of megaprojects (and why they fail in most cases to deliver on time and within budget), the project delivery model employed, and potential solutions.
We conclude with some remarks on how insights gained in studies of megaprojects might apply to their smaller cousins.
2. Features of Megaprojects
Megaprojects present distinct features, according to Flyvbjerg, but, as any IT professional who worked on large projects might recognize, these characteristics are inadvertently present in large and medium-sized initiatives as well, although perhaps to a lesser degree.
Below is a list of the most prominent characteristics defined by Flyvbjerg.
2.1 Inaccurate Forecasts and Project Risk
In papers published by Flyvbjerg in 2006 and 2014 on inaccurate forecasts and project risks, the author outlines the following ideas:
The author recommends using reference class forecasting instead of traditional methods to combat such challenges. This method was invented by Nobel-prize winner and economist Daniel Kahneman (author of the international bestseller Thinking Fast and Slow).
We will discuss reference class forecasting in its own section.
2.2 Lack of Technical Expertise in Project Management
Project management involves complex decision-making requiring some familiarity with a project’s technical aspects and no small amount of domain expertise. Long-running projects tend to see project managers come and go and have little time to learn.
When project constraints are unmet, they must be revisited, and new schedules and budgets laid out. The scope might also be tightened as long as the solution remains viable. All this involves complex negotiations with business stakeholders, project sponsors, suppliers, contractors, and clients.
Inexperienced or new leadership will struggle under situations of intense pressure.
2.3 Decision-Making and Conflict of Interest
Stakeholder management rises to a new level in global or multi-regional projects involving stakeholders from diverse socio-cultural backgrounds.
This diversity makes planning particularly challenging as people with different or conflicting interests are involved in decision-making.
2.4 The Uniqueness Bias
The uniqueness bias is a potential explanation of why managers of large projects who view their projects as unique are more prone to failure. The main ideas are as follows:
2.5 Over-Commitment
Flyvbjerg, Cantarelli, and Molin, in a 2014 paper, discuss the issue of overcommitment to hasty decisions, long-running costly projects, and faulty specifications.
They then use overcommitment to at least partially explain the significant overruns that megaprojects may incur.
Their ideas are as follows:
2.6 Strategic Misrepresentation, Principal Agent, and Rent-Seeking
According to Flyvbjerg’s studies, three behavioural biases contribute to understanding megaproject outcomes regarding cost overruns.
2.7 Impact of Rare Events
Project delivery is inherently risky and stochastic, but megaprojects carry the additional risk of higher exposure to Black Swans due to their extended schedule.
The impact of rare events (or Black Swans as they have come to be known through Nassim Taleb’s best-seller The Black Swan) on project delivery is illustrated with the following ideas:
2.8 Complexity
The scientific school of management, championed by mechanical engineer and business consultant Frederick Taylor, taught that any production process could be measured and quantified for efficiency and low variations in the output’s quality.
Not long after that, the intricacies of stakeholder relationships lept to the forefront, and complexity emerged as a result.
Complexity arises when the human element is introduced into any mechanistic Newtonian system, especially in the form of human social groups. Direct causal relationships disappear, and rigid control and direction become negligible.
3. The Planning Fallacy
3.1 Problem Description
Daniel Kahneman and Amos Tversky ran experiments in 1979 to prove how inadequate people are at forecasting. Their ground-breaking work helped Kahneman win the Nobel Prize for his theories on behavioural economics.
The result of their experiments was as follows:
In fact, this happens all the time, even for mundane tasks we commit daily. This serious underestimation of future efforts leads to serious planning issues. Hence, the term planning fallacy denotes the illusion of having things under control.
3.2 Reference Class Forecasting
Kahneman and Tversky recommended that forecasters make every effort to frame the forecasting problem into something they are familiar with to facilitate utilizing all the available historical information (in the form of probability distributions).
They emphasized how using distributional information from previous initiatives like the current one helps take an outside view. Reference class forecasting helps forecasters take the outside view. It works as follows:
- Select a reference class of past, similar projects. Attributes such as size, state of technology used (novel, mature), and industry can be used to define a similarity measure.
- Generate a probability distribution for the selected reference class. For example, the probability distribution should show the cost on the x-axis if you forecast costs.
- To establish the most likely outcome, compare your new project with the reference class distribution. You must also look at variability to determine whether project risk is high enough to warrant contingency planning.
3.3 Forecasting Without Error Rates
In his monumental work The Black Swan, Taleb discusses three fallacies as a result of looking at the expected outcome of a forecast rather than a range of probable values. These are as follows:
4. Project Delivery and Management
4.1 The Break-Fix Model
Flyvbjerg describes the current project delivery methodology of megaprojects with the Break-Fix model. It works as follows:
4.2 Negative Learning
In his paper Make Megaprojects More Modular, Flyvbjerg tells the story of the Japanese nuclear reactor project Monju, whose construction was approved in 1983 and began in 1986.
In December 2016, three decades after its inauguration, the power plant was shut down indefinitely. After 34 years and 12 billion dollars, Monju generated an hour’s worth of electricity!
Monju’s story is a perfect example of negative learning, a situation where the more you learn, the slower you go.
The engineering teams working on the Monju project kept finding one problem after another, with each issue pushing the reopening date farther into the future until the government finally decided to terminate the project.
The problem with Monju, as with most failed megaprojects, was its monolithic and bespoke nature.
On the opposite side of the spectrum, we have Tesla’s Gigafactory 1 and Madrid’s railway expansion project, whose secret was an iterative approach and modular design based on mature technology and robust engineering. More on this in the next section.
5. An Agile Solution to Megaproject Delivery
5.1 Replicable Modularity
Consider the following approaches to delivering a megaproject.
- In the first approach, you build a monolithic and bespoke system.
- The project can only be productive when it’s 100% completed.
- Each component is highly customised and requires massive integration efforts. Interfaces are complex, proprietary, and cannot be reused.
- Because every element is unique, few learning opportunities exist, and even fewer lessons can be carried over into other project areas.
- Experimentation and rework are challenging and expensive.
- Under this regime, there are no fail-fast and fail-safe experiments.
- Once the project is completed, scaling up is exceptionally challenging.
- In the second approach, the design is modular, and the entire project can be built from similar components.
- With this approach, the project can start production once its first module is installed.
- Reusable modules allow experimentation and inexpensive learning.
- Lessons learned can be applied in the installation of the next module.
- Losing some modules due to structural or installation errors does not jeopardise the entire venture.
- The project can start small and scale on demand.
5.2 Speed in Iterations
You typically cannot predict with arbitrary precision how users will interact with a product or how their preferences will change as they come to understand what the technology can do for them. This statement is especially true for novel systems.
For example, a Minimum Viable Product or MVP is first produced for new software products. Its objective is to get user feedback as early as possible, allowing product managers to gauge the product’s viability and provide insights into what features to build next.
In this context, speed is of the essence, usually facilitated by applying an iterative approach to releases.
Combined with modularity, an iterative approach allows engineers to constantly improve the quality of their deliveries while learning as they go.
If the modules used are the same, a self-similar architecture will emerge. Otherwise, a complicated or even complex system will take shape.
5.3 Technology Selection
We have dedicated an entire article to technology stack selection in software engineering. This section will reuse some of the ideas in the context of megaprojects, gleaning further insights from Flyvbjerg’s studies.
The first idea is to use reliable and mature technology (Principle 6 from Operational Excellence in Software Engineering). While that may sound dull and not as innovative as we would like it to be, innovation can still be created by combining old ideas in new ways.
The second idea is to use technology that lends itself easily to modularity. In the energy industry, wind turbines are a perfect example of modularity. Software solution architectures can be designed for modularity and scalability. Standard interfaces facilitate integration efforts.
These parameters (tech stack selection, architecture, solution design) can be selectively chosen for maximum modularity.
6. Final Words
At the beginning of this article, we set out (as software practitioners) to explore the influential factors in the success or failure of megaprojects so that perhaps we can draw some parallels with the more manageable IT projects we are familiar with.
Below is a list of similar challenges and what we can do about them.
7. References
- Make Megaprojects More Modular — by Bent Flyvbjerg
- What You Should Know About Megaprojects and Why: An Overview — by Bent Flyvbjerg
- From Nobel Prize to Project Management: Getting Risks Right — by Bent Flyvbjerg
- Making Sense of the Impact and Importance of Outliers in Project Management through the Use of Power Laws — by Alexander Budzier and Bent Flyvbjerg
- Lock-in and Its Influence on the Project Performance of Large-Scale Transportation Infrastructure Projects: Investigating the Way in Which Lock-In Can Emerge and Affect Cost Overruns — by Bent Flyvbjerg, Chantal C. Cantarelli, Bert van Wee, Eric J E Molin
- Thinking Fast and Slow — by Daniel Kahneman
- Antifragile — by Nassim Nicholas Taleb