| Where I think this article goes a little wrong is the assumption that a RACI is about risk management. A RACI can tell you who is responsible for running the risk management process, but the R (responsible) and A (accountable), are not meant to move risk and absolve all others. They're just markers for "who is going to get this work done". They are about managing work, not managing the risks that can arise from that work. Risk management is something a lot of people talk about, some people over-complicate, but few seem to do well. I have an approach that is a mixture of agile and formal methods that is actually quite simple, and includes voices from lots of groups. I've done this on many dozens of software projects. First of all there needs to be a list of risks. This list needs to be contributed to by all stake-holders, including third-parties responsible for any part of the delivery. "We all agree these things could stop the project being successful". Then you need to quantify the risks to prioritise them. The best way I've learned to do this is a number - between 1 and 10 - for "likelihood" and "impact". A 10 on likelihood is "this is certainly going to happen", a 1 is "it very probably won't, but it could". Impact is a bit more subjective, but a 10 is "if this happens, the project is guaranteed to fail and it's going to be awful", a 5 is "it would be pretty serious, but there are things that could happen to save the project despite it" and a 1 is "this probably doesn't matter". Talk it through, everyone needs to agree these are sensible estimates. "We all agree these are reasonable quantifications of the impact and likelihood of the risks". Then multiply the two numbers. Low likelihood (2) but high impact (8) gets a score of 16. High likelihood (8), high impact (7), gets 56. Low on both (2 and 2), gets 4. Order them. Start at the top scoring one. Figure out mitigations. Mitigations are actions. They have dates by which they must be done, and owners who are accountable for those actions. They can include third-parties, but if they're not at the table, somebody with a contractual relationship with that third party who is at the table (say, the customer), is going to have to own the mitigation and be accountable for it. Keep going until you get below a threshold (say, a score of 20), or you have eliminated anything above moderate score (say, 4), in either the likelihood or impact columns. You've now got clear insight of what your risks are, quantified how important they are, identified mitigations and their owners and due dates, and can have regular conversations. Mitigations could be rows in the RACI if they are strategic recurring processes or large items of work. But you can't just put it in there at the start and hope it gets managed, you need to actively manage to get it in there. "We all agree these are the actions that will be taken, and by whom, and by when, to manage the risks we have agreed and prioritised together". You will need to revisit this list - sometimes called a risk register - multiple times as the project progresses and you learn new things (agile isn't just for engineers). This, I think anybody would agree, is project management. |
Let's compare the typical startup risk management strategy:
The project owner keeps all risks in their head, no formal tracking or acknowledging of risks. People mention risks and mostly go unheard; if the risk is low probability, it's excused, if a risk is high probability but low impact, it's excused. The project owner can't track too many things, so risks are dismissed rather than adding stress to the project owner who tracks it all in their head. If the project owner is feeling good and engaged, the project owner picks their favorite risk and then has a meeting and pressures people into dealing with it somehow. If the project owner is overwhelmed, just ignore the risks.