Dependency Risk -> Risks

docs/estimating/Interference-Checklist.md

@@ -120,7 +120,7 @@ Download this in [PDF](/estimating/Interference-Checklist.pdf) or [Numbers](/est
 |                                                         | Involves payments                                                                 |           |                 |
 |                                                         | Involves security infrastructure: firewalls, proxies, VPN etc.                    |           |                 |
 |                                                         |                                                                                   |           |                 |
-| **[Dependency Risks](/tags/Dependency-Risk)**           |                                                                                   |           |                 |
+| **[Dependency Risks](/tags/Dependency-Risks)**           |                                                                                   |           |                 |
 |                                                         | Requires the introduction of a new dependency                                     |           |                 |
 |                                                         | … which is immature                                                               |           |                 |
 |                                                         | … which must be chosen from competing alternatives                                |           |                 |

docs/practices/Deployment-And-Operations/Monitoring.md

@@ -24,7 +24,7 @@ practice:
   attendant:
    - tag: Complexity Risk
      reason: "Implementing comprehensive monitoring solutions can add complexity."
-   - tag: Software Dependency Risk
+   - tag: Reliability Risk
      reason: "Creates dependency on monitoring tools and their accuracy."
    - tag: Funding Risk
      reason: "High-quality monitoring tools and systems can be costly."

docs/practices/Development-And-Coding/Library-Adoption.md

@@ -22,7 +22,7 @@ practice:
    - tag: Complexity Risk
      reason: "Can reduce the amount of code you are responsible for, hence the amount of 'owned' complexity."
   attendant:
-   - tag: Software Dependency Risk
+   - tag: Feature Fit Risk
      reason: "Creates dependencies on the adopted standards and libraries."
    - tag: Lock-In Risk
      reason: "Adopting proprietary libraries may lead to worsening terms-of-service in the future."

docs/practices/Development-And-Coding/Tool-Adoption.md

@@ -20,7 +20,7 @@ practice:
    - tag: Operational Risk
      reason: "Enhances operational efficiency through the use of appropriate tools."
   attendant:
-   - tag: Software Dependency Risk
+   - tag: Lock-In Risk
      reason: "Creates dependencies on specific tools and their continued support."
    - tag: Funding Risk
      reason: "Can incur costs associated with acquiring and maintaining tools."

docs/practices/Planning-And-Management/Design.md

@@ -26,7 +26,7 @@ practice:
   attendant:
    - tag: Lock-In Risk
      reason: "Design decisions can create boundaries that limit flexibility and adaptability."
-   - tag: Software Dependency Risk
+   - tag: Reliability Risk
      reason: "Creates dependencies on software components and design patterns."
    - tag: Feature Fit Risk
      reason: "Too much design up-front can create problems meeting feature requirements."

docs/practices/Planning-And-Management/Prioritising.md

@@ -71,7 +71,7 @@ There are several ways you can prioritise work:
 
 - **Largest Mitigation First**:  What's the thing we can do right now to reduce our [Attendant Risk](/tags/Attendant-Risk) most?  This is sometimes hard to quantify, given [Hidden Risk](/tags/Hidden-Risk), so maybe an easier metric is...
 - **Biggest Win**:  What's the best thing we can do right now to reduce [Attendant Risk](/tags/Attendant-Risk) for least additional [Schedule-Risk](/tags/Schedule-Risk)?  (i.e. simply considering how much *work* is likely to be involved)
-- **Dependency Order**:  Sometimes, you can't build Feature A until Feature B is complete.   Prioritisation helps to identify and mitigate [Dependency Risk](/tags/Dependency-Risk).
+- **Dependency Order**:  Sometimes, you can't build Feature A until Feature B is complete.   Prioritisation helps to identify and mitigate [Dependency Risks](/tags/Dependency-Risks).
 
 By prioritising, you get to [Meet Reality](/thinking/Meeting-Reality) _sooner_ and _more frequently_ and in _small chunks_.
 

docs/practices/Testing-and-Quality-Assurance/Automated-Testing.md

@@ -23,7 +23,7 @@ practice:
      reason: "Writing and maintaining unit tests can be time-consuming."
    - tag: Complexity Risk
      reason: "Managing a large suite of unit tests can add to the complexity."
-   - tag: Software Dependency Risk
+   - tag: Reliability Risk
      reason: "Creates dependencies on testing frameworks and tools."
    - tag: Internal Model Risk
      reason: "Unit Testing and code coverage can give false assurances about how a system will work in the real world."

docs/practices/Testing-and-Quality-Assurance/Integration-Testing.md

@@ -13,7 +13,7 @@ practice:
    - "End-to-End Testing"
    - "Continuous Integration"
   mitigates:
-   - tag: Software Dependency Risk
+   - tag: Reliability Risk
      reason: "Ensures that integrated components work together as expected."
    - tag: Implementation Risk
      reason: "Validates that the implementation meets requirements."
@@ -22,7 +22,7 @@ practice:
   attendant:
    - tag: Schedule Risk
      reason: "Can be time-consuming, leading to delays in the project timeline."
-   - tag: Software Dependency Risk
+   - tag: Reliability Risk
      reason: "Adds dependencies on test environments and their availability."
   related:
    - ../Planning-and-Management/Change-Management

docs/practices/Testing-and-Quality-Assurance/Measurement.md

@@ -22,7 +22,7 @@ practice:
   attendant:
    - tag: Funding Risk
      reason: "Implementing measurement systems can be expensive."
-   - tag: Software Dependency Risk
+   - tag: Reliability Risk
      reason: "Creates dependencies on measurement tools and their accuracy."
    - tag: Complexity Risk
      reason: "Collecting and analyzing data can add to the complexity of the project."

docs/practices/Testing-and-Quality-Assurance/Regression-Testing.md

@@ -20,7 +20,7 @@ practice:
   attendant:
    - tag: Schedule Risk
      reason: "Can be time-consuming and introduce delays."
-   - tag: Software Dependency Risk
+   - tag: Reliability Risk
      reason: "Requires a stable testing environment, creating dependencies."
    - tag: Complexity Risk
      reason: "Managing extensive regression tests can add complexity."

docs/presentations/AllWorkIsRiskManagement/index.md

@@ -389,7 +389,7 @@ hide_table_of_contents: true
             <div class="slide-notes">
                       <p>Now, at this point, you might be thinking - how many of these risks are there?  tvtropes has literally thousands of different tropes recorded.  Is it the same for Software Projects?  </p>
 
-      <p>Luckily, the answer is no.  On the Risk-First website I just break it down into about 50, and some of those are just more specific versions of others.  There are many different types of Dependency Risk - such as Staff Risk, and Software Dependency Risk.</p>
+      <p>Luckily, the answer is no.  On the Risk-First website I just break it down into about 50, and some of those are just more specific versions of others.  There are many different types of Dependency Risk - such as Agency Risk, and Reliability Risk.</p>
 
       <p>I run through these on the website but we’re not going to go into detail today.   </p>
 

docs/presentations/HowToWin/index.md

@@ -328,7 +328,7 @@ hide_table_of_contents: true
 
       <p>Just like in the horse racing, or the roulette example, what we want are bets where payoff is worth what you stake.  </p>
 
-      <p>So, you might say: a bet on OAuth2 adds the software dependency risk, but at least it doesn’t tie up one developer for a month, pushing up my schedule risk.  Things could go south, but this might be the safest bet out of the ones available.</p>
+      <p>So, you might say: a bet on OAuth2 adds a dependency risk, but at least it doesn’t tie up one developer for a month, pushing up my schedule risk.  Things could go south, but this might be the safest bet out of the ones available.</p>
 
 
             </div>

docs/risks/Communication-Risks/On-Messages.md

@@ -17,7 +17,7 @@ When we construct messages in a conversation, we have to make judgements about w
 
 This is called [Theory Of Mind](https://en.wikipedia.org/wiki/Theory_of_mind): the appreciation that your knowledge is different to other peoples', and adjusting you messages accordingly.  When teaching, this is called [The Curse Of Knowledge](https://en.wikipedia.org/wiki/Curse_of_knowledge):  teachers have difficulty understanding students' problems _because they already understand the subject_.  
 
-A second, related problem is actually [Dependency Risk](/tags/Dependency-Risk), which is covered more thoroughly in a later section.  Often, to understand a new message, you have to have followed everything up to that point already.
+A second, related problem is actually [Dependency Risk](/tags/Dependency-Risks), which is covered more thoroughly in a later section.  Often, to understand a new message, you have to have followed everything up to that point already.
 
 The same **Message Dependency Risk** exists for computer software:  if there is replication going on between instances of an application and one of the instances misses some messages, you end up with a "[Split Brain](https://en.wikipedia.org/wiki/Split-brain_(computing))" scenario, where later messages can't be processed because they refer to an application state that doesn't exist.  For example, a message saying:
 

docs/risks/Complexity-Risk/Complexity-Risk.md

@@ -79,9 +79,9 @@ Although modern languages include plenty of concurrency primitives (such as the
 
 **Threat**: [Race conditions](https://en.wikipedia.org/wiki/Race_condition) and [Deadlocks](https://en.wikipedia.org/wiki/Deadlock) abound in over-complicated concurrency designs:  complexity issues are magnified by concurrency concerns, and are also hard to test and debug.  
 
-Recently, languages such as [Clojure](https://clojure.org) have introduced [persistent collections](https://en.wikipedia.org/wiki/Persistent_data_structure) to alleviate concurrency issues.  The basic premise is that any time you want to _change_ the contents of a collection, you get given back a _new collection_.  So, any collection instance is immutable once created.  The trade-off is again speed to mitigate [Complexity Risk](/tags/Complexity-Risk).  
+Languages such as [Clojure](https://clojure.org) introduce [persistent collections](https://en.wikipedia.org/wiki/Persistent_data_structure) to alleviate concurrency issues.  The basic premise is that any time you want to _change_ the contents of a collection, you get given back a _new collection_.  So, any collection instance is immutable once created.  The trade-off is again speed to mitigate [Complexity Risk](/tags/Complexity-Risk).  
 
-An important lesson here is that choice of language can reduce complexity: and we'll come back to this in [Software Dependency Risk](/tags/Software-Dependency-Risk).
+An important lesson here is that choice of language can reduce complexity: and we'll come back to this in [Software Dependency Risk](/risks/Software-Dependency-Risk).
 
 ### 5. Networking / Security
 
@@ -93,7 +93,7 @@ There are plenty of [Complexity Risk](/tags/Complexity-Risk) perils in _anything
 
 Luckily, most good languages include cryptographic libraries that you can include to mitigate these [Complexity Risks](/tags/Complexity-Risk) from your own code-base.  
 
-This is a strong argument for the use of libraries.  But when should you use a library and when should you code-your-own?  This is covered further in the section on [Software Dependency Risk](/tags/Software-Dependency-Risk).  
+This is a strong argument for the use of libraries.  But when should you use a library and when should you code-your-own?  This is covered further in the section on [Software Dependency Risk](/risks/Software-Dependency-Risk).  
 
 ### 6.  The Pursuit Of Perfection
 

docs/risks/Complexity-Risk/Hiding-Places.md

@@ -22,4 +22,4 @@ The complexity of software tends to reflect the complexity of the environment it
 
 In particular, when we talk about the environment, we are talking about the number of external dependencies that the software has, and the risks we face when relying on those dependencies.  
 
-So the next stop in the tour is a closer look at [Dependency Risk](/tags/Dependency-Risk).
+So the next stop in the tour is a closer look at [Dependency Risks](/tags/Dependency-Risks).

docs/risks/Coordination-Risk/A-Model-Of-Coordination-Risk.md

@@ -5,7 +5,7 @@ sidebar_position: 1
 
 ## A Model Of Coordination Risk
 
-Earlier, in [Dependency Risk](/tags/Dependency-Risk), we looked at various resources (time, money, people, events etc) and showed how we could [depend on them](/tags/Dependency-Risk) taking on risk.<!-- tweet-end -->  Here, let's consider the situation where there is _competition for those dependencies_ due to [Scarcity Risk]((/tags/Scarcity-Risk):   other agents want to use them in a different way.  
+Earlier, when looking at [Dependency Risks](/tags/Dependency-Risks), we looked at various resources (time, money, people, events etc) and showed how we could [depend on them](/tags/Dependency-Risks) taking on risk.  Here, let's consider the situation where there is _competition for those dependencies_ due to [Scarcity Risk]((/tags/Scarcity-Risk):   other agents want to use them in a different way.  
 
 ### Law Of Diminishing Returns
 

docs/risks/Dependency-Risks/Agency-Risk/Agency-Risk.md

@@ -17,7 +17,7 @@ featured:
   element: '<risk class="agency" />'
 sidebar_position: 12
 tweet: yes
-part_of: Dependency Risk
+part_of: Dependency Risks
 ---
 
 <RiskIntro fm={frontMatter} />

docs/risks/Dependency-Risks/Deadline-Risk/Deadline-Risk.md

@@ -11,7 +11,7 @@ tags:
  - Deadline Risk
  - Risks
 tweet: yes
-part_of: Dependency Risk
+part_of: Dependency Risks
 ---
 
 <RiskIntro fm={frontMatter} />
@@ -56,7 +56,7 @@ The data processing team needs a new account report to be ready at the start of
  - [Schedule Risk](/tags/Schedule-Risk) is _continuous_, like money.  i.e. you want to waste as little of it as possible.  Every extra day you take compounds [Schedule Risk](/tags/Schedule-Risk) additively. A day wasted at the start of the project is much the same as a day wasted at the end.
  - [Deadline Risk](/tags/Deadline-Risk) is _binary_.  The impact of [Deadline Risk](/tags/Deadline-Risk) is either zero (you make it in time) or one (you are late and miss the flight).  You don't particularly get a reward for being early.
 
-So, these are two separate concepts, both useful in software development and other fields.   Next up, something more specific: [Software Dependency Risk](/tags/Software-Dependency-Risk).
+So, these are two separate concepts, both useful in software development and other fields.   Next up, something more specific: [Software Dependency Risk](/risks/Software-Dependency-Risk).
 
 ## Example Threats
 

docs/risks/Dependency-Risks/Dependency-Risks.md

@@ -7,30 +7,20 @@ featured:
   element: '<risk class="dependency" />'
 sidebar_position: 6
 tags:
- - Dependency Risk
+ - Dependency Risks
 tweet: yes
 slug: /risks/Dependency-Risks
 part_of: Operational Risk
 ---
 
 # Dependency Risks
 
-[Dependency Risk](/tags/Dependency-Risk) is the risk you take on whenever you have a dependency on something (or someone) else.   <!-- tweet-end -->
+[Dependency Risks](/tags/Dependency-Risk) are risks you take on whenever you have a dependency on something (or someone) else.  
 
 One simple example could be that the software service you write might depend on hardware to run on:  if the server goes down, the service goes down too.  In turn, the server depends on electricity from a supplier, as well as a network connection from a provider.  If either of these dependencies aren't met, the service is out of commission.
 
 Dependencies can be on _events_, _people_, _teams_, _work_, _processes_, _software_, _services_, _money_ and pretty much _any resource_, and while every project will need some of these, they also _add risk_ to any project because the reliability of the project itself is now a function involving the reliability of the dependency.  
 
-In order to avoid repetition, and also to break down this large topic, we're going to look at this over 7 sections:   
-
- - This first section will look at dependencies _in general_, and some of the variations of [Dependency Risk](/tags/Dependency-Risk).
- - Next, we'll look at [Scarcity Risk](/tags/Scarcity-Risk), because time, money and staff are scarce resources in every project.
- - We'll cover [Deadline Risk](/tags/Deadline-Risk), and discuss the purpose of Events and Deadlines, and how they enable us to coordinate around dependency use.
- - Then, we'll move on to look specifically at [Software Dependency Risk](/tags/Software-Dependency-Risk), covering using libraries, software services and building on top of the work of others.
- - Then, we'll take a look at [Process Risk](/tags/Process-Risk), which is still [Dependency Risk](/tags/Dependency-Risk), but we'll be considering more organisational factors and how bureaucracy comes into the picture.
- - After that, we'll take a closer look at [Lock-In Risk](/tags/Lock-In-Risk) and [Dead-End Risk](/tags/Dead-End-Risk).  These are the risks you face in making choices about what to depend on.
- - Finally, we'll wrap up this analysis with a look at some of the specific problems around depending on other people or businesses in [Agency Risk](/tags/Agency-Risk).
-
 ## Why Have Dependencies?
 
 Luckily for us, the things we depend on in life are, for the most part, abundant:  water to drink, air to breathe, light, heat and most of the time, food for energy.  
@@ -50,7 +40,9 @@ So, dependencies are a trade-off.  They give with one hand and take with the oth
 
 ## Types Of Dependency Risk
 
-<TagList tag="Dependency Risk"  /> 
+In order to avoid repetition, and also to break down this large topic, we're going to look break this down into some specific sub-types (shown below).
+
+<TagList tag="Dependency Risks"  /> 
 
 
 

docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md

@@ -13,7 +13,7 @@ tweet: yes
 tags: 
  - Risks
  - Funding Risk
-part_of: Scarcity Risk
+part_of: Dependency Risks
 ---
 
 <RiskIntro fm={frontMatter} />

docs/risks/Dependency-Risks/Lock-In-Risk/Lock-In-Risk.md

@@ -11,7 +11,7 @@ tags:
  - Risks
  - Lock-In Risk
 tweet: yes
-part_of: Dependency Risk
+part_of: Dependency Risks
 ---
 
 <RiskIntro fm={frontMatter} />

docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md

@@ -11,7 +11,7 @@ tweet: yes
 tags: 
  - Risks
  - Process Risk
-part_of: Dependency Risk
+part_of: Dependency Risks
 ---
 
 <RiskIntro fm={frontMatter} />

docs/risks/Dependency-Risks/Reliability-Risk/Reliability-Risk.md

@@ -11,7 +11,7 @@ tags:
  - Reliability Risk
  - Risks
 tweet: yes
-part_of: Dependency Risk
+part_of: Dependency Risks
 ---
 
 <RiskIntro fm={frontMatter} />

docs/risks/Dependency-Risks/Schedule-Risk/Schedule-Risk.md

@@ -13,7 +13,7 @@ tags:
  - Risks
  - Funding Risk
  - Schedule Risk
-part_of: Dependency Risk
+part_of: Dependency Risks
 ---
 
 <RiskIntro fm={frontMatter} />

docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md

@@ -48,7 +48,7 @@ As we saw in [Map and Territory Risk](/tags/Map-And-Territory-Risk), it's very e
 
 There are plenty of [Hidden Risks](/tags/Hidden-Risk) within the operation's environment. These change all the time in response to economic, legal or political change.  In order to manage a risk, you have to uncover it, so part of [Operations Management](#operations-management) is to look for trouble.
 
-- **Environmental Scanning** is all about trying to determine which changes in the environment are going to impact your operation.   Here we are trying to determine the level of [Dependency Risk](/tags/Dependency-Risk) we face for external dependencies, such as suppliers, customers, markets and regulation.  Tools like [PEST](https://en.wikipedia.org/wiki/PEST_analysis) are relevant, as is 
+- **Environmental Scanning** is all about trying to determine which changes in the environment are going to impact your operation.   Here we are trying to determine the level of [Dependency Risk](/tags/Dependency-Risks) we face for external dependencies, such as suppliers, customers, markets and regulation.  Tools like [PEST](https://en.wikipedia.org/wiki/PEST_analysis) are relevant, as is 
 - **[Penetration Testing](https://en.wikipedia.org/wiki/Penetration_test)**: looking for security weaknesses within the operation.  See [OWASP](https://en.wikipedia.org/wiki/OWASP) for examples.
 - **[Vulnerability Management](https://en.wikipedia.org/wiki/Vulnerability_management)** is about keeping up-to-date with vulnerabilities in [Software Dependencies](/tags/Software-Dependency-Risk).