What’s Behind the Arrow?™

Pearl and the Missing Causal Reasoning in Enterprise Design

We draw boxes with arrows between them. Strategy points to objectives. Objectives point to capabilities. Capabilities point to processes. We define them, classify them, assign owners to them and place them into Business Process Maps (BPM) design repositories. We build increasingly sophisticated models showing how one object relates to another. Then we connect two of them with an arrow.

A→B

What is actually behind the arrow? It’s a question that became increasingly difficult to ignore while reading Judea Pearl. Pearl’s work is concerned with causality. What would happen if we changed something, and what might have happened had we acted differently.

That distinction has an unexpectedly important implication for enterprise design. Because much of what we call traceability tells us that A is connected to B. It does not necessarily preserve why we believe changing A will cause B to change. The distinction looks small. It’s not.

From seeing to doing

Pearl describes a ladder of causal reasoning. At the first level is association. We observe that X and Y occur together. How would seeing X change my belief in Y?         

A plant using one scheduling practice performs better than another. Projects using a particular governance mechanism appear more successful. Customers receiving a particular service remain longer. There may be a strong statistical relationship. But there is an immediate problem. We do not yet know why.

Perhaps the better performing plant also has more spare capacity. Perhaps the successful projects have more experienced managers. Perhaps the customers who received the service were already the most engaged customers. Something else may be influencing both X and Y. Seeing is not the same as causing.

Pearl’s second level changes the question. Instead of asking what we observe when X occurs, we ask. What happens to Y if we deliberately change X? What would  Y be if I do X? That small word do changes everything. We are no longer spectators. We have intervened in the system. And that is precisely what almost every transformation program does. We change a policy. Introduce a control. Redesign a process. Change a decision rule. Implement new technology. Automate an activity.

We intervene in an operating system because we believe the intervention will produce a different outcome. Somewhere, whether explicitly documented or not, there is a causal proposition.

The dangerous shortcut

This is where Pearl’s distinction becomes particularly relevant to strategy execution. Consider a familiar progression of Strategic intent -> Objective -> Strategic initiative-> Requirements -> Work Delivery

It appears entirely reasonable. But look closely at the transition from objective to initiative. Suppose the objective is improving fulfilment reliability. The organisation then establishes an initiative, implement advanced planning. That small step contains a very large proposition. We believe that implementing advanced planning will improve fulfilment reliability. In causal terms give that we introduce X, Y will change.

The initiative is not simply an item of work. It is an intervention based on a hypothesis. Yet once the initiative is approved, something subtle happens. The hypothesis becomes a commitment. The initiative is decomposed into requirements. The requirements are decomposed into solution components. Those components become projects, deliverables and work packages.

Each can then be designed, configured, tested and implemented. The system shall detect planning exceptions. The system shall calculate a revised schedule. The system shall notify the planner. The system shall update downstream execution. Each requirement is tested successfully. The initiative is delivered on time. The project satisfies scope. Yet the original causal proposition can remain untouched. Did advanced planning actually cause fulfilment reliability to improve?

This is the dangerous shortcut.  Objective -> Initiative. because behind that arrow sits a claim. We believe doing X will cause Y. If nobody opens that arrow, the hypothesis becomes an initiative, the initiative becomes requirements, the requirements become work, and eventually the work is successfully tested. Everything gets tested except the original assumption.

That is not a criticism of project management. Once an intervention has been chosen, decomposing it into controlled work is precisely what project and program disciplines are designed to do. The more fundamental question is whether we moved into that decomposition too early. Before decomposing the work, we should first decompose the reasoning.

Why should B change?

Imagine an organisation introduces a new control intended to improve schedule performance. At a high level the reasoning might appear as new Control -> Improved schedule performance. There is a considerable amount of reasoning hidden inside that arrow. Perhaps the new control prevents work from being released before it is ready. Less premature release reduces work in process. Lower work in process reduces queueing. Lower queueing reduces waiting. Reduced waiting improves schedule performance. The original arrow has now become something more meaningful.

Now we have more than a relationship. We have an explanation of expected system behaviour. And importantly, each relationship can be questioned. The arrows have become hypotheses. That is quite different from drawing a line between two objects. It also changes the nature of design. Instead of moving immediately from Objective -> Initiative we remain in the causal problem for longer. The intervention appears after the reasoning, not before it.

Pearl’s third question

Pearl then moves to the highest rung of his ladder. The counterfactual. The question changes again. What would have happened if we had done something differently? Suppose schedule performance improves after the new control is implemented. But what if demand also fell? What if additional labour became available? What if supplier performance improved? What if another operational change occurred at the same time? Would the improvement have occurred without the intervention? That is a much harder question.

It is also remarkably close to the question organisations routinely try to answer when they claim benefits from transformation.

From hypotheses to requirements

There is another difficulty. The language of requirements tends to remove uncertainty.

A strategic proposition might begin as the statement. We believe that reducing planning decision latency will improve fulfilment reliability and becomes implement real-time replanning. Then qualified as a set of requirements. The system shall automatically replan when a material exception occurs. Unless the original hypothesis remains visible somewhere, the organisation can forget that the requirement was derived from an assumption about how the operating system would behave.

This distinction matters because requirements can be verified without the causal proposition ever being validated. This creates an interesting problem for enterprise architecture, process modelling and transformation design. We are good at preserving objects. But can we discover why? What assumptions made the relationship credible? What conditions were expected to hold? What mechanism was expected to transmit the effect? What evidence would have challenged the original reasoning?

This matters because the enterprise does not stand still. An operating design created under one set of conditions can continue to exist long after those conditions have changed. This is where static traceability reaches an important limit. It can tell us that A remains connected to B. It cannot tell us whether the reason for connecting A to B still holds. That requires the assumptions behind the relationship to remain visible.

Impact assessment then becomes a different question

Traditional impact assessment asks something valuable. If I change A, what else is connected to it? The repository identifies B, C and D. Those objects can then be reviewed. But Pearl suggests a deeper question. If I change A, what should happen? That is not structural impact. It is behavioural impact.

 If an intervention is expected to reduce WIP, and lower WIP is expected to reduce queueing, then changing the intervention should have consequences that propagate through the system. Impact assessment can become more than tracing connections. It becomes an examination of the consequences of changing what we believe about the system.

This also changes how we think about measurement. Measurement becomes evidence. We have evidence about where our explanation of the system may have failed. Did the system behave in the way our design said it would?

From delivery control to causal learning

This distinction also explains an apparent tension in strategy execution. Project and program management need controlled scope. Requirements need precision. Delivery needs schedules, ownership and accountability. None of that should disappear. But strategy execution has an additional obligation. It must remain capable of discovering that the intervention itself was based on the wrong assumption. That creates two different forms of traceability.

Design traceability. Did we build what we intended to build? The second is less common. Causal traceability. Did what we built produce the effect for which we built it? The two should not be confused. A transformation can have excellent design traceability and weak causal traceability.

From documentation to a persistent model

This leads to what may be the more important operational implication of Pearl’s thinking. What if the reasoning behind the arrows persisted? A simply causal reasoning to retain why an important relationship was believed to exist. Then the enterprise design would contain more than a record of decisions. It would contain a model of expected system behaviour.

The learning organisation has to learn somewhere

Unless the organisation changes the model through which it understands the system, much of that learning remains local. The project design stays where it was. The architecture stays where it was. A persistent model of expected behaviour creates a learning organisation. Execution does not merely generate performance data. It generates evidence about the assumptions embedded in the design.

The arrow must remain provisional

Making causal reasoning persistent does not make it correct. In fact, the opposite principle should apply. The purpose of making an assumption explicit is to make it easier to challenge.

An arrow  A->B  must not acquire authority merely because someone placed it in an enterprise repository. That is where Pearl’s idea of testability becomes particularly powerful. A causal proposition should imply observations that can falsify it. A model changed by evidence can become part of a learning system.

What’s behind the arrow?

Mackie makes us examine the conditions that form the causal “cement” between events. Goldratt makes us question the assumptions and measurements through which decisions cascade through an organisation. Pearl adds another perspective.

He asks us to distinguish what we see, what happens when we do, and what might have happened had we done otherwise. That distinction exposes something easily overlooked in enterprise design. We have become very good at modelling the things on either side of an arrow. We are also very good at taking chosen interventions and decomposing them into requirements, deliverables and executable work.

What we are less disciplined about is preserving the reasoning that justified the intervention in the first place. Behind that arrow is a hypothesis. We believe doing this will cause that. The arrows tell us why we thought it would work. And the evidence tells us whether we should continue to believe them.

That’s what’s behind the arrow.