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.
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.
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”.
As shown in the above diagram, using an abstraction you already know means:
As shown in the above diagram, inventing a new abstraction means:
As shown in the above diagram, learning a new abstraction means:
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.
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.
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.
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.
Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.