Skip to main content

Meeting Reality

Of the new terminology we've looked at so far, Meeting Reality might be one of the most baffling. However, it is a crucial concept in risk management.

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

Meeting Reality

Different Internal Models​

The world is too complex to understand at a glance. It takes years of growth and development for humans to build a useful internal model of reality in our heads in order to understand the risks they face. Even then, we need domain experts to understand specific kinds of risk in specific areas (like software development, for example).

Within a development team, that 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.

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

When we started organising our dinner party we had an internal model of the risks we faced doing that. You might take actions to ensure there is enough food, that you've got RSVPs and so on.

Where does the term "Internal Model" come from?

Risk-First borrows the term "Internal Model" from the finance industry, where it was used in the 2004 Basel II capital requirements rules (i.e. rules to say how much money (or capital) banks needed to keep handy for any crises that might arise. In Basel II there was an "Internal Model Method", where a bank could create its own model for how much capital it needed to store. The catch was, the bank would have to demonstrate via simulations that this would have been adequate for any crisis occurring in the previous ten years.

Sadly, the financial crisis of 2007 demonstrated very quickly that just looking at the last ten years probably wasn't enough.

Interestingly, the term was previously used in Cybernetics Theory which looked at concepts of feedback and control in dynamically evolving systems, which is exactly what we're looking at here too.

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.

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 has the greatest Payoff - the one that 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.

Now, that's easier said than done! 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: 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.

One popular type of automation is Unit Testing. Writing unit tests adds to the amount of development work, so on its own, it uses up time from the schedule. It also creates complexity - you now have more code to manage. 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: 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. But sometimes, this can be dangerous: if the release contains bugs that affect the user population, your reputation may suffer and you might end up fire-fighting support issues.

UATs, beta-releases, incremental (small) releases and phased releasing to small populations of users also allow us to meet reality too, but dial down the stakes.

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.

Trade-Offs​

Making a move on the Risk Landscape is about accepting a trade-off. And the examples in this section are all classic software development trade-offs. If you're an experienced software developer, you'll understand that any technology decision (whether it's unit testing, database choices or release processes - the examples we've seen here) means accepting a trade-off.

The Risk-First diagram gives us two things. First, it makes this trade off clear: what do I lose? what do I gain? Second, by describing our trade-offs in terms of risk, we are also making clear the fact that up front, we're never certain whether the trade-off will be worth it.

Summary​

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:

Terms Used

Feedback Loop

The process of testing an Internal Model, through taking action to Meet Reality. Typically, we talk about short or long feedback loops, depending on the intervals between Meeting Reality. (View Tag)

Risk Landscape Risk-First Term

A hypothetical landscape on which risks can be placed. Taking Action means making a move on the Risk Landscape to reposition a project so that it has a different profile of Attendant Risks. (View Tag)

Take Action

Refers to any activity in the project. Actions are taken in order to manage some risk. At the same time, Taking Action usually means interacting with reality and updating the Internal Model. (View Tag)

View Glossary

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