≡ Menu
Pawel Brodzinski on Software Project Management

MSF: Risk Management Basics


It’s the first post of series describing several concepts from Microsoft Solution Framework. Post will cover basics, so I strongly recommend original white papers if someone wants to make some deeper studies. Instead of going deep I’ll try to describe practical point of view. One more thing – I play with MSF 3.0/3.1 concepts. If you work with version 4.0 they can be hidden a bit now, but they’re still there – MSF 4.0 is an implementation of MSF 3.1.

Concept of risk management is quite obvious – it’s about predicting what (bad) can happen to a project. It’s like in a real life – before long journey we predict that car can brake down and it’ll completely ruin our holidays. The goal is to minimize a chance that out holidays will be poor… er… the project will go wrong.

First we need to define risks. Every member of a team can do that. Fact that idea of car braking down came from our 5-year old child doesn’t make the risk irrational. Saying that UFO can kidnap the driver is ridiculous – no matter who proposed that. In case of defining risks everyone’s invited.

Knowing just that my car can brake down doesn’t make it any better – rather worse because now I’m stressed. Just knowing what can go wrong isn’t enough. Some more information is needed: what to do to avoid the threat and what should we do if it became real. Overhauling a car is nice plan to avoid problems, calling a service would work well if something bad would happen despite our preventability. Now our risk is well equipped. It doesn’t matter who came with plans what to do – risk author or anybody else. What matters is that it’s known what to do.

OK, so we have our risk well-defined. What now? Now it’s essential to manage those risks. All of them? Definitely not. We rather don’t want to think what would happen when UFO came, because it won’t come. We don’t want to spend time analyzing what will happen when fly hits the car, because nothing will happen. At least in our lives. We need to measure somehow which risks are more important than others, so we count risk exposure. We get exposure by multiplying impact the risk has on us by probability that risk will happen. Impact of kidnapping the driver by UFO is great (close to 100% of scale), but the probability is… hmm… lower than zero. Probability of hitting some flies is close to 1 but I don’t think it will have any impact worth mentioning. At least for us. Possibility of car breaking down is rather low (but not zero) and impact is high, so exposure will be at some level. It’s more important issue to manage than two previous. Discuss only few positions from the top of the list. The rest is less important. If you’ve tried to manage all of them you wouldn’t have gone anywhere.

Who should decide about levels of probability and impact? Everyone’s invited. The driver probably isn’t an oracle in case of servicing car, and for sure he doesn’t know anything about flies’ life. Every member of the team should make his own vote. Then, exposure of the risk is counted as average of everyone’s exposures of that particular risk. Now, after sorting risks by exposure, we know what is perceived as greatest danger to the journey (or the project) on the very moment. Now, go implement your plan to avoid the risk. Go overhaul your car.

During journey threats can change. With perfectly serviced car exposure of materializing the risk of broken vehicle is very low. Now another position will go to the top of the list. Maybe it’ll be a child, who haven’t gone to WC and now exposure of dirtying upholstery on the back seat goes up. Minute after minute. How would you know that? By evaluating your risk on regular basis. It depends on project size and its stage, but generalizing a bit I find weekly evaluations working well. Make them not only on planning stage (preparations to journey/project/whatever) but during implementing phase also. Don’t be surprised if top 3/5/10 list changes when focus of a process is altered.

Easy? Easy! A piece of cake. That’s so natural. We do it everyday in the real life, why not try at work?

Series of MSF Basics won’t be very regular. I’ll try to write at least a post once every two weeks.

in: project management, software development

0 comments… add one

Leave a Comment