BAU Improvements

In my last article on service improvement, I laid out four premises that underlie how I think we should approach CSI:

Process improvements evolve with time on railroads
  • 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 –

'Basic Service Management' by Rob England (a.k.a The IT Skeptic)

Basic Service Management by Rob England

This is a quick review of Rob England’s book ‘Basic Service Management’.

You can find out more about Rob’s book and the TIPU method here: If you want to share your own review please add a comment below.

In my opinion this is a well written introduction to service management.

This book might have also been called:

  • ‘Service Management in a nutshell’
  • ‘An introduction to Service Management’
  • ‘Service Management for Business Owners’
  • ‘The book on Service Management that you buy for your boss’ or
  • ‘How to introduce someone to service management without scaring the bejesus out of them by banging on about ITIL or other IT geekery’

I read this in one sitting and I’m not a fast reader. It is quick, accessible and thought provoking.

It is not an ITSM or IT book per se, in fact I think the best recipient of this book is a non-IT business owner or service owner who wants to appreciate the benefits of service management.

As an ITSM professional, this is the sort of book you need to send to those you wish to educate and influence about your chosen profession. Or as one Amazon reviewer put it: “I recommend reading it before you get lost in ITIL”. This would also be useful to an entrepreneur looking to start or scale their business.

Why Service Management?

“If you are reading this book, you probably don’t manage your services so much. That gives you an opportunity to increase revenues and profitability: improving your service brings increased efficiency and effectiveness. That means increased returns for much less investment than from improving your products or equipment”.

Rob England, The IT Skeptic

Rob is a great wordsmith and well respected in the ITSM industry – my only criticism of this book is that I wish he had used the power of metaphor, story telling or examples to describe his seven practice areas. The second half of the book tends to slide into a glossary of his basic service management terms and bullet points. I thought this might have been a perfect opportunity for Rob to use some examples in order to reinforce his message and walk the reader through his ‘Seven Areas’ rather than explaining principles in purely theoretical terms.

In the ‘How to Use this Book’ section Rob urges the reader to “Read it, It is short”. In a similar fashion my advice to you as an ITSM professional is, “Buy it, it is good”.

Have you read Rob’s book? Please share your opinion in the comments below.