7 Future of change management
“Isn’t it funny how day by day nothing changes, but when you look back, everything is different … C. S. Lewis”
Change management has existed in some form since the very early days of IT, when systems were monolithic and changes were relatively infrequent but well planned. The evolution in change management since then is about doing the same thing faster, within the complexities of modern computing.
With the advent of radically new approaches in development methodologies, change can no longer be the same thing only different – change management must itself change to meet the needs of the organization. The goals for change management remain: they must always be clear and focused on business outcomes.
The goals, again, are to:
• Support timely and effective implementation of business-required changes
• Appropriately manage risk to the business
• Minimize the negative impact of changes to/for the business
• Ensure changes achieve the desired business outcomes
• Ensure governance and compliance expectations are met.
In Chapters 3, 4 and 5, I’ve outlined a practical approach to building an effective change management capability that has a high likelihood of being successful in your organization. I’ve leveraged best practices in ITSM and a proven, common-sense approach to meet these core goals.
But if we take a closer look at the goals, you’ll see that some things have not been addressed. Many things, in fact, such as weekly change advisory board (CAB) meetings, change schedules and lots of things relating to processes. I’ve emphasized the need to focus on business outcomes and not process, and I did so for a reason.
In ITSM, we use the term ‘fit for purpose’ as a way of describing if something is fully suitable for the purpose for which it was designed. We must continually evaluate whether our change capability is the optimal way to meet the specified goals.
No matter where your organization is with change management, you will need to continue to improve and mature it. I’ve shown a multiphased approach in Chapters 3 to 5, and by following it you’ll have a solid change capability. You’ll also have a foundation upon which you can continue to grow with the business.
7.1 A brief introduction to the new methodologies
Traditional application development followed a waterfall methodology, where development cycles could be lengthy, and the objective was to deliver a completely functional application that met the documented requirements. It was called waterfall because the process flowed in a linear step-wise process from requirements and design through development and testing and then to final release. It borrowed heavily from engineering methodologies used to design buildings and bridges. The quality of the result followed directly from the discipline and precision applied to each step, with subsequent steps being built on the solid foundation of the previous step.
This methodology fitted very well with what I will call traditional change management. The relatively brief delay to bring changes to the CAB for review was minor in comparison with their lengthy development cycles. Many corporations still rely on applications developed using this methodology decades ago, but the challenges and rate of change required to support the business has increased so dramatically of late that, quite frankly, change management by and large hasn’t kept pace.
Enter the variety of new development methodologies, most of which fall under the generalized description of ‘iterative development’. While each has its own unique focus, they all share some common objectives:
• More frequent releases of usable code
• Shorter development cycles focusing on the delivery of incremental and agreed functionality
• Higher degree of business engagement
• Higher use of automation (especially building and testing).
Of the many iterative approaches, the ones that are getting the bulk of attention are Agile and DevOps. Keep in mind that these approaches are rapidly evolving, so as soon as this guidance is published, the information will quickly date. However, the implications for change management will remain the same.
7.1.1 Agile
I won’t attempt to do justice to the Agile approach to development. I’m sure those familiar with its use will take issue with my brief summary. However, as the point is to highlight its implication for change management – especially as it has traditionally been practised – I think it serves my purpose. (For a more complete treatment, please check out the Agile Manifesto and related information; see Bibliography.)
Agile is a development approach that seeks to release small incremental units of functional code rapidly. Each release is functional and fully tested, adding incremental and usable functionality to the system (or application) under development. The development cycle varies depending on the organization, but is typically 1–4 weeks. While each increment should be stand-alone, it is likely that multiple increments of functionality will be combined into a single release package. The release rate is aided by using automated testing and build automation.
To summarize, Agile:
• Is a development approach
• Involves small, frequent releases (i.e. iterations or sprints)
• Requires as a minimum the highest-priority functionality to meet customer needs first (minimal viable product)
• Is delivered by a cross-functional team in a short period of time, typically 1–4 weeks (note that this means functionality is delivered is small units).
7.1.2 DevOps
DevOps is similar to Agile in that it features short iterations of development activity, the result of which is the delivery of a usable subset of the required features. It incorporates as a core value the concepts of Lean IT in its relentless pursuit of rapid delivery of business value. DevOps practitioners acknowledge that it is a movement that requires organizational culture to be addressed.
The DevOps approach centres around three core ‘ways’ of adoption:
• Systems thinking (emphasizing the performance of the whole system)
• Amplifying all feedback loops (to improve understanding)
• Embedding a culture of continual experimentation and learning.
It emphasizes the highly collaborative involvement of both applications development and operations staff throughout the development process.
In practice, DevOps relies heavily on automation – in the building and testing processes and self-service infrastructure on demand – as well as during promotion to production. DevOps seeks to create a collaborative culture in which IT and business resources work together to maximize rapid delivery of business value.
A related concept is continual delivery – the idea that any given change can be released as a stable, usable application, and there can be many such releases daily. In this regard, DevOps borrows heavily from Theory of Constraints (Goldratt and Cox, 1990) and views the entire development lifecycle as a continuous flow, where work should flow smoothly ‘from left to right’ (i.e. from idea to business value).
Following these concepts and methods, leading organizations are able to release potentially hundreds of changes per day. Obviously, traditional (CAB-based) change management is ill-equipped to function at this pace, let alone add much value.
7.2 What’s changed; what’s the same
What has changed is the challenges to change management that are associated with iterative methodologies, such as:
• Supporting frequent, small releases
• Integrating automated testing into the lifecycle
• Blurring the lines between business and IT.
What change management and the new approaches have in common is that they:
• Support timely and effective implementation of business-required changes
• Minimize any negative impact and manage risk
• Ensure realization of business outcomes by testing changes and releases before implementation
• Ensure enterprise governance and compliance requirements are met.
7.3 Change management challenges
If change management is supplanted or optimized to DevOps development, how does it address non-software changes such as network, infrastructure, servers, firewalls and the like?
Can non-software changes be developed with DevOps? While I’m sure they can benefit from the Lean thinking and laser-like focus on business value (as I’ve already emphasized), there is no single approach to managing the myriad changes the modern IT shop faces.
Many organizations struggle with effective configuration management, upon which modern change management strongly depends. IT organizations hoping to bring a DevOps mindset to all changes must invest heavily in infrastructure tools to vastly reduce the effort required to manage configurations. Having effective automated tools to manage configuration opens the door to change modelling and automated testing of proposed changes.
Cloud-based services with vastly reduced organizational focus on the infrastructure also open up new opportunities for accelerating time to value of changes.
Remember W. Edwards Deming’s view on engineering quality into the process rather than inspecting it in at the end. As change management matures, it must loosen its grip on individual RFCs and increase its focus on engineering (change) quality into the overall development cycle. This is where DevOps and mature change management, as I’ve described it in this publication, are in complete alignment.
Change authority must be pushed down as close to the development process as possible. Where there’s effective (DevOps) development, build and testing, automated to the point where quality can be predicted mathematically, change authority should be delegated, essentially to the DevOps process itself. Recall that the goals of change management never required formal/human review of changes, only that change management is tasked with ensuring those objectives are being achieved. When properly designed and optimized, the development process itself ensures the goals of change management are fulfilled.
With that in mind, change management must look at the overall development capability of the organization, assessing its ability to produce the level of change quality required by the business, and make investments to bring about improvements where needed.
Change management must be constantly evaluating the results of the change capability (realization of business outcomes), and, just like our colleagues in manufacturing engineering, seek to identify where in the development process defects could most effectively be engineered out.
7.4 An effective change capability
The approach presented in this publication is designed to bring about mature change management. There’s a natural progression from introducing the concept of change control, to building a mature change capability. Chapter 5 includes key elements for optimization that set the stage for a step in evolution, namely:
• Delegated change authority
• Standard changes
• Change models.
With these, change management is no longer a one-size-fits-all proposition. It now has the tools to apply the required level of oversight to the various value streams over which it has authority.
Whereas a CAB-centric change programme is problematic for high-velocity, highly automated development methodologies, these three elements are key. They allow application of the right level of autonomy to development approaches that produce quality changes in alignment with organizational needs. This is effective change management in a DevOps world. The result is a change capability that’s suited to add value through effectively managing the organization’s change capability.
Any organization adopting change management at this point would be ill-advised to implement a traditional, bureaucratic change process that amasses control and decision authority into a single, central body such as the CAB.
The goal of change management is an organizational capability that produces business outcomes while ensuring the principles of change management are satisfied along the way. These principles are to:
• Support timely and effective implementation of business-required changes
• Appropriately manage risk to the business
• Minimize negative impact of changes to/for the business
• Ensure changes achieve desired business outcomes
• Ensure governance and compliance expectations are met
which are served well by:
• Becoming an integral part of the IT value stream
• Letting go of the ‘silo of the CAB’
• Focusing on achieving business outcomes
• Measuring itself by the business value it produces
• Achieving its goals as part of development flow.
These principles will never go out of style because they don’t dictate any particular process or practice. Change management practitioners must learn to constantly adapt to meet the needs of the businesses they serve.
7.5 Where do we go from here?
Well, for starters, the need for effective management of changes isn’t going to change. The challenge change management faces is its well-earned reputation of being slow, bureaucratic and hopelessly outdated. It’s a legacy that requires more than minor tweaking to shed.
Change management must become a core organizational capability that never rests on prior success. What may have worked in the past won’t meet the needs of the future. For most change management practitioners, the journey has only just begun. The cadence of the phased approach will continue into the future as they strive to meet their organization’s ever-changing need for effective change management.
So, focus on the business, and how you can help achieve its goals. Keep up the relentless pursuit of excellence, practitioners!