Skip to main content

Meeting Reality

Here we look at how exposing your "Internal Model" to reality is in itself a good risk management technique.

Meeting Reality

Your Model

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.

Taking actions changes reality, but changes your model of the risks too

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.

Navigating The Risk Landscape

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.

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.

Example: Automation

Hidden Risks of 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.

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. There are lots of tasks that are expensive:

  • The Release Process
  • Training Users
  • Getting users to use your system
  • Gathering feedback

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.

To de-risk these big operations, you should try to 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.

Example: User Acceptance Testing (UAT)

Putting your software in front of users in production will definitely put you into contact with reality. You'll learn a lot.

Beta-releases and releasing to small populations of users also allow us to meet reality, but in a less risky way.

Testing flushes out Hidden Risk, but increases Schedule Risk

Activities like User Acceptance Testing (UAT) or incremental delivery give us some flavour of reality, but more cheaply and sooner.


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:

Could it be that everything you do on a software project is risk management? This is an idea explored next in Just Risk.