How to write a 30/60/90-day improvement plan that actually gets done
Most improvement plans fail on day 31. The first month gets done because it has attention; the rest evaporates because it was never a plan, it was a list of aspirations with month labels on it.
What makes it a plan, not a wish list
Every line needs four things. If any one is missing, that line will not happen.
- A named owner. A person, not a team. "Operations" owns nothing.
- A date. A specific one, not "Q3".
- A verb you can watch. "Publish the standard checklist", not "improve documentation".
- A measure of done. What will be true when it's finished, and how you'll know.
What belongs in each window
- Days 1 to 30, prove it and stop the bleeding. Quick wins that need no budget and no systems change, plus the measurement you'll need later. Put the baseline measures in place now, or you will never be able to prove the change worked.
- Days 31 to 60, change how the work is done. Standard work, revised handovers, removed approval steps, retraining. This is where the real gain sits, and it needs the credibility earned in the first 30 days.
- Days 61 to 90, make it stick. Systems and automation changes, controls, the review rhythm, and the handover to business-as-usual ownership.
Sequence by dependency, not by enthusiasm
Before scheduling anything, ask what must be true first. Automating a broken form just gets you broken data faster. The usual honest order is: measure, simplify, standardise, then automate.
Build the review rhythm into the plan
Put a fortnightly 30-minute review in the diary for the whole 90 days, with the measures on screen. Plans do not die from bad ideas; they die from nobody asking about them on a Tuesday.
More guides
The four categories, the formula, a worked example, and the assumptions you must write down if you want finance to accept the number.
Current state vs future state, swimlanes, the level of detail that's actually useful, and the five mistakes that make maps useless.

