Stabilize the Patient and Modify First Response
The goal of a successful Change Management process implementation is to reduce the amount of unplanned work as a percentage of total work done. Organizations that are in a constant firefighting mode can have this percentage at 65 percent or even higher.

The first phase of a Change Management implementation as outlined in the Visible Ops Handbook (a useful guidance and prescriptive roadmap for organizations beginning or continuing their IT process improvement journey) resembles the triage system used by hospitals to allocate scarce medical resources. In a similar fashion, IT must identify the most critical systems generating the most unplanned work and take appropriate action to gain control.

The primary goal of this phase is to stabilize the environment, allowing work to shift from perpetual firefighting to more proactive work that addresses the root causes of problems. Start by identifying the systems and business processes that generate the greatest amount of firefighting. When problems are escalated to IT operations, which servers, networking devices, infrastructure or services are constantly being revisited each week (or worse, each day)?

These items are your list of "most fragile patient" which are generating the most unplanned work. These are the patients that must be protected from uncontrolled changes, both to curb firefighting and to free up enough cycles to start building a safer and more controlled route for change.

For each fragile patient (i.e. server, networking device, asset, etc.), do the following:

1. Reduce or eliminate access: Clear everyone away from the asset unless they are formally authorized to make changes. Because these assets have low change success rates, you must reduce the number of times the dice are rolled.
2. Document the new change policy: keep the change policy simple: "Absolutely no changes to this asset unless authorized by me." This policy is the preventive control and creates an expectation of behavior.
3. Notify stakeholders: After the initial change policy is established, notify all of the stakeholders about the new process. Make sure the entire staff sees it: Email it to the team, print it out, and add it to login banners.
4. Create change windows: Work with stakeholders to identify periods of time when changes to production systems can be made. Your goal will be to eventually schedule all changes into these maintenance windows. Amend the change policy accordingly. For example, Once I authorize the changes, I will schedule the work to be performed during one of the defined maintenance windows on either Saturday or Sunday between 3 and 5 pm.
5. Reinforce the process: By now, you have defined a clear expectation of how changes are to be made. Make sure that people are aware of the new process and reinforce it constantly. For example; "Team, let me be clear on this: These processes are here to enable the success of the entire team, not just individuals. Anyone making a change without getting authorization undermines the success of the team, and we'll have to deal with that. At a minimum, you'll have to explain why you made your cowboy change to the entire team. If it keeps happening, you may get the day off, and eventually, it may prevent you from being a part of this team."

To do this, proper change monitoring must be in place so you can trust, but verify. You will use this instrumentation to detect and verify that changes are happening within the specified change management process, and also to negatively reinforce and deter changes that are not.

You must be aware of changes on all infrastructure that you are managing: servers, routers, network devices, databases and so forth. Each detected change must either map to authorized work, or it must be flagged for investigation.

Critical questions that need to be answered are:

• Who made the change?
• What did they change?
• Should it be rolled back? If so, then how?
• How do we prevent it from happening again in the future?

Create the Change Team
In this next step, you will continue to develop the change management process by creating a Change Advisory Board (CAB), comprised of the relevant stakeholders of each critical IT service. These stakeholders are the people who can best make decisions about changes because of their understanding of the business goals, as well as technical and operational risks.

Create a Change Request Tracking System
A prerequisite for any effective Change Management process is the ability to track requests for changes (RFCs) through the authorization, implementation, and verification processes.

Paper-based manual systems quickly become impractical when the organization is large or complex, or when the number of changes is high. Because of this, most groups use some computerized means to track RFCs and assign work order numbers. Some refer to these applications as ticketing systems or change workflow systems. The primary goals of a change request tracking system are to document and track changes through their lifecycle and to automate the authorization process.

Secondarily, the system can generate reports with metrics for later analysis. Each change requester should gather all the information the Change Manager needs to decide whether the change should be approved. In general, the more risky the proposed change is, the more information that is required.

For instance, a business as usual (BAU) change, such as rebooting a server or rotating a log file, may require very little data and oversight prior to approval. On the other hand, a high-risk change such as applying a large and complex security patch on a critical production server may not only require good documentation of the proposed change, but also extensive testing before it can even be considered for authorized deployment.

Start Weekly Change Management Meetings (to Authorize Change) and Daily Change Briefings (to Announce Changes)
Now that you have identified the change stakeholders by creating the CAB, the next step is to create a forum for them to make decisions on requested changes.

The CAB will authorize, deny, or negotiate a change with the requester. Authorized changes will be scheduled, implemented, and finally verified. The goal is to create a process that enables the highest successful change throughout the organization with the least amount of bureaucracy possible.

While they may seem unnatural at first, with practice, weekly 15 minute change management meetings are possible. Take special care to avoid an attitude of "just get it done," which allows people to make changes that circumvent the change approval process.

If you make it easy for all changes to flow through your process, it will soon be easier to use the process than to circumvent it, even during emergencies. CABs must meet on a regular published schedule that all stakeholders understand. To start, each CAB should meet weekly.

Miscellaneous Change Management Do's and Don'ts
Here are some tips for change management.

Items to do: