Same maths. Four frameworks where there was one. A reporting cadence that finally fits inside the period it's meant to report on.
Anonymised composite. This case study is a representative composite drawn from real Risk Studio engagements on a major UK infrastructure delivery programme. Specific scheme names, dates and individuals have been removed pending client publication permission. The workflow, frameworks, deliverables and outcomes described below are exactly those Risk Studio runs in production today.
The scheme is a major-junction upgrade on UK road infrastructure, carried over between investment cycles on the client's delivery programme. Around 3,200 schedule activities in the working baseline, a risk register that has crossed 180 live entries at its peak, and a reporting cadence pinned to the client's quarterly period board. Three frameworks were named in the assurance plan — DCMA 14-Point as the procurement floor, CIOB PP21 because the client's planning manager had moved across from the rail side, and a draft "QSRA readiness" check the assurance team had been developing in spreadsheets.
The delivery team sat across two consultancies and the client's own risk function. Five people touched the QSRA each period: a Planner, a Risk Manager, a Risk Analysis Manager, the RAM's reviewer, and a Regional Risk Manager who saw the outputs at the portfolio level. None of them had a full day a week to give to it.
What the team was running before Risk Studio was the standard Safran round-trip. The Planner exported the XER on day one of the period. The Risk Manager rebuilt the risk register inputs in a working spreadsheet, copying three-point estimates from the live register into the format Safran wanted. The Risk Analyst loaded both into Safran, ran the model, exported five files per scheme, and pasted the percentile bands back into the client's Excel report template by hand.
DCMA was the only framework being checked. It was being checked in a spreadsheet a senior analyst had inherited from a previous engagement — passed around as an email attachment, last modified two years before, with three known bugs the team worked around manually. CIOB PP21 was on the assurance plan but had been dropped from period reports because there was no time to run it. The draft QSRA readiness checks never made it past pilot.
The cycle ran on a 28-day rhythm. Five days for inputs, ten for the Safran rounds and the report build, five for review and rework, and the rest waiting on sign-off. By the time the Regional Risk Manager opened the portfolio view, the schedule had already moved on. The team knew this. The client knew this. Nobody had a clean way to fix it without lifting the entire toolchain.
We didn't replace the toolchain in one step. The rollout ran in three.
Risk Studio installed on the RAM's laptop alongside Safran. One period run end-to-end, both ways, in parallel. Outputs compared row by row. The RAM kept Safran as the reference. Risk Studio earned the right to be looked at.
Next period, Risk Studio ran as the primary tool on the one scheme. Safran kept as a contingency. The four frameworks ran live for the first time. The team kept a running log of every disagreement between Safran's numbers and ours.
By period three, the running log of disagreements had closed out (the residual was a known rounding difference in Safran's correlation engine, well inside any decision-grade tolerance). The team retired the spreadsheets and the inherited DCMA workbook. The toolchain was Risk Studio plus the existing planning tools.
Total elapsed time from first install to embedded: 11 weeks. Three reporting periods. No re-baselining, no schedule freeze, no special licence procurement — the tool ran on the same MacBooks the team already had.
Numbers measured over the first three reporting periods after embedding. Period-one validator findings count is unusually high — it captures the backlog of issues the previous toolchain never surfaced.
Day one. The fresh XER lands in the scheme folder. The risk register is updated in the live grid — manual edits, paste-in, or the standard SOMA template depending on who's working. The validator fires automatically the moment the inputs are in. Within 90 seconds the analyst has 75 framework checks rendered against the schedule, each failure traced to a source row, activity ID or risk entry. The delta against last period is on screen. The morning is spent triaging the findings and pinning what matters into the Schedule Lens workshop view.
Day two. One-hour workshop with the Planner inside Schedule Lens. The pinned issues become the agenda. Most close out by lunch — a missing predecessor here, a forgotten constraint there, a risk that was mapped to an activity that's since been resequenced. The few that need a wider conversation are tagged for the period board.
Day three. Risk Manager works through the register against the updated schedule. Three-point estimates are refreshed. The Monte Carlo runs in-house — 10,000 iterations across the three models (deterministic-only, threats pre-mitigation, threats post-mitigation), tornados rendered for both activity and risk drivers, the mitigation delta plotted across the bands. P-values land on the same page as the previous period for direct comparison. The RAM signs off the run in the audit log.
Day four. The four deliverables generate on the same audit chain — the client's Excel report (populated with literal values, so SharePoint previews display correctly), the Weblink HTML dashboard for the client, the PDF for assurance, and the 12-slide PPTX briefing with auto-generated speaker notes addressed individually to the PM, Planner, Risk Manager, RAM and RRM. The Regional Risk Manager opens the portfolio movement view and sees this scheme's shift in context with the rest of the portfolio. Period closed.
Used to receive a list of failed DCMA checks as a PDF, three days after the export. Now opens Schedule Lens in the period-one workshop, clicks any flagged bar, sees the diagnostic trace and the predecessor and successor lists in the same view. Most logic issues close in the workshop, before the MC runs.
Used to copy three-point estimates into a Safran-format spreadsheet by hand each period. Now edits the live register grid in Risk Studio. The validator catches mismatched min-likely-max ordering, missing distributions and split-impact totals that don't reach 100% as they happen — not after the MC has run and produced a misshapen curve.
Used to defend the run with a folder full of working files and screenshots. Now signs off in the per-finding accept workflow, with the written reason stamped to the HMAC-chained audit log. When the assurance team asks why a check was accepted six months later, the answer is on screen in two clicks.
We used to spend the first week of every period rebuilding the Safran inputs. Now we open Risk Studio, drop the XER, and the four-framework findings are on screen in 90 seconds. That hour is what the analysts use to actually think about the schedule.— Risk Analysis Manager, UK infrastructure delivery team (composite voice)
Anonymised composite — yes. Reproducible workflow — also yes. The four-framework validation, the in-house Monte Carlo, the four deliverables on one audit chain are exactly what runs on the schemes this study is drawn from.
Reminder: this is an anonymised composite drawn from real engagements on a major UK infrastructure delivery programme. Named-client publication will follow once the client has reviewed and signed off the public version. If you'd like the long-form, attributed write-up under NDA, ask us on the call.
