Here we look at how exposing your “Internal Model” to reality is in itself a good risk management technique.
The world is too complex to understand at a glance. It takes years for humans to build a model of reality in our heads. And within a team, the model is split amongst people, documents, email, tickets, code… but it is still a model.
This “Internal Model” of reality informs the actions we take in life: we take actions based on our model, hoping to change reality with some positive outcome.
For example, while organising a dinner party you’ll have a model of who you expect to come. You might take actions to ensure there is enough food, that you’ve got RSVPs and so on.
The actions we take have consequences in the real world. Hopefully, we eliminate some known risks but we might expose new hidden risks as we go. There is a recursive nature about this - we’re left with an updated Internal Model, and we see new actions we have to take as a result.
Navigating the “Risk Landscape”
The diagram above shows just one possible action but really, you’ll have choices. We often have multiple ways of achieving our goals.
What’s the best way?
I would argue that the best choice of what to do is the one which mitigates the most existing risk while accruing the least attendant risk to get it done. That is, when you take an action, you are trading off a big risk for a smaller one.
You can think of Taking Action as moving your project on a “Risk Landscape”: ideally, when you take an action, you move from some place with worse risk to somewhere more favourable, as shown in the diagram above.
Sometimes, you can end up somewhere worse: the action you took to manage a risk has made things worse. Almost certainly, this will have been due to a hidden risk that you weren’t aware of when you embarked on the action, otherwise you’d not have chosen it.
An Example: Unit Testing
Take Unit Testing for example: Clearly, writing Unit Tests adds to the amount of development work, so on its own, it adds Schedule Risk.
However, if you write just enough of the right Unit Tests, you should be short-cutting the time spent finding issues in the User Acceptance Testing (UAT) stage, so you’re hopefully trading off a larger Schedule Risk from UAT and adding a smaller Schedule Risk to Development.
Second Example: Automation
Automating processes (as shown in the diagram above) is often tempting: it should save time, and reduce the amount of boring, repetitive work on a project. But sometimes, it turns into an industry in itself, consumes more effort than it’ll ever pay back and needs to be maintained in the future at great expense.
Third Example: MongoDB
On a previous project in a bank we had a requirement to store a modest amount of data and we needed to be able to retrieve it fast. The developer chose to use MongoDB for this. At the time, others pointed out that other teams in the bank had had lots of difficulty deploying MongoDB internally, due to licensing issues and other factors internal to the bank.
Other options were available, but the developer chose MongoDB because of their existing familiarity with it: therefore, they felt that the Hidden Risks of MongoDB were lower than the other options.
This turned out to be a mistake: the internal bureaucracy eventually proved too great and MongoDB had to be abandoned after much investment of time.
This is not a criticism of MongoDB: it’s simply a demonstration that sometimes, the cure is worse than the disease. Successful projects are always trying to reduce Attendant Risks.
The Cost Of Meeting Reality
Meeting reality in full is costly. For example, putting your software in front of users in production will definitely put you into contact with reality. You’ll learn a lot. But there are lots of tasks that are expensive:
- The Release Process
- Training Users
- Getting users to use your system
- Gathering feedback
All of these steps take a lot of effort and time. But you don’t have to meet the “whole of reality” in one go. You can meet it in a limited way which is less expensive. This is why we have activities like User Acceptance Testing (UAT) or incremental delivery. They give us some flavour of reality, but more cheaply and sooner.
Beta-releases and releasing to small populations of users also allow us to meet reality, but in a less risky way.
In all, to de-risk, you should try and meet reality:
- Sooner: so you have time to mitigate the hidden risks it uncovers.
- More Frequently: so the hidden risks don’t hit you all at once.
- In Smaller Chunks: so you’re not over-burdened by hidden risks all in one go.
- With Feedback: if you don’t collect feedback from the experience of meeting reality, hidden risks stay hidden.
So, here we’ve looked at Meeting Reality, which basically boils down to taking actions to expose yourself to hidden risks and seeing how it turns out:
- Each Action you take is a step on the Risk Landscape.
- Each Action exposes new Hidden Risks, changing your Internal Model.
- Ideally, each action should reduce the overall Attendant Risk on the project (that is, puts it in a better place on the Risk Landscape.
Could it be that everything you do on a software project is risk management? This is an idea explored next in Just Risk.
Add Your Star On GitHub to receive an invite to the GitHub Risk-First GitHub team for new article notifications and discussion.