Why these programmes fail
Not for technical reasons. They fail because the scope was agreed eighteen months before anything shipped, the business changed underneath it, and by the time anyone saw working software the requirements described a company that no longer existed.
They also fail because the process that got documented was the official one. The real process, the one with the spreadsheet and the WhatsApp group and the person who knows which exceptions to allow, never made it into the requirements. Then the system goes live and people quietly carry on using the spreadsheet.
What we do instead
Map what actually happens. We sit with the people doing the work and document the real process, including the workarounds. The workarounds are the most valuable thing in the room: each one marks a place where the official system fails, and together they are the requirements.
Get the data into one place. Most transformation value is unlocked here rather than in any new interface. When the same customer exists under three spellings in four systems, nothing downstream can be trusted.
Rebuild around outcomes, not the org chart. Processes that cross departments are where the delay lives. Systems designed around departments preserve that delay in software.
Ship in cycles. Each 28 days ends with something live. If the business changes direction at month four, you have four cycles of working systems rather than a half-finished programme.
Adoption is the hard part
A system nobody uses is worse than no system, because now you are paying for it and still running the spreadsheet.
So we involve the people who will use the thing from the first week, not at training. We measure adoption after release and treat low adoption as a design fault rather than a user problem. And we leave documentation written for the person doing the job, not for the person who built it.
Asked before,
answered straight
How long does digital transformation take?
The honest answer is that it does not end, which is why we stopped treating it as a project with a finish line. What we can tell you is that each 28-day cycle ends with something live and measurable, and you decide after each one whether to continue.
Do we have to replace our existing systems?
Usually not. Most of the value in these programmes comes from connecting what you have and fixing the data moving between systems. Replacement is sometimes right but it is the expensive answer, so it needs a better reason than age.
How do you measure whether it worked?
We agree the measurement before starting: hours saved, errors reduced, days taken out of a cycle time, cost removed. Agreeing it up front is what makes the result a fact rather than an opinion at the closing meeting.
Start with one process.
Pick the one that causes the most arguments. One cycle to map it honestly and tell you what fixing it is worth is a small bet with a clear answer at the end.