The role of OCM in continual improvement

But I think it’s difficult to go from a good idea to implementation. I believe project management can prepare a solution for the organization, but organizational change management (OCM) will prepare the organization for the solution. Miss either of those two, and you’ll be lucky to make it out with anything like success. That’s why a lot of the work I’ve been doing over the last 10 years has been structured around OCM.

Unmanageable improvement cultures

Time and time again, I’ve seen how organizations can find it difficult to embrace continual improvement. Instead, they’ll implement intermittent improvement practices here and there, especially centred on heroes and hero culture.

This is where a company has a person or group of people who, like Special Forces, will be parachuted behind enemy lines to save the day – every day. But the company can grow to depend on these heroes and their way of solving problems; it becomes the culture, and people can become burnt out. To get over this, we need a change of culture.

Part of this culture change is to recognize people’s contributions and thank them for these. But we need the organization – and everyone in it – to understand that this is no longer how improvement should be done. There should be no more heroics but a structure in place, so the organization is continuously making improvements, rather than reacting to and being driven by change.

And, of course, as this involves changing the way the organization itself behaves, implementing this culture of continual improvement will need OCM.

Maintaining and improving approaches and methods throughout the organization

Rather than creating a work of art every time, there needs to be a consistent methodology across the whole company.

But you don’t want to improve your group to death through some cataclysmic flood of work that you’re unprepared for. You need to make sure that, in working with the end-to-end ITIL service value system (SVS) and value streams, you’re not creating a huge “glob” of stuff that flows through the tube. At the same time, you need to avoid a hyper-local view of continual improvement. Everything must be across everybody.

Assessing improvements’ effectiveness

How, then, do you achieve an end-to-end view of outcomes, outputs, efficiencies, risks and costs?

To put this in the context of ITIL 4, especially around its guiding principles, it’s both about the end-to-end view of thinking and working holistically, and the lateral view of collaborate and promote visibility – the transparency and the ability to work across the organization.

These are the two elements we really want to leverage in the ITIL 4 guiding principles. We want to make sure they apply as an end-to-end view as well as laterally, so we can talk about bottlenecks, excess capacity and consider, for instance, where we’re damaging those value streams that we’re actually trying to improve and update. Without this end-to-end point of view, it a quite possible to sub-optimize a value stream, “fixing” one step without the insight as to how that change may impede or even break other steps either up or down stream in the process.

Generating and incorporating feedback on improvements, implementations and results

We want to ensure that continual improvement is going to have a broadly beneficial view both end-to-end and laterally across the organization; that we’re achieving the best possible result on our ability to co-create value with our consumers. We need to ask and analyse where we’re helping, where we’re wasting time, and where we’re actually hurting.

Encouraging stakeholders to express their needs, wants and concerns and to take risks

Continual improvement must become business as usual – not just something we do to overcome a particular hurdle before reverting to our old ways.

This requires us to make sure we’re open to taking risks and to giving people the ability to make suggestions, knowing that the good ones will be acted upon. We need to make sure we’re encouraging fast feedback loops and acting on that feedback immediately.

The key here is to promote learning from failures, rather than sustaining a blame culture. This absolutely depends on OCM – and that change must be led from the top. It’s about implementing continual improvement as a mindset within the organization, rather than just a practice.

Continual improvement is often seen as concerning small, incremental changes, whereas OCM is assigned to something bigger, more earth-shattering. But there’ll be a lot of overlap. Equally, the OCM part of a major implementation – working with stakeholder groups, identifying potential areas of resistance or reasons why stakeholders might not agree with an idea – can become an incredibly fertile seed for developing new continual projects.

Once OCM and continual improvement are properly stood up, they’ll work closely together for you – like Batman and Robin. The two are fundamental to ITIL 4 methodology and vital to the successful implementation of any new solution.