What is it?

Change Management is a service transition process primarily but reaches across the service lifecycle. It is primarily and approval process designed to ensure the right people make the right decisions understanding the risk and cost of the decision. A strategic decision that has risks across several business units and service is likely to go to an executive leadership team, whilst at the other end of the scale a regularly performed task that has low risk might be assigned an approval to be repeated in the form of a standard change. The trick is to know what decisions need top be made by what people in the space in between, what information needs to be provided and how managers making decisions are provided with an assurance about the technical aspects of the decision making.   

What does it Look Like?

The change process can be made to look a lot more complex than the diagram below

When a request for change is made, the first decision is to decide whether it should go through the normal change process. The three types of requests that wouldn't need to are

1. Standard Change - already pre-approved to proceed (by way of a one off approval for regualrly repeated tasks)

2. Emergency Change - something needs to be done quickly and generally there is a fast-track process which makes sure the people in the right level of authority sign it off quickly

3. Other Requests - generally come through the wrong channel from Request fulfillment, you want to order an approved software addition e.g MS Visio where only the cost of the addition needs to be approved. These aren't changes, they are in effect a variation of a standard change as the software has already been tested to work on the desktop it is just not routinely provided for everyone for cost reasons. Sopme organisation treat these types of request as change requests, the danger is that actaul chnage gets buried in the day to day request traffic.

The change process then can be summarised as follows

Once it has been determined that the request is a change the next decision for the cnage manager is who gets to approve it. This is generally where a risk model os applied based on risk times the likilihood of the risk occurring.  Another factor that needs to be considered is how many services doe the chnage impact on, of course it would pay to have a service catalogue and SLA's to help make the decision here.

Of course the decision framework shouldn't be decided on a case by case basis, starting at the Executive leadership team you should have an approved governance system that allows for most decision to hit the right level. This is where an experienced Change Manager helps, they become familiar with systems and service, and can slot most decision required to the right level, or go and check out any that are borderline.  

Many organisations don't consider the pre-development approval to be a change request, rather that is governance. The change process should be initiated before development starts and track the change through the development lifecycle. Changes should be recorded in the CMDB, or at the very least the current status of the change should be recorded in the change management system. Without the status the current approval for any given change is not easily found out, and people may work on unapproved changes wasting time and potentially creating the risk that an unapproved change will make it into production. Most people who have worked in IT long enough can think of a small change that had a major impact because someone didn't think it important enough to advise change management about. Change management can't prevent all issues occurring, but it van give your incident management a good chnace of finding what caused an outage much faster.

Common Mistakes

1. Treating all change as a project responsibility and leaving approvals to a steering committee

2. Not choosing the right level for approval, either too much goes to senior managers or not enough, the former means they delegate important decisions and therefore don't get to see the things they should, the latter creates the same situation by not forwarding the correct issues for decision

3. Not communicating decision to other levels, probably one of the single biggest sources of concern, A senior team may make a decision but their decision s never circulated to any of the other levels. 

4. Not communicating decisions upwards so that managers understand the risks of proceeding. This is one of those situations that often doesn't come to light until a serious incident occurs and the senior manager says "Why didn't I know about that?". So applying an approved decision making framework is a key and ensuring everyone understand that framework.