How Heidelberg Materials built integrated cost and schedule risk analysis on Europe’s first full-scale carbon capture plant
At Brevik, on Norway’s south coast, a 100-year-old cement factory is capturing roughly half of its own CO₂ emissions – about 400,000 tonnes a year – while continuing to run at full production. It is the first full-scale carbon capture plant in the cement industry, built as part of Norway’s Longship programme. And it is exactly the type of first-of-a-kind, high-scrutiny project where a single missed estimate is expensive and a single missed deadline is public. Heidelberg Materials and their delivery partner Metier needed more than a schedule and a budget. They needed a way to know, at any point, how confident they could actually be in either one.
Peter Moberg, Project Control Manager at Metier, spent four and a half years building that capability from the ground up – first in Safran Project, then in Safran Risk. What follows is the story of how a team with no shared tools, processes, or history got to a fully integrated cost and schedule risk analysis (ISCRA), told through the choices that made it work and the ones that took longest to get right.
Starting From Nothing
“When we came in, we had nothing,” Moberg says of the project’s early days. No shared procedures, no common tools, a team that had never worked together. The project’s grant support agreement with the Norwegian state set the baseline requirement: risk analysis of schedule and cost had to be performed twice a year and had to identify the most important risks and opportunities for the remaining work.
As the project matured, the Ministry of Energy asked for more: a fully integrated schedule and cost risk analysis, not two separate exercises. That single requirement changed the shape of the project. It meant a new procedure, more experienced risk managers and analysts on the team, and the acquisition of a tool that hadn’t originally been part of the plan – Safran Risk. Before any of that could produce a usable risk model, though, the team had to build something more basic: one schedule everyone could actually work from.
One Schedule, Many Contractors
Brevik was never going to run on a single planning system. The main EPC contractor and the parallel contractors working alongside them each planned in their own tools and formats. They used Microsoft Project, XML exports, Safran-native files from one Aker-linked contractor, and, for some of the smaller civil contractors, spreadsheets. None of that made for a coherent picture of who was doing what, where, and when.
Moberg’s team solved it by building what they called the Integrated Detail Schedule (IDS) inside Safran Project: one entity combining the owner’s schedule with every contractor’s data. Making that possible required a set of shared reference fields – WBS, contract, phase, area, sub-area, discipline, procurement package, and later a system and commissioning package as the project matured from area-based construction to system-based commissioning – all governed by documented procedures rather than a requirement that everyone work in one shared workspace. Out of that single schedule came a weekly reporting rhythm: activity and milestone reports, area-based and commissioning schedules, a filtered critical path, delay reports ranked by deviation so responsible teams could see who was driving delay, look-aheads, progress S-curves, and, for anyone who preferred it, the entire schedule exported straight to Excel.
The Configuration Choices That Mattered Most
Two decisions, in Moberg’s telling, did more than anything else to make the eventual risk analysis possible.
The first was including cost directly in Safran Project, not just hours or quantities. It let the team produce cost histograms and periodic cost plans by WBS for corporate finance, and it changed how much attention the project got from management. On a project running into the billions, knowing how much funding is needed in the coming periods matters to the state and to Heidelberg Materials alike. Contingency itself stayed outside the resource-loaded scope and was added through the change register during baseline revisions, so it never distorted what was being earned against.
The second was modelling cost as a quantity resource rather than a cost resource. This was a workaround for the fact that Safran Project’s bar chart editor doesn’t roll cost progress up to group level. For procurement costs and services with no natural hour count behind them, the team created a resource with a quantity of one and a cost rate of a thousand, purely to give those cost items an earned-value basis similar to an hour. “It’s not totally accurate,” Moberg says, “but it’s better than excluding all of that cost.”
Underpinning both was a third, quieter decision: aligning the cost breakdown structure with the WBS at the top levels, so the two used the same codes down to a certain depth. Each activity carried a CBS code that was one-to-one with the WBS and one-to-many with schedule activities, mirrored in the ERP system – what Moberg calls “the thin red line between cost management and schedule management,” letting data move between the two on a one-to-one basis. The payoff showed up gradually: the monthly cost overview and histogram reports, drillable to any level of the WBS, went from wide deviations between planned, earned, and actual cost in the project’s early years to deviations the team could explain – and eventually close to zero – as the model matured.
From Schedule to Risk Model
Getting from a detailed schedule to a usable risk model took its own set of decisions. With several thousand activities in the Integrated Detail Schedule, most of them irrelevant to a forward-looking risk analysis, Moberg used a flag field he called “exclude from SRA” to filter out completed, cancelled, and otherwise immaterial activities. It was easier, he found, than trying to hand-pick which activities belonged in the model. What remained exported cleanly from Safran Project into Safran Risk, with the one recurring friction point being activity-level estimate uncertainty.
Qualitative risk, by contrast, lived in a separate register – RAM Risk, chosen through a public procurement process on functionality and price, and one Moberg describes as “a good competitor” to Safran Risk Manager. Because it wasn’t natively connected to Safran Risk, translating each risk’s probability and consequence into the single values a quantitative model needs was manual and time-consuming.
To connect schedule delay to cost impact without resource-loading every single activity, the team used hammocks – tied to milestones, with a daily burn rate covering both direct and indirect cost, so that when a milestone slipped, the cost exposure moved with it automatically. On top of that base, they added estimate and event uncertainty on both cost and duration, run through six or seven baseline revisions, each following the same pattern: a kickoff with the full project management team, smaller working sessions to update the model, and a structured walkthrough of the results at the end.
The team ran this analysis not just for overall project completion but for every major milestone, at P50 and P85 confidence levels – the two figures that ultimately determined how contingency was distributed. The band between P50 and P85 became the steering committee’s contingency to hold; everything up to P50 was divided, somewhat subjectively, among project managers and sub-project managers, taking into account how complete and how mature each part of the work already was.
The Real Requirements of the Journey
None of this arrived quickly. From the project’s first baseline to a fully integrated schedule and cost risk analysis took around a year and a half of the team maturing together – longer, Moberg hopes, than most organisations will need once the pattern exists to follow. Along the way, the project passed three external audits of its risk process with no findings.
The results were visible in the data itself: probability-per-baseline graphs showing cost and schedule confidence rising over successive revisions, as the team resolved open questions and locked down more of the plan. The team never got as far as using a joint cost-and-schedule confidence level, but leaned heavily on critical-path analysis throughout. Eventually, in April 2024, the project reached a point where management judged further uncertainty analysis unnecessary and moved to managing the contingency it already had – a milestone Moberg treats as an important, if unglamorous, part of the story.
He is candid about what made the process hard. Getting a shared vocabulary for uncertainty across a team that hadn’t worked together before took real effort. Translating a qualitative risk register entry – a risk described as “15–35% likely” or “a month to three months’ delay” – into the single figures a quantitative model needs is a genuinely difficult step, not a mechanical one. Getting reliable risk input from contractors is hard whether or not it’s written into their contract: hard to get without it, and hard to use well even with it, because the capability to work systematically with uncertainty often isn’t there yet. And risk correlation – the fact that one event can hit cost and schedule in several places at once – is genuinely complicated to model; the team’s answer was to interconnect the schedule activities driving both, so a single risk event moved every output it should. Woven through all of it was a simpler truth Moberg states plainly: teams are, more often than not, too optimistic about their own cost and schedule estimates.
A Plant That Delivers, and a Process to Match
For all the complexity behind the scenes, the plant works: the captured CO₂ comes out at almost food-grade purity, hitting a specification that was, in Moberg’s words, one of the most critical uncertainties in the entire project.
“The risk management process is more important than the result itself,” Moberg concludes – not because the numbers don’t matter, but because of everything a team has to get right about its schedule, its cost model, and its own habits of optimism before those numbers can be trusted. Like we at Safran often experience, the path from nothing to a fully integrated analysis is one many project teams are already on, at very different stages.
If your team is earlier on that same path – still reconciling contractor schedules, still deciding how to fold cost into the plan, or ready to move from a qualitative risk register to a defensible quantitative model – Safran’s project controls and risk specialists are happy to talk through what that next step looks like for your project.
Want to see more?
The project team joined Safran for a webinar where they went into more details on the topic. Access the recording of the webinar here
Facing similar challenges?
Meet us at Project Days in Helsinki. Reach out to our partner team in Finland – Proha – to talk through where your project is on this journey.
