Review dates
Three questions in fifteen minutes: still used, still safe, still worth it?
Lesson 1 named who answers for each thing that runs. Lesson 2 made sure they can stop it. This lesson deals with the slower risk: things that quietly outlive their use. The fix is the cheapest control in the framework. A date in a calendar, and fifteen minutes when it arrives.
Things don't retire themselves
Software piles up. It's easy to start and nobody's job to stop.
of software licences go unused, on average.
Zylo, 2026
new applications added by the average organisation every month.
Zylo, 2026
of companies abandoned most of their AI initiatives in 2025, up from 17% a year earlier.
S&P Global, 2025
Abandoning something is not the same as retiring it. An abandoned tool often keeps running. Its seats renew, its data still flows to a vendor, and somewhere a team still depends on a workflow built around it. Nobody decided to keep it, and nobody decided to stop it.
That's why the third part of principle 3 is a review date. Everything shared or high-stakes that runs has one, and when it arrives, the owner decides.
Three questions, fifteen minutes
When a review date arrives, the owner answers three questions, in fifteen minutes or less.
- Is it still used? This is a question about the item, never about a person. You're asking whether the tool still earns its place, not who uses it how much. The framework never treats usage as a performance measure.
- Is it still safe? Look at the corrections log, any incidents, any change the vendor made, and where its data goes now.
- Is it still worth what it costs? The full running cost, against what it frees up or improves.
Three yeses: keep it, and set a new date. Any no: fix it, or retire it. Either way, findings go on the friction list, which is how a review feeds the next turn of the loop.
The fifteen minutes matters. A review that needs a meeting won't happen. And if an owner can't answer the three questions in fifteen minutes, that's a finding too: the monitoring isn't telling them enough.
- 1Is it still used?
38 of 40 seats were used last month.
- 2Is it still safe?
Data stays in your region, and the vendor has signed your data agreement. No incidents.
- 3Is it still worth what it costs?
Managers say it saves them about an hour a week. It costs less than one of those hours a month.
What the owner brings to fifteen minutes
Fifteen minutes is enough when the evidence is already gathered. Most of it comes from the runbook in lesson 2.
- For “still used?”: seats in use, or how often it ran, from the admin console or the tool's own log. Counts of the tool, never rankings of people.
- For “still safe?”: the corrections log, any incidents through stop, tell, fix, learn, anything the vendor changed, and whether its data still goes where the data map allows.
- For “still worth it?”: the full running cost, including the time people spend checking its output, against what it frees up at the bottleneck or elsewhere.
A fix gets a date too. “Fix it” with no date is how something stays half-broken for a year. Write down what will change and when the owner looks again, usually within a few weeks rather than at the next full review.
The rhythm in the next lesson keeps all this moving. Reviews coming due are on the weekly agenda, so nobody is surprised, and the quarterly meeting sees any review that ended in fix or retire.
Retiring properly
Retiring something is a decision, and it covers three things.
- Its data. Export what you need to keep, then delete the rest as the data map says. A tool you've stopped using can still hold your clients' data.
- Anything that depends on it. Templates, integrations, reports and other workflows. Move them, or switch them off on purpose.
- The people who relied on it. Tell them, and show them what replaces it.
The last thread is the one most often skipped, and it's the one that bites. Take a tool away from people who relied on it without a word, and some of them will rebuild it in personal tools, out of sight. That's the ban from module 3, arriving by the back door.
Setting the dates
The framework says Own is done for an item when every field is filled in and its review date is in the calendar. How far out to set each date is your call. Here's a reasonable starting point, which you can change:
- High stakes: inside this loop, before the quarterly meeting, so leadership sees what's due.
- Everything else: within two loops.
- Any vendor change that touches an item brings its review forward.
Spread the dates out. Six reviews in one week will get rushed. One a week gets fifteen proper minutes each.
Most frameworks put review dates on tools. The Deployment Framework puts them on the rules as well: the guardrails get a full review every year, at the annual meeting. The four principles and the promises are the exception. They're fixed, so no meeting reviews them.
Put a date on everything you own. Items you named in lesson 1 appear below. When a date comes round, open the review and answer the three questions for real.
A reconciliation helper in finance fails its review: it costs more than it saves now that the new ledger does most of the matching. The owner proposes switching it off on the last day of the month. Four people use it during the close, and two monthly reports pull from it.
What do you do?
A review date turns “we should look at that sometime” into fifteen minutes on a Tuesday.
Which of these get a review date?
Mark it complete. Your answers are already saved in this browser.