Our previous post on change management laid the foundation for this discussion, defining key terms, establishing the objective, and outlining the most common mistakes made by those implementing change management.
Now, we’ll dive into what a change management process should look like for most organizations. While some organizations will need to adapt the process in certain ways to fit their needs, this framework should be a helpful guide for most.
Step 1: The trigger or input for the process is a Request for Change or Change Proposal.
- A change proposal typically represents a strategic change coming from leadership, but a request for change can come from anyone in the organization.
Step 2: As the change management process is kickstarted by the request for change or change proposal, a change record is created.
- The change record allows an organization to detect and record the change.
Step 3: The change is then reviewed and categorized.
Step 4: Once the change has been reviewed and categorized, it is prioritized.
Step 5: At this stage, there is either a change approval, or it is denied.
- As discussed in our first post, the change approval is just one step in the process! Those thinking of change management only as the process for approving changes are missing out on the value of a full change management process guided by best practices.
- The change approval comes from a change advisory board. They must ensure that the change really is going to be beneficial.
Step 6: Once a change is approved, the work shifts hands and is sent over to the release management team. They build, test and manage remediation.
Step 7: Once release management has worked through the details, they go back to change management with a plan for implementation.
- This should be a collaborative process in which release management presents their best recommendation to change management who then provides any additional feedback necessary to create the best plan possible.
Step 8: At this step, change management will approve the change for implementation. They will also create a forward schedule change (FSC) calendar for the change.
- As a part of the FSC, change management may also create a planned service outage to minimize disruption if they anticipate outages while the change is being deployed.
Step 9: Then the change is deployed! This step includes the implementation of the change as well as any necessary training that needs to go along with instituting the change.
Step 10: Deployment should never be the final step in the process. After a change is deployed, it’s very important to do a post-implementation review to ensure the change had the intended outcomes.
Step 11: Another crucial post-deployment step is to make any necessary updates to maintain knowledge management. This is where you take time to update your CMDB, SKMS, CMS or other necessary tools.
This framework for the change management process works best for most organizations. For those looking to implement a process like this, there are some key things that are needed to enable effective change management.
- Take the time to help people within your organization understand why this is important. Their compliance will be essential, so explain the “why” behind change management to help remove resistance.
Formal process policy and procedures
- Create a formal policy and procedures for change management at your organization. Using flow charts or other visuals to illustrate the process can help make it easier to follow.
Training, training, training
- Enable teams to effectively execute on change management work by providing the necessary training and equipping them with the tools they’ll need.
Technologies to support change process and ITSM process integration
- Make sure your technology supports the change management process and provides the capabilities you need. You may need to configure and customize tools to do address manual process areas you discover.
Now that you’ve gotten our quick and dirty change management overview, learn more by watching our recent change management webinar, featuring Anthony Orr, IT leader and author of ITIL v3 2011 publications.