When you read the title of this post, please be certain to focus on the phonetics and not the spelling of the title. With me? Ok, let’s proceed.
Risk management is pretty simple when you think about it. Microsoft has defined a sick management process that is part of both MOF and MSF, and it looks like this:
I love this picture – it really shows what you need to do and when. But you can boil down the essentials of risk management even further:
- Figure out things that could go wrong – these are your risks
- For each risk, figure out how likely it is to happen
- For each risk, figure out how bad life will be if it happens
- Multiply these two together to find the highest priority risks
- For the highest priority risks, figure out what actions you’re going to take to keep them from happening
- For the highest priority risks, come up with a plan to minimize the damage done if the actions in step 5 don’t work as planned
This makes sense, right? It’s amazing how often you can take small steps early on that prevent big project-threatening problems later on. Many people (and many software development organizations) still don’t see this, however – they think that people who focus on risk early are “being negative” when in fact that they’re simply being proactive.
Why do I mention this today? Well, I’ve run into a problem where someone (no names will be named) has lost around four (although some might say seven) days’ productivity when asking for a little information could have reduced this to an hour or less of lost time. The good news is that I now have a little .NET utility that generates a DTEXEC.EXE /VALIDATE batch file for all of the packages in a project, a solution or a file system folder and its sub-folders. It’s simple, handy and proactive, and it has that certain someone back on track with (cross your fingers!) no more lost time. Now back to work…
 This is generally measured in percentage.
 This is generally measured in pounds of poop that will hit the fan.
 The resulting figure is measured in poopercentage, which is a unit rarely encountered outside risk management, but you can simply think of it as a number if you’d like.