Back in the day when information technology was dragging itself out of the swamp, approaches to technical change were many and varied. Technicians came to IT from a variety of disciplines and different methods were inevitable.
The IT world was a simpler, more plodding place, at a time when analogue business systems were still warm. Business continuity for many meant going back to pen and paper, memos and telephone calls. Inconvenient, but not too much of a stretch, working without IT not yet unthinkable.
Before Change Management (BCM)
BCM, implementing and maintaining IT services was considered ‘too technical’ to be of interest to managers and service users. Planning occurred on a continuum ranging from formal project management through to spontaneous. Individual technicians or teams did their own thing and success could be attributed to the robustness of technique, luck or both.
More to the point, recovery from a failed change was sometimes achieved perfectly with a textbook back-out plan, or by fluke, or it may have taken on a life of its own. These were the failures that had file servers still in pieces on Monday morning, with attempts to restore service thus far unsuccessful and still counting.
As IT staggered to its feet, and core systems broke out of central processing onto desktops, the pace of change picked up, as did the incidence of failure. Expanding IT departments meant that different approaches to change multiplied exponentially, and the wheel may have been reinvented several times (a day or week). If perpetual chaos was to be avoided, an overarching approach was required. Enter change management.
The shock of the new
IT change management came as a surprise to practitioners of IT change. Suddenly motives were under scrutiny and perhaps found lacking in financial or business authority; autonomy was perceived to be curtailed. The process, not factored into the work, took too long, and real or self-imposed deadlines could not be met.
Change was just change; thinking about it explicitly would draw no further illumination and writing about it was unnecessary. Risk and impact assessments became obtuse; the question ‘what will you do if the change goes wrong?’ was frequently answered with ‘it won’t’. Instead of being accepted as a reach for consistency, change management was often considered a criticism of ability.
A challenge
Implementing change management was, and still is, a huge challenge; attempting to corral a multitude of methods into one approach, with built in approval gates, inevitably satisfies no one. Good practice processes such as ITIL provide the framework, but, ironically, there are as many different takes on change management as there are implementations of it.
Often imposed and designed to cover all eventualities, processes can become complex, and one person’s governance becomes another’s bureaucracy. Resistance, for whatever reason, has always been an issue and taken many forms (such as artificially downgrading risks, misusing emergency status, or bypassing the process altogether). The image of change management getting in the way of change has been difficult to shake off.
The agile revolution
The advent of agile methods such as DevOps responds to the need to facilitate increasing demand and pace of change in technology, especially with the early introduction of prototype products that are enhanced as requirements are refined.
Change management processes that are perceived to be over-engineered might justifiably be deemed incompatible and as teams develop self-sufficiency, control and ownership of their systems and services, they also expect to manage their own changes. On the other hand, if agile methods are perceived to be a licence to carry out rapid change autonomously, that might lead to the rejection of change management altogether, as not fitting the model.
The elephant in the room
However, there is no intrinsic resistance to change management in the DevOps approach. On the contrary, its creators sought to retain good practices, but as ideas are appropriated and adapted to fit individual business needs, concepts evolve, and there are no guarantees about what survives.
Herein lies the elephant in the room: if agile methods such as DevOps are black boxes, opaque outside of a close-knit team, how does the rest of the organisation know what change management is carried out?
To what extent are agile teams integrated with change management, innocent of the need, or Trojan vehicles that legitimise process avoidance? Have agile teams owned their change management or let it slip? The answer is probably ‘all of the above’, depending on experience, team process maturity, and context.
Fit for purpose
Change management as an external process is still relevant but may no longer be fit for purpose in an agile world. Elements of practice such as risk assessment and testing are not the preserve of change management.
Teams that already incorporate these, and other aspects of the process, rightly see duplication of effort as a contradiction, their faster methods hamstrung by the addition of outmoded ways of working. On the other hand, teams that do not embed good practices at a local level, consciously or unconsciously, may slip under the radar, plunging a whole area of business risk into darkness amid assumptions to the contrary.
This potential for fragmentation is a danger zone. If agile methods of working are, at least in part, a backlash against processes that are too slow to meet real needs, then this exposes an opportunity for doubters and resisters to take a fork in the road. Unfortunately, that fork could lead back to the good old bad old days of freedom, but lawlessness. As self-managed teams begin again to steer their own course, the view from outside becomes unclear.
Notwithstanding a lack of change governance contributing to the return of the Monday morning outage, assumptions might be made about how things are done, and expectations may, or may not, be met. Variance between practices may cause confusion between teams and managers, and service users may become frustrated with piecemeal communication, or worse, no communication at all.
Flexibility
To avoid a return to BCM, the role of the change manager becomes more important than ever and they must take a more flexible approach to process than they may have in the past.
Every organisation is different, but guiding teams on the requirements of change governance and helping them to embed the leg work into their normal routines may be more effective than imposing a rigid one-size-fits-no-one obstacle course that everyone must face.
The change manager retains overall responsibility and orchestrates a coherent view to demonstrate quality assurance and communicate impact from a central perspective, but in the meantime, duplication of effort and perceptions of unnecessary bureaucracy are avoided.
Hey, Marty!
If, for some, the face of change management is fading, like Marty’s siblings in the photograph in Back to the Future, it is important to acknowledge that change management (like the film) has been around for 30 years or more. It may not always have been perfect, but its intentions are honourable.
Those tempted to step over it would be foregoing the opportunity to progress from the shoulders of giants. But change management must acknowledge and meet those who are owning its ideals themselves. By incorporating its requirements at the local level but maintaining an overview, it becomes possible to realise the potential of fast turnaround change without compromising quality.
After Change Management (ACM)
It may be that the agile world is ACM, but that should not mean a wholesale rejection of the process. Change management can, and should, adapt and reinvent itself to keep up with the change that it serves. The concept will always be essential; its ability to change itself is progress.
