What’s Change Management Got to Do with Service?

I’ve got that old Tina Turner song, “What’s Love Got to Do with It?” stuck in my head. It’s annoying. It’s playing right along with a recent conversation with a peer. We were debating the “need” for change management and I declared that it’s all about good service. The peer looked shocked and even offended.

“What’s change management got to do with that?!”

I’m so glad you asked.

IT change management or change enablement, as it is called in ITIL^® 4 has a bad reputation. I think, in general, people in our IT organizations think of change enablement as a bureaucratic, painful process. It can be viewed as a lot of paperwork and “extra” work to just be able to do your job, especially if it isn’t done well. Key words: “If it isn’t done well.”

I think we can flip the perception. Change enablement can be a positive practice in your organization for both the IT employees that participate in the practice and the organization that sees the results of the practice. There are many ways change enablement can help your organization deliver better service. Here are just a few:

Plan Changes

The most basic part of change enablement is scheduling changes. A good change practice will maintain a centralized change calendar in order to avoid scheduling many changes at the same time, scheduling changes that might have an impact on other changes, and then considering the overall organizational calendar.

I work in higher education. In planning changes, we must consider all kinds of things in and around our change calendar. Of course, we consider the working hours of employees, classes, student deadlines like registration, and grade entry. But we also have to think about sports schedules, special events, and even graduation. Bad planning in our environment might impact classes or the ability to sell tickets at a basketball game. Either of those things would be disastrous for our “customers.” The business equivalent would be a change executed with potential impact during a peak usage time for employees.

The last thing we want do is have a system or service unavailable that would impact anything in a negative way during a peak time. Our customers, both internal and external, expect that from us. They need to feel confident that we will look out for them and not impact their working needs. Change enablement encourages good planning and helps us provide good service.

Assess Risks

Risk assessment is at the heart of any effective change enablement practice. Risk assessment is a consistent and clear look at what really will and could be affected by the proposed change. It is important that risk assessment not just be a judgement call of the change submitter. Risk assessment really needs to dig into the change.

We do this with a questionnaire, designed by Andrew Dietz here at Georgia Tech, that assigns values to the responses and produces a “score” that then assigns the risk level. Our risk assessment is as follows with the points for each question preceding the answer. After answering the seven questions the score is totaled and then risk is determined based on the threshold at the end of the assessment.

Question 1: What is the criticality of the service(s) affected by the change?

(1) Business Support: Service failure could result in one or more of:

• Disruption to monitoring, administration or internal support
• Low impact to end-user productivity

(2) Business core: Service failure could result in one or more of:

• Moderate impact to end-user productivity
• Indirect negative customer satisfaction
• Indirect revenue impact to the Institute

(3) Business Essential: Service failure could result in one or more of:

• Significant impact to end-user productivity
• Impact to the Institute’s reputation
• Direct negative customer impact
• Compliance violation
• Direct revenue impact to the Institute

(5) Mission Critical: Service failure could result in one or more of:

• Widespread business disruption
• Public damage to the Institute’s reputation with potential negative media exposure
  

Question 2: Which of the following most closely characterizes the complexity of the proposed change?

(1) Simple procedure, well-tested and repeatable, implemented by a single team, accompanied by detailed documentation

(3) Procedure composed of multiple steps, requires multiple hand-offs, accompanied by generic or minimal documentation

(5) Complex procedure composed of many steps that may or may not have been tested or performed before, requiring considerable coordination with other teams, or backed by unprecise or incomplete documentation.

Question 3: What history best describes the type of change being proposed?

(1) Largely successful in the past

(3) Some issues previously encountered

(5) First time implementing or known to have caused service interruptions or unexpected issues in the past

Question 4: Can the proposed change be backed out?

(1) Yes, the change can easily be backed out and is backed by detailed related documentation

(3) The change may be able to be backed out but not easily, or is not backed by robust documentation

(5) No, the change cannot be backed out, or no related documentation is available

Question 5: What type of impact is the proposed change expected to pose to the service it supports?

(1) No service interruption reasonably expected

(2) Service degradation (i.e., available but not at optimal performance levels)

(3) Partial service interruption (i.e., a component or portion of the service is expected to be unavailable)

(5) Complete service interruption (regardless of duration)

Question 6: Is redundancy available to prevent the proposed change from affecting performance or availability of the service?

(1) Yes, there is redundancy to prevent a service outage

(5) No, there is no redundancy to prevent a service interruption during or after implementation of the change

Question 7: How many users could potentially be impacted by the proposed change if it were to fail unpredictably?

(1) No user impact or a single user

(2) A single team or department

(3) Multiple users, teams or departments

(5) Half or more users in the Institute

Risk Threshold

• Low: 7–12
• Moderate: 13–24 
• High: 25–40

The risk threshold is then used to determine timing, communication, and other key parts of the change. Accurate and consistent risk assessment is another way change enablement provides good service to the organization. I encourage you to use our tool to create your own in order to assess the risk of your organization’s changes.

Identify Major Incident Causes

When a major incident happens, the first place you should look for possible causes is the change records. If you are documenting changes well, this is an easy place to look for the origin of the major incident. From a service standpoint, it may provide a quick solution or a workaround to the issue that has resulted. The change could potentially be backed out. Side note: Any good change request should include a back-out plan.

When a major incident happens, the first place you should look for possible causes is the change records.

In addition to considering change records during a major incident, you should be looking at and reporting on the number of incidents resulting from changes. This metric demonstrates the impact of changes. It gives insight into the effectiveness of testing and the accuracy of risk assessment. It is a way to identify the true “cost” of change. For example, one change could result in 50 incidents that required 10 hours of overtime at the service desk. This is valuable information for leadership and really quantifies the impact. It is just one more way that change enablement can provide good service.

Create a Communication Plan

Finally, and perhaps most important, is that change enablement provides good service by enabling good communication practices. A communication plan should be a part of any change request. The plan should, at minimum, answer the following questions:

• Who are the target audiences?
• What are the specific messages for each target audience?
• WHAT: Describe what the change entails in the simplest and most non-technical terms possible
• WHY: Provide clear and concise statements of the business purpose for the change
• WHEN: State when the change will take place
• IMPACT: Describe the potential and expected impact of the change to people and services
• When will the notifications be sent/posted? Before, during and/or after the change?
• What are the notification methods to be used?
• Is IT operations aware of the change and able to post timely updates to and status posting you provide?
• Is the IT service desk aware of the change so it can be prepared to handle a potential increase in user calls?

Timely, effective, and consistent communication with your stakeholders is key to providing good service. Change enablement should facilitate communication in and around changes. Our IT communications and marketing director is a CAB member. Communication around changes is that important. Attitude is almost everything. Communication is the rest.

An Opportunity to Provide Great Service

I truly believe if we present change enablement, as it is now defined, as an opportunity to provide great service to our organizations, customers, and stakeholders, that it can and will play a big part in our success. Change the dialogue about change enablement. Show your IT organization that change can be part of the great service equation, therefore adding value to an organization instead of being a bureaucratic hoop to jump through.

Now back to the song…

What's change got to do, got to do with it
What's change but a bureaucratic token?
What's change got to do, got to do with it
Who needs a change when a service can be broken?

Vicki Rogers has more than 20 years of IT experience and is currently the Senior Manager of Change at Georgia Tech Previously, she was a senior IT manager at Amtrak and the service desk manager at the University of West Georgia. She has expertise in service management, change management, leadership development, and diversity in IT. She has been involved in service desk creation, implementation, and adoption of ITSM best practices, as well as insourcing IT. Vicki has a BBA in Business Management, an MBA, and an EdS in Learning, Leadership, and Organizational Development. Her graduate research involved cultivating and developing women leaders in higher education IT divisions. Vicki is a regular national speaker on leadership, service management, diversity, and change. Outside of work and school, Vicki is the mom of two brilliant and successful college girls and one very spoiled schnauzer. Follow Vicki on Twitter @vickirogers.