SCAN – some recent notes

Still somewhat in catch-up mode, but seems like this’d be the right time to summarise a few ideas that have come up in recent months on the SCAN framework for sensemaking and decision-making.

First of these is a simple cross-map with the manager-time, maker-time dichotomy:

Managers, as per classic ‘scientific management’, tend to view the world in discrete blocks of time. Their world is certain, is definite – if often quite a long way removed from the real-time action. To business-managers and line-managers, meetings and suchlike should occur exactly on-schedule, to a predefined timeline, and each meeting should last exactly the time specified in the schedule. (The word ‘should‘ tends to occur quite a lot here…) To project-managers and production-managers, every task should take place within a similarly predefined timeline or schedule, and each task should complete in no more than a known amount of time – all defined, no doubt, by the dreaded time-and-motion men or their more up-to-date equivalents. And if anyone fails to match up to these expectations – if anything takes any time longer than expected – they’re derided as being ‘behind schedule’.

Makers, meanwhile, live in a very different world – and one that, by definition, is much closer to the real-time action. Here, tasks take as long as they take: and the more uncertainty there is about what needs to be done, the more uncertain is the estimate of how long it will take.

For makers, there’s often also a real problem with interruptions. With knowledge-work especially – such as in enterprise-architecture, where we’ll often need to ‘get our head around’ some very large chunk of some context or system – it can take hours to build up the mental picture, and sometimes a mere moment’s interruption to lose the whole lot and have to start again from scratch. Being forced to break off in the middle of something for some manager’s meeting can cause a huge hit against productivity: a couple of meaningless meetings in the middle of either side of the business-day – to satisfy some manager’s need for ‘certainty’ as to how the schedule’s going – can easily kill off any possibility of usable work in that entire day. Not good from anyone’s perspective… yet all too common, too.

This is one reason why I so much like Kai Schlüter’s ‘SCAN as decision-dartboard‘: it’s a simple, practical way to show managers where each task really sits on that axis of certainty-to-uncertainty, from manager-time to maker-time – and hence how each respective task needs to be managed, in terms of time and uncertainty.

Next item is an alternate way to indicate the SCAN axes. The usual way I’ve shown these is as the delimiters or boundaries between the SCAN domains, crossing over in the centre of the context-space map. The horizontal-axis I’ve usually shown as a double-headed arrow:

…and the vertical-axis as a single-headed arrow, anchored at the base-point of ‘Now!’:

…which we would bring together as:

But actually, the horizontal axis should perhaps be shown as a single-headed arrow too, because whilst the right-hand side extends to infinity, the left-hand side represents an absolute limit such as absolute-certainty or absolute-predictability. We’d still need, though, to show those (dynamically-changing) boundary-conditions along the two axes, that in effect demarcate the SCAN domains:

• doing the same thing should lead to the same result (left-side) or can lead to a different result (right-side)
• “in theory there’s no difference between theory and practice” (above the line); “in practice there is [a difference]” (below the line)

Which, overall, gives us this:

I’m not saying we should always use this instead of the centre-axis layout: it’s just that for some purposes – some types of sensemaking and decision-making exercises – it may be more usable or easier to understand.

Next, a set of keywords to clarify what happens in each ‘domain’. For me, these have been around for a very long time: the first version, which in those days I described as R₄ and, somewhat later, as R₅, dates way into the tag-end of the last century. These days I perhaps should describe the set as R₈, because it now has eight keywords – two for each of the SCAN domains:

— Simple

• regulation – reliance on rules and standards
• rotation – systematically switch between different elements in a predefined set, such as in a work-instruction or checklist (or in the elements in a framework such as SCAN itself)

— Complicated

• reciprocation – interactions should balance up, even if only across the whole
• resonance – systemic delays and feedback-loops may cause amplification or damping

— Ambiguous

• recursion – patterns may be ‘self-similar’ at every level of the context
• reflexion – intimations of the nature of the whole may be seen in any part of or view into that whole

— Not-known

• reframe – switch between nominally-incompatible views and overlays, to trigger ‘unexpected’ insights
• rich-randomness – use tactics from improv and suchlike to support ‘structured serendipity’

Or, in visual form:

Which, to illustrate, is recursively just another reframe for SCAN – exactly as described for the ‘Ambiguous’ and ‘Not-known’ domains above.

Finally, some extensions to SCAN, created by Kai Schlüter (who also developed the ‘SCAN as decision-dartboard’ technique mentioned earlier). Each of these extensions is actually a separate frame or checklist that we would use in parallel with SCAN, to trigger further insights – again as per the reframe method for the SCAN ‘Not-known’ domain. And as we’ll see, each extension is labelled via a meaningful acronym for the respective context: EPIC SCAN, WISE SCAN and PACE SCAN.

EPIC SCAN is focussed on the epic problems of unneeded-complexity as “the root-cause of too-high costs”:

• Emergent Complexity – consequence of many small and unrelated decisions.
• Perverse Complexity – consequence of clumsy attempts to reduce complexity.
• Irreducible Complexity – consequence of the real complexity of the demand environment.
• Contrived Complexity – consequence of deliberate creation to benefit some stakeholders.

WISE SCAN is about the factors that help us to be wise in guiding business-transformations:

• Worth – the future capability must be worthwhile to trigger a transformation.
• Informed – the future capability must contain all the relevant information, as much as needed, containing the necessary facts.
• Simple – the  future capability must be the most simple solution which fits the purpose.
• Environment – the future capability must be embedded in the greater context.

PACE SCAN explores the drivers behind the pace of work, and critical factors in business-transformation:

• People – to transform people will make the difference between success and failure.
• Adaption – to transform the complete solution must be adapted to reach fit to purpose.
• Communication – to transform communication is key to secure that the targets will be reached.
• Emphatic – to transform it is required to sense also the unspoken which enables to deliver and help that people and solution form a perfect fit-to-purpose environment.

I really love it when I see people taking up ideas that I’d developed, and then building on those ideas to do something even better with them. What Kai has done here with SCAN has been amongst the best I’ve seen, and especially well-suited to his very fast-paced business-driven architectures. Many thanks indeed, Kai! 🙂

Hope this is useful, anyway: over to you, as usual?