Viable Systems Modelling for Project Management part 8

In this series so far we have looked at each of Stafford Beers 5 Systems within the Viable Systems Model, relating them to project management, and also how the model is recursive so that the 5 systems are repeated at both lower and higher levels. I promised a round-up final post that proposed a VSM check-list for project management. That was over a year ago - how time flies! But I have got there eventually.

The Viable Systems Model check-list for Project Management

In the check list below you will find tags for which part of the systems things are in (systems 1 through 5) and whether or not they are to do with variety accentuation or amplification.

1. Ensure that you have requisite variety:

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. Without this the project (the system) will be unable to cope properly with the variety within the project. For example, hand-offs between teams where a team is no ready or able to take on the demands from other teams within the project. This is a Project Board responsibility.
2. Ensure that external variety is properly handled: This is the job of the Project Board, and is essentially about scope management. Demands for changes in scope (external variety) need to be properly attenuated (filtered) so that scope change is managed. If all change demands are allowed, the project resource would soon be swamped and unable to cope.
3. Ensure that good two-way communications exist between the teams and up to the Project Board: This is another resourcing issue. Communications don’t happen without time and effort. We need to set aside resource to make sure this happens. Communications are a key amplifier for projects (i.e. to ensure that project messages are properly heard and understood). A typical example of this not working is when new systems and processes are not adequately embedded in the business environment. To help enable this:
• Project Manager: Ensure that team leaders know their role in communicating information to the rest of the system (other teams, the project manager). 
• Project Manager: Provide fit for purpose tools for the collection and communication of the information. 
• Team Leader: Acting on information received, plan one’s own team work, passing back information about any re-planning that is necessary. 
• Project Manager and Team Leader: Carry out effective filtering to ensure that teams are not distracted by out of scope requests, but ensure the project manager knows about them.
• The Project Board does not make good decisions because it is either flooded with too much information, or starved of information - it's the job of Project Manager to ensure this works properly. 

2. Provide adequate autonomy:

1. Don’t micro-manage what project teams do: Project Boards should not interfere with the day-to-day work of the project team (system 1). Once the overall instructions have been issued, leave them to get on with their job.
2. Avoid the Project Manager being 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 Manager should stick to the higher level coordination of project activities (system 2).
3. Project Teams may compete for resources or not align their input/output links well enough. In this case the Project Manager should be involved - this is all about being sensitive to when project teams can be left to their own devices, and when it's necessary to intervene (a classic system 3 role).

3. Make audit work:

1. Project Assurance is the 3* system of  project management. Its role must be to check that the project is working well enough so that the desired outputs and outcomes are being produced (if possible, on time and within budget; but certainly within the constraints set by the Project Board). Avoid making the mistake that checking the process of project management is the same as doing adequate assurance. Checking risk logs or Gantt charts is not the same as checking outputs and outcomes!

4. Beware of the environment:

1. Projects must be aware of the external environment in both the short-term and long-term. The former is dealt with by direct links between the teams (system 1 operations) and the environment. For example, if you are planning a system upgrade, you need to link it into the operational cycles of your business (e.g. you don't do it at critical busy times). This is the job of the Team Leaders and to some extent the Project Manager (to check it's happening).
2. The long-term concern is a system 4 function, and this is the job of the Senior Supplier and Senior User. For example is the Senior User knows a change is on the horizon in terms of the normal operational cycles, this needs to be fed into the project and the short-term environment scanning won't pick this up.
3. Sometimes big changes will happen, and if system 4 is doing its job well the project should get enough warning to review and potentially adjust. This could lead to scope changes - but these need to be controlled by the Project Board. (this is a system 5 role).

When things go wrong

Change:

Things go wrong in projects when there is a breakdown in one or more of the system roles. Change is a constant for all projects, so one of the first things to note is that each system must play it's proper role in dealing with change. Change in project jargon is defined by risks and issues (risks identify possible sources of change, and issues are when change happens).

1. Project Teams will be sensitive to changes in the immediate environment and to changes in resources, and part of their system 1 role is top ensure that changes are communicated to system 2 (the Project Manager) 
2. Such change will be subject to fluctuation, so the Project Manager needs to assess whether the change is serious enough to escalate it (to system 3) - this is part of the system 2 role.
3. System 3's role in this respect is to decide whether adjustments need to be made in operations as a result of change, and whether to flag this up to systems 4 and 5. This is another of the Project Manager's roles.
4. At the Project Board, the changes are considered in the light of the larger environment and the wider business implications (with input from Senior Supplier and Senior User) - this is systems 3 and 4 at work.
5. The Project Sponsor has final say (along with the Project Board as a whole) in deciding what to do about the change - system 5.

Scope:

Change can also happen if the scope is redefined. A project that is being properly managed as a viable system will have structures in place to identify potential scope changes and to deal with them.

1. Identification is the responsibility primarily of the Senior User (system 3) and the Senior Supplier (system 4), to some extent the Project Manager (system 3).
2. Decisions about scope change fall within the remit of the Project Board and Sponsor (system 5).

Risk management:

Risk has an impact on change (see above), and is often glossed over in projects because it is situated within the wrong part of the overall system. Most Project Boards would, where risk management is poor, define the responsibility for risk management as part of the Project Manager's role. However identifying risk is about an awareness of the external environment at system 4 level, and an awareness of the business at system 3 level. This puts the remit for risk firmly within those two systems, and thus management of risk as a Project Board (system 5) function.

The complete VSM diagram here can be clicked to enlarge.