I’m going back to the point raised by Peter, as mentioned in this post from last week (specifically Peter has to improve service with a reducing budget, demoralised staff and reducing headcount).
I’ll recap on some of the things I’ve covered:
- The importance of setting yourself specific, real, measurable objectives.
- Avoiding unnecessary complexity.
- How important roles and responsibilities are. This topic is bound up with team structure as well, but I’ll blog about that at a later date.
This blog post will be about shared vision and understanding in IT Service Management, and how important it is that, as a manager, Peter works to achieve this (excuse the term ‘shared vision..’ even though it sounds like something David Brent might bang on about).
Let me start by saying what I would not do. I would not want to be a Moses figure coming down from the managerial mountain with ‘the process’ or with ‘an ITIL vision’ handing out papers, processes and directions. This can engender a feeling of antipathy before you even get started the way that any change imposed in a work setting can do (my experience of working life gathered in the last 25 years is that generally people are resistant to change – even in IT – where technological change is viewed very differently to organisational change). Remember that your staff may think they currently do a great job, even if customers think they do not.
What I would do, and have done in the past, is to persuade that we need to do things better and differently, and to encourage people at all levels to suggest how.
As always though, there is a right way and a wrong way. Don’t ask your staff to write down suggestions and send them to you – the chances are you’ll get almost no response. Many people are intimidated by blank sheets of paper (even me, from time to time).
A better approach is to organise (i.e., chair) workshops where people can suggest improvements. However, organise these after you’ve applied some thought yourself about the problem(s) as you see it, so if the workshop is slow to get started you can prod it into life. Make careful notes during the meeting, and report back promptly afterwards.
At all costs avoid the workshop turning into a festival of moans. The first of these I ever organised did exactly this, with the 1st-line team immediately saying “the network team cherry-pick Incidents leaving behind stuff they don’t like the look of”. As it happened this was true, but with network team members in the room the tone became confrontational.
At the time I handled this badly. What I’d do now would be to re-state the negative in a more neutral way, as in ‘You mean some Incidents you assign to the network team are not being handled as quickly as customers would like’ and try to move onto a more consensual tone.
During these workshops, some people will contribute a lot, others a little or nothing. If you are reorganising and creating new roles (such as an Incident Manager or Service Level Manager) try to reward the most interested and positive with new roles, rather then simply choosing people based on seniority (though I know that can be controversial).
I’ll continue this theme in future posts, looking at some of the specific ITIL disciplines Peter might consider.