Free Clip from Change Management: Closing the Plan - Transferring Ownership and Releasing of Resources

1. Home
2. Courses
3. Change Management: Closing the Plan
4. Free Clip: Transferring Ownership and Releasing of Resources

---

---

Mobile users:  Jump to the Free Clips

---

This course was published via Pluralsight.

Transferring ownership and releasing resources are two of the foreclosure conditions that need to be met to gain approval for completion.

The ownership of all change outcomes, including processes, technology, organizations, and other outcomes must be transferred from change resources to stakeholder operational resources. This means the responsibility of keeping things running, up to date, and accurate falls on a person or group who is not part of implementing the change. And all of this should be evidenced by a written agreement of both parties. I personally like the operational group to physically sign the document in some sort of formal ceremony, such as a release party or even at the end of the lessons learned meeting. Signing a document in front of a large group signifies progress, commitment, and ownership. In addition, you'll want them to sign because it's very difficult for someone to say afterwards that they weren't ready, or were not properly prepared by the group who implemented the change.

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 getting developed, only those first three should be transitioned, and that should be clear in the document. Knowledge transferred should also be included. Notice how I said transferred, as in past tense? This document signifies the transition of responsibility, which means all of the prep work to make the transition possible should already be done. You want to write down all of the knowledge which 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 on 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, 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 that 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 are 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 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. And as I mentioned before, I do recommend you get physical signatures.

This course was published via Pluralsight.