ITIL

Home/Tag: ITIL

ITSM: don’t stop with Ops!

Rachel SeanigerIn this guest blog, Rachel Seaniger urges continuation of the IT Service Management (ITSM) journey to achieve lasting value.

 

My colleagues and I find that a large percentage of organisations implementing ITIL® only go as far as service operations (and often change management) but rarely get as far as formalised service strategy or service design.

©iStock.com/rappensuncle

The ITIL lifecycle provides rich guidance on service strategy, service design, service transition and continuous service improvement. So why do so few go beyond the basic quick fixes of service operations? Every organisation is unique and there are more reasons than stars in the sky, but I see them falling into roughly five categories:

Reason #1: Obviously, the place to start is where the user is most directly involved with the IT organisation. The highest priorities are the areas of highest visibility – for example, processes for requesting a new laptop or incident management. That gets done then… nothing!

Reason #2: Having tackled the immediate, customer-facing issues to achieve early wins, the team simply runs out of puff. But there’s so much scope to go further with ITSM… Remember, the tortoises are the winners.

Reason #3: Sometimes the IT team tries to extend beyond service operations but simply fails. Feeling they’ve got their fingers burnt, they have little appetite for pressing on.

Reason #4: ‘Business as usual’ always prevails within IT, chewing up available resources and time – so even the best-meant ITSM implementations grind to a halt prematurely (the road to Hell is paved with good intentions!).

Reason #5: The business simply doesn’t understand the value of the more strategic ITSM processes, so is unwilling to invest further. Many senior IT managers also fail to see value in extending beyond ops. This is the big one and the hardest to overcome; without management commitment and sponsorship, the efforts of underlings are doomed to failure – however logical and passionately advocated.

For all these reasons, we often get just so far – when there’s still a way to go.

Why NOT stop here?

Users are happier, the organisation has paid lip service to ITSM and IT management feels that it’s fulfilling its charter. But how much more could be achieved?

There is tremendous value in following up with the service strategy and service design phases. This takes ITSM beyond merely what the user is interested in and what they need; potentially transforming the entire IT service delivery function to make it more efficient, less costly and infinitely more stable in the long run.

Without formalising these phases, you will always be playing catch-up. The ideal place to be is on your front foot: optimising emerging technologies and positioning IT to meet users’ future needs. Yes, I’m afraid that it’s all about the ‘I’ word that we all aspire (and struggle) to achieve: innovation.

Look at the symptoms; do any of them sound familiar?

Lack of service strategy results in:

  • Your business users googling ‘big data’ and ‘Internet of Things’ to find solutions to their IT issues
  • You’re no longer getting invited to strategic planning meetings, and everyone stops talking when you walk into senior management meetings
  • You’re spying an IT outsourcer brochure on the CEO’s desk
  • IT solutions rolled out that the IT organisation had nothing to do with
  • IT being perceived as an abyss, into which money mysteriously disappears with nothing coming back out

Lack of service design results in:

  • The business still using the old system despite the new solution being a raging success, according to IT’s objectives
  • User satisfaction dipping to new lows, although service levels are almost always met
  • Users not getting what they want while vendors are meeting all their service targets
  • Porsche promised, VW delivered – which does the job adequately, but just isn’t a Porsche
  • Service Level Managers needing trauma therapy after monthly service review meetings

This article was first published by UXC Consulting – view the original article here.

Service Management 2016 is now less than a week away! Find out more about the Conference program, Gala Awards Dinner, and workshops!

 

 

 

By |2018-03-19T16:23:18+10:00August 12th, 2016|guest blogger, Service Management 2016|

Transformation goes beyond adoption and adapting

hooper

Matt Hooper is speaking at Service Management 2016. He is an industry advocate for Service Management strategies and best practices around Enterprise Service Management. For over 20 years Matt has instituted methodologies for business intelligence and optimisation. Leveraging technology to drive business outcomes, he has built an industry reputation for his highly effective approach to creating value through Service Management. Matt is active on social media known as VigilantGuy, and co-hosts the weekly podcast: Hacking Business Technology (HackBizTech.com).

The latest content from Axelos, the makers of ITIL®, “ITIL® Practitioner Guidance”, heavily re-states an already existing mantra of ITIL®, Adapt and Adopt.  The reality is, this guidance is much too little and way too late. The premise and principal behind this mantra is that we have to evaluate our current state of operational delivery capabilities, then apply the pieces of ITIL® that will help us make improvements.

This was solid guidance 10 years ago, when IT had a fighting chance to demonstrate that they were the responsible functional area to capitalise on digital strategies to lead business innovation. However, few organisations’ IT departments stepped into that role. An overtly and polarised focus on technology and process left most IT departments less cohesive, with larger walls of bureaucracy between IT operations, development, enterprise architecture and the PMO (Project Management Office – seriously, they have their own office).

Hooper-Speaker-ITSMf

Digital transformation is not merely improving what’s not working today.  Transformation is the complete re-conditioning, re-structuring, and re-thinking of how digitisation is enabling organisations to act differently. ITSM professionals must truly transform if they are going to survive the new business dynamic, where “IT” is no longer a department but a pervasive business competency.

While the ITIL Practitioner Guidance has been updated with new terms and references and new more Agile concepts, there are 5 areas where “Adapt & Adopt” will just not cut it:

  • Language
  • Knowledge
  • Asset/Configuration
  • Change/Release
  • Requirements

To be a leader in Digital Transformation, ITSM professionals need to do their own personal transformation. Like a caterpillar to a butterfly, they need to re-condition, re-structure and re-think their role in business enablement.

To learn how to be truly transformative, join me at itSMF Australia’s annual Service Management conference on Wednesday 17 – Thursday 18 August in Brisbane, Australia. I’ll be speaking at 12pm on Wednesday 17 August on: Creating enterprise agility through Lean service management and DevOps.

 

By |2018-03-19T16:23:18+10:00July 28th, 2016|Service Management 2016, transformation|

Delivering Problem Management with Kanban

ian jones

 

 

We are pleased to welcome previous Service Management speaker and member of the ITSMF Awards Alumni Ian Jones to the blog today! 

 

I previously led an IT Service Management team providing Incident, Problem, Change and Configuration Management services in line with ITIL. Our work was highly variable and ranged in complexity since we primarily supported other IT professionals in their IT operations. The whole team used Agile Scrum to manage our work and the problem analysts used Lean Kanban for (ITIL) Problem Management. This blog post will outline how Kanban was applied to effectively deliver our Problem Management service.

Our organisation used Agile as the main delivery method for projects, and Lean (based on the Toyota Production System) for operations. Bell and Ozen (2011, p8) suggest Lean aims to empower teams to simplify, then when appropriate, automate routine tasks. Process improvement frees up capacity, providing individuals with more time and better information to exercise problem solving, creativity and innovation in situations that are not routine.

What is Kanban?

Kanban means sign, signboard, billboard, card or signal of some kind (Liker, 2004, p. 106). It is a scheduling system for Lean, just-in-time production and a system to control the logistical chain from a production point of view. Kanban was developed by Taiichi Ohno, at Toyota, to find a system to improve and maintain a high level of production. The Kanban Method was later added to as an approach to incremental, evolutionary process improvement for organisations (De Haaff, 2013). For readers who are familiar with Scrum, you would be aware of this concept of the signboard or visual management in the form of a story wall. There are differences between Kanban and Scrum and these differences shouldn’t be seen as strengths or weaknesses. Some of these differences include:

Kanban Scrum
Work scheduling  Customer driven pull  Fixed timeboxed push
Task estimation  N/A  Yes
Tracking work  Focus on flow  Focus on velocity
Work in progress limits   Yes   N/A
Process ownership  Team  Scrum Master
Continual Service Improvement  On demand, as defects are seen  At the end of the sprint in the retrospective

 

Application to Problem Management

Initially my team employed Scrum for managing their problem investigations, however we found the concept of timeboxing the work into sprints added no value. Investigations could vary greatly in complexity and therefore finding the root cause and completing corrective actions could be difficult. Task estimation was also challenging and the actual results varied widely due to the above reasons. The team then applied Kanban as an alternative and their wall contained the following columns:

  • Backlog;
  • Post Incident Review (PIR) booked;
  • PIR held;
  • Publish and Task Followup; and
  • Complete.

kanban_wall

 

Kanban suggests that staff ‘pull’ work from left (first column) to right (last column). If staff have capacity  (actual work in column X < work in progress limit in column X) then they pull work from the previous work step (column on the immediate left). This video provides a visual explanation.
The problem analysts employed a series of important variations to their Kanban wall. These variations included:
  • They pulled work from the ‘Publish and Task followup’ and not ‘Complete’ as this step is entirely dependent on other IT staff (tasks like corrective actions are mostly performed by other IT staff) and the duration of task followup is variable;
  • Unlike typical value streams, the problem analysts do not hand over their investigations to other staff and tended to progress the investigation from start to finish (except for extended absences from work). This was because the effort and cost of task switching between problem investigations exceeded any proposed benefits from handovers between investigation steps;
  • Work in Progress limits were informally used and not strictly enforced. If an analyst had too many investigations in a particular column, we used it as a flag for assistance and potentially management escalation rather than a reason to block the incoming work. Upon these events, we preferred to negotiate with stakeholders (service owners, management) on work priorities rather than block the work.
So as you can see, the team took the concept of Kanban and tailored it in a way that supported them, which should not be surprising since problem investigations, by their nature, are not generally standard or repeatable forms of work.

One significant benefit we saw in adopting Kanban was that it supports Principle 5 of the Toyota way: ‘Building a culture of stopping to fix problems, to get quality right the first time’ (Liker, 2004, p.38). The visual management of our work and conducting daily stand-ups allowed the analysts to easily identify defects or weaknesses in their investigations, pause work and jointly derive immediate improvements to their service. This has led to significant quality improvements in their work which was acknowledged by our customers and management.

References
Bell, S., and Orzen, M. (2011). Lean IT, New York: CRC Press.

De Haaff, B. (2013) Kanban the secret engineer killer. Retrieved July 30, 2013 from http://blog.aha.io/index.php/kanban-the-secret-engineer-killer/.

Liker, J. (2004). The Toyota Way, New York: McGraw-Hill.

This blog was originally published on Ian Jones’ blog.

 

By |2018-03-19T16:23:20+10:00June 2nd, 2016|Kanban, Service Management 2016|
Go to Top