Identifying meaning in context: VPECS and VPEC-T

In a multiple-stakeholder enterprise – which, in practice, is the case for every enterprise – how do we make sense of how each stakeholder views the context? What’s important to them? What’s not important to them? And why?

And given all of that, how do we, as enterprise-architects, bring all of these different views together to build something that works well for everyone’s needs?

Not easy…

For a long time now, one of the key tools I’ve used for this part of my work has been VPEC-T (Values, Policies, Events, Content, Trust). It was developed by Nigel Green and his colleague Carl Bate, and documented in their 2007 book Lost In Translation. As the Wikipedia entry puts it:

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.

Nigel and Carl Bate summarise the roles of the VPEC-T ‘lenses’ as follows:

• Values describe that which defines the context
• Policies describe that which directs the context
• Events describe that which triggers change within the context
• Content describes that which informs the context
• Trust describes that which dominates the context

Or, in visual form, each of these lenses focus in turn on a given context:

Importantly, there’s no sequence to this: the lenses are used in any order, as appropriate, often iteratively or recursively.

The catch there is that sometimes – particularly in service-design – we do need to know and understand how themes play out in sequence as well.

Somewhat in parallel to Nigel and Carl, for many years I’d been using a variation of the classic Chinese wu xing or Five Element model as a way to describe relationships different areas or roles of an enterprise – see my post ‘Metaframeworks in practice, Part 3: Five Elements‘ for more detail on this.

In Five Elements, the order in which we do things is very important. We can do the various aspects of the work in just about any order, if we really want to, but in practice there are very clear patterns between sequences that work well, versus sequences that don’t.

In visual form, the ‘five elements’ – here shown as Purpose, People, Preparation, Process, and Performance – form a distinct sequence of activities across the overall enterprise, or even within any aspect of that enterprise:

These are domains of activity; but there’s nothing that specifically indicates what would trigger or guide the shift from one emphasis to the next.

And what I saw with VPEC-T was that it seemed to provide exactly those necessary triggers. Or something very similar to VPEC-T, anyway – a point we’ll need to come back to in a moment:

• vision and values provide a bridge between Purpose and People
• policies and procedures provide a bridge between People and Preparation
• identifiable start-events provide the transition from Preparation to Process
• identifiable completion-events mark the end of Process and the start of the closure and review of Performance
• reaffirmed trust is the desired-outcome of Performance that links back to Purpose

From there, it then seemed that we can usefully combine the two frameworks – Five Elements, and VPEC-T – into one single dynamic framework:

It all seemed to fit pretty well, although there were few rather noticeable kludges: strictly speaking, each of these transitions was an Event, and Content was distributed throughout the whole sequence, much as indicated in the Service-Cycle:

Or, for Enterprise Canvas, we would describe Content in a different way entirely, based more on a modified form of Zachman than on VPEC-T:

As described in my post Metaframeworks in practice, Part 5: Enterprise Canvas, we can then link all of these together – Service-Cycle, Five Elements, VPEC-T, the Enterprise Canvas service-model – into a kind of single zig-zag frame that summarises all of the interactions and the respective stakeholders in each stage of service-delivery:

In practice, in unravelling the complexities of service-design, that works really well as a visual summary.

Yet there’s a catch, a really, really important one that’s all too easy to miss: this isn’t VPEC-T as specified in the ‘Lost In Translation‘ book. It’s the same acronym, with some of the same meanings for each element of the expanded acronym, but they’re all used in a different way.

And if we don’t keep a clear separation between this and the original VPEC-T, we’re likely to create all manner of unwonted and unnecessary confusions further down the track.

That point created quite a bit of worry for me and, even more, for Nigel Green. We met up to discuss this, a couple of years back, and as described in my posts ‘Not quite VPEC-T‘ and ‘More on ‘Not-quite VPEC-T’‘, we came up with a summary that provides just about enough of a separation between the two usages:

• the original VPEC-T (with hyphen) describes a set of ‘lenses’ – it does not imply any kind of sequence
• the service-oriented usage of VPECT (no hyphen) – as in Enterprise Canvas and the Service-Cycle – does describe an explicit sequence of transitions

In other words, the service-cycle VPECT is definitely related to the original VPEC-T, but the usages and roles of the two frames are somewhat orthogonal to each other.

That’s an adequate compromise, but perhaps still not quite clear enough to reduce the risks for potential confusion between the two. There it sat for some fair few months, anyway.

Yet just recently, whilst doing some rethinking and rework around the Service-Cycle, it struck me that there’s another way we could do this, which actually fits better with how the service-cycle actually works. It still has the same transitions between the Five Elements, but there are two subtle shifts:

• Trust and Commitment are actually the core of everything – hence needs to be the central reference-point for all activities, rather than solely in one specific transition
• the transition that links past Performance to indefinite-future Purpose is verification of Satisfaction and Success, in terms of the success-metrics derived from the enterprise vision and values

The explicit Event the marks the transition from Preparation for service-delivery and into into active Process of service-delivery could perhaps be more accurately described as the Initiating-event, to match the set of Completion-events at the end of service-delivery. But it’s probably easiest to leave it as ‘Event’, because that’s usually the one type of event that people most notice and describe as as ‘an event’.

Overall, then, that gives us a revised-acronym of VPECS. (Or VPICS, to acknowledge the Initiating-event – or VPECS-T or VPICS-T, if we’re going to include Trust as well – but it’s probably easiest to leave it just as VPECS.) Or, in visual form:

So, to summarise, on the differences between VPECS and VPEC-T:

• use the VPEC-T acronym to describe the form of ‘lenscraft’ specified in Lost In Translation
• use the VPECS or VPICS acronym if you mean this sequence-oriented frame above

But most important, though, don’t mix them up: they’re related, but they’re not the same.

I’ll update my diagrams over the next few weeks to reflect this shift.

Hope this makes sense, anyway – over to you for comment?