Included in the document should be the scope of what is being transitioned. For example, if a new software application has five modules, but only the first three are live and in production while the other two are still being developed, only those first three should be transitioned, and that should be clear in the document. Knowledge transfer should also be included. Notice how I said transferred, as in the past tense? This document signifies the transition of responsibility, which means all the prep work to make the transition possible should already be done. You want to write down all the knowledge that was transferred via face-to-face meetings and the location of all relevant documentation. If something was mistakenly left out of the knowledge transfer, the implementing team should be expected to assist if called upon.

Finally, all change resources should be released and made available for use in other change efforts. There are a few ways to do this, and in the next clip, I'll show you my preferred way of releasing resources.

The template I'm going to show you is the final summary report, which is used for closing the change initiative.

Here is the Final Summary Report template. You'll notice three tabs at the bottom of this spreadsheet. The first tab is for the first two closure conditions, Scope and Lessons Learned. The second tab is for the third closure condition, Transfer of Ownership. The third tab is for the fourth closure condition, Release of Resources. You'll find space for the change and project name, as well as the approval date and the names of the approvers. If you need more space for the approvers, feel free to add that in. Right below that, you'll find a table for the first closure condition, the Scope of the change/project. Here, you should list out all of the objectives and whether they were met or not. Again, if you need to add more rows, feel free to do that. Below the table is an area for Closure Condition #2, Lessons Learned. Here, you just have three questions. First, was a lessons learned meeting conducted, yes or no? The answer to this question should always be yes. If the answer is no, you really shouldn't be looking to close this change just yet. Was the lessons learned evaluation shared with others? If your organization has a PMO or a CMO, you should absolutely share the lessons learned evaluation with those groups. If your organization does not have one of those groups, you at least want to share it with your manager and other people who perform your role. And finally, the location of the lessons learned evaluation, whether that be on some network drive or in a knowledge database. The last section of this tab is for the signatures. In a previous clip, I mentioned the importance of getting a physical signature for the closure of a change or project. You may elect not to use this, but if you do, there is a space built right into this report for those signatures.

Let's move over to the Transfer of Ownership tab, where you'll be able to document Closure Condition #3. Again, you should add as many rows as needed. The information you want to capture on this table is the transition items, the knowledge transferred for those transition items, who it's being transferred from, who it's being transferred to, and the signature of the person it's being transferred to. Let's review a couple of the examples I've included. The first example of a transition item is the help desk ticket escalation process. The accountability of this process is moving from John Smith to Sally Jones. And the knowledge transferred from John to Sally included the help desk ticket escalation flow chart. You'll notice I included the location of that flow chart, as well as exactly when John reviewed it with Sally. In the last column, we have a space for Sally's signature should you choose to print this form and obtain it. The second example is for the communication of weekly statistics. Sandy Jenkins is currently accountable for this but is transferring it to Tommaso Bertolino. While there wasn't a personal handoff on this one, Sandy has notated where the communication style guide resides, as well as all of the historical communications. Tommaso should only sign if those files meet his needs for a knowledge transfer.

The final tab is for Closure Condition #4, Release of Resources. In the table, you should record each resource's name and their role. I provided two examples: John Smith, a change analyst, and Sandy Jenkins, the communication lead. You'll notice we have two additional columns: Release Date and Release Conditions. The instructions above the table explain a release date should be used when a resource is already committed to a new change of project. I personally like to use release conditions, and you can see an example of one here. Just because a resource is being released, that doesn't mean the person has to be released 100% at the same time. Here is an example of two conditions. The first is to reduce John's commitment to 50% on September 1st of 2022. The second release condition is to release him from this change or project completely once all of the documentation is updated in the knowledge base system. If all four closure conditions are met, your approver should have no problem signing this document. As I mentioned before, I recommend you get physical signatures.