This section of the ABCDE way is another that separates average change management from top class, ‘customer-first’ delivery. It’s often these final stages that you’ll be remembered for, so let’s make it a good one
Embed is about pulling all your data and learning together to help the Sponsor decide whether the benefits and aims of the project have been met.
If those success factors are complete, or they’re on track to get there by the date you forecast, you’ll perform a handover in to ‘BAU’ where they’ll take safe ownership of the new product or service.
In this section we’ll also look at lessons learned, on-going benefits and getting ready to close the project down in a controlled way.
In this stage you’re pulling together a summary of progress, the data sets and lessons learned to enable your Sponsor to agree whether you’re ready to do a handover.
Everything’s coming together nicely, it’s like you planned it ????. You’ve launched the product or the service, you measured progress. It’s now time to document what happened so that you can show play that back to the Sponsor. Then you’ll ask them to decide if they’re happy for you to move on.
There are 4 key elements to the Document stage. You’re pulling all the information together in one place, and you’ll provide a summary back to the sponsor. Just think of this as a bigger-than-usual status report. This will be the last status report that you’re going to do for your Sponsor… sad times.
In Documents and Data, dig out your critical success factors and pull together the results against your exit criteria. You may also want to refresh some documentation, such as customer Q and As, manuals, or an update to some website content that you need to do before you finish. Bring it all together.
Roles and Responsibilities are key. Spell out clearly who will look after the thing that you’ve delivered in the real world once the project has closed. Remember that these people have been on the journey with you. They were identified in the RACI right at the very beginning. So, they know the journey that you’ve been on, it’s not going to be a hard sell to hand over a responsibility to them.
Issue log summary is the list of all the problems that came out after go-live: a complete list of all your incidents. It includes the ones that are closed and importantly, the resolution, so you can refer back to that in future if needs be. It also includes any open incidents. We don’t want to leave the business with any open problems that the project should have solved before they left. So, if there are any still open, it should only be improvement ideas and tweaks or perhaps change requests that we might have thought about along the way.
Time for reflection. What could you do better or differently? A lesson learnt from me: before you embark on a project, it’s always a good idea to get some advice from people that may have either delivered something in the business already or have delivered something quite similar to what you’re doing. They’ll always have things that went well and equally not so good things. That delivery experience is magic and you could avoid making their mistakes.
