Approach
Five stages on one path. Each closes on a leadership decision, not a deliverable — the work does not move on until it is taken. Depth and duration are agreed before the first stage.
Agree the commercial objective, the boundary of the operation in scope, and what a result would look like. Nothing is examined before that boundary is set.
Decision gateScope and objective signed off
Leadership inputSponsor and function heads confirm the boundary
You set the objective, confirm what is in and out of scope, and name the sponsor who will take the decisions.
Follow the work as it is actually run — not as it is documented. Establish where it waits, repeats, or changes hands without a defined trigger, and test the cause rather than the symptom.
Decision gateFindings accepted as the working basis
Leadership inputAccess to operating data and the people who run the work
Your team explains how the work is really done and gives access to the relevant operating data.
Design the future state against capacity that exists: the steps, the decision rights, the thresholds, and the measures that will show whether anything moved.
Decision gateDesign approved for mobilisation
Leadership inputDecision on trade-offs between cost, service and headcount
Your managers test whether the design is workable and where it conflicts with commitments already made.
Put the change into day-to-day work, not into a report: named owners, an agreed sequence with dependencies, and the first operating documents.
Decision gateOwners and dates committed
Leadership inputRelease of time from the people carrying the change
You assign owners, take the management decisions, and release the time the changes require.
Test whether the change held, resolve the friction it created, and hand the review routine to the management team so it runs without us.
Decision gateHandover accepted
Leadership inputA standing review slot in the management calendar
Your managers run the review routine and act on what it shows.
Management decisions, approvals and accountability for the operation stay with you throughout. We supply the analysis, the options and the structure; the decision at each gate is yours.
Common questions
Yes, and it is often the better starting point. A defined scope produces usable answers faster than a whole-operation review, and what is learned in one area usually transfers.
A clear statement of what you want to improve, access to the people who run the work, and whatever operating data you already keep. You do not need to prepare new analysis for us.
In writing, before work starts. We discuss the problem, propose what is in and out of scope, and confirm the objective, the access required and the outputs expected. If the scope changes during the engagement, that is agreed too.
Enough to understand how the work is really done: conversations with the people doing it, and time from the managers who will own the changes. The level depends on the scope and is agreed up front.
Outputs depend on the agreed engagement. They may include a process map, a prioritised list of issues, a cost view, an implementation roadmap, ownership and measures, or operating documents. The Services page explains what each is for.
Yes, where it is within the agreed scope. Support can range from handing over a roadmap your team runs, to working alongside your managers while changes are introduced. Decisions and accountability stay with you throughout.
Each agreed change has an owner, a measure and a review point. Reviews use your own reporting where possible, so the routine continues after the engagement ends.
We tell you. Whether they are added to the current scope, deferred, or handled separately is your decision, and any change to scope is agreed before work continues.
Both are possible, and which applies is set by the engagement. We are not useful as advice alone if nothing changes afterwards, so we prefer scopes that carry through to a defined implementation point.
Information-sharing and confidentiality arrangements are agreed for each engagement before information is exchanged. We limit what we ask for to what the scope needs, and we do not publish client names or client data.
Framing is the first stage, and it begins with a description of the operation and the objective behind it.