Constraint mapping

From Cynefin.io
Jump to navigation Jump to search

Constraint mapping appears in the Field guide to managing complexity (and chaos) in times of crisis and aims to attune decision makers to path-dependent features of the underlying territory (including deployable resources) which might otherwise be overlooked. This explicitly addresses Inattentional blindness arising from preoccupation with self-evident affordances (considered as solicitations to action) and involves a pause on the part of any decision maker lurching towards doing "the next right thing." They are something we can know and also something we can manage therefore they give us a low energy way of exploring hypotheses.

The output of constraint mapping could take almost any form, but in any and all cases, it should be held lightly, as showing "where to look, not what to see" (as indicating where a decision maker might wish to focus attention rather than as specifying exactly what the decision maker should pick up if looking in that direction).

Introduction

Cynefin® has long used the constraint-based definition of complexity, with the domains having rigid, governing, enabling, no effective and unknown constraints as distinguishing factors.  The original idea of constraints in Cynefin® came from Alicia Juarrero's work and has subsequently been developed.

It is a common mis-conception that constraints can only have negative implications, preventing things from happening or restricting what is possible. This is not the case and Cynefin® will provide for many, an entirely new way to look at constraints, which affords users a powerful lens or perspective through which to make sense of a context or system. Enabling constraints, are the best example of this, these constraints afford humans or other agents of change in a context or system the ability to do something. Put another way, they give permission to do, as opposed to preventing or restricting what is possible.

Constraint mapping and the associated typology of constraints is a central method within Cynefin® and helps navigate complexity by increasing understanding of the things available in a context or system which can be managed.

There are at least three reasons for mapping constraints:

  1. Constraints are things we can manage in a complex system, they are also things which increase awareness of how we can know how to act. Once you map constraints, distribution and delegation of decision making and action is easier and safer. With a focus on modifying constraints and monitoring for what happens there is an accompanying activity of planning for how to contain unhelpful consequences.
  2. Mapping and managing constraints help avoid a direct connection between a situational assessment and a decision about an action to take. Humans make decisions on actions based on a first-fit pattern match based on recent experience, followed by post hoc use of situational assessment to justify the decision already made. This means those who describe the problem generally control the solution. A starting point of mapping and then managing constraints, combined with speculating as to the likely emergence that could result, creates a more objective decision-making process. Mapping includes a process which helps ensure a set, or portfolio, of changes made, are safe-to-fail and enables beneficial changes to be quickly encouraged, or amplified, whilst unbeneficial changes are quickly discouraged, or dampened.
  3. Mapping “Containers” at the innovation phase of a process can create a shared understanding for the group who are involved. Containers make some things possible and some things impossible. This map of the possibility space created by overlapping constraints can be populated by system components for potential ideas or imagined future states. The to-and-fro process of generating ideas and changing containers from, say, robust to resilient enables a kind of rapid prototyping at a conceptual level

This is not the same thing as the use in Goldratt's Theory of Constraints. This post is one view on the differences written by Steve Holt, although Goldratt flagged that an organisation's policies are one of the first things that should be reviewed and these can be considered governing constraints.


A typology of constraints

Containers Connections Exert a force
Robust (survive unchanged until they break and if they break then it is generally catastrophic) Resilient (survive by change, continuity of identity over time) Change can trigger a phase shift (anti-fragile would be a part of this)
Generally ordered Generally complex TBD
Clear decisions Natural conditions Decisions that allow for emergence

A matrix view of the typology of constraints

Robust Resilient
Rigid/Fixed Elastic Tethers Permeable Phase shifts (previously known as "mutating") Dark
Containers e.g. Seawalls e.g. Family? e.g. Fixed operating budgets e.g. Salt marshes e.g. Case law e.g. Cultural taboos
Connections e.g. Queen + subject e.g. Manager + team member e.g. Police officer + speeding driver e.g. Team member + team member e.g. A marriage
Force

Dark constraints exert a force that we can detect but we cannot trace it back.

These may become a set of three triads which will also allow mapping in SenseMaker®.

In more detail:

Robust constraints

  • Can be either Rigid or Governing (degrees of flexibility or discretion)
  • Survive by becoming stronger and more entrenched
  • They are context-free, which means they apply to everything, regardless of context
  • When they fail, do so catastrophically

Resilient constraints

  • Also referred to as enabling - designed to encourage agency
  • Survive by adapting and changing, continuity of identity over time
  • Are contextual - can be adapted for context; guidelines or heuristics rather than rules
  • When they break, there is usually some warning or the impact is small

Robust constraints can be …

  1. Rigid or fixed which means they are clearly defined, visible and can be enforced. If you want a metaphor think of a sea wall, or dykes. They have all the advantages of certainty, all the disadvantages of sudden catastrophic failure when their limits are reached.
  2. Elastic and thus have the benefit of adapting to a degree of change which is good, but they can still break and possibly give a false level of confidence. An elastic waistband may give you the illusion of maintaining a healthy weight but only for a time. The failure is more extreme.
  3. Tethers which provide a backstop, like a tow rope for example which has the slack taken up before it applies. These can be fail safes, backups only coming into play in extremis. The danger is damage when they snap into effect, both for the object being tethered and for the tether itself.

Resilient constraints can be …

  1. Permeable (for containers) or conditional (for coupling), in both cases the constraint is contingent. Some things can get through others can’t. Think of a salt marsh to contrast with the sea wall if you want an example. Or a system where rules can be broken in specific cases subject to heuristic control.
  2. Mutating which means they change over time, they don’t switch on and off, you can see the evolutionary pattern. Case based legal systems on contrast with those based on the Napoleonic code would be a good example of these. In companies, they are hardly ever used, but could be valuable.
  3. Dark are like dark matter or dark energy, we can see their impact but we don’t know what they are. Aspects of organisational culture fall into this category as do taboos, rituals, and the like. Far more prevalent in modern organisations than people realise they are almost a complex system in their own right, only knowable or changeable by interaction.

Constraint Mapping Approaches

Constraint mapping is an assembly: a process built by combining potentially-related methods with a view to developing trans-contextual understanding. The following is only intended to be an illustrative example (to be elaborated and extended over time).

Future backward/Four points assembly

  • Explore the space - make use of Future backwards
  • Establish the context - make use of Four points
  • Access the constraints - review the groups/cluster and discuss which constraints are at play
  • Establish actions - use the portfolio forms to outline a series of actions


Do's and Don'ts

Simple bulleted list including common mistakes

Virtual running

Constraint mapping has been facilitated virtually using a digital collaboration canvas and virtual communication channels.

References

Articles and books

Blog posts

Cases

Link to case articles here or third party material

Other resources

Method card material

This material will be extracted for the method cards, which are also referred to as the Hexies

Possible symbols or illustrations

Front page description

Use of the constraint typology to brainstorm all constraints and then map them onto an energy/time grid.

Back of card summary

Mapping constraints onto an energy/time grid allows the identification of counterfactual and volatile, high-risk states. Time and energy here refer to the time and energy that would be required in order to change a constraint, where energy can take many forms, such as cost or human effort or investment. Constraints are identified by via the standard methods using the typology of constraints or through the use of SenseMaker® to capture the material. The space between the counterfactual, on the top right of the grid, and the constantly-shifting, at the bottom left, is in effect the field of operation. Things that could change but won't be dealt with the time and energy available can be considered de facto counterfactuals for the time being.

How can it be used?

  • for diagnosis - to establish the issues and constraints that exist
  • for analysis/understanding - help establish the landscape of constraints within a context
  • for intervention - help to understand options in the current context and which constraints could be modified

Method Properties - Ratings

Represented by symbols: for the cost and resources needed, the complex facilitation skill level and the likely engagement level


Retrieved from ‘https://cynefin.io/index.php?title=Constraint_mapping&oldid=6012’