The Tool and its Use
The spreadsheet is available for download here:

Download risk_assessment.xls

It does not require macros to run. It contains ten tabs that each address a common risk area on software projects. Each tab has a number of questions about your project, you answer the questions by selecting the response that best fits your project from the drop down list in column “C”.

As you go, a risk severity score for that category is calculated and an overall risk score tallied for the project. There is an eleventh tab where you can optionally enter your own project specific risks if you wish. Then, on tab 12 the results are displayed. An example for a fictitious project “Alpha” is shown below:

Here we can see that our score for the risk area addressed on tab “1 – Size and scope” produced a score of 62 out of a possible 108, giving a “Yellow” risk flag for than category. (Risk scores below 40% are rated “Green”, 40%-70% are “Yellow” and score over 70% are rated “Red”). The score for tab “2 – IT Tools and Methods” scored 30 out of 93, giving a “Green” risk flag. Likewise tab “6 – Business Process” was flagged as “Red” a warning sign that the project carries a lot of risk in this area.

Column 12 in the risk profile graph shows an overall score for the project; in this case 418 out of a possible 839, giving the overall project a “Yellow” status. I worked for a consulting company in the UK that used a similar model to help determine the seniority of project manager that should be assigned to a project. Back then I was assigned to “Green” and “Yellow” projects, they called in the big guns for “Red” projects.

Now I believe the smarter thing to do is to try and find ways to chop large “Red” projects into multiple “Yellow” or “Green” projects, or find ways to vary the scope or approach so that “Red” projects can be reconceived as lower risk projects, but this is not always possible.

Limitations
Remember that this is just a tool and a fool with a tool is still just a fool. It is designed to help you think about the various risks on your project, it should not substitute thorough risk analysis involving a wide variety of project stakeholders. Typically a risk assessment on an agile project would include the following activities:

• Brainstorming possible risks with the development team and other interested stakeholders
• Reviewing previous project risk lists and issues lists for potential risks on this project
• Analyzing previous project retrospective reports, looking at the “What did not go well?” or “Areas for improvement?” suggestions for clues to potential risks
• Analysis of the user stories or features identified to date, to determine if any of these carry significant risks
• Analysis of the “Impediments to progress / blockers” items raised in daily stand-up meetings, these items can be project risks or precursors to potential risks
• By using standard risk lists and profiles (such as this tool) to ensure common risk areas are examined

So, tools like this spreadsheet should obviously not be used as your only risk assessment method. Also some of the questions are now a little dated. The IEEE source I took these from needs refreshing in the fields of hardware technology risk, and bringing up to date for emerging trends such as closer collaboration with users or offshoring. However it remains better than nothing and since you have the framework for the tool at your disposal, there is nothing to stop you updating it.

Also, I would like to point out that it is not as comprehensive or sophisticated as professional risk tools on the market. If you have access to commercial tools I would forget this and use those instead, the tools I have used are extremely valuable.

That said, if your current risk assessment process is ad-hoc and varies from PM to PM, a simple tool to address the common risk areas could be a great starting point.