TOC and I: Using Systems Thinking to Understand Impact

Like most BAs or thinkers of any kind, when I first came across systems thinking, I had a yeah, of course reaction.

Systems thinking is a way of making sense of the complexity of reality by looking at it in terms of wholes and relationships, rather than by breaking it down into its parts.

In short, systems thinking is an approach that focuses on the interplay between things, not just the things themselves. You know: understand the context before messing with things … blah blah blah … all very natural BA stuff.

You might have already come across systems thinking, theory of constraints, and current reality trees. Maybe you've even used them in anger.

If that's the case, feel free to skip the context setting. But if not, then let's dive into systems thinking — and, more specifically, the theory of constraints.

Within the umbrella of systems thinking, there is a management theory called the Theory of Constraints (TOC), created by Dr. Eliyahu Goldratt. The central idea of TOC is that every system has constraints, and that reducing the impact of a constraint is the most effective way to improve the system.

And like all (read: none) great thinkers, Goldratt chose to explain his ideas as a novel. No, I am not at all joking, and boy was I surprised when what I thought was the fictional introduction added for engagement purposes just kept on going and going … for an entire book.

Luckily, it is not the only method he used to communicate his ideas, and there are plenty of books, videos, and thinks on his theories — thank lawd!

Within TOC there are five logical tools:

• The current reality tree,
• the future reality tree,
• the prerequisite tree,
• the transition tree, and the
• the evaporating cloud.

Side note: Best named logical tools, no?

For this article, I’ve focused primarily on the Current Reality Tree (CRT) as I was mostly interested in understanding how business analysis affects the system.

It's actually not that scary!

Once you get the hang of reality trees, they are relatively easy to read. The boxes are statements about an observable effect, and the arrows show the causal relationship between two effects. An effect without a cause is a root cause.

To read, refer to boxes as IF, arrows as THEN and circles as AND. Some examples:

1. IF Solution has defects, THEN Solution fails functional / perf / security testing.
2. IF Team does not understand the constraints AND Solution requirements are unclear and/or incomplete, THEN Solution has defects.

Let’s get to the point.

The reason I went down this systems thinking causal map rabbit hole is because I wanted to understand how business analysis influences the systems within which it is done. And I wanted to do that in a way that permitted me to reason about it. It is all well and good to claim that we’re instrumental, but proving it would be better, no?

So, I created a (hypothetical) current reality tree for all the things that go wrong with business analysis work based on my experience. Call it a mash up of the bad things that I’ve seen more than once.

Now it is important to note up front that I am wildly self taught in this method! And perhaps even more importantly, this is a hack. The CRT approach is designed to surface how the different parts of a real system work together, and here I’m using it to understand how things can go wrong. So I’ve included more unhappy stuff than you’d usually include.

Knock on wood. 🤞

As a result, many of the ANDs I would read as AND/ORs because it is less likely that both will occur in the real world, but either could contribute to the unintended consequence. For example, both Solution requires rework OR Effort estimates are incorrect can result in Solution not delivered on time. Or both, of course.

And for the map, I started with the following six big undesirable effects:

1. Stated project benefits are not realised
2. Solution fails functional, performance, and/or security testing
3. Project budget is exceeded
4. Solution is not delivered on time
5. Solution fails business acceptance testing
6. Project scope is reduced

But with all those disclaimers out of the way, here’s the whole map. I don’t think it is too overly dramatic to say:

Tracing back from those six undesired effects turned into this whole mess. 👇

Yeah, that's a special kind of gross!

But what’s most interesting is that if we trace back from our undesirable effects — picking reasonable causes and symptoms along the way — then we eventually end up with just three root causes.

1. Stakeholders not engaged in the process.
2. Problem or opportunity is not analysed.
3. Solution analysis not undertaken.

But why stop there? Yulia Kosarenko claims that the most important thing business analysis delivers is shared understanding across all stakeholders. And what's underlying these three big bads?

Yip. Us.

Business analysts have an outsized impact on the entire delivery system.

I don’t want to Han-splain™ to you how to tackle these root causes. Especially since any advice would have to be contextual to be of any value to you. But I do want to show you what this map looks like when the business analysis is Done Well™.

Welcome to project heaven!

The following is the future reality tree (FRT) for when you build shared understanding.

I jest, of course.

The truth is that Business Analysts operate in a complex system where every good outcome is predicated on many other things also going right — good development, good testing, good everything. Doing our job and doing it well is necessary, but, sadly, not necessarily suffcient to delivering value.

Okay, okay, okay! So what does this all mean?

Simple: we are too easily distracted from the what by the how.

We get obsessed with techniques. And we forget that the requirements don’t matter — but the shared understanding of the problem, scope, and options do. And equally, the stakeholder map doesn’t matter, but the relationships do. The as-built document format doesn’t matter, but the IP it represents absolutely does.

Now I’m as bad as any BA. I have my preferred approaches to all of the above. But I shouldn’t.

First, I should ask Why?, then What?, and only then, How?. Because the performance of a system depends on how the parts work together, not on how they act independently.

If we focus only on the artefacts that we create and ignore the system in which we work, then we might not see the impact that we’re having. But to avoid that, we first need to see the system. Only then can we focus on the right things. That’s where systems thinking can help.

But if you're looking at the insane diagrams I did above and wondering if I didn't actually go a tad mad while writing this article — and if you aren't especially interested in joining me — then let me remind you what the Cheshire Cat in Alice in Wonderland said:

Here’s a selection of resources I’ve been using.

1. WTF is … systems thinking by Simon Copsey
2. Systems Thinking for Happy Staff and Elated Customers by Simon Copsey (video)
3. Current Reality Trees to Lift the Fog of War by Simon Copsey
4. Thinking in Systems by Donella Meadows
5. Using a current reality tree by Stuart Rance
6. Theory of constraints
7. Thinking in Systems by Donella Meadows
8. Thinking for a Change: Putting the TOC Thinking Processes to Use by Lisa J. Scheinkopf