Services · Governance
We design governance as a decision system, not compliance theatre, for the program and for the business it leaves behind, so ownership is clear and trade-offs happen before delay becomes cost.
Steering committees review status but rarely resolve trade-offs.
Delivery teams wait on decisions that have no clear owner.
The system is live, and nobody can say who decides a configuration change.
AI pilots are running with no owner, no baseline and no way to switch them off.
We design and run the decision system: who decides what, at what threshold, on what evidence, and by when. Then we design the operating model that keeps those decisions running once the system is live and the program has gone.
We build it on the floor as much as in the boardroom, talking with people at every level. We have the hard conversations, and help leaders make the hard calls, so the program can deliver.
What you get
Governance is not a calendar of meetings or a set of templates. It is a decision system, designed so that a decision lands with someone able to make it, at the moment it still has options.
One accountable owner per material decision, with the boundary written down, so a contained change and a boundary change are told apart.
Contained changes stay local. Anything that crosses a boundary is decided jointly, by design, with a record of who decided and why.
A live record of what is open, who owns it, and the date it has to be made by.
An unmade decision shows its owner and its cost of delay, so waiting is visible rather than comfortable.
Tolerances for cost, time, scope and risk, agreed with the executive before they are needed.
Executives see risk early enough to still have options.
A shared rule for ranking competing work, so trade-offs are made openly and not by whoever escalates loudest.
Two initiatives want the same team. The ranking, and who decided it, is on the record.
A group sized to decide, meeting at a rhythm matched to the work, with attendance by agenda item.
Steering receives the decisions that are needed, each with options and a recommendation.
Where AI recommends, where it acts, and where a human signs, with escalation thresholds for agent behaviour and spend.
An agent acts inside a boundary someone wrote down, and the signature stays human.
The operating model
Every live system has an operating model, designed or not. We design yours with the people who will hold the seats, and write it on one page the team can run.
Who actually decides today, and where the vendor's defaults and the people at the desks are supplying the answers.
The gaps are named before anything is designed, and nothing is redesigned that already works.
The whole model as one artefact: named seats, what each decides, where decisions rise, and what holds it up.
Every decision has a named holder, and the whole thing fits on one page the team can run.
Triage tiers, resolution times, and what happens when an owner leaves.
Requests have an agreed response, and nothing an owner held is orphaned.
Each seat sized honestly against the work it already sits on top of: nominee, effort, and the support it needs. An agent is a seat too, with an owner and a support tier.
Every seat has a name, and the capacity conversation has already happened.
What changes for whom, in what order, with the ADKAR work behind each change.
People are running the new model, not just reading it.
The value record
Value is not a benefits case written to secure funding. It is a set of measures kept current from before go-live to well after it, so the organisation can say what changed and decide what to do next.
What the investment is meant to change, linked to the decisions and capabilities that cause it, with one owner per benefit.
A faster month-end is owned by finance, and tied to the changes that make it possible.
Each measure captured before go-live, from the system of record rather than a slide.
You can say what the last program actually changed, with evidence.
A scheduled check after go-live, tied to the decision it informs: defend, extend or stop.
Grounds to defend, extend, or stop the next investment.
Every AI use case with a baseline, a number it must move, and the condition under which it is switched off.
A pilot that does not move its number is stopped, not renewed by default.
A forum that reports, and a forum that resolves
Seen in practice
Case studies
A £1B business on a single integration platform, kept stable through cutover and hypercare.
Round-the-clock cover for an integration platform, with a six-person team, a restructured knowledge base and release readiness.
Clearer epics and stories, and sprint planning and retrospectives rebuilt, so decisions held between ceremonies.
Support, documentation and code moved from three disconnected systems onto one Atlassian backbone.
Business Central delivered with a warehouse specialist brought in, so the system and the way people worked changed together.
A support needs analysis and an L2–L3 transition, with no downtime on a complex NAV and PrintVis estate.
A service support model for a workspace operator, with the server infrastructure designed to stand it on.
A £40K-a-year ITSM tool replaced with SysAid on an ITIL operating model, for about $4,000 a year to run.
An eight-week read of an IFS estate across three countries, before the upgrade was designed.
Guides and thinking
Field guide · No. 02
The postures, artefacts and governance discipline that separate a programme that ships from one that compounds.
Field guide · No. 03
For leaders running an ERP programme where the platform decision is made and the operating-model work is not.
Field note · 4 min
The wrong decision costs you a quarter. Indecision compounds.
Field note · 3 min
A programme cannot skip the operating model. It can only skip designing it.
Field guide extract · 5 min
Four things that make a programme look successful while the value leaks out the back.
Related services
The estate of systems the operating model has to run on, and the foundations AI depends on.
Go/no-go decisions made on evidence at each gate, and senior leadership to chair the forums.
Sponsors and steering members coached to run the decision system themselves.
If you are planning a system migration, portfolio reset, or complex multi-vendor delivery, we can help you make the trade-offs, establish the governance, and build a way of working your team can sustain.