In plain English: Map how work really happens, set a measurable goal, fix the most boring expensive thing first, ship small, and measure. Tech comes last, not first.
Somewhere right now, a company is launching its "digital transformation programme". There's a kick-off event, a new logo for the initiative and a 60-slide deck. Eighteen months later, the new system is live, the old spreadsheets are still in use, and everyone quietly agrees not to mention it again.
It happens all the time, and almost never because the technology failed. Projects fail for boring reasons: nobody agreed what success looks like, too much got started at once, or the shiny new tool was switched on and then politely ignored.
The fix is just as unglamorous: a handful of decisions, made in the right order. This is the six-step sequence we use with clients. It works for a 15-person firm and a 500-person one alike — only the size of each step changes.
Step 1: Face the truth about how work really happens
This is the step almost everyone skips. They jump straight to choosing software — and then automate a process nobody fully understood.
Before you look at a single tool, write down how the work actually gets done today. Not the org chart. Not the process manual from 2019. The real path an order, a quote or a new customer takes through your company.
For each core process, capture:
- Every hand-off. Who passes what to whom, and how — e-mail, spreadsheet, shouting across the office.
- Every re-typing. Each time the same information goes into a second system.
- The waiting. Where work sits idle because someone's on holiday or an approval is stuck in an inbox.
- The numbers you can't get. Questions management asks that take someone a day to answer.
This takes a few workshops, not months. The output is a one-page map per process — and it almost always produces at least one gasp. ("Wait, that's how invoices get approved?")
Shortcut: our free Digital Readiness Scorecard scores five areas in three minutes and points straight at the weakest ones.
Step 2: Define the outcome, not the project
"Introduce a new CRM" is a project. "Reply to every inbound lead within one hour" is an outcome.
The difference is huge. An outcome tells you when you're done — and lets you judge options fairly. Sometimes the answer turns out not to be a new CRM at all, but a two-day integration with the one you already have.
Good transformation goals are:
- Measurable — a number with a unit: hours per week, days of lead time, percentage of orders processed without a human touching them.
- Owned — one named person is accountable. Not "the team". Teams don't get fired.
- Few — three per year, at most. Every extra goal dilutes attention.
Write the baseline next to each goal. If you can't measure the baseline, measuring it is your first task.
// quick one
Want us to do this for you? We only take a few new clients at a time.
See if you’re a fitStep 3: Pick the first move by return, not by excitement
You'll end up with a long list of things that could be better. The temptation is to start with the most visible or most exciting one. Resist it. Score every candidate on four questions instead:
| Question | Why it matters |
|---|---|
| How often does it happen? | Daily beats monthly — frequency multiplies every minute saved. |
| How much time or money does it cost each time? | The size of the prize per occurrence. |
| Does it follow clear rules? | Rule-based work is cheap and safe to automate. Judgement-heavy work is not — yet. |
| What does an error cost? | Mistakes in invoicing or compliance are expensive, which raises the value of automating. |
The winner is nearly always boring: moving order data into invoicing, generating standard documents, syncing contacts between two tools. Boring wins build trust and free up the time for the harder projects. The full method, with a worked example, is in the 2-hour exercise that finds your most profitable automations.
Step 4: Buy, bend or build — on purpose
For each move you've picked, choose consciously between three options:
- Buy a standard tool and adapt your process to it. Cheapest when your process is standard.
- Bend an existing tool through configuration and integrations. Often the best value — until the workarounds pile up.
- Build a focused piece of custom software. Worth it when the process is what makes you different, or when you're paying people to bridge gaps between tools every day.
The mistake isn't choosing wrong once. It's never making the decision explicitly at all. The maths is in buy, bend or build.
Step 5: Ship small, then make adoption part of the job
Get the first usable version in front of real users in weeks, not quarters. Then treat adoption as part of the project, not something that magically happens afterwards:
- Train with real cases from the team's own work, not demo data.
- Switch the old way off. If the spreadsheet still exists, it will still be used. Guaranteed.
- Check usage four weeks after launch, not on launch day. That's when you find out whether it stuck.
A change nobody adopts has a return of exactly zero, however elegant the software. Nobody has ever been impressed by an unused dashboard.
Step 6: Measure, learn, repeat
Go back to the baseline from step 2. Did the number move? If yes, write down what it's worth and pick the next item from your list. If not, find out why before you build anything else — it's usually adoption, a missed edge case or a goal that was measured wrongly.
This is the moment transformation stops being a project and becomes a habit: a steady rhythm of small, measured improvements that compound. Companies that work this way don't have "transformation programmes". They just get a little faster every quarter — while their competitors are still on slide 37.
Ready for step 1? Take the free Digital Readiness Scorecard. Three minutes, a personal report, and the first moves we'd make in your shoes.