Anchor Every Project with Quality Standards

Quality expectations drive the effort that the project team must commit to verifying project deliverables and outcomes. If you skip the conversation about quality standards, you’re just guessing what “good enough” means for the project. In other words, if you don’t know the needed level of quality, you won’t know how much verification and testing you need to meet stakeholder expectations and requirements. The discussion and documentation of quality standards connects stakeholder needs, project activities, and verification/testing effort that contribute to satisfying the project purpose. Here are some tips for managing a project with a quality standards mindset:

• Document both requirements and the tolerance for error in quality standards. Effective descriptions of quality come from understanding what deliverables need to do and how much tolerance stakeholders have for something going wrong. For example, a word processing program and an air traffic control system can both be called software, but they come with vastly different expectations of quality.  Meet with key stakeholders early on to ask them what failure looks like and what the risk would be.
• Use the required quality level to determine activities in the WBS. More rigid quality requirements mean more design reviews, testing activities, and potentially sign-offs built into the schedule. On the other hand, higher tolerance for unexpected outcomes means the team can move faster and skip some testing and verification activities without increasing risk. A best practice is to review each quality standard and make sure that verification and testing tasks in the WBS are at the right level to build to, review, and test against those standards.
• Allow fewer verification tasks for low-risk deliverables to increase delivery velocity. When the cost of an error is low, such as a minor bug in a word-processing feature, teams can engage in lighter testing. That way, the project manager can purposefully calibrate verification activities to the actual risk. For example, with tight deadlines, identify lower-risk components and make sure the team doesn’t over-test their deliverables. 
• Ensure high-risk deliverables get rigorous verification before delivery. Air traffic control software is a clear example of a high-risk deliverable. An error isn’t an inconvenience; it’s a potential catastrophe. This level of consequence justifies extensive performance verification, redundant testing, and formal sign-off before release. The extra time and cost for these tasks aren’t overhead; they’re mandatory for managing risk. In addition, for all high-risk deliverables, schedule independent verification rather than relying solely on team-level testing.

Have you defined quality standards for requirements and deliverables in your projects? If so, have you evaluated your WBS to see if you’ve included appropriate tasks for verification and testing? If not, give it a try!

For more about quality, check out Daniel Stanton’s Project Management Foundations: Quality course.

Coming Up

I finished recording voiceovers for most videos in the new Project Management Foundations course. Recording live action is coming up. In the meantime, I’m working on video storyboards. A few weeks away from LinkedIn Learning taking over production work!

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 106,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________