Do you risk analyse your projects?

Question

Do you use risk analyse methods when starting new projects?

I love when fresh ppl start working at the company, they have so much theory they learn and want to implement when they start to work. Risk analysing, project management, coding standards, documentation standards and so on. (Then the reality hits them, most customers will not pay for all this) ;) But still, i really love the fresh winds and new knowledge they carry with them!

The car industry and i assume a LOT of other industys use risk analysis on daily basis when implementing a new feature or whatever they do.

My experience is that the "risk analysing" I have done in the past was to say "this part is a tricky one, I dont know if it gonna work or not" and "If it does not work this way, we can try that way".

Today I used a risk analyse protocol belonging to the car industry, and I was impressed that it after the meeting singled out the one thing in the project that was most vulnerable. And gave a number of how much attention we should give that feature in the program against all other.

Of course we have done this earlier in projects but then its just called, "What can go wrong in this project" or "What is the obstacles in the project?" not a part of a protocoll that can be meassured between projects and analysed with nubers.

So.. I want to know everything you know about risk analysing. Enlight me!

Answer 1

I've never been involved in a project that did much formal risk analysis. However; we do slightly less formal risk analysis all the time - we're constantly making lists of things that could blow up in our faces, what we're planning to do to prevent the explosion, and what we will do if we're unsuccessful in preventing it, and it happens.

I've been very impressed with the material in Waltzing With Bears: Managing Risk with Software Projects. They offer a very formal risk analysis process, but their analysis and insights are valuable on much less formal risk analysis, as well.

Answer 2

There are several types of risk that should be taken into account when approaching a project:

• Risk of not implementing - The risk posed if the project fails, or if the project is terminated
• Risk of missed requirements - The risk that requirements will be missed
• Organizational risk - The risk created by any organizational changes caused by the change

Additionally, there are feature specific risks:

• Integration risk - The risk that integrating a feature will cause the system to stop functioning properly
• Regression risk - The risk that the feature will cause other features to not work
• Security risk - The risk that a feature will not provide adequate protection to the system (introduce an exploit)

In terms of analysis, it is important to identify the project risks qualitatively so that the team is aware of these. They are primarily mitigated by communication plans. For the feature specific risks, it is important to identify the specific risks quantitatively. Typically, the architect should document integration and security risks, and the QA team should be responsible for regression risk. I have found that there really are no tools that can do this as well as a good team that communicates well.

Answer 3

Risk analysis is a fancy way of saying "covering my arse when things go tits up", and as such is an excellent way of dodging blame when things don't work out as planned (which, in software engineering, is pretty much always).

Risk Analysis: Point out all the things that can go wrong, write them up in a pretty .pdf, and send them to your pointy haired bosses.

Answer 4

I do risk analysis all the time - both formally and informally (when assessing, for instance, if a bug needs to be fixed).

It's an excellent tool to give appropriate attention to the appropriate issues, avoid paranoia about some aspects of the project (sometimes, we lose perspective and worry about the wrong things), and make difficult decisions when you have limited resources.

It doesn't have to be extremely formal or time-consuming. When you get down to it, our method is simply to ask:

• "what's the probability of this occurring?"
• "what's the impact if this occurs?"
• "how well will we be able to handle the problem?"

You give a score from 1 to 10 to all criteria, multiply them, and take preventive care of risks in decreasing order (we also have a threshold above which a risk is considered unacceptable and must be mitigated).

You might also add a fourth question on how much it costs to reduce the risk at the source (being in the medical industry, we don't: a risk that's considered unacceptable for the patient's health must be lowered, regardless of the cost, or that feature must be dropped)