I was pondering what to describe as the next process in this series. Should I go over to service level management or should I cover change (and maybe release later on) first? It is more common to start with change than with service level (which may in some situations be the wrong decision, more later on), so I start with change as well.
Goal of Change Management
The IT environment is put under constant change in order to meet business requirement, to counter threats, to ward of incidents and problems and to improve value by increasing utility and warranty. Change management is responsible to make sure this change occurs with the least impact on business and taking only managed risks.
Make sure you do it right the first time!
The Principles of Change Management
- Define what is out of scope. When in doubt, it is in scope!
- Use change models and standard changes (a lot)
If you do not have 75% of your changes modelled, your change process needs more resource than nescessary.
- Document your companies requirement on rate of change vs. stabilitiy and risk taking
Make sure that The Business is in agreement with this definition or maybe even driving it.
- Allow for different speeds in different environments or for different services
Some services will have a high security and low risk requirement, so don’t let those be the brakes on your more rapid services. In some markets the quick will eat the slow, while in others the big will eat the small (big often means slow).
- Every change has to be documented (of course)
Even the most risk-free and 100 a day change (if it has not been defined as out of scope) has to be documented as an RfC.
- Review, report and verify
Change management is often felt as a hindrance. So people tend to work around it. It is one of the main jobs of change management is to stay relevant. As an example: when someone applies for a new standard (pre-approved) change, you will find the description as completely risk-free. If you believe this, you approve the standard change and from now on it will run without explicit approvals. Your job is to verify two things:
- Is the standard change as risk free as described?
Monitor for failed changes, including modifications made directly during the implementation, incidents related to the change or additional (emergency?) changes to the same environment immediately following the success of the previous change.
- Is this standard change misused to perform unrelated changes?
Check the real activities of a given change. If users find a way past change management, they may start using this path for other activities.
- Is the standard change as risk free as described?
- Be accepted inside your organization
This is the hardest part, since change managements decisions should not be overruled by upper management (too often). Make sure you have sufficient management backup or else change management will be the toughest job in the company. If you fear that upper management will overrule you, offer to include them into the process for a defined set of changes.
- No Change without a planned fallback scenario
If needed the scenario can be: start from scratch, but make sure that this is spelled out and not just an empty field on your RfC.
- Honest risk analysis
If there is no fallback -> higher risk, if there is no defined and tried change model -> higher risk, if execution is outside of its maintenance window -> higher risk. It may still be urgent, but be clear on the risk side.
If this list sounds a little paranoid, you may be right. A good change manager is always looking where his process may be leaking.
Activities of Change Management
Change management seems to be an easy enough process to model. But again the difficulties start in the details. My personal recommendation is similar to ITIL® v3 but still differs in some slight details. First I will list the standard activities done for each change (including standard, emergency and all the rest of them). Below I have added additional activities outside of the normal flow.
- Record the RfC
This is done by the change initiator. This change initiator should already know what she wants to do. An RfC is usually not entered by the customer, it is entered by the IT expert who plans the change (customers may create service requests). So the expert can already plead their case for change while creating the RfC. The RfC should have information on the execution plan and the risk evaluation plan from the beginning. These should be created as a job list, workorder, tasks or whatever it is called in the tool.
- Sanity check
This often called Review the RfC, which can easily be mistaken for the change review. Depending on the model of the change either a person from change management or the change tool will verify the contents of the RfC. You need to define rules and regulations for this step and you need to continue adapting them to the real world.
- Change assessment & preparation
Each change needs to be assessed at least by the people who are impacted and the ones executing the change plan. A common way to organize this uses workorders. The change initiator created the initial workorder list, which
mayhave been copied from the change model. These workorders contain jobs of different types (or you may have different workorder lists, this is up to the tool implementation)
- Assessment jobs: Can be executed immediatly, have to be finished before the authorization.
- Preparation jobs: May be executed immediately, have to be accepted before the authorization and have to be finished before the implementation.
- Execution jobs: Have to be accepted before the authorization and may only be executed during the implementation.
- Review jobs: May be accepted before the authorization (optionally) and have to be executed before final closure.
The assessment phase contains all assessment jobs and the acceptance of all preparation, execution and flagged review jobs.
- Change authorization
This is where we decide if the planned actions are OK and the risk is acceptable. The way a change is authorized depends heavily on its change model and its risk. For low risk standard changes, you may implement an auto-authorizeif defined criteria are met (e.g. inside its maintenance window, no conflicting changes). Many low to medium risk RfCs will be authorized by the change manager (and her team). Medium and high risk RfCs will need to go to a formal CAB meeting (see my post here on CAB agenda). High and very high risk RfCs will additionally need upper management authorization. Each additional layer of authorization is indeed additional, so that if change manager rejects an RfC it will not go to CAB meeting and may not (if done right) be pushed through by upper management.
- Change preparation
This step may already start in parallel with the assessment phase, as long as you are aware of the implications of a rejected change. This step contains the execution of all the preparation type workorders as described in change assessment. This may include developing, purchasing and building. For complex changes which require a lot of risky pre-work, it is possible to have child-changesas preparation steps. A good tool environment can combine their handling but this is not required for the process to work.
- Change implementation
This is the date we all have been looking for. The execution workorders are done in this step. The defined start and ending date were approved for change, so make sure the implementers stick to it. For complex implementation work it is advisable to define a point of no return, which may be a milestone the on-duty manager has to decide on. When the point of no return is reached it is impossible to implement the fallback scenario without having an unplanned impact on the service or on other changes. For those keen on configuration management, you may design your process as you wish, adding jobs to document CI changes within the implementation phase are later in the review phase. This depends on your requirement for real-time data and its costs.
In the review we start to learn from this change experience. The review results are fed back into the change models and may change the risk assessment for any given model (esp. of the standard changes). Checking for success of the change implementation should include if the rollback scenario was activated and if it was defined correctly, if the change was modified during the implementation (last minute fixes) as well as checking for incidents related to this change during the next high use period of the impacted services. The depth of the review is dependant on the change model and may also be defined as a set of workorders.
- Change closure
A formal closure of the change by the change initiator indicates that the implementation is finished.
So where is the additional procedures for emergency change or how does a standard change differ from the steps defined above? The only difference is in the sizing of the individual steps. If your emergency change model(s) are well defined and your tool supports you well, having all these steps for an emergency change is easy. As an example of speeding up the phases I would propose that your change tool sets any workorder assigned to the current user immediately into the state accepted. If you have that in place, you can create a change for yourself and it can immediately rush on to the authorization. Be minimal in your e-change models but stick to your process definition.
In addition to the standard activities for each change, I have added some activities not directly related to a single RfC.
- Change modelling
Any new change model request should be taken up by change management, since it increases the acceptance of the process. Changes to the change models are RfCs themselves, so they are handled by the standard process. In this case though change management has a larger role, since they are builder and implementer of the RfC.
Every process should create reports and use them to improve their actions. For change management this is even more so, since your organization will continue to try to avoid being botheredby change management. So you use your reports to detect misuse. Measure change success against the planned values for each standard change model. Check if the risk assessment is accurate enough. Verify that a change really changed what it was meant to change. Make sure that the job plans or workorders are really used as a means to track the work and that there are no shadow jobs.
Again an activity that fits any process. But let me stress that a good change manager knows what is going on and knows how well his process is accepted. A strong change manager has his appearance in many meetings (and boards) accross the company.
Attributes of an RfC
This post has turned to get longer by the minute, so I will keep this list short and by no means complete. Just some my suggestions are:
- Affected Services
Ideally this is a reference to the service CIs that are affected by this change.
- Changed CIs
In addition to the service CIs, list the directly changed CIs.
- Affected CIs
The CIs that will be impacted. The list “Affected Services” can be a subset of this list.
- Required CIs
Another list of CIs, which indicates the CIs used during the implementation of the change. This can reduce the chance of conflicting changes on different CIs.
- Impacted Clients
Especially for service providers in a multi-client environment you will need to list the impact for each customer.
Can be either a link to another workflow object (e.g. Incident) or a selection of sources out of the current system. Values could be Incident, Problem, Service Request, External, Project, Release, …
- Change model
Of course the change model. Selecting a given change model should fill out the change as complete as the model defines. The change model may also contain restrictions on execution time, selectable CIs and restrictions on modifying the data of the RfC (e.g. assessment workorders created by the change model may not be removed).
- Risk category
Classify what the impact can be, if the change turns into a disaster. This value is a key to the complexity of the change process. Try modelling as few values as possible, as many as required. The risk category defines the level of managerial approval you need to authorize the change, so this needs to reflect the decision making process of your company.
List all individual risks of the change. Of course be more elaborate for high risk or complicated changes. For each risk there should be a place to note the mitigation strategy, the fallback scenario (names are enough, list the details somewhere else) and control used to discover the risk. This list should be used during implementation and when a change fails you can indicate which risk produced the failure (or find a new one!).
There are more details to note for each RfC (I left out some obvious ones like short and long description, owner, etc.), but I listed some of the things you may not find everywhere else as well.
Change management is one of the processes many companies start with and at the same time it is one of the most hated processes. I have seen so many change managers without any power to stop a change that I am starting to believe that if a company is not mature enough to accept formal decision procedures, change management should notbe implemented. If it is done well, with thought and experience, reflecting your companies way of decision making, it will be a great benefit to your quality.
Remember that even though change management has the power to stall changes, it is there to enable change.