Implementation Strategies and the Post-Implementation Review

Implementation strategies and the post-implementation review. Two decisions hide in this lesson: how to switch the business over to a new system, and whether the project is really finished at go-live. The exam has a firm view on both.

The situation. The build is done, the data is converted, and now the project has to actually change everyone over. One camp wants to run the old and new systems side by side for a month; another wants to save the cost and flip everyone to the new system on Saturday night, old system off. And once it is live, the plan is to close the project and move the team on.

So, the ways to change over, from safe to fast. Parallel running: old and new operate together for a period, their outputs are compared, and the old system is a ready fallback. It is the lowest risk, and the highest cost, because you run and reconcile two systems at once.

Phased changeover: the move happens in stages, module by module or site by site. Risk and cost sit in the middle, a failure is contained to the stage, but the two systems must interoperate during the transition.

Pilot: one site or group adopts the new system first, limiting the blast radius before a wider rollout. And direct, or big-bang, cutover: everyone moves at once and the old system is retired immediately. Cheapest and fastest, and the highest risk, because there is no fallback if the new system fails.

What separates the low-risk options from the high-risk one is the fallback. Parallel and phased keep a way back; a direct cutover does not. That is why parallel running is the lowest-risk choice and also the most resource-intensive. When a question asks which changeover carries the least risk, it is parallel, precisely because the old system stays live to compare against and fall back to.

So when a critical system is moved by big-bang cutover, the auditor’s greatest concern is exactly that: if the new system fails on Monday morning, there is nothing to revert to. That does not forbid a direct cutover; it raises the bar. It demands exhaustive testing beforehand and a tested rollback plan, a rehearsed, proven way back to a working state, not a paragraph in a document. An untested rollback is not a fallback; it is a hope.

Which means there is no single right changeover; there is a right one for the risk. The more unacceptable a failure would be, the more you lean toward parallel running and away from a direct cutover.

Now the second decision. Going live is not the finish line. The project set out to deliver benefits, the ones the sponsor put in the business case back in lesson one, and no one yet knows whether it did. That is the job of the post-implementation review.

A post-implementation review looks back and asks whether the system met its objectives and delivered the expected benefits, at the expected cost. Two things make it meaningful. Timing: it is conducted after the system has stabilised into normal operation, not at go-live, because too early you measure teething troubles, not steady-state value. And independence: it is most credible when performed by someone independent of the project, so the people who delivered it are not the ones grading it.

And here the thread from lesson one closes. Because the benefits were stated and measurable at the start, the review has something concrete to check them against. A project with no approved business case leaves the review with nothing to measure, which is why the two lessons are two ends of the same thread.

So carry this away. Judge a changeover by its fallback, not by its speed; a direct cutover of a critical system without a tested rollback is the classic wrong choice. And do not treat go-live as the end. The loop closes at the post-implementation review, conducted after stabilisation, ideally independently, measuring the delivered system against the benefits it was supposed to bring.