[wpietri]

Oh, and if your project hasn't explicitly thought through the risk, you may find out your biggest risk the hard way. If the team hasn't discused it, here's what I suggest:

Set up a 1-hour meeting. For the pre-reading, google a couple of articles on the kinds of risk to software projects. For the meeting, explain the goal is to find the the current top 5 risks. Open up a Google Sheet, label one column "Risk", and have everybody spend 10-15 minutes filling the column in. Then add a column called "Votes", and have everybody increment the votes counter by 1 for what they see as the top 5. Now sort by votes.

If people already agree on the top 5, great. If not, you'll need to get more consensus around the risk. One way to do that is to add two more columns called "Odds" and "Impact". (You can use H/M/L or 0-10 for most people; an especially numerate audience can use actual odd and actual cost.) Jointly fill those in, getting people to discuss why they would pick different things.

Once you have adequate consensus, move on to discussing them and how to mitigate them. Hopefully you end up with specific action items (which can include an MVP!). Then come back in 1-3 months to do it again; hopefully your big risks will go away and you'll have new risks. If you're lucky, the meeting will become unnecessary over time.

[LaundroMat]

It's not always easy for team members to openly discuss risk. The pre-mortem technique can help with that. Basically, it comes down to imagining being in a future where the project has failed miserably and asking team members to look back and identify what has gone wrong.

This framing allows people to speak more freely about their fears.

[wpietri]

Great point. I haven't tried that technique, but it sounds like a great way to get people to productively examine their fears.