Adventure is just bad planning
– Roald Amundsen
In most of Europe, today is a cold mid winter day, which is a perfect setting for staying indoors and engaging in some tranquil reflection and thought. In this blog post, we examine the nature of public planning disasters, taking off with a recent example from Berlin´s new airport and ending with some reflections on modern project and risk management.
Berlin Brandenburg Airport
The German newspaper Der Spiegel reported that Berlin Mayor Klaus Wowereit had toured the tower of the yet-to-be-opened Berlin Brandenburg Airport. At 72 meters the tower is 1 meter higher than the one at Frankfurt’s airport. It is a subtle symbol of Berlin’s newfound confidence.
However, when the mayor had seen enough and got into the elevator to go down, it got stuck. The mayor and his party had to be carefully cranked down by hand from the high-tech tower to the troubled reality below. This story is symptomatic of the disasters that have fallen upon the project to construct the airport.
In 1991, soon after the reunified Germany decided to move its capital back to Berlin from Bonn, the planning started for a suitable new airport. Berlin had three tiny ones: the famous Tempelhof (now closed), Tegel, which is also in western Berlin, and Schönefeld in the eastern part of the city. During the years of division, Tegel had mainly served the airlines of the three western Allies while East Germans had used Schönefeld.
Project planning for the new airport started in 1996 and construction began in 2006. The target was to open Berlin Brandenburg Airport in 2010, but the opening date has been postponed four times due to delays in construction. The airport is now due to open on October 27th 2013, but according to recent news update it is believed to be ready in 2014 at the earliest.
The development of Berlin Brandenburg Airport is reported to have encountered a series of delays due to poor construction planning, poor project management and poor project execution.
The new airport originally got approval for handling 45 million passengers a year, but is now constructed for only 27 million, which is roughly as many as the existing airports handled in 2012. This means that already when the airport is opened, it will be too small.
The construction of the airport originally had a budget of €2.4 billion but is now likely to cost twice as much. Unfortunately the additional costs will not stop there. It has been estimated that the airport has been planned with too few check-in areas and too few parking positions for aircraft.
Also the location was badly planned. Some 100,000 Berlin residents will suffer from noise, whereas it could have been 30,000 if the location had been slightly different.
Great Planning Disasters
In 1980, the English urbanist Peter Hall published a book called Great Planning Disasters. The book looks at how seven very different projects that were developed during the 1970s played out, why they were pursued in the first place, and what we can learn from them for the future.
I bought the book second hand more than 20 years ago, and I came to think of it as I read about the Berlin Brandenburg airport.
As the scale of planning increases so do the possibilities for error. Hall argues that the scale of some planning mistakes is such that they may correctly be termed disasters.
The books examples are large scale projects, such as the Third London Airport and the Sydney Opera House. They were largely inspired in and by the public sector where it was assumed that such projects could not be generated for private gain but were so extensive that a combination of private and public agencies were required in their planning and implementation.
Two sorts of disaster are discussed: positive and negative. The former have been implemented and includes the Concorde aircraft and the Sydney Opera House, the latter aborted, including London’s third airport.
The author analyses how the conditions and the protagonists can give rise to planning disasters, and suggests some ways in which disasters may be avoided or limited. Hall identifies the two main reasons for planning disasters: overestimation of demand and underestimation of cost.
Each project is very different from the next, but there are a few important reoccurring themes that Hall stresses as the major causes for disasters. Of course each plan was carried out in a different time frame, in a different place, concerning different people, and of course had many different reasons for failing (or nearly failing), but the same issues come up time and time again. These include poor financial planning, inadequate population studies, and the ego of those in power.
The plans that Hall focuses on are massive and in turn are very costly. The plans range from a couple million pounds for the negative plans to the billions for the positive ones.
Sydney’s Opera house cost just under one billion Australian dollars, BART, the Bay Area Rapid Transit system serving the San Francisco Bay Area, cost approximately 1.6 billion US dollars, and the Concorde, which was by far the most costly, ended up totaling two billion pounds.
The problem that Hall has with these numbers is not simply due to the fact that the respective administrations spent this much money on projects that ended up not delivering on their promises (although this is obviously an important issue as well), but rather that the costs were never accurately forecasted to be so high.
The projects were all severely underestimated; either by a lack of understanding of the markets, extremely long time delays, or by the simple fact that studies were not done.
In the case of the Concorde airplane, Hall states that the “cost estimates were simply made up” because those in charge did not truly care about the feasibility of the project, they just wanted it done.
Concorde and BART had the unique characteristic of being somewhat commercial projects, in that they needed to be “sold” to the public. However, the demand for both super-sonic jets and high speed rail were vastly overestimated, and again in the case of the Concorde, Hall states that there “was no firm estimate of sales at all”. The project was devised and built on the ambitions of prestige.
Both Concorde and BART used incredibly expensive brand new disruptive technology that was untested, resulting in escalating costs and a complete lack of knowledge by experts to estimate the final cost. Not to mention the fact that the new technology resulted in massive problems, such as delays and system failures in BART, resulting in more labor costs and more time.
The Sydney Opera House had a different problem; they could not accurately estimate the costs due to the fact that the main architect did not have detailed plans for the building, causing officials in Sydney to hire new consultants and finally a new architectural firm completely for several million extra dollars.
The end result for all of these “disasters” was a final bill that shocked the public and required an explanation, and most of the people in power had no more to say than “we didn’t know” or in the worst cases “we didn’t care”.
Peter Hall mentions more than once that there is “no magic formula” for fixing these projects or for creating perfect ones in the future. Rather one must look at this book as a means for making improvements and forming guidelines.
Naturally all of the projects named involve planning, and more specifically long range planning. A handful of the cases involve the environment, either wanted to protect (as in the BART example) or not taking it into consideration enough (as with the London motorways or the airport examples).
And all of the projects involve some government involvement and are very politically charged. Hall attempts to give some theory about how long range planning can be accomplished for even risky and uncertain events. He pushes for detailed studies of projects in the past, as well as more realistic studies on current trends. Hall says that checks and balances should be created within the planning system so that no one agency or group has more control than another. This would take care of the problem of shifting governments and perhaps the lack of experience of some architects or planners.
Hall also believes that forecasts should be qualitative as well as quantitative in order to adjust for certain political or value changes in the mind of the public.
As for the political nature of the projects, one must accept that you cannot separate planning from politics. They go hand in hand most of the time, and as Hall states “if a planner ignores political behaviour, his decisions will be simply unrealistic”, but at the same time he cannot bend over backwards to accommodate politicians. However, more checks and balances would help control outrageousness of the governing body. Also Hall advocates for incorporating politics into forecasting and risk management methodology.
An earlier approach to understanding planning disasters was defined in Horst Rittel and Melvin Webbers article Dilemmas in a General Theory of Planning, published in the journal of Policy Sciences in 1973. The article can be downloaded by clicking on the link below:
In the article, the authors explain that the search for scientific bases for confronting problems of social policy is bound to fail, because of the nature of these problems. They are "wicked" problems, whereas science has developed to deal with "tame" problems. Policy problems cannot be definitively described.
Moreover, in a pluralistic society there is nothing like the undisputable public good; there is no objective definition of equity; policies that respond to social problems cannot be meaningfully correct or false; and it makes no sense to talk about "optional solutions" to social problems unless severe qualifications are imposed first. Even worse, there are no "solutions" in the sense of definitive and objective answers.
Wicked problems, according to Rittel and Webber, have ten characteristics:
- There is no definitive formulation of a wicked problem. Formulating the problem and the solution are essentially the same thing. Each attempt at creating a solution changes the understanding of the problem.
- Wicked problems have no stopping rule. Since you cannot define the problem, it is difficult to tell when it is resolved. The problem solving process ends when resources are depleted, stakeholders loose interest or political realities change.
- Solutions to wicked problems are not true-or-false but good-or-bad. Since there are no unambiguous criteria for deciding if the problem is resolved, getting all stakeholders to agree that a resolution is ‘good enough’ can be a challenge.
- There is no immediate and no ultimate test of a solution to a wicked problem. Solutions to wicked problems generate waves of consequences, and it is impossible to know how all of the consequences will eventually play out.
- Every implemented solution to a wicked problem has consequences. Once the airport is opened or the new train station goes live, you can’t revert to any previous solution.
- Wicked problems do not have a well-described set of potential solutions. Various stakeholders will have differing views of acceptable solutions. It is a matter of judgment as to when enough potential solutions have emerged and which should be pursued.
- Every wicked problem is essentially unique. There are no ‘classes’ of solutions that can be applied to a specific case. Part of the art of dealing with wicked problems is the art of not knowing too early what type of solution to apply.
- Every wicked problem can be considered a symptom of another problem. A wicked problem is a set of interlocking issues and constraints which change over time, embedded in a dynamic social context.
- The causes of a wicked problem can be explained in numerous ways. There are many stakeholders who will have various and changing ideas about what might be a problem, what might be causing it, and how to resolve it.
- The planner (designer) has no right to be wrong. A scientist is expected to formulate hypothesis, which may or may not be supportable by evidence. A project planner doesn’t have such a luxury, they are just expected to get things right.
The Project Management Triangle
If the problem in Berlin, and in other great planning disasters, lies in project planning and project management failure, what is it concretely that have failed? The answer may lie in the project management triangle.
I studied project management for the first time in 1992, as I took a course at the IBM Education Center on Lidingö in Stockholm. I have been fascinated by and practiced project- and risk management methodologies ever since. The course I took was according to the PL10 IBM Project Management methodology, with the five traditional project components:
- Project Initiation
- Project Planning and design
- Project Execution
- Project Monitoring and controlling systems
- Project Completion and follow-up
Today the main project management methodologies in use are PRINCE2, PRISM, PMBOK etc., and there are certification courses and diplomas for each. However at the core they are similar and teach the same concepts, albeit with different terminology.
Project management is the discipline of planning, organizing, motivating, and controlling resources to achieve specific end goals. A project is a temporary activity with a defined beginning and end. It is usually time-constrained, and often constrained by funding or deliverables.
The temporary nature of projects stands in contrast with business as usual which are repetitive, permanent, or semi-permanent functional activities that organisations perform to produce products or services.
In practice, the management of projects and the management of business-as-usual is quite different, and as such requires the development of distinct technical skills and management strategies.
All projects have specific constraints in time limit, budget, and scope and a unique project organisation. The constraints are set and optimised by the initial project planning process, and they are the constraints to follow during the projects execution.
Often the three constraints are portrayed as a triangle. If you adjust any one side of the triangle, the other two sides are affected. Quality is a function of all three.
The time constraint refers to the amount of time available to complete a project. The cost constraint refers to the budgeted amount available for the project. The scope constraint refers to what must be done to produce the project’s end result.
These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope.
For example, if you decide to adjust the project plan to:
Bring in the scheduled finish date, you might end up with increased costs and a decreased scope.
Meet the project budget, the result might be a longer schedule and a decreased scope.
Increase scope, your project might take more time and cost more money in the form of resources, such as workers.
The art of project planning is to get the initial plan right, so that it is possible to deliver the required scope within the set time limit and to the calculated budget cost.
Sounds easy, but in complex projects (such as the construction of an airport) it becomes an extremely complex task to get the planning right.
It does not matter what industry you are in, how experienced you are, how "different" your project is, or what version of project management methodology your organization uses. At every project’s core is the trio of time, cost, and scope. These are the factors you juggle every day to keep your Project plan on track.
The discipline of Project Management is about providing the tools and techniques that enable the project team to organize their work to meet these constraints. In project management there are tools and methodologies to use to get a project back-on-track, when you have noticed that the initial planning was wrong, or when it is put off track due to external circumstances.
How to optimise to meet time schedule
After analyzing your project time schedule, you might find it does not meet the project deadline. There are several ways you can adjust the length of your schedule. The methods you choose depend on the limitations imposed on the project as a whole, such as budget, resource availability, scope, and the flexibility of the tasks.
The most efficient way to shorten the time schedule is to change the tasks that lie on the critical path. The critical path is the series of dependent tasks whose last task finishes at the project end date. If any of the tasks in this series move, the project end date also moves. Modifying tasks that are not on the critical path may not affect the schedule. You can:
- Shorten the duration of tasks (usually a reflection of reduced scope or increased/more efficient resources).
- Overlap tasks so that they can be worked on simultaneously.
- Remove tasks to meet the finish date (usually a reflection of reduced scope).
- Assign additional resources.
- Decrease the amount of work assigned (usually a reflection of reduced scope or more efficient resources).
As you adjust the time schedule, your costs might increase, resources might become over allocated, and your scope might change. For example, if you shorten durations of tasks on the critical path, the project will probably finish sooner, but the scope of those tasks and possibly the entire project might be reduced.
How to optimise to meet budget
You might find that the Project plan you have built exceeds your budget. Project costs are affected primarily by resources assigned to the tasks in the project, the rate-based cost and the fixed costs of people, equipment, and materials. Therefore, to reduce costs, you can cut project scope so that there are fewer tasks or shorter durations for tasks that need resources.
If you don’t want to cut scope, you can adjust resources and make sure that your settings for rates, fees, and overtime are correct. You can verify that the resources assigned are the best for the job. You might be able to replace a more expensive resource with a less expensive one, and use the more expensive resource where it is most cost-effective.
As you adjust the plan to meet your budget, your finish date might be extended, or the scope might decrease. For example, if you remove overtime from tasks that had overallocated resources assigned, you might find the schedule lengthened to the point where the finish date is a month later. Or if you’ve cut scope to meet the budget, you might find that the finish date is actually scheduled to occur sooner.
What happened in Berlin, that made a national prestige project such a failure? What went wrong? Both the theories of Hall and of Ritter-Webber tells us that it is most likely a matter of poor project planning and poor project execution.
Easy then, with clear and well documented project planning and management, such problems should be possible to handle?
However, the conclusions of both Hall and Ritter-Webber is that the problem may not lie as much with the project planners and project managers. These inevitably become the scape-goals, but the real culprits are often the project sponsors.
It is important for every project to have a sponsor to;
Provide the project planners with a clear objective of what the project is set to achieve
Ensure separation of decision making responsibilities between project manager and project sponsor
Ensure accountability for the realisation of project benefits
Ensure oversight of the project management function
Carry out senior stakeholder management
Because the project sponsor is the ‘owner’ of a project from conception to commissioning and operation it is particularly important that the sponsor is extremely clear on the task assigned to the project, and to achieve continuity of sponsor throughout the project. Yet this is correspondingly difficult to achieve because of the extended duration of sponsorship compared to project management.
It is also difficult when it is not clear who is the ultimate sponsor. In Hall´s examples, as in Berlin, the sponsors seems to be a combination of private and public agencies.
In most great planning disasters, the core problem lies in lack of or hidden agenda of the project sponsors.
In Berlin as in Hall´s examples, the project sponsors have not been clear on task, objectives and budget. In fact, which is worse, it seems it has not been clear who are the ultimate sponsors. Is it the city of Berlin or the regional state of Brandenburg or the national governments transport ministry, or Air Berlin or Lufthansa?
Berlin Brandenburg Airport is publicly owned by Flughafen Berlin Brandenburg GmbH, an airport management company, currently also responsible for Tegel and Schönefeld airports. The shares of the company are divided between the states of Berlin and Brandenburg (37 percent each), and the Federal Republic of Germany (the remaining 26 percent). The primary task of this company seems to have been to manage the existing airports and the supervision and sponsor role for the project to build the new one seems to have been relaxed.
Originally, it was planned to contract one private building company for Berlin Brandenburg Airport. Due to arguments over the financing of the political parties involved, the one-contractor-concept was scrapped and a new call for proposals was launched in 2002. In the new call it was decided that, instead of having one general contractor, the contract volume would be split up among numerous companies.
So neither on the project sponsor side, nor on the project planning and execution side has there been any clear authority and organisation.
As is stated in the old axiom GIGO, “Garbage in, Garbage out”, regardless of how accurate a program’s logic is, the results will be incorrect if the planning input is invalid.