Viable Systems Modelling for Project Management part 7

If you have followed this series so far you’ll know that we have looked at each of Stafford Beers 5 Systems within the Viable Systems Model, relating them to project management. What more is there? Well Beer’s model is recursive, or fractal, and this is what this article covers.

The by-now familiar VSM diagram, reproduced here, shows the 5 Systems and how they are interconnected. If you look at System 1, you’ll see that each sub-systems (O1.1, O1.2 and O1.3) are represented as a circle topped by a square (though it looks like a diamond because the systems are skewed to the right). This is because each of these sub-systems can be viewed as a system in its own right, and thus will have its own Systems 1 through 5.

In project management terms, each sub-system could be a team within the project. So each team has its operational level (System 1) and so on. For example the team supervisor is the equivalent of the project manager, so as well as being System 2 in terms of the whole project system, is System 3 in terms of their own system. And the project manager role represents higher level to the team system so is the equivalent of Systems 4 and 5.

This recursiveness continues: each person within a team is a system in their own right.

And the project is embedded within a larger system: for example is could lie within a programme, or within a portfolio. So just as the VSM helps with an individual project to see if all systems are in place (and hence viable), it also helps as you move up or down through the nest of Russian dolls that is the VSM recursion!

There is both a powerful message and a danger in this. The powerful message is that each operation (system 1) has it's own 5-system structure, including management. Looking at the big green square in our diagram (the "system in focus"), the message is that it should not become too involved in the detailed management of the operation (the large system 1 circle), because that it the responsibility of the next level of recursion - the smaller green squares. An example is work package management: once a work package is handed off to a team, it is not the job of the project manager or Project Board to plan exactly how that work should be carried out, allocate it to team members, etc..

The danger is that the lower level management function misunderstands the recursive model and tries to do the higher level management functions as well. An example of this would be if a team directly requests work from another team beyond what has already been agreed within the project. A case like that should be managed by the project manager.

In the final post in this series (coming next) I’ll try to summarise everything and come up with a VSM for projects checklist (if such a thing is not an oxymoron).