Fork me on GitHub
Risk First Logo

Home of Risk-First Software Development

Start Here

Quick Summary
A Simple Scenario
The Risk Landscape


Please star this project in GitHub to be invited to join the Risk First Organisation.


Consuming Hacker News 14 May 2019
Twitter Cards 22 March 2019
Next - Scrum? 7 March 2019
Available On Amazon 25 February 2019
New Proof 10 February 2019


Click Here For Details

Process Risk

Process Risk is the risk you take on whenever you embark on completing a process.

Process: a process is a set of activities that interact to achieve a result.” - Process, Wikipedia

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 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

As the above diagram shows, process exists to mitigate other kinds of risk. For example:

These are all examples of Risk Mitigation for the owners of the process. But often the consumers of the process end up picking up Process Risks as a result:

Process Risk, and its consequences, compared with Agency Risk

When we talk about “Process Risk” we are really referring to these types of risks, arising from “following a set of instructions.” Compare this with Agency Risk (which we will review in a forthcoming section), which is risks due to not following the instructions, as shown in the above diagram . Let’s look at two examples, how Process Risk can lead to Invisibility Risks and Agency Risk.

Processes 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, so often it’s better to try and have clear boundaries of what is “in” and “out” of the process’ domain.

Sometimes, processes are not used commonly. How can we rely on them anyway? Usually, the answer is to build in extra feedback loops:

The feedback loops allow us to perform Retrospectives and Reviews to improve our processes.

Processes, Sign-Offs and Agency Risk

Often, Processes will include sign-off steps. The Sign-Off is an interesting mechanism:

Often, Sign-Offs boil down to a balance of risk for the signer: on the one hand, personal, career risk from signing off, on the other, the risk of upsetting the rest of the staff waiting for the sign-off, and the Dead End Risk of all the effort gone into getting the sign-off if they don’t.

This is a nasty situation, but there are a couple of ways to de-risk this:

Evolution Of Process

Writing software and designing processes are often overlapping activities. Often we build processes when we are writing software. Since designing a process is an activity like any other on a project, you can expect that the Risk-First explanation for why we do this is risk management.

Processes arise because of a desire to mitigate risk. When whole organisations follow that desire independently, they end up following an evolutionary or gradient-descent approach to risk reduction (as we will see below).

Here, we are going to look at how a Business Process might mature within an organisation.

Business Process or Business Method is a collection of related, structured activities or tasks that in a specific sequence produces a service or product (serves a particular business goal) for a particular customer or customers.” - Business Process, Wikipedia

Let’s look at an example of how that can happen in a step-wise way.

Step 1: clients `C` need `A` to do their jobs, incurring Complexity Risk.

  1. As the above diagram shows, there exists a group of people inside a company C, which need a certain something A in order to get their jobs done. Because they are organising, providing and creating A to do their jobs, they are responsible for all the Complexity Risk of A.

Step 2: team `B` doing `A` for clients `C`.  Complexity Risk is transferred to B, but C pick up Staff Risk.

  1. Because A is risky, a new team (B) is spun up to deal with the Complexity Risk, which might let C get on with their “proper” jobs. As shown in the diagram above, this is really useful: C’s is job much easier (reduced Complexity Risk) as they have an easier path to A than before. But the risk for A hasn’t really gone - they’re now just dependent on B instead. When members of B fail to deliver, this is Staff Risk for C.

Step 3: team `B` formalises the dependency with a Process

  1. 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).

Person D acts as a middleman for customers needing some variant of `A`, transferring Complexity Risk

  1. Teams like B can sometimes end up in “Monopoly” positions within a business. This means that clients like C are forced to deal with whatever process B wishes to enforce. Although they are unable to affect process P, C still have risks they want to transfer.

In this example, you can see how the organisation evolves process to mitigate risk around the use (and misuse) of A. This is an example of Process following Strategy:

In this conception, you can see how the structure of an organisation (the teams and processes within it, the hierarchy of control) will ‘evolve’ from the resources of the organisation and the strategy it pursues. Processes evolve to meet the needs of the organisation.” - Henry Minzberg, Strategy Safari

Two key take-aways from this:

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: 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 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) 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…


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 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 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, 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

This implies that there is a tendency for organisations to end up with needless levels of Process Risk.

To fix this, design needs to happen at a higher level. In our code, we would Refactor 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, it’s time to look at Boundary Risk.

Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.