In my last article on service improvement, I laid out four premises that underlie how I think we should approach CSI:
- Everything we change is service improvement.
- Improvement planning comes first.
- We don’t have enough resource to execute all desired improvements.
- We choose the wrong unit of work for improvements.
What are the desired business outcomes?
We must focus on what is needed. To understand the word ‘needed’ we go back to the desired business outcomes. Then we can make a list of the improvement outputs that will deliver those outcomes, and hence the pieces of work we need to do.
Even then we will find that the list can be daunting, and some sort of ruthless expediency will have to be applied to choose what does and doesn’t get done.
How will you resource the improvements?
The other challenge will be resourcing the improvements, no matter how ruthlessly we cut down the list. Almost all of us work in an environment of shrinking budgets and desperate shortages of every resource: time , people and money. One way to address this is to do some of the work as part of BAU.
These are all aspects of my public-domain improvement planning method, Tipu:
- Alignment to business outcomes
- Ruthless decision making
- Doing much of the work as part of our day jobs
Let me give you two more premises that build on the first four and take us to the heart of how I approached service improvement with Tipu.
Fifth premise: Improvement is part of a professional’s day job
Railroads work this way. Process improvements evolve over time on the job. The only time they have a formal process improvement project is for a major review: e.g. a safety campaign with experts checking the practices for safety risks; or a cost-cutting drive with time-and-motion analysts squeezing out efficiencies (we call it Lean these days). Most of the time, middle managers and line workers talk and decide a better way as part of their day jobs, often locally and often passed on as unwritten lore. Nobody in head office knows how each industrial track is switched (the wagons shuffled around: loads in, empties out). The old hands teach it to the newcomers.
Most improvement is not a project. Improvement is normal behaviour for professionals: 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. We should all expect that we will make a difference and leave systems better than we found them. Improvement is part of business as usual.
As a culture, IT doesn’t take kindly to ad-hoc, local grass-roots, unmanaged improvements. We need to get over that – we don’t have good alternatives if we are going to make progress.
Sixth premise: Software and hardware have to be near-perfect. Practices and processes don’t.
The tolerances for the gap between wheels or rails are specified in fractions of a millimetre on high-speed track. Even slow freight lines must be correct to a few millimetres, over the thousands of kilometres of a line. And no the standard 4’8.5” gauge has nothing to do with Roman chariots. It was one of many gauges in use for mine carts when George Stephenson started building railways, but his first employer happened to use 4’8”. Sorry to spoil a good story about horse’s butts and space shuttles.
Contrast the accuracy of the technology with the practices used to operate a railroad. In the USA, freight train arrival times cannot be predicted to the nearest half-day. (Let’s not get into a cultural debate by contrasting this with say Japanese railroads. To some, the USA looks sloppy. They say it is flexible.) Often US railroads need to drive out a new crew to take over a train because the current crew have done their legally-limited 12 hours. Train watchers will tell you that two different crews may well switch a location (shuffle the wagons about) differently. Compared to their technology, railroads’ practices are loose. Just like us.
In recent years railroad practices have been tightened for greater efficiency (the New Zealand Railways carry more freight now with about 11,000 staff than they once did with 55,000) and especially for greater human safety. But practices are still not “to the nearest millimetre” by any means.
Perfection is impossible
We operate with limited resources and information in an imperfect world. It is impossible for an organisation to improve all practices to an excellent level in a useful time. Therefore it is essential to make the hard decisions about which ones we address. Equally it is impossible – or at least not practical – to produce the perfect solution for each one. In the real world we do what we can and move on. Good enough is near enough except in clearly identified situations where Best is essential for business reasons. Best Practice frameworks not a blueprint: they are a comparison reference or benchmark to show what would be achieved with unlimited resources in unlimited time – they are aspirational.
Some progress is better than nothing. If we try to take a formalised 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, if the money holds. Unfortunately, the outcome for the many aspects of service delivery not included in the projects’ scope is likely to be nothing. Most organisations don’t have enough funds, people or time to do a formal project-based improvement of every aspect of service management. Aim to address a wider scope than projects can – done less formally, less completely, and less perfectly than a project would.
We can do this by making improvements as we go, at our day jobs in BAU. We will discuss this ‘relaxed’ approach more fully in future.
We need an improvement programme to manage the improvements we choose to make. That programme should encompass both projects and BAU improvements.
Project management is a mature discipline
The management of projects is a mature discipline: see Prince2 and Managing Successful Programmes and Management of Portfolios and Portfolio Programme and Project Office, to name just the four bodies of knowledge from the UK Cabinet Office.
What we are not so mature about is managing improvements as part of BAU.
The public-domain Tipu method focuses on improving the creation and operation of services, not the actual service systems themselves. The former is what BAU improvements should focus on. i.e. Tipu improves the way services are delivered, not the functionality of the service (although it could conceivably be used for that too).
Service owners need to take responsibility for improvements
The improvement of the actual services themselves – their quality and functionality – is the domain of the owners of the services: our IT customers. They make those decisions to improve and they should fund them, generally as projects.
On the other hand, decisions about improving the practices we use to acquire/build and operate the IT machinery of services can be taken within IT: they are practices under our control, our authority, our accountability. They are areas that we are expected to improve as part of our day jobs, as part of business as usual.
We’ll get into the nitty-gritty of how to do that next time.
image credit – © Tomas Sereda – Fotolia.com