Viable Systems Modelling for Project Management part 3

My last post explained how the first of Stafford Beer’s VSM systems, System 1, can be applied to project management. Now we continue with looking at System 2. For a reminder of the whole VSM model see my overview post.

The role of System 2: Regulatory Centre

Last time we looked at the role of the individual Operational Units (System 1) and found that in the model they needed to have two-way communications between themselves and the rest of the system. We also saw that variety had to be properly dealt with. It’s the control of this inter-communication and variety that falls to System 2.

There are two key functions involved within System 2 – to provide local regulatory control of System 1 and to prevent undue oscillation. Whilst the first function is hopefully reasonably obvious, the second may not be so, thus bears some further explanation.

Imagine two operational units (A and B). A produces materials that are used by B. These materials are passed directly from A to B (in the diagram of the VSM (click to enlarge), this is denoted by the double headed arrows between the operational units O1.1, O1.2 and O1.3). In ideal circumstances, A would produce just what B needs, when it is required. B would not suffer lost time waiting for A, and A would not suffer from having to store stock through over production. “Lean” readers will recognise that this is central to “flow”. The regulatory function within System 2 knows whether the exchange is in balance or not, both at any given moment and also over time (I envisage it having its own version of a process control chart).  Let’s now further imagine that A in fact supplies other units as well (C, D and E). Say that A becomes under productive for some reason. Not just B, but also C, D and E are now threatened. Do they therefore get together and share what A produces to minimise the overall impact? Unfortunately, left to their own devices, normally they don’t. Normally they actually become competitive and try to build up their own stockpiles, and damn the consequences to anyone else! Trust and collaboration is lost. The systems start to work in extreme fashions. Oscillation sets in.

So System 2 works by making sure everyone knows what’s going on (local regulatory). A’s system 2 simply presents the information about production capability to all the other systems and also to higher order systems (corporate regulatory). In the diagram, the System 2 triangle is the corporate regulatory function, and the intersections of the vertical line that leads down from it and the horizontal lines that connect to the operational units are the local regulatory functions of System 2. The other units’ System 2 functions can then replan according to the new information, and higher order systems can take a view on whether intervention is needed to prevent potential oscillation.

System 2 also regulates variety. One way of doing this is to divide up the instructions that are coming down from higher levels according to what's relevant to System 1 units. Thus when the brain issues commands to walk, the nervous system doesn't convey this information to every muscle in the body, but only to those ones that need to know.

System 2 in projects

Project teams should work together towards a common goal. In reality they often compete with each other because of scarce resource (money, staff, expertise), and they certainly sometimes aren’t very good at sharing information! Yet project teams have a potential System 2 function available in the person of the team leader. Yet I have seldom seen it articulated that the team leader’s role is as much about communication between teams as it is about regulation of their own team. VSM teaches us that this communication role is essential.

The second problem with project (teams) is that communications – when they do occur – are not very effective. The communications need to contain useful information that is presented factually and non-emotionally. Let’s imagine that Team A has to produce design drawings for teams B and C. A designer goes off sick leaving the design team potentially unable to fulfil the design requirements on time. This information needs to be sent to teams B and C so they know about it. It may be that they can replan some of their work on other aspects to minimise the impact of the design delay. But if not, the information needs to be passed to higher level systems so that a decision can be made. In such a case the team leaders discuss the issue with the project manager: this takes place at the corporate regulatory level (the triangle).

The variety controlling role is also essential. How many times does one see a direct request going to a team to "just add this extra little bit"? System 2 needs to filter out this sort of "out of scope" demand and also inform System 3 that it's happening so that a higher level decision can be made - if necessary - about scope change. Again it is unusual to see this function being adequately fulfilled.

No surprises

This is not new. Having good information about what’s going on in a project is a central factor in project management. But all too often it doesn’t work. The VSM shows that what is usually lacking is clarity in System 2 functions. Team leaders need to collect and communicate information about their System 1 operations (their teams) in an open, factual way, withholding nothing. They also need to plan their teams’ work based on the information they receive. This role needs to be made clear and the right tools need to be in place to support it.

VSM lessons

So we have some further lessons for project management to add to those already identified, in the setting up and management of the project team:

1. Ensure that team leaders know their role in communicating information to the rest of the system (other teams, the project manager).
2. Provide fit for purpose tools for the collection and communication of the information.
3. Acting on information received, plan one’s own team work, passing back information about any re-planning that is necessary.
4. Carry out effective filtering to ensure that teams are not distracted by out of scope requests, but ensure the project manager knows about them.

As before, what VSM does is to underline how critical these aspects are, and clearly identify what needs to happen to remains stable.

I’ve alluded above to the passing of information to higher order systems, and in the next instalment I’ll be looking at how this happens with System 3.