Staging and Classifying

Our tour is complete.

But if we are good collectors, then before we finish we should Stage our specimens and do some work in classifying what we've seen.

Towards A "Periodic Table" Of Risks

As we said at the start, Risk-First is all about developing A Pattern Language. We can use the terms like "Feature Risk" or "Learning Curve Risk" to explain phenomena we see on software projects. If we want to De-Risk our work, we need this power of explanation so we can talk about how to go about it.

The diagram above compiles all of the risks we've seen so far on our tour across the Risk Landscape. Just like a periodic table, there are perhaps others left to discover. Unlike a periodic table, these risks are not completely distinct: they mix like paint and blend into one another.

If you've been reading closely, you'll notice that a number of themes come up again and again within the different sections. It's time to look at the patterns within the patterns.

The Power Of Abstractions

Abstraction appears as a concept continually: in Communication Risk, Complexity Metrics, Map and Territory Risk or how it causes Boundary Risk. We've looked at some complicated examples of abstractions, such as network protocols, dependencies on technology or Business Processes.

Let's now generalize what is happening with abstraction. To do this, we'll consider the simplest example of abstraction: naming a pattern of behaviour we see in the real world, such as "Binge Watching" or "Remote Working", or naming a category of insects as "Beetles".

Using A Known Abstraction

As shown in the above diagram, using an abstraction you already know means:

• Mitigating Feature Risk: because the abstraction is providing you with something useful. For example, using the word "London" allows you to refer to a whole (but slightly non-specific) geographic area.
• Accepting Communication Risk: because if you are using the abstraction in conversation the people you are using it with need to understand it too.
• Accepting Map and Territory Risk: because the abstraction is a simplification and not the actual thing itself.
• Living with Dependency Risks: we depend on a word in our language (or a function in our library, or a service on the Internet). But words are unreliable. Language changes and evolves, and the words you are using now might not always mean what you want them to mean. (Software too changes and evolves: We've seen this in Red Queen Risk and Feature Drift Risk.)

Inventing A New Abstraction

As shown in the above diagram, inventing a new abstraction means:

• Mitigating Feature Risk. By giving a name to something (or building a new product, or a way of working) you are offering up something that someone else can use. This should mitigate Feature Risk in the sense that other people can choose to use your it, if it fits their requirements.
• Creating a Protocol. Introducing new words to a language creates Protocol Risk as most people won't know what it means.
• Increasing Complexity Risk. Because, the more words we have, the more complex the language is.
• Creating the opportunity for Boundary Risk. By naming something, you implicitly create a boundary, because the world is now divided into "things which are X" and "things which are not X". Boundary Risk arises from abstractions.

Learning A New Abstraction

As shown in the above diagram, learning a new abstraction means:

• Overcoming a Learning Curve: because you have to learn a name in order to use it (whether it is the name of a function, a dog, or someone at a party).
• Accepting Boundary Risks. Commitment to one abstraction over another means that you have the opportunity cost of the other abstractions that you could have used.
• Accepting Map And Territory Risk. Because the word refers to the concept of the thing, and not the thing itself.

Abstraction is everywhere and seems to be at the heart of what our brains do. But clearly, like taking any other action there is always trade-off in terms of risk.

Your Feature Risk is Someone Else's Dependency Risk

In the Feature Risk section, we looked at the problems of supplying something for a client to use as a dependency: you've got to satisfy a demand (Market Risk) and service a segment of the user community (Feature Access Risk).

However over the rest of the Dependency Risk sections we looked at this from the point of view of being a client of someone else: you want to find trustworthy, reliable dependencies that don't give up when you least want them to.

So Feature Risk and Dependency Risk are two sides of the same coin, they capture the risks in demand and supply.

As shown in the diagram above, relationships of features/dependencies are the basis of Supply Chains and the world-wide network of goods and services that forms the modern economy. The incredible complexity of this network mean incredible Complexity Risk, too. Humans are masters at coordinating and managing our dependencies.

The Work Continues

On this journey around the Risk Landscape we've collected a (hopefully) good, representative sample of Risks and where to find them. But there are more out there. How many of these have you seen on your projects? What is missing? What is wrong?

Please help by reporting back what you find.