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. For example:

• 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 is designed to efficiently allocate meeting rooms.
• 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.
• Complexity Risk: Working within a process can reduce the amount of Complexity 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 the process. Process therefore can provide Abstraction. McDonalds 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.

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

• 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.
• Feature 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, for example filling out a
• 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: Processes generally handle the common stuff, but ignore the edge cases. If the exceptional cases are not dealt with in

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.

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.

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.