Home > Blogs > barry

Risk: It's a 4 letter word

Posted: Thursday, June 24, 2004 12:55 PM by Barry Gervin
Filed under: , , ,

Risk is bad. But it doesn't have to kill you if you acknowledge, plan for and manage it. The most important part of risk management is to avoid the evil consequences as soon as you can in your project. Having risks show up the day before a delivery date (or later) is really really bad.

Both the Rational Unified Process and the Microsoft Solution Framework do good jobs at addressing perhaps one of the most important project management practices. I recommend to clients to make risk management a part of their team meetings - weekly if not more often. As a team, we need to identify, analyze and prioritize risks so that we can plan to deal with them effectively.

As part of identifying and analyzing risks is to accurate assess the consequences of the risk should it happen, and while this might seem silly, an accurate description of how we know the risk has turned into a problem. That may be a drop dead date, or some other description.

A good way to prioritize risks (using MSF) is to rank the impact of a risk should it actually happen. Combine that with a probability of the risk occurring and multiple them you get a probable impact or in MSF terms, Exposure. Ranking by Exposure will help you quickly identify what risks you should spend some resources on trying to mitigate.

All of this is described in more detail in the MSF Risk Management Discipline v. 1.1 pdf.

You can also download a couple of nice spreadsheets as part of the MSF Sample Project Lifecycle Deliverables which includes a huge array of other types of documents related to MSF. But I recommend starting with the Simple Risk Assessment Tool.xls at the very least.

Comments

  • TrackBack June 24, 2004 3:46 PM

  • Barry Gervin June 25, 2004 6:15 AM

    I've been reading some about "risk" lately. One thing that has made it hard to try to understand is that there are almost no specific examples of what is meant by risk. I'm of course familiar with the word in the sense that risk is "something bad happening", but what types of things should I be thinking about as risks? Are there at least some more or less standard things that people look for? Thanks.

  • Barry Gervin June 25, 2004 1:00 PM

    The PDF linked above talks about various categories of Risks: General, Business, Technical, Environmental. Page 17 goes into more detail. Essentially a risk is any thing that could happen to positively or negatively affect the outcome of your project (including how long it will take, how much it will cost, how good it will be, etc.)

    It's important to allow risk identication to happen in a brainstorming environment, but to end up being pretty pragmatic about what you track (and what you have any control over - or mitigation capability).

    In the MSF course, we actually go through sample scenario's. There can be a large # of risks that students delve through but as you start to analyze them, some become more important that others. Don't get too hung up on these examples, but a few....

    -Analysts who are defining the requirements of the software are not subject matter experts and they don't have a lot of access to users or SME's to collect and validate requirements from. What if we end up building software that meets nobody's needs?

    -We are using .NET. This is new to our developers, they haven't had any formal training. What if we totally go down a dead end path?

    -Developer X is being a critical/complex component that everybody is waiting on, and he is going on vacation at the end of next week. What if he doesn't get it done?

    -We have purchased a 3rd party component that we didn't write and don't have source code for. What if there are bugs in it? What if they go out of business? What if their support is weak?

New Comments to this post are disabled