Process risk done

dictionary.txt

@@ -359,3 +359,6 @@ erratically
 eidos
 lara
 croft
+accrete
+decommissioned
+ratchets

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

@@ -27,7 +27,7 @@ practice:
    - tag: Invisibility Risk
      reason: "The quality and performance characteristics may be obscured by automation."
    - tag: Process Risk
-     reason: "Automation introduces a process"
+     reason: "Automation introduces a process, which therefore means a new source of Process Risk."
    - tag: Agency Risk
      reason: Automated processes have their own agency and might not work as desired.
    - tag: Security Risk

docs/practices/Deployment-And-Operations/Configuration-Management.md

@@ -22,8 +22,6 @@ practice:
    - tag: Complexity Risk
      reason: "Reduces complexity by managing system changes in a controlled and documented manner."
   attendant:
-   - tag: Process Risk
-     reason: "The CM process can introduce bureaucratic overhead."
    - tag: Dependency Risk
      reason: "Dependencies on the CM tools and processes can become critical points of failure."
    - tag: Security Risk

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

@@ -19,6 +19,8 @@ practice:
      reason: "Identifies and addresses potential issues before they impact system reliability."
    - tag: Security Risk
      reason: "Monitors for security breaches and anomalies."
+   - tag: Process Risk
+     reason: "Monitoring a process can ensure that when it misbehaves the issues are quickly caught."  
   attendant:
    - tag: Complexity Risk
      reason: "Implementing comprehensive monitoring solutions can add complexity."

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

@@ -26,6 +26,8 @@ practice:
      reason: "Delays in the release process can impact overall project timelines."
    - tag: Operational Risk
      reason: "Releasing software means that the software has to be supported in production."
+   - tag: Process Risk
+     reason: "Complex release procedures are a source of process risk."
   related:
    - ../Planning-and-Management/Change-Management
    - ../Tools-and-Standards/Version-Control

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

@@ -16,7 +16,7 @@ practice:
    - tag: Feature Risk
      reason: "Build or improve some features which our clients will find useful."
    - tag: Process Risk
-     reason: Problems with processes can be fixed by adding code.
+     reason: Problems and edge cases with software processes can be fixed by adding code.
   attendant:
    - tag: Implementation Risk
      reason: "Poor coding practices can lead to significant implementation issues."

docs/practices/External-Relations/Contracts.md

@@ -25,7 +25,7 @@ practice:
    - tag: Coordination Risk
      reason: "Requires careful coordination to ensure all terms are met."
    - tag: Process Risk
-     reason: "The process of drafting, negotiating, and managing contracts can be complex and time-consuming."
+     reason: "The process of drafting, negotiating, and managing contracts is a process with significant risk."
    - tag: Deadline Risk
      reason: "Contracts often stipulate certain conditions must be met at certain times."
   related:

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

@@ -26,7 +26,7 @@ practice:
    - tag: Coordination Risk
      reason: "Requires coordination among stakeholders to provide timely sign-off."
    - tag: Process Risk
-     reason: "Approval processes may lack required flexibility"
+     reason: "Adding approvals to a process increases the number of stakeholders involved and can impact process performance."
   related:
    - ../Planning-and-Management/Stakeholder-Management
    - ../Communication-and-Collaboration/Review

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

@@ -23,7 +23,7 @@ practice:
    - tag: Schedule Risk
      reason: "Managing changes systematically can introduce delays."
    - tag: Process Risk
-     reason: "Change management can increase dependency on approval processes and stakeholders."
+     reason: "Change control is a process, and therefore is a source of process risk. "
   related:
    - ../Development-and-Coding/Coding
    - ../Testing-and-Quality-Assurance/Integration-Testing

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

@@ -18,8 +18,6 @@ practice:
      reason: "Ensures optimal utilization of team members' skills and capabilities."
    - tag: Schedule Risk
      reason: "Distributes workload effectively, helping to meet deadlines."
-   - tag: Process Risk
-     reason: "Delegation can be used to stop processes getting in the way of progress."
   attendant:
    - tag: Agency Risk
      reason: "Can lead to a loss of control over task execution and quality."

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

@@ -30,7 +30,7 @@ practice:
    - tag: Complexity Risk
      reason: "Managing an excessive number of logged issues can add complexity."
    - tag: Process Risk
-     reason: "Creates dependency on issue tracking tools and their accuracy."
+     reason: "The issue lifecycle from creation to resolution is a process, therefore a source of process risk."
    - tag: Schedule Risk
      reason: "Managing and resolving logged issues can impact project timelines."
   related:

docs/risks/Dependency-Risks/Agency-Risks/_category_.yaml

@@ -1,4 +1,4 @@
-position: 4
+position: 7
 link:
   type: doc
   id: Agency-Risk

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

@@ -6,7 +6,7 @@ slug: /risks/Boundary-Risk
 featured: 
   class: c
   element: '<risk class="boundary" />'
-sidebar_position: 11
+sidebar_position: 6
 tags:
  - Risks
  - Boundary Risk

docs/risks/Dependency-Risks/Deadline-Risk/_category_.yaml

@@ -1,4 +1,4 @@
-position: 4
+position: 3
 link:
   type: doc
   id: Deadline-Risk

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

@@ -1,5 +1,5 @@
 ---
-title: Dependency Risk
+title: Dependency Risks
 description: Risk faced by depending on something else,  e.g. an event, process, person, piece of software or an organisation. 
 
 featured: 

docs/risks/Dependency-Risks/Process-Risk.md → docs/risks/Dependency-Risks/Process-Risk/On-Bureaucracy.md

@@ -1,48 +1,36 @@
----
-title: Process Risk
-description: Risks due to the following a particular protocol of communication with a dependency, which may not work out the way we want.
 
-slug: /risks/Process-Risk
-featured: 
-  class: c
-  element: '<risk class="process" />'
-sidebar_position: 10
-tweet: yes
-tags: 
- - Risks
- - Process Risk
-part_of: Dependency Risk
----
 
-<RiskIntro fm={frontMatter} />
 
-[Process Risk](/tags/Process-Risk) is the risk you take on whenever you embark on completing a _process_. <!-- tweet-end -->
 
-> "**Process**: a process is a set of activities that interact to achieve a result." - [Process, _Wikipedia_](https://en.wikipedia.org/wiki/Process)
+
+
+
+
+
 
 Processes commonly involve _forms_:  if you're filling out a form (whether on paper or on a computer) then you're involved in a process of some sort, whether an "Account Registration" process, "Loan Application" process or "Consumer Satisfaction Survey" process.  Sometimes, they involve events occurring:  a [build process](https://en.wikipedia.org/wiki/Software_build) might start after you commit some code, for example.  The _code we write_ is usually describing some kind of process we want performed.
 
-## The Purpose Of Process
 
-![Introducing process can mitigate many risks](/img/generated/risks/process/process-risk-introduction.svg)
 
-As the above diagram shows, process exists to mitigate other kinds of risk.  For example:
 
- - **[Coordination Risk](/tags/Coordination-Risk)**:  you can often use process to help people coordinate.  For example, a [Production Line](https://en.wikipedia.org/wiki/Production_line) is a process where work being done by one person is pushed to the next person when it's done.  A room booking process is designed to efficiently allocate meeting rooms. 
- - **[Operational Risk](/tags/Operational-Risk)**:  this encompasses the risk of people _not doing their job properly_.  But, by having a process, (and asking, did this person follow the process?) you can draw a distinction between a process failure and a personnel failure.  For example, accepting funds from a money launderer _could_ be a failure of a bank employee.   But, if they followed the _process_, it's a failure of the [Process](/tags/Process-Risk) itself. 
- - **[Complexity Risk](/tags/Complexity-Risk)**: working _within a process_ can reduce the amount of [Complexity](/tags/Complexity-Risk) you have to think about.  We accept that processes are going to slow us down, but we appreciate the reduction in risk this brings.  Clearly, the complexity hasn't gone away, but it's hidden within design of the process.  For example, [McDonalds](https://en.wikipedia.org/wiki/McDonald's) tries to design its operation so that preparing each food item is a simple process to follow, reducing complexity (and training time) for the staff.
+## Bureaucracy
+
+Where we've talked about process evolution above, the actors involved have been acting in good faith:   they are working to mitigate risk in the organisation.  The [Process Risk](/tags/Process-Risk) that accretes along the way is an _unintended consequence_:  There is no guarantee that the process that arises will be humane and intuitive.  Many organisational processes end up being baroque or Kafka-esque, forcing unintuitive behaviour on their users.  This is partly because process design is _hard_ and it's difficult to anticipate all the various ways a process will be used ahead-of-time.  
+
+But [Parkinson's Law](https://en.wikipedia.org/wiki/Parkinsons_law) takes this one step further:  the human actors shaping the organisation will abuse their positions of power in order to further their own careers (this is [Agency Risk](/tags/Agency-Risk), which we will come to in a future section):
+
+> "Parkinson's law is the adage that "work expands so as to fill the time available for its completion". It is sometimes applied to the growth of bureaucracy in an organisation... He explains this growth by two forces: (1) 'An official wants to multiply subordinates, not rivals' and (2) 'Officials make work for each other.'" - [Parkinson's Law, _Wikipedia_](https://en.wikipedia.org/wiki/Parkinsons_law)  
+
+This implies that there is a tendency for organisations to end up with _needless levels of [Process Risk](/tags/Process-Risk)_.
+
+To fix this, design needs to happen at a higher level.  In our code, we would [Refactor](/risks/Complexity-Risk#technical-debt) these processes to remove the unwanted complexity.  In a business, it requires re-organisation at a higher level to redefine the boundaries and responsibilities between the teams.  
+
+Next in the tour of [Dependency Risks](/tags/Dependency-Risk), it's time to look at [Boundary Risk](/tags/Boundary-Risk).
 
-These are all examples of [Risk Mitigation](/tags/Mitigated-Risk) for the _owners_ of the process.  But often the _consumers_ of the process end up picking up [Process Risks](/tags/Process-Risk) as a result:
 
- - **[Invisibility Risk](/tags/Invisibility-Risk)**: it's often not possible to see how far along a process is to completion.  Sometimes, you can do this to an extent.  For example, when I send a package for delivery, I can see roughly how far it's got on the tracking website.  But this is still less-than-complete information and is a representation of reality.    
- - **[Dead-End Risk](/tags/Dead-End-Risk)**: even if you have the right process, initiating a process has no guarantee that your efforts won't be wasted and you'll be back where you started from.  The chances of this happening increase as you get further from the standard use-case for the process, and the sunk cost increases with the length of time the process takes to complete.
- - **[Feature Access Risk](/tags/Feature-Access-Risk)**: processes generally handle the common stuff, but ignore the edge cases.  For example, a form on a website might not be designed to be accessible to disabled people, or might only cater to some common subset of use-cases.
-
-![Process Risk, and its consequences, compared with Agency Risk](/img/generated/risks/process/process-risk.svg) 
-
-When we talk about "[Process Risk](/tags/Process-Risk)" we are really referring to these types of risks, arising from "following a set of instructions."  Compare this with  [Agency Risk](/tags/Agency-Risk) (which we will review in a forthcoming section), which is risks due to _not_ following the instructions, <!-- tweet-end -->as shown in the above diagram .  Let's look at two examples, how [Process Risk](/tags/Process-Risk) can lead to [Invisibility Risks](/tags/Invisibility-Risk) and [Agency Risk](/tags/Agency-Risk).
 
-### Processes And Invisibility Risk
+
+s And Invisibility 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.
 
@@ -111,31 +99,4 @@ In this example, you can see how the organisation evolves process to mitigate ri
 Two key take-aways from this:
 
  - **The System Gets More Complex**: with different teams working to mitigate different risks in different ways, we end up with a more complex situation than when we started.  Although we've _evolved_ in this direction by mitigating risks, it's not necessarily the case that the end result is _more efficient_.  In fact, as we will see in [Map-And-Territory Risk](Map-And-Territory-Risk#markets), this evolution can lead to some very inadequate (but nonetheless stable) systems.
- - **Organisational process evolves to mitigate risk**: just as we've shown that [actions are about mitigating risk](/thinking/Start), we've now seen that these actions get taken in an evolutionary way.  That is, there is "pressure" on our internal processes to reduce risk.  The people maintaining these processes feel the risk, and modify their processes in response.  Let's look at a real-life example: 
-
-## An Example - Release Processes
-
-Over the years I have worked in the Finance Industry it's given me time to observe how, across an entire industry, process can evolve both in response to regulatory pressure, organisational maturity and mitigating risk:
-
-1. Initially, I could release software by logging onto the production accounts with a shared password that everyone knew, and deploy software or change data in the database.  
-2. The first issue with this is [Agency Risk from bad actors](/tags/Agency-Risk):  how could you know that the numbers weren't being altered in the databases? _Production Auditing_ was introduced so that at least you could tell what was being changed and when, in order to point the blame later.
-3. But there was still plenty of scope for deliberate or accidental [Dead-End Risk](/tags/Dead-End-Risk) damage.  Next, passwords were taken out of the hands of developers and you needed approval to "break glass" to get onto production.  
-4. The increasing complexity (and therefore [Complexity Risk](/tags/Complexity-Risk)) in production environments meant that sometimes changes collided with each other, or were performed at inopportune times.  Change Requests were introduced.  This is an approval process which asks you to describe what you want to change in production, and why you want to change it.  
-5. The change request software is generally awful, making the job of raising change requests tedious and time-consuming.  Therefore, developers would _automate_ the processes for release, sometimes including the process to write the change request.  This allowed them to improve release cadence at the expense of owning more code.
-6. Auditors didn't like the fact that this automation existed, because effectively, that meant that developers could get access to production with the press of a button, taking you back to step 1...
-
-## Bureaucracy
-
-Where we've talked about process evolution above, the actors involved have been acting in good faith:   they are working to mitigate risk in the organisation.  The [Process Risk](/tags/Process-Risk) that accretes along the way is an _unintended consequence_:  There is no guarantee that the process that arises will be humane and intuitive.  Many organisational processes end up being baroque or Kafka-esque, forcing unintuitive behaviour on their users.  This is partly because process design is _hard_ and it's difficult to anticipate all the various ways a process will be used ahead-of-time.  
-
-But [Parkinson's Law](https://en.wikipedia.org/wiki/Parkinsons_law) takes this one step further:  the human actors shaping the organisation will abuse their positions of power in order to further their own careers (this is [Agency Risk](/tags/Agency-Risk), which we will come to in a future section):
-
-> "Parkinson's law is the adage that "work expands so as to fill the time available for its completion". It is sometimes applied to the growth of bureaucracy in an organisation... He explains this growth by two forces: (1) 'An official wants to multiply subordinates, not rivals' and (2) 'Officials make work for each other.'" - [Parkinson's Law, _Wikipedia_](https://en.wikipedia.org/wiki/Parkinsons_law)  
-
-This implies that there is a tendency for organisations to end up with _needless levels of [Process Risk](/tags/Process-Risk)_.
-
-To fix this, design needs to happen at a higher level.  In our code, we would [Refactor](/risks/Complexity-Risk#technical-debt) these processes to remove the unwanted complexity.  In a business, it requires re-organisation at a higher level to redefine the boundaries and responsibilities between the teams.  
-
-Next in the tour of [Dependency Risks](/tags/Dependency-Risk), it's time to look at [Boundary Risk](/tags/Boundary-Risk).
-
-
+ - **Organisational process evolves to mitigate risk**: just as we've shown that [actions are about mitigating risk](/thinking/Start), we've now seen that these actions get taken in an evolutionary way.  That is, there is "pressure" on our internal processes to reduce risk.  The people maintaining these processes feel the risk, and modify their processes in response.  Let's look at a real-life example: