This is another of the sort-of status-reports about the ‘hammer it out in practice’ work that designer Joseph Chittenden and I have been doing on Five Elements, to make it more accessible and usable for a more general audience.
In the previous post ‘Documenting the Not-known‘, we looked at the different types of toolsheets that we’d need, in different parts of the exploration; this one’s more about the ways in which the real-world flow of an exploration often turns out to be a lot more layered and fractal than is implied by the simple step-by-step sequence shown here:
The catch is in how we hide all of that complexity, so that it does still seem to be as simple as shown above, even though it actually isn’t.
To illustrate this, let’s strip the visual-description down to a more-abstract form:
Starting at Purpose, that sequence is the overall flow for exploration of a given concern – and in essence it does work out much that way. It’s the detail that gets a bit tricky…
To expand on this, we’ll use that same simplified Five Elements, but with the same colour-coding as on our usual overview-graphic earlier above (though with the colours a bit washed-out for readability):
We bring that concern of hers into the session, initially to Pivot (the Atrium between the ‘rooms’, in the visual-picture above). In practice, the concern will itself often have multiple parts – for example, “we have a problem with xxxx machine, it might affect our workflow, we don’t know how our customers are going to respond, and I don’t know how to fix it”. To start the Five Elements cycle, Pivot sends the concern, in its initial state, into Purpose.
In Purpose, we set out to find the big-picture that links together all those sub-parts of the concern, together with key themes that we’ll use throughout the session: overall vision, values and ‘story’ (which we’ll use particularly in People); key applicable rules, regulations and standards (for Preparation); guiding-principles for decision-making (for Process); and key success-criteria (for Performance).
At the end of Purpose, we’ll have a set of chunks of context to work on – in our example above, how to fix the machine, how to assess probable production-impact, and what and how to advise customers – plus the overall descriptors for the big-picture. Note that in effect we have a one-to-many relationship here: one concern results in one big-picture but any number of chunks of context to assess.
Pivot sorts out the priorities for those chunks, then passes the chunks one-by-one to People.
In People, we split the respective chunk into a portfolio of suggested projects (each together with the list of associated stakeholders, which is why it’s still called ‘People’). Note that we have another one-to-many relationship: one chunk gives rise to any number of projects.
Pivot prioritises and passes those project-specs to Preparation, which (among other things) returns back a list of tasks (i.e. a Gantt-chart or suchlike). Which gives us yet another one-to-many relationship: each project gives rises to any number of tasks.
Pivot crosschecks those tasks, then sends them to Process to enact.
(It’s arguable that ultimately every action, every thought, every whatever, is part of some Process or other, at some level of fractality, from the concern-as-a-whole to the smallest micro-action. In essence, we choose the boundaries of process: the boundary of a process is where we say it is, because that’s where we say the boundary is. Yeah, another great big recursive rabbit-hole there, if we’re not careful… For Five Elements, we skip sideways from the rabbit-hole by saying that Process is an identifiable chunk of work, with an identifiable start-point and end-point, for which we’ve prepared in Preparation.)
Which, at the end of Process, leads to Performance. Where, as we review the benefits-realised and lessons-learned for a single task, we may need to unwrap the whole stack of nested one-to-many linkages – performance for that specific task, in context of performance for the overlighting project, in context of performance for the respective chunk, in context of performance for the big-picture, all in context of the initial concern:
- a nominal single concern may (and often will) have multiple sub-concerns
- in Purpose, we identify the common big-picture shared across all of those sub-concerns, but reframe the relevant aspects of that big-picture into one or more meaningfully actionable chunks
- in People, we expand the explorations for each of those chunks into a portfolio of project-specifications or equivalent – each of which is linked back to the respective chunk, big-picture and initial concern
- in Preparation, we expand each of those project-specifications into a set of actionable tasks – each of which is linked back back to the respective project-specification, chunk, big-picture and initial concern
- in Performance, we derive, verify and assess verify each of the outcomes and lessons-learned, in context of the respective task, project, chunk, big-picture and concern – in other words, not solely in context of the respective task
In essence, a single concern in Five Elements should, in Purpose, become described in context of just one big-picture – but might give rise there to maybe half a dozen chunks acted on in separate visits to People. Which in turn results in maybe dozens of distinct projects to be addressed in distinct visits to Preparation. Leading to maybe hundreds of distinct tasks to be enacted in Process. In turn providing maybe thousands of distinct learning-opportunities across all the teams of people involved in that original concern, creating the possibility of new capabilities and competences that become available for use in any number of future concerns. A single concern giving rise to maybe thousands of elements, all within what is nominally the same Five Elements session.
Now add into that complexity the potential for ‘jitter’, jumping back-and-forth to the Five Elements domains either side of the current focus – such as looking at previous Performance and possible future engagement of People whilst exploring Purpose.
And add into all of that the implication that each question or concern that arises anywhere in all of that exploration has the potential to become the triggering ‘concern’ for its own Five Elements session, fractally, recursively, indefinitely, yet all in context of the initial concern.
Five Elements looks simple: yet the reality is that a single Five Elements exploration, from a single concern, can give rise to a huge amount of complexity, a huge range of activities and outcomes. That’s the reality.
Yet we can keep it all simple, by remembering just a couple of key points:
- no matter how complex it gets, no matter how much expansion, no matter how much ‘jitter’, no matter how much nesting and fractality, the overall flow of Five Elements always goes the same way, from Purpose to People to Preparation to Process to Performance, and optionally onward to Purpose again
- Five Elements is also an action-checklist: even though it often can’t work as a simple-step-by-step, we also must not miss out any step – we must visit every Five Elements domain at least once during each overall exploration
So yes, it’s true that a Five Elements exploration can become quite complex. Very complex, at times.
Yet at root, a Five Elements exploration is also very simple. Despite all of the fractality, all of the complexity, all of the different tools that we could use at each stage and within each domain, there still always only the same five steps, always in the same overall order, each time always addressing the same overall types of activities and focus. As long as we keep track of which step we’re doing at each moment, without mixing them up, everything does work out just fine – no matter how complex it gets.
Five Elements looks simple. It is simple. Yet it’s that very simplicity that enables it to tackle any type of concern, in any type of context, with any content, any scope, any scale, any level of complexity.
We tackle complexity by keeping it simple. That’s what Five Elements allows us to do.