#vpect is a deceptively simple systems thinking lens developed by a couple of friends of mine (Carl Bate and Nigel Green), and described in their book Lost in Translation. The letters stand for Values, Policies, Events, Content and Trust. For a good brief description, see VPEC-T the 5D lens by @RoyGrubb.
Besides using the VPEC-T lens in a number of practical situations, I've also run a couple of Next Practice workshops featuring the VPEC-T lens. My own experience leans towards using VPEC-T as a diagnostic lens - for understanding problems, analysing requirements and identifying risks, and I have found that people accept this pretty readily. I have previously posted some examples of this kind of diagnosis on this blog (see VPEC-T category), and I've recently been using VPEC-T as a lens to help me build an Organizational Intelligence assessment and diagnostic tool.
In a systems thinking context, diagnostic tools are useful to appreciate the positive aspects of an existing or proposed system (why it works at all) as well as the negative aspects (why it doesn't work as well as it could/should). Therefore not just analysing problems but also checking that a proposed solution represents a real and effective improvement on the status quo. But a diagnostic tool alone cannot produce solutions, it merely helps you evaluate any given solution. In other words, it tells you what's going on, it doesn't tell you what to do, but it might tell you what not to do.
Which raises the question whether VPEC-T also works as a problem-solving and design lens. From my own experience as well as the examples I've looked at, I have always got the impression that the heavy lifting in design terms is done by the P-E-C elements (Policies, Events, Content), especially in an IS context, with V and T helping to frame the organizational change and adoption engineering.
This impression was confirmed by a tweet today from Nigel, who said he had been "doing a lot of P-E-C work recently but now the gears were shifting to the V and the T big time" (@taotwit). "While P-E-C can help shape design patterns the V and the T are required to get buy-in to them" (@taotwit). Chris Bird agreed: "I think you have to have your PEC thinking in place so you can illustrate VT during change project" (@seabird20).
VT is certainly important for adoption engineering, but we certainly shouldn't regard design and adoption as two separate questions. Does it make sense to talk about "solving" the V and T requirements as well as the PEC requirements? (For example, in designing a communication system joining two professional communities with distinct value systems and a history of mistrust, what are the sociotechnical design patterns that can support healthy and productive collaboration across the trust divide.)
VPEC-T practitioners may set out with the intention of paying attention to all five dimensions in a balanced way throughout a systems intervention, but this is not easy. As Nigel says, "Believing that VT are critical to maintain throughout a change programme is vital (@taotwit) but getting folk to keep it high on their agenda when they get focused on PEC in say, a design cycle, is a big challenge! (@taotwit)" And conversely, "sometimes the PEC messages can get swamped by VT debates" (@taotwit).
As a diagnostic lens, VPEC-T has been used to help understand a broad range of organizational and social questions. However, all of the examples I've seen of its use as a problem-solving and design lens have been within the IS domain. So I shall be interested to explore the use of VPEC-T as a problem-solving lens in other domains.
No comments:
Post a Comment