diff --git a/docs/practices/Communication-And-Collaboration/Documentation.md b/docs/practices/Communication-And-Collaboration/Documentation.md index 727cab722..82b2d1a3d 100644 --- a/docs/practices/Communication-And-Collaboration/Documentation.md +++ b/docs/practices/Communication-And-Collaboration/Documentation.md @@ -13,8 +13,6 @@ practice: - "Guides" - "Technical Writing" mitigates: - - tag: Invisibility Risk - reason: "Makes all aspects of the project transparent and accessible to the team." - tag: Communication Risk reason: "Provides clear guidelines and information, reducing misunderstandings." - tag: Internal Model Risk diff --git a/docs/practices/Deployment-And-Operations/Automation.md b/docs/practices/Deployment-And-Operations/Automation.md index f32eb7995..94ce524e8 100644 --- a/docs/practices/Deployment-And-Operations/Automation.md +++ b/docs/practices/Deployment-And-Operations/Automation.md @@ -26,7 +26,7 @@ practice: reason: "Introducing automation adds to the complexity of a project" - tag: Feature Fit Risk reason: "The automated process might not capture the variability of requirements of the original approach" - - tag: Invisibility Risk + - tag: Communication Risk reason: "The quality and performance characteristics may be obscured by automation." - tag: Process Risk reason: "Automation introduces a process, which therefore means a new source of Process Risk." diff --git a/docs/practices/Development-And-Coding/Version-Control.md b/docs/practices/Development-And-Coding/Version-Control.md index 0cd5b7342..883d51fcf 100644 --- a/docs/practices/Development-And-Coding/Version-Control.md +++ b/docs/practices/Development-And-Coding/Version-Control.md @@ -20,7 +20,7 @@ practice: - tag: Regression Risk reason: "Maintains a history of changes, allowing rollback to previous versions if needed." attendant: - - tag: Invisibility Risk + - tag: Communication Risk reason: "Poor version management can be chaotic and leave lots of work in progress." related: - ../Planning-and-Management/Change-Management diff --git a/docs/risks/Communication-Risks/On-Channels.md b/docs/risks/Communication-Risks/On-Channels.md index 61a403485..cfc0a8966 100644 --- a/docs/risks/Communication-Risks/On-Channels.md +++ b/docs/risks/Communication-Risks/On-Channels.md @@ -22,7 +22,7 @@ The channel characteristics also imply suitability for certain _kinds_ of messag Shannon discusses that no channel is perfect: there is always the **risk of noise** corrupting the signal. A key outcome from Shannon's paper is that there is a tradeoff: within the capacity of the channel (the **bandwidth**), you can either send lots of information with _higher_ risk that it is wrong, or less information with _lower_ risk of errors. -But channel risk goes wider than just this mathematical example: messages might be delayed or delivered in the wrong order, or not be acknowledged when they do arrive. Sometimes, a channel is just an inappropriate way of communicating. When you work in a different time-zone to someone else on your team, there is _automatic_ [Channel Risk](/tags/Channel-Risk), because instantaneous communication is only available for a few hours a day. +There are practical implications to this: messages might be delayed or delivered in the wrong order, or not be acknowledged when they do arrive. Sometimes, a channel is just an inappropriate way of communicating. When you work in a different time-zone to someone else on your team, there is _automatic_ [Communication Risk](/tags/Communication-Risk), because instantaneous communication is only available for a few hours a day. When channels are **poor-quality**, less communication occurs. People will try to communicate just the most important information. But, it's often impossible to know a-priori what constitutes "important". This is why [Extreme Programming](https://en.wikipedia.org/wiki/Extreme_programming) recommends the practices of [Pair Programming](https://en.wikipedia.org/wiki/Pair_programming) and grouping all the developers together: although you don't know whether useful communication will happen, you are mitigating [Channel Risk](/tags/Channel-Risk) by ensuring high-quality communication channels are in place. @@ -30,9 +30,9 @@ At other times channels are crowded and can contain so much information that we ### Marketing Communications -When we are talking about a product or a brand, mitigating [Channel Risk](/tags/Channel-Risk) is the domain of [Marketing Communications](https://en.wikipedia.org/wiki/Marketing_communications). How do you ensure that the information about your (useful) project makes it to the right people? How do you address the right channels? +When we are talking about a product or a brand, mitigating [Communication Risk](/tags/Communication-Risk) is the domain of [Marketing Communications](https://en.wikipedia.org/wiki/Marketing_communications). How do you ensure that the information about your (useful) project makes it to the right people? How do you address the right channels? -This works both ways. Let's looks at some of the **Channel Risks** from the point of view of a hypothetical software tool, **D**, which my team would find really useful: +This works both ways. Let's looks at some of the **Communication Risks** from the point of view of a hypothetical software tool, **D**, which my team would find really useful: - The concept that there is such a thing as **D** which solves my problem isn't something I'd even considered. - I'd like to use something like **D**, but how do I find it? diff --git a/docs/risks/Communication-Risks/On-Messages.md b/docs/risks/Communication-Risks/On-Messages.md index 8573e700e..f307b1b8a 100644 --- a/docs/risks/Communication-Risks/On-Messages.md +++ b/docs/risks/Communication-Risks/On-Messages.md @@ -43,9 +43,9 @@ For people, nothing exists unless we have a name for it. The world is just atoms People don't rely on rigorous definitions of abstractions like computers do; we make do with fuzzy definitions of concepts and ideas. We rely on [Abstraction](/tags/Abstraction) to move between the name of a thing and the _idea of a thing_. -This brings about [Misinterpretation](/risks/Message-Risk#misinterpretation): names are not _precise_, and concepts mean different things to different people. We can't be sure that other people have the same meaning for a name that we have. +This brings about [Misinterpretation](#2-misinterpretation): names are not _precise_, and concepts mean different things to different people. We can't be sure that other people have the same meaning for a name that we have. -Another cost of [Abstraction](/tags/Abstraction) is [Invisibility Risk](/tags/Invisibility-Risk). While abstraction is a massively powerful technique, it lets the function of a thing hide behind the layers of abstraction and become invisible. +So one cost of [Abstraction](/tags/Abstraction) is [Communication Risk](/tags/Communication-Risk). While abstraction is a massively powerful technique, it lets the function of a thing hide behind the layers of abstraction and become invisible. As we saw above, [Protocols](/risks/On-Protocols) allow things like the Internet to happen - this is amazing! But the higher level protocols _hide_ the details of the lower ones. HTTP _didn't know anything about_ IP packets, for example. diff --git a/docs/risks/Dependency-Risks/Process-Risk/On-Bureaucracy.md b/docs/risks/Dependency-Risks/Process-Risk/On-Bureaucracy.md index 6faa846db..0104fadd4 100644 --- a/docs/risks/Dependency-Risks/Process-Risk/On-Bureaucracy.md +++ b/docs/risks/Dependency-Risks/Process-Risk/On-Bureaucracy.md @@ -30,7 +30,7 @@ Next in the tour of [Dependency Risks](/tags/Dependency-Risk), it's time to look -s And Invisibility Risk +## Processes And Communication Risk Processes tend to work well for the common cases because *practice makes perfect*, but they are really tested when unusual situations occur. Expanding processes to deal with edge-cases incurs [Complexity Risk](/tags/Complexity-Risk), so often it's better to try and have clear boundaries of what is "in" and "out" of the process' domain. @@ -82,7 +82,7 @@ Let's look at an example of how that can happen in a step-wise way. 3. Problems are likely to occur eventually in the `B`/`C` relationship. Perhaps some members of the `B` team give better service than others, or deal with more variety in requests? In order to standardise the response from `B` and also to reduce scope-creep in requests from `C`, `B` organises bureaucratically so that there is a controlled process (`P`) by which `A` can be accessed. Members of teams `B` and `C` now interact via some request mechanism like forms (or another protocol). - As shown in the above diagram, because of `P`, `B` can now process requests on a first-come-first-served basis and deal with them all in the same way: the more unusual requests from `C` might not fit the model. These [Process Risks](/tags/Process-Risk) are now the problem of the form-filler in `C`. - - Since this is [Abstraction](/tags/Abstraction), `C` now has [Invisibility Risk](/tags/Invisibility-Risk) since it can't access team `B` and see how it works. + - Since this is [Abstraction](/tags/Abstraction), `C` now has [Communication Risk](/tags/Communication-Risk) since it can't access team `B` and see how it works. - Team `B` may also use `P` to introduce other bureaucracy like authorisation and sign-off steps or payment barriers. All of this increases [Process Risk](/tags/Process-Risk) for team C. ![Person D acts as a middleman for customers needing some variant of `A`, transferring Complexity Risk](/img/generated/risks/process/step4.svg)