Not many software engineers manage risk and even fewer know how to do it. It really is a shame because managing risk makes it much easier to set deadlines, meet deadlines and track progress. It doesn’t even take very long!
What is risk? It is the potential for something to go wrong. We already know a lot about risk from our normal lives. We know that something really bad that is unlikely to happen can be about as risky as something that is somewhat bad but is decently likely to happen.
Strangely we don’t always apply this thinking to our software projects and we are likely to make a list of the work that needs to be done for the project, add it up and declare “The project will take 2 months”. If someone were to then ask “What if something goes wrong, how long would it take then?” we would probably look blankly at them and ask “What is going to go wrong?” Luckily other people have already done the cataloging of software project risks for us!
In their book “Waltzing with Bears: Managing Risk on Software Projects”, Tom DeMarco and Timothy R. Lister performed postmortems on hundreds of software projects to learn what factors impact the success of software projects and how those factors can change project completion dates or cause project cancellation. They identified 5 risks that they thought should be considered as part of planning any software project:
- Schedule Flaws: Work sizing is incorrect
- Turnover: People leave the project
- Inflation: Features are added to the project after initial sizing
- Specification Flaws: Consensus is not reached by the stakeholders
- Productivity: People sometimes work at different speeds
Do any of these sound familiar? I know they sound really familiar to me. Just thinking about all of these as part of any project planning process already puts you in the 10% of software project risk managers…but if you read on we can make it to the top 1%!
DeMarco and Lister have a risk management Excel spreadsheet on their website (https://systemsguild.eu/riskology), but luckily for you I have updated it to a Google Sheet that you can copy here. Their website has a manual, but here are some basic instructions:
- Make a list of all the work that needs to be done to complete the project
- Estimate all of the work items and add them together to get your most optimistic project duration
- Enter your project start date and most optimistic end date in the Simulation Control sheet
- Eyeball the 500 scenario histogram in the Simulation Control sheet and decide what deadline you feel comfortable committing to. Different people have different levels of risk tolerance and that is OK
You are now a great risk manager! This process is oversimplified, but it works because DeMarco and Lister decided approximately how risky each of the five risk factors are for a normal project. Your projects may not be normal, but it is best to assume that they are until you have evidence that they are not. If you do want to tune the spreadsheet more to your specific needs, you can change the best case, average case and worst case penalties for each risk factor in the yellow cells of the RF1-5 sheets.
As your project goes on you will be able to see if any of the big 5 risk factors do occur. If they don’t then lucky you! If they do then at least they were factored into your deadline, but if everything goes wrong at once there is not much you can do. Risk management is an art, not a science. By incorporating risk into your planning process you will be able to consciously manage it rather than ignore it and hope for the best.
Leave a Reply