At a recent Q&A session I was asked: where could a person get their project risks? I stifled a smart-alecky answer that would have included driving to the grocery store, and decided that the question that was being asked was really: how do I go about recognizing and capturing risks? Perhaps a more boring question, but far more important. If I answered the first question the answer would have been that risks are generated by the interaction of the project with other projects, applications, the business, technology and world (risk categories) – pretty much the existence of a project could be considered a risk magnet. The answer to the second question is that once you have a risk magnet (a project) you will need to ask as many different people as is feasible to recognize the possible risks. The discussion of risk always appropriate, however the typical meeting/events and the types of people to consider in the conversation need to be planned. The discovery process typically follows the requirements/user story discovery process outlined below.
- Carve out time when you are developing the backlog and ask as diverse a group as possible to identify the potential problems that could get in the away of delivering the value promised by the project. Prompt the group to consider business, technical, operational and organizational factors. Diversity is incredibly important to inject different perspectives, so that the team does not fall prey to only seeing the risks they expect (a form of cognitive bias).
- Form a small team (consider the Three Amigos) to interview stakeholders that were not part of the planning exercise. Explain the project and use the same category prompts to generate a risk discussion.
- Gather risk data though surveys when the program stakeholders are geographically diverse. (Note: I have only seen this used well in very large programs with professional market research staffs)
- Interview customers or potential customers. Customer interviews are not generally used as a standalone risk discovery tool, but rather as a tool to gather requirements/user stories. However, piggybacking a few questions to solicit potential risks is useful to add a diversity of thought to risk identification.
- Periodically ask about risks either as an agenda item or as a follow-on to standard meetings. For example, I have seen teams that have successfully added a five-minute follow on to the last daily stand-up of the week in order to consider risks. A quick risk recognition session can easily be added to other standard meeting many projects have. Other standard scrum meetings that can be used to identify risks include: demonstrations, retrospectives and sprint planning. Each of these meetings will provide a different perspective on the project and the team therefore could expose other potential risks.
The baseline answer to the question of how can I recognize and capture risks is by involving all of the projects stakeholders in a discussion of potential risks. The process of collaborative discussion will help increase diversity of thought, reducing (but NOT eliminating) the potential number of unknowns – unknowns that could impact the projects ability to deliver value.