This is the third post in preparation for my presentation about Enhanced Risk Management in Kanban via the Theory of Constraints at the forthcoming Lean Kanban Netherlands 2012 conference, on October 25-26, 2012. The purpose of this series is to help understanding how the ideas of the Theory of Constraints can be applied in contemporary software processes, and in particular to the Kanban Method. This series will provide some foundational knowledge in the areas of:
- Schedule Management
- Buffer Management
- Risk Management
- Root Cause Analysis
- People Factors
- Continuous Improvement
Recap
The two earlier posts…
- Critical Chain Project Management in the Theory of Constraints
- Buffer Management and Risk Management in the Theory of Constraints
…presented Schedule Management, Buffer Management and Risk Management. In this post we will look more deeply into Root Cause Analysis and People Factors.
Earlier we’ve covered how Critical Chain Project Management places a Single Project Buffer at the end of the project activity network, and how the project buffer needs to be appropriately sized. We learned how to monitor the Buffer Consumption during project execution. We divided the project into three zones (green, yellow, and red), and we learned how to interpret the thresholds and signals with Buffer Fever Charts and Control Charts. We realized that even processes that are not under statistical control can be handled via Trend Analysis. We discovered that we can identify Common Cause Variation and Special Cause Variation by classifying Reason Codes for buffer penetration events, and then performing Frequency Analysis to examine the frequencies with which they occur. When a common cause is found, we have identified a potential Constraint in the Process (rather than a constraint in the project work flow), and we can take actions to promote a Process of Ongoing Improvement driven by the Five Focusing Steps, and focusing only on the most common or expensive problems (the constraints of our process).
To make our interventions as effective as possible, though, we need to find the root causes of such problems, and then propose and implement solutions that are accepted by all people involved. That is the topic of the present post.
Root Cause Analysis in the Theory of Constraints
When you need to perform a Root Cause Analysis, there are many methods you might consider, like:
- The “Five Whys” [HIBBS-2009]
- Causal (a.k.a “Fishbone”) Diagrams [ISHIKAWA-1990]
- Project introspections [KERTH-2001]
- Retrospectives [DERBY-2006]
Once you discover the depth of the Theory of Constraint’s approach to root cause analysis, such methods will appear limited in one way or another. This statement is not to be taken as a dismissal of other methods — in fact you should still keep them in your arsenal, but use them as further tools within the wider context of TOC’s Root Cause analysis tool: the Thinking Processes.
Thinking Processes
The Thinking Processes are tools that allow performing root cause analysis. In [COX-2010], Victoria J. Mabin and John Davis, give a comprehensive overview of these tools. They can be summarized as shown in the following mind map:
The Thinking Processes were already used in [GOLDRATT-1992], of which the first edition was published in 1984. Later they were formalized in [GOLDRATT-1990a] and [GOLDRATT-1990b], and finally presented in a more comprehensive form in [GOLDRATT-1994].
Decision Making and Logic Reasoning
The Thinking Processes are used in many situations of the Theory of Constraint. Their purpose is primarily to resolve operational and management problems. They support Decision-Making and represent Logic Reasoning.
The key aspect is this: The Thinking Processes are founded on logic. In particular on Sufficient Cause thinking, and Necessary Condition thinking, as described by [SCHEINKOPF-1999].
In [SCHRAGENHEIM-1999] we find several examples of how the Thinking Processes can be applied to management. The Thinking Processes offer a variety of tools for use in different situations. Some are primarily focused on finding the root cause of problems; others are more operational and focus on how to resolve the identified problems. The root cause analysis capability of the Thinking Processes comes to fruition in the context of risk management.
Process of Ongoing Improvement (POOGI)
Originally, the Thinking Processes were developed to support the Theory of Constraints’ process of ongoing improvement; and specifically to answer the three fundamental questions:
- What to change?
- To what to change to?
- How to cause the change?
(Later developments by Goldratt and others — as told by Dr. Alan Barnard in [COX-2010] — added another initial question, “Why change?”, and a final question, “How to measure the change and achieve a process of ongoing improvement?”; though these last two questions are not as interesting as the first three for the purpose of supporting root cause analysis and ongoing improvement.)
It is vital to notice that these three questions are the same questions you need to resolve once you have found the root causes of your problem. It is not only about finding the root causes, but also about doing something about them! The Thinking Process have also this very important operational aspect: they help you in identifying the problem, finding a solution and ultimately implementing the solution.
Current Reality Tree and Relevant Problem
The Current Reality Tree (CRT) is the tool of choice for conducting root cause analysis in the Theory of Constraints. (Note that while we focus on the CRT, one should not disregard the other tools offered by the Thinking Processes, because they can be invaluable when formulating risk prevention, mitigation, transference or avoidance actions.)
One of the most comprehensive treatments of the Thinking Processes is found in [DETTMER-2007], wherein the Current Reality Tree is introduced in terms of identifying the Relevant Problem:
What happens if the problem we’ve identified […] is the wrong one? Inevitably, we would expend time, energy, and resources solving the wrong problem, which means that the original problem would still be with us. And that means the overall situation will probably not improve.
In complex situations, the real problems are not always evident. The suggestion is hence to “construct a Current Reality Tree – a logic tree […] designed specifically to find hidden system-level problems in complex situations.”
By using the Current Reality Tree you gain confidence that you direct your investigation towards the right problem. Even if that problem may hide under several layers of cause and effect. The CRT depicts a logical structure, representing the current reality of the system you are examining. Given a set of circumstances, the CRT visualizes cause-and-effect connections between tangible conditions of the system, and their root causes.
Being an exercise in logic, the CRT is indifferent to arbitrary internal and external system boundaries: The investigation can bring you to look “outside” of your normal domain of interest. (Beware, though, of subjective biases: while the CRT can produce a faithful representation of cause and effect, it is not a complete picture of reality, but only of the part that is subjectively perceived and analyzed.)
Undesirable Effects and Root Causes
When building a CRT, we are really on the outlook for an Undesirable Effect (UDE) — or more simply stated: “problems.” Identifying the UDEs is the first step in constructing a CRT diagram. [DETTMER-2007] describes an UDE as:
The most prominent indication you have something that might be amiss in a system. An UDE is something that really exists; something that is negative compared with the system’s goal, critical success factors or necessary conditions.
You relate the UDEs via a logical chain of cause and effect to Root Causes (RC); and identify the critical root causes producing a majority of the system’s UDEs, including the worst ones. There can be more than one root cause. You must select those generating the most negative impact, in accordance with TOC’s principle of focusing effort where most efficient.
Span of Control and Sphere of Influence
Then you identify and focus only on the Root Causes inside your Span of Control or Sphere of Influence.
According to [DETTMER-2007], the Span of Control “includes all of those things in our system over which we have unilateral change authority. In other words, we can decide to change those things on our own.”
The Sphere of Influence “is an arbitrary perimeter enclosing those aspects of our lives that we can influence to some degree, even if we can’t exercise unilateral control over them.”
Conversely, do not consider root causes traced back into the remote external environment, where the possibility of even exercising influence are non-existent. Dettmer gives the wise advice: "There’s no point in working on something over which you don’t have at least some influence."
From Reason Codes to Root Causes
Let’s go back to where we left at the end of the previous post: we were looking at the Critical Chain Project Management’s Buffer Management techniques, and attributing reason codes to buffer zone penetration events. When you attribute reason codes, and plan to act, you must identify what triggered the problem in the first place, or find the Root Cause(s).
It is at this point that the Thinking Processes (TPs) of the Theory of Constraints come into play in practice. With respect to the process of identifying risks by recording and keeping track or reason codes for each buffer zone penetration episode, one can see how the underlying reasons, and the counter-actions taken, are related to UDEs and RCs.
We can go full circle, and relate the identification of risks to the performing of root cause analysis, and then resolve the problems. By focusing on the most frequently occurring reason codes or those causing most disruption, we can identify good candidate UDEs from where we start the root cause analysis.
Once we identify the UDEs, then:
We work our way from the UDEs back through the chain of causes and effect to root causes. The root cause is the beginning of the cause-effect relationship. There might be several intermediate effects and causes between the root cause and the UDE.
(Note that this is the main reason why “pile-ups” on a Kanban board are not necessarily giving away the root cause of the problem. More likely they are indicative of a UDE, but the root cause might be several layers away in complex network of Effect-Cause-Effect events.)
Intermediary Objectives Map
While we can sort and triage the risk codes according to their frequency or impact, and while we can identify the corresponding root causes that we can act upon or exercise influence, there is yet one more important decision to make before actually taking action. Not all root causes are equal. Some may contribute more or less to the achievement of your goals.
This is where you need the Intermediary Objectives Map (IO Map).
The Intermediary Objectives Map gives strategic direction and supports the process of continuous improvement, providing a long term risk reduction effect. The IO Map was first described by [DETTMER-2007]. The purpose of the IO Map is to answer the fundamental and preliminary question:
What is the desired standard?
The IO Map is a graphical representation of a system’s Goal, Critical Success Factors (CSFs) and the Necessary Conditions (NC) for achieving them. These elements are laid out in a logical hierarchy: the goal at the top, the Critical Success Factors immediately below it, and the supporting Necessary Conditions below them. Dettmer describes:
Each of the entities […] exists in a necessity-based relationship with the entities below it. The CSFs are considered major milestones, or terminal outcomes, on the journey to the goal. NCs represent the conclusion of significant activities required to complete the CSFs.
For instance, in the earlier post Theory of Constraints and Software Engineering, I gave an example about how a company could decrease investment and operating expenses by choosing Open-Source Software. A corresponding Intermediary Objectives Map might look like this:
When performing root cause analysis, the best effects are achieved by identifying and acting on those RCs that are related to the elements of the IO Map. Then you know that any change in that area impacts your ultimate goal. If you find a pair of root causes, and cannot decide which one is more important, choose the one that has the most impact on the elements of the Intermediary Objectives Map. Again, the Theory of Constraints is all about focus and leverage.
People Factors and Change Management
If you really dig deep for the Root Causes to your problems, more often than not you will end up in your Sphere of Influence rather than in your Span of Control. Remember, there is no point going beyond your Sphere of Influence, because there you cannot have any impact at all.
By definition: Your Sphere of Influence is controlled by people other than… yourself! Therefore it is a place where people skills matter.
[DEMARCO-2003] stressed the importance of people factors in the context of risk management. Similarly, Agile methods stress people factors too. However of the many approaches in the Software Engineering literature, none give actionable advise and tools for dealing with people factors. The Theory of Constraints does, and unsurprisingly the approach starts with logic.
In answering the three fundamental questions (*What to change? To what to change to? and How to cause the change?), notice how they pertain — respectively — to the problem, the solution and the implementation of the solution.
When you are out there, trying to influence your… Sphere of Influence, people might disagree on any one of these, and in different ways. This is where you have to use the Categories of Legitimate Reservation (CLR) in order to address the Layers of Resistance.
Categories of Legitimate Reservation
The Categories of Legitimate Reservation (CLR) are simply a classification about reservations that might be raised (by yourself or others) from a purely logical perspective. There are seven of them:
- Entity Existence
- Causality Existence
- Cause Insufficiency
- Additional Cause
- Cause-Effect Reversal
- Predicted Effect Existence
- Tautology
(Actually there is an eighth, or zero-th, that comes before all others; but it is just about making sure statements have sufficient clarity to be unambiguously interpreted.)
Whenever there is a reservation, by recognizing which category it belongs to, you can better handle it. In practice, the Categories of Legitimate Reservation have a technical role in constructing th logic diagrams — and in particular the Current Reality Tree. [DETTMER-2007] states that
The Categories of Legitimate Reservation are the logic glue that holds the trees together […] We use the CLR as we construct our trees to ensure that our initial relationships are sound. We use the CLR after the tree is built to review it as a whole. We use the CLR to scrutinize and improve the trees of others (and they to review ours).
However, the CLRs have more than a mere technical role, and serve when you need to deal with others:
We use the CLR to communicate disagreement with others in a non-threatening way, which promotes better understanding rather than animosity.
This last point is relevant, especially when the problems originate from people or, worse, ingrained policies.
Policy Constraints
Policy Constraints (like arbitrary deadline dates) are created by people. They are not limitations of the physical world. Paradoxically, they are much harder to break than physical constraints, because often they involve clashes of egos, personalities, power plays, etc..
This relates deeply to risk management, because of the necessary collaboration and/or understanding between people that is implied in resolving risks that are consequential to such policy constraints. Challenging a policy implies proposing a change. In [COX-2010] Efrat Goldratt-Ashlag explains:
When we recognize that a change should be made, […] we cannot pull it off without someone else’s permission and/or collaboration. […] getting buy-in is not a trivial task […] Resistance comes in many forms.
When you perform root cause analysis, and find that the relevant Root Causes are in your Sphere of Influence, then you can solve such problems only by involving other people, that supposedly you can “influence.”
In these instance, you must master debating and persuading to convince people to change, and resolve the problems you care about. You have to overcome resistance.
Layers of Resistance
The Layers of Resistance are resistances to change that can be classified and confronted in a systematic manner. They are a simple means for recognizing where you might find disagreement when you engage in discussions with the individuals in your Sphere of influence.
There are three Layers of Resistance:
- Disagreement on the problem.
- Disagreement on the solution.
- Disagreement on the implementation.
(Note: starting from these three Layers of Resistance, the Thinking Processes elaborate even more layers inside them, for a total of nine. These additional layers further expand on how to use the Thinking Process to overcome resistance to change. While the details of such techniques are important, they do not affect the present discussion, and are not examined any further.)
The three Layers of Resistance correspond to the three fundamental questions that support the process of continuous improvement:
- What to change?
- To what to change to?
- How to cause the change?
If change involves other people, you have to overcome their resistance; they might resist any one of those three question: hence the three layers.
While the Layers of Resistance deal with change generically, more specifically they also characterize problem resolution in the context of risk management. Knowing about the Layers of Resistance becomes critical when Root Causes are found in your Sphere of Influence, because then any problem, solution or implementation has to meet the agreement of the people involved.
This is why the Persuasion Techniques of the Theory of Constraints (which, unsurprisingly, are exactly the same techniques used in the Theory of Constraint’s sales processes) are important when managing risk. The Persuasion Techniques allow you to “exercise your influence” in your Sphere of Influence.
The Layers of Resistance are the last tool of the Thinking Processes that we examine here. You might have to handle objections and reservations in any one of these layers. Knowing which layer you are dealing with will help you to use the appropriate tool of the Thinking Processes.
The Current Reality Tree is the tool of choice for identifying and discussing about problems. The Thinking Processes offer other kinds of trees and tools for the other two layers of resistance, like: the Future Reality Tree, the Negative Branch Reservation, the Transition Tree, the Prerequisite Tree, and the Strategy and Tactics Tree. While we will not look at these other trees, what you will find as common ingredients in all discussions, is how objections are raised; and you can handle them by knowing what kind of reservation is being raised.
Remember: we are trying to find a way to use the Theory of Constraints in the context of risk management in Kanban, and specifically to perform root cause analysis.
The Current Reality Tree is all we need in order to be better equipped at finding root causes. (Naturally, resolving those causes might require the dialectic argumentation tools described above too.)
Stay tuned: soon you will see how it all fits together.