The Post-Launch Review: What to Check Six Months In

Six months ago you retired the spreadsheet, ran the training sessions and fielded a fortnight of “where did the button go?” questions. Things have gone quiet. Quiet can mean the tool is working. It can also mean people have stopped complaining because they have stopped using it properly.

The post-launch review is how you find out which. It is not a celebration and it is not a performance review for the project team. It is a structured look at how the tool is really being used, so you can fix what drifted before it hardens into habit.

Why six months

Too early, and you are reviewing the learning curve rather than the tool. Too late, and workarounds have become the process. Six months is usually long enough for a full cycle of the work, including month-end and at least one quarter-end, and short enough that people still remember what the old way was like.

If your process is seasonal, time the review just after the busy period. A tool that copes with a quiet March may fall apart in a frantic November.

Check adoption: who uses it, and how

Start with the facts. Most platforms show login and activity data. Look for:

• Active users versus licensed users. If 40 seats are paid and 22 people logged in last month, find out why. Some may be occasional users who do not need a seat; others may have quietly gone back to their own lists.
• Where records are created. If most new records arrive through a single person, that person may be retyping work that others send them by email.
• Time between steps. Records that sit in one state for a long time often point to someone who is not checking the tool.

Then talk to people. Pick six users across roles, including at least one who uses the tool reluctantly, and ask three questions: what do you do in it, what do you do outside it, and what annoys you most. Fifteen minutes each is plenty.

Why Your Team Keeps Going Back to the Spreadsheet is useful background here, because the reasons people drift away are usually fixable.

Check data quality: is the data trustworthy

A tool can be fully adopted and still full of rubbish. Run a few quick tests:

• Blank fields. Which important fields are empty on more than, say, 10 percent of records? Either the field is not needed or it is not enforced at the right stage.
• “Other” and free text. If a picklist’s “Other” option is the second most popular choice, the list is missing values.
• Duplicates. Search for the same client, supplier or item entered twice under slightly different names.
• Stale records. Count records that have not changed in 90 days but are not closed. Each one is either finished and not marked, or stuck and not noticed.

Pick twenty records at random and check them against reality. Is the status right? Is the owner still the owner? This takes an hour and tells you more than any dashboard.

Look for the workarounds

Workarounds are the most valuable finding in any review, because each one is a user telling you what the tool is missing. Look for:

• Personal spreadsheets that pull an export and add columns
• Notes fields used to store structured information like dates or amounts
• Chat messages asking someone to “update the record for me”
• Duplicate records created to represent a second step or a split order

Do not treat these as rule-breaking. Ask what job the workaround is doing, and whether the tool should do it instead. Sometimes the answer is a new field. Sometimes it is an honest “that is analysis, keep it in a sheet”, which is fine. When a Spreadsheet Is Actually the Right Tool draws that line.

Find what nobody uses

Every launch includes features someone was sure would be essential. Six months on, check which views, fields, automations and reports have not been touched.

Unused features are not harmless. They clutter forms, slow people down and make the tool harder to learn for new starters. Automations that fire into the void create noise, and old reports with stale filters give wrong answers to anyone who stumbles on them.

For each unused item, decide: remove it, hide it, or fix it because it was a good idea that nobody discovered. The Overbuilt Tool: When You Designed for Problems You Don’t Have covers how to simplify without upsetting the person who asked for it.

Compare against what you promised

If you set baselines before launch, as Measuring Success: Metrics That Prove Your Migration Worked recommends, now is when you measure against them. Turnaround time, error rates, hours spent on reconciliation: put the before and after side by side.

Be honest about the misses. If turnaround improved but data quality did not, say so. A review that only reports good news will not be believed the next time you ask for budget, and the misses are usually where the next round of improvements comes from.

Turn findings into a shortlist

A review that produces forty recommendations produces none. Sort your findings into a simple table and pick no more than five to act on:

Favour high impact, low effort first. Put the rest in the backlog with a note of when you found them, so the next review can see whether they still matter.

Share the shortlist with users. Telling people “you said X, so we are changing Y” is the single best way to keep them reporting problems instead of working around them.

Where to start this week

• Book the review into the calendar for six months after launch, and invite the business owner and technical owner.
• Pull active-user numbers and compare them with paid seats.
• Choose six users across roles and schedule fifteen-minute conversations.
• Pick twenty random records and check them against reality.