Considering risk identification as an important part of project planning, and if working in an environment where projects are quite similar, having a checklist with a set of standard risks to be analyzed before opening every project could be a time-saving strategy.

I used to check the reasons for a project to fail, proposed by the several versions of the CHAOS report, but this can be tricky, since the report itself has been challenged from several points of view (e.g. The rise and fall of the chaos report figures).

Besides, in spite of the fact that having a list of the recurring risks shared between all the project managers in the company could be a great tool, keeping it coherent and updated from project to project could turn into a controversial burden since each project manager could have its own way to manage and analyze risks.

So, if its possible and useful, what steps should I need to take for creating and maintaining a shared checklist for recurring risks?

  • How many PMs are your focs group? Is there a knowledge management system in place? Is a working QM in place?
    – Tob
    Jun 22, 2015 at 18:27
  • @Tobias from 3 to 5 PMs depending on the season. Knowledge spread among several tools. QA area fully operative. Jun 22, 2015 at 20:44

5 Answers 5


Regarding your further details, it should be possible to settle such a checklist and keep it updated with little effort. If you can show the need for change.

This should be you first step. You need to identify the need for change in order to communicate the expected benefit. You should find some arguments why everybody should invest a (small) amount of time to

  • install the list
  • keep the list updated
  • apply the list

In addition you arguments should include a point where the PMs life gets easier :)

Then you could ask your PM colleagues to provide their experience to initiate the list.

Afterwards, QA should be you friend. They should see ways how to integrate the list in your existing processes (e.g. during lessons learned acquisition). There should be some kind of intrinsic motivation :)


Scan post mortem documentation. Scan past projects' risks and issues registers. Conduct several focus groups with project managers and practitioners and brainstorm. Review trade journals and industry reports.

I think building and maintaining the checklist would be extremely easy. What is difficult is getting people to use it for their upcoming projects. Getting past risk resistance is unbelievably difficult--optimism biases; Lake Wobegon confidence in their team and themselves; political agendas; bad things happen to other people's projects, not mine. Provide the checklist to an up and coming project team and you will get: whoever built this list was a naysayer and a no can do person.


Rather than focus on a checklist, begin by asking what process can be put in place to encourage a team to identify and plan for risk before a project begins.

Why focus on process first? Because you are correct in thinking that getting people to use such a risk checklist will be difficult. People are so flooded with information and data that it can often be ignored. Plus, who will maintain the risk database? Will there be liability if a risk is listed in the database, but not applied to a project that later fails? How easy will it be to search for applicable risks?

There are two processes for risk planning that I recommend: pre-mortems and FMEA.

Pre-mortems are a less formal process that I learned about through an episode of Freakonomics Radio. Fast forward to minute 20 of this episode to hear pre-mortems explained. The general idea is that team members are asked to imagine the project has failed in a massive way. Then, they're asked to imagine causes of failure. I like this approach because it engages the whole team and because it is very focused on risks relevant to the specific project being discussed.

FMEA, or failure modes and effects analysis, is a more formal and structured approach for risk planning. FMEA is typically conducted either for components of a product, or for steps in a service delivery or design process. For software, an FMEA might consider each feature the software is intended to perform. For each feature, likelihood of failure, cost of failure, and likelihood of failure detection are rated from 1-10. Ratings are used to assign each feature a risk score, for example 1 x 1 x 1 is 1, or a very low risk, and 10 x 10 x 10 is a 1000, a very high risk. Features are then prioritized by risk score so that the highest risk items can be identified and addressed.

With either approach given above, it may be useful to have a risk checklist as you described in your question. The checklist may help people to generate a set of risks relevant to a project being planned. However, the real impact comes from putting a system in place that encourages teams to conduct pre-mortem or FMEA style analysis before work on a project begins.


One idea to create and maintain a shared checklist for recurring risks is to perform a general “lessons learned” on the last several projects (good and bad ones/yours and several others). Use the ISHIKAWA / Fishbone diagram model. Identify the recurring issues that caused problems. Also, try to identify what “works” (a reverse ISHIKAWA).

You may consider a great source from Carnegie Mellon/SEI “Taxonomy Based Risk Identification” (google the term) which is old (1993), but has about 150 essential questions to determine risks for software projects. It works today.

You may want to consider “The Four Horseman of IT Project Doom” based on a study from 120 project managers (google the term and it comes up as a PDF). Tie this into a checklist. If you can, run the checklist on projects and have the sponsor sign off.

SOURCE: Used the ISHIKAWA on seven or eight IT systems (trying to rebuild after we were breached) project failures in a small IT shop and it was accurate (we had to buffer/sanitize before giving to senior management as a lot of issues were sourced from that level). We used the SEI taxonomy with a small PM shop on a small $2.8m project and it worked well; contractor used a spreadsheet to track questions and weight them – color coded risk as green/yellow/red.


I'm not sure of the best way to enforce compliance in your situation. However, you can find a large list of software development project risks in the appendix of this online manual -

Risk Register User Guide

It's a more comprehensive list than you will find in the CHAOS report (which only listed 10 risks, from memory), so you may find it helpful.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.