This is the first of a two-part series of articles exploring the often overlooked importance of human factors in IT Change Management.
In this article we discuss the collaborative aspects of Change, and steps that can be taken to ensure that decisions are taken by the business as a whole. The next article focuses on the design of the Change process itself, and the importance of organisational communication.
Overview
Medium to large enterprises heavily depend on technology to deliver products and services. These systems are complex, with applications serving multiple purposes and high levels of interdependency between them.
Because of this, making changes in the technical space can be difficult. A software upgrade to a server operating system, for example, may impact an application that it hosts. In turn, the affected application could be depended on by software running in the cloud.
Change Management is a discipline that seeks to mitigate this complexity. Organisations adopt change processes to exercise control over how and when changes are made, manage the risks associated with them, and be prepared for when things don’t go according to plan.
While Change Management is fairly ubiquitous in most medium to large organisations, we have found that they tend to focus primarily on digital processes and technologies, with less emphasis on human factors. This is problematic because any modification not only involves business personnel directly, but the most significant impacts are when end users are affected.
By taking a human-centred approach we can address this gap by prioritizing the needs, experiences, and feedback of the individuals involved in and affected by change processes. We argue for the incorporation of design principles such as cooperation, communication and user experience analysis to achieve this, and that this will result in a more robust and pragmatic approach.
The Change Advisory Board
ITIL advocates for collaboration and visibility across teams and a culture of shared responsibility. For this to work there must be an agreed, shared understanding of how the business delivers its IT strategy.
This is because a single team operating in isolation may have many competing priorities with other parties' concerns. Typical examples of this are the trade-off between user experience and cybersecurity, or the balance between network demands and infrastructure capacity.
Businesses often drive collaboration through a Change Advisory Board (CAB). The CAB is a group of key stakeholders in areas from across the business who meet regularly to discuss and approve planned changes, and to review changes that were introduced since the last meeting to deal with an unplanned outage or issue.
Run a Technical CAB as well
CAB meetings can be highly technical, so to ensure that discussions are relevant to all stakeholders many organisations will operate a CAB as well as a Technical CAB (TCAB).
The TCAB's role is to review the technical aspects of a proposed change more granularly. They will meet before the main, business-wide CAB, to which they will provide a set of recommendations. The overall decision on each change rests with the main CAB, who are charged with ensuring that the associated costs, risks and complexities fall within the overall IT strategy for the entire business.
Some members of the TCAB should attend CAB to provide technical clarifications if required. Whether they have voting rights in both TCAB and CAB is an individual business decision.
Drive collaboration
An effective CAB is designed so that all participants can contribute. Here we list some approaches we’ve encountered that have proven effective in creating a collaborative CAB.
Hold CABs regularly
Bi-weekly meetings are common, but this depends on the cadence of change that occurs in the business. If meetings are more frequent than they need to be attendance can drop off as they aren’t seen as being an effective use of stakeholders’ time.
If they are too infrequent then Change Management can become sclerotic, IT isn’t able to react quickly enough to business needs, and (in some cases) individuals may begin to circumvent the system entirely and introduce untracked changes.
CAB meetings should be actual meetings.
We have seen a few cases over the years of organisations trying to implement CAB decisions within change management workflows, skipping the meeting entirely. These solutions replace the CAB meeting with a set of approval tasks sent to stakeholders via email.
While this does provide a convenient way for CAB members to respond to approvals on their own time, it has serious drawbacks:
the collaborative aspect of the CAB meeting is effectively lost
individual stakeholders, particularly when they have a high workload, may just approve or reject changes without proper consideration, and
in some cases, stakeholders might not respond at all – particularly if they are on leave – delaying the entire process.
Rotate the CAB chairperson
This is a very effective way of ensuring engagement from all parties. If a stakeholder knows that they will be chairing the next meeting, they are incentivised to focus on the issues raised in the current meeting.
Furthermore, a rotating chair promotes the view that the CAB is owned collectively, and has shared responsibility.
Conclusion
In any complex organisation technical changes can impact multiple areas of the business. For this reason it makes sense that decisions around those changes are owned by stakeholders from the entire organisation. There is a tendency to look for technical solutions to improve change processes - for example, a more detailed workflow, or an automated method for conducting risk assessment. These are all valid and necessary. However, Change Management is by it's nature a group effort. Therefore, human factors which govern behaviours around collaboration, decision making and communication are critical aspect to consider when driving improvement.