One of the difficulties in adopting new engineering practices is getting the rest of your team on board. This is especially true if they've never seen the thing you're doing before, or if they don't see how it solves a problem - I've found that the techniques I've borrowed from other disciplines are often perceived as overkill by my colleagues. However, people can get set in their ways to the exclusion of other approaches and it can keep them from really giving your idea a chance.

For example, I did a Probabilistic Risk Assessment on one of our projects recently to try and identify hidden obstacles during a particularly tricky data move. PRAs are a technique that is used by NASA and other highly regarded engineering organizations to quantify the impact of possible failure modes and to prioritize your efforts to mitigate them. At its core, the technique is to rate the impact of each failure mode and multiply that by its probability of occurring to yield the expected impact. This makes total sense to anyone who has studied game theory or who tries to use probabilistic reasoning, but it seems somewhat silly and artificial to others.

The assessment I did gave me some new insight on medium-impact, medium frequency problems that needed to be addressed, as well as some high-impact low probability ones that could take us out of the game. As a tool for assessing the risk it performed well, but the real value of using this technique was that I was forced to really think about the risks that we were exposed to and rate them relative to each other. Once I had that information in one place where I could look at it (with a bit of nice formatting to help distill the info) it was straightforward to start identifying mitigation strategies - and to see where risks were related to each other.

Going over the results with my team, I also saw another real benefit: we had a common ground to start from. Everyone understands how the PRA works; the math is not hard. Getting some numbers up on the board and discussing them together along with the mitigation strategies oriented us as a team on the highest risk items and gave us a natural prioritization. Additionally, the spreadsheet containing the assessment also acts as a record for us to retain our thoughts on this and we've used it as a reference when planning our development efforts.

In practice how to apply these techniques to software is not always obvious, and some techniques may really be overkill or a waste of time. However, if you see value in using something new I encourage you to stick to it. Over time, other folks may see it too.

If you like what I write, you can subscribe to my mailing list to get new posts in your inbox: