Digital transformation becomes vague when it begins with a portfolio of technology rather than a specific operational outcome.
Ninety days is enough to create evidence, but not to transform an entire organisation. The aim should be one bounded workflow, a credible baseline, a tested improvement and a decision about what comes next.
What good engineering looks like
In days 1 to 30, map the workflow, decisions, systems, controls and baseline measures. In days 31 to 60, implement the smallest change that tests the critical assumptions. In days 61 to 90, operate it with real users, measure outcomes and decide whether to scale, adapt or stop.
- One accountable business outcome.
- Named operational and technical owners.
- A baseline before implementation.
- A reversible pilot with production-grade controls.
- An evidence review and explicit next decision.
A practical starting point
- Choose the workflow with visible friction and available ownership.
- Write the intended outcome and boundary.
- Fund discovery, delivery and adoption together.
- Schedule the day-90 decision before work begins.
The decision to make
A useful transformation plan does not promise that everything will change. It proves that the organisation can make one important operation clearer, safer and more dependable.
Set a baseline the team can trust
A baseline should describe how the workflow behaves before the pilot, not simply how many tasks the team completed. Select a small set of measures that the owner can explain: elapsed time from request to decision, the number of handoffs, repeat work after an exception, and the proportion of cases that need manual correction. Define how each measure is counted and who checks it. Without that definition, a week of improvement can be confused with a change in demand or with missing data.
Record the starting position using real cases, including a delayed or rejected case. Note where data is unavailable and use a short observation period if a system cannot yet report it. The purpose is to make the day-90 comparison honest. A measured pilot can still fail its target; that is useful evidence when the team knows which assumption did not hold.
Make the day-90 decision explicit
Agree on the decision gate before delivery begins. The team may continue, revise or stop the approach, but each path needs a named decision maker and evidence threshold. For example, an operations owner may require fewer manual corrections without a rise in unresolved exceptions; a technical owner may require that access, audit logs and recovery still work under realistic load. State the threshold as a testable condition, and keep assumptions separate from observed results.
At the review, compare the same measures with the baseline and examine the cases behind the totals. Ask whether a faster path moved work into another team, whether a new control added a hidden queue, and whether users found a workaround. Then record the decision, the evidence, the remaining risks and the person responsible for the next experiment or rollout. A pilot is complete when the organisation can explain its result and its next choice, even when that choice is to stop.