a. "things that would mean the project failed."
in contrast to:
b. "things that could lead the project to fail."
For "a" one could list. There is no money left. The team desintegrates. Etc...
And finally ask yourself, what could I do now so that, if we arrive to any of the listed sutations the damage is reduced.
Take this comment with a grain of salt. As every other comment on the internet.
After doing all the normal project management estimates, etc, the very first thing he does is sit down everyone who will actually be implementing the project (or a representative sample).
He then asks them a simple question: "Come up with one scenario where this project would fail."
The implication being that this is lateral to the train of thought people use to make initial estimates. Iow, in all possible estimation scenarios, the project is assumed to have been a success! It's not unreasonable to expect that implicit optimism to filter down through sub-estimates.
His point was that giving people permission to imagine scenarios for total and abject failure identified important risks that could be back-fed to improve the initial optimistic estimate.
I pulled in a sample of people from the development team and proposed the following scenario:
It's the Monday morning immediately after our implementation, and you come in to the office to find a bunch of senior managers discussing a big issue with the system.
What went wrong?
That brought up a huge number of potential issues that were sitting in the back of the engineers minds that have never been written on any risk register, etc.
We talked them through, got comfortable that some of them weren't really likely/possible, and then worked on mitigations for the others (mostly via test plans)
In the end, the implementation was a success.