What is the best way to analyze a project's risk?

Question

Is there a fool-proof way to pull out all the risks involved in a project? And does it differ depending on the type of projects your working on (ie: website, client/server...)?

Answer 1

There is no fool-proof way - the most dangerous risks are the ones that you don't foresee.

Unfortunately, this is compounded by the fact that developers tend to be optimists. If you ask a programmer for a "most likely estimate" you will tend to get the same answer as if you had asked for a "best case estimate." In my experience, the best that you can do is get good people, and always assume that their estimates are low, even after you have asked them not to be optimistic, even after you have told them to include a few unforeseen detours.

And above all, never, never, NEVER tell your programmer that an estimate is too high and he needs to lower it. If you want to pull an estimate out of your hat, then do so, but be honest about the fact that you pulled it out of your hat. Pretending that "this is the programmer's estimate" when you pressured him to lower it is risky and dishonest.

I highly recommend The Mythical Man-Month by Fred Brooks for other insights into the dangers of the software development process.

Answer 2

Risk Management is a huge topic, and probably one that can't be done justice in an answer here on stackoverflow. Your best bet is to go and get a good book on software project management (the recommendation for the Software Project Survivial Guide is a good one) and go from there.

Answer 3

I liked very much this article: Risk Analysis in Software Design(PDF), take a look to it, gives a good overview about Risk Analysis, but I think that there is no fool-proof way , it really depends on your environment...

Answer 4

Do not forget the endgame of any development:

Release into production

It could be argue that any risk regarding software development should be evaluated against that objective (successfully achieve a release into production of your software, in other words 'delivering the service to the client').
That would not be enough since monitoring, and maintaining that software are risky operations in themselves, but it is a good guideline.

For instance, NASA (for which 'release' is of paramount importance!) has a Software Quality Models definition. IBM has a great series of articles on the topic.

All the other answers and book recommendations are correct.

I just wanted to put in the center of any answer what a project is all about ("release"), in order to better establish one's own definition of a "risk" for that project.

Answer 5

Experience. The practice of developing and releasing software will allow you to anticipate and mitigate risk in a way that no structured analysis can.

Answer 6

"Does [risk] differ depending on the type of projects [you're] working on?"

Yes, absolutely. There are several universal risks for software projects (lack of managerial commitment, poor communication, etc.), but risk "profiles" differ with context. The risks of a videogame project, say, are very different than the risks of an enterprise supply-chain management projecst.

For corporate development, risks differ depending on managerial support and sophistication, team structure, project size, client-facing vs internal, platform choice, and level of integration, just to name some major areas.

The very fact that risks differ is one of the reasons why "insufficient experience in the domain" is a universal risk.

Risk profiles for various contexts are popular subjects for academic papers (do a survey, grind some numbers, get a publication credit...). They aren't typically riveting reading, but they are well worth reviewing when developing a project plan.

A great short book on risk management is "Waltzing with Bears" by DeMarco and Lister.

Answer 7

A couple of major risks include: do the programmers know what needs to be built, and how to do it, and can they work together? Some development methodologies, including agile and extreme, attack these risks head on by getting something real built as soon as possible, and then evolving a working system by going after one high priority business goal at a time.