ITIL®4 has been launched successfully. Across the globe ITSM professionals have been proudly adding the ITIL 4 certificate to their name – a new theoretical badge of honour. However ITIL 4 was launched into the industry to solve a problem and to play an important part in enabling businesses.
The ‘problem’ is that ITIL is perceived as being out of date and slowing things down in an era of digital disruption, no longer ‘fit for use’ for a business community demanding more agile ways of working. The perceived role for ITIL 4 in ‘enabling business’ is to contribute to the end-to-end co-creation of value, helping deliver outcomes versus outputs and thereby making it more fit-for-purpose.
That’s the theory. But any new way of working only delivers value when it can be applied to solve a problem and enable the business. Translating theory into practice is the real badge of honour. So, does ITIL 4 do what it says on the tin?
Masterclass: learning the hard way
itSMF UK recently delivered a new Masterclass – ‘ITIL®4 in Action’ – aimed at exploring and experiencing this new way of working. A team of delegates were immersed into the simulated environment of the Mission Control Centre of the MarsLander Mission.
Playing the business, product owner, IT (Dev, Ops and service management) and supplier roles the team were faced with challenging new customer demands for innovation, whilst at the same time needing to ensure availability and stability of existing and new products and services. In short, the team explored the benefits of ITIL 4 in action.
In-fighting and fighting for relevance
At the start of the session we asked delegates what they were hoping to learn. As can be seen from the list below, many were hoping to find out how ITIL 4 would deliver the benefits described above. As one delegate described it, “we [ITSM professionals] are fighting for relevance”, echoing a theme from the itSMF UK 2018 conference, as described in this blog on the website:
- Understand how Dev, Ops and ITIL can work together, and how ITIL 4 can enable that.
- Learn how to break down silos and create more end-to-end collaboration.
- Find out how this can help shift DevOps attitudes to ITIL and shift ITIL thinking and behaviour to be more aligned with DevOps.
- Discover how to avoid the ‘in-fighting’ between the framework tribes.
- Learn how this helps. We are ‘fighting for relevance’.
- Determine how we can capture input into our transformation initiative. We are seen as being old and slow and must demonstrate new ways of working.
- Compare MarsLander with Apollo 13 as part of our ITIL training.
- Identify ‘service desk’ team efficiency improvements to take away from ITIL 4.
- Decide how this helps translate theory into practice.
- Explore simulation for ITIL 4 awareness and introduction.
- Provide a crash overview of ITIL 4 main concepts.
- Discover the value of ITIL 4.
- Find out how ITIL 4 looks at continuity.
Before we started the simulation I asked how many people knew the guiding principles of ITIL. Only one person put their hand up, but nobody was actually using them. The guiding principles have been around since 2016 with the introduction of the ITIL Practitioner guidance, which unfortunately has not been adopted as it deserved to be. (The full list of guiding principles is described in the latest issue of ServiceTalk Express.) We did an exercise based on the guiding principle ‘Collaborate and promote visibility’. The team were asked in pairs to describe the behaviours they see today that demonstrate ‘effective collaboration’. We headed the flip-over ‘In fighting’ to remind the team this is what we were trying to break down.
This was their list of behaviours.
- Two-way communication – provide and ask for feedback, active listening, summarise agreed goals, ask questions to clarify understanding.
- Say yes more often than no, yes
as default. Where necessary say ‘no, unless…(risks), ‘yes,if….’
(does our business want us to say yes to all ‘wants’ or clarify ‘needs’ and commit when we say ‘yes’?)
- Encourage open and transparent communication.
- Aim for a no-blame culture, foster a safe working environment.
- Find a common language. Are we talking about the same things? (Later in the simulation the business goals became the common language: how does what we do and what we talk about in IT relate to business goals?)
- Encourage ideas. (Later in the simulation, we considered how to recognize them, respond to them, show respect for them. If you ignore them good ideas dry up).
- Identify the appropriate level of involvement: what are the right skills, the right decision-making authorities?
- (Later in the simulation, agreeing goals and how work gets prioritised.)
It is interesting to note that this list differs with every team and often reflects back on the level of trust, blame, and safety that delegates feel in their working environments.
Why didn’t you tell us? Why didn’t you ask?
We then played the simulation. The collaborative behaviours were mostly ignored, there was little ‘listening’, business goals were unclear, SLAs weren’t known, priorities were based on individual silos and the product owner insisting. There was little insight into the complete backlog of work or who was working on what, there was little insight into service improvement needs. Service management was not seen as a value-add in the initial round.
Service management and ITIL was not seen as relevant to the business team!
Between simulation rounds we explored the definition of a service according to ITIL and probably the main guiding principle ‘focus on value’:
“A means of enabling VALUE co-creation by facilitating OUTCOMES that customers want to achieve, without the customer having to manage specific COSTS and RISKS.”
How could the team prioritise value if they did not understand the business goals? How could the team deliver value if they did not know what value looked like? How could they ‘co-create’ if they weren’t collaborating?
IT team to business: ‘Why didn’t you tell us’?
Business team to IT: ‘Why didn’t you ask’?
If we in IT, using ITIL 4, want to be seen as relevant to the business and the agile ‘tribes’ then we have to step up to the plate and claim that position.
We then held a ‘stand-up’ to reflect and improve. The stand-up for reflection and for prioritisation of work was facilitated by the product owner and the service manager roles.
The team first explored the Service Value System. This included the importance of translating the guiding principles into behaviours and the importance of governance to help prioritise business goals and balance outcomes with risks. The team mapped the complete backlog of work in terms of value. VC+VL+VI (value creation work, value leakage work, and value improvement work). The team agreed the value streams for each type of work and then visualised work in progress as well as wastage (manual work and repetitive wasted work). A priority mechanism was agreed, to include in each round a measure of ‘service improvement’ aimed at reducing value leakage and/or increasing value creating capacity.
As the rounds progressed the team applied effective collaboration behaviours, correcting each other and giving feedback. It wasn’t easy, coaching was needed in the beginning. They focused on goals and communicated in terms of business goals not in terms of technology. They prioritised their work according to VC+VL+VI, enabling them to increase the speed and the amount of work flowing through their value streams. Goals were achieved, business value indicators achieved. It felt good. There was no ‘in-fighting’, there were no more silos.
The business dropped the SLA about solving times and percentages in favour of ‘business value impact’.
If only work was like this! Why can’t it be?
At the end of the session we asked delegates, ‘What did you discover today that you need to take away and apply back at the office?’?
- Use VC+VL+VI (value creation work, value leakage work and value improvement work (reduce leakage or increase value creation).
- Try to establish appropriate governance mechanisms for prioritising VC+VL+VI types of work. Not all ‘features’ have the highest priority, and technical debt, defects, and risks must also be part of prioritisation, linked to business impact.
- Discover ‘blockers’ (waste and toil) for input into the ‘continual improvement’ register, explore value and impact of issues to users (value leakage).
- Start identifying and mapping value streams for the different types of ‘demands/opportunities’; engage Dev and Ops in this mapping.
- Understand the different value types and map value streams. Understand your own role in the value stream.
- We work in ‘siloed’ improvements. We need to look at the whole system (and value stream), identify upstream and downstream dependencies. Use problem management as feedback upstream, also learn to make business case for problems – business impact.
- Problem management is critical and must have business understanding. Problem management roles must work closely with product owners to gain business understanding.
- Include vendor in stand-up and in prioritising improvements. look for win-win improvements (co-create value).
- Remember the take-away ‘collaboration’ exercise: the importance of the guiding principles and translating them into visible behaviours, then coaching on these behaviours.
- Try and make a visible map of the tools that support the value streams. Look at IT4IT. Look at the value flow framework (Mik Kirsten, ‘project to product’) and work from task top in integrating and aligning tools and producing value metrics (for the various end-to-end stakeholders).
- Hold review discussions on the value of SLAs. Establish IT metrics versus business value. What metrics make business sense?
- Aim for more ‘outcome’ less ‘service’ focus.
- Use this type of exercise with Dev and Ops, also to demonstrate to ‘business roles’ their responsibilities in governance and co-creation.
- Advise clients that ITIL 4 can co-exist with other agile approaches and aligns with value stream thinking and end-to-end co-creation of value.
- Look forward to putting this into practice(s)!
The team had felt the benefits of ITIL 4 in action, they had experienced how to develop and embed ‘collaborative’ behaviours, learnt how to ‘progress iteratively with feedback’ and apply continual improvement skills, and had captured concrete, pragmatic takeaways. All in one day! They had experienced the power of experiential learning in helping translate theory into practice and develop the all-important ‘softer’ skills. Imagine what would happen if you did this exercise with end-to-end stakeholders in YOUR organisation!
“It was a very beneficial day, a real eye-opener!”
A call to action
If you want to use ITIL 4 to claim relevance then it is time to translate theory into action. Here is a blog of 9 take-away tips about applying ITIL 4 concepts. These were tips from an actual team made up of business, Dev and Ops stakeholders who were experiencing exactly the challenges mentioned by delegates at the start of this workshop. Which challenges does YOUR organisation need to solve? How are YOU ensuring ITSM relevance? Will YOU take up the call to action? In the words of Army General Eric Shinseki, “If you don’t like change, you’ll like irrelevance even less”.