The client I’m currently working for has what is best described as an extremely conservative attitude to change management. In certain environments of course, this is perfectly normal and necessary. Unfortunately, they also have a requirement for multiple major infrastructure projects to be delivered in tight time frames, and the conflict between the two requirements is really coming to a head at the moment. In a memorable exchange today, a service delivery manager insisted that all work on the relevant projects be put through the change management process – even where it is not service affecting. Since the change request process is both convoluted and bureaucratic, this requirement will lead to increased delivery times on all of the infrastructure projects.
When challenged about the risk this posed to delivery, the manager’s reaction was to assert that all changes should go through the change request procedure, regardless of impact. The highlighted part of that statement is key. If major projects have to submit change requests for each and every item of work along the way to implementation, it is not unreasonable to expect that delivery times will be negatively affected, not to mention the fact that it is likely to bore any sane person to tears! Indeed, so conservative is the client, that when the deletion of temporary files from a server was given as an example of something that wouldn’t require a change request, the technical team were immediately overruled and told that indeed this would require a change request! At that point I was seriously considering whether to run away and join the circus.
Aside from a breath-taking lack of perspective when it comes to risk and day-to-day operations, this kind of attitude is also a major threat to the successful delivery of key projects. In fact, this became so apparent during the meeting that I was attending that I joked that we would need to setup a separate project just to write the change requests (naturally, this went down like a bag of sick with some attendees). As it turns out, the real requirement is for better communications within the support teams that look after the environment – not something I would consider to be the primary objective of a proper change management regime.
Now: we all know that change management is a Good Thing and that the days of simply implementing a change with zero documentation are long behind us. Implementation of risky changes needs to be well documented in advance, and controls and tests put in place to remove as much risk from the change as possible without becoming an obstacle to implementation. Fundamentally though, projects should be considered as a series of changes that are documented (or should be) in the design and implementation documentation, and the change management processes and procedures should be flexible and lightweight enough to adapt to this kind of scenario. If the process is unwieldy or complex, there is every chance that your implementation team will start to bypass it to get their job done, and that’s a recipe for disaster.
So, to summarise:
- The change management process must be adaptable and flexible enough to deal with a number of scenarios.
- Change management should not become a barrier to the implementation of projects.
- Change management procedures should not be so complex that implementers feel compelled to bypass them to do their job.
- Processes and procedures must be regularly reviewed to ensure that they are still fit for purpose, and where improvements are identified, they should be documented and issued to all change implementers in advance of implementation.
Change management is crucial to the success of modern enterprise IT systems, but so is a sense of proportion! Get it right and you will find the implementation of complex changes becomes exponentially less risky.