If you’ve attended an ITIL Foundation course, you’ll remember learning about emergency changes, and the role of the ECAB – the emergency change advisory board. In many cases, the ECAB is presented as something of a “rubber stamp,” helping a change manager “cover their back” by getting an emergency action signed off by senior staff. What the relevant ITIL book (Service Transition) actually says is “Where CAB authorization is required, this will be provided by the emergency CAB (ECAB)” (do you think this would look good as a tattoo?).
In IT, one of our biggest (maybe even our favorite?) grumble, every year, is how the business expects us to deliver more for less. So why is that? Perhaps there’s one overriding reason why the business expects it: IT has, by and large, delivered exactly that for the last 50 years or so. From inside IT, we’re very aware how hard it is to deliver these constant improvements in times of budget cuts and austerity. But step outside IT, take a wider perspective and you’d agree that your customers just see technology driving savings and the IT department offering more and better services than ever before.
Have you ever thought about the truly basic concepts underpinning continual service improvement (CSI)? Let’s take a look at the words themselves.
The main point of CSI is to deliver improvement, so I think it makes sense to start with that word.
Often individuals’ preconceptions of improvement limit the scale and scope of what can be delivered.
This is especially true of suppliers who think they know what a customer, user, or other stakeholder would consider “better”.
Let’s illustrate this with a familiar product – cream cakes. What range might the term “improvement” cover?
As more companies move to adopt DevOps practices to improve IT performance (my company included), I was thinking to myself – is it clear how to blend this with our existing IT service management (ITSM) activities? These existing ITSM disciplines and processes, often based around ITIL, have served us well for many years. So although most of us accept that it’s time to adapt, how do we best marry the ITSM, or ITIL, activities and DevOps? In particular, how do we best incorporate the IT service desk in the DevOps world?
In this blog, I want to look at each of the DevOps “three ways” and outline how the service desk can be fundamental to all of them as well as other Agile concepts.
IT service management (ITSM) and ITIL, the most commonly adopted ITSM best practice framework, are both full of terminology. Just look to the names of the 26 ITIL processes, some of which are pretty self-explanatory but sadly some aren’t.
So if you’re just starting out with ITSM and ITIL, I’m wondering which are the most important words in ITSM to know, from a traditional perspective? You might ask why I say “traditional” – it’s because I’ve written another blog that takes a more business-focused, and sometimes funny look, at the ITSM A-Z.