Theory of Constraints: Using a Current Reality Tree
You’ve probably heard people who work in IT service management (ITSM) talk enthusiastically about the Theory of Constraints (ToC) and how it can help us work smarter, but most of us have only a basic understanding of the ToC thinking tools.
If you’ve never come across ToC before then reading The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win is an excellent place to start. It’s not a dry presentation of the theory, but a novel that follows a fictional IT organization as it struggles to transform itself using ToC ideas. If you have read the Phoenix Project then you may already be thinking about how to use ToC in your organization.
ToC is a very logical, and analytical, way of thinking about how systems work, and how to help them improve. It consists of several collaborative “thinking tools” that are quite similar in the way they operate, but are optimized for use in different situations. The aim of the tools is to help organizations answer three fundamental questions:
- What to change?
- What to change to?
- How to cause the change?
Once you can answer all three questions confidently, you are in a position to make changes that genuinely lead to improvements.
Obviously, I can’t describe all the different ToC tools in a single blog, so I’m just going to focus on one tool today, the one that helps organisations identify “What to Change”. ToC practitioners call this tool The Current Reality Tree (CRT).
Current Reality Tree
Seasoned ITSM practitioners know that if you want to make improvements, you need to talk to the people who do the work. But there’s a problem. If you talk to all the people in your organization and ask them what needs to be fixed, you’ll end up with a very long list of things that should be addressed and no good way of deciding where to start. That’s where the CRT comes in. It’s designed to help you uncover and understand the relationships between all the different issues, and to identify the issue that you should address first. You create a CRT by:
- Agreeing the scope of the system that you want to understand
- Listing the undesirable effects that exist in the current situation
- Analysing the cause / effect relationships between the undesirable things you have listed and identifying underlying causes that contribute to them
- Tying everything together in a single cause / effect tree
1. Agreeing the scope
This is an important first step. You need to be sure that you have the knowledge, experience and authority to make improvements. If you are the supervisor of a small team, then it probably doesn’t make sense for you to analyse the strategy of the large organization you are part of. You won’t have enough information to identify the right issues, and you are extremely unlikely to have the necessary authority to take any action.
Identifying the scope of your analysis will help you identify the people you need to work with. Make sure that you include everyone who can contribute to your understanding of the overall system that you are working on.
2. Listing the undesirable effects
The next step is to create a list of the undesirable things that are happening in the current situation. ToC practitioners call these “undesirable effects” or UDEs.
So far this sounds a lot like asking people what needs to be fixed, but there are several crucial differences.
Firstly, an ideal list consists of no more than 5 to 10 undesirable effects to analyse. If you start with more than this then you are probably looking in too much detail at this early stage.
Secondly, you take the time to ascertain whether each UDE on your list is real by asking two questions:
- Does this effect really exist in the current environment? You will need to ask searching questions to make sure that the effect is real, and is having an impact. For example, if your effect was “Service desk agents don’t know how to manage incidents” you should ask things like “How do we know this?”, “Is it definitely lack of knowledge and not lack of time, or lack of motivation or some other factor?”
- Has the effect been clearly described? You need to make sure that each effect is properly described – a one or two-word summary won’t do, it’s too readily misunderstood. For example, “Service desk agents” is not an adequate description of an undesirable effect, and if it appeared on your list there could be completely different understandings of what it actually means.
Thirdly, you state all the undesirable effects positively, as things that are actually happening right now. A common mistake that people make is to list the absence of their preferred solution, for example “Service desk agents have not been on ITIL training”. In fact, in this case, the real issue is that “Service desk agents don’t know how to manage incidents”.
Here’s an example to illustrate how the CRT works.
Below is a typical, if simplified, list of undesirable effects from a fictitious service desk.
- Many incidents are poorly managed
- There are lots of repeat incidents
- Service desk agents don’t know how to manage incidents
- End users are unhappy with the service
- There’s a very high turnover of service desk staff
- Incidents take a long time to resolve
3. Analyzing the cause / effect relationships
Once you have your list of undesirable effects, you can look for cause / effect relationships between them. In the example we are looking at, you might decide that it’s obvious why end users are unhappy with the service. It’s because incidents take a long time to resolve AND there are lots of repeat incidents. You then use a graphic organiser (the tree) to make the relationship visible, as shown below. Do be aware that this is not a flow chart -it’s a way of making cause/effect chains visible.
4. Tying everything together
To complete your analysis, you search for the appropriate place to add each of the undesirable effects to your tree. You will almost certainly identify additional causes for some of the undesirable effects on your list and you add these to your tree at the appropriate point. You will see in the diagram below that I have added ‘We identify very few problems’ as one cause of ‘There are lots of repeat incidents’.
You continue to build the tree, adding new items and moving them as necessary, until all your undesirable effects have been placed on the tree and you have joined everything together. It’s easy to tell when you’ve completed your tree properly. The cause/effect connections make sense when you read the tree from the top down, using the word because (‘Many incidents are poorly managed’ because ‘Service desk agents don’t know how to manage incidents’ and because ‘There is a very high turnover of service desk staff’). Equally, they make sense when you read the tree from the bottom up, using the word so (‘We identify very few problems’ and ‘Many incidents are poorly managed’ so ‘There are lots of repeat incidents’).
By the time you’ve finished building your tree, you will have identified the issues that you need to address first. In this case, you clearly need to address the knowledge of service desk staff, and you probably need to do something about problem management too.
The CRT doesn’t tell you what to do about the situation. That comes later when you consider “What to change to” and “How to cause the change”. What the CRT does do is help you to identify what you need to rectify.
What is a constraint?
You may have noticed that in this blog about the Theory of Constraints, I haven’t yet told you what a constraint is. According to ToC, every system always has a single bottleneck, which constrains how the whole system performs. When you address this bottleneck the constraint moves somewhere else. ToC tells us that any investment we make that doesn’t address this constraint will be wasted, because the overall performance of the system will not improve.
This blog has shown you how you can use the ToC Current Reality Tree to help you improve by identifying the constraint in a system; exactly what it is that you need to change.
Other ToC tools
I have described just one of the ToC tools, the Current Reality Tree, and I have shown you a simple example of how it can help to identify the constraint where you need to make improvements.
All of the ToC tools are based on a similar logical, analytical and collaborative approach. Other tools that you may want to learn about include
- The Future Reality Tree, which can help you decide “What to change to”
- The Prerequisite Tree and the Transition Tree, which can help you decide “How to cause the change”
- The Evaporating Cloud, which can help you to resolve conflicts
You can read more about these tools in Lisa Scheinkopf’s book Thinking for a Change: Putting the TOC Thinking Processes to Use.
Do please let me know if you try building a CRT, and if you’d like to see future blogs on some of the other ToC tools.
This work is licensed under CC BY-SA 4.0