Congratulations! You know what change management is. Now it’s time to set up the process in your organization.
There are essentially two ways to start the process. Using an input or trigger. Inputs to the change process are : “request for change” or a “change proposal.” A trigger can be an organizational event such as beginning of strategic planning cycle.
The “request for change” can come from anyone who believes they have identified a need and sometimes a solution, or even just a better alternative to a current practice. The “change proposal” will normally come as a part of an overall strategy or project within the organization.
In either case, this will start the change management process. Here are your next nine steps:
Create a change record – All of the changes within the organization should be recorded, so you can gather change metrics for decisions including store and track all changes. Then you will add the vital information to the record throughout the process. The record helps manage the lifecycle of the change from beginning to end.
Review and Categorize – This helps change management become more effective and efficient. Categorization can later be related to value of the change, one category of change could be more valuable to the organization than another one. Basically, this helps with decision support and work efforts as we continue the process.
Prioritize – Based on your answers for categorization, you can evaluate your changes based on impact, urgency to the business and other supporting factors such as cost. The priorities should reflect the order of importance to the organization for business value versus the need for costly operational efficiencies that may not have any business value.
Approval #1 – Ideally, the organization will have a change advisory board (CAB) with financial, business and technical expertise to help advise on approval or denial of the change. Questions that may come up are: How much will your change cost? Do we have enough money in the budget? What is the level of risk involved with the change? How will this change impact (or even conflict) with other changes or processes in the organization? What is the value to the business of the change? The answers to these questions will help the change manager/authority with the essential decision of whether to do the change. Either way, it’s important that someone can evaluate the cost, impact, time, quality, risk and scope to the business decide whether or not to proceed at this point.
Release Management – The change doesn’t just take effect upon approval. The release team is responsible for coordinating and collaborating across functional teams the building and testing, incorporating appropriate tools, and forming backup plans to formally implement the change.
Approval #2 – This approval is for implementation of the solution by the deployment team. Implementation has to be done to mitigate risk for the change. The Change manager/authority decides when the change should be implemented and uses tools such as a forward schedule change (FSC) calendar to communicate the change implementation to various stakeholders. Keeping in mind the risk of potential service outages or disruptions so the change is managed efficiently. Key input for implementation comes from the release team on amount of time needed and resources, so that the change manager can manage the change with little or no risk to the organization.
Deployment/Implementation – Based on the plan for deployment, the implementation is now executed. Implementation include training and other awareness activities for the change. This helps minimize risk, help insure change success and adoption.
Review – Implementation of the change is not the end of the change lifecycle. This is the evaluation stage or post implementation review (PIR). Has the change had the intended consequences? Has it met the customer needs? Has it met the business needs? What is the risk level of the change? Should the change be classified as normal or standard? The change manager/approver may decide at this point to use the back-out plan created earlier by the release team to insure business continuity and mitigate risk of an undesirable outcome of an change implementation. The change manager may also decide to change the change type from normal to standard or visa versa based on risk.
Knowledge Management and Asset/Configuration Management – Update CMDB, SKMS, CMS, or other tools/databases so that the entire organization benefits from the change and has the best knowledge for their service support and delivery decisions.
Remember, the objective is to successfully meet the budgetary guideline constraints, the business and customer service requirements, all while causing minimal disruption to IT services for your customers. Following this ITIL best practice for change management will certainly help.
Read Anthony’s previous post about the Service Catalog and Enterprise Service Management here
Summary:
How to Set-up Change Management
There are two ways to start the process. Using an input or trigger. Inputs to the change process are : “request for change” or a “change proposal.” A trigger can be an organizational event such as beginning of strategic planning cycle. this will start the change management process. Here are your next nine steps: 1. Create a change record. 2. Review and Categorize. 3. Prioritize. 4. Approval #1. 5. Release Management. 6. Approval #2. 7. Deployment/Implementation. 8. Review. 9. Knowledge Management and Asset/Configuration Management.”
