One of my former clients had a large IT organization dedicated to quality management. The chief information officer mandated that every project have a quality manager to ensure that the project adhered to sanctioned standards. When my team's project started, the quality manager gave us a long list of standards. As we looked through them, it appeared that many didn't apply to our project, or they were so vague we couldn't understand how to implement them. Many people assigned to the project dismissed the quality standards as busy work and simply ignored them. Others tried to understand how the standards applied to the project and made a valiant effort to demonstrate adherence. Nonetheless, while our project passed the quality standards review, it was a distraction to the team and didn't add much value.
Quality does matter
Despite that one experience, I am still a strong proponent of quality standards. They help tremendously when meeting expectations during product development and if the product has to be modified. But quality standards must not take on a life of their own, requiring incremental work to meet some standard with no defined, associated value. Yes, quality standards need to exist, and projects should follow them. But these standards must be available to all, practical, achievable, and believable. More important, the group needs to see the value that quality standards provide. If value can't be understood or demonstrated, the project team will have a hard time buying into and implementing the needed quality.
Top of Page
Guidelines for developing quality standards
How can you put in place practical, achievable, and believable quality standards? Consider the following guidelines as you embark on your journey:
- See if quality standards already exist in your organization. If you're in a large organization, chances are someone has already developed quality standards for the type of projects you manage. Ask peers, managers, and other stakeholders if the needed standards are in place. If you find any, consider adopting them or using them as a starting point.
- Set up a quality standards advisory board. Assemble a team from stakeholder groups that are affected by the projects you manage. Your goal here isn't to share the workload with this team, but to use them as advisors to help ensure that the quality standards you define are all you intend them to be.
- Understand how your stakeholders perceive quality. Conduct interviews with each stakeholder group to understand the expectations for deliverables. For example, for IT quality standards, you could discuss expectations with managers from usability, production support, and other key sponsors. Ask them what they think is needed to deliver a successful project. You may think this is an obvious question, but some responses may give you perspective about stakeholder values, and also what isn't important to them. Don't underestimate the power of these interviews: they can help to align your perceptions of quality with those of your stakeholders.
- Start with a template. There are lots of standard quality plans and templates out there, so you shouldn't have to start with a blank sheet of paper. Use a good, robust template with options to pick and choose from that apply to your organization and project.
- Develop a consequence for each quality standard. I like to call this the "Who cares?" test. For each standard you identify, develop a logical, thoughtful consequence that will occur if it is not met. If you and your advisory board can't identify a realistic outcome, or if the consequence is minor, consider revising or deleting the standard. It's too easy to throw everything into your quality standards list. More is not always better, so be sure to focus on what matters most.
- Evaluate the quality standards as a regular part of your project postmortem. Putting practical standards in place is a great first step toward meeting stakeholder expectations. So, to ensure that your quality standards continue to pay dividends, it's important to include a regular postmortem review. Ask questions such as:
- Were any quality standards ignored? If so, was the consequence significant?
- Was the product designed with the quality standards in mind, or were they applied after the product was designed and needed to be tested?
- Did the team take the quality standards seriously, or did they follow the guidelines because they had to?
Getting a good read on how project teams viewed the quality standards will help you improve these measures, and over time they will evolve with your organization.
Top of Page
Quality standards are an important component of your project management methodology. For measurements to be effective, they need to be practical, believable, and achievable. If you create quality standards that don't represent reality, your project teams will look for loopholes or ignore them entirely.
Top of Page
|About the author Lonnie Pacelli is a business owner, consultant, and author with over 20 years of experience in project management. He has worked with Fortune 500 companies including Microsoft, Accenture, Motorola, Hughes Electronics, AT&T, and Northrop Grumman, and successfully managed projects ranging from installation of complex information technology systems to small process improvements. He is currently CEO of Banzai Sushi in Seattle. Lonnie is the author of The Project Management Advisor: 18 Major Project Screw-ups and How to Cut Them Off at the Pass (Prentice Hall, 2004), The Truth About Getting Your Point Across (Prentice Hall, 2006), and Leadership Made Simple (Amazon.com, 2006).