Quality Management, Blurred: How PMI Quietly Redefined “Assurance”
- Bill Holmes
- May 29
- 3 min read

“If you can’t describe what you are doing as a process, you don’t know what you’re doing.” W. Edwards Deming
“You can’t control what you can’t measure. You can’t manage what you can’t define.” Tom DeMarco
One of the strengths of the PMBOK® Guide Sixth Edition was its clarity — especially when it came to quality. You knew where the roles sat. You knew what was process-focused, what was product-focused, and what belonged at the organizational level.
But with the Seventh Edition, PMI swapped precision for principle. And while the follow-up Practice Guides attempt to fill the gaps, one thing has gotten increasingly fuzzy: the meaning of Quality Assurance.
Let’s break down what changed, what PMI tried to fix, and why the lines still aren’t as clear as they used to be.
The Sixth Edition: Clear Roles, Clear Layers. In the Sixth Edition, quality management followed a familiar, structured path:
Plan Quality Management — define standards and how to measure them.
Manage Quality — integrate those standards into project processes. This function included quality assurance activities at the project level.
Control Quality — inspect deliverables to ensure they meet requirements.
Crucially, Manage Quality was positioned as the internal assurance mechanism within a project — making sure we didn’t just inspect quality into existence at the end, but built it into our methods from the start.
At the organizational level, however, Quality Assurance was broader — focused on enterprise-wide process consistency, audits, compliance frameworks, and governance oversight. This wasn’t just semantics; it shaped how organizations staffed, reviewed, and supported project work.
The Seventh Edition: Principle Over Process Then came the Seventh Edition — a shift to performance domains, backed by principles and a less prescriptive model. The language around processes was reduced, and the previously understood separation between project-level and enterprise-level QA vanished from view.
The term “Quality Assurance” was now frequently used as a stand-in for “Manage Quality.” With that move, the distinct meaning QA once carried — especially as a broader governance function — became diluted.
The Practice Guide: A Partial Reset Recognizing that many professionals still needed the process guidance, PMI released the Process Groups: A Practice Guide — essentially a modern addendum to the Sixth Edition’s process-based clarity.
The guide restores Plan, Manage, and Control Quality processes — including many of the same tools and techniques seen in the Sixth Edition. But here's the catch: even in the Practice Guide, PMI continues to use “Quality Assurance” interchangeably with Manage Quality — reinforcing the idea that QA is a function that lives only inside the project, executed by the team.
In other words, while PMI put the process model back on the table, they didn’t bring back the organizational layer of Quality Assurance — the one responsible for cross-project consistency, compliance, and oversight.
Why This Matters
Responsibility gets murky: Is QA the PM’s job? The team’s? The enterprise’s? PMI’s shift implies it’s all internal to the project now.
Governance gets lost: Without acknowledging QA’s role outside the project, organizations risk treating quality like a delivery detail, not a structural safeguard.
Training gets harder: We’re left explaining what QA used to mean before explaining what PMI currently says it is.
Final Thought: Blurred Terms, Real Consequences The PMBOK® Guide Seventh Edition and its companion Practice Guides aim to give us flexibility — and that’s not a bad thing. But flexibility isn’t a substitute for clarity.
When you use “Quality Assurance” as a proxy for “Manage Quality,” you flatten two very different layers of responsibility. One is about building good processes into a project. The other is about ensuring those processes work across the organization.
If PMI won’t re-draw that line, practitioners still need to — because real quality doesn’t just happen within a project. It happens because the organization made it a priority.
Need help explaining this to your team or translating it into your governance model? I’ve been through this evolution with clients and students — and I’d be happy to share what actually works in practice.
Coda
I teach hundreds of students a year, and a central theme of all the classes is "data driven decisions". We are to gather data, conduct unbiased analysis and make recommendations based on a clear eyed analysis of undisputed facts! However, in my 33 year career, I don't recall EVER doing that! My boss would form an opinion, and my job was to find a way to support the decision through both action and analysis. If I found that the data indicated a different, better approach... Well, you know what happened.
"Quality" falls under the same heading that "Safety" does- The processes associated with QA/QC, as they are in safety, are embedded into every workflow process at all levels of the WBS/CBS and at all 4 levels of responsibility. https://build-project-management-competency.com/1-4-1-5-unit-5/