The most important risk analysis of our projects

Human beings tend to avoid pain. We want to avoid every kind of pain so much that we actually are willing to enter extensive scenarios of work to avoid even the risk of it.

Failing is always painful. It is painful mentally, physically or socially. Or in many cases a little bit of them all. Because of the painful nature of failing, we would so much like to avoid it. No matter how high the cost was.

I’ve spend some time of my 11 years of being an entrepreneur by studying what makes some people succeed and others to never find the steps to the levelups they so desire.

It turns out, that one of the deciding factors of success is our willingness to suffer. Our willingness to endure pain opens up a possibility, because failing would then mean a chance to learn something new instead of just focusing on the pain that we wanted to avoid.

Now if we considered software projects, the same principle applies. We go through extensive scenarios to avoid or mitigate risks. But for what?

In case you want to create something new that might change the world it will always involve loads of sweating and risks of failure. So the tip that Tom DeMarco and Timothy Lister gave in their book Walzing With Bears stands strong.

If a project has no risks. Don’t do it.

After considering this I ended up with a conclusion. The really important question in our software projects is not how we could mitigate our risks.

The really important question is actually this:

Which risks should we want in our project even more?

Image for post
Image for post

(This post was inspired by the talk Liz Keogh gave at the European Testing Conference in Helsinki)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store