The Limits of Today’s Risk Practices

Most organizations now do SOME things right with risk:

• They collect project data (even if the type and quality vary by industry).

• They no longer rely only on averages, but they acknowledge variability instead of pretending an “expected value” tells the whole story.

• They follow a recognizable risk process—identify, analyze, respond (buffer, transfer, control, or accept), and monitor.

But there are three big problems Ivan sees in practice.

Big Problems In Practice

(1) Superficial Risk Identification

Many teams spend days in workshops generating long lists of risks, often recycling old registers. Without a clear map of the work to be done, the results are shallow.

This is like asking someone who has never baked to brainstorm “everything that can go wrong” when making a cake.

But, if you give them a process map of the baking steps,  they can suddenly identify risks intelligently.

The same is true for projects: if we don’t start from how the work will actually be done, our risk register misses crucial points.

(2) Contingency as a Blunt Percentage

In many capital projects, contingency is set as an arbitrary percentage of baseline cost—5%, 10%, or whatever feels “safe.”

This ignores actual variability. That percentage might be far too low or unnecessarily high. Worse, contingency is often treated as a pot of money that will be spent regardless.

If a team finishes one work item under budget, they slow down or overspend elsewhere to “use up” the funds.

Data even show negative correlations between related work items when this happens—evidence that people are managing to the budget, not the real need.

(3) Ignoring Correlations and Low-probability, High-impact Risks

Many contingency models assume work packages are independent, even though in reality outcomes are often correlated. Properly accounting for correlation can double or triple contingency requirements.

At the same time, organizations sometimes price in low-probability, high-impact events (like a rare hurricane) into base budgets.

If the event doesn’t happen, money is wasted, and if it does, no reasonable contingency truly covers it.

The Real Engine of Projects: Production Systems

Ivan argues that we focus too much on project administration (reports, cost tracking, compliance) and too little on how project work is produced.

Every project can be seen as a production system made of interconnected chains:

• Design and engineering

• Procurement and supply

• Fabrication and prefabrication

• Installation and integration

• Testing and commissioning

These chains turn inputs into outputs.

Drawings into designs -> Materials into modules ->  Modules into finished assets.

They rely on resources and are governed by how those resources are organized, scheduled, and fed with work.

Key elements of this production view include:

• Capacity: What the system can deliver over time, not just how many resources you have on paper.

• Inventory/Work in Process (WIP): Work that has started but isn’t finished—partially installed systems, piles of pipe spools waiting for a valve, “almost done” work.

• Throughput: The rate at which finished work comes out of the system.

• Cycle time: How long it takes items to flow from start to finish.

• Variability: Differences in task durations, throughput, and cycle times—often invisible but highly impactful.

Operations science, built on laws like Little’s Law, shows how these pieces interact.

For example, as resource utilization approaches 100%, cycle time explodes. This adds more load to an already busy system dramatically increases delays. High WIP and variability combine to slow throughput and amplify rework risk.

Why Variability and WIP Are Hidden Risks

Most project controls focus on scope, schedule, and cost. We sometimes refer to this as the traditional “iron triangle.” But when you look at real project performance data, many efforts are simultaneously late and over budget.

Trade-offs are not working as theory might suggest.

From a production perspective:

• High WIP is visible risk. Every partially completed work item is a potential rework candidate and a source of delay when changes or defects are discovered.

• High variability in task performance erodes effective capacity. A line that looks capable of a certain throughput on paper can deliver half that once variability is considered.

• Pushing teams to high utilization without buffers may feel efficient but actually slows cycle time and increases the probability that rework will impact critical dates.

Project behaviors often make this worse. To show progress and hit earned value targets, teams open more work fronts, even when preceding tasks aren’t truly ready.

That creates large WIP, more coordination complexity, and longer feedback loops. This is exactly the conditions that magnify risk.

From Schedules to Production Maps

Traditional methods like CPM and PERT are still useful, but Ivan sees them as describing desired timing, not the underlying engine.

Schedules describe what should happen while production maps describe how things actually happen.

Next-generation Risk Management starts with:

• Mapping key production chains (design, fabrication, installation) at the right level of detail.

• Understanding how work packages flow through servers (crews, workstations, approval steps) with specific variability.

• Identifying bottlenecks, typical WIP levels, and realistic throughput.

With that foundation, risk identification becomes more concrete.

With this, you can see:

• Where rework will hurt cycle time the most.

• Where too much WIP will cause delays and mistakes.

• Where additional capacity would actually improve throughput (versus where extra resources simply add coordination overhead).

Using Analytics for Smarter Contingencies

Production analytics and data-driven models let you simulate how variability and WIP affect cost and time.

Instead of blanket percentages, you can:

• Estimate contingency based on the variability of standard work processes and realistic correlations between them.

• Focus contingency on incremental, manageable risks—those that fluctuate around the baseline—rather than trying to absorb rare catastrophic events.

• See how contingency needs change over time as real data arrive (for example, as bottleneck performance stabilizes or deteriorates).

In this view, cycle time becomes as important to risk as throughput.

Faster throughput with uncontrolled WIP and rework can make risks worse, not better.

Good risk management is about stabilizing the engine, not just pushing it harder.

What Next-Gen Risk Management Looks Like

Ivan’s “next generation” project risk management isn’t a new buzzword. We see it as a shift from treating risk management as a checklist exercise to treating it as a production science problem.

It means:

• Starting with a clear picture of how work is produced, not just what tasks are on the schedule.

• Using operations science and analytics to understand variability, WIP, capacity, and cycle time.

• Designing contingencies and mitigations that target the true drivers of variability, instead of arbitrary percentages.

• Recognizing that many chronic project failures in capital projects mirror those in government work, despite stable scope and clear business objectives.

If you want to improve project outcomes, Ivan suggests moving beyond risk registers and high-level dashboards.

The real leverage lies in understanding and shaping the production system that turns ideas and drawings into delivered assets.