Method
The same route on every project, whatever its size. It runs from diagnosis through design, and continues into implementation, manager training and support through the first weeks of real use.
01
Diagnose
02
Benchmark and principles
03
Design
04
Validate
05
Implement
06
Support
01
Understand the problem before proposing anything.
We collect the documentation, talk to the people involved and work out what is actually happening. Most projects change shape at this stage, and it is cheaper to change them here.
Output
A shared view of the problem and the priorities.
02
Agree the structural decisions before drafting anything.
What comparable companies do, and the small number of principles the system has to satisfy. These are the decisions that are expensive to reverse later, so they are made explicitly and early.
Output
The principles, agreed in writing.
03
Build the policy, framework or system itself.
The first full version, sized to the company you are rather than to a reference model from a much larger one. Every element has to earn its place by being used.
Output
A structured draft of the deliverables.
04
Test the decisions with leadership and get approval.
A review round with the people who have to live with the result, plus legal or financial review where the project needs it. Trade-offs are adjusted here, not after launch.
Output
An approved version.
05
Prepare the organisation to actually use it.
Templates, rules, communication and training. The company gets everything it needs to launch, and the managers who will run it are trained on real cases.
Output
Everything needed to launch it, ready to go.
06
Stay with it through the first weeks of real use.
A defined period of support after launch, then a check-in once the system has been used for real. Almost every framework needs one round of correction, and it is better done with us than without.
Output
A system in use, with a named internal owner.
Implementation
Every project includes turning the framework into documents and tools people can use, training the managers who will run it, and checking that it is being used. That is in the scope from the start, so the project ends with the system in use rather than described.
Principles
01
There are always two or three things that, done first, make everything after them simpler. In the wrong order, some of the work has to be done twice.
02
If a process only works when someone has a free afternoon, it will not work. Everything we build has to fit into a normal week.
03
If a competency cannot be seen in everyday work, it cannot be assessed either — and a rating that comes out of it will not hold up in the conversation that follows.
04
A framework copied from a much larger company brings more process and less clarity. What we design is sized to the organisation in front of us.
05
Every project ends with someone inside the company responsible for it, the documentation written, and a date set to review it.
06
The first weeks of real use show things no design can anticipate. We stay through that phase, correct what needs correcting, and help the team become self-sufficient.
The diagnostic runs the first two steps and produces the roadmap for the rest.