Blog Posts Enterprise Architecture (EA)

Fractality in Five Elements method

Blog: Tom Graves / Tetradian

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:

Hence, overall:

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:

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.

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="https://www.businessprocessincubator.com/content/fractality-in-five-elements-method/?feed=html" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples

BPMN.org

XPDL.org

×