From problem to practical solution.
Six stages. Not every engagement runs all of them — an assessment stops after the third, and a small automation might compress the first two into a week — but they always happen in this order.
The short version
- UnderstandWe learn how the business works today.
- ShapeWe define what should change and what the right solution looks like.
- BuildWe develop, integrate, automate and implement.
- ImproveWe measure what changed and identify the next opportunity.
Six stages in delivery, four in the version worth remembering.
Understand
Discovery, stakeholders, current state, goals.
- Stakeholder map
- Current-state notes
- Goals and constraints
What comes out of it
- Who is affected, and who decides
- What the business is actually trying to achieve
- How the work runs today, observed rather than described
What it costs to skip
The solution solves the problem that was described in the first meeting, which is rarely the problem the business has.
Analyze
Process, root cause, requirements, constraints.
- Process map
- Pain-point register
- Requirements draft
What comes out of it
- The process mapped, with handoffs and waiting made visible
- Root cause separated from symptom
- Constraints that are real, and constraints that are habit
What it costs to skip
Money gets spent automating a step that should have been deleted.
Shape
Future state, solution options, priorities, roadmap.
- Future-state design
- Solution options
- Roadmap
- MVP definition
What comes out of it
- A future-state process the people who run it have agreed to
- Options — buy, build, integrate, automate — with honest trade-offs
- A scoped first release, and what deliberately waits
What it costs to skip
Scope is decided during the build, by whoever is closest to the keyboard.
Build
Development, integrations, automation, testing.
- Working software
- Test cases from the rules
- Technical documentation
What comes out of it
- The software, integration or automation itself
- Tested against the business rules that were written down
- Built to be maintained by someone who was not there
What it costs to skip
Something works on the day it ships and nobody can safely change it afterwards.
Launch
UAT, deployment, handover, adoption.
- UAT sign-off
- Deployment notes
- Handover documentation
What comes out of it
- The people who will use it have tried it before it goes live
- Deployed and verified in the real environment, not only locally
- A handover the team can actually work from
What it costs to skip
A correct system that nobody adopts, which is indistinguishable from a failed one.
Improve
Measure, learn and continue.
- Before-and-after measures
- Adoption notes
- Next-opportunity list
What comes out of it
- What changed, measured against what was captured at the start
- Friction found in real use rather than in a demo
- The next opportunity, and whether it is worth taking yet
What it costs to skip
Nobody ever finds out whether the project was worth doing, so the next one is argued from opinion.
Numbers get captured at the start, not invented at the end.
Numbers are captured at kickoff and again after delivery, because a result that was never baselined is an opinion. Where a figure does not exist, this site says what was delivered instead of estimating an outcome.
Captured at kickoff
- Processing time
- People involved
- Handoffs
- Errors and rework
- Volume
- Customer wait time
- Manual steps
- Systems involved
Captured after delivery
- Processing time
- Steps removed
- Handoffs removed
- Automation rate
- Error reduction
- Wait-time reduction
- Adoption
- Volume handled
Start at stage one.
Tell Us What's Not Working