The simple differences between product risks & project risks
Going into the subject of Test Project Strategy and more specifically around MTPs there are 2 points where we are not always sure what to do and what are our responsibilities as testers and test managers:
Product Risks & Project Risks
The first step is to understand these are 2 different entities:
Product Risks are areas in the AUT where there is a high risk you will find (important or numerous) defects, usually due to changes or other internal factors.
Project Risks are situations that may or may not happen (risks), if they materialize they usually cause delays in the project’s timelines, and the source of these risks may be internal or external.
Product Risks
As testers one of our tasks is to manage Product Risks.
We are paid (at least in part) to be aware of all Product Risks, to make sure the rest of the project team is also aware of them, and to coordinate this information with Project Management to make sure our schedules are taking these risks into account.
In addition, we are expected to plan our testing strategy based on these risk, scheduling more tests (and earlier tests) on areas with higher risks in order to find these issues faster.
My preferred method for handling Product Risks starts by listing them as part of my MTP and reviewing them with all the Project Stakeholders. During these reviews I try to get inputs into the relevance of these risks, as well as information about additional risks I may be unaware off. Once the project starts we review and update all product risks as part of the coordination meetings with the rest of the project team.
Examples of Product Risks are:
- Complex features affecting multiple areas of the existing product, like an upgrade/migration of the system.
- New Technologies used in the product; for example a new DB server, a new programming language, a new integration, etc.
- New Developers or Development Teams, who may lack experience and thus pose a higher risk to the existing product.
- Tight Schedules, that make people work in a rush and commit more mistakes.
Project Risks
The responsibles for Project Risks are the Project Managers, who are also in charge of the project’s schedule. The QA, as part of the overall team, is responsible for the Project Risks within our work areas.
Project Risks are usually managed in an Excel Sheet (or Google Docs Spreadsheet) where we list and manage all the risks for the project. For each risk we collect and manage the following information:
- Risk Name & Description
- Risk Index (we use this field in order to sort our list) – calculated by multiplying its probability by its consequence
- Risk owner
- Date of relevance – when does the risk starts been relevant and prevention actions can start taking place
- Prevention Actions – how to avoid this risk
- Contingency Plans – what do we do if the risk materializes
The most usual project risks related to the QA & Testing work are:
- Delays in the delivery of the AUT for testing
- Lack of technical knowledge on specific areas of the product
- Lack of testing environments and/or data that effectively simulate real customer usage
To sum things up...
Risks are a big part of any manager’s work. We are expected to be in the lookout for the things that may happen and prepare accordingly.
Most of the task related to Risk Management are not complex but they require good understanding of the project and product as well as the strict discipline required to keep following and managing these risks throughout the whole lifecycle of the project.
