Viable Systems Modelling for Project Management part 2

In my previous post I introduced Stafford Beer’s Viable Systems Model (VSM) and how project management can fit in with it. In this part we’ll be looking at the first of his five systems: System 1 – Operational Units.

The role of the Operational Unit 

In one sense, this is the most important part of the system, because here is where the “work” gets done. In human body terms, it’s what the different parts of our body just get on with, without our having to think about it: heart beating, breathing, digestion, and so on.

Many parts… one body

St Paul understood that the early church comprises different parts and that these all had to work together in harmony (1 Corinthians 12). He was an early systems thinker! Beer’s VSM shows very clearly that operations are divided up into different operational units – each with its own role.

In project management terms, this has two key implications. The “operational units” of the project need to be clearly identified and carefully designed. It’s common sense, really, because all I’m saying is that you have to make sure you have the right resources available and enough of them. But how often is it that one’s host organisation pays lip service to this? Project teams – if they exist at all – have to fit in the project work around their day jobs. The first lesson from VSM, then, is do not skimp on this aspect of setting up a project. Cut corners here and problems with viability are bound to happen later on.

Autonomy

Not only do we not have to think about the body’s different activities; for the most part we ignore them and leave them to get on with things on their own. They are autonomous. They don’t need instructions from higher up because they know what to do.

For projects, then, this means that the operational units should not be tinkered with. Project boards should not be too operational, too details focussed. (Of course the complete opposite may occur, but that’s the subject for a later part, when we look at System 5). Again, this seems like common sense, but how many projects get this right?

Independence

Autonomy is not the same as independence. In the VSM operational units are not independent. They can’t declare “home rule”! (St. Paul recognised this too). The operational units are highly dependent on each other. This means they need to understand what the other units are doing, and they need to tell other units what they are up to. Two-way communication. As they receive information about other units, they should make adjustments in their own work neither to demand too much input nor provide too much output (overload).

Project frameworks like PRINCE2 do indeed recognise this, but I don’t think they pay enough attention to it. It really is critical that we get this right, or again we have a recipe for disaster.

Variety

I had been in two minds whether to write about variety earlier on, but have decided to leave it to here as it seems a good place to introduce this key aspect. Beer borrowed from Ross Ashby's seminal work on variety, and it's underlying rule that only variety can absorb variety. Let's take a simple example of a coffee shop. Imagine that the shop regularly has around 1000 customers a day and between them they create demand for 25 varieties of coffee. The only way that the shop can "absorb" this variety in demand is to stock 25 different types of coffee. We would say, in formal terms, that the shop has "requisite variety". However let's say that two of the varieties are only rarely requested, and if the shop keeps these in stock there's a risk they'll go out of date. So it offers 23 varieties and is apologetic to customers when they (rarely) ask for the other ones. It no longer displays requisite variety, but the compromise is acceptable to the customers, who continue to come and allows the shop to operate on a viable level.

In reality, the amount of variety is usually far higher than we can sustain economically - for example in a school it would be wonderful to have a one-to-one teacher to pupil ratio, but this is not economically viable!

For System 1 this is key because it has to deal with both incoming variety - which is usually greater than it's own internal variety - and also make sure its outputs are properly dealt with even though the environment into which it puts them is far richer (so it needs to be noticed). So on the input side of System 1 there needs to be a filter that cuts down incoming variety (Beer calls this an attenuator) and  a mechanism for making itself heard to the environment (an amplifier).

In project terms we can think of this as having a clear scope - this creates the incoming variety filter. And on the output side we need to ensure that the deliverables are used effectively, so there needs to be an effective means of embedding this in the external environment (communications, training, etc.).

The lessons for projects are that changes to scope have to be very carefully controlled, and also that the delivery teams are both clear about their scope and stick to it. There also need to be good mechanisms for ensuring the deliverable items are properly handled.

VSM lessons

So we have three clear lessons for project management, in the setting up and management of the project team:

1. Identify the right resources and put them in place:
   This means that people need to be freed to do the work needed within the project, and we need the right people to do the job. 
2. Don’t micro-manage what they do:
   Project boards should not interfere with the day-to-day work of the project team. Once the overall instructions have been issued, leave them to get on with their job. 
3. Ensure that good two-way communications exist between the teams:
   This is another resourcing issue. Communications don’t happen without time and effort. We need to set aside resource to make sure this happens.
4. Ensure there are good attenuation (scope control) and amplification (output embedding) mechanisms.
   Controlling variety effectively is essential to the viability of a project. One of the greatest causes of project failure is when scope is not properly managed: it's a requisite variety issue!

None of this is new in project management terms, but what VSM does here is to remind us how critical these aspects are, and it emphasises the fact that if we get any of this wrong, the system (i.e. the project) will become unstable; non-viable.

Next we’ll be looking at System 2 – and returning to the communications and management issues to see how the management of operational units should take place in practice, within the VSM.