From manufacturing, to B2B services, to computer technologies, product teams often talk about the triple constraint. You know the one: “Fast, cheap, or good—pick two.” (Yes, we know that the third one is often scope, not quality; just humor us).
We often use it as a way to communicate to higher ups that they can certainly ask for all three, but there’s no way for a team to deliver on it.
What tends to get ignored, though, is how staff involved in project management are essentially being asked to balance the three priorities against each other. Just as there’s never a situation where you can hit all three (at least not reliably), there’s rarely a time when you can flatly ignore any of them altogether. Though product/project quality is the most common of the three to draw the short straw.
You don’t always have a surplus of time, resources, or skilled labor to throw at that conflict. But projects don’t just magically produce quality output without some help. So let’s see if we can’t provide a bit of guidance that might assist you in your efforts (without demanding too much from you).
What is quality management?
Let’s start by paying some of our SEO dues. After all, if we let the bots completely dominate the content marketing industry, it’s only a matter of time before they move on to bigger and better things. Like world domination.
Like so many terms in business, “quality management” can be a reference to more than one thing, so for clarity’s sake, we’re going to lay out some definitions. First and foremost, we’re not referring to “Total Quality Management,” or TQM. That movement was a response to the rising success of business in Japan during the 70’s and 80’s. Western businesses started to worry when companies like Toyota started leveraging methods like lean manufacturing to achieve higher quality at lower costs.
TQM died out in the early ‘90s, with most of the initiatives and approaches that were effective being absorbed, subsumed, or superseded by the International Organization for Standardization, and their quality management systems.
These days, quality management is a broader term referring to the methodology of pursuing increased quality within a business context. It’s an umbrella termthat encompasses everything from specific frameworks used as a quality management system, as well as distinct business functions like quality assurance and quality control.
Quality management is generally accepted to have four aspects: planning, assurance, control, and improvement. Not every organization leverages all four, but as far as business terminology, anything in these categories would fall under the larger linguistic umbrella.
Basically, quality management is the “quality” analog to strategies designed to improve speed/efficiency (like Agile development), and minimize costs (e.g. just-in-time inventory). In some cases, like lean manufacturing mentioned above, a particular framework may function across all three constraints.
Triangular tug-of-war
Whoever first picked the word “constraint” was certainly onto something, weren’t they? Each person on the team, no matter the project, is only human. And even the most powerful machines have hard limits. It is, as they say, a zero-sum game. Feel free to raise your hand if you feel like you’re winning said game, but we won’t hold our breath.
Dynamics differ from project to project, but it’s not uncommon for project managers to act as both facilitator and coordinator, without actually being directly involved in the production. You’re handling logistics of labor the way a…well a logistics team would plan and schedule the shuffling of physical assets.
Where does this leave you? Well, kind of like you have three different groups of “bosses”:
- The people in finance, who want things done cheap
- The managers and supervisors, who want the work completed quickly
- The customers, who want the product they’re paying for to be the best
Beyond that, the hard limits on these constraints will usually be defined by people other than you, such as when executives set strict budget limits, clients set hard deadlines, or production teams needing something as silly as meal breaks or sleep. Which, of course, leaves you stuck trying to create quality products with one metaphorical hand tied behind your back.
Still, who doesn’t want to be proud of the work they’ve done, or to be part of a project that demonstrates high levels of skill, workmanship, and quality? So as you play this zero-sum game, you’ll have to try to make the resources at your disposal stretch as best you can, if you want to hit quality targets.
Without, you know, going over budget, burning out overworked staff, or dragging projects out further than is permissible.
Learn more about the five phases of every successful project
A quick and dirty guide to quality management planning
Like the triple constraint itself, there are a few foundational realities you need to balance as a project manager.
Prioritize progress over perfection
Try as we might, there’s no such thing as zero-error processes. There will always be goofs, mistakes, glitches, defects, and the like. The goal isn’t elimination, but mitigation, monitoring, response, and continuous improvement. If there is a finish line in this race, it’s “best it can be,” not “without flaw.”
What does that look like in practice for project managers? In large part, it’s a matter of choosing the right success metrics (which we’ll talk about more below). Remember those three sliders of value: quality, speed, and financial efficiency. You’ll want to use those (and how they’re weighted in the value judgments of the management team) to select the data points you want to collect, and then use that data to measure effectiveness in three areas:
- Do our processes successfully build the product/products?
- Do the products work as intended/deliver on promises?
- Do our customers/target audience report satisfaction with our product?
Now, here’s where the rubber hits the road: “effectiveness” and/or success is not a pass-fail test. You’re measuring degrees—to what degree do we build our products on time, under budget, and to specifications? To what degree does the product perform as desired, and to what degree are customers satisfied with it?
Take customer satisfaction as an example. Maybe you’re measuring things based on reviews and ratings (though that method leaves a bit to be desired). Maybe you’re tracking customer retention rates. Maybe you’re tracking sales growth. Whatever you’re using as a meter stick, it’s not going to be 100%.
Instead, there will be some combination of “Yes!”, “No!”, and “eh.” The negative values aren’t failures; they’re diagnostic data, and they can be used to help guide efforts to optimize, improve, refine, and otherwise try to improve success rates. Even then, though, the objective is still not to hit 100%. It’s to reach an attainable and acceptable threshold, and then make continual adjustments to maintain that performance.
Learn from critical feedback
There’s no pleasing everyone. There will always be at least one person (and, more likely, a whole contingent of people) who will be unhappy with the results of the project. It may be customers/clients, executives, or even yourself. That’s ok, and it’s to be expected. Remember, negative feedback doesn’t equal failure. It’s diagnostic data. So it’s best to have systems in place to identify why they’re dissatisfied.
We used customer satisfaction as an example in the above section, much of which is also relevant here. But you may or may not have a finger in the pies responsible for actually managing quality assurance, making adjustments to products or target markets, or similar factors. If that’s the case, the data points we’re discussing here are largely for those who will be handling those aspects.
For you in project management, though, anything related to the process itself will probably be under purview, and those are things you can focus on. That means that, at least as far as customer satisfaction, your “customers” are internal—managers, production teams, and other stakeholders.
That means your goal here is to identify obstacles in the project process that make it difficult for teams to build for quality, work efficiently, and complete things on time. You’ll be mediating between the management team (who will likely be setting some of the standards for those values), and the production staff that has to meet the targets.
Consult the staff on what’s creating the biggest headaches, and what ideas or solutions they think would be the most helpful. And confer with the big wigs on what’s flexible, what’s not, and the realities that the production teams are dealing with. Like the above section mentions, there won’t be 100% success in every area (or, more likely, any area).
What you’re seeking is functional, successful compromise, ideally leading to external customer satisfaction.
Expect to fail (and plan accordingly)
There is no, and never will be, a single, surefire path to ensuring quality. And even if there was, it wouldn’t survive day one of production. As the old military adage goes, “no strategy survives first contact with the enemy.”
But what might sound like impending doom at first is actually a reassurance. Bumps in the road are not just possible, they’re basically guaranteed. Incidentally, so are moments where you’ll have to make changes on the fly, saving more formal revisions for when they can be properly scheduled and accommodated.
In other words, you can rest easy knowing that perfection wasn’t actually ever on the table, no matter what anyone on the team contributed to the effort. Even with the most effective systems or approaches, there are plenty of snags you can hit, and wrenches that can end up in the works. There will always be retrofits, adjustments, repairs, and a certain amount of slate-wiping. Plan as best you can, and build room into those plans to leave some margin for a few of those errors.
After all, between a well-prepared realist and a poorly rehearsed optimist, the former nearly always sees better results in the end.
Planning quality into your project planning
Start with the standard
It’s hard to evaluate something for quality if you don’t know what qualifies as good or bad. So, as common sense as it might sound, we recommend that you start by establishing standards.
Some of this may have already been done for you. Industry standards, regulatory guidelines, and legal constraints are factors in a host of different contexts, and we’d be remiss if we didn’t encourage you to adhere to such mandates.
Once you’ve accounted for these (or determined that they’re not applicable), it’s time to look at your standards:
- The standards of your organization.
- The standards of your team and the relevant experts you have on staff.
- The standards you personally bring to the table from private and/or professional experience.
Lastly, you’ll want to be honest with yourself about how attainable any of these standards are. Some will be idyllic and borderline theoretical. Others will be aspirational—possible, but difficult or unlikely to be achieved. You’ll have realistic standards, ones that can reasonably be attained either currently or with a number of feasible adjustments.
At the bottom will be your threshold for “minimum viable product” (yes, we know that’s not what MVP typically means in a product context, but we’re rolling with it here, and so should you). These will be the absolute floor, below which the product or project is genuinely dead on arrival. Products that don’t function or fall apart on first use, services that fail to actually fill their core purpose, that sort of thing.
With your standards so organized, you’ll be prepared to judge not just if the project was a success, but also to what degree it was successful.
Follow the numbers
Where possible, leverage historical data to inform your plans, strategies, and decisions. Trends from analytics and other records may highlight areas that need more (or less) attention from your quality management efforts.
Different projects have different objectives, and different markets want different things. If you have historical data to refer to, you may be able to conserve resources by minimizing effort in areas that don’t add value, so they can be redirected to bolstering quality where it’s actually desired.
Get organized
Once you have plans and processes in place, quality management effectively becomes its own project, more or less. Anyone who’s had to run a kanban board, manage Gantt charts, participate in scrum sprints, or the like is probably well acquainted with this already. Both you as the project manager, and the team you’re helping to coordinate, will have an easier time reaching objectives if progress is tracked via an external medium.
What’s more, you’ll see more success if you have reliable ways to monitor, record, review, and optimize the quality management processes themselves, not just the processes they seek to oversee.
Assign ownership
If you’ve been in PM for any length of time, this should be nothing new. But it’s important for someone to be in charge of and/or responsible for the progress and measurement of these efforts. Things easily get lost in the shuffle if there’s no one in particular who’s supposed to ask “Hey, where are we at with ‘X’?”
Critically, ownership doesn’t always have to be yours. There are plenty of situations where it’s feasible—optimal, even—to let someone else wear the hat. It gives production-level staff opportunities to practice leadership/collaboration skills, and gives them a stake in the quality of the end product, as success here reflects positively on them (and vice versa).
Learn from both victories and mistakes
We’ll end with the reminder that the only true failure is failing to learn from unsuccessful efforts. Beyond that, the faster you can learn—that is, the faster you can identify problems and respond to them—the faster you can reach an acceptable win state.
As mentioned a few times above, whether something works or it doesn’t, that’s just another data point, helping you identify where to double down and where to tinker a bit more.
Working in project management, you may not always be in a position to impact much beyond reporting on things that affect product quality and project efficiency. But even in these cases, you may be able to provide critical information that can be used to refine, iterate, or pivot as needed.
Sometimes, the most valuable data points are the ones that help identify what went wrong, and point to possible solutions.
