Part 11 of the Sensible Service Management Series from Rob England, aka @theITskeptic
Right back at the start of this series on Sensible Service Management, I noted: SM process improvement can deliver on four top goals of an enterprise:
- Successful daily operations
- Growing the business
- Controlling costs
- And keeping customers happy
You’ll deliver on these goals when you work to improve three areas: (1) how you respond to user requests, (2) how you fix things and (3) how you control changes to make sure you don’t break things in the first place.
We’ve already discussed the practices in those three areas, and we’ve looked at the principles of measurement. Now at last we look at how to go about improvement.
Focus on outcomes
Think about the practices and functions we have discussed already that are required for services to be delivered well: service desk, incident, major incident, request, change, release and problem. If any one of these is not being performed, or not to an adequate level of capability, then there is a risk to delivery of services.
Which of these practices and functions require some improvement in your organization? It might be easier to list those that do notrequire any improvement. There is a lot to consider when improving services.
How then to cover everything that needs to be examined? The key word here is “needs.” We should understand what are our business goals for service, derive from those goals what are the required outcomes from service delivery, then focus on improvements that deliver those required outcomes … and nothing else.
One way to improve focus is to work on smaller units than a whole practice. A major shortcoming of many IT service management projects is that they take the ITIL “processes” as the building blocks of the program. “We will do Incident first.” “We can’t do Change until we have done Configuration.” Even some of the official ITIL books promote this thinking.
Put another way, you don’t eat an elephant one leg at a time: you eat it one steak at a time… and one mouthful at a time within the meal. Decomposes the service management practices into smaller, more achievable units of work, to assemble Lego-style into a solution to the current need. The approach goes like this:
The value we are asked (or propose) to produce is A.
Therefore the organizational goals or objectives are B.
Therefore the improvement outcomes required are C.
Therefore the program outputs to be produced are D.
These outputs come from practices E, F and G.
Specifically they come from the following bits of those practices H thru Z.
By breaking it down into only the bits that compose a solution to deliver to a business value, rather than working on a whole practice for its own sake, we are starting on the outside and drilling in, focusing on demonstrable value.
Incident Management can be broken down into separate units of work:
• Incident tracking
• Incident impact assessment
• Incident escalation
• Incident resolution
• Incident reviews and reporting
• Incident matching
Some of these have dependencies on others. In other cases, they can be improved independently.
These tasks don’t attempt to be a complete description of Incident Management. There will be other pieces of work we could do later.
This helps us to shortlist improvements and to narrow the scope of work.
Frequently the business goals are general: “improve quality,” “cut costs,” “retain customers”… This throws a wide net, so it is often the case that our “shortlist” is still overwhelming. How to address everything? Don’t!
Every organization carries risk – we live with it, we manage it. Usually, the ideal state is unachievable ‒ a realistic compromise must be found. This hinges around an acceptable level of known risk from unaddressed requirements.
We must consider available time and resources and then develop a Continual Service Improvement (CSI) Plan to work on only those tasks with which we can deal given the constraints. The hard calls have to be made: what is in and what is out. This should be a collaborative exercise; everybody needs to understand the hard decisions that were made.
It helps to sort the tasks by what they deliver: business value, risk reduction and/or compliance.
It is better to manage a known risk caused by an improvement being left to later, than to have an unknown and unmanaged risk resulting from it being neglected. Leaving work to later does not mean these improvements are any less important. All selected improvements are important. A reality check says that they can’t all be done in the immediate future, so we have to defer something. We all defer work anyway: this approach manages it and makes it a known risk instead of turning a blind eye.
Managing the work
When we look at the list of improvements that absolutely must be done and cannot be left for later, how should we approach them?
We could form a project or projects to make the improvements. A project approach is structured and controlled and carefully estimates the resource commitment before starting. A project approach also considers the best solution and ensures it is a complete one. Experience shows that improvement projects rapidly grow large. Improvement work also struggles to show a compelling business case, even when we have aligned it to business requirements. Partly this is because a good solution is expensive, and partly because much improvement is seen as “housekeeping”: non-strategic, non-transformational.
In small-to-medium enterprises there is even less appetite for formal projects. So I suggest you (mostly) don’t generally use projects to improve services.
Where else can we source the resources to make the improvements? From “business as usual” (BAU). Improvement is normal behavior for professionals. It is part of our job to devote a certain percentage of our time to improving the systems we work with. We should all expect that things will be better next year; that we will make a difference and leave systems better than we found them. Improvement is business as usual. We need to make this commitment.
It is better to commit most staff for a proportion of their time rather than a few staff dedicated fulltime to the program of work. This promotes buy-in, by involving all those affected. In a highly critical initiative, 10% of resource could be allocated. For most situations, 5% is more realistic, i.e. about 2 hours a week – on average – from everyone.
Take an agile approach. Work in cycles or “sprints.” Within each sprint, create small teams of two or three people and ask them to look at one or two improvements at a time, determine what can be improved, and make the improvements. The people who use the practices know best how to improve them. Empower staff to design and implement their own solutions.
By all means manage all these assignments as a portfolio using Program Management methods if you have the resources to do so, but do not manage the individual assignments as projects. If we subjected each team to project management by breaking down the assignment into tasks, then estimating, resourcing and tracking each task, the management overhead would swamp us.
(Note: you can spin off work into projects sometimes, where you recognise that the work
- will create a capital asset
- needs additional resources
- and/or is sufficiently complex that it is too risky without project management
Also, there is nothing to stop you managing other assignments using project management methods if you feel the need.)
As well as putting Program Management in place, you should also maintain a central plan and a central architecture of how your practices should hang together, to ensure everyone is heading in the same direction.
As I discussed in an earlier post, service improvement is behavioral improvement. People-change (also known as “culture change”) is at least as important as changing practices and technology. Better practices alone don’t fix anything (just as technology on its own doesn’t either). Improvements to practices only work if the behaviors of those affected change to adopt the new practices:
- Refine the practices (using best practice frameworks for reference as appropriate)
- Improve the technology to support them if necessary (often not)
- And most of all, change the behaviors of the people involved in order to adopt the new practices.
A good length for a sprint is two to three months. This sounds a long time, but it is not when considering human rates of change (as compared to technological ones). It is a short time when it comes to improving practices and changing behaviors. There is only so much that can be achieved by a small number of people devoting 5% of their time for a few weeks. Assignment teams must look for pragmatic outcomes that address the most urgent needs and/or the low-hanging fruit.
Some progress is better than nothing. If we try to take a formalized project-managed approach to service improvement, the outcome for the few aspects addressed by the projects will be a good complete solution… eventually, when the projects end. Unfortunately, the outcome for the many aspects of service delivery not included in the projects’ scopes is likely to be nothing. Most organizations don’t have enough funds, people or time to do a formal project-based improvement of every aspect of service management. We aim to address a wider scope than projects can – done less formally, less completely and less perfectly than a project would.
In many situations, “best” is overspending: “good enough” will do (“copper not gold”). And for many – perhaps most – organizations, it is all very well for the experts to go on about “have to” and “must,” but there is only so many resources ,available and we must work within the bounds imposed on us. The ideal gives us something to aim for but we should accept when we cannot achieve it.
Even though you don’t have to improve for ever, don’t stop once you have done what you set out to do, for three reasons:
1) Anything left alone will run down. You need to keep it alive, keep it working.
2) The world changes, requirements shift; you need to continually adjust.
3) Most organizations want to continue to improve, to keep getting better.
It is a journey that never ends. Service management transformation is not a project with an end-date. Assign it to someone and make them accountable. It is continual not necessarily continuous: you don’t have to work on it every day but you do need to keep coming back to it. Implement that formal improvement program. Get into this continual cycle: check your current state; plan where you want to be and how to get there; act to make it happen. (The most common version of this cycle is known as the Deming Cycle of Plan-Do-Check-Act, but I think Check-Plan-Act makes is more logical. I first saw it in Understanding Your Organization as a System, Vanguard Consulting, 2001, http://www.systemsthinking.co.uk/5-1.asp).
Too many change programs lose momentum because management moves on or loses interest. This has facetiously been described as Plan-Do-Stop. This is why you need an on-going formal program of work to provide continuity and permanence.
Not familiar with GoToAssist Service Desk yet? Support teams can quickly and easily log and track incidents, deliver end-user self-service and manage configurations. The GoToAssist Service Desk tool provides a simple, intuitive way to more effectively manage IT operations and gain visibility into IT services. Try it free for 30-days, start using GoToAssist Service Desk today!