Skip to content

Ensuring quality

Part of the Responsibilities section.

Quality assurance (QA) is an essential part of any project, and it is especially important for TPMs. TPMs are responsible for ensuring that the project meets its quality standards, and they do this by working with the team to identify and fix defects.

quality

Photo by Jon Tyson on Unsplash

There are a number of different QA activities that TPMs can do, including:

  • Planning: TPMs need to plan for QA activities. This includes deciding which activities will be performed, who will perform them, and when they will be performed.
  • Executing: TPMs need to execute QA activities. This includes performing the activities, such as testing the project's deliverables.
  • Reporting: TPMs need to report on the results of QA activities. This includes identifying any defects that were found and the steps that were taken to fix them.
  • Communicating: TPMs need to communicate with stakeholders about QA activities. This includes keeping them updated on the results of QA activities and getting their feedback on how to improve the QA process.

QA is an important part of the TPM role, and it helps to ensure that the project meets its quality standards. By following the tips above, TPMs can effectively manage QA activities and ensure that their projects are of high quality.

Here are some additional tips for TPMs on ensuring quality:

  • Set quality standards: TPMs need to set quality standards for the project. These standards should be clear, measurable, and achievable.
  • Communicate quality standards: TPMs need to communicate the quality standards to the team. This should be done in a clear and concise way.
  • Provide training: TPMs need to provide training to the team on how to meet the quality standards. This training should be relevant to the team's roles and responsibilities.
  • Monitor progress: TPMs need to monitor the project's progress to ensure that it is on track to meet the quality standards. This should be done regularly and systematically.
  • Correct defects: TPMs need to correct defects that are identified. This should be done in a timely and effective way.
  • Prevent defects: TPMs need to prevent defects from occurring. This can be done by identifying and fixing potential problems early on.
  • Learn from mistakes: TPMs need to learn from mistakes that are made. This can be done by conducting root cause analysis and identifying ways to improve the QA process.

Is there such as thing as quality that is too high?

When you're setting your quality bars you have to consider the cost of quality. The cost in terms of currency / budget, the cost in terms of time, and perhaps opportunity cost. When I worked on a big EA Sports video game we routinely shipped (released the product for sale to the public) with thousands of software bugs still present. It was untenable to fix them all given the time and budget constraints we had on the program. The good news is that were were excellent at triage: we prioritized the right bugs to fix to minimize negative impact on the player, the customer.

So be realistic with your quality bar. Face the fact that your program won't be perfect. But strive for "great enough" that you and your team are proud of what you deliver. And that it has a great chance to succeed in the market.

Building quality in vs. fixing quality issues

This could be a whole book unto itself but it's worth considering what you can do as a TPM to ensure that quality is built in to your program instead of having to fix quality issues later. In other words, a bug not introduced means a bug that doesn't have to be found, tracked, fixed, verified, and regressed. Whether automated, manual, or cultural, consider what you as a TPM can do to instill a sense of quality first in your team.

  • Great code reviews. Fair, balanced, exhaustive, and comprehensive code reviews can find potential quality issues before they are even committed to the code.
  • Self-testing. What can developers and other team members do to test their own work even before they submit it for a pull request and code review? Can they write a quick test harness? Can they think of outliers that would stress their code? Can they ask someone else to check their assumptions?

What else can you think of to proactively build quality into a program? Let me know with a suggestion or feedback.