How an engagement runs.
Four stages, in this order, every time. The first exists so that the other three are not spent building the wrong thing.
Diagnose
Before anything is designed, we need to see how the work actually moves — not how the process is supposed to work on paper.
- Understand how work currently moves between people and tools
- Find the bottlenecks where things wait on one person
- Identify the tasks being repeated by hand every week
- Discover where time is being lost without anyone noticing
Design
We decide what the system should do before we build any of it, and we write that decision down so you can disagree with it early.
- Decide what should be automated
- Decide what should remain a human judgement
- Design the right system before building it
- Agree the point where a person still signs off
Build
Implementation happens in the tools you already use. Nothing is rebuilt for the sake of it.
- Connect the tools already in use
- Implement the workflows agreed in the design
- Test against real scenarios, not sample data
- Hand over documentation of what runs where
Run & support
A system that nobody watches drifts. The last stage is about keeping it correct once real work is going through it.
- Launch the system on live work
- Monitor how it performs in the first weeks
- Improve what the first real cases turn up
- Maintain reliability and agree how it is looked after
Timelines depend on the process. Real dates are agreed once we have seen how the work moves.
Not sure which stage you are at?
Most engagements start with a diagnosis of one process. If you would rather see the thinking before you talk to anyone, the free blueprint is that first stage in written form.