Insights on SCAN: The bubble-metaphor

In the work we’re doing to make the ‘bucket-list’ of sensemaking-tools more accessible to general users, occasional insights arise that make the tools themselves richer and more powerful. There’ve been a bunch of those recently from our work on SCAN, about sensemaking and decision-making in run-time action:

The first of these insights is a new metaphor for SCAN itself, developed by our designer Joseph Chittenden. It models each task as a bubble, whose size we indicate in terms of the SCAN dimensions – extent of certainty and uncertainty (horizontal), versus total elapsed time for the task (vertical):

In the vertical dimension, above the line is the amount of time needed to plan and get everything ready for the task; below the line is the amount of time needed to do that task.

In the horizontal dimension, to the left is the extent to which the task-activities to deliver the aims of the task seem to be (upper left) versus actually are (lower left) reducible to simple step-by-step sub-tasks; to the right is the extent of activity known to contain uncertainties to be addressed in planning (upper right), versus uncertainties that can or will only arise at run-time, and can only be addressed in run-time action. Run-time certainties (lower left) can be addressed by machine-type automation and/or by low- to no-skill human action; run-time uncertainties can only be addressed successfully by human or human-like skills.

The crucial understanding that we get from the bubble-metaphor is that the effective time-to-execute and complexity of a task can blow out in any of those directions:

Think of the available run-time capability – the respective ‘ability to do work’ – as being a constrainer like the nozzle of a funnel. In terms of the metaphor, task-throughput would be constrained by the size of the nozzle, and the size and flexibility of the bubbles that we try to push through the nozzle. If we have high capacity for simple/certain tasks, but low capacity for complex/uncertain tasks, every task with high real-world complexity will tend to jam in the nozzle, reducing the effective throughput regardless of how much simple-task capacity we have.

When we hit up against run-time uncertainty that won’t fit through the nozzle, what happens next depends on the ‘flexibility’ of the bubble. ‘Flexible’ means that there is still some capacity available to resolve uncertainty away from the run-time action (upper-right in the bubble). If so, then we may be able to pull back and use that to reduce the effective width of the bubble – though at the cost of taking more time to do the overall task, or, in terms of the metaphor, stretching the vertical dimension of the bubble. If there’s no such ‘offline’ capacity – an ‘inflexible’ bubble – then the task will jam up in the nozzle, blocking any further progress on task-delivery until those challenges are resolved. This happens a lot in ‘efficiency’-obsessed organisations that delude themselves into a belief that everything can be reduced to simple rules, and that real-world uncertainties can be somehow wished-away…

The key here is to apply ‘just enough’ exploration before run-time, to reduce the ‘unknown-unknowns’ over on the right-side of the bubble, and also maintain enough skills-capacity to cope with inevitable run-time uncertainties. In effect, to reduce the ‘horizontal’ size of a task-bubble, we need to do things like virtual-walkthroughs and so on, to elicit warnings about potential for, and potential impacts of, any run-time uncertainties – and do this before the task gets close to that nozzle of run-time.

And to reduce potential ‘blow-out’ in the vertical dimension – the overall execution-time for a given task – we need sufficient capability on-call to act on and resolve run-time uncertainties, if run-time staff do not themselves have enough skill to resolve the uncertainties on their own. For example, the staff in a troubleshooting call-centre will often need be to those with the highest skill-levels in that context – and not merely those who can read a step-by-step script.

The bubble-metaphor doesn’t replace the existing SCAN frame – it’s just another way to look at the same issues, particularly when we assess how a set of tasks in a complex real-world context can interact with each other, and what we need to do in order to reduce the risks that any single task could ‘clog up the works’ for a broader overall outcome.

For example, consider the set of tasks that need to happen before a surgical operation takes place. We could map these out in relation to each other on a SCAN frame, in terms of probable-uncertainty (horizontal) and how far ahead in time (vertical) each must occur, relative to the ‘Now’ of the operation itself:

In the bubble-metaphor, each of these tasks is a ‘bubble’ in its own right; and each must pass through the respective metaphoric nozzle before the task-bubble for the overall surgical-operation itself can do so. We can then use the bubble-metaphor to help reduce the risk that any task-bubble might blow out in either dimension, slowing or blocking progress towards the overall desired outcome.

Is this metaphor useful to you? Is it worth developing further? Or is it just a distraction, one metaphor too far? Let us know your comments on this, if you would.