5 Ways to Minimize Disagreements between Stakeholders During Defect Reviews

As you approach the completion of your project, you will intensify the meetings with the clients and all stakeholders. As a final stage of the project, you will also need to document your experience and steps during this project so that you will be able to use that experience in your upcoming working challenges.

At one of the final defect review meetings, your expectations about the project outcomes could break down. There may be an issue between stakeholders that could paralyze your project, just as it approaches its completion. You could suffer the consequences of this problem or you can manage it accordingly. To be successful, you have to present the defect impacts to stakeholders and apply your management skills to resolve the problem.

1. Have regular defect review meetings

Since the testing team has uncovered the possible defects, the participants simply review a short presentation on each defect and decide whether to ignore the defect, fix it or postpone it until the project is over. Although this activity is performed near the end of the project, it can still generate some changes. Stakeholder conflicts over how to resolve the defects can lead to new critical project change decisions reflecting on the scope and schedule.

You must me ready for a successful resolution by getting the facts before making a decision. If you don’t make this step, the process may become victim to the stakeholders using their status, power, voice or threats to make the decision. You should envision the impact of the defect on the users (clients) and how it can reduce the expected business benefits of the project.

2. Understand the stakeholder’s opinions about the defect

It may depend on how often they use the functionality, or how many transactions are affected. Some stakeholders will see the defect as critical while others may feel that a defect is much less effective.

The changes in the environment caused by a defect may slow down a large user group or frustrate a sensitive group of customers. You should hear the stakeholders that appear to understand the impacts on the system behavior, once the operational system is analyzed and tested. 

You have to return to the system requirements documentation to see how the requirement being tested in the system was prioritized. You can analyze the priority of the requirement to resolve the conflict. This method is less helpful when the defect turns out to influence a smaller part of the overall requirement.

3. Make sure your definition for defect severity is clear to everyone

You have to decide what defects must absolutely be fixed before putting the system into production. Not every defect will disturb the project; some amount of issues must be fixed, and for the others you can negotiate.

4. Ask the project sponsor to resolve issues or to be the final decision maker

In some projects, the project sponsor may not attend the defect review meetings, and you will need to provide a brief summary with facts and schedule the sponsor to attend the next defect review meeting, or set up a special meeting for the resolution. You will have to decide what will be done with the defects afterwards.

5. Reach a consensus among all stakeholders by promising to fix certain defects as a priority in the next project/release

You should be careful, however since such an agreement can be made early in the project context, but not be fully considered on a higher level in the organizational project roadmap or portfolio management process. So the fixes may not possibly be so fast. If you are the individual who looks at a stakeholder honestly and says that a defect fix will be completed in a prioritized way and it does not come to pass, you could ruin your credibility.