4 Maturing change management (phase 2)
“Any intelligent fool can make things bigger, more complex … it takes a touch of genius – and a lot of courage – to move in the opposite direction. Ernst F Schumacher”
The challenge we face in maturing change management is how to do more with less (rather than doing more by adding unnecessary complexity). The essence of an effective change management programme is achieving the objectives while keeping complexity to an absolute minimum.
Where complexity is required, it must be thoroughly weighed against the business value it creates, while considering alternative means of achieving the same outcome(s) in a less convoluted way.
Simplicity is the operative word and must be kept at the forefront of change management adoption.
The basic change management programme described in the previous chapter must be handled carefully to avoid the pitfalls that so frequently accompany too much focus on process and too little attention to the business outcomes.
In phase 2, we’ll focus on optimizing business value by:
• Proactively managing the change lifecycle (including integration with project management and IT governance)
• Shifting the focus onto the achievement of business outcomes
• Optimizing the effectiveness and efficiency of the change process.
4.1 Maturing a basic change management programme
This section applies as much to a newly adopted basic change management programme (as described in Chapter 3) as it does to an existing change management effort. The aim is to build a change capability that’s constantly improving to meet ever-changing business needs. Many organizations, however, already have a change programme similar to the basic one and, too frequently, even a programme that has not stagnated becomes bureaucratic and ineffective over time. When bureaucracy starts settling in, cultural dissatisfaction and resistance are not far behind, and you risk losing the momentum your change programme once had.
In this chapter, I’ll describe how to maintain or regain momentum from phase 1, and increase the effectiveness and efficiency of your change capability.
4.1.1 Governance compliance
Corporations and public agencies operate under regulatory and governance compliance requirements. Though specific requirements vary depending on the country, size and nature of the enterprise, the ability to demonstrate effective control over the IT systems that underpin the organizational business is important.
The Sarbanes-Oxley Act and Health Insurance Portability and Accountability Act (HIPAA) are two US examples of laws with strong control requirements. Other countries and industries have others and more are being enacted regularly.
The degree to which your organization must demonstrate regulatory compliance must be understood. A central theme emerges: organizations must be able to demonstrate management of IT changes that include current (up-to-date) process documentation and logs of process compliance audits.
This single factor requires a formal lifecycle approach to managing changes. A last-check, IT-centric change programme is not sufficient to demonstrate effective change control and may not be fully compliant with regulations or laws.
Regardless of the specific requirements to which your organization may be subject, effective change management requires that changes are:
• Documented
• Evaluated for risk
• Prioritized and authorized by management
• Able to be escalated as emergency changes
• Tracked and reported.
These should be accomplished as efficiently as possible, of course, but compliance must be auditable – meaning, there must be documented evidence of the activities.
4.1.2 Change in scope and configuration management
In phase 1, the scope of change management is somewhat vague but generally understood to be any changes that could have an impact on the IT services used by customers. Because we focused on the introduction of the concept of change control, it was more important to start with the addition of formal management of changes.
As change management matures, it will become more important to have a clear and consistent understanding of the increasing scope.
Change management is closely tied to configuration management. Configuration management supports change management by providing a logical view of the infrastructure. It allows change management to answer a question such as: What configuration items (CIs) are impacted by this change? Understanding all the components of an IT service, their current state and how they are related to each other is a powerful enabler of effective change evaluation. Without configuration management, change management must rely solely on design documentation and the memories of the IT staff who built the system. Both of these have practical limits.
On the one hand, with effective configuration management the scope of change management is quite clear – if it’s in the configuration management system (CMS), all changes must be managed by change management. On the other hand, without configuration management in place it’s a bit more challenging, but the goal is the same – if it could impact on a production IT service, then it should be under change control.
Obviously, configuration management is beyond the scope of this publication, but it’s worth noting that it’s difficult to move beyond the basic change programme described in Chapter 3 without effective configuration management. (It’s also worth noting that change management must update the CMS to reflect approved changes.) Obviously this requires change management to know which components (CIs) are associated with any requested change and how, specifically, they are being changed.
The short story is that all IT services that support business processes and all the components that underpin those services must be documented (in the CMS), and changes to them must be managed through change management.
While this may sound a bit academic, it is an important distinction that links to the reason why we manage changes in the first place – to support business outcomes. That being the case, any changes to infrastructure components that are associated with business-supporting systems must be managed to ensure that the required levels of security, availability and integrity are maintained. Analysis of how any given change may impact on other parts of the infrastructure and/or IT services is an essential element afforded by effective configuration management.
Are changes in development and test environments subject to change management?
A common question around change management is, ‘Do changes in development and testing have to go through change management?’
The question demands further clarification. The development and testing environments are critical to the effective validation of changes supporting business functions. So, yes, changes to those environments themselves are clearly under change control. But if the question is, ‘Does change management need to review and approve changes (being developed) moving through the development and testing environments?’, then the answer is no.
The entire development process is itself a business process, making the infrastructure upon which the development process is conducted a production environment.
Further, development and testing must be rigidly maintained such that they accurately reflect the production environment, otherwise testing conducted there is not an effective validation of performance to be expected in production, which increases the risk to the business of changes.
Either way, the change policy should make the scope for change management clear. Note: as the change management matures, the scope of the process may be updated, too. As the scope changes from the basics discussed in the previous chapter, it is critical that the updates are communicated.
4.2 Phase 2 goals
You’ll recall our goals in phase 1 were:
• Introduce change control
• Show early results
• Ensure cultural adoption
• Manage the IT environment
• Set the stage for future maturity.
These are carefully chosen to maximize the likelihood of a successful platform upon which you can mature the change management capability.
With these secured, we’ll be adding some additional elements that will maximize both business value and effectiveness in managing IT changes.
Phase 2 goals are:
• Manage the change lifecycle by:
• Effective and efficient management of changes
• Demonstrating appropriate governance
• Maximize business outcomes
• Optimize change management.
4.2.1 Manage the change lifecycle
One of the significant limitations of a phase 1 change process is that it is entirely reactive. The only task is one of inspection after the planning and development work has been completed and before the change is deployed. This last-check-only change process causes staff to view change management as largely ceremonial, focusing exclusively on the communication of changes that are already happening – as opposed to a control process whose function is to actively manage all changes.
Although there is some value in this approach, it is limited by its exclusive reliance on direct inspection of all changes. In other words, change management has no ability to affect the quality of changes outside of reviewing those brought to the change advisory board (CAB) after the development work is complete. It also has no ability to reject changes that might be wasteful, risky or unnecessary before any work is started.
This is an important point for maturing change management – breaking the paradigm of the CAB (and with it change management) from a reactive-only review board to one where requests for change (RFCs) are evaluated before any work is authorized or started.
4.2.2 Maximize business outcomes
Managing the change lifecycle and optimizing the change process are not only the logical next steps in maturity, they are integral to achieving it. This includes consideration of the business outcomes that a change is intended to support, not after the implementation but before it is authorized to proceed into development. This change-approval/work-authorization responsibility is an entirely new aspect of change management, although one in which many IT organizations never engage. I believe this omission is the single greatest reason why change management is widely viewed as a bureaucratic process that slows down delivery.
By contrast, I contend that achieving business outcomes is the core of effective change management. The goal must be for change management to be an organizational (not simply IT) capability that ensures that changes produce the results the business requires. Anything less is a misuse of organizational resources and should be challenged by organizational governance (senior management, boards of directors etc.).
This means the RFC and those reviewing it must address not just the technical and logistical aspects of a change but also the expected business results – the outcomes that the business is hoping to achieve.
4.2.3 Optimize change management
‘Optimize’ can mean many things to many people, so perhaps it’s best to start with what I mean by the term. I see it as finding the right combination of operational practices to produce peak business value, at the same time keeping costs in the form of labour and delayed realization of value to a minimum, and with no unnecessary process bureaucracy.
The next chapter is dedicated to optimizing change management. At this point, suffice it to say that what we’re trying to achieve with the addition of the pre-development checkpoint is to strike a better balance of process and outcome, while managing business risk.
I cannot emphasize enough that adding this checkpoint must be carefully managed so it does not become a no-value step that just slows down progress and causes resentment.
The tale of bad water
The old story goes that a certain town had great-tasting drinking water that came directly from a clean river that originated from the nearby snow-capped mountains. The town took great pride in its water.
One day, however, the water started to taste bad. Rumours went around that it might even be dangerous to drink. The town’s water treatment plant was fitted with expensive filtration equipment, but the water remained undrinkable.
Consultants were then hired to analyse the problem. They concluded that the treatment plant required significant upgrades to restore the town’s treasured water quality. The town council considered their options.
One day, a young man out walking saw a dead moose in the middle of the river. Not long after he’d returned home and told his parents about it, a group of townspeople went out and, with much effort, removed the dead animal from the river.
Not long after that the town’s water was crystal clear and tasted great once again.
The moral of the story?
Sometimes you need to go upstream and remove the dead moose from the river.
4.3 Phase 2 process
In phase 2, we are moving upstream, if you will, adding an extra checkpoint before development work actually begins. This pre-work review allows change management to expand its focus on the end-to-end change lifecycle. Figure 4.1 shows the simplified view of the newly added step.
This new checkpoint is achieved with the same CAB described in the previous chapter but with some key differences. The most notable is that change management becomes the actual authorizing agent for development work to begin – nothing can start until an RFC has been approved.
Figure 4.1 Expanded basic change process flow
In organizations with a strong project/portfolio management capability, this function may already be performed to some degree by the project management office (PMO). If you’re fortunate enough to have effective project governance, this additional CAB function should be integrated with the work the PMO is already doing. In this case, the PMO may give the approval for the project, taking into account financial analysis (return on investment (ROI), net present value (NPV) etc.) as well as business prioritization and portfolio optimization.
If your organization follows the systems development lifecycle (SDLC) methodology, you may recognize the phases. In phase 2, we’re inserting a CAB checkpoint between the SDLC design and build phases, as shown in Figure 4.2 (shown also is the previous post-development CAB between testing and deployment SDLC phases).
As you look at inserting this new CAB point, be mindful of how it intersects with other processes, especially IT governance and project management.
RFCs are reviewed for technical and logistical details to ensure the proposed change:
• Is likely to achieve the stated business outcomes
• Adequately addresses risks
• Is unlikely to have an adverse impact when released.
Figure 4.2 Phase 2 change and systems development lifecycle
Expanding the CAB role
Unfortunately, reactive-only change management is so prevalent that many IT people work their whole career without ever imagining that change management has any role other than the final check before going live. For them, it feels like an enormous overreach where change management exceeds its rightful domain and meddles in the planning and development process.
You’re asking people to literally rethink everything they’ve known about IT delivery and change management, and it’s important to not underestimate the scope of the change this new role presents.
People with a ‘traditional’ view of change management are much more likely to resist process additions that they think are irrelevant, produce no value, disrespect staff expertise and add bureaucratic bloat. In their minds, such additions are contrary to delivering business results, so introducing change in a heavy-handed way (especially when staff believe the current process has been serving their needs quite adequately) could provoke awkward debates and prove unproductive.
This is why it is important to focus on outcomes over process. Start your change maturity programme by communicating the goals, which now include maximizing business outcomes. This is a goal with which it’s hard to disagree. Starting from a point of agreement on goals is important for getting the IT culture to buy into these process additions.
As with all good communication, you want to start with a solid reason why you’re making changes to the change management process. Considering why, and what’s in it for them, is fundamental to gaining cultural support for changes.
This new checkpoint greatly expands the role of change management beyond its traditional ‘do-no-harm’ final check.
Many change management programmes become stymied at this very point, and the longer you remain at the phase 1 level, the harder it is to move into phase 2 maturity.
Crossing over can be a challenge that has more to do with people and organizational culture than with process.
The keys to success are:
• Careful transition planning
• Gaining an understanding of and enabling integration with existing planning and governance
• Clear and consistent communication of what’s changing and why
• Clarity in (especially new) roles and responsibilities.
Where there’s significant cultural resistance, or lack of management support, organizations tend to compensate for immature change management by offloading this critical review process to other areas, typically development or architecture teams.
The upstream roles must work very closely with the rest of change management for the entire process to be effective. The task of consolidating the change-related functions performed in other locations into a more central change management capability is likely to produce more initial resistance than value.
Keep in mind that this second phase expands the focus to include business outcomes versus just the test and review that was part of phase 1, but don’t attempt to turn it into a monolithic change management process. If the functions being performed elsewhere meet all or part of management of change lifecycle, keep them.
Recall W. Edwards Deming’s insistence that quality cannot be inspected into the process; it must be part of the overall change management flow. The sooner an error is detected and corrected, the lower the cost and risk to the organization. By introducing this next stage of maturity, change managers are in a position not only to review and validate proposed changes before development work begins, but also to be involved throughout the lifecycle of the change.
Change lifecycle
All changes have a start and end point. In IT service management (ITSM), we refer to the end-toend process as the lifecycle of a change (or a service). The application of an end-to-end approach is one of the ways to improve delivery of business value The lifecycle starts the moment an idea for a new or changed service is communicated and carries on through the entire effort to bring that change to fruition.
Although the change is theoretically completed once it is implemented and producing the value the business needs, in reality there is no real end. Services in production must be continually improved to meet ever-increasing business needs. Over time, previously released changes peak and fade, new changes emerge, and the lifecycle continues. It can be thought of more as a continuous flow than as a static point in time.
Effective change management must accommodate changes of all sizes and types and that come from multiple sources, such as:
• Continual service improvement (CSI) efforts
• Incident-driven changes to correct issues
• Business-driven changes to support business outcomes, such as:
• Bringing in new IT services
• Adding functionality to existing IT services
• Maintenance and upkeep.
Each of these requires different levels of change management oversight, but all must be effectively managed.
The view of changes from a lifecycle perspective is a departure from the traditional understanding of change management and is one of the key points that must be carefully communicated for a successful change programme.
Once an RFC has been raised, and initial requirements have been gathered, it’s time to draft a proposed solution to meet the requirements. The plan should be documented in enough detail that it can be understood and reviewed by technical staff and IT decision makers. In this context an RFC can be viewed as a business case for the requested change. As such, it becomes a decision support tool that should include information about rationale, costs (which may include development and operational cost estimates, NPV and/or ROI analysis options). Of course, as in phase 1, the RFC includes all regular information, including expected business outcomes.
The CAB reviews the RFC. If and when it is approved, the development team(s) can be authorized to begin work.
When development and testing are complete, the RFC is brought back to the CAB, where it is reviewed for potential production release. This review ensures that the required results described in the proposal have been effectively met by the solution developed.
If approved for release, the change is then implemented in production and enters a stabilization period. When the acceptance criteria are met, and the business has accepted the change, the CAB does a final review, at which time the change is declared complete (and successful), and the RFC is closed out.
4.3.1 Process flow
In Figure 4.3 we take a more detailed look at the change lifecycle. We’re adding a single new process step – engaging the change management process from the very beginning of the change lifecycle. Regardless of how formal, every change has some form of requirements gathering and planning – this is basic to project management and required for a successful development process.
All the information gathered in the early requirements and design phases is documented in a change proposal that is presented to the CAB for review before work begins.
Change proposal
All significant changes should be documented in an RFC that is submitted to change management. The RFC must include a high-level description of the proposed change, which might be a new service, a significant change to an existing service, or decommissioning of a service. Especially important is the inclusion of the desired business outcomes, which should be described in sufficient detail that their achievement can be demonstrated through quantitative measures.
Depending on the organization, RFCs may include a business case that addresses the relevant business issues, risks, and considered alternatives (see Appendix C).
The proposal should also describe a high-level schedule so change management can assess the impact of this change on others in development.
The proposal should include a functional block diagram of the proposed solution, noting new and existing components and how they must be adapted to support the new change.
Requests for smaller changes, such as server and infrastructure patching and operating system upgrades, generally include a before/after state diagram and description, along with a high-level plan of how the change will be implemented (phased in, all at once, regional roll out etc.).
Figure 4.3 Phase 2 change management process flow
4.3.2 Phase 2 CAB
Recall that in phase 1, the CAB was primarily concerned with avoiding negative business impact by evaluating developed and tested changes for risks of unintended consequences and logistical challenges. Change management was not involved before the change had been developed and tested, so it’s no wonder that there was very limited ability to avoid issues resulting directly from how the change was developed.
In phase 2, the RFC must first and foremost be explicit on the intended business outcomes. For change management to effectively evaluate the proposal’s likelihood of producing the desired outcomes, they must be clear and unambiguous. To the degree possible, they should be stated in quantifiable terms such as:
• Results where an increase/decrease is measurable. These could include:
• Transaction throughput rates
• Server response times
• Number of simultaneous customer interactions
• New functionality reflected in:
• The number of new use cases
• User interface feature requirements.
When reviewing the RFC, the goal is to think through the proposed solution and identify any potential issues with how the solution is designed. The change proposal must address any business or IT process changes to support the changed service and describe how the proposed deployment will work.
The review needs to be undertaken by well-qualified staff who look at the big picture.
Consider:
• Are the desired business outcomes documented, understood and approved (by the business)?
• What are the risks to the business and/or IT systems (risk of proposed change versus not making the change)?
• Is the proposed change the most effective means of achieving the desired business outcomes?
• What effect will the proposed change have on existing business and IT processes?
• What is the relationship between this change, other changes and existing services with respect to data integrity, performance, system availability and continuity?
• Can the infrastructure support the change (network bandwidth, firewall rules, server capacity etc.)? (Does the change propose additional infrastructure capacity, and is it sufficient?)
• Does it follow established technical and architectural standards?
• Does it introduce new technologies, and if so, are we prepared to support them?
• Does it add unnecessary complexity? (Is there a simpler solution?)
• Does the organization have the knowledge, experience and capacity to deliver the proposed solutions? (Does the proposal describe how these will be accomplished – training, partnerships, consulting etc.?)
• Does the proposal address the business process and cultural transitions required by the change?
• Is the business likely to realize the desired outcomes?
• What is the impact on service?
• What is the impact on customers?
• What is the priority for this change?
• If everything is high priority then nothing really is
• If everything is designated as high priority, this impacts on resource availability and risk. Change management should not approve the RFC without considering both these factors
• Are all stakeholders/constituencies in the change aware and sufficiently engaged to provide feedback?
Change management is intended to be a control, communication and coordination process, with the responsibility (and authority) to ensure that approved changes align with business needs and can produce the desired business outcomes without undue risk to the business. The business must be apprised of related risks and consulted on the acceptable level of risk (of making versus not making the change).
This new step provides a clear separation between change planning, change development and change implementation. In this way, change management is responsible for the control, coordination and communication of changes throughout their lifecycle. At any point in time, change management must be able to articulate the current state and progress of all changes under consideration.
Once the CAB has completed its initial review, the change manager will ensure that the appropriate authority either approves the change to move it into execution (build) or rejects it for further planning.
As in phase 1, following development and testing, the change returns to the CAB for a final review before authorization to release into production is given.
This post-development review can now focus on the following questions:
• Does the change achieve the stated business outcomes? (Does the testing verify it?)
• Has the build and test process identified any additional risks, and have they been addressed?
• Is the business ready for the change at the proposed time? (Has there been effective communication?)
• Is the implementation plan realistic and complete? (Are IT staff trained and prepared for a successful implementation?)
• Does the test plan appropriately validate the change success, the continued stability of the service and the acceptance criteria defined in the change proposal?
• Is the roll-back plan realistic and complete? For major releases, has the roll-back plan been tested and proved capable of restoring the pre-implementation state?
• Are there any conflicts or risks associated with the targeted change window?
4.3.2.1 CAB membership
In this second phase, we’ll add some more CAB members:
• Business relationship management
• Service and process owners
• Business representatives (may vary with the RFCs under review).
With the focus on business outcomes, business representatives and relationship management are important to include in change review. Service and process owners are included because process changes are within the scope of change management, and process owners are ultimately accountable for how their process meet the needs of the organization.
These new members have the same collective responsibility to evaluate proposed changes using their knowledge, experience and expertise.
4.3.2.2 Formal change evaluation
In cases of major changes, or where complexity or risk is particularly high, the change manager may commission a formal change evaluation process. This evaluation can be performed by a team of specialists with the appropriate skills and background to conduct an in-depth analysis of the proposed change. The services of specialized consultants and representatives from key vendors, partners and component providers may also be engaged.
The end result is a formal report detailing the findings, identified risks, and risk analysis, and may include recommendations for risk mitigation or compensating measures to be included in the change development effort. The report is provided to the change manager and typically reviewed at a CAB meeting.
4.3.2.3 Emergency changes
Emergency changes are intended for circumstances where the company is facing dire circumstances – significant risk to the organization that requires immediate remediation. Emergency changes are one of those governance and compliance points where the process must be well-defined and documented and followed consistently in normal operations.
It is important that the intensity of the situation surrounding emergency changes does not derail the documented emergency change process. Although the rules of engagement are different when there’s a major incident that requires an emergency change, the requirements for effectively managing changes remains the same.
With that said, a common approach in organizations that have strong incident management is for the incident manager to work closely with the change manager to facilitate timely review of emergency changes.
All emergency changes are still subject to tracking through the normal RFC tool, reviewed by the eCAB (or some other form of review), and are ultimately approved by the appropriate change authority. Urgency, and even dire situations where the business is at significant risk, do not justify violation of change authority.
Good practice is to leave such emergency changes open through a stabilization period. If the organization requires post (major) incident reviews, the results of that review would come to the CAB and be included in the CAB review of the implemented emergency change, ultimately leading to the normal change manager approving the closing of the emergency change.
These pieces can be accomplished in various ways, but keep several good practices in mind:
• Full delegated approval authority can be granted to a major incident manager.
• The scope of delegated authority is limited to changes directly related to remediation of the major incident.
• Full delegated approval is valid for the life of the major incident, and is withdrawn at the resolution of the incident.
• Emergency changes should be tracked using the same tracking method as all other changes, and with the same expectation of the level of detail. (Moments of crisis can present elevated opportunities for errors and oversights that can have far-reaching impacts on the organization. Such changes should be handled at the highest standards, not the lowest.)
• Emergency changes should be reviewed by the normal CAB process after the fact (this is especially important for authorization of CMS updates).
For organizations that adopt this form of emergency change delegation, there must be complete clarity in roles and responsibilities for both the change manager and the incident manager in these circumstances, and it should be spelled out in the change policy.
4.3.2.4 RFC status tracking
One additional clarification on the role of change management – the change manager (in conjunction with delegated approvers) approves the updating of the status of changes as they progress through the workflow. This is important because, first of all, change management is responsible for managing the lifecycle of changes. Secondly, changes must meet certain criteria before their status is updated. Change requesters and implementers communicate the progress and status of changes in implementation, and the change manager must determine whether the criteria for a change of status have been met.
The results of an implemented change will generally fall under one of the following statuses:
• Successful/implemented Successful changes are pretty straightforward. The change was implemented with minimal deviation from the documented implementation plan and has met the acceptance and stabilization criteria.
• Rolled back Changes can be rolled back for numerous reasons, including that important issues arose during implementation requiring significant rework of either the implementation plan or the change itself. Another reason would be that the implementation could not be completed during the approved change window and continuing with the work beyond that would disrupt the business.
All RFCs must have a realistic, documented roll-back plan, which should state what decision-making authority the business is granting to the change implementer for roll-back determination. This ensures that all changes attempted will either be successful within the defined change window or rolled back, according to the documented plan and with no harm to the business.
In many cases – especially with major changes – the business stakeholders may choose to be directly involved with the decision to roll back or continue in the face of issues. At their discretion, the business may approve less-than-optimal results in preference to rolling back (and forgoing the value the change brings).
Rolled-back changes require change management and all change stakeholders to understand why they occurred and to ensure that the underlying issues are addressed before the change implementation is attempted again.
• Failed Not all organizations differentiate failed changes from those that are rolled back, and I see little reason to build an arbitrary distinction here; however, ‘failed change’ is a common phrase, so let me at least address it.
In my view, a failed change is simply one that hasn’t gone as planned, or isn’t producing the results expected. As I mentioned earlier, the business can choose to accept an underperforming change if it believes that the business value is greater than the negative impact. In such a case, the change could be classified as having failed, but the decision was made to not roll it back (at least not at this time).
Alternatively, a change could be so damaging that it must be rolled back; in which case, it’s a failed change that’s been rolled back.
The most important thing is that the organization has clear definitions for change outcome categories. Also keep in mind that, while it’s beneficial to use such definitions consistently with the best-practice recommendations, it is more important that they serve the needs of your company.
Achieving business outcomes
In a manner of speaking, a last-check CAB (as described in the previous chapter) can be viewed as playing to ‘not lose’. In other words, the best a reactive-only change programme can do is avoid obvious implementation problems and disasters.
Managing the lifecycle, on the other hand, is ‘playing to win’. The whole point of managing IT services is to support the organization with services that maximize value while managing risk and minimizing negative impacts. Any change that falls short of achieving optimal business value is a poorly managed change.
There are a couple of implications here that may not be obvious. For change management to ensure business outcomes are achieved, the desired outcomes must be documented as part of the RFC. Further, business outcomes are determined by the business, and it is unwise for IT staff to make assumptions about what they may be generally, or in particular, for any given change.
Extortion changes
I’ve seen changes allowed to go into production with known issues simply because ‘so much time has been invested’ and ‘the business needs it now’. Had the proposed changes been reviewed before building, many issues could have been avoided altogether.
I’ve also seen unplanned infrastructure changes made literally at the last minute, because an implemented change was incompatible with another component (i.e. the new application wouldn’t run on the version of the operating system that was being used, necessitating an urgent upgrade).
I call these ‘extortion changes’, and they pose significant risk because they typically bypass normal planning, testing and review. They can also cause collateral damage to other services, causing a cascade of unplanned changes in production.
These types of change are particularly dangerous without configuration management in place, as the trickle-down effects to other services may not be identified until days or weeks later, when the initial change has been long forgotten. This makes it hard for support staff to identify the issue because the extortion change was made in haste and poorly documented.
This is not good practice in change management, though it may be common in some environments.
A second implication is that specific, non-ambiguous measures must be established to enable change management to determine whether a change has achieved the desired outcome(s). Change management must fully embrace this role and not default to the technical and logistical details only. Again, this is the essence of mature change management.
Stabilization period
After a change has been implemented, it should remain open in some fashion until the acceptance criteria have been reviewed and demonstrated to be complete. The stabilization timeframe should be defined in the change proposal, along with the acceptance criteria. For example, it’s not uncommon to define target numbers of post-implementation incidents or business transactions to be processed. During this period (also known as early life support or warranty period), change management still has jurisdiction over the change. Therefore, should significant issues arise, it is the role of change management (in conjunction with the incident manager) to determine whether to roll back the change as per the roll-back plan in the RFC or see if additional changes are required that will successfully address the issue.
Once the stabilization timeframe and criteria have been met, with an acceptable number of incidents, the CAB will review the change, along with test results, incident trending reports and any other meaningful demonstration that the change has met the defined acceptance criteria.
What if the change can’t meet the acceptance criteria?
In some cases, a change is implemented and the established acceptance criteria are never met, or the change may not produce the desired business outcomes. Does that mean the change was unsuccessful, rolled back, or failed? In these cases, there are several choices. Which is appropriate depends on the needs and desires of the business.
Accept ‘as is’
The business can decide to accept the change as released, noting that it didn’t meet certain criteria. If the issue causes service degradation or downtime, the business can decide if the downtime (and any associated workarounds) is acceptable, especially if the change has critical value that outweighs the negative impact.
This may be final, or the missed requirement can be prioritized for a future release. If the latter is chosen, the change should be considered successful, and the missed requirement will be carried forward in another change.
Roll back
If a criterion is not met that is significant to the business, it may choose to roll back the change until it can be reworked and released again with assurance that the missed requirement is met.
For organizations with a strong release capability, this may be little more than rejecting the current release, with the expectation that the next scheduled release will provide the required functionality.
Conditionally accept or reject
Lastly, the business may conditionally accept (or reject) the change and draw up a plan for remediation of noted issues. This may be in the form of a service improvement plan or simply as something to be addressed in the next release. A conditional acceptance constitutes a commitment of time and resources to address the issues. To maintain credibility and support, such commitments should be carefully considered, and always followed up.
Post-implementation review
Depending on the size and strategic nature of the change, a post-implementation review (PIR) may be conducted. This is standard practice in project management, and if a change is managed as a traditional project, this will be done under the project management office (PMO).
For smaller changes, this is carried out as part of the CAB review to close out the RFC. Not every change requires a full PIR, and it’s a good idea to identify criteria in the change policy.
The culture of the organization will dictate the format and requirements of a PIR, but at a minimum, it should address the following questions:
• Were the stated and agreed outcome requirements met?
• Is the new/changed service operating as expected?
• Has the change been successfully documented and communicated to the support teams?
• Are there any open issues that could impact on the operational stability of the change? (How will they be resolved?)
• What went well?
• What could have gone better? (Are there specific opportunities for improvement that should be implemented in the organization?)
• Are stakeholders satisfied with the outcome of the change?
4.4 Metrics/KPIs
As before, critical success factors (CSFs) and key performance indicators (KPIs) should be carefully chosen to measure the specific needs of change management in the adopting organization.
Below are some examples of metrics that focus on measurable aspects of this second phase, and is in no way exhaustive.
• CSF 1 Ensure efficient use of IT resources
• KPI 1 Increase in changes completed within estimated time and resource usage (number and percentage)
• KPI 2 Decrease in urgent and emergency changes (number and percentage)
• CSF 2 Ensure effective management of change-related risk
• KPI 1 Decrease in changes rolled back, failed, or requiring remediation
• KPI 2 Decrease in unmanaged changes (number and percentage)
• KPI 3 Decrease in differences between approved infrastructure state and CMS
• CSF 3 Improve effectiveness of the change management capability
• KPI 1 Increase in changes that deliver agreed outcomes (number and percentage)
• KPI 2 Increased satisfaction for change management expressed by PMO and customers.
4.5 Chapter 4: key concepts
The key concepts in Chapter 4 can be summarized as follows:
• Change management is engaged at the beginning of the change lifecycle.
• RFCs must be authorized prior to beginning development.
• Completed and tested changes are brought back to the CAB for post-development review before release.
• Metrics that monitor efficiency and effectiveness are established.
• Clear and consistent reasons for changes are communicated to change management.