What Does Quality Actually Mean on a Project?

Ask ten project managers what “quality” means and you’ll get ten different answers. Some will point to the sign-off checklist. Some will say it’s about meeting the client’s requirements. A few will mention ISO 9001. And at least one will quietly admit they’re not entirely sure — they just know it when they see it.

I’ve been there. Early in my career, I treated quality as something that happened at the end of a project — a final review, a UAT sign-off, a tick in a box. It wasn’t until I started working with formal quality management systems that I realised I had it completely backwards. Quality isn’t a destination you arrive at. It’s the road you build as you go.

So let’s get back to basics. What does quality actually mean on a project?

The Textbook Answer (and Why It’s Not Enough)

The PMI’s PMBOK Guide defines quality as “the degree to which a set of inherent characteristics fulfils requirements.” ISO 9000 puts it similarly: quality is the “degree to which a set of inherent characteristics of an object fulfils requirements.”

Both definitions are accurate. Neither is particularly useful on a Monday morning when your stakeholder is unhappy and you’re not sure why.

The problem with the textbook definition is that it assumes the requirements were correct in the first place. In my experience, that’s a dangerous assumption. Requirements get written in a hurry. They get interpreted differently by different people. They evolve as the project progresses. And sometimes, what the client asked for and what they actually needed are two very different things.

This is where the concept of fitness for purpose becomes essential. A deliverable can meet every documented requirement and still fail to deliver value. A system can pass every test case and still frustrate the people who use it every day. Quality, in the real world, means the thing we built actually does what it was supposed to do — for the people it was supposed to do it for.

The Four Dimensions of Project Quality

Over the years, I’ve come to think of project quality as having four distinct dimensions, each of which can fail independently:

1. Conformance to Requirements

This is the textbook definition — did we build what was specified? It’s necessary, but not sufficient. A project can conform perfectly to its requirements and still deliver something that nobody wanted.

2. Fitness for Purpose

Does it actually work in the real world? Can the end users do their jobs with it? Does it solve the problem it was designed to solve? This is the dimension that gets missed most often, usually because we stop asking questions once the requirements are signed off.

3. Reliability and Consistency

A quality outcome isn’t a one-off. It performs consistently, under normal conditions and under pressure. This is where risk management and quality management intersect — because a system that works 95% of the time has a 5% failure rate, and in some industries, that’s catastrophic.

4. Value Delivered

Ultimately, quality is about value. Did the project deliver what the organisation needed? Did it justify the investment? Did it move the needle? This is the dimension that connects quality management to business strategy — and it’s the one most project managers are least equipped to measure.

Where Quality Goes Wrong on Projects

In my work across SAP implementations, infrastructure upgrades, and RTGS system migrations, I’ve seen quality fail in remarkably consistent ways. It’s rarely a single dramatic failure. It’s usually a slow accumulation of small compromises.

Quality gets treated as a phase, not a process. When quality assurance is scheduled as a step near the end of the project, it becomes a filter for catching problems rather than a system for preventing them. By the time you find the defect, the cost of fixing it has multiplied several times over. ISO 9001 is built on the principle of prevention over detection — and it’s right. If you only consider Quality at the end of the process, it’s already too late.

Requirements are signed off without being understood. I’ve sat in requirements workshops where everyone nodded along and nobody asked the difficult questions. The document gets signed. The project proceeds. And six months later, the stakeholder says “that’s not what I meant.” Quality starts with clarity — and clarity requires courage to ask uncomfortable questions early.

Risk and quality are managed in separate silos. Your risk register and your quality management plan should be in constant conversation with each other. Every quality failure is a risk that materialised. Every unmitigated risk is a quality failure waiting to happen. When these two disciplines operate independently, you end up managing the same problems twice — once as a risk and once as a defect.

The definition of “done” is never agreed upfront. What does a successful go-live look like? What are the acceptance criteria? Who has the authority to sign off? If you can’t answer these questions before the project starts, you’ll be arguing about them at the end — and quality will be whatever the loudest voice in the room decides it is.

Quality Is a Leadership Decision

Here’s the thing I’ve come to believe most firmly after years in this field: quality is not a technical problem. It’s a leadership problem.

The technical frameworks exist. ISO 9001 gives you a robust, internationally recognised system for managing quality. The PMBOK gives you the tools. The processes are well-documented and proven.

What’s missing, in most organisations, is the leadership commitment to actually use them. Quality gets cut when the time or budget is under pressure. Quality reviews get skipped when the deadline is looming. Quality standards get quietly lowered when the client is getting impatient.

And then we wonder why the project didn’t deliver what we promised.

Quality isn’t aspirational. It’s foundational. It’s not something you add to a project when you have time and budget to spare. It’s the structure on which everything else is built. When you compromise quality, you don’t save time — you borrow it, at a very high interest rate, from your future self.

What This Means for You

If you’re a project manager reading this, I want to leave you with three practical questions to take into your next project:

1. Have we defined what “good” looks like — in terms the end user would recognise? Not just the technical specifications, but the lived experience of the people who will use what we build.
2. Where does our quality plan connect to our risk register? If they’re two separate documents that never reference each other, that’s a gap worth closing.
3. What would we have to stop doing if we took quality seriously from day one? Sometimes the most honest quality conversation is about the shortcuts we’ve normalised.

Quality management isn’t about perfection. It’s about intention — the deliberate, consistent choice to build things properly, even when it’s inconvenient.

That’s where the standard lives. And the standard is foundational, not optional.

Michelle Mills is a PMP-certified Project Manager and Quality & Risk Specialist with over a decade of experience delivering large-scale projects across financial services and technology. She writes weekly on the intersection of Project Management, Quality, and Risk at michellemills.co.za.