Everything is improvement

Traditionally Continual Service Improvement (CSI) is too often thought of as the last bit we put in place when formalising ITSM.  In fact, we need to start with CSI, and we need to plan a whole portfolio of improvements encompassing formal projects, planned changes, and improvements done as part of business-as-usual (BAU) operations.  And the ITIL ‘process’ is the wrong unit of work for those improvements, despite what The Books tell you. Work with me here as I take you through a series of premises to reach these conclusions and see where it takes us.

In my last article, I said service portfolio management is a superset of organisational change management.  Service portfolio decisions are decisions about what new services go ahead and what changes are allowed to update existing services, often balancing them off against each other and against the demands of keeping the production services running.  Everything we change is service improvement. Why else would we do it?  If we define improvement as increasing value or reducing risk, then everything we change should be to improve the services to our customers, either directly or indirectly.
Therefore our improvement programme should manage and prioritise all change.  Change management and service improvement planning are one and the same.

Everything is improvement

First premise: Everything we change is service improvement

Look at a recent Union Pacific Railroad quarterly earnings report.  (The other US mega-railroad, BNSF, is now the personal train-set of Warren Buffett – that’s a real man’s toy – but luckily UP is still publicly listed and tell us what they are up to).

I don’t think UP management let one group decide to get into the fracking materials business and allowed another to decide to double track the Sunset Route.  Governors and executive management have an overall figure in mind for capital spend.   They allocate that money across both new services and infrastructure upgrades.

They manage the new and existing services as a portfolio.  If the new fracking sand traffic requires purchase of a thousand new covered hoppers then the El Paso Intermodal Yard expansion may have to wait.  Or maybe they borrow the money for the hoppers against the expected revenues because the rail-yard expansion can’t wait.  Or they squeeze operational budgets.  Either way the decisions are taken holistically: offsetting new services against BAU and balancing each change against the others.

Our improvement programme should manage and prioritise all change, including changes to introduce or upgrade (or retire) services, and changes to improve BAU operations.  Change management and service portfolio management are both aspects of the same improvement planning activity.  Service portfolio management makes the decisions; change management works out the details and puts them into effect.

It is all one portfolio

Second premise: Improvement planning comes first

Our CSI plan is the FIRST thing we put together, not some afterthought we put in place after an ‘improvement’ project or – shudder – ‘ITIL Implementation’ project.
UP don’t rush off and do $3.6 billion in capital improvements then start planning the minor improvements later.  Nor do they allow their regular track maintenance teams to spend any more than essential on the parts of the Sunset Route that are going to be torn up and double tracked in the next few years.  They run down infrastructure that they know is going to be replaced.  So the BAU improvements have to be planned in conjunction with major improvement projects.  It is all one portfolio, even if separate teams manage the sub-portfolios.  Sure miscommunications happen in the real world, but the intent is to prevent waste, duplication, shortages and conflicts.

Welcome to the real world

Third premise: we don’t have enough resource to execute all desired improvements

In the perfect world all trains would be controlled by automated systems that flawlessly controlled them, eliminating human error, running trains so close they were within sight of each other for maximum track utilisation, and never ever crashing or derailing a train.  Every few years governments legislate towards this, because political correctness says it is not enough to be one of the safest modes of transport around: not even one person may be allowed to die, ever.  The airlines can tell a similar story.   This irrational decision-making forces railroads to spend billions that otherwise would be allocated to better trackwork, new lines, or upgraded rolling stock and locos.  The analogy with – say – CMDB is a strong one: never mind all the other clearly more important projects, IT people can’t bear the idea of imperfect data or uncertain answers.
Even if our portfolio decision-making were rational, we can’t do everything we’d like to, in any organisation.  Look at a picture of all the practices involved in running IT

You can’t do everything

The meaning of most of these labels should be self-evident.  You can find out more here.  Ask yourself which of those activities (practices, functions, processes…  whatever you want to call them) which of them could use some improvement in your organisation.  I’m betting most of them.
So even without available funds being gobbled up by projects inspired by political correctness, a barmy new boss, or a genuine need in the business, what would be the probability of you getting approval and money for projects to improve all of them?  Even if you work at Google and money is no problem, assuming a mad boss signed off on all of them what chance would you have of actually getting them all done?  Hellooooo!!!

What are we doing wrong?

Fourth premise: there is something very wrong with the way we approach ITSM improvement projects, which causes them to become overly big and complex and disruptive.  This is because we choose the wrong unit of work for improvements.

How to cover everything that needs to be looked at?  The key word there is ‘needs’.  We should understand what are our business goals for service, and 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 programme.  ‘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.  Especially when the elephant has about 80 legs.

Don’t eat the whole elephant

We must decompose the service management practices into smaller, more achievable units of work, which we assemble Lego-style into a solution to the current need.  The objective is not to eat the elephant, it is to get some good meals out of it.
Or to get back to railroads: the Sunset Route is identified as a critical bottleneck that needs to be improved, so they look at trackwork, yards, dispatching practices, traffic flows, alternate routes, partner and customer agreements…. Every practice of that one part of the business is considered.  Then a programme of improvements is put in place that includes a big capital project like double-tracking as much of it as is essential; but also includes lots of local minor improvements across all practices – not improvements for their own sake, not improvements to every aspect of every practice, just a collection of improvements assembled to relieve the congestion on Sunset.

Make improvement real

So take these four premises and consider the conclusions we can draw from them:

  1. Everything we change is service improvement.
  2. Improvement planning comes first.
  3. We don’t have enough resource to execute all desired improvements.
  4. We choose the wrong unit of work for improvements.

We should begin our strategic planning of operations by putting in place a service improvement programme.  That programme should encompass all change and BAU: i.e. it manages the service portfolio.

The task of “eating 80-plus elephant’s legs” is overwhelming. We can’t improve everything about every aspect of doing IT.   Some sort of expediency and pragmatism is required to make it manageable.  A first step down that road is to stop trying to fix things practice-by-practice, one ITIL “process” at a time.

Focus on needs

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.

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– as I’ve already hinted – 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

More of this in my next article when we look closer at the Tipu approach.

9 thoughts on “Everything is improvement”

  1. You do need to start with “What is our business?” and figure out how everything you do enhances that business. There is plenty of books/journals and the like written about how a lot of businesses get this wrong…or had it right but then…lost focus.

    That concept I think lines up well with what you are saying here (figure out what you “need”).

    I also think all change efforts should be managed holistically and from project conception to operational implementation. I’ve brought this up at Back2ITSM and other places.

    What I don’t quite buy is “every change is an improvement” – maybe one day I’ll come around. For now, I just don’t see it that way. Over 35% of businesses are apparently still running XP. Soon, they’ll be forced to move to Windows 7 (or 8) because XP will no longer be supported. They’ll do the change…not to “improve” anything but because it is basically required to stay in business. A law may come down to say you have to store all emails for 10 years – companies will do the technical and processes changes – but what was improved for their business? Nothing. It is just required. Keep the lights on…BAU…status quo.

    I just can’t imagine a board (or whomever) being “sold” some $25,000,000 spend to switch from XP to Windows 7 throughout the enterprise is an “improvement” when the only thing it is doing is keeping you “current” – no other reason.

    Perhaps it is just how I understand the word “improvement”- maintaining status quo does not qualify as an improvement to me.

    1. I’m not convinced there will be huge pressure to move away from XP. I’m more certain there will be huge pressure NOT to upgrade XP and use alternatives. e.g. XP as a dumb terminal to navigate VDI or Cloud Services?

      1. Perhaps. I think security vulnerabilities will push some organizations to migrate. Others may be contractual meaning, I am the service provider to you – I provide you desktops and desktop support – using XP I have a profit margin of X but contractually I have to be utilize HW/SW that is within vendor support – I may not have any other incentive to move away from XP other than this contract. I’ll incur a hefty cost to migrate that my profit model may not be able to cover – or possibly not for some time. Anyway, that is also possible…

    2. Let me turn that around. Why would you spend $25M to upgrade Windows if it didn’t improve something?
      it improves your ability to stay in business.

      And conversely, if it doesn’t, don’t upgrade. “Dropped support” is just vendor FUD to drive upgrade revenue. is it actually a business risk? that depends on the business.
      A basic principle of business is that you should recover (and then maximise) your ROI on investments before you replace them. As marin’s comment says, if XP is still meeting business needs, why replace it?

      Every change is – OR SHOULD BE – improvement

      1. Changing the oil in your car after x number of miles “improves” the ability of your car to stay running but it doesn’t improve the car does it? Nobody changes their oil because they are looking for improvements – they are looking to stay operational.

        Changing the battery or the spark plugs “improves” the ability of the car to stay in an operational state but do you really think of this as an improvement of your car as compared to when you bought the car brand new? If you don’t do those things – eventually your car won’t be operational but doing those things doesn’t “improve” the performance of the car or make it better than when it was new – it just keeps you running.

        That is the same with XP for some (not all) businesses. XP or Win7 means as much to them as oil in a car. It is something they need to operate but nothing that it perceived that will change or improve their business.

        I don’t mean to suggest that for some company this change couldn’t be an improvement – but such a thing has to be clear – what was improved? It is on intention and use – not just the change itself. I change my shoes – that is an improvement? Or I change my shoes to some light weight running shoe and I’m actually going to go running – that can be an improvement.

        My position is unchanged (not improved I guess) – some changes are maintenance – keep the lights on – activity. They are necessary but offer nothing to “improve” the business – they do allow for the business to continue (status quo – like oil in the car) though.

Comments are closed.