An ITIL Process Conundrum

A student brought me up short on a recent course when we were discussing the distinction between incident management and problem management. We had been talking about the need for Incident Management to resolve the user’s issue quickly and the purpose of Problem Management to identify the root cause and provide a workaround or a permanent solution.

The scenario surrounding this particular conundrum goes like this. . . .

• A user contacts the service desk and complains that a particular document he is trying to print fails when sent to his local departmental printer.
• The service desk asks the user to redirect the print to a different printer (different manufacturer) two floors down.
• This is successful albeit very inconvenient. The service desk agrees with the user that this issue has been resolved and the incident can be closed.
• The service desk agent believes that this issue needs to be investigated further and raises a problem record.

• The problem management team eventually identify that there is a deficiency in the printer firmware and ask the manufacturer to provide a fix.
• Meantime, based on the experience from the incident, a Known Error record is generated containing details of the workaround that was successfully employed by the originating user.
• This is used on several occasions in the following months to resolve further similar incidents albeit with considerable inconvenience to the users concerned.

• Eventually, the printer manufacturer comes up with an updated version of the firmware. This is tested, found to be a valid solution and a change request is raised to roll the new version out to every printer of this make and model.
• No further incidents are raised.

• Sometime later the original user, based on prior experience, is directing his printed output to the printer two floors down. A colleague asks him why he is doing this. “Because our departmental printer can’t cope with this particular type of document” he replies.
• Well, I don’t have any trouble says the colleague – prompting to original user to try the local printer which, of course, works perfectly.

The IT service provider has clearly let down its customers/ users. But whose responsibility was it to advise the user-base in general, and this particular user in particular, that the workaround was no longer necessary. What went wrong? How would you change processes to improve the communication flow?
Stuart Sawle
http://www.sysop.co.uk

The Challenges of Managing Change Effectively

One of the significant improvements with ITIL v3, way back in 2007, was recognition of the need to move the change authorisation window further up the lifecycle. No longer, we thought, would change authorisation be sought when the development work had been completed and operational running was imminent. No longer would changes be “thrown over the wall” giving service operation scant notice – virtually blackmailing them into accepting the change.

Some progress has undoubtedly been made. Most customers tell me that operational acceptance is a key part of their change management process. But it still appears that change management is not considered until major investment of resources to design, build and test the change have already been committed.

Consider, if you would, what the core volumes say about the change proposal. It describes it as: “A document that includes a high-level description of a potential service introduction or significant change, along with a corresponding business case and an expected implementation schedule. Change proposals are normally created by the service portfolio management process and are passed to change management (i.e. the CAB) for authorisation. Change management will review the potential impact on other services, on shared resources, and on the overall change schedule. Once the change has been authorised, service portfolio management will charter the service.

Wouldn’t our services be managed more effectively if all major changes were reviewed and authorised at this stage. Consider the impact on the authority and reach of the change advisory board.

The reasons cited above all others for the failure of changes is lack of planning; lack of appreciation of the complexity; inadequate timescales; and inadequate budget for the change. How much better would we handle these matters if due consideration to change was given early enough?

Our purpose in service management is to facilitate change; to allow our organisations to adapt to changing business drivers speedily and effectively. We also have a duty to ensure that changes are implemented smoothly; without any detrimental impact on the business – i.e. get them right first time. Proper and timely scrutiny of change proposals will go a long way to achieving our objectives.

Stuart Sawle
http://www.sysop.co.uk

Making the Service Desk Count

Here at Sysop, we have spent a great deal of time in and around Service Desks of many shapes, sizes, skills and geographic dispersions. Distilling all of the feedback, It seems to me that creating a good Service Desk is all about understanding what the business needs from the desk and creating a function to support that need.

A Service Desk can be shaped to provide any type of service the business wants,  but it’s this very level of detail we need to be clear about and there are some vital steps that will help us to create the type of service our users expect.

We know that front line support is largely a thankless task. It takes a special kind of person to really do it justice. Resilience is certainly a vital quality, and something that most support people internalise and continue to develop of as a consequence of the day to day experiences of being in the front line. Resilience though is but one vital quality.

There are a number of very important factors that will help us in our pursuit of great staff and ultimately an acclaimed Service Desk. When we recruit and select Service Desk staff we must surely choose them because they demonstrated an appropriate level of skill, common sense and probably because we quite liked them. Yes, Likeability is an essential quality! So what else is needed?

Commitment—the Key

As either a stakeholder or user of Service Desk, we tend to expect a lot and give very little. I know the old adage “it’s better to give than to receive”, but the poor old Service Desk would have to be superhuman to have any sort of chance of be getting it right in many organisations.

The key is commitment – commitment from senior management, and commitment and passion from the line managers most closely involved

Heard it all before? Probably, but, let’s face it: if you don’t choose the right people; pay them the right salary; give them appropriate training; provide them with the correct tools for the job; and, most importantly, give them the autonomy they need; how can they ever provide the kind of service our users expect?

Walk the Walk

By management commitment I mean more than funding the desk. After the initial investment, it is imperative that senior managers continue to ‘walk the walk not just talk the talk’ on behalf of the Service Desk function. They need to: support the Service Desk; understand and respect their remit; back their decisions; extol their achievements; and conform to due process like all other users.

The Service Desk will fail to be successful if senior managers (and their PA’s!) don’t respect its position. The Service Desk should have: a defined remit and agreements to conform to; priorities to commit to; and a host of activities to complete to keep the wheels in motion. Senior managers must not be allowed to ‘jump the queue’ for non-critical requests.

It is essential in developing and maintaining a good desk that they too commit to and support the agreements that govern the Service Desk. If the Service Desk is delivering service in accordance with well thought-out SLA’s then they should be meeting the needs of all parties, even the senior management team.

Gaining the buy-in and commitment is probably the most exacting challenge facing IT service managers. It’s certainly the most common weakness we come across when helping customers improve their services. It helps when a third-party advocate makes the case to senior management. It’s easier for a Sysop consultant to challenge senior management attitudes and behaviours than it is for an in-house manager. Give us a call, we can almost certainly help.

Stuart Sawle

Thanks to Michelle Major Goldsmith for her contribution to this blog

Getting to Grips with Problems

First of all, thanks to my colleague John Allder for prompting me on the topic of root-cause analysis or more simply put: getting to grips with problems.

The phrase ‘root cause analysis’ is often used in a general sense to describe the activity of identifying the underlying cause of an incident.  However, the phrase Root Cause Analysis (RCA) is also given to a specific technique that is intended for use in investigating a series of actions or occurrences that lead to an undesired outcome.

Every major problem should be reviewed to learn lessons for the future.
• What was done correctly
• What was done wrong
• What could be done better in future
• How to prevent recurrence
• Whether there has been any third-party responsibility and whether follow-up actions are required

RCA helps to identify not only what happened and how it happened but also why. Only by understanding why will we be able to devise workable corrective measures. For instance, suppose a network technician disconnects a working router rather than a broken one. A typical investigation might conclude that human error was the cause and recommend better training or that technicians should take more care but neither of these is likely to prevent future occurrences. RCA assumes that mistakes do not just happen but that they have specific causes, and would ask ‘why?’ In the case of the poor network technician the RCA analyst might ask ‘was the router properly labelled?’, ‘was the technician told which router was faulty?’, ‘is there a recognised procedure for deciding whether a router is working or not?’, ‘did the technician know what it was?’

Root causes have four characteristics:
1. They are specific causes: ‘human error’, for example, is too general.
2. They are causes that can reasonably be identified: RCA must be cost beneficial so the analyst must know when to stop the investigation.
3. They are within the control of the management of the organisation. The analyst is looking for causes that can be addressed by the organisation. Although adverse weather conditions might very well have triggered the incident, we cannot do anything to affect the weather and so that is not an appropriate root cause. We can of course do something about how we are impacted by adverse weather and perhaps our root cause / resolution might lie there.
4. They can be addressed by specific solutions. A vague recommendation such as ‘ensure that technicians follow defined procedures’ is wholly inadequate and probably means that more thought needs to be given to identifying the specific cause.

RCA is a specific discipline. It follows four distinct phases:

• Data Collection
• Charting
• Root Cause Identification
• The Development of Recommendations

Carried out properly, Root Cause Analysis will ensure that an organisation learns all of the lessons from a major disruption to service and reduce the risk of future failures. It will help staff to identify ways not only of reducing the likelihood future disruption, but also of limiting the impact of any disruption that does occur.

http://www.sysop.co.uk

Selling Change to the Team

Isn’t it amazing how we can use a simple phrase that would actually lead to our undoing – making it difficult, if not impossible, to actually achieve what we intend.

If your approach is to “sell” the idea of change to the team they will see right through you. The change becomes more about what you want; change is being imposed; those whose co-operation you seek will react with the smile that says “yes boss, no chance”. And that’s the best you can hope for – the more recalcitrant ones will actively work against you.
Change needs to be managed, people need to be understood and involved.

I well remember a reorganisation at Woolworth’s when a manager, I regarded as a fool, was appointed as my boss. He took the trouble to have a face to face chat with me. He allowed me to express my fears and concerns. He listened to me and sought to find ways in which we could work together. It worked. Not only did we develop a fruitful, purposeful relationship – we became firm friends and still are – some 30 years later. He even acted on some of my advice to downplay some of his traits that led people like me to dismiss him as fool!

If you think a change is needed quickly, take time out to assess whether the drivers are really that urgent. We can be so go-minded that we can overlook this simple check. Consider would a more relaxed time-frame still achieve your objectives? Would taking a little more time to consult and truly involve those affected make your decision more acceptable? Would the ideas and discussions allow you to improve the quality of the change?

As a senior manager you probably relish change and thrive on it. Be aware that the chief insecurity of most staff is change itself. Their first reaction will be to feel threatened.

Remember, like grief, there is a series of stages that people go through before they become accepting of change. From suspicion, through curiosity, to visualisation, acceptance and finally commitment, your team members need to be allowed the time, and your time, to explore, understand and respond.

Stuart Sawle              http://www.sysop.co.uk

Change Management – Managing Change

Within the disciplines of IT service management we tend to think we’re pretty adept at managing change – after all a big chunk of our responsibility is about making sure that the changes are implemented for the business reliably, safely and accurately and in a controlled and disciplined manner. However that’s Change Management in ITIL speak. I’m talking here about managing those changes that affect you and / or your teams.

I think it’s a hugely ironic that IT specialists at the forefront of implementing change for the business are, as a group, most resistant to change themselves. That makes it very difficult to develop a culture of continual service improvement and to implement a framework like ITIL®.

It is widely accepted that the top three barriers to service improvement are:
• Plan, Do, Stop
• Saying Yes and meaning No
• Lack of Commitment from senior management.
Planning and acting to overcome these three obstacles is a crucial element in any programme of change.

Resistance is good. Winning people over helps validate that Yes really means Yes and that the improvement programme will continue even when the initial focus is switched elsewhere.

Management commitment is more difficult but goes to what I said in an earlier blog about speaking truth to power. All too often I see projects effectively killed off because senior managers display an attitude characterised by “You have my full commitment – just so long as you don’t need my time, effort, budget or involvement”.