90-Day Business Transformation Plan: Template and Worked Example
A 90-day transformation plan should turn one important business constraint into an evidence-backed decision: expand a tested change, revise it or stop. It is not a promise to transform an entire company in three months.
A 90-day transformation plan should turn one important business constraint into an evidence-backed decision: expand a tested change, revise it or stop. It is not a promise to transform an entire company in three months.
This template is for an operating leader and delivery team who can name the workflow they want to improve. It combines a 30/60/90-day schedule with ownership, measurement and explicit approval gates. The completed example concerns invoice approval. Its figures and targets are illustrative, not Cognativ client results.
Download the editable blank plan (CSV) or download the completed invoice example (CSV). Both files open in a spreadsheet; no registration is required.
A Completed Plan: Reduce Invoice Approval Delays
Imagine a distributor whose invoices wait for purchase-order corrections and manager approval. The sponsor wants shorter approval time without increasing incorrect payments. The pilot covers one business unit and standard purchase-order invoices. Supplier onboarding, non-PO exceptions and payment execution remain outside its scope.
| Period | Work and accountable role | Evidence required at the gate |
|---|---|---|
| Days 1-30 | Finance operations lead maps receipt through approval, samples delayed invoices and agrees event definitions. | Four-week baseline; missing timestamps quantified; exception categories; named pilot owner and approved scope. |
| Days 31-60 | Accounts payable lead tests complete-request validation and a delegated approval queue for the selected unit. | Same measurement rules, daily exceptions, weekly accepted/reworked totals, confirmed fallback process. |
| Days 61-90 | Finance sponsor reviews results, workload, control failures and implementation cost with process owners. | Expand/revise/stop decision, unresolved issues, operating owner, next review date and funded next scope. |
The hypothetical baseline is a median of six business days from receipt of a complete invoice to approval. The proposed target is four days or less during the last four pilot weeks. Incorrect approvals must not rise above the baseline rate. These numbers define a test; they are not industry benchmarks or a forecast.
Measure invoices from the same starting event in both periods. Otherwise a new intake check could exclude difficult invoices and make approval time look better while suppliers wait longer. Track receipt-to-complete time separately and report the number of invoices still open at the cutoff.
Days 1-30: Establish the Problem Before Funding the Solution
Write the problem in observable terms: which customers or employees are affected, where work waits, and what the consequence is. “We need an AI workflow” is a proposed solution. “Complete invoices wait three days for an approval assignment” is a condition that can be investigated.
Walk through real cases with the people doing the work. Compare the process diagram with event records and exception handling. A formal policy may describe approvals that staff bypass because the named manager is unavailable. Record that difference without assuming that a new system will resolve it.
The GOV.UK discovery guidance offers a useful separation between understanding a problem and committing to build. The schedule here is an authored planning framework, not a government-prescribed 90-day method.
At the first gate, require a baseline, a plausible constraint, a feasible intervention and agreement from the people who own the affected controls. If records cannot distinguish waiting from active work, fund a short measurement step. Do not replace missing evidence with a more ambitious target.
Days 31-60: Run a Pilot That Can Fail Informatively
Choose the smallest scope that tests the proposed explanation. In the example, routing complete invoices to a delegated approver tests whether assignment delays matter. Replacing the ERP, changing supplier terms and automating payment at the same time would make the result difficult to interpret.
Define entry criteria, exclusions and the fallback before starting. Staff must know how to return an invoice to the existing process when data are incomplete or authority is disputed. Preserve the reason for fallback; excluding those records from the report would hide part of the pilot's cost.
- Daily: resolve blocked cases, confirm control exceptions and assign an owner to overdue work.
- Weekly: compare outcomes, volumes and case mix; inspect a sample of both accepted and reworked invoices.
- At day 60: decide whether the evidence supports continued testing. A control failure can stop expansion even if cycle time improves.
Set a change log. A staffing increase, holiday, supplier campaign or altered invoice mix can affect results. A before-and-after difference is useful operating evidence but does not, by itself, prove the pilot caused the change.
Days 61-90: Make an Operating Decision, Not a Presentation
Review the intended result alongside adverse effects and total effort. Faster approvals may transfer unresolved work to procurement or increase rework after payment. Count support effort, manual corrections and the cost of sustaining the new queue, not only implementation tasks completed.
| Decision | Evidence supporting it | Next commitment |
|---|---|---|
| Expand | Useful improvement under comparable conditions, acceptable controls and an operating owner. | Specify the next unit, capacity and rollback conditions. |
| Revise | A promising effect with a bounded unresolved constraint or measurement gap. | Change one assumption and define another test. |
| Stop | No useful improvement, unacceptable harm, excessive operating cost or a disproven problem hypothesis. | Restore the approved process and retain the learning. |
Capture the decision in a short record: evidence considered, alternatives rejected, accountable decision-maker, conditions and review date. A completion percentage is not a substitute. Closing every project task can still leave the business constraint unchanged.
How to Adapt the Template to Your Business
- Replace the example scope with one named process and a clear start/end boundary.
- Specify the outcome, baseline period, target, denominator and source. Name the person who can explain the calculation.
- Assign an accountable owner to each workstream and decision. Identify dependencies outside that person's authority.
- Choose evidence gates before scheduling activities. Dates should make the evidence achievable, not pressure the team to declare success.
- Include a quality or risk guardrail, fallback and explicit expansion decision.
For a small team, one worksheet and a weekly review may be sufficient. For several units, retain a common outcome definition while recording different constraints and owners. Do not average incompatible measures into a single transformation score.
The service measurement guidance is a useful reference for connecting performance data to user needs. The practical goal here is narrower: at day 90, know what changed, what remains uncertain and who owns the next decision.