Applying lean to improve ITSM processes

The DevOps and Agile movements are putting increasing pressure on traditional approaches to IT Service Management (ITSM) as many organizations embrace new technology and become more and more cloud native.

These concepts related to the movements are all about evaluating what a business needs, how agile that business needs to be and how you apply Lean and Agile thinking to modernize ITSM. Every organization has a specific goal or business outcome which is critical to generating revenue. So, anyone working in supporting roles should understand the impact of their activities on that ultimate goal and seek to eliminate waste, including in IT.

But how readily are organizations accepting the need to move from functional to outcome-oriented activity?

Few organizations think in broad terms but, rather, are often forced by compelling events to question their current models and evaluate a better way to do what is required to support their business outcomes. Without that pressure they may not feel compelled to change, and we see this in segments of various sectors and industries rooted in “industry traditions”. Many organizations moving forward with digital and cloud technologies are more likely to feel the compulsion to evolve rather than incrementally change.

The need for speed and agility

In practice, two things have become increasingly more important: the need to be more agile; to react quickly to changing needs and the demand to increase velocity when delivering new technology features and functions.

This is forcing IT organizations to a reckoning point: find approaches that work better as their businesses evolve, and ensure that every organizational movement translates to energy.

This also affects the identification and elimination of waste: do you have steps slowing down your ability to deliver, and are they necessary? Do you have a series of “gates” to pass through to progress in a serial-based activity flow rather than a more lean and agile based approach where only truly necessary steps are followed?

Much of what keeps people back is F.U.D. (Fear, Uncertainty and Doubt) related to risk management and the singular belief that traditional, rote processes are a protection against risk. In the hierarchy of IT needs, isolating the business from risk was always high up. Yet, today, it’s not only possible to manage risk at speed and increase velocity without the “wheels falling off”, but it is necessary to perform multiple activities simultaneously and still managing business risk.

Many fear that, as we tear down the pillars of traditional ITSM, we may reintroduce risk. However, with the right approach (such as appropriate mitigation plans and proper checks and balances), you should be able to take on more risk as a trade-off to having a more agile approach that supports and grows the business. Many businesses will be in a better position to choose an acceptable level of risk for their situation in order to gain more business value. Adopting this approach means engaging the entire organizations at a more holistic level and accepting the need for difficult conversations between parts of the organization that might not normally interact.

ITIL® – relevant today?

If organizations are looking to improve ITSM, then ITIL and the components of the service lifecycle remain extremely relevant today.

When questioning how to reduce waste in systems and challenge dogma about how things should be implemented in practice, ITSM professionals should be following the spirit of ITIL’s processes rather than treat it as a spiritual proclamation. You don’t have to create seven meetings to agree a process but you do need to look at your practices, modernize them, eliminate waste and focus on the outcomes (and not the outputs) of the ITIL processes in the context of organizations today.

The ITIL Practitioner guidance is a very good first step in practical application of ITIL within organizations, guiding them to focus on “minimum viable process”, a.k.a. implementing the fewest required processes and procedures to achieve the desired outcomes and value, while mitigating risks and reducing costs.

Applying Lean or Agile in organizations through change management

A good example of where we can apply Lean or Agile thinking to traditional ITSM processes is in the realm of Change Management where many organizations still manage change through a weekly “Change Control” meeting.

Meetings are often a good place to investigate if applied effort is being wasted rather than creating business value. In many companies, a weekly change control meeting is attended by an average of 20 or more people (I have witnessed change control meetings that had well over 100 attendees). The cost to a company to gather that many people on a call for an hour or more weekly can be tremendous; add the wait time that a potential change has while waiting for the next meeting and business value can often be unnecessarily delayed by weeks rather than minutes or hours.

In many cases, technology and automation can be leveraged to move the decision point from these meetings to real-time decisions by the business owners and key stakeholders of these systems.

For example, approval of changes that have a low potential risk (impact to the business), can often be delegated to system owners. The higher the potential risk, the greater the approval authority that was needed. In this dynamic, the only time meetings are needed is in the case of an emergency change, where the potential for risk is greatest. In these cases, an emergency meeting is called and all key stakeholders or their delegates are informed of the risks and approve the change as appropriate.

I have seen variations of the above approach implemented at a variety of companies. In each case, these companies had increased change velocity by an average of 30-40%, and thus increased the velocity of development and the enablement of key business functions as well. In other words, by eliminating wasteful effort, more of the organization’s “potential energy” is converted to value for the business.

We are, ultimately, in the early stages of transforming to some future state ITSM model(s). There is a mounting evidence that IT needs to be more agile as business needs change. While we as an industry move towards this future, we need new ITSM support models to help achieve the accompanying velocity.

Comments

Future state ITSM (operating) models need to finally place the customer at the center of things, replacing processes, concepts and methods. Service Management (the original version created by product marketing) was all about understanding the customer, what makes them tick, what they value, what they do in pursuit of success, and how they exploit product and organizational capabilities in that pursuit.

Nothings changed. We just lost our way as IT bubble citizens... But you know this Shane - I know that.

I do like the author's point about outcomes vs outputs; but the article hardly scratches the surface. If we take the idea of outcomes to drive our view of service management - we should focus on the value stream rather than processes. For example - what about the relationship between agile delivery, technical debt and the level of incidents that affect a service. Traditionally ITIL proposes 'proactive problem management' as a mechanism for reducing incidents in a service, whereas from a lean perspective this should have already happened during development. Whilst Agile aims to reduce technical debt, in practice it may not due to the necessity for speedy delivery. Examining the service from this perspective and applying Lean will have greater potential for improvement than the change process. Looking at from this perspective the degree of change control should be inverse to the level of quality realized in the 'production line' of the service as happens in manufacturing.

Good article but disagree with the statement "the only time meetings are needed is in the case of an emergency change" because that assumes a degree of maturity on the part of the organization. Every organization is different and risk tolerance is something that cannot be flatly determined. Flexibility is key in delivering an ITIL solution to an organization.