Approach
APR.01Understand the system before changing it.
I start with how the business actually operates, not with a preferred tool. I map the process, make constraints visible and rank the opportunities before designing anything.
Three rules
APR.02Understand the system before changing it.
Every engagement starts with the people, decisions, tools and handoffs behind the visible problem.
Build the smallest intervention that matters.
Not a transformation programme. A useful change with a clear owner and a measurable effect.
Leave capability behind.
Documentation, transparent tools and a practical handover are part of the work.
The sequence
APR.03Map. Prioritise. Design. Build. Transfer. Five steps, in this order, each with an output you keep.
Map
01People, decisions, tools and handoffs.
Output
Current-state mapPrioritise
02Value, effort and risk, ranked.
Output
Opportunity registerDesign
03The smallest intervention, specified.
Output
Prototype + specBuild
04Tools, automations and AI where they help.
Output
Working systemTransfer
05Documentation, owners, handover.
Output
Capability left behind
What you keep
APR.04No dependency by design.
When the answer includes software, automation or AI, I define it, prototype it and help deliver it. Then I hand it over.
- Documentation
- How the system works, who owns it and how to change it.
- Your tools
- Transparent tools you already use or can run without me.
- Your repositories
- Code and automations live in accounts you own from day one.
- Handover
- A named owner on your side and a practical session to transfer the work.