Guest Post: Making Levers Work: How Behaviour Enablers Connect Decision Intelligence and Human Action (Part 2)

In Part 1 of this two-part post, we introduced the challenge of how, despite having created a well-formed CDD, the actions chosen by a decision maker may never actually be taken. Here, we present practical advice from the COM-B world for fixing the situation. We introduced this diagram illustrating the problem:

Where Behaviour Enablers live in a CDD 

This change of perspective to understanding behavior enablers adds a step to how we work with CDDs in practice. 

First, we build the CDD as usual. We clarify the outcome(s) we care about, identify relevant intermediates, and design levers (choices of actions) that we believe will influence those intermediates. This gives us a first, coherent picture of how the system works and where to act. 

The Decision Intelligence Handbook and our course, Getting Started with Decision Intelligence, both teach how to start with this first-draft CDD and to refine it into a “well-formed” one. This CDD refinement process maximizes its value, either as a diagram or as a scaffold for integrating technology.  CDD refinement includes checking that outcomes aren’t intermediates (proxy outcomes), verifying that all intermediates and outcomes are measurable (not process steps), and more. 

Behaviour Enablement Analysis (BEA) is a new CDD refinement technique that overcomes the challenge described above where actions might not be taken in practice.  BEA begins by reviewing intermediates to ask, “Which describe the results of human behaviour?” For example, we might see intermediates labeled as, “degree that project leads escalate risks early”, “degree to which teams openly share failures”, or “number of managers who say that they use AI in their daily decisions”. Then, whenever an intermediate measures the degree to which a person or a group behave differently, we mark it as a behavioural intermediate. 

For each behavioural intermediate, we then run a COM-B check. We ask whether the people involved truly have the capability, opportunity, and motivation to achiever the behaviour that leads to that intermediate in their everyday context. As we do this, we might discover missing skills, lack of time or forums, fear of negative consequences, or other reasons that the intermediate we thought we’d measure won’t be achieved. These represent messing Behaviour Enablers. 

The image at the top of this post shows an example of the result of this kind of analysis. You can see that two intermediates have been identified as behavioral ones.

Behaviour Enablement Analysis (BEA) is a new CDD refinement technique that is grounded in psychological research, and which overcomes the challenge described above where actions might not be taken in practice.  

BEA follows the process below.  It helps you identify behavioural intermediates, test them with COM-B, and add the enablers needed to make it more likely that people can perform the behaviours represented in the CDD:  

Behaviour Enablement Analysis (BEA) – Short Checklist 

1. Identify Behavioural Intermediates 

• Review intermediates and mark those that describe human behaviour (e.g., “teams share failures”, “managers use AI daily”). 

2. Run a COM-B Check for Each 

For every behavioural intermediate, ask: 

• Capability: Do people have the skills/knowledge? 

• Opportunity: Does the environment give time/resources/forums? 

• Motivation: Do people want to do it, or are there fears/barriers? 

3. Capture Missing Behaviour Enablers 

• Note why the behaviour won’t occur today (e.g., missing skills, lack of time, fear of consequences). 

• Convert each gap into an enabling action. 

4. Integrate Into the CDD 

• Add required enablers as levers or support factors. 

• Recheck: Will the behaviour now realistically happen? 

 
An example: fewer project crises 

By way of example, consider a common goal: reducing the number of project crises in an organization.  Let’s assume that our decision maker is the Chief Operating Officer (COO) 

A first-pass CDD might include a new lever: for management to introduce a monthly risk report for all major projects. Between that lever and the outcome “number of project crises”, we place intermediates such as “average age of a risk before it’s escalated” and “degree to which employees agree that risks are visible and discussed”, as reported on a survey. On the surface, this logic appears sound: the risk report should lead to early escalation, which increases visibility, which in turn should reduce crises. 

This CDD reflects the assumption that project leads will indeed escalate risks early just because the organization has introduced a monthly risk report. But this can be unrealistic . 

To catch this CDD error, imagine that we assess the behavioural intermediate “average age of a risk before it’s escalated”. We ask whether the necessary capabilities, opportunities, and motivations are in place for the existence of monthly risk report alone to reduce this number. 

Starting with capabilities, we might discover that project leads have very different understandings of what counts as a risk, and that some of them are unsure how to frame a risk for senior management. The existence of the risk report alone is not enough. 

Looking at this risk age intermediate through the opportunity lens, we may find that there is no stable governance forum where risks can be raised in a structured way, or that meeting agendas are always too full to talk about them. Again, the report is only one necessary – but not sufficient – condition to achieve its desired result. 

Finally, are there motivational gaps between the report and the speed of risk escalation? Imagine that we discover that, in the past, people who raised risks early were sometimes blamed or subtly punished, which makes escalation feel unsafe. 

Each of these gaps points to a missing Behaviour Enabler. The next question is, how to model them?  We can start by just drawing a box on the CDD with the enabler name.  For our example, all three of these boxes point to the risk timing intermediate.  Now, we need to determine whether these enabler elements are externals – outside of the decision-maker’s control, levers – under the decision maker’s control, or some combination of the two. 

In order to make this assessment, we need to ensure that we fully understand the authorities given to our decision maker – the COO in this case.  Now, different organizations will empower their COOs in different ways, so the result is not one-size-fits-all.  Generally speaking, we’ve found that Behaviour Enablers have two parts.  First, there is a preexisting situation, which by definition is outside of the decision maker’s control.  For that reason, we model it as an external. By way of illustration, let’s consider our example capability enabler from above: project leaders’ risk management skills, which we described above as the degree to which project leads have very different understandings of what counts as a risk, and the degree to which they are unsure how to frame a risk for senior management.     

In any given organization there will be a particular set of both preexisting risk management skills, which we should model as an external. 

In addition, there will probably be some action or actions that the COO can take to improve those project management skills, which is a lever (list of choices of actions). 

Together these two elements influence a new intermediate: the level of project risk management skills amongst project managers. This, in turn, enables (in part) our “escalation speed” intermediate.

Second, we often find that the decision maker does have some ability to alter the situation, so this would indeed be a new lever (choice of action).  Both of these elements should point to the intermediate under analysis.  To implement this might be a design task for the COO: convening a working group to agree on a shared definition of risk and a simple framework for describing it, creating a recurring forum or agenda slot for risk discussion, and modelling leadership behaviour that clearly shows that early escalation is valued and protected rather than punished. 

There may be one or more levers worth modelling.  “Convene a risk working group” might be detailed enough.  Or the COO might want to model at a more granular level, creating a small bundle of coordinated actions: introduce the report, run a short training on risk identification and framing, establish a fixed risk agenda item in governance meetings, and make it visible that leaders appreciate early escalation. 

As illustrated here, COM-B becomes a refinement step on behavioural intermediates. It helps us sharpen our levers so that people can actually behave in the way the CDD implicitly assumes, and the designed levers can thereby manifest their full modelled impact. 

Why surfacing hidden Behaviour Enablers matters 

Looking at organizations through the Behaviour Enablers lens reveals a recurring pattern. They are hidden in many transformation initiatives, leading to unnecessary failure. We design a lever, communicate it, and then assume that the necessary human conditions are already there: of course people understand the topic, of course they have time, of course they will want to behave differently because the initiative is obviously a good idea. 

But reality is rarely so kind. 

Hidden Behaviour Enablers show up in small phrases like “they’ll just take this into their existing meetings” or “everyone knows how to use that tool by now”. In a CDD, they show up as behavioural intermediates that look simple in the first CDD draft but upon inspection we realize has only modelled some – but not all – of the necessary conditions for success.  When psychological enablers are ignored, people do not behave as expected. This is not because they are irrational or lazy, but because the system asks them to do something that is too costly given their current psychological capability, opportunity, and motivation. 

The good news is that behavioural psychology gives us an answer.  So far, though, this field has not systematically and universally been translated into day-to-day practice in organizations. The use of decision intelligence and CDDs for analysis for important and complex business decisions provides this mechanism: it allows us to decompose a choice-of action-decision into its constituent parts, and to “debug” our shared understanding as reflected in that CDD for the fact that capability, motivation, and opportunity factors – though often critical – are easy to overlook in fast-moving and complex situations.  

Behaviour Enablers make often-overlooked psychological assumptions visible. Instead of asking “Why are people resisting?”, we can ask “Which enabler is missing?” Do people actually know what to do? Do they have a real chance to do it? Does the behaviour make sense to them, and does it feel safe enough to try? Does it fulfill their motivational needs? 

From model to practice 

The combination of DI, CDDs, COM-B, and Behaviour Enablers offers a practical way to close the gap between strategy and daily behaviour. 

For people who build CDDs, this means adding one simple step: after you have drafted the diagram, mark all behavioural intermediates and run a quick COM-B check on each of them. Wherever capability, opportunity, or motivation are missing or fragile, name the missing Behaviour Enablers and use them to sharpen or update your CDD. 

The result is that CDDs become living maps that take seriously is actually required for people to act differently. Instead of blaming “resistance” when change does not happen, we can ask a more productive question: which Behaviour Enablers did we overlook, and how can we put them in place? 

That, in the end, is what makes levers work. Not just knowing where in the system to act, but designing the human conditions that allow action to turn into real, sustainable behavioural change.