Culture

For some time and particularly when ITIL started to gain prevalence, it was taken as read by many (including many senior IT people) that the Service Desk WAS ITIL and ITSM. Often this extended to software, where people referred to the ITSM tool as the ‘service desk’, or ‘ we need to buy a new service desk’ etc. A ‘service desk’ is an operational team of people delivering a time-based support service, not a piece of software.

However, this misconception has also pervaded across people in IT organisations in such a way that they would see an ITSM implementation as ‘something that the service desk does, not something I need to get involved in, thankfully…’.

Nothing is further from the truth – true many ITSM implementations have a central focus around the service desk, but the real success of service management as a ‘supply chain’ depends heavily on all parts of IT contributing and playing their part.

The first level fix is great if it can be achieved, but if it can’t then an escalation process is required (for dedicated second and third-level support) in order to meet the end-to-end Service SLA customer expectation a business outcome. We all know that resolution time is often greatly increased (at the customer and business’s expense), not by lack of knowledge or technical capability, but simply by delays in escalation, acceptance and relative priority of work.

So we need to communicate and involve and educate and get engagement across our supply chain, otherwise, our processes and services and SLAs are a wasted effort and not worth the paper they’re written on. Essentially much of the effort, that will determine the success or failure of an ITSM project comes down to how well we can motivate and engage with technical groups and people to follow new or updated support processes.

The big mistake that has been made over and again in this area is the classic IT approach of ‘right, we’ll do ITIL training, update our processes and all will be fine’. Of course, processes don’t happen by themselves and if they are not explained, simplified and enforced, then they get ignored. This still happens although thankfully less regularly.

So it’s about “culture change” right?

Well yes, although here is where it has once again tended to fail by assuming that culture change is yet another process or binary tool that can be implemented using PRINCE2, or software distribution tools…

The assumption has often been taken that, for this project to succeed, we’ll need to ‘change people’, ‘they’ll need to change their attitude’ etc – all often well meant and based on the fact that some people aren’t perhaps performing or delivering as they should. This also can be misleading if there are not clear guidelines as to what people are led to deliver, however many projects do have a ‘culture’ or communications stream, when what they really need is the application of good management, leadership, clear ownership and governance.

We can’t change people, but we can change the environment that they operate in, such that they might decide to change their behaviour and performance.

Good project and operational communications are absolutely vital for success, but they also need to be backed up by strong visible management to enforce the processes and agreed practices that emerge – the iron glove.

For the velvet fist, we should be explaining, consulting, involving and engaging with as many people as possible to ensure that they follow due process for the right reasons – i.e. they see the value in doing so.

It’s not just the service desk

It’s not just about the process – governance is key Processes, RACI etc must be end to end across the organisation for these to work for the customer. This is why we refer to the IT ‘supply chain’ – ITSM processes require ownership across the supply chain and traditional Silo organisations and management structures don’t recognise that.

Key Points

1. Culture and communications must be considered and planned for, but don’t expect to change people overnight, if at all
2. Senior Management must visibly support these projects
3. Planning and operations must include governance – ie how will ensure that processes are followed?
4. In order to make successful ITSM processes work as a supply chain, we need to cut across the traditional management structure.

ITSM goodness tips

• Processes don’t happen or work by themselves – if there’s no governance then they’re a waste of time
• Documentation is good – but engagement, empowerment and attitude are even better
• Understanding technology is good, but understanding people and culture is even more useful
• So, putting in a last-minute-on-Friday-that’s-not-been-fully-tested change will be fine, won’t it..?!?
• Every minute that IT ping-pongs faults/incidents about, is expensive lost business time
• IT organisations must function as a service supply chain – not a group of great technical teams
• It’s simple – fix it the first time and fast, or better still, stop it failing at all.
• 3 simple tips to make processes effective – ownership, ownership and ownership
• Somehow the myth that ITIL is a panacea still prevails – dispel it
• No matter what anyone says, you can’t just buy ‘ITIL’ / ITSM off the shelf + do it in a few weeks
• ITIL training will help staff to learn ITSM + use the same language, but won’t change the organisation
• There’s a whole group of people who just need an ITSM overview session rather than a 3-day foundation course
• The tech guys just need to be told what to do + what’s in it for them, don’t ask them to define strategy + processes
• ITIL is documented in common sense, which is still a rare commodity. It also needs good management to make it successful
• ‘Culture eats strategy for breakfast, lunch and dinner’