At a glance
Data centres
Countries
Projects annually
In production
Individual project values
Annual identified capital requirement
Scale and duration only. The four reported productivity, sourcing, fiscal-control and return figures are not shown here; they sit in the evidence section with their status, because the methodology they reference is not held anywhere in the project.
01
The operating context
A large global enterprise owner-operator manages a geographically distributed mission-critical estate — around forty data centres across more than thirty countries. It runs roughly three thousand projects a year against that estate, with individual values ranging from about ten thousand dollars to five million.
The defining constraint is not delivery capacity. It is that the organisation identifies substantially more capital demand than it has investment capacity to fund: a hundred and fifty to three hundred million dollars of identified annual requirement against a smaller budget.
02
The challenge
When demand exceeds capacity, two things become critical at once. Prioritisation has to be good, because choosing the wrong projects is expensive in a way that cannot be recovered later. And programme discipline has to be good, because value lost inside approved projects is capital that was allocated and then did not arrive as outcome.
The second is the harder one to see. Value leaks at the joins in the scope-to-close-out chain, and each leak looks small on its own.
- Work ordered late, or not ordered at all
- Change made but not recorded
- Scope that moves without anyone deciding that it should
- Reconciliation left incomplete
- What was delivered not matching what the purchase order said
- Issues discovered at project close, when the options for addressing them have largely gone
Across three thousand projects a year, small and unrecorded becomes material and invisible.
03
Why the existing model was not enough
A programme assembled from separate systems is reported on retrospectively. Someone pulls the pipeline from one place, approvals from another, purchase orders from finance, delivery status from project managers and commercial position from a spreadsheet, and reconciles them into a picture of where the programme stands.
That picture is always slightly historical and slightly wrong, because the reconciliation is a human act performed at intervals rather than a property of the record.
The defects hide in the gaps the reporting looks across. A missed order is missing from the ordering system; unrecorded change is absent from the change record. The reporting process reconciles between systems, which is precisely where these failures live.
Prioritisation suffers too. Deciding which projects to fund is easier with reliable evidence about how previous ones actually performed — and that evidence is the first casualty of retrospective assembly.
04
One governed chain, and the joins where value used to go
Project Delivery holds the whole sequence as controlled steps against a single project record, rather than as hand-offs between systems. The leakage points below attach to the joins, not to the stages — which is the point.
Projects a year passing through this chain
Countries the estate spans
The chain has been governed this way
05
What changed
Project Delivery was deployed as the governed environment for the whole chain: scope, approval, project controls, work packaging, sourcing, commercial management, delivery, change, financial governance, close-out and programme reporting.
The significant word is governed. Sourcing happens as structured e-sourcing rather than as inconsistent procurement. Change is recorded where the scope lives. Commercial position and delivery status describe the same project rather than two accounts of it.
01
Project Delivery (& Programme Management)
Operational project delivery on live estates — scope, approval, project controls, work packaging, sourcing, commercial management, delivery, change, financial governance and close-out — with programme reporting produced from the same record rather than assembled alongside it.
02
Capital Planning
The planning front end: continuous, AI-assisted planning from portfolio to board-approved plan.
Not deployed in this environment today. Investment prioritisation therefore sits outside the governed record, which is what the future direction below addresses.
06
The connected operating model
The programme is managed from the underlying project record rather than reconstructed retrospectively — one governed picture across pipeline, approvals, sourcing, delivery, commercial position, change and close-out.
That inverts the reporting relationship. Programme reporting stops being a periodic assembly exercise and becomes a read of the record. And because the record is continuous rather than assembled, the leakage points in the chain are places where something is visibly missing rather than places nobody was looking.
Before
The programme position is reconstructed
- Pipeline, approvals and purchase orders held separately
- Delivery status collected from project managers
- Commercial position maintained alongside the work
- Reporting is a periodic assembly exercise
- Failures sit in the gaps between the sources being reconciled
After
The programme position is read
- One project record from scope through close-out
- Sourcing as structured e-sourcing, governed in the chain
- Change recorded where the scope lives
- Programme reporting is an output of the record
- A missing step is visibly missing rather than unlooked-for
07
Outcomes and evidence
Four tiers, in descending evidential strength. This deployment carries the most quantitative figures of the three, and the weakest methodology behind them. Both facts are stated here rather than one of them being allowed to imply the other.
Deployment and operating facts supported by the source record.
- Four years in production as the governed environment for the programme.
- Approximately three thousand projects a year, across around forty data centres in more than thirty countries, with individual project values from about ten thousand to five million dollars.
- The full scope-to-close-out chain is governed in one place, including programme reporting — which is produced from the project record rather than assembled from separate sources.
Figures reported in the source record without an established measurement basis.
- Approximately twelve to seventeen per cent programme-management productivity. Standardised workflows, automation, reporting and project controls let managers handle greater volume without linear growth in overhead. Verify
- Approximately seven point six per cent average cost reduction across the measured competitively sourced project cohort, through structured e-sourcing rather than inconsistent procurement. Verify — cohort undefined
- Approximately one hundred and eighty-six thousand dollars a year of fiscal-control benefit — avoided programme leakage and reduced uncontrolled variance across the scope-to-close-out chain. Verify — methodology absent
- Approximately five point six times return on investment. Verify
Why none of these four is presented as validated proof. All four reference a case-study methodology, a measured cohort or a derivation that is not held anywhere in the project's evidence records. Without it, the productivity range has no baseline or definition, the sourcing cohort has no size, period or comparator, and the fiscal-control figure — the most precise-looking of the four — has no derivation at all. The Case Study Production Standard requires source, period, method, scope, status and owner for every published outcome, and proof doctrine is explicit that estimates presented without assumptions are not acceptable proof. These are reported here as reported, in the tier that says so, and none is drawn as a graphic.
Qualitative observation about the operating model.
- The programme position is read rather than reassembled. One governed picture across pipeline, approvals, sourcing, delivery, commercial position, change and close-out. This is the operating change the deployment was made for, and it is observable without needing a percentage attached to it.
Where evidence does not exist, nothing is asserted in its place.
- No schedule or delivery-on-time outcome. None is recorded in the source.
- No prioritisation or investment-decision outcome. Capital Planning is not deployed here, so the case study makes no claim about how investment decisions are now made.
- No implementation duration or user count. Neither is recorded.
- No applied-AI outcome. The source records no AI or MIRI capability in this deployment, and none is implied — including in relation to Capital Planning, which is not deployed.
- No portfolio-wide return claim. Clarisync publishes a general expected-return range for its customers elsewhere. It is a claim about the customer base, not about this customer, and it is not used here.
08
What comes next
Extending the record upstream into Capital Planning. The phase under discussion would connect investment prioritisation directly to the evidence generated through operations and delivery — closing the loop between what the estate has actually needed and what gets funded next.
Capital Planning is not deployed in this environment today, and no commitment or timeline is recorded. This is a discussion, described as a discussion.
09
Customer perspective
Attribution status
No approved customer statement exists for this deployment. The customer operates under confidentiality and has not been asked for, or granted, permission to be quoted or identified.
A reference call with a peer operator can be arranged on request through the Proof Centre.
A programme you reconstruct is a programme you learn about late. This one is read.
10
Evidence, method and governance
Anonymity
This customer is anonymised. No name, brand, site name, location or country list appears anywhere in this asset, and none will be added without written permission. Named suppliers and the identity of the sourcing cohort are withheld.
No breakdown is published that would let the fiscal-control or sourcing figures be resolved to specific projects or suppliers.
Evidence basis
Scale and duration facts — site count, country reach, annual project volume, project value range, identified capital requirement, time in production — are supported directly by the internal source record for this deployment.
All four quantitative outcome claims carry verification flags, and the reason is the same in each case: the measurement basis they reference is not held in the project's evidence records. The productivity range has no stated baseline, definition or population. The sourcing cohort is referenced but never defined — no size, no period, no comparator. The fiscal-control figure and the return multiple both cite a case-study methodology that is not present in Project Foundry, in the Knowledge Core, or in the website production sources.
None of the four is drawn as a graphic. Charting a figure lends it apparent derivation, and these have none; the only quantitative graphic on the page draws the demand-versus-capacity relationship, with capacity deliberately hatched and unlabelled because the source states that it is smaller without stating by how much.
The general expected-return range Clarisync publishes for its customer base is a claim about the customer base, not about this customer, and is not used here.
Product and taxonomy notes
The third System of Work carries an unresolved naming conflict across approved sources — "Capital Planning & Delivery", "Capital Planning & Project Delivery" and "Capital Planning & (Project) Delivery" all appear. This page uses the canonical compromise form where a grouped reference is required, and preserves the conflict rather than resolving it. The two internal source artefacts for this case study differ on the same point: one labels the deployment "Capital Planning & Project Delivery", the later one "Project Delivery". The later, narrower label is the more accurate one here, because Capital Planning is not deployed.
The Programme Management boundary is also unresolved in approved sources: it is folded into Project Delivery in some and referenced at portfolio level under Capital Planning in others. This case study describes programme management performed within Project Delivery, consistent with the source, and does not resolve the boundary.
Project Delivery is scoped to operational project delivery on live estates, not general greenfield construction. This case study does not extend that scope.