Viable Systems Modelling for Project Management part 4

In Stafford Beer's VSM systems, Systems 1 and 2 are concerned with the operations of the system (see previous posts). However in any system there is the need to intervene if the operations are potentially in conflict (which can cause oscillation) or not doing what the system needs in a changed environment. This is where the higher-level systems, 3, 4 and 5, come in, and this article deals with System 3.

The role of System 3: Synergy Centre

As noted above, whilst System 2 looks after communications between operational units (System 1), it doesn't deal with potential conflict that emerge. These it reports up to System 3 for decision/action. So System 3's role is optimisation and generating synergy between Operational units (project teams). The diagram (click to expand) shows this by the fact that there is a link from system 3 to the top system 2 triangle.

Note the 3* triangle which feeds down to the operational units. (It's shown separately from the 3 rectangle). This is the audit function. Management cannot know everything that goes on within operational units - nor need it (that would contravene requisite variety), but it does need to know that things are as they should be. For that to occur there needs to be the ability to check that they are so: this is done via the 3* function, or audit.

So System 3 is responsible for:

• Ensuring resource allocation between each Operational unit is appropriate.
• Monitoring and changing the environments with which each Operational unit (project team) is involved if improvements can be made (usually in response to changing external conditions, but also if internal conflicts arise).
• Leading on from the above, changing the way outputs and information flow between the Operational units (but not tinkering otherwise).
• Reviewing the capacity of Systems 2 and 3 to deal with the entire complex of Operational units. This will involve both making the relevant decisions and making sure they are implemented. 
• Ensuring information systems are capable of producing thorough and up-to-date information, as follows:
• The Operational units must be accountable, so appropriate measures of what they do must get to System 3.
• System 3* does audits and surveys - it is an information service to System 3, looking at whatever is of relevance.
• System 3 must have a thorough model of all that it needs to know about the goings-on within the entire complex of interacting Operational units (project teams). Otherwise it will be making decisions in ignorance.
• An information system must be capable of generating alerting signals so that the organisation can find out that something has gone badly wrong as soon as it happens. Stafford Beer called this "algedonics".

System 3 in projects

This sounds awfully like the role of a project manager! Two very important principles emerge from this:

1. The project manager is not responsible for doing the work of the operational units. How many project managers find themselves getting involved with the actual production work of the project? This is anathema to the VSM because it compromises System 3's ability to be independent.
2. A critical role of the project manager is as an information exchange - receiving information from the Operational units (via System 2) and acting on it accordingly by issuing instructions back down the line and passing information up to Systems 4 and 5 if need be. In project terms this would be when tolerance is exceeded. Systems 5 and 4 communicate via System 3, so if strategic changes occur, System 3 is the nexus point for receiving the new strategy and translating this into appropriate actions for the Operational units (project teams).
3. The 3* function is not a project manager role - it is more the role of project assurance. My experience is that this usually does not happen at all, or if it does happen it's conducted by "professional auditors" who are not domain experts and who therefore concentrate on the wrong sort of information. In audit it's very tempting to gather lots of data and "analyse" it. For example looking at Board minutes, Risk Logs, Gantt charts. Instead project assurance (audit) should be about checking to see that actions are followed through and feedback loops are working correctly (e.g. escalation to Project Board, follow-up on work package actions).

VSM lessons

I have seen countless projects where:

• The project manager is too "operational", where he or she takes on too much responsibility - in effect this is project manager as superhero. It's simply not sustainable!
• The project board does not make good decisions because it is either flooded with too much information, or starved of information - this is a project manager role issue. Boards may also make poor decisions for other reasons, which we'll explore in a later post.
• Project teams compete for resources or don't align their input/output links well enough.
• Project assurance is more about checking whether the "process" of project management is correct than about whether the project management is working.

VSM shows us that the project manager role is critical in these respects. As before, this possibly sounds very familiar, and what VSM is - again - doing very clearly, is to illustrate the proper role and emphasise gaps or inconsistencies.

With Systems 1, 2 and 3 we have a complete model for the working of a system when the environment remains stable. But as we know only too well, things change over time, so the system needs the ability to monitor and adapt to the environment. This is where Systems 4 and 5 come in, as we'll see in the next and later posts.