IT Change Management Stakeholders: The Complete How & Why of Identifying & Analyzing

Introduction: Why are stakeholders important?

Stakeholder feedback into Continuous Improvement Practice is the best and fastest way to transform Information Technology (IT) into a strategic asset for your company.

This article focuses on examining ITIL® Change Management stakeholders, who they are, the analysis of them, and why it is important, and the countless opportunities to gain insight into what to improve from stakeholder feedback.

What is the definition of key stakeholders in IT change management?

Definition: "Any person or organization that has an interest or involvement in an organization, product, service, or practice."¹

Sources of Stakeholders

The following is the best practice core of the ITIL Change Management Practice to identify sources of individual or organizational stakeholders:

• It begins with the Requester of the Request for Change (RFC), which could be for themselves or a group. The Requester is the first person you should contact as your stakeholder. They will always give you a list of business stakeholders.
• The Change Manager receiving the RFC reviews it for accuracy. Change Managers know who wants changes and how easy they are to work with. This person is your second point of contact.

Once the Change Manager verifies that the RFC meets the change criteria, a Change Authority approves it. There are three change authorities, one for each change type. These people work with business and IT and are another great source of stakeholders.

Not all changes require project management involvement. However, all changes should follow a well-documented project plan and stakeholder analysis.

Change Types

Standard Changes

Standard Changes are the best opportunity for impressing stakeholders. They are preapproved by the change manager. To qualify for Standard Change status, a manager submits a proposal to the Change Manager. Within this one-time proposal are detailed work instructions for conducting the change, technician training logs, history of these changes to demonstrate that it has not caused an incident the last several times, and a written plan for gathering stakeholder feedback after execution. Standard Changes are a perfect stakeholder feedback opportunity. Make sure to conduct a Post Implementation Review (PIR) with the stakeholders.

It is common for best-practice companies to have a goal that standard changes are 80% of changes. Why? Because, they:

• Are frequent
• Are predictable by following detailed work instructions
• Do not fail
• Are good candidates for automation
• Are the most efficient Change Type
• Cost less
• Have higher customer satisfaction potential
• Do not burden the Change Management Practice

Emergency Changes

Emergency Changes are great stakeholder learning opportunities. When they happen, Change Management should require there already be written and tested plans in place to respond quickly. The Emergency Change Advisory Board (ECAB) authorizes, but often with plans and well-practiced routines in place, action to restore is underway before any "official" approval. Since the emergency may impact many users, rapid action can save a significant amount of lost productivity.

One of the ECAB's responsibilities is determining the root cause of the emergency to avoid it happening again. For example, failure to follow maintenance is a common cause. The ECAB should require the collection of not only stakeholder feedback, but a calculation of lost productivity/revenue to help determine the true cost of the outage. This can be a strong incentive for Continuous Improvement.

All emergency changes should conclude with a PIR review that includes stakeholder impact.

Normal Changes

Normal Changes have the most opportunities for stakeholder involvement. They require a project plan and Project Management leadership. The reason Change Management strives to maximize Standard Changes and minimize Emergency Changes is to free up change resources for Normal Changes. It is through Normal Changes that we achieve a strategic advantage for the business. It is also an opportunity to improve efficiency through the feedback the many stakeholders that Normal Changes provide.

In summary, all three change types require an analysis of stakeholders, as each type of change has a different type of stakeholder. Each type of change requires a PIR to gather stakeholder feedback. Stakeholder feedback is the key input for Continuous Improvement.

Identifying the Stakeholders

The Continuous Improvement Practice requires identifying great stakeholders within IT departments involved, suppliers, the business partners and recipients of your change efforts. Below is a list of the ITIL Practices contributing to Change Management, which are also project stakeholders and contribute to analysis, approval, and project involvement:

• Strategy Management: Provides tested strategies, such as collecting the stakeholder feedback and communications plan and strategy.
• Continuous Improvement: Ensures alignment to organization goals.
• Project Management: Assigns teams, manages standards.
• Financial Management: Analysis of budget requests, calculating ROI /TCO, and authorizing project funding.
• Service Level Management (SLM): Provides historical customer service metrics.
• Problem and/or Incident Management: Heavily involved if a change is to correct service performance.
• Service Configuration Management: Ensures that accurate and reliable information about the configuration of services, and the Configuration Items (CIs) that support them. Supports risk assessment and accuracy of the live environment.
• Service Asset Management: Manages the asset register, the key attributes, ownership, and financial value affected by a project.
• Availability, Capacity, Security, and Continuity Management: Ensure warranties meet the requirements of the business.
• Release Management: Ensures that the new or improved service components are ready for deployment through proper testing.
• Deployment Management: Ensures that deployment goes smoothly, that the timing is good for stakeholders, availability of stakeholder training, documentation, and FAQs accompany the change, including the Service Desk and other IT support groups.
• Service Desk: Plays a pivotal role as a single point of contact for users' questions about changes.
• Knowledge Management: Captures lessons learned and is the keeper of knowledge to execute in support of the organization.
• Supplier Management: Sources products and expertise needed to accomplish the project tasks.
• Design Thinking: Guides the practical and human-centered approach that accelerates innovation.
• Business Change Management: Helps ensure that the business is ready to accept major changes.

As you can see, there are numerous stakeholders just within the ITIL Practices, and all of these have their own lists of helpful stakeholders. The purpose of showing the above list is to help create awareness for (1) inclusion into your communications strategy (Strategy Management Practice) and (2) for sources of stakeholder feedback at all levels for continuous improvement (sometimes called Voice of the Customer or VOC).

What is the importance of stakeholder analysis during IT change management processes?

Above, we looked at the stakeholder roles. Identifying them is the first step to understanding them. Understanding them helps a change project manager to communicate in the most appropriate way (they all have preferences we should respect). When your stakeholders feel that you understand them and their individual needs, they feel included in the project and important. They want to help make the change good for everyone, and help you improve!

"One of the most common ways to overcome resistance to change is to educate people [stakeholders] about it beforehand. Communication of ideas helps people see the need for and the logic of a change." John Kotter²

There are multiple times when a project manager needs stakeholders influence:

1. In developing the project vision. The project must have a clear reason for doing what they are doing, and that it is in alignment with the users.
2. At milestones, requesting stakeholder input helps to keep the project on track and keeps stakeholders abreast of the challenges.
3. User acceptance testing. Invite your best stakeholders to be part of the final testing. It will be a great honor.
4. Before delivery, stakeholders should have input into the way that works best for them.
5. After the change, we look to operational stakeholders as the best inputs into lessons learned in the Post Implementation Review (PIR).
6. The more we listen to what they are saying, the more they become loyal stakeholders. Everyone wants to feel appreciated.

What is the stakeholder analysis process?

You can visualize change project management value creation through the steps of the ITIL Service Value Chain (SVC)³

Figure 1: ITIL Service Value Chain

The SVC receives input from Project Management disciplines and ITIL practices. Six activities make up the chain: Plan, Improve, Engage, Design & Transition, Obtain/Build, and Deliver & Support, and each activity interacts with all the others, all the time.

However, the are two other major factors: Value and Demand.

Value (not an activity, but the outcome)

Value is the desired output. It represents the vision at the beginning of the project and may include products and services.

Demand (not an activity, but an input)

At the highest level, the business has opportunities it wants to exploit and Demands for new and improved IT service delivery. This is where it all begins.

How does Demand get attention from Information & Technology?

• Continuous Improvement Register (CIR), where IT collects stakeholder ideas for improvement. This is a fantastic resource for interested stakeholders.
• Strategic meetings between the Relationship Management Practice and business leaders. If you want high-level stakeholders, check here.
• Unsatisfactory operational metrics gathered by Service Level Management (SLM) Practice. SLM has many connections to different business departments. Ask SLM for stakeholders you can talk with.
• Analysis by various ITIL Practices. Ask them who you should contact in the business, as they will certainly know:
  • Continuous Improvement (most common). Who does not want to get better?
  • Problem Management
  • Security Management
  • Availability Management
  • Continuity Management
  • Performance Management

To make all this happen efficiently, Change Management uses Project Management Practice, all the Practices, and various stakeholders for managing the operating model (i.e., SVC) of the key activities to convert the inputs into desirable outputs.

What is stakeholder analysis in IT change management?

To briefly explain the activities is to witness just how many stakeholders it takes to ensure the project runs on time, within budget, and delivers the results the business requires to be a success. See the following summary table for effective stakeholder management:

(This takes place at each activity, and each activity is guided by stakeholder strategy.)

Conclusion: Stakeholder engagement ends up here where Continuous Improvement begins

As noted previously, after completion of all types of changes, best practice requires a Post Implementation Review (PIR). PIRs document whether the project outputs achieved the intended business outcomes and the expected benefits including (1) what went right, (2) what went wrong, (3) stakeholder feedback and, (4) recommendations to achieve better results next time (Continuous Improvement).

When do you perform stakeholder analysis?

Finally, suddenly deciding it is the time to gather stakeholder feedback seldom works as well as planning for Continuous Improvement. Capturing quality feedback takes such planning and building it into all your projects and daily operations. ITIL best practice recommends the Strategy Management Practice define a generic IT Stakeholder Analysis Process, and that all Practices customize for their particular requirements.