Metaframeworks in practice, Part 3: Five Elements

What frameworks do we need to make sense of relationships, interdependencies and dynamics across the the whole of an enterprise?

This is the third of five worked-examples of metaframeworks in practice – on how to hack and ‘smoosh-together’ existing frameworks to create a tool that will help people make sense of a specific business-context:

In accordance with the process outlined in the ‘Metaframeworks in practice‘ overview-post, each of these worked-examples starts from a selected base-framework – in this case, Bruce Tuckman’s ‘Group Dynamics’ project-lifecycle sequence – and builds outward from there, to support the specified business-need.

Five Elements framework


There was no specific business-client for this one: it’s more something that I’d built up over many years and have used extensively in EA and management-consultancy over the past couple of decades.

It’s one of several base-frames that I use to provide a client-team with a simple yet reasonably-complete overview of their entire business-context. It can be used on its own, but it’s more often used as a base-frame with any number of other overlays, to give an almost infinite variety of context-specific frameworks.

Metaframework process

Start with Bruce Tuckman’s classic Group Dynamics project-lifecycle sequence:

Forming -> Storming -> Norming -> Performing -> Adjourning

Note that if this rotation is called a ‘cycle’, it ought to be a cycle, not just a linear sequence – which, via reciprocation or balance, suggests that the Adjourning at the end of a project should link up to the Forming of a new one. A compare of this to other cyclic models such as PDCA suggests that this does make sense.

Apply part-as-whole reflexion, to suggest that this is a pattern that repeats on larger and much-larger scales: the enterprise as layer upon layer of continuous-cycle ‘project-like’ activities. In the same way that different people tend to emphasise different parts of the project-lifecycle, different people or teams would emphasise different parts of the  enterprise-as-cycle. Hence:

  • Purpose: the Forming activities – strategy and the like
  • People: the Storming activities – HR, governance, arbitration
  • Preparation: the Norming activities – planning, scheduling, setup-logistics and infrastructure
  • Process: the Performing activities – production, maintenance, operations
  • Performance: the Adjourning activities – fulfilment, reporting, accounts, support, customer-satisfaction, review

Or, in visual form, as an explicit rotation:

Or, to give a (simplified) sales-oriented business-example:

  • Purpose: product- and/or service-definition, value-proposition
  • People: customer-profiles, clarification of market
  • Preparation: marketing, advertising, pre-sales, point-of-sale
  • Process: sales, sales-fulfilment
  • Performance: accounts-receivable, customer-support, performance-review

Note that since this is a reflexion of a small-scale (project-level) frame to a much larger scale, therefore recursion also applies: a Purpose-oriented team would enact its own Purpose, People, Preparation, Process and Performance, and so on. (In other words, these ‘phases’ are more accurately ‘lenses‘ through which to view activities and relationships between activities – not a ‘simplistic categorisation‘ of work or roles.)

Apply a cross-map overlay with other related ideas on enterprise-effectiveness: Efficient, Reliable, Elegant (simplicity etc), Appropriate (‘on-purpose’), Integrated. These map to the project-cycle respectively – and again recursively – as Purpose / Appropriate, People / Elegant, Preparation / Efficient, Process / Reliable, Performance / Integrated. Or, in visual form:

It’s not a direct mapping: one key difference is that the ‘effectiveness’ group do not have a natural sequence, but present a more freeform ‘rotation‘ in which the elements interweave with each other in any number of different and often recursive ways. The reason for maintaining the cross-map is that each phase in the project-cycle does tend to emphasise or rely on the respective effectiveness-element.

Via serendipity, that cross-map reminds me of much earlier work I did for my 1978 book Needles of Stone, in a chapter on the traditional Chinese wu xing or Five Elements model. The cross-mapping to the project-cycle fits exactly, yet also with the same free-form ‘rotation‘ as for the effectiveness-elements – with the key point that the apparent linear sequence of the project-cycle is the only interrelationship-path in which each element actively supports the next in the sequence. This has immediate practical applications in conflict-modelling and conflict-resolution across an enterprise, such as in this example of a conflict between scientists and engineers in an Australian research-establishment:

And in another serendipity, I come across Nigel Green and his work on VPEC-T (Values, Policies, Events, Content, Trust) as a form of ‘lenscraft’ for inquiry into relations between stakeholders across a complex enterprise:

VPEC-T (“vee-pec-tee”) is used where interaction between agents and communication between parties can easily result in ambiguity. This form of analysis is particularly applicable where it is likely that the interaction and communication context is unordered, complex or chaotic, and liable to result in misunderstanding.

In their book Lost In Translation, Nigel and his co-author Carl Bate summarise the VPEC-T lenses as follows:

  • Values define the context
  • Policies direct the context
  • Events trigger change within the context
  • Content informs the context
  • Trust dominates the context

I try out a cross-map between this and the overall Five Elements, but it doesn’t fit at all – there is a clear mismatch. However, in another serendipity, I note that if I skew the cross-map by half a step ‘forward’, it does map quite well: not as dimensions, but as transitions. For example, the bridge between Purpose and People – that which links People to Purpose – could be summarises as ‘Values’.

There’s still a mismatch in this new cross-map, around ‘Content’, which doesn’t make sense as a transition between Process and Performance. But then I remember that in the original VPEC-T, ‘Content’ is a dimension – not a transition – and hence it would be legitimate to rethink that part of the frame more explicitly in terms of transitions. (‘Content’ actually applies everywhere throughout the frame.) This gives a revised transition of ‘Completions’ – a set of end-events – between Process and Performance. Overall, in visual form:

That last cross-map is particularly useful as a means to summarise the different types of leadership needed throughout a project-lifecycle and across an enterprise, and the various phases and contexts for which each respective form of leadership would be most needed. (Or, for that matter, least-needed or least-appropriate.) The catch is that that re-use of the VPEC-T frame is definitely ‘non-standard’ – a point that needs to be emphasised in order to avoid confusion with the original frame.


The Group Dynamics frame is public-domain, and, as the Wikipedia-page shows, has already been ‘hacked’ and re-purposed in many different ways: no relations-problems there.

The effectiveness-set was my own work, so again the same applies.

The classic wu xing frame has been around for well over two thousand years, in many different forms and variations. The version I’ve used in the cross-map here is applied exactly as per a well-established version; there’s also a lot more depth that can be added, courtesy of many historical wu xing cross-maps in Chinese tradition, in relation to medicine, music and much more.

The one ‘danger-area’ was around VPEC-T, which is not only semi-proprietary, but I’m also re-using it here in a clearly non-standard way. Nigel Green was definitely concerned about the potential clash and confusion, but was happy to help me sort it out and minimise the risk: see the posts ‘Not quite VPEC-T‘ and ‘More on ‘Not-quite VPEC-T’‘ for more detail on those discussions and their outcomes.


I’ve used this framework, in many context-specific forms, in much of my enterprise-architecture and consultancy work over the past decade or so. Each consultancy-task seems to bring up a requirement for yet another new cross-map on this base-frame, using the same metaframework-techniques to create a custom framework for that particular context. At present it’s proving especially popular in Latin America, as a way to visualise the interactions across an entire enterprise.

In my 2008 book Real Enterprise Architecture, I used the 5×5 matrix of the project-cycle / effectiveness-elements cross-map as a base-frame to explore the context of whole-enterprise architecture.

There’s also a summary of the combined Five Elements frame in my 2008 book SEMPER and SCORE. That chapter also describes several other cross-maps on the same base-frame, such as to time-frames, asset-categories and more.


The key lesson-learned here is that base-frames and useful cross-maps can arise from just about anywhere, and from just about any period. In this case, the main sources include:

  • project-management (US, 1960s) – the Group Dynamics model
  • quality-management (US/UK 1940s, Australia 1990s) – effectiveness-map
  • Chinese tradition (China, c.500BCE) – wu xing / Five Elements model
  • enterprise-architecture (UK, 2007) – VPEC-T

It’s therefore valuable to maintain an eclectic range of interests and connections, as doing so enables the strongest possibilities for serendipity and mismatch for metaframeworks.

Next worked-example: context-space mapping and SCAN, a method and general-purpose framework for sensemaking in enterprise-architectures.

For now, though, any questions or comments?

Leave a Reply

Your email address will not be published. Required fields are marked *