« The Power of “I Told You So”
Project Risk Management: It’s Either Contingency Planning Now or Emergency Relief Later »

No Risk of Defects! Making Quality-Related Risks Actionable

September 20, 2007 | Author: admin | Filed under: Quality Management, Risk Management

No Risk of Defects! Making Quality-Related Risks Actionable
By Alan Koch, PMP - Global Knowledge Course Director

It never fails! While I am facilitating a Risk Planning workshop, one of the risks that a team member suggests during the brainstorming session is that there will be defects in the product. Later, when we are critiquing and consolidating the list, the team is surprised when I suggest that this one be dropped from the list!

The Project Management Body of Knowledge (PMBOK) defines a risk as “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.” The key word for this discussion is “uncertain.” Defects are a certainty, so this item does not belong on our risk list. In fact, we should be planning for the fact that there will be defects.

Does that mean that quality-related risks don’t belong on our risk list? Not at all! There are many potential quality-related risks, but we must be much more specific if we are to make them an actionable part of our risk planning.

Actionable Risks

Before we look at the quality-related risks that could potentially affect our project, let’s take some time to discuss why we do risk planning. The purpose of risk planning is to allow us to take action on the identified risks.

  • Some risks can be mitigated: We can take action to reduce their probability or impact.
  • Some risks require a contingency plan: They are so bad that we must plan ahead for how we will react to them.
  • Some risks can be transferred to others: We can purchase insurance against them.
  • Some risks can be avoided: We can restructure the project to eliminate them.

When looking for quality-related risks to our project, we must focus on a level that is actionable. We want to identify things that are concrete enough that we can identify discrete actions that would mitigate, transfer, avoid, or be appropriate contingencies.

Where Do Quality-Related Risks Come From?

Most quality-related risks are not initially quality-related at all. They usually have their genesis in other types of project activities and are realized only when a quality problem is uncovered. When you think back to the quality issues that you have experienced on prior projects, you will undoubtedly see that the majority of them were caused by some activity that has nothing whatsoever to do with testing or quality assurance.

Quality Risks from Project Communications

If our project must interact with other groups to get information that is key to our success, then we have a project communications risk that could impact product quality. For example, suppose our product, when complete, must coexist with a product that is being developed by another project team. In order for our implementation to work properly, we must exchange the necessary technical information with that other project team at appropriate points in the project.

In this scenario, there is a risk that some dependencies between the two products will remain unanticipated, resulting in significant time impacts and rework during system integration testing or, worse yet, at implementation! This is a very real quality-related risk that is actionable: we can mitigate it by instituting technical exchange activities and cross-project interface reviews.

Quality Risks from Technical Challenges

If our project is attempting a solution that has not been tried before, then we have a technical risk that could impact product quality. For example, suppose this is the first time a new programming language has been used in our shop. Most of our programming team will be climbing a steep learning curve on that language as the project progresses.

In this scenario, there is a risk that the programmers will misuse the new language’s structures and syntax, resulting in code that operates in unexpected ways. This is another quality-related risk that is actionable since it can be mitigated through formal training, good coding standards, and peer reviews of code by the team. We could also avoid this risk by using a language with which the team has more experience.

Quality Risks from Customers

If our project’s customer makes significant changes to the project scope or requirements, our team may be pressured to complete extra technical work in a constricted timeframe. For example, the customer may discover during the last phase of development that some regulatory requirement was overlooked, and it must be included for project success.

In this scenario, there is a risk that the engineering work will be compromised by the shortcuts that may be taken to complete the unexpected new work, resulting in defective implementation. This is a quality-related risk that is actionable. We can mitigate it through a disciplined change control process that ensures that undue pressure is not put on the development team, and through a quality assurance process that ensures that good engineering practices are followed, even under pressure.

Identifying Quality Risks

Brainstorming quality risks to our projects can result in good actionable risk plans. To ensure this is so, we must think not just about what has gone wrong in the past, but also about the root cause of those problems. Once we understand why we experienced those problems, we can name the risks that might show up on our next project, and do it in a way that will be actionable, and will help to ensure project success.

This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge delivers comprehensive hands-on project management, business process, and professional skills training. Visit our online Knowledge Center at www.globalknowledge.com/business for free white papers, webinars, and more.

© Copyright 2007, Global Knowledge. All rights reserved.

Share this article:
  • StumbleUpon
  • Digg
  • del.icio.us
  • Technorati
  • Reddit
  • YahooMyWeb
  • blogmarks

Related Articles

This entry was posted on Thursday, September 20th, 2007 and is filed under Quality Management, Risk Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories