The recovery plan was good. Six months later, one of the three fixes has been delivered. The plan was never the problem.
By the time an organisation admits an implementation is in trouble, it has usually been in trouble for a year. Each individual difficulty was explained — this site has a leadership problem, that group needs more time, this is a training issue — and none of the explanations was ever added up.
Then comes the recovery: a new director, a clear mandate, a credible ninety-day plan. Narrowed scope, three specific product fixes, a rebuilt training approach, a realistic sequence.
The fixes required decisions that crossed two directorates — a process step, a data definition, who could authorise an exemption. The governance that would have settled them had not been rebuilt. The board still met monthly, still consisted of the same people, and still referred cross-boundary questions to a forum that met quarterly.
Every item on the plan was sound, and each of them arrived at the same bottleneck.
Rebuild the decision-making before the plan. A recovery plan is a set of decisions waiting to be made, and if the organisation could already make them it would not need a recovery.
Built to Be Used closes with a chapter on recovering an implementation that has already gone wrong.
#ProgrammeManagement #ITgovernance #TurnaroundManagement
This article accompanies the book Built to Be Used.