Five Things Nobody Tells You Before a Transformation
Most failed digital transformations were not failed builds. They were failed specifications — and nobody noticed until the invoice arrived.
I have spent more than two decades watching organisations commission software they did not need, to fix processes nobody had properly described. The pattern almost never varies. The technology gets blamed. The supplier gets blamed. The users get blamed for resisting. The one thing that rarely gets examined is the sequence of decisions that put everyone in that position months earlier.
That pattern is why I wrote Discover Your Process First: The Missing Step in Every Failed Transformation. Here are five things you will take away from it.
1. How to discover your process before you automate it — and why the sequence protects the whole investment
Automation is an amplifier. Point it at a well-understood process and it multiplies the value. Point it at a process nobody has mapped and it multiplies the confusion — faster, at scale and now with a support contract attached.
The book makes the case for a specific order: discovery, then specification, then build. Reverse it and every subsequent choice rests on assumptions rather than evidence, which is why the cost of a late change is so brutal. You are not changing code, you are unwinding a chain of decisions that all share the same unexamined premise.
You will finish these chapters able to argue for discovery as a protection of the budget rather than a delay to it — which is usually the argument you actually need to win.
2. How to map workflows collaboratively, using a five-stage methodology that goes well beyond a flowchart
A flowchart drawn by one analyst in a back room describes one person's understanding of the work. That is not the same thing as the work.
The book sets out a five-stage methodology for graphically mapping workflows as a room activity, with the people who do the job in front of the map. The disagreements are the point. When two departments describe the same handover differently, you have found a defect that would otherwise have surfaced in user acceptance testing at ten times the cost.
You will learn to produce a workflow that carries sequence, ownership, the information moving between steps, the decisions being made and the outcomes each step must deliver — worked through with a graphical tool and real examples rather than described in the abstract.
Flow - Task Identification - Process - Logic - Exceptions
3. How to assign roles clearly using ARCHI™ — including the Helper
RACI has been the default for decades, and it has a gap. It describes who is responsible, who is accountable, who is consulted and who is informed. It has no honest place for the person who is not accountable, was never formally consulted, but without whom the step does not complete.
Every organisation has these people. The colleague in another department who checks the thing before it goes out. The long-serving administrator everyone rings when the system does something strange. Their contribution is invisible on the chart and therefore invisible in the specification — until they are on leave, or they retire, and the process quietly stops working.
The book introduces ARCHI™, which keeps the clarity of RACI and adds the H: an explicit Helper designation that makes cross-boundary participation visible and accountable. There is a worked ARCHI worksheet in the appendices you can take straight into your next mapping session.
4. How to verify a specification before a single line of code is written
Here is the question that tends to produce a long silence: how do you currently know that a specification is correct?
Most organisations cannot answer it, because their real verification method is to build the thing and see whether people complain. That is not verification. That is a very expensive test.
There is a better answer, and it begins with the map. A properly mapped workflow is not a picture of the process — it is structured information about how the work actually runs. That means it can be taken further than review. It can be turned into a testable model: the specification made executable, so it can be exercised, challenged and put under load before anybody commits a developer to it.
Run cases through it and the defects surface on their own. The decision point with no defined outcome. The handover with an owner on one side and nobody on the other. The role assignment that no named person actually holds. These are the same faults that normally emerge in user acceptance testing, months later, when fixing them means unpicking working code. Found in the model, each one costs an afternoon.
The book covers this as Intelligent Verification, and it is the reason the mapping stage earns the time it takes. A map that only informs people is documentation. A map that generates a testable model is an asset — and it is what the Verification Engine™ inside Agile Discovery™ is built on.
5. How to choose between Waterfall, Agile and Agile Discovery™ on merit
Waterfall is not obsolete and Agile is not universal. Both are routinely selected for reasons that have nothing to do with the work: because it is what the organisation has always done, because it is what the supplier sells or because a delivery framework was chosen before anyone understood the problem.
The book gives each an honest hearing. Waterfall suits stable requirements and fixed regulatory outcomes. Agile suits genuine uncertainty about user needs, provided you have the access to users that Agile assumes. Agile Discovery™ is the methodology I developed for the case that handles neither well: where the uncertainty is not about the solution at all, but about a process nobody has yet described.
You will come away able to make that choice deliberately, and to explain the reasoning to a board.
Why this book?
None of this is expensive. It amounts to a few weeks of structured work at the front of a programme, set against a failure rate that continues to embarrass an entire industry.
The organisations that get this right are not the ones with better technology. They are the ones that took the time to understand their own work before asking anybody to change it.
Discover your process first. Everything else follows.
Back the campaign and reserve your copy.
This book argues against building things before you understand who they are for.
Backers get the signed first edition, and Inner Circle supporters get their name in the acknowledgments. (Prices in USD.)
Subscribe to my LinkedIn newsletter How SME's Can Go Digital!
David Blagden © 2026
#DigitalTransformation #ProcessDiscovery #AI #DiscoverYourProcessFirst