With the publication of ITIL® ver. 3 in 2007, a clear stance was taken regarding the scope of change management. The authors of the Service Transition volume pointed out the rather obvious fact that changes at almost any place in the value network of service delivery could impact the quality of the services. Therefore, it is desirable for those changes to be under control. This includes changes at the strategic and tactical levels, as well as the operational level. It includes, too, changes among the suppliers and customers, as well as changes within the service provider organization itself. Changes under control might occur at any time throughout the service life-cycle.
With so clear a statement in place, it is curious to note that the scope of change control remains a major open question in many organizations. Curious, but understandable. For there are many issues underlying the decision on scoping change control. I mention here the more salient issues:
- the historical use of change control in an organization
- the desire to start with operational changes in production
- the inability to progress change control beyond the initial scope
- a deep divide between application development and production management
- a single change control process is not applicable to the full enterprise
I will review each of these points in greater detail.
The Historical Use of Change Control
Many, if not most, organizations have been performing some form of change control long before any best practice framework or international standard told them to do so. Not only do organizations have established traditions of managing their changes; they are often quite satisfied with the results they achieve. And therein lies the rub. The approach of adopting and adapting best practice advice is often interpreted to mean that best practices are used to lubricate squeaky wheels, to address the pain points. Fixing something that is not perceived to be broken often is not considered, or is given so low a priority that it never happens.
Starting with Operational Changes
For the same reasons as cited above, the most visible pain points that can be directly related to ineffective change control are the failed changes to the production environment. If failed changes, or changes to cause production incidents, or production changes that go unrecorded are truly the issue, then it is eminently reasonable to start change control at the internal, operational level. This assumption is reinforced by the commonly held view, based largely on ITIL ver. 1 and ITIL ver. 2, that ITIL concerns operations, exclusively.
Failure to Progress Change Control
The final question in ITIL’s continual service improvement model is “How do we keep the momentum?” An organization that had no formal or well defined change control activity has probably suffered many aches and pains in the course of implementing that activity. As mentioned above, this initiative is most likely to have operational changes in production as the scope. The effort of continual improvement is likely to focus on three areas:
- increasing the coverage of control over production changes and, at the same time, detecting and reducing the number of changes that are not under control
- reducing the overhead of change control
- improving the quality of the impact and risk assessments
All worthy efforts and difficult enough. For such organizations, expanding the scope of change control beyond the production environment, beyond operational changes and beyond internal changes is probably considered as utopic, if it is considered at all.
Perhaps the greatest impetus to maintaining the will and energy to expand the scope of change control would be the unqualified success of the initial efforts. Most organizations are happy to build upon their successes. Unfortunately, most change control initiatives tend to yield mitigated results, even after great effort, making the whole idea somewhat less attractive to the rest of the organization.
The Development—Production Divide
The great divide between application development and production management has been a subject of discussion for a long time. Certainly, the IT service management enthusiasts have been critical of the practice of “throwing applications over the wall” for a long time.
ITIL ver. 3 started to provide specific advice for the roles that people with production responsibilities should play during application development and testing. Unfortunately, this message was passed with difficulty, if passed at all, to those responsible for application development. Application developers have approached the same issue by wanting to enhance, rather than reduce, their control over the full software development life-cycle. For some, infrastructure has become just another type of code, to be managed largely as code is managed.
In the more traditional development shops, control over the development environment was the purview of the developers themselves. Whatever change control they might have exercised was completely internal to development. Any administrative overhead to control such changes would have been treated as unacceptable interference that would drag down productivity. Indeed, the main control issue for developers is in the configurations of the components they use, not in the changes per se.
Approaches such as Continuous Delivery leave little role at all for production personnel. Indeed, Jez Humble has suggested a Solomonic solution to accommodate the entrenched policies of change management to the goals of continuous delivery. Unfortunately, many change managers view themselves as the last barrier to the unleashing of chaos. Only their heroic efforts keep the company running. Someone has forgotten to tell them that their role is to facilitate changes [that is, make it easier to make changes], as much as it is to ensure the quality of those changes.
Devops people, frustrated by the general intransigence, seek to automate many service management roles out of existence. Ultimately, the most efficient and the best managed organizations will indeed have a very high degree of automation when it comes to introducing changes. The challenge to Devops is to focus on and to realize what their proponents say, rather than what they do. They say that Devops is principally a cultural shift, an attitude. But 99% of the discussion about Devops concerns the nifty tools that can be used for automation. To be fair, most of IT has the same problem.
A deeper and more significant development—production split is implicit in agile management. ITIL takes the approach that the entire service life-cycle is under change control. This includes, but is not limited to, changes to strategies, changes to the service portfolio, changes to the requirements for solutions, changes to the specifications of solutions, changes to the methods for testing and accepting solutions and changes to the methods for packaging and deploying solutions. Let us take requirements management as an example.
According to ITIL, requirements for new or changed services [including, of course, changes to any applications used to deliver those services] need to be collected, normalized, validated and baselined. Changes to the baselines requirements require, according to ITIL’s process, a request for change, an assessment of the impact and risks of the change, scheduling of the change, co-ordination of the change implementation and some form of review and closure of the change.
The agile approach considers the requirements are elicited, refined and fulfilled as part of the development cycle. The customer will not be sure of the requirement until the solution demonstrates how it is to be fulfilled. And even then, new requirements will come regularly and throughout the lifetime of the solution. This approach is utterly incompatible with ITIL’s view of change management. Try to get a scrum master to agree to ITIL’s view of change control activities. While this might be a fool’s errand, getting them to agree on the goals of change control is much more likely. When it comes to creating applications, most developers would probably agree that the goals of change management are best achieved by whatever software development methodology is to be used. Using a change control process in addition to that is redundant. In short, developers of many different stripes continue to defend their terrain from encroaching change control. The more agile they are, the more they provide a method that ensure coherence throughout the chain of production, the more right they are to do so.
One Process for All Changes?
When organizations implement a change control process following the advice of ITIL, they generally end up defining one or more organizational positions, or jobs, for full-time change managers or analysts. Imagine a change analyst who spends his or her days processing changes to firewall configurations, server memory allocations or database initialization parameters. Now, suppose that the scope of change management is expanded to cover strategic changes or changes at the suppliers or customers. Can you imagine that same change analyst chasing after the CIO, demanding why no RFC was submitted for the new version of a policy? And what is the analyst supposed to do if the sales department is completely reorganized, creating a huge impact on IT, but no RFC was submitted?
ITIL does not go into the details of how change control could be applied throughout the scope that it claims for this discipline. Tactical changes internal to the service provider are perhaps controllable in the same way as operational changes. For example, a process owner proposes a change to his or her process, providing the reasons for the change, the plan for implementing it, possibly a back-out plan, etc. This input can be logged, classified, assessed, authorized, planned, co-ordinated and reviewed, just like any operation change.
As we saw above, however, the classical activities of change control are unlikely to work as is for modern application development. Pretending to exercise change control over development is the worst of both worlds. Administrative overhead is added and no value gained. We can also assume that the head of IT, or the head of any other department in the organization, cannot be expected to follow the same process as a DBA or a Linux administrator.
If the goals of change control remain applicable and useful throughout the broad scope as imagined by ITIL, the activities, the deliverables and the people playing the change control roles are likely to differ radically. For example, changes among the customers will require specific input from the customer relationship manager or business analyst. There is no decision to be made to approve the change; the customer has already made that decision. (Of course, the situation would be quite different if a single change control discipline were to manage the entire enterprise, not just IT.) Similarly, when a supplier makes or proposes changes, the service provider organization is likely to have to respond to a fait accompli. Although it might be possible to convince the supplier to back out of a change, the more likely result is either to change supplier or to make internal changes to accommodate the external change. There are no activities in the ITIL change control process for such decisions, insofar as they must be made before submitting any change proposal or request!
Many Barriers and Varied Approaches
We see that there are many barriers to the adoption of change control to cover the full life-cycle of services. We should recognize, however, that the goals of change control may be achieved in many different ways. There may be certain key aspects to change control that should be preserved, no matter what set of activities are used to achieve the goals. These include:
- documenting the proposed change and its result
- using change control as a front end to configuration control
- evaluating changes to determine if the goals have been achieved and how to improve in the future
On the other hand, the control of changes may be achieved in different ways:
- the goals of change control may be achieved in ways that are inherent to other processes, such as application development
- the control of changes in parts of the value network that are external to the service provider organization will require additional assessment and planning activities
- it is not realistic to expect the same change managers and analysts to handle all changes throughout the scope of change control
- techniques for facilitating changes will be radically different, according to whether they are internal or external to the service provider and whether they are strategic, tactical or operational.
The future of change control in a truly mature and integrated organization probably involves establishing control activities and authorities whose scope is the entire enterprise, rather than being limited to the IT service provider. Let there be an end to the IT vs. Business divide. IT is part of the business, no? But this is a subject for a future posting.
Leave a Reply