The problem you fixed last year is back
Most fixes get made at the level of the team that felt the pain. The operating model, meaning who decides what, on what information, and who carries it when it goes wrong, is left as it was, so the problem re-forms around the fix. This practice works at that level instead.
Nobody designed it. It accumulated.
Every business has an operating model. Most have never written it down, which is not the same as not having one. It means the model is whatever has built up: decisions that sit with whoever has been there longest, handoffs that exist because two people once fell out, approval steps nobody can trace back to a policy.
That works, and then at a fairly predictable size it stops. Coordination that ran on relationships starts running on meetings, the meetings multiply, and the business responds by hiring, which lengthens the queue it was trying to shorten.
Redesigning the org chart is the most-reached-for answer and the least effective one. Boxes move. Decision rights do not.
Four kinds of work, all of them structural
Every one of these starts from how the business operates today, not from how the last strategy document said it should.
Target operating model
How the business is meant to run: structure, decision rights, handoffs, and the information each decision actually needs. Written down, so it can be argued with rather than assumed.
Decision rights and accountability
Who decides, who is consulted, and who owns the outcome when it goes wrong. Most coordination problems turn out to be decision-rights problems that nobody has named out loud.
Business cases and benefits realisation
The case for the change, and then the harder half: tracking what landed against what was promised, with the gap stated rather than quietly absorbed into the next forecast.
Change and adoption
The difference between a new operating model on paper and one people work inside. Adoption is where redesigns fail, and it fails quietly enough that the programme still reports green.
We do not start with the org chart
Reorganising is fast, visible and the easiest thing in this practice to sell. It is also the intervention most likely to leave the underlying problem intact while spending a year of goodwill finding that out.
We start from how decisions actually get made today, traced through real ones rather than described in a workshop, and we change the structure only where the structure is what is in the way. Sometimes it is. More often the fix is smaller, duller, and holds.
Trace a decision, not a process
Most engagements here open by following two or three real decisions end to end: who raised it, what information existed at the time, who had to agree, how long each step waited, and what happened after it was made.
It is faster and more honest than a process-mapping exercise, because it shows the model as operated rather than as described. The distance between those two is usually where the work is.
It also produces something a board can act on without approving a programme first, which is the point.
Seven areas, scored out of five. Answer for how things actually work rather than how they are meant to, see your rating on screen, and take the detailed PDF if you want it.
A second assessment goes one level down: Agile Delivery asks whether the way work actually flows matches the model on paper. Scoring well on one and badly on the other is the common case, and the gap is usually the finding.
Operating model decisions are rarely only that
A decision right is only real if something enforces it: a system, a contract, or a person with the standing to say no.
Who leads this work
Where this work turns into a named person carrying it at board level, week to week.
See the leadershipProblem before platform
Why programmes fail on sequencing rather than technology: the same discipline, applied one level up.
Read the articleHow the six reconcile
What each discipline covers, and what happens when two of them disagree about the same recommendation.
See the approachStart with the decision that keeps stalling
Name the one that queues, and we can usually tell you within a conversation whether it is a structure problem or something smaller.