ITIL

Using Theory of Constraints to Help Continual Service Improvement

Stuart Rance

6 min read

1022 views

Using Theory of Constraints in ITSM

I’ve written about continual service improvement (CSI) before. If you haven’t read my previous articles then you might like to look at Continual Service Improvement (CSI) – The Most Important Service Management Process and The Help You Need to Adopt Continual Service Improvement. These will give you some background on what CSI is, and how you can get started.

Theory of Constraints (TOC) is a set of “thinking tools” that were developed by Eliyahu Goldratt. TOC was popularised in a novel called The Goal, which described how TOC solved a range of problems at a fictional manufacturing plant. I can’t describe the various TOC tools in detail in this blog, but I will try to show how some of the TOC tools can make a significant contribution to your CSI efforts.


One key principle of TOC is that you need to consider the whole system, not just one aspect of it. This is a really important idea when you are thinking about continual improvement. TOC reminds us that sometimes improving one part of the system will make no difference to your overall result, and it is even possible that an improvement to one part will make the overall result worse. TOC summarises this with the statement “Any improvements made anywhere besides the bottleneck are an illusion”. For example you should not think about how you can improve “incident management” or “problem management” or “knowledge management” in isolation. These processes work together to deliver value to your customers and you need to think about improvements in terms of how they impact the whole end-to-end system, not just how they affect one part.

The first TOC tool that I learned about is called the Evaporating Cloud. This tool provides a systematic way of resolving conflicts and problems. The Evaporating Cloud can be used in CSI to help with decisions such as which improvement opportunity you should invest in. You begin by identifying your conflict – whatever it is that is making your decision difficult – in the simplest possible terms. For example, you want to improve your change management process, but the change management team is happy with things as they are. There you go – that’s your conflict, and once you have done that, the approach taken by the Evaporating Cloud is quite different to other decision-making approaches. You don’t decide your change manager is a fool and dig your heels in.  You don’t even start looking at alternative courses of action.  What you do is look for a common goal. For example, in the context of IT service management (ITSM) continual improvement, this common goal might be to improve customer satisfaction, or increase profitability. If all participants can agree on a common goal then this gets you a long way towards agreeing on how to get there. In many ways this is similar to the ITILCSI approach, which starts by identifying the vision. After identifying a common goal, the Evaporating Cloud shows you how to continue by following the steps below:

  1. Documenting the opposed “wants” that lead to the conflict; for example, I want to invest in improvement X and you want to invest in improvement Y.
  2. Documenting the underlying “needs” that lead to each of the wants; for example: why do I want to invest in improvement X? what need does investing in X satisfy? why do you want to invest in improvement Y? what need does investing in Y satisfy?
  3. Crucially, you always talk to the other side of the conflict respectfully, making sure that you begin with their wants and needs, and checking that these have been identified correctly, making changes where necessary.
  4. Finally you identify an intervention that can separate one of the wants from the underlying need, so finding a way to meet everyone’s needs and satisfy the shared goal.

Another TOC tool that I have found really helpful in conjunction with CSI is the Ambitious Targets tool (if you are familiar with TOC, then this is a simplified version of the prerequisite tree). This can really engage staff in improvement planning, because it plays to our greatest strength.  All of us know how to resist change.

The basic approach is to agree on the ambitious target, for example “we will create 500 new knowledge base articles next month”, and then to get everyone in the room to think of reasons why we can’t achieve it. Write these reasons on flipcharts, and keep going round the room until everyone has had a chance to list their objections. Then for each objection ask the person who raised it what they think should be done about it. I was quite sceptical about this approach until I tried it in a workshop, where it worked wonderfully well. People generally had excellent intuition about how to solve the problems that they had identified themselves, and really wanted to. We ended up with a set of actions and owners that would clearly make the initiative succeed. I have since used this in many workshops and it has always been really effective.

In summary, TOC includes a great set of tools that can help you with continual service improvement. Here are some things you can do to start using them in your environment.

  • If you haven’t yet read The Goal, then get yourself a copy and read it now. If you have already read The Goal then read The Phoenix Project, which is based on The Goal and uses a very similar style to consider problems in an IT environment.
  • Start thinking about how you could improve end-to-end value delivery, rather than planning how to improve individual processes.
  • Try using the Ambitious Target tool approach next time you’re in a workshop trying to plan a difficult project.
  • Find out who runs TOC training in your local geography and consider attending a course.
  • If you enjoy learning complex ideas by reading, then buy a copy of Thinking for a Change. Putting the TOC Thinking Processes to Use. This book gives a detailed introduction to all of the TOC tools, as well as the TOC approach to improvement (based on understanding “What to change?”, “To what to change?” and “How to cause the change?”).


Image credit

Like this article? You may also like: The Help You Need to Adopt Continual Service Improvement

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.

What did you think of this article?

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.

Did you find this interesting?Share it with others:

Did you find this interesting? Share it with others:

About

the Author

Stuart Rance

Stuart is an ITSM and security consultant, trainer, and author who has worked with clients in many countries, helping them create business value for themselves and their customers. He was the author of the 2011 edition of ITIL® Service Transition and lead author of RESILIA™ Cyber Resilience best practice published in June 2015. Now that his children have all left home, he has plenty of time on his hands for contributing to our blog – lucky us!

We respect your privacy. By continuing to use our site, you agree to our privacy policy.

SysAid Reviews
SysAid Reviews
Trustpilot