How to Review a Software Project After Delivery

Delivery is a good point to examine a software project, but it is not the end of learning. Real staff and customers may use the system differently from a demonstration. A useful review compares the original business goal with actual work, distinguishes defects from new ideas, and chooses a manageable next set of improvements.

Revisit the promise made at the start

Find the original problem statement, agreed scope, budget assumptions, and measures of success. Which customer or staff tasks were supposed to improve? Ask people to complete those tasks in the delivered system and compare them with the old way of working. Note what has genuinely changed and what still relies on manual steps. Avoid rewriting the goal after the fact to make the result look better or worse.

The GOV.UK service standard on defining success connects measures to the problem a service should solve and recommends revising them as understanding grows. A small business can apply that approach without adopting public reporting requirements: define what mattered, check it, then adjust the measure if experience shows it was incomplete.

Separate three kinds of findings

First, identify defects where the product does not behave as agreed. Second, identify adoption problems where behavior is technically correct but staff cannot complete the task comfortably. Third, identify new needs discovered through use. The responses differ. A defect may require repair before wider rollout; an adoption issue may call for a better workflow or training; a new need belongs in a priority discussion. Mixing all three in one list makes it hard to decide what is owed and what is a new investment.

Ask the developer to explain technical issues in business terms: which work is affected, what the likely cause is, and how the fix will be checked. Ask staff and customers for specific examples rather than a general rating alone. The GOV.UK guidance on moderated usability testing recommends observing people perform realistic tasks. A brief session with an ordinary and awkward case can show problems that a meeting discussion misses.

Review costs and continuing responsibility

Compare actual project spending with the plan, including work added after discovery. Record what caused changes: unclear requirements, outside dependencies, business decisions, or technical repair. Avoid treating every difference as failure; some discoveries prevent a more expensive mistake. Still, the owner should know what ongoing hosting, support, maintenance, and supplier costs the delivered system now creates.

Agree who owns open issues and when they will be reviewed. Decide what must be corrected immediately, what can be scheduled, and what should be declined. Keep a short record of the decision and its reason. A review that produces a large unprioritized wish list will not help a small team. Repeat the review after a normal business cycle if the first weeks did not include typical use.

Include the people responsible for operating the system. Can they manage accounts, understand alerts, access backups, and reach the provider when something fails? A project may be delivered for ordinary use while leaving support arrangements unclear. Ask for a practical handover of essential accounts and instructions, then confirm that the right staff can use them. This protects the business after the launch team moves to other work.

Share the findings without turning the review into a search for blame. Staff may have adapted a process to keep customers served, and the developer may have made a reasonable choice with incomplete information. Identify the condition that produced a problem and the next decision needed. That makes the review useful for future projects as well as the current product.

Holism can help an owner conduct this review with a developer who uses AI and a reusable foundation to make focused changes. The owner judges the business outcome; the developer checks the technical result and explains remaining risk. A good post-delivery review turns real use into a clear next decision rather than treating a launch as the final proof of success.