Risk management is not project management

At the end of the day, no matter which way you cut it, if you run a project you must be accountable for it, otherwise failure is certain. Even if you choose a 3rd party and get them to sign off on being accountable for delivery, it's you who chose them. It's much better to be explicit. Truly owning the project and being accountable for the outcome means you'll also be more honest with yourself. If there are hardships on the way, and there always are, you must work to figure it out, you can't roll it onto someone else.

Projects aren't Fantasy Island. It's simply not reasonable to pretend something isn't true (i.e., you're accountable for your own projects) when it is. It's like saying, "The plane will fly because we're not going to believe in gravity anymore. Gravity is too inconvenient. Gravity be gone...".

Ultimately, this is a sign of poor management and leadership.

You can outsource the work, you can never outsource the responsibility.

> The risk of losing time remains though. If you want to lower that, you need redundancy: Outsource the project multiple times. That also costs multiple times as much though and still all of them might fail.

If the task is impossible or the requirements are insane, sure. You'll likely fail in all of those multiple times. It is likely though that given enough bids, Someone will find a loophole so they will be compliant to the letter of the requirements but not the spirit.

For example, you might say your software needs to run in a web browser and use standard/modern HTTP calls but you never specify it has to work on more than just windows so some vendor implemented the whole thing using xbap (silver light) and viola you can now use your stupid topaz signature input and your thermal check printers. But now the "website" works only on Windows.

But yeah if you give even a thousand different teams the task to create a time machine to go back in time, they'll all most likely fail.

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.