The eight strategies, in the order they work
Same items as every other digital transformation list. The order is what makes them a strategy, and each one carries an owner and a test.
One: name the outcome in one sentence
One sentence, one number, one date, such as cutting the time from order to dispatch from four days to one by the end of next year, or lifting a customer experience score on one journey.
Why it sits first. Everything downstream inherits it. With five goals you have no goal, because every trade-off can be justified by one of the other four.
The sponsor writes it, not the programme team, because a digital strategy the sponsor cannot recite is not one. If an executive cannot write the sentence, the programme does not have a sponsor. It has a budget holder, which is different and less useful.
Owner: the executive sponsor. Test: ask three people on the programme to write the outcome from memory and compare the three sentences.
Two: pick one process and map it as it really runs
Not as the manual describes it. Sit with the people who do it and write down what actually happens, including the spreadsheet nobody mentions and the approval that is really a phone call.
Why it sits second. This is where the real constraints appear, and they are rarely the ones in the business case. Map before you buy, and both the shortlist and the customer experience you are promising will change.
Process mapping also tells you which steps are candidates for automation rather than redesign, and our post on business process automation with RPA covers where that line sits.
Owner: the process owner in the business, not IT. Test: show the map to the people who do the work and count the corrections.
Three: fix who owns the data before you move it
This is data governance at its most practical. Name an owner for each core record type: customer, product, site, supplier. Write one definition per key metric, with the source system and what it excludes.
Why it sits third. Everything after this inherits your data, and data-driven decision making rests on it, because a model, a dashboard, a migration and a report all carry the same inconsistency forward, and each one makes it more expensive to fix.
This is the least glamorous week in the programme and the one with the highest return. Our guide to data management and governance covers how ownership works in practice.
Owner: a business data owner per record type. Test: pick a supplier and count how many versions of it exist across your systems.
Four: decide what happens to the legacy systems
Three honest options exist for each one. Replace it, which is expensive and slow. Wrap it behind an API, which buys years and keeps the integration cost visible. Leave it alone, which is a real answer for a stable system nobody needs to change.
Why it sits fourth. You cannot decide this before the process map, because the map tells you which legacy systems are actually in the path. And you must decide it before the platform, because the answer changes what the platform has to do.
The common failure is treating replacement as the default. Most estates have two or three systems that genuinely need replacing and a dozen that need wrapping. Our post on cloud computing in digital transformation covers what moves and what does not.
Owner: the enterprise architect, with the process owner. Test: for each system in the path, which of the three options is written down, and who signed it?
Five: ship one thing to real users
One process, one user group, one date, and not a proof of concept in a lab, and not a pilot that runs for a year without a decision attached to it.
Why it sits fifth. Everything before this was preparation, and preparation has a shelf life. A programme that has not shipped anything in nine months has lost the argument internally, whatever the plan says.
It also converts opinions into evidence. Before the pilot, the debate about the new way of working is theoretical, and after it there is something to point at.
Owner: a delivery lead with authority to ship. Test: name the users, the date, and what will be true afterwards that is not true now.
Six: change the operating model to match
Now the agile methodologies, the team structures, the funding model and the governance board, with cross-functional teams that own an outcome rather than a handover.
Why it sits sixth, and why this is not negotiable. Agile ways of working introduced before anything has shipped become a vocabulary. People learn the ceremonies and keep the old process underneath, because nothing has proved the new one works.
After step five you have a team that shipped something and can explain how, and that team is the template. Change management stops being a slide deck and becomes a description of what the successful team did.
Owner: the sponsor, with HR and finance, because funding and reporting lines have to move too. Test: which team currently owns an outcome end to end, and who do they report to?
Seven: move the measure from delivery to outcome
Stop reporting what shipped, and start reporting whether the outcome sentence from step one is actually moving.
Why it sits seventh. You need the definitions from step three, and something live from step five before an outcome measure means anything, because reporting it earlier means reporting noise.
This is where data-driven decision making stops being a phrase on a slide, and where data analytics earns its place in the programme rather than sitting beside it. The same discipline applies as anywhere else: one definition per metric, one owner, and a number that two departments produce identically. Our posts on how big data changes operations and where AI and machine learning fit cover the analytics and model side.
Owner: the metric owner in the business function. Test: what did the outcome number do last month, and who reported it?
Eight: make adoption somebody's job
The old process has to stop, and somebody has to own stopping it, with a date, and with the authority to switch off the old system. This is change management with a date on it rather than a communications plan.
Why it sits last. You cannot switch off what has no replacement, and you cannot ask people to change before the new way exists. But a programme that skips this step ends with two processes running in parallel, which costs more than the one it replaced.
This is the quietest failure in enterprise digital transformation, because nothing goes wrong. The new system works, the old one still runs, and the saving never appears.
Owner: the process owner, with a named date. Test: what is the switch-off date for the old process, and who set it?
