Project Viability – a cybernetics approach, part 3

In the first part of this series I introduced the idea of Requisite Variety and attempted to outline how it might apply to project management.  The second part looked in more detail at the inputs into a project from its external environment and the need for Attenuation (or filtering). This third installment covers information flows within the project.

A bit of VSM

Before considering project information flows internally, it’s important to understand how a cybernetic approach might work, drawing on Stafford Beer’s classic Viable Systems Model^[1] that I have been using so far. The diagram shown here illustrates the five systems within the model, and these can be very roughly defined as:

• System 1: Operations = project teams
• System 2: Operational Coordination = team leaders & project manager
• System 3: Operational Control and Audit = project manager / project assurance
• System 4: Research = project board
• System 5: Policy and Strategy = project board

Systems 3-5 are part of “management”, system 1 is wholly operational and system 2 bridges the gap between them. All of these components need effective inter-communication to work effectively, but with communication lines running between everything, the system could easily get overloaded. An example of this, in project terms, would be if every task was reported in detail to the project board.

Project methodologies such as PRINCE2 recognise this, and put structures in place to prevent this overload and to maximise effectiveness of communication. Indeed much of these methodologies can be mapped directly to the VSM. However this correspondence is not deliberate or conscious (I don’t think, for example, that the authors of PRINCE2 considered the VSM when creating the methodology). So this means there are also gaps. It’s in identifying these gaps that we can make the most improvement in projects, because once we know about them, we can fix them and thus improve project communications.

Attenuation and Amplification

Harking back to Part 1 of this series, you will recall that incoming information needs to be attenuated (filtered) and outgoing information needs to be amplified. So if you imagine there are an attenuator and an amplifier connecting every part of the VSM, you’ll have an idea of how this works. The VSM diagram above shows just one linking line in order to keep it uncluttered but in fact every connection has an attenuator and an amplifier.

Operations communication

Looking at the VSM diagram we can see there are four obvious communication links for operations, plus a fifth less evident:

1. Between the environment and the operation (dealt with in Part 2 of this series);
2. Between the different operations themselves (e.g. O1.1 and O1.2). All the operations should be interconnected. The diagram doesn’t show this (for simplicity), but O1.1 is also connected to 1.3.
3. Between each operation and its system 2 coordinator
4. Between system 3* (three star) and each operation: 3* is the audit function
5. Between the operations and systems 3/4/5 – this is via system 2

Inter-team communications (system 1)

The operational units equate to project teams. In the project scenario introduced in Part 2 (purchasing an IT system to enable a customer-facing reception desk to log calls) we might have a tender preparation team, a purchasing/contracts team, a system implementation team, and so on.

Gaps can and do occur if we don’t ensure that there are communications covering all of the above teams. For example, if there are four project teams, there needs to be six interconnections as shown to the right. However even this more detailed diagram simplifies the true picture because recall that there are attenuators and amplifiers for each operational unit. The next diagram illustrates this for one pair of units: each unit has one amplifier (shown in blue) and one attenuator (red) so that’s four links, and therefore 4 x 6 = 24 links overall in our four unit model. If you add more units the number of lines of communication grows exponentially!^[2]

In projects there are often gaps of communication between teams for this very reason, and this usually leads to problems because things get overlooked as a result (e.g. leaving something out of the tender requirements). But if all the teams communicated according to the model they could easily get flooded out – and that’s just the inter-team communications, let alone the others listed above.

The trick is to use the attenuators to filter what’s not needed, and the amplifiers to make sure the communications are properly addressed. Anyone who works on IT networks will recognise this system because it’s a classic networking communications protocol. If you look at the diagram on the right, imagine that each team is “listening” to the communications traffic that’s flowing around the network. What they are listening for is some kind of flag that tells them this communication is pertinent to them – if they detect that flag, they pick up the communication packet and look at its content, otherwise they just let it flow on past. The red arrows are the attenuators, which are “listening” to the communications traffic and picking out what’s meant for them, so O1.3 will pick out the packet O1.3-ABCD but will ignore O1.1-1234.

The amplifiers work in reverse: if O1.4 needs to make sure that O1.1 listens, then its packet is labelled O1.1-XXXX so that O1.1 picks it up.

There might also be some special message that everyone needs to hear, so an agreed flag (e.g. XX) can be used: thus all teams will pick up the packet labelled XX-9999.
The point is that there is:

• a communications network that connects up all the teams, and
• an agreed protocol for how the teams message each other.

I have rarely seen anything like this actually created in a project environment, though Agile “stand ups” come close.

Here are just a couple of examples of how something like this might work in reality:

Use a Twitter feed
Agree the feed’s hashtag (i.e. the project name, e.g. #callogger) and then the hashtags for the individual teams or types of message. The Twitter feed is set to filter on the main project hashtag [#calllogger] and you only pick out the hashtags meant for you/your team such as [#calllogger #team1 we need advice on IP – team 2] – Team 1 will pick this up and know to contact team 2. Team 2 is not tagged here because it’s the sender. Another message, such as [#calllogger #ALL there is a milestone meeting in room 99 on 12 December], gets picked up by everyone because of the #ALL tag.

NB: I’ve chosen Twitter because it forces you to keep messages short, but other social media channels like FaceBook or LinkedIn would work as well.

Email
Twitter is great because – like other social media channels – it allows you to see all the communication traffic, and you can also filter it. With email there is the danger that the sender can “over filter” – because email can be point to point as well as broadcast. So if I choose to send an email to team 1, the other teams will have no chance of seeing it (unlike in the Twitter example).

The trick is to have a joint email account that everyone can see, and to use the subject line for the filter. The joint email account equates to the #callogger project hastag, so that doesn’t need to go in the subject line. This the messages above would be headed simply [Team1 we need advice on IP – team 2] and [ALL there is a milestone meeting in room 99 on 12 December]. This could be further refined by using colour coding (e.g. in Microsoft Outlook you can set categories up for each of your “hashtags”).

As well as having flags for individual teams and “ALL”, you can define other special purpose flags such as HELP and INFO – just don’t go overboard with too many or you defeat the object!

What you end up with is a shared communications channel so all teams can see the information flow, with a handy means within that to flag individual communications so that attenuation and amplification work effectively.

Systems 1 and 2 communications

Each team needs to be able to communicate with its system 2 coordination function, and each of the systems 2s need to be able to communicate with each other and also with the “master” system 2 coordinator which is seated in “management”. In project terms the system 2 function is taken on by team leaders, and the master system 2 function is the project manager.

They also need to be able to communicate in the same way as has been described, i.e. all system 2 nodes need a shared communications channel. This will work in exactly the same way as the above: in fact the very same channel can be used.

So a tweet might read [#callogger #PM we need extra resource TL1] – which decodes as a message for the project manager (#PM) from team 1’s team leader (TL1).

The type of communication will be higher level, but the same channel can be used, and the same protocols.

System 2 and systems 3/4/5 communications

This is no different: all we need is additional tags to identify the new components. System 2 will need to communicate regular items to management, such as project update reports, budget status, etc., and also have the ability to flag extraordinary or ad hoc messages. So if the message [#callogger #PM help run out of money T3] is picked up by the project manager, the PM can then message [#callogger #SPON need urgent budget meeting PM].

System 3* communication

In effect we now have a project wide, shared communications channel and a mechanism for filtering out what we don’t want, plus amplifying our messages so that they get picked up by the right target audience.

System 3* has a special role in the VSM: it provides an audit function to check at a detailed operational level that everything is running fine. System 3 is the primary recipient, hence the 3* label, and system 3 would then pass on any necessary information as result of the audit, e.g. to the project manager or project board. The problem that audit has is getting to the information - but this shared channel solves that, and the auditor can simply randomly sample all of the communications, or selectively filter parts they want as appropriate.

In project terms, audit is project assurance. This is a role I have seldom seen carried out well, or at all, and I suspect it’s because the way the system is configured isn’t sufficiently viable. The VSM helps solve that, and the above example illustrates how.

What about rich information?

The Twitter, and to some extent, email examples are fine for short messages – but what about richer information such a project plans, the Invitation to Tender document, the system Functional Design Document, etc.? This is just a type of “packet content” in network terms, and all you need is the vehicle to carry and expand it as required. So a tweet that says [#callogger #TL2 draft ITT is here PM] includes a hyperlink to the ITT (Invitation to Tender document) - NB there is no actual link in this example.

Responsibility to listen

This process only works where every part of the system takes the listening role very seriously. If the shared communications channel is ignored the mechanism will fall apart. In the human body, if a muscle stops “listening” to its system 2 nerve coordinator, it can’t respond when the brain says “run”. Likewise, if the brain stops listening, it won’t pick up the muscle’s “help I’m starting to cramp”. Similarly each component system of the project must keep a weather eye on the communications channel – this is just as true of the sponsor as it is of a team leader.

In conclusion (for this part)

1. We can provide more effective internal project communications if we have a shared, broadcast style communications channel and agreed protocol for how to flag the messages within it.
2. Each component of the system has a responsibility to monitor the channel on a frequent and regular basis.
3. Because the channel is shared across the whole project, project assurance is made easier because there is access to all project communications.

In the final part of this series I’ll look at amplification and the environment.

---

References
[1] Beer, S. (1972) Brain of the Firm, John Wiley & Sons, Chichester, (2nd edition with new material published 1981)
[2] Brooks, F. (1975) The Mythical Man-Month: Essays on Software Engineering,  Addison-Wesley, Boston (Anniversary edition with new content published 1995)