Service Desk Triangle – can you see it from my (SDM) angle?

One thing that strikes a chord with many of my clients is a simple concept that I’ve used for some time, although only recently defined more explicitly. This centres around the role of the Service Desk Manager (SDM), which for me is still the pivotal role in ITSM. I act as a mentor for this role with some clients and help them to put theory into practice for success in the job.

The idea is around the communications and stakeholder ‘juggling act’ that the SDM has to carry out daily – I call this the Service Desk Triangle. This refers to the 3-way pull on the SDM that can potentially result in them disappearing without a trace – i.e. like into the ‘Bermuda triangle’…

service desk triangle

 

Basically there are 3 very distinct stakeholder groups that they have to manage and keep happy and on-side, namely:

1 The Service Desk team – who need specific management and TLC, as they operate in a front-line service role with specific time demands and a daily dose of negative interactions. These people need a mixture of clear and structured management with supportive staff coaching and support, to keep motivated and maintain quality.

2 Customers – who obviously have a different set of expectations and requirements which need to be met and managed professionally and effectively, as the service desk is the ‘shop front’ for the whole of the IT organisation.

3 The rest of the IT organisation – i.e. part of the service desk’s team, but often its biggest problem area. Successful and integrated service delivery requires seamless teamwork across IT teams in support of the service desk and its customers, but this doesn’t always happen…!

The SDM needs to build effective relationships and get agreement from their colleagues across IT to make service an effective ‘supply chain’. So they have to be parent, coach, service provider, diplomat and negotiator, to name but a few roles, as well as of course marketer, salesperson, tough manager, mentor, analyst and master of ceremonies…!

I know from experience how tough it is when all three of these areas are out of sync and bearing down on the beleaguered SDM. On the other hand it’s very rewarding when the juggling is working and all three stakeholder groups are content.

It is a good practical approach if the SDM does some analysis and ‘stakeholder mapping’ to keep tabs on what each area’s requirements, issues, preferences and idiosyncrasies are – this can help by providing an ongoing pain and/or satisfaction barometer for the SDM to monitor and act on accordingly. The SDM also needs to have a deep portfolio of communications and influencing skills to be able to understand and satisfy each different agenda.

 

So, if you are engaged in some way with the Service Desk from the outside, it does no harm to consider the SDM’s daily challenge, keeping disparate sets of people and teams happy simultaneously – give it some thought, put yourself in their shoes for a while and ‘see it from their angle’… 

Maybe also if you do this you could see and act on ways to make the triangle a bit less of a challenge for the SDM? What do you think?

Problem Management Success – Start Using Causal Closing Codes

slide2

Many organisations struggle to make
Problem Management work effectively.

For me there are a number of reasons for this – many to do with getting the right people to do the right job.

One key area which is vital to develop for this is reporting, particularly to start to really identify underlying causes and trends – e.g. for incidents. If you close your incidents off against the initial (logging) categories that you’ve used to identify the incident, you may miss the reason why the incident actually happened. So closing against ‘software’ may be useless to you if the cause was actually a user or 3rd party error.

So it’s important and useful to use separate ‘closing’ categories or ‘causes’ for logging categories or impact etc. – these are different things.

Here is a suggested list of closing or ’cause’ codes to help you to identify trends and make some sense and provide MI around root cause etc.

Known/Standard Error

  • existing issue, fault or request known, with workaround to maintain service

Process Failure 

  • no relevant process
  • process not adequate
  • governance – process not followed

Resource Issue

  • Skill/knowledge issue
  • Availability issue

External Issue

  • 3rd party system issue
  • environment issue

User Issue

  • user error
  • training issue
  • Policy issue

Hardware Failure

  • xxx as required

Security issue

  • password reset
  • access issue

Systems Issue

  • networks
  • infrastructure
  • operating systems failure
  • xxx as required

Software Issue

  • design issue
  • build issue
  • test issue
  • service introduction issue

Contract/Commercial Issue
Information

  • technical information given
  • ‘how to ‘ question answered

Request or Order Fulfilled

Cause Unidentified

  • service resumed, cause unknown

(Optional to be used by limited SD people only) usually should be passed to problem management, but in some cases the cause is unknown. To be used with care and to avoid having ‘other’ as an option.

How effective is the reporting in your area of influence right now?

Are you already using causal closing codes?

Do they work for you and if so, which ones in particular?

Tips for ITSM Goodness

I presented a big list of little tips at the recent OVUM conference on ITSM in London:

Here’s the slides  OVUM presentation 20 tips

 

Plus Some additional short tips

  1. If you are going to do an ITSM project, clarify what it will deliver for your organisation
  2. Somehow the myth that ITIL  is a panacea still prevails – dispel it
  3. No matter what anyone says, you can’t just buy ‘ITIL’ / ITSM off the shelf + do it in a few weeks
  4. You can achieve a lot of small targeted incremental service improvements in 30 days
  5. Getting a system running quickly isn’t a new cure-all, ITSM goodness takes time
  6. If you need funds for ITSM then define what this will deliver in simple business terms (1 slide?)
  7. Don’t be too ambitious for your ITSM project in terms of cost savings – it’s hard to quantify
  8. You can define benefits in terms of service quality + risk reduction, as well as cost benefit
  9. The way you set up your ITSM project is as important as how you deliver it – objectives, outcomes, project – people, skills, realistic planning
  10. If you don’t have a clear definition of what you do in IT, how can you know if you’re doing a good job?
  11. ITIL training will help staff to learn ITSM + use the same language, but won’t change the organisation
  12. There’s a whole group of people who just need an ITSM overview session rather than a 3 day foundation course
  13. 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
  14. For your Service Catalogue think (internal) IT services like email + support, + (external) business services that do what the organisation does
  15. SLM, SLAs + Service Catalogue – all must be done with customers – otherwise it’s old IT arrogance
  16. Let’s move our IT organisation from providing systems to delivering Services
  17. IT is + should be part of the business not a separate (necessary evil) function
  18. Let’s not think of running IT ‘as’ a business but ‘like’ a business – + part of it
  19. It’s the (project) process that counts with SLM – i.e. talking/listening to your customers
  20. ‘We did SLAs before + no-one was interested’ – no wonder if they were IT-only driven
  21. If your SLA document is more than a couple of pages then it’s an SLD – service level disagreement
  22. Don’t write SLAs as if you are writing a legal document – keep it simple + avoid IT jargon
  23. Don’t bother trying to do CMDB unless you are really sure why + for what result
  24. If you must do CMDB then don’t give the project to a tech person
  25. CMDB – be clear on your criteria for defining + storing CIs
  26. Too many well-meaning CMDB projects have failed by trying to do too much – ‘boiling the ocean’
  27. Actually, the whole concept of a single CMDB/CMS is flawed + in reality doesn’t exist
  28. Metrics in isolation are dangerously misleading – its an eco-system which needs balance
  29. We need services/SLAs to give our metrics + KPIs relevance, otherwise we get what suits us in IT
  30. KPIs without balance + business context simply drive compliant behaviour – maybe at cost to the business
  31. Don’t think that anyone cares about blanket 99.9% ‘availability’ – 100% when it matters is what matters
  32. If you are going to talk about 1st/2nd/3rd levels of support, you need to define what these mean
  33. Generally it’s faster, cheaper + better for the customer if incidents are fixed at the first contact
  34. Change + release management really are ‘no-brainers’, although doing them with common sense is still rare.
  35. Problem management is more about ownership than just process – give the right person the job
  36. The Problem Manager is part analyst, part investigator, but mostly project manager completer-finisher
  37. In IT we like to build models, tools + processes rather than just managing people + issues
  38. ITIL is documented common sense, which is stilll a rare commodity. It also needs good management to make it successful
  39. Culture eats strategy for breakfast, lunch and dinner’

 

 

Should you centralise?

This month’s tip comes from a question sent in to me: 

“We have a number of corporate support areas and ‘helpdesks’. Would it make sense to try and centralise these and build a single central operation?”

While there’s no simple answer to this, I suggest a few key points to consider:

1) In general it will be more cost effective to centralise various support operations, as this will usually save through a single approach, use of tools and processes, reduction in licences,  reduction in overlapping activities etc.

2) It will usually be easier to manage a single operation and easier to get consistent delivery and management information

3) However you must be clear on the objectives of this, as the potential negatives and risks may be high to the business, such as:

  • Loss of key staff and skills, if jobs are seen to be downgraded
  • Difficulty in combining completely different types of operations, personality-types and skill levels – e.g. software support, telesales, building maintenance
  • The costs, time and resources required to consolidate the operations may be significant and outweigh the benefits, particularly in small organisations
  • Service and quality levels will almost certainly be adversely affected during the changeover period and this may expose the business to risk.

As ever, this sort of change project will need careful consideration, objective setting, cost/benefit analysis, detailed budgeting and planning, as well as quality project management in order to truly succeed.