Predict project blowouts using a risk matrix

If you’re working on a technical project, you’ve probably come to terms with the fact that it’s nearly impossible to forecast every possible issue that could negatively affect your project. Things are simply too unpredictable. But there’s help! Say hello to the risk matrix…

To make this a bit more tangible, let me tell you about our recently finished iOS/Android project for our client Prepd. Before the project kicked off, we used this very simple and effective technique to thoroughly think our project through. And that helped us prevent many unwanted incidents that would have resulted in a complete project blowout.

Be prepared for the worst case

One thing I’ve observed over and over again is this: no matter how much experience you have, you will never be able to reduce or eliminate all the possible risks that may affect your next project. Unless you’re working as a pilot or at a nuclear power plant where every possibility is extensively calculated, assuming you’ll have a totally risk-free project is akin to wishful thinking. There are:

  • external parameters outside of your control (the client’s business) that you cannot anticipate at the start
  • internal issues (your own tech stack and team) that you cannot fully predict because requirements change from one project to the next
  • the dynamic nature of the web which makes it hard to keep up with changes (third party plugins and services, breaking changes, software and updates etc…)

So you better be open to things going wrong. Nevertheless, we think that it’s possible to be prepared for and identify most of the worst-case scenarios, so that if something does go wrong, you’ve got enough buffer, capacity, resources and know-how to absorb the shock.

How to create a risk matrix

Before the Prepd project kicked off, we put together an internal risk matrix that listed the potential incidents that we could think of that could derail the project. That risk matrix forced us to think deeply about the challenges and mentally go through each of them in detail.

What does a risk matrix look like? As you’ll see, it’s quite simple:

Set up a table with two axes. One axis stands for “probability” (e.g. “Unlikely”, “Possible”, “Certain”), the other for “potential impact” (“Negligible”, “Critical”, “Catastrophic”). Then:

  1. Brainstorm as many risks as you can think of
    • This should involve everything that is remotely related to and has ever gone wrong in one of your previous projects (hint: keep an archive of incidents for future reference)
    • Mentally go through the different phases of the project, identifying the different risks in each phase and what external factors could affect things.
    • Let other teammates contribute, noting down their concerns. The more, the merrier!
  2. Categorise the risks you’ve identified, weighing them up against each other, and put each of them into your table at the corresponding spot
  3. Evaluate likelihood vs. impact and highlight the most critical issues (usually the ones that are most likely and have the most catastrophic potential impact)
  4. Team up with someone to discuss the matrix, and how the different scenarios would negatively affect your project
  5. Look at what protective measures you can set up. Create a list of actions or rescue plan in case something goes wrong
Risk matrix with the risk impact on the x- and its likelihood on y-axis
A risk matrix we used for Prepd to highlight some potential issues we could (and actually did!) run into

The result

Let’s get back to the reality of the project again and let me tell you about our experience.

As you can imagine, a few of the issues listed above actually did occur as expected, some things never happened, and a few of them derailed us quite a bit.

Expected issues

  • All the issues that we had categorised as “certain” actually occurred
  • From the possible and unlikely column, half of them really happened
  • And from the rare column, only one thing went wrong

As you can see above, we added comments to some of the issues to discuss possible ways of avoiding them. That “mental preparedness” made a big difference to how we dealt with the issue when it popped up.

Unexpected issues

Despite our best efforts, some unexpected things that we didn’t think of in our risk matrix did actually occur as well. They didn’t derail us entirely, but caused some frustration and slowed down our process. Let’s take a look at them:

  • We had to apply for an Enterprise Developer Account at Apple on behalf of the client, and that process took much longer than expected because of additional paperwork and a lengthy approval process. The account didn’t get activated in the end, so we had to look for a plan B.
    Conclusion? Nothing that we could have anticipated, but something we’ll factor into our next project and ensure that we start the application process right at the beginning of the project.
  • A couple of times, our deployment pipeline failed because of changing or updated third-party dependencies, and it took us some time to figure out what went wrong. Usually these issues were kind of random and fixing them required some extra time and research. This slowed down the development process a lot.
    Conclusion? New technologies always bear unexpected risks that you should allow extra time and budget for. It’s also worth considering npm shrinkwrap in such scenarios
  • We were using a third-party API to parse some of our app’s content, but the data that it returned didn’t meet our expectations, so we had to figure out ways around its shortcoming and build a few additional tools to take care of that.
    Conclusion? Expect external dependencies (especially critical APIs) to fail or deliver unexpected results, and build small test cases to gauge how much additional budget/time needs to be allocated.
  • All the source data (recipes and nutrition information) provided to us for the app by the Prepd team had to be reviewed and tweaked manually, then added to our CMS one by one, slowing down our process and forcing us to onboard another person to help with content entry.
    Conclusion? Prioritise and provide budget for content sanitisation, determine early enough whose role content management is.

What did we learn from this exercise?

As mentioned before, the web is not rocket science. It’s dynamic, things break and there’s always a lot of unknown territory for you to explore. The more experienced people on your team you have, the less trouble you’ll probably get into. But you still need to think things through meticulously and make sure to have some processes in place to reduce risks and their potential impact. The risk matrix is an excellent tool to help you do just that.

Risk management is actually a major field of its own, and there are plenty of certificates and courses in that space to turn you into a serious risk expert. The Risk Matrix is a methodology used in Risk assessment and exists as a standard in different contexts and organisations (e.g. NASA, ISO), but you probably don’t have to go that deep to understand and apply this fairly simple exercise in your day-to-day business.


Image credit: