News, Reviews and Resources for ITSM Professionals.

Service Improvement at Cherry Valley

Home » Featured, Practices » Service Improvement at Cherry Valley

Problem, risk, change , CSI, service portfolio, projects: they all make changes to services.  How they inter-relate is not well defined or understood.  We will try to make the model clearer and simpler.

Problem and Risk and Improvement

The crew was not warned of the severe weather ahead

In this series of articles, we have been talking about an ethanol train derailment in the USA as a case study for our discussions of service management.  The US National Transport Safety Board wrote a huge report about the disaster, trying to identify every single factor that contributed and to recommend improvements.  The NTSB were not doing Problem Management at Cherry Valley.  The crews cleaning up the mess and rebuilding the track were doing problem management.  The local authorities repairing the water reservoir that burst were doing problem management.  The NTSB was doing risk management and driving service improvement.

Arguably, fixing procedures which were broken was also problem management.   The local dispatcher failed to tell the train crew of a severe weather warning as he was supposed to do, which would have required the crew to slow down and watch out.  So training and prompts could be considered problem management.

But somewhere there is a line where problem management ends and improvement begins, in particular what ITIL calls continual service improvement or CSI.

In the Cherry Valley incident, the police and railroad could have communicated better with each other.  Was the procedure broken?  No, it was just not as effective as it could be.  The type of tank cars approved for ethanol transportation were not required to have double bulkheads on the ends to reduce the chance of them getting punctured.  Fixing that is not problem management, it is improving the safety of the tank cars.  I don’t think improving that communications procedure or the tank car design is problem management, otherwise if you follow that thinking to its logical conclusion then every improvement is problem management.

A distinction between risks and problems

But wait: unreliable communications procedure and the single-skinned tank cars are also risks.  A number of thinkers, including Jan van Bon, argue that risk and problem management are the same thing.  I think there is a useful distinction: a problem is something that is known to be broken, that will definitely cause service interruptions if not fixed; a “clear and present danger”.  Risk management is something much broader, of which problems are a subset.  The existence of a distinct problem management practice gives that practice the focus it needs to address the immediate and certain risks.

(Risk is an essential practice that ITIL – strangely – does not even recognise as a distinct practice; the 2011 edition of ITIL’s Continual Service Improvement book attempts to plug this hole.  COBIT does include risk management, big time.  USMBOK does too, though in its own distinctive  way it lumps risk management under Customer services; I disagree: there are risks to our business too that don’t affect the customer.)

So risk management and problem management aren’t the same thing.  Risk management and improvement aren’t the same thing either.  CSI is about improving the value (quality) as well as reducing the risks.

To summarise all that: problem management is part of risk management which is part of service improvement.

Service Portfolio and Change

Now for another piece of the puzzle.  Service Portfolio practice is about deciding on new services, improvements to services, and retirement of services.  Portfolio decisions are – or should be – driven by business strategy: where we want to get to, how we want to approach getting there, what bounds we put on doing that.

Portfolio decisions should be made by balancing value and risk.  Value is benefits  minus  costs.  There is a negative benefit and a set of risks associated with the impact on existing services of building a new service:  there is the impact of the project dragging people and resources away from production, and the ongoing impact of increased complexity, the draining of shared resources etc….  So portfolio decisions need to be made holistically, in the context of both the planned and live services.  And in the context of retired services too: “tell me again why we are planning to build a new service that looks remarkably like the one we killed off last year?”.  A lot of improvement is about capturing the  learnings of the past.

Portfolio management is a powerful technique that is applied at mulltiple levels.  Project and Programme Portfolio Management is all the rage right now, but it only tells part of the story.  Managing projects in programmes and programmes in portfolios only manages the changes that we have committed to make; it doesn’t look at those changes in the context of existing live services as well.  When we allocate resources across projects in PPM we are not looking at the impact on business-as-usual (BAU); we are not doling out resources across projects and BAU froma  single pool.  That is what a service portfolio gives us:  the truly holistic picture of all the effort  in our organisation across change and BAU.

A balancing act

Service portfolio management is a superset of organisational change management.  Portfolio decisions are – or should be – decisions about what changes go ahead for new services 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.  “Sure the new service is strategic, but the risk of not patching this production server is more urgent and we can’t do both at once because they conflict, so this new service must wait until the next change window”.  “Yes, the upgrade to Windows 13 is overdue, but we don’t have enough people or money to do it right now because the new payments system must go live”.  “No, we simply cannot take on another programme of work right now: BAU will crumble if we try to build this new service before we finish some of these other major works”.

Or in railroad terms: “The upgrade to the aging track through Cherry Valley must wait another year because all available funds are ear-marked for a new container terminal on the West Coast to increase the China trade”.  “The NTSB will lynch us if we don’t do something about Cherry Valley quickly.  Halve the order for the new double-stack container cars”.

Change is service improvement

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.

So organisational change management is CSI. They are looking at the beast from different angles, but it is the same animal.  In generally accepted thinking, organisational change practice tends to be concerned with the big chunky changes and CSI tends to be focused more on the incremental changes.  But try to find the demarcation between the two.   You can’t decide on major change without understanding the total workload of changes large and small.  You can’t plan a programme of improvement work for only minor improvements without considering what major projects are planned or happening.

In summary, change/CSI  is  one part of service portfolio management which also considers delivery of BAU live services.  A railroad will stop doing minor sleeper (tie) replacements and other track maintenance when they know they are going to completely re-lay or re-locate the track in the near future.  After decades of retreat, railroads in the USA are investing in infrastructure to meet a coming boom (China trade, ethanol madness, looming shortage of truckers); but they better beware not to draw too much money away from delivering on existing commitments, and not to disrupt traffic too much with major works.

Simplifying service change

ITIL as it is today seems to have a messy complicated story about change.  We have a whole bunch of different practices all changing our services, from  Service Portfolio to Change Management to Problem Management to CSI.  How they relate to each other is not entirely clear, and how they interact with risk management or project management is undefined.

There are common misconceptions about these practices.  CSI is often thought of as “twiddling the knobs”, fine-tuning services after they go live.  Portfolio management is often thought of as being limited to deciding what new services we need.  Risk management is seen as just auditing and keeping a list.  Change Management can mean anything from production change control to organisational transformation depending on who you talk to.

It is confusing to many.  If you agree with the arguments in this article then we can start to simplify and clarify the model:

Rob England: ITSM Model
I have added in Availability, Capacity, Continuity, Incident and Service Level Management practices as sources of requirements for improvement.  These are the feedback mechanisms from operations.  In addition the strategy, portfolio and request practices are sources of new improvements.   I’ve also placed the operational change and release practices in context as well.

These are merely  the thoughts of this author.  I can’t map them directly to any model I recall, but I am old and forgetful.  If readers can make the connection, please comment below.

Next time we will look at the author’s approach to CSI, known as Tipu.

Image credit: © tycoon101 – Fotolia.com




8 Responses to " Service Improvement at Cherry Valley "

  1. Stephen Alexander says:

    “Everything we change is service improvement.” — I am not sure this is true. If I do a change to an OU in AD and it has the unintended impact on another service – knocking that service out – and then leads me to do a “change” to that service, just to get it back to “normal” – that is “service improvement”? As the customer it is not “improving” anything for you to give me what you were giving me before. As the Service Provider – if my service was not “enhanced” at all by this OU change in a supporting service (AD) – then there was no improvement to me either. Maybe the initial change (to AD) was some sort of “service improvement” (perhaps to another one of the services they support – remember, there are many ‘shared services”) but if I am not getting the benefit of that and it is requiring me to change just so I can continue to deliver “normal” service – I cannot see how I can sell this work as “improvement” nor can I see as a customer buying it as “improvement”

    Additionally, if you were commissioned to deliver me a service and when you did, something did not work quite right (as expected) and you have to do some “changes” – you cannot possibly come to a meeting with me and tell me these are “improvements” – no, what they are is you doing what you should have done in the first place. They are “changes” in production to a delivered system that is failing to meet expectations – there is no “improvement” going on here – there is you doing what you have to do to meet expectations.

    As an aside – you seem to be using the term “value” from the Service Provider’s perspective and not necessarily the customer’s perspective. They are not really the same thing – and I suppose I have been thinking of value normally only in terms of the customer not always in terms of the SP. So, you are suggesting that the SP needs to determine the value the SP gets out of providing a service – irrespective of any particular customer’s value of consuming the service – and then decide if they want to create, retire, improve, or leave as is (what did Drucker call it…milk then slaughter?). It is unfortunate I suppose that the same term “value” is used for both the SP and customer when they are really different things.

    • I think that’s pretty subtle distinctions, that a change to repair a bad change is not improvement. of course it is, on two levels: (a) fixing something broken is an improvement and (b) the knock-on repair-changes are really part of the original change unit of work.

      • Stephen Alexander says:

        I think it is a subtle distinction – I don’t believe all changes are “improvements” – they can be in support of improvement – but not necessarily improvements themselves. As an engineer – I won’t buy it that the work you are making me do at 2 AM on Saturday just so my service won’t break because you wanted to whatever to your service is an “improvement” to my service. I can buy that your work is an improvement to your service – I can’t buy that the knock-on work is an improvement to my service. I can buy that my work is in support of your work though.

        I know plenty of engineers that if you come to them and say “Hey, you need to do an improvement to your service because I’m doing an improvement to my service, and when I do my improvement, your service is going to break. So, for your service to not break after I do my improvement you need to do an improvement to your service.” – They will respond with – “My service doesn’t need improving. Your improvement needs improving so it doesn’t break stuff. So, go back to the drawing board and figure something else out”

        This language is a bit different: “I’m doing an improvement effort to my service. As a result of this though it will disrupt your service. So, I need you to do a change to your service so I can implement my improvement.” This acknowledges – their service is not improving, it is however, changing and I need that change to happen to support my effort.

        I think there are improvements, there are changes to support improvements, and their are changes that you have to do to keep the lights on (KTLO) – that provide no “improvement” to service but do allow you to keep running. A new legal requirement that means I have to keep data for 5 years instead of 3. That is an improvement? To who? It is a legal requirement that I have to comply with – it is KTLO. If anything I have increased cost, decreased value, increased liability (all the ways in which I can fail to meet this legal requirement), and increased complexity (all the things I have to do now to ensure I meet this requirement now, and in the future). I cannot see how an IT Manager, Director, will see this as an “improvement” – maybe, just maybe, a customer will see it has an improvement – but they may not…once they get the bill.

        This week, we had some layoffs at the company. They are changing the org structure. I suppose this is an “improvement” effort. It doesn’t feel like much of an improvement. It feels more like we are doing something to support the CEO and his “improvement” effort.

        Perhaps the perception of it being an “improvement” or not depends on if you are initiating it or impacted by it.

    • Re “value”:
      I don’t subscribe to the Cult of the Customer. Every organisation is in business for its own benefit, even not-for-profits.

      Commercial enterprises need to deliver value to the customer in order to get paid and attract customers, so in that sense they care about value to the customer but only as a contributor to the value they return to their owners.

      Not-for-profits need to ensure they remain viable.

      In both cases, if you use customer value as the primary metric and follow it to its absurd conclusion the organisation will quickly cease to exist.

  2. Stephen Alexander says:

    Nice diagram.

    I think one like this but more detailed on not just “Operational” but how PPM/Risk and Portfolio deal with Design and Change Management there – then leading into “Operational” – there is more than 1 touch point with Change Management. Projects have Change, generally speaking from testing you can have design changes, perhaps there is a risk discovered that leads to design change — all this takes place before moving to production – where then this model seems to then take effect.

    • Nope. See that “PPM” bubble inside Change? It is initiaitng projects to fulfill change requests, and generating a constant stream of changes out from those projects.

      • Stephen Alexander says:

        Okay. I see that. On a separate diagram I guess we can decompose what is inside of PPM – showing the drivers of change (such as Capacity, Availability, Continuity) inside of PPM.

  3. […] between problem management and risk management as well how changes can contribute to improvement. Service Improvement (The ITSM […]

Product Group Tests

Article by Topic