Added market risk

dictionary.txt

@@ -352,3 +352,4 @@ wrongdoing
 demystify
 dysfunctional
 outlier
+ousted

docs/practices/Communication-And-Collaboration/Demo.md

@@ -21,6 +21,8 @@ practice:
      reason: "Facilitates clear communication of the product's features and benefits to stakeholders."
    - tag: Learning Curve Risk
      reason: "Prototypes are a way of learning about a particular solution to a problem."
+   - tag: Implementation Risk
+     reason: "Demonstrations often highlight issues in implementations"   
   attendant:
    - tag: Schedule Risk
      reason: "Demos can introduce delays if not planned and executed properly."

docs/practices/Communication-And-Collaboration/Documentation.md

@@ -24,8 +24,6 @@ practice:
      reason: "Creating and maintaining documentation can be time-consuming."
    - tag: Complexity Risk
      reason: "Extensive documentation can sometimes add to complexity rather than simplifying it."
-   - tag: Implementation Risk
-     reason: "Poorly documentation can lead to implementation issues in development."
   related:
    - ../Planning-and-Management/Requirements-Capture
    - ../Development-and-Coding/Code-Reviews

docs/practices/Communication-And-Collaboration/Review.md

@@ -29,8 +29,6 @@ practice:
      reason: "Reviews can introduce delays in the project timeline."
    - tag: Coordination Risk
      reason: "Requires effective coordination among team members."
-   - tag: Implementation Risk
-     reason: "Can lead to conflicts over quality and implementation details."
   related:
    - ../Deployment-And-Operations/Monitoring
    - Retrospective

docs/practices/Development-And-Coding/Standardisation.md

@@ -16,16 +16,16 @@ practice:
    - "Re-Use"
   mitigates:
    - tag: Feature Fit Risk
-     reason: "Ensures that the features conform to predefined standards, reducing variability."
+     reason: "Ensures that the features conform to predefined standards, reducing variability and potentially widening accessibility."
    - tag: Operational Risk
      reason: "Reduces operational errors by providing clear guidelines and protocols."
    - tag: Communication Risk
      reason: "Improves communication by using a common language and standardized terms."
   attendant:
    - tag: Inflexibility Risk
      reason: "May limit creativity and flexibility by enforcing strict adherence to standards."
-   - tag: Implementation Risk
-     reason: "Can introduce complexity and delays during the implementation phase."
+   - tag: Schedule Risk
+     reason: "Adhering to standards can introduce scope creep during the implementation phase."
    - tag: Compliance Risk
      reason: "Ensuring continuous compliance with evolving standards can be challenging."
   related:

docs/practices/External-Relations/Outsourcing.md

@@ -26,6 +26,8 @@ practice:
      reason: "May introduce communication challenges with external teams."
    - tag: Security Risk
      reason: "Potential risks related to data security and confidentiality."
+   - tag: Market Risk
+     reason: "Increasing the size of the supply chain introduces risks that the state of that supply chain changes with the market."
   related:
    - ../Planning-and-Management/Contract
    - ../Communication-and-Collaboration/Stakeholder-Management

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

@@ -13,20 +13,25 @@ practice:
    - "Software Architecture"
    - "Design Patterns"
    - "Architecture"
+   - "Research and Design"
   mitigates:
    - tag: Conceptual Integrity Risk
      reason: "Provides a clear structure and organization, making the system easier to understand and use."
    - tag: Implementation Risk
      reason: "Guides the development process, ensuring that the system meets requirements and design specifications."
    - tag: Operational Risk
      reason: "Ensures that the system architecture supports operational requirements and scalability."
+   - tag: Market Risk
+     reason:  (Research and) design allows you to leapfrog competitors and provide new sources of value.   
   attendant:
    - tag: Boundary Risk
      reason: "Design decisions can create boundaries that limit flexibility and adaptability."
    - tag: Software Dependency 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."
+   - tag: Funding Risk
+     reason: "Design can be an expensive bet that doesn't lead to improved software." 
   related:
    - ../Planning-and-Management/Requirements-Capture
    - ../Development-and-Coding/Coding

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

@@ -24,6 +24,8 @@ practice:
   attendant:
    - tag: Scarcity Risk
      reason: "Prioritization can create dependencies on specific tasks or features."
+   - tag: Market Risk
+     reason: "Prioritising a single client or narrowing scope reduces diversification, increasing exposure to changes in the market." 
   related:
    - ../Planning-and-Management/Requirements-Capture
    - ../Communication-and-Collaboration/Retrospectives

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

@@ -18,7 +18,7 @@ practice:
    - tag: Coordination Risk
      reason: "Allows stakeholders to coordinate on their work and demands."
    - tag: Communication Risk
-     reason: "Facilitates clear and consistent communication between stakeholders."
+     reason: "Facilitates clear and consistent communication between stakeholders."    
   attendant:
    - tag: Coordination Risk
      reason: "Requires effective coordination among all stakeholders, which can be challenging."

docs/risks/Feature-Risks/Feature-Fit-Risk.md

@@ -42,4 +42,20 @@ In the above diagram, we can see Feature Fit Risk being addressed by [Analysis](
 
 ### 4. Evolving Requirements
 
-**Threat:** Not reassessing the design when new requirements emerge can lead to delivering features that no longer align with the client’s current needs.
+**Threat:** Not reassessing the design when new requirements emerge can lead to delivering features that no longer align with the client’s current needs.
+
+### 5. Accessibility Concerns
+
+**Threat**: It's easy to ignore edge cases around _types of user_, failing to consider the full breadth of platforms the software will need to run on, ease-of-use, visual accessibility, auditory accessibility and cognitive accessibility. 
+
+### 6.  Over-Complication
+
+**Threat**: In an effort to provide as much as many features as possible, software can become over-complicated and hard to use.  Trying to mitigate [Feature Fit Risk](/tags/Feature-Fit-Risk) can lead to [Complexity Risk](/tags/Complexity-RisK).
+
+:::tip Anecdote Corner
+
+The excessive menu-diving in [Feature Phones](https://en.wikipedia.org/wiki/Feature_phone) of the late 1990s are an example of trying to account for too much [Feature Risk](/tags/Feature-Fit-Risk):  although it _seemed_ like the market wanted more and more features added to their phones, [Apple's iPhone](https://en.wikipedia.org/wiki/IPhone) was able to steal huge market share by presenting a much more enjoyable, coherent user experience, despite being more expensive and initially having _far fewer_ features.   
+
+Feature Phones had been drowning in increasing numbers of box-ticking features while ignoring the feature that users really wanted:  a clear, responsive user interface and ease-of-use.
+
+:::

docs/risks/Feature-Risks/Feature-Risk.md

@@ -1,6 +1,6 @@
 ---
 title: Feature Risk
-description: Risk you face when providing features for your clients.
+description: Risks you face when providing features for your clients.
 
 
 featured: 
@@ -32,3 +32,4 @@ Not considering [Feature Risk](/tags/Feature-Risk) means that you might be build
 
 <TagList tag="Feature Risk" filter="risks/Feature-Risks" /> 
 
+

docs/risks/Feature-Risks/Implementation-Risk.md

@@ -1,6 +1,6 @@
 ---
 title: Implementation Risk
-description: Risk that the functionality you are providing doesn't match the features the client is expecting, due to poor or partial implementation.
+description: Risk that the functionality you are providing doesn't correctly implement the perceived solution you are trying to build for your clients.
 featured: 
   class: ff
   element: '<risk class="implementation" />'
@@ -13,6 +13,42 @@ part_of: Feature Risk
 
 <RiskIntro fm={frontMatter} />
 
-The [Feature Risk](/tags/Feature-Risk) family also includes things that don't work as expected, that is to say, [bugs](https://en.wikipedia.org/wiki/Software_bug).   Although the distinction between "a missing feature" and "a broken feature" might be worth making in the development team, we can consider these both the same kind of risk:  _the software doesn't do what the user expects_.  We call these [Implementation Risks](/tags/Implementation-Risk).  
+[Implementation Risk](/tags/Implementation-Risk) exists in the gap between _what you are trying to build_ and _what you actually build_.  That is, the difference between your software in theory and in practice.  It includes things that don't work as expected, that is to say, [bugs](https://en.wikipedia.org/wiki/Software_bug) and missing features.  A good way of looking at this might be to consider it the sum of all the development items you have on your to-do list.    
 
-It's worth pointing out that sometimes, _the user expects the wrong thing_.  This is a different but related risk, which could be down to [training](/tags/Training), [documentation](/tags/Documentation) or simply a [poor user interface](/tags/Communication-Risk) (and we'll look at that more in [Communication Risk](/tags/Communication-Risk).)
+## Worked Example
+
+![Reducing Implementation Risk Via Automated Testing](/img/generated/risks/posters/implementation-risk.svg) 
+
+In the above diagram, we can see [Implementation Risks](/tags/Implementation-Risk) being addressed by [Automated Testing](../../practices/Testing-And-Quality-Assurance/Automated-Testing) - building out a series of examples and running them to make sure the software behaves as expected.  The downsides of this may include the extra [complexity](/tags/Complexity-Risk) in the project and the [impact to the schedule](/tags/Schedule-Risk) of building the tests. 
+
+As you can see from the table at the top, many of the practices we adopt in software development have been designed for the purpose of tackling [Implementation Risks](/tags/Implementation-Risk), but incur their own overheads in terms of effort and time.  
+
+## Example Threats
+
+### 1. Incorrect Assumptions about Inputs
+
+**Threat**: it's easy to assume that the most common form of input represents the entire class, only for unusual or obscure or unusual input cases to reveal themselves as implementation issues. 
+
+### 2. Leaky Abstractions
+
+**Threat**: In a similar way, abstractions that make sense in the design phase can often fail to usefully model real-world concerns. 
+
+### 3. Not Working As Advertised
+
+**Threat**: A lot of programming languages and libraries purport to giving you a certain piece of functionality which you come to rely on or expect in your own code.  However it later transpires that they don't completely meet your expectations.  Your work has been built on top of faulty assumptions.
+
+### 4. Unfamiliar Domain
+
+**Threat**: If you or your team are using new tools, working in a new domain or making use of unfamiliar algorithms or libraries you should expect elevated levels of implementation risk while you build your [Internal Model](/tags/Internal-Model) of that domain.
+
+### 5. "Hard" Domains
+
+**Threat**:  Implementation risks are more prevalent in certain areas of computing, such as concurrency, memory management, security, algorithms with complex time/space tradeoffs and so on.  See [Complexity Risk](/tags/Complexity-Risk) and [Security Risk](/tags/Security-Risk).
+
+:::tip Anecdote Corner
+
+Implementation Risks lead to bugs and disappointed clients, but often the results are more serious.  The original wireless (WiFi) network protocol, [IEEE 802.11](https://en.wikipedia.org/wiki/IEEE_802.11) from 1997 was supposed to offer security via [WEP - Wired Equivalent Privacy](https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy).  However, there were severe design flaws in the algorithm and in the early 2000's it was proven to be completely insecure to the point that you could fairly trivially recover a WEP pass-key just by snooping the encrypted network.  
+
+Having security experts [review](/tags/Review) the standard would have helped, however there is also legal context around this that the US had export restrictions around cryptography at the time which would have hampered strong wireless security anyway.
+
+:::

docs/risks/Feature-Risks/Market-Risk.md

@@ -13,8 +13,6 @@ part_of: Feature Risk
 
 <RiskIntro fm={frontMatter} />
 
-![Market Risk](/img/generated/risks/feature/market-risk.svg) 
-
 Market Risk is a term from finance:
 
  > "Market risk is the risk of losses in positions arising from movements in market prices." - [Market Risk, _Wikipedia_](https://en.wikipedia.org/wiki/Market_risk)
@@ -23,6 +21,43 @@ I face market risk when I own (i.e. have a _position_ in) some [Apple](https://a
 
 This risk applies equally well when building a software product, as the software you're building is effectively your stock and its value is whatever the market places on it (i.e. what people are willing to pay).
 
-Even projects that are internal to a company are not immune:  they still need to have a value to the company and therefore suffer Market Risk.
+Even projects that are internal to a company are not immune:  they still need to have a value to the company and therefore suffer Market Risk.  If you have multiple internal customers for your software or a single highly important internal customer, you will be less exposed to internal market risk.
 
 Since the _market_ decides what it is prepared to pay, Market Risk tends to be outside your control.  Although, as shown in the diagram, you can use tools like **marketing** to try and engage with your market and get them to see the value in what you are doing. 
+
+## Worked Example
+
+![Market Risk](/img/generated/risks/posters/market-risk.svg) 
+
+In the above diagram, a successful Software-as-a-Service (SaaS) company has found a niche with some high-value clients.  While this means they don't suffer [Funding Risk](/tags/Funding-Risk), they are susceptible to the whims of those clients.  In order to reduce the [Market Risk](/tags/Market-Risk), they decide to engage a marketing company to help them find new clients to work with, potentially in an adjacent domain.   
+
+The wider client base reduces the life-threatening impact of one of the original clients leaving, but these new clients require additional functionality in the software, increasing it's complexity and absorbing more of the development budget.
+
+## Example Threats
+
+### 1. Technological Disruption
+
+**Threat**:  A competitor releases a product that eats into your share of the market, or creates some innovation that renders your product obsolete. 
+
+### 2. Changing Market Fundamentals
+
+**Threat**: Factors such as interest rates, inflation rates and exchange rates may all affect the financial health of your software.
+
+### 3. Not Listening To The Market
+
+**Threat**: It's easy to ignore the wider market moves and hope that they are background noise. Not paying attention to how (potential) customers are behaving in the market may lead to surprise.
+
+### 4.  Financial Leverage
+
+**Threat**: Taking on too much debt (i.e. borrowing too much) increases market risk as creditors expect to be paid irrespective of market conditions.  
+
+### 5.  Ignoring 
+
+:::tip Anecdote Corner
+
+While not a traditional software company, [WeWork](https://en.wikipedia.org/wiki/WeWork) (a provider of co-working spaces) nevertheless branded itself as one and was able to borrow heavily against its "tech" image.  They relied on high levels of debt for rapid expansion which raised eyebrows at the time it filed for IPO in 2019. 
+
+However, in 2020, the COVID-19 pandemic hit and led to a massive shift to remote work, leading to the CEO, Adam Neumannm, being ousted for poor financial discipline.  The [New York Times](https://web.archive.org/web/20191102160054/https://www.nytimes.com/2019/11/02/business/adam-neumann-wework-exit-package.html) called this "an implosion unlike any other in the history of start-ups".
+
+
+:::

src/images/generated/risks/posters/implementation-risk.adl

@@ -0,0 +1,24 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<diagram xmlns="http://www.kite9.org/schema/adl"
+         xmlns:svg="http://www.w3.org/2000/svg"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xmlns:xslt="http://www.kite9.org/schema/xslt"
+         id="diagram-113"
+         xslt:template="/public/templates/risk-first/risk-first-template.xsl">
+   <container bordered="true" id="c" style="--kite9-layout: down; ">
+      <risk class="implementation"/>
+      <label id="id_16">
+      The new search function doesn't 
+      return search results when 
+      multiple terms are entered.
+    </label>
+   </container>
+   <group style="--kite9-layout: down; --kite9-horizontal-align: left;">
+      <action style="--kite9-horizontal-align: left;">Automated Testing</action>
+   </group>
+   <container id="d" style="--kite9-vertical-sizing: maximize;  ">
+      <risk class="complexity" style="--kite9-vertical-align: top;  " />
+      <risk class="schedule" style="--kite9-vertical-align: top;  "/>
+      <label id="id_16-oa">Attendant Risks</label>
+   </container>
+</diagram>