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.
As the above diagram shows, process exists to mitigate other kinds of risk. For example:
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 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.
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:
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.
C, which need a certain something
Ain order to get their jobs done. Because they are organising, providing and creating
Ato do their jobs, they are responsible for all the Complexity Risk of
Ais risky, a new team (
B) is spun up to deal with the Complexity Risk, which might let
Cget 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
Athan before. But the risk for
Ahasn’t really gone - they’re now just dependent on
Binstead. When members of
Bfail to deliver, this is Staff Risk for
Crelationship. Perhaps some members of the
Bteam give better service than others, or deal with more variety in requests? In order to standardise the response from
Band also to reduce scope-creep in requests from
Borganises bureaucratically so that there is a controlled process (
P) by which
Acan be accessed. Members of teams
Cnow interact via some request mechanism like forms (or another protocol).
Bcan now process requests on a first-come-first-served basis and deal with them all in the same way: the more unusual requests from
Cmight not fit the model. These Process Risks are now the problem of the form-filler in
Cnow has Invisibility Risk since it can’t access team
Band see how it works.
Bmay also use
Pto introduce other bureaucracy like authorisation and sign-off steps or payment barriers. All of this increases Process Risk for team C.
Bcan sometimes end up in “Monopoly” positions within a business. This means that clients like
Care forced to deal with whatever process
Bwishes to enforce. Although they are unable to affect process
Cstill have risks they want to transfer.
D, who has experience working with team
Bacts as a middleman for some of
C, requiring some variant of
A. They are able to help navigate the bureaucracy (handle with Process Risk).
Dend up becoming a new team, with a new process?
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:
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:
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.
Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.