Process Risk

Process Risk, as we will see, 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

In the software development world (and the business world generally) 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. But sometimes, they involve events occurring: a build process might start after you commit some code, for example.

The Purpose Of Process

Process exists to mitigate other kinds of risk, and for this reason, we'll be looking at them again in Part 3: Practices, where we'll look at how you can design processes to mitigate risks on your own project.

Until we get there, let's look at some examples of how process can mitigate other risks:

• Coordination Risk: You can often use process to help people coordinate. For example, a Production Line is a process where work being done by one person is pushed to the next person when it's done. A meeting booking process ensures that people will all attend a meeting together at the same place and time, and that a room is available for it.
• Dependency Risk: You can use processes to make dependencies explicit and mitigate dependency risk. For example, a process for hiring a car will make sure there is a car available at the time you need it. Alternatively, if we're processing a loan application, we might need evidence of income or bank statements. We can push this Dependency Risk onto the person asking for the loan, by making it part of the process and not accepting the application until this has been provided.
• Complexity Risk: Working within a process can reduce the amount of Complexity you have to deal with. We accept that processes are going to slow us down, but we appreciate the reduction in risk this brings. (They allow us to trade Complexity for Schedule risk). For example, setting up a server might be complex, but filling in a form to do the job might simplify things. Clearly, the complexity hasn't gone away, but it's hidden within the process. Process therefore can provide Abstraction. mcdonalds. tbd
• Operational Risk: Operational Risk 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, making a loan to a money launderer could be a failure of the loan agent. But, if they followed the process, it's a failure of the Process itself.

These are all examples of Risk Mitigation for the owners of the process. The consumers of the process end up picking up most of the Process Risks. Let's see how this comes about.

Evolution Of Business Process

Before we get to examining what constitutes Process Risks, let's consider how processes form. Specifically, we're going to look at Business Process:

"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

Business Processes often arise in response to an unmet need within an organisation. And, as we said above, they are usually there to mitigate other risks. Let's look at an example life-cycle of how that can happen.

0. Let's say, there exists a group of people inside a company C, which need a certain something A in order to get their jobs done. It might be a producing a resource, or dealing with some source of complexity, or whatever.

1. Person B in a company starts producing A as a service to others. This is really useful! It makes the the lives of clients in C much easier as they have an easier path to A than before. B gets busy keeping C happy. No one cares. But then, B goes on holiday. A doesn't get done, and people now care: the Dependency Risk is suddenly apparent.

2. Either, B co-opts other people to help, gets given a team (T), or someone else forms a team T containing B to get the job done "properly".

• T is responsible for doing A, but it needs to supply the company with A reliably and responsibly, otherwise there will be trouble, so they try and please all of their clients as far as possible.
• This is a good deal for their clients within C, but because there is a lot of variation in what the clients ask for, T end up absorbing a lot of Complexity Risk and are overworked.
• This is attendant Schedule Risk: They either need to streamline what they are doing, or get a larger budget, because all this extra Complexity impacts their ability to reliably deliver A.

3. T organises bureaucratically, so that there is a controlled process (P) by which A can be accessed. Like a cell, they have arranged a protective barrier around themselves, the strength of which depends on the power conferred to them by control of A.

• P probably involves filling in a form (or following some other Protocol).
• T can now deal with requests on a first-come-first-served basis and deal with them all in the same way: Complexity Risks are now the problem of the form-filler in C.
• T has mitigated Schedule Risk issues by drawing a line around the amount of Complexity Risk they are willing to take on.
• C now has Process Risk: will their requirements for A be met by T? They have to submit to the process to find out...

4. But it's hard to make sure the right clients get access to A at the right times, and it's necessary to synchronise access across company C. (A Coordination Risk issue.)

• T reacts and sets up sign-off, authorisation or monetary barriers around A, moving the Coordination Risk issue out of their team.
• But, for C, this again increases the Process Risk involved in using A.

5. But, there are abuses of A: people either misuse it, or use it too much. (These are Operational Risks).

• T reacts by increasing the amount of process to use A, mitigating Operational Risk within their team, but...
• This corresponds to greater Process Risk for clients in company C.

6. Person D, who has experience working with team T acts as a middleman for customers requiring some variant of A for a subset of C. They are able to help navigate the bureaucratic process (handle with Process Risk). The cycle potentially starts again: will D end up becoming a new team, with a new process?

In this example, you can see how the organisation evolves to mitigate risk around the use (and misuse) of A: First, Complexity Risk, then Coordination Risk, then Dependency Risk and finally, the Process Risk was created to mitigate everything else. 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." - Minzberg, Strategy Safari

An Example - Release Process

For many years I have worked in the Finance Industry, and it's given me time to observe how, across an entire industry, process can evolve, both in response to regulatory pressure but also because of organisational maturity, and mitigating risks:

1. Initially, I could release software by logging onto the production accounts with a password that everyone knew, and deploy software or change data in the database.
2. The first issue with this is bad actors: How could you know that the numbers weren't being altered in the databases? Production auditing came in so that at least you could tell who was changing what, in order to point the blame later.
3. But, there was still plenty of scope for deliberate or accidental damage. I personally managed to wipe production data on one occasion by mistaking it for a development environment. Eventually, passwords were taken out of the hands of developers and you needed approval to "break glass" to get onto production.
4. Change Requests were introduced. This is another approval process which asks you to describe what you want to change in production, and why you want to change it. In most places, this was quite an onerous process, so the unintended consequence was that release cadence was reduced.
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, effectively taking you back to step 1. So auditing of Change Requests had to happen.

... and so on.

Process Risks

Process Risk, then, is a type of Dependency Risk, where you are relying on a process. In a way, it's no different from any other kind of Dependency Risk. But Process Risk manifests itself in fairly predictable ways:

• Reliability Risk: If people are part of the process, there's the chance that they forget to follow the process itself, and miss steps or forget your request completely. The reliability is related to the amount of Complexity Risk the process is covering.
• Invisibility Risk: Usually, processes (like other dependencies) trade Complexity Risk for visibility: 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.
• Fit Risk: You have to be careful to match the process to the outcome you want. Sometimes, it's easy to waste time on the wrong process.
• 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 report back.
• Agency Risk: Due to Parkinson's Law, see below.
• Operational Risk: Where processes fail, this is often called Operational Risk, which we'll address further in it's own section.
• Credit Risk: Where you pay for something to be done, but then end up without the outcome you want. Let's look at that in more detail.

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

• Testing that backups work, even when no backup is needed.
• Running through a disaster recovery scenario at the weekend.
• Increasing the release cadence, so that we practice the release process more.

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

Bureaucracy Risk

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. So, some of Bureaucracy Risk is due to Complexity.

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 Bureaucratic Risk.

Credit Risk

Where the process you depend on is being run by a third-party organisation, (or that party depends on you) you are looking at Credit Risk (also known as Counterparty Risk):

"A credit risk is the risk of default on a debt that may arise from a borrower failing to make required payments... For example... A business or consumer does not pay a trade invoice when due [or] A business does not pay an employee's earned wages when due" - Credit Risk, Wikipedia

Money is changing hands between you and the supplier of the process, and often, the money doesn't transfer at the same time as the process is performed. Let's look at an example: Instead of hosting my website on a server in my office, I could choose to host my software project with an online provider. I am trading Complexity Risk for Credit Risk, because now, I have to care that the supplier is solvent.

There's a couple of ways this could go wrong: They may take my payment, but then turn off my account. Or, they could go bankrupt, and leave me with the costs of moving to another provider (this is also Dead-End Risk).

Mechanisms like insurance, contracts and guarantees help mitigate this risk at the cost of complexity and expense.

Sign-Offs

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

• By signing off on something for the business, people are usually in some part staking their reputation on something being right.
• Therefore, you would expect that sign-off involves a lot of Agency Risk: people don't want to expose themselves in career-limiting ways.
• Therefore, the bigger the risk they are being asked to swallow, the more cumbersome and protracted the sign off process.

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:

• break Sign Offs down into bite-size chunks of risk that are acceptable to those doing the sign-off.
• Agree far-in-advance the sign-off criteria. As discussed in Risk Theory, people have a habit of heavily discounting future risk, and it's much easier to get agreement on the criteria than it is to get the sign-off.

Software Processes

tbd

tbd. processes as a response to legal environment.