Communication Risk
Part Of
Reduced By Practices
- Analysis: Facilitates clear communication of requirements and expectations among stakeholders.
- Approvals: Provides formal communication of acceptance and readiness.
- Demo: Facilitates clear communication of the product's features and benefits to stakeholders.
- Design: Provides a clear structure and organization, making the system easier to understand and use.
- Documentation: Provides clear guidelines and information, reducing misunderstandings.
- Issue Management: Facilitates communication about issues and their status among team members.
- Marketing: Facilitates communication of the product's value proposition to the target audience.
- Meeting: Facilitates clear and direct communication among team members.
- Prototyping: Facilitates clear communication of concepts and requirements.
- Refactoring: Well-factored code should be easier to understand.
- Requirements Capture: Helps in explaining exactly what should be built.
- Review: Maintains alignment with design principles and goals.
- Sales: Facilitates direct communication with potential customers to understand their needs.
- Stakeholder Management: Facilitates clear and consistent communication between stakeholders.
- Standardisation: Improves communication by using a common language and standardized terms.
- User Acceptance Testing: Facilitates feedback from end users, improving the final product.
Attendant To Practices
- Automation: The quality and performance characteristics may be obscured by automation.
- Delegation: Requires clear communication to ensure tasks are understood and executed properly.
- Outsourcing: May introduce communication challenges with external teams.
- Stakeholder Management: Misaligned communication strategies can lead to misunderstandings and conflicts.
- Version Control: Poor version management can be chaotic and leave lots of work in progress.
Communication Risk is risk associated with getting messages heard and understood and the transfer of information.
If we all had identical knowledge, there would be no need to do any communicating at all, and therefore no Communication Risk. But people are not all-knowing oracles: we rely on our senses to improve our Internal Models of the world. There is Communication Risk here - we might overlook something vital (like an on-coming truck) or mistake something someone says (like "Don't cut the green wire"). For people, Communication Risk includes:
- Not having the information you need.
- Being presented with the wrong or erroneous information.
- Being "out of the loop" of important updates.
- Not being able to speak the language, or misunderstanding what's being said.
For our software, it includes:
- Issues with connectivity, Accuracy and relevance of information.
- The problem of contradictory versions of information.
- Protocol incompatibilities.
Communication Risk applies equally well as a concept in human scenarios between people, teams, organisations as well as software scenarios such as libraries, services, and data formats.
A Model Of Communication
In 1948, Claude Shannon proposed this definition of communication:
"The fundamental problem of communication is that of reproducing at one point, either exactly or approximately, a message selected at another point." - A Mathematical Theory Of Communication, Claude Shannon
And from this same paper we get the diagram above: we move from top-left ("I want to send a message to someone"), clockwise to bottom left where we hope the message has been understood and believed. (I've added this last box, reconciliation to Shannon's original diagram.)
One of the chief concerns in Shannon's paper is the risk of error between Transmission and Reception. He creates a theory of information (measured in bits), sets the upper-bounds of information that can be communicated over a channel, and describes ways in which Communication Risk between these processes can be mitigated by clever Encoding and Decoding steps.
But it's not just transmission. Communication Risk exists at each of these steps. Let's imagine a human example, where someone, Alice is trying to send a simple message to Bob.
| Step | Potential Issue / Threat |
|---|---|
| Motivation | Alice might be motivated to send a message to tell Bob something, only to find out that he already knew it. |
| Composition | Alice might mess up the intent of the message: instead of "Please buy chips" she might say, "Please buy chops". |
| Encoding | Alice might not speak clearly enough to be understood. |
| Transmission | Alice might not say it loudly enough for Bob to hear. |
| Reception | Bob doesn't hear the message clearly (maybe there is background noise). |
| Decoding | Bob might not decode what was said into a meaningful sentence. |
| Interpretation | Assuming Bob has heard, will he correctly interpret which type of chips (or chops) Alice was talking about? |
| Reconciliation | Does Bob believe the message? Will he reconcile the information into his Internal Model and act on it? Perhaps not, if Bob forgets, or thinks that there are chips at home already. |
Worked Example
You're about to roll out new software in an organisation and you're worried that staff within the organisation won't bother to read the documentation on how to use it. You organise a Demo. However, there is the risk that by doing this you divert staff from hitting the very visible release milestones that have been mandated by senior staff.
Example Threats
Each of the above stages represents a potential threat vector, increasing Communication Risk. (For risks and threats pertaining to the Internal Model itself, see Internal Model Risk.)
1. Channel Threats
Threat: Channel is noisy, containing much that isn't the signal you're after.
Threat: Channel is low-bandwidth and important messages that should be sent and received aren't.
See On Channels
2. Protocol Threats
Threat: The protocol isn't what is expected (e.g. you're understand English but they're speaking French, or you're expecting HTML but get JSON)
Threat: The protocol changes to a new version (e.g. people start using words you don't understand, or the network changes to use IPv6)
See On Protocols
3. Message Threats
Threat: Someone is sending a message with malicious purpose
Threat: The message contains only part of the information you need, leading to the wrong decision.
See On Messages
The 1998 Mars Climate Orbiter software disaster was caused by two teams (Lockheed Martin and NASA) collaborating on building different parts of the orbital insertion control program. The two components needed to communicate with each other but there was a discrepancy: one piece of software was expecting pound-force seconds of thrust, while the other was producing newton seconds - one imperial, one metric measurement. This is a great example of Communication Risk occurring at the protocol level.
During flight, two navigators had spotted discrepancies in the orbital insertion but failed to correctly fill out forms relaying their concerns to the project managers in charge - Communication Risk occurring at the channel level.
The orbiter and lander were both lost at the cost of hundreds of millions of dollars.