Articles

Does Quality Always Matter?

Does quality always matter? The simple answer is yes. Unfortunately, it’s not always a simple question. Quality is another constraint on a project and addressing it appropriately is critical to meeting stakeholders’ needs and for optimal results. 

Key Takeaways

• Quality is a constraint like scope, schedule, budget and cost, and sometimes it is less important than those other factors.
• Business priorities may dictate that a low-quality solution is what’s needed and that’s perfectly appropriate.
• If the team feels they can deliver a better solution without impacting other constraints, they must gain approval from key stakeholders — particularly the sponsor and customer.

PMI Picks offers the following insights:

Quality can have a significant influence on project outcomes, but it may take longer to achieve and come at a higher cost than lower-quality alternatives.

So, while organizations may be prepared to spend more money or add more resources to get a solution faster for a project, there are also instances where they are prepared to accept a lower standard to get that earlier release.

That’s especially common with software development, particularly mobile application development, where time to market is the driving factor behind everything. The attitude here is that if it functions it can be patched later. With continuous delivery and related DevOps concepts, that patching can happen multiple times a day if necessary.

There are other areas where quality will never be compromised such as safety-related solutions, financial and privacy products and so forth. These are areas where quality is the highest priority constraint. Adjustments are made elsewhere to preserve quality.

As project managers we must help our teams understand that sometimes other factors mean that the quality of the solution we are asked to deliver isn’t as high as we would like it to be. However, we must also help them understand exactly what that means.

When the specifications or requirements for a solution show that a lower level of quality is acceptable, they define the standard that might be met. For the project team, while this might represent the proverbial “low bar,” it is still important to ensure that target is met.

Put simply, just because the team isn’t being asked to build the “best” version of a product or solution ever, that doesn’t mean it’s okay to cut corners, fall short of the target that has been set or work with an uncaring attitude. The standard for quality is just another requirement like the features that are in scope and the team must deliver to that standard.