Make an inventory of the potential risks to the project. Gather the project team together in early phases or iterations
of the project in order to create an initial risk list.
When you identify risks, consider 'what can go wrong'. At the broadest level, of course, everything can go wrong.
The point is not to cast a pessimistic view on the project, however; identify potential barriers to success so
that you can reduce or eliminate them.
More specifically, look for the events which might occur which would decrease the likelihood that you deliver the
project with the right features, the required level of quality, on time and within budget.
Using brainstorming techniques, ask each member to identify a project risk. Clarification questions are allowed, but
the risks should not be evaluated or commented on by the group. Go around the table until no more risks can be
identified. It might be useful for the team identify the potential risk sources, risk categories, and impacted
stakeholders - this could help the team identify potential new risks.
Involve all parties in this process, and don't worry too much about form or duplicates; you can clean up the list
later. Use homogeneous groups of people (customers, users, technical people, and so on). This eases the process of
collecting risks - individuals are less inhibited in front of their peers (in specialty and hierarchy) than in a
large mix.
Make clear to the participants that raising a risk does not equate in any way with volunteering to address the risk. If
there is any sense that raising a risk will result in becoming responsible for addressing it, no one will identify any
risks (or the risks they do raise will be trivial).
Start with a generic risk lists such as the Assessment and Control of Software Risks by Capers Jones [JON94] or the Taxonomy-Based Risk Identification established by the
Software Engineering Institute [CAR93]. Circulate the risk list: seeing what has been already identified often helps
people to identify more.
|