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.
etc

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:
1. Risk Name & Description
2. Risk Index (we use this field in order to sort our list) – calculated by multiplying its probability by its consequence
3. Risk owner
4. Date of relevance – when does the risk starts been relevant and prevention actions can start taking place
5. Prevention Actions – how to avoid this risk
6. 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
etc.

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.

2 Responses to The simple differences between Product Risks & Project Risks

  1. PM Hut January 24, 2009 at 2:00 pm #

    How do you usually handle the following:

    – Lack of technical knowledge on specific areas of the product
    – Lack of testing environments and/or data that effectively simulate real customer usage
    etc.

    Is it handled by the Project Manager/The QA Manager, or both?

    Btw, I suggest you take a look at this short article about the effects of poor project management on testing, it is very relevant to your post.

  2. Joel Montvelisky January 25, 2009 at 10:35 am #

    Hi PM Hut,

    I would consider both of the risks you listed here as project risks and thus they should be handled by the manager in charge of the operation (in this case the QA Manager).

    Obviously is there is a Project Manager he/she should make sure all project risks are handled, but the responsibility goes to the technical manager.

    BTW, nice article. I specially agreed with the part that testing gets pushed since timelines are the top-most priority of some projects, and many times preced even quality…

Leave a Reply

Shares