Operating model transformation
Data and people existed; the process and the cockpit did not
A delivery assurance function owned everything and controlled nothing. I diagnosed nineteen gaps, designed the target operating model, and put stop conditions in the roadmap so it could not become another initiative nobody uses.
- Traced individually to a target capability, a quarter and a platform module
- 19 gapsTraced individually to a target capability, a quarter and a platform module
- With acceptance criteria — a specification a developer can build from
- 67 requirementsWith acceptance criteria — a specification a developer can build from
- One per quarter: if adoption fails, stop adding features and fix the cause
- 4 stop conditionsOne per quarter: if adoption fails, stop adding features and fix the cause
The client
The delivery assurance function of an enterprise software vendor, responsible for the quality of both its own and its partners' implementation projects. The role existed, with a channel and a fortnightly meeting, and no formalised operating model behind it.
The engagement
A four-layer transformation package — diagnostic, target operating model, twelve-month roadmap and a platform specification — delivered with an authenticated site so leadership and incoming staff each saw only their half.
The problem
The function owned delivery quality, project rescue, partner support, governance, advisory, billing input, project health and closure — everything at once — with no operating model, no accountability matrix, no lifecycle, no metrics and no portfolio view. Project status could be changed by anyone with no criteria or audit trail. Documentation had no single source, so onboarding a new lead meant archaeology across channels. The diagnosis compressed to one line: the data and the people exist; the process and the cockpit do not.
What I did
I refused to start with the tool, because a configuration exercise on top of undefined process just produces a more expensive version of the same confusion. So the sequence was diagnosis, then operating model, then roadmap, then platform specification — each layer traceable to the one above it, with a nineteen-row matrix linking every diagnosed gap to a target capability, a delivery quarter, a platform module and a stated outcome. The target model draws the accountability lines that were actually causing the pain: project health belongs to the assurance lead, the commercial promise to the customer belongs to the account role, a formal hold belongs to leadership with an executive approver. Governance was made portfolio-aware rather than purely methodological, so revenue-at-risk sits alongside schedule variance. And the roadmap was written as product development rather than as a process initiative: quarterly adoption gates with explicit stop conditions, a ban on building a parallel shadow system in spreadsheets, and a list of the things not to automate early — billing generation before the rules are agreed, client-facing AI output before a human review process exists, performance indices where no baseline plan exists at all.
What was built
A diagnostic naming nineteen gaps and ten reusable failure patterns; a target model covering roles and accountability, multi-dimensional project classification, a five-stage lifecycle with gates, a multi-dimensional health model, risk escalation, billing governance and resource visibility; a four-quarter roadmap of eleven modules with monthly work packages; and a platform specification with sixty-seven requirements and acceptance criteria so the model could actually live in the tool rather than in spreadsheets.
On the table at the end
- As-is diagnostic: nineteen gaps, ten failure patterns, accountability matrix
- Target operating model: fourteen capabilities, accountability splits, lifecycle and gates
- Twelve-month roadmap: eleven modules, four quarterly milestones, twelve monthly work packages
- Platform specification: sixty-seven requirements with acceptance criteria and a developer backlog
- Handover packs per client engagement plus generic packs by engagement type
- Authenticated command-centre site with role-separated views
What it changed
Converted an informal assurance role into a designed function with a quarter-by-quarter roadmap, measurable adoption targets, and explicit stop conditions — so leadership could tell the difference between a governance system being adopted and a governance system being performed.
How it ran
- 01
Diagnose before designing
Nineteen gaps by severity and ten reusable failure patterns — role without operating model, data without governance, status without health, communication without follow-through.
- 02
Draw the accountability lines
Health to assurance, commercial promise to the account role, formal hold to leadership with an executive approver — the ambiguities that were causing the escalations.
- 03
Design the lifecycle and the health model
Five stages with gates and mandatory artefacts, and health as a multi-dimensional rating covering schedule, scope, billing, risk and data quality rather than one colour.
- 04
Roadmap as product development
Eleven modules, four quarters, monthly work packages, a detailed first thirty days, and metrics with quarterly targets rather than aspirations.
- 05
Build in the stop conditions
Each quarter carries a question that halts feature work if the answer is no — can one real portfolio review be run from this, do teams use the lifecycle, does leadership trust the dashboard enough to escalate on it.
Other work
All case studies →- Professional services
A project office that lives in a git repository
Project knowledge lived in people's heads and chat threads, and AI tools were producing confident documents with no provenance. I made the repository the single source of truth and gave every project management role a written protocol.
- Portfolio management
Earned value that survives an empty project
Portfolio dashboards go green because the data model rewards going green. I built one that measures in hours, sorts by trouble, and refuses to report a number it does not have.
- Payments
A red project where the client had no single voice
A payments build was slipping on every axis at once. The root cause was not the team — it was that meetings with the client were being spent discovering the client's own requirements.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.