Risk, Cost & Project Control: Knowing Early That You Are Late

Berlin's new airport was supposed to open in October 2011. Construction had started in 2006, the terminal stood finished, and an opening party was planned for 2 June 2012. It did not happen: the fire protection and alarm system had not been built to the construction permit and failed the mandatory acceptance test. The airport finally opened for passengers on 31 October 2020, fourteen years after construction began. A 2009 budget of €2.83 billion had grown to €5.4 billion by 2015, and later reports gave far higher totals, with the final figure depending on what is counted.

Almost no one in that story was lying about the building. The terminal was real. What failed was the information flowing upward, in reports that were green until they were suddenly not, and a plan with no room in it for a complex system that had never been tested as a whole. This piece is about the tools that exist so that this is noticed earlier: the risk register, reserves, a simulation of the schedule, earned value, and the discipline of change control. They are less glamorous than agile boards, and in construction, aerospace, pharma and public-sector projects they are the daily work.

Risks, issues and the register

A risk is an uncertain event or condition that, if it happens, affects the project's objectives. An issue is a risk that has already happened, or a problem that is certain. The difference decides who acts and when: you manage a risk with a response chosen in advance, and you resolve an issue now. Risk includes good outcomes too: a supplier might deliver early, a new tool might save a month. Many guides call bad risks threats and good ones opportunities.

Good risk statements have three parts, cause, event and effect: "Because the permit office is short of staff (cause), approval might take longer than six weeks (event), which would delay the start of construction (effect)." "Permit risk" is not a risk statement; it is a topic. The statements go in a risk register: a table with one row per risk, giving its probability, its impact, the chosen response, an owner, and a trigger (the early sign). The register's value is mostly in the conversation that writes it, and then in reviewing it every week or two, which most teams skip.

Probability times impact, and why the matrix misleads

Probability times impact is the oldest idea in risk: expected loss is the chance of the event times its cost. The standard picture is a risk matrix (heat map): probability on one axis, impact on the other, each scored 1 to 5, the product coloured green, amber or red. It is fast and everyone understands it, and it is used in project management, safety engineering and security around the world.

It also has well-documented problems. Tony Cox (Risk Analysis, 2008) showed mathematically that matrices can give the same rating to very different risks, and can even rate a quantitatively smaller risk higher than a larger one. Thomas, Bratvold and Bickel (SPE Economics & Management, 2014) argued that the ranking depends on arbitrary choices such as how the bands are drawn. Douglas Hubbard's The Failure of Risk Management (2009) makes a broader case for numerical estimates. Defenders answer that a matrix is a prompt for discussion, not a calculation, and that a rough ordering beats none. Both are fair. The tool below lets you feel the problem.

Without JavaScript: the six risks (probability, cost) are: developer leaves (40%, $80k), data migration fails (15%, $400k), supplier goes bankrupt (5%, $3,000k), sponsor adds scope (70%, $150k), licence price rises (30%, $15k), breach at go-live (10%, $1,200k). Matrix scores are 6, 6, 5, 12, 3 and 8; expected losses are $32k, $60k, $150k, $105k, $4.5k and $120k. The matrix ranks the supplier risk fifth of six; expected loss ranks it first.

The lesson is not "never use a matrix". It is that colours hide magnitudes: a rare disaster and a frequent nuisance can share a score, and a bin can span a factor of five. Use the matrix to decide what to talk about, then put actual ranges (cost in money, delay in days) on the risks that matter.

Responses, reserves and the language of P50 and P80

For each significant threat there are the classic responses. Avoid (change the plan so the risk cannot happen), transfer (let someone else carry it, by insurance or a fixed-price contract, remembering that the other party prices the risk in), mitigate (reduce probability or impact), accept (do nothing now, perhaps holding a reserve), and in PMI's vocabulary escalate (hand it to someone with the authority to deal with it). For opportunities the mirror set is exploit, share, enhance, accept and escalate. After a response you may still have a residual risk, and the response itself may create a secondary one: a second supplier cuts the supply risk and adds an integration risk.

Money and time set aside for risk are reserves. In the PMBOK Guide (6th edition) vocabulary, the contingency reserve covers identified risks and sits inside the baseline, controlled by the project manager; the management reserve covers risks nobody has identified yet, is held above the baseline, and needs the sponsor's approval to use. Other bodies draw the line differently, and government rules often forbid hidden padding, so check your organisation's terms before assuming.

How big should the reserve be? A single estimate cannot say. A Monte Carlo simulation can: give each task a range (minimum, most likely, maximum), draw a random duration for each, add up the path through the network, and repeat thousands of times. The results form a distribution. The date with a 50% chance of being met is the P50; the date with an 80% chance is the P80. A manager who wants to be 80% sure sets the budget at the P80 and keeps the difference from the plan as contingency. Two things surprise people. First, tasks with a long upper tail, which is how real tasks behave, push the average well above the sum of most-likely values. Second, when two paths merge at one task, that task waits for the later of the two, so uncertainty on a "non-critical" path still pushes the finish out (a point 36/91 makes with the critical path).

Without JavaScript: with no risk events, the most-likely path adds to 28 days, but the simulation gives P50 = 37.3 days and P80 = 42.0 days, and only about 2% of runs finish in 28 days or less. With all three events on, P50 = 41.2 and P80 = 47.5.

Cost estimating follows the same pattern. Early estimates are rough on purpose: the cost-engineering profession (AACE International) grades them from Class 5, a concept-stage screening estimate, to Class 1, a definitive one, and the expected error shrinks as the design firms up. A reserve that is large at the start and smaller later is the same idea in money. The US Government Accountability Office's 2020 Cost Estimating and Assessment Guide makes risk and sensitivity analysis a standard step in credible estimates for large programmes. And a reminder from Bent Flyvbjerg's database of about 16,000 projects across many fields and countries (How Big Things Get Done, 2023, with Dan Gardner): only 8.5% hit both budget and schedule, and only 0.5% hit budget, schedule and promised benefits. Flyvbjerg's explanation is largely optimism and strategic misrepresentation at the start (36/90), which a reserve cannot cure, but a better reference class can.

Earned value: three numbers, a dozen answers

Suppose a project is half the planned time in. Are you late? Are you over budget? "We have spent 55% of the money" tells you nothing until you ask how much work that bought. Earned value management (EVM) answers by putting everything in money. It began in United States defence programmes in the 1960s (the Department of Defense's Cost/Schedule Control Systems Criteria, 1967), became the ANSI/EIA-748 standard, and is now used in construction, aerospace and public works in many countries; Australia, for example, has its own standard, AS 4817. It rests on three numbers at a moment in time:

• PV, planned value: the budgeted cost of the work that should be done by now.
• EV, earned value: the budgeted cost of the work actually done (budget at completion, BAC, times the fraction truly complete).
• AC, actual cost: what that work actually cost so far.

The EAC formula is the common default; if the problem was a one-off, the other usual forecast is AC + (BAC − EV). The tool below uses an invented 12-month, $120k project whose plan follows an S-curve (slow start, fast middle, slow finish).

Without JavaScript: at month 6 the plan (S-curve) says 50% of $120k = $60k should be done. With 40% complete and $55k spent: EV = $48k, CV = −$7k, SV = −$12k, CPI = 0.87, SPI = 0.80, EAC = $137.5k, ETC = $82.5k, TCPI = 1.11.

Read the table the way a project controller would. A CPI of 0.87 means each dollar spent has bought 87 cents of planned work. A TCPI of 1.11 says that to finish on budget the team must be 11% more cost-efficient from now on than the plan assumed, which is a claim worth challenging. Three honest cautions. EV is only as good as the "percent complete", which is easy to inflate (the last 10% takes forever), so good practice uses firm rules like "0% until started, 100% when accepted". Schedule variance measured in money drifts to zero at the end even for a project that finished late, because all the planned work is eventually earned; Walter Lipke's earned schedule fixes this by measuring schedule in time. And EVM measures cost and schedule, not whether the thing is worth having, so it fits agile, discovery-style work poorly.

Change control, scope creep and the watermelon

The Sydney Opera House shows what happens when scope and design are not settled. Jørn Utzon won the competition in 1957; the early estimate was about A$7 million and the target for completion was January 1963. Construction started in 1959, before the geometry of the sail roofs had been solved. Utzon left the project in February 1966, and the building opened on 20 October 1973, at a cost of about A$102 million. It is now one of the most loved buildings in the world, which is a useful reminder: success and cost overrun can both be true, and a project can be called a failure on one measure and a triumph on another.

Scope creep is the slow growth of what is asked for without a matching change in money or time: each request is small and reasonable. The defence is a change control process, which can be light: any change is written down with its effect on cost, schedule and risk, then approved or refused by named people (a change control board on large projects, a product owner on a small one). The point is not to say no. It is to make the trade visible, so that "yes, and here is what moves" is the normal answer.

The status report is the other control. A watermelon report is green outside and red inside: the summary says on track while the detail, if anyone read it, says otherwise. It happens because green keeps the sponsor calm and the person reporting safe, so the cure is cultural as much as technical: report numbers (CPI, SPI, days of float, the top three risks and their triggers), define colours by rule (for example red when SPI is below 0.9), and reward early bad news.

Pre-mortems and the outside view

The best risk register is written before the project is attached to anyone's pride. Gary Klein described the pre-mortem in the Harvard Business Review in September 2007. At the kickoff, the team is told: "Imagine that it is a year from now and the project has failed spectacularly. Take two minutes to write down every reason you can think of." Klein's argument, based on research on "prospective hindsight", is that imagining the failure as a fact makes it easier for people, including the sceptics who would otherwise stay quiet, to say what worries them. Pair it with the outside view (36/90): before you trust your own estimate, look at how similar projects actually went.

Template: a risk register

Write each risk as cause, event and effect, give it a probability and a cost or delay in real units, pick a response, and name one owner and a trigger. Nothing is stored; copy the text out when you are done.

What a graduate just sees

• A risk is a possible event with a cause and an effect; an issue has already happened.
• A matrix colours risks, but a rare disaster and a frequent nuisance can share a score; put real ranges on the big ones.
• Plans built from most-likely values are optimistic: tails push the real finish later, and merging paths add more.
• P80 is the date you can promise; the gap between P50 or the plan and P80 is what contingency is for.
• Earned value puts work, cost and time on one scale: CPI and SPI below 1 are early warnings, TCPI says how heroic the recovery must be.
• Scope grows by small reasonable requests; change control makes each trade visible.
• A green summary above red details is a watermelon; define colours by rule.
• Imagine the failure first, then look at similar projects before you trust the plan.

Where it shows up next

• Leading Projects (36/94): the hard part of risk is telling sponsors and teams what you see, and a safe place to say it.
• Construction Management (34/70): contingency, change orders and cost control are the daily language of the site and the contract.
• Agile, Scrum & Kanban (36/92): burnup charts and forecast ranges are the iterative cousins of earned value.
• Operations Management (34/52): variability and queues are where schedule risk comes from.
• In the world: a stadium roof, a hospital IT roll-out, a satellite launch date, a government benefits system, a wedding.

If you want to go deeper

• 📘 Textbooks. Harold Kerzner, Project Management: A Systems Approach to Planning, Scheduling, and Controlling (Wiley, 13th edition, 2022); and Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide) with the Standard for Risk Management in Portfolios, Programs, and Projects.
• 📘 Gentler. Bent Flyvbjerg and Dan Gardner, How Big Things Get Done (Currency, 2023), about why big projects fail and how a few succeed; and Douglas Hubbard, The Failure of Risk Management (Wiley, 2nd edition, 2020).
• 🌐 Free course. MIT OpenCourseWare 1.040, Project Management (Spring 2009).
• 🌐 Reference. The US Government Accountability Office, Cost Estimating and Assessment Guide (GAO-20-195G, March 2020), which covers estimating, risk analysis and earned value.