Quality Management in Projects: Planning for It, Building It In, and Making It Stick
When I started working on railway projects, I noticed something interesting. We'd successfully deliver sites - track laid, trains running, all technical milestones hit. But handovers were taking months to complete, sometimes even stretching into years.
Looking closer, I realised the maintenance teams, the people who'd look after these assets for 20+ years, weren't being brought in until the final stages. We were all doing our jobs well, but working in silos. What could have been early conversations became last-minute negotiations.
Teams would move on to new projects while handover details were still being resolved. I knew we could do better. How do you shift from just delivering infrastructure to delivering something the end user genuinely wants to accept?
The answer came through understanding what quality management really means. Not just ticking boxes or following procedures, but something deeper. Let me share what we discovered.
Why Quality Actually Matters
Industry studies show that rework due to poor quality averages about 5% of project cost. On a £10 million project, that's half a million pounds potentially wasted.
The APM Body of Knowledge defines quality management as "the ability to ensure that outputs are delivered in accordance with requirements." But let me break it down in simpler terms. Quality management means your outputs meet the needs of customers, users, and stakeholders. They align with industry standards and organisational policies. They comply with regulatory or legal requirements.
This includes getting the technical details right first time: proper specifications, accurate calculations, correct installations - as well as managing the process and people effectively. Most importantly though, it means creating a culture of quality, where the whole team shares responsibility for doing things right.
The Four Stages of Quality Management (What They Really Mean)
According to APM, quality management rests on four components: Quality Planning, Quality Assurance, Quality Control, and Continuous Improvement.
Here's what each looks like in practice. I'll explain with relatable real-world examples as well as what we learned on those track works, and show you what this might look like in the real world.
1. Quality Planning: Figuring Out What "Good" Looks Like
Main outcome: Define what "good" looks like upfront, agree acceptance criteria, and make sure everyone understands success before you start.
The everyday example: Think about buying new furniture. You need a wardrobe that'll last several years, fit your room, hold what you need, and not break the bank. You work out your requirements: dimensions, budget, storage capacity, style. After comparing options, you decide IKEA best fits your specific needs. Maybe it's the modular design, the price point, or the warranty. That's planning and defining your requirements upfront and knowing what "good" looks like for your situation before you start.
How this applied to our track works: The same principle applies. We'd been laying tracks without properly involving the people who'd actually live with them. Here's what we discovered, the maintenance teams who'd be looking after these tracks for the next 20+ years were only brought in a few weeks before the actual works. No earlier touchpoints, no input on design decisions, no say in what would make their lives easier.
This was the root cause of our handover problems.
The solution seems obvious now, but it took us months to figure out. We started involving the end user at the planning stage. We built relationships and key checkpoints throughout the project, started developing rapport with them, and worked towards the same definition of "done." The result? Smoother handovers and significantly less rework.
So what does quality planning actually look like on your projects? Here are the key tools you'll work with:
Quality Plans and Acceptance Criteria documents
Pre-handover checklists agreed with the end user
Clear definitions of "done" for each deliverable
Regulatory and safety compliance requirements captured upfront
2. Quality Assurance: Building Quality Into the Process
Main outcome: Build quality into the way you deliver, so problems don't stack up at the end.
Back to that wardrobe: When you assemble it, you follow the instructions step by step. You check the right screws are going in the right holes. You make sure everything lines up before tightening it. That's assurance, building quality into the process so the final product actually stands up.
How this applied to our track works: We introduced assurance checks before and during delivery. We'd verify materials were ready, check track components met specifications, and ensure everything was in place before installation began. Instead of waiting until the end to discover problems, we were catching issues early. And here's the crucial bit, if we noticed something that could impact the end user, we'd discuss it transparently and work together on a solution. This not only reduced defects but also built trust with the end user, who could see quality being built in at every stage.
In hindsight, this was one of those transferable lessons. Quality isn't something you bolt on at the end. You build it in as you go.
So what does quality assurance look like on your projects? Here's what you'll typically see:
Independent audits and peer reviews
Mid-project inspections and checks
Test scripts followed and signed off at each stage
Training and feedback loops to ensure consistent standards
3. Quality Control: Making Sure It Actually Works
Main outcome: Test and verify that the finished output meets the requirements before handover.
Your wardrobe is built: Now you open the doors, check the drawers slide smoothly, make sure it doesn't wobble. That's control, confirming it's fit for purpose before it's put to use.
How this applied to our track works: We learned the value of transparency. We got the end user involved to witness tests and see the results first-hand. Once the work was done, we agreed any snags together and followed up to action them quickly. We made sure all the paperwork was spot on before handover. This collaborative approach gave them the confidence to sign off without the lengthy negotiations that used to drag on for months.
So what does quality control look like on your projects? These are the typical deliverables:
Inspection and Test Plans (ITPs)
Factory Acceptance Tests (FATs) and Site Acceptance Tests (SATs)
Non-Conformance Reports (NCRs) where things don't meet spec
Final sign-off checklists, snagging lists, and validation evidence
4. Continuous Improvement: Learning As We Go
Main outcome: Learn from each project and embed improvements for next time.
Think about that first wardrobe build: It takes hours. Screws in the wrong places, plenty of frustration. By the second or third, you've figured it out. You lay everything out, organise the parts, maybe use an electric screwdriver. Each time, you get faster and better.
How this applied to our track works: Every site taught us lessons we couldn't ignore. We started slowly making changes to the way things were done: standardising templates, clearing snags as we went rather than leaving them until the end, building relationships earlier. Each small improvement helped shift the perspective and gradually influenced the culture.
It seems easy on the surface, but culture change takes time. It wasn't perfect. After a few bumps we developed a rhythm and continued to be open to learning, trying to do the right thing better each time. The shift from "just get the track open" to "deliver a package the end user can actually trust" didn't happen overnight. But it did happen.
So what does continuous improvement look like on your projects? Here are the common approaches:
Lessons learned reviews and after-action reports
Updating templates and checklists for future projects
Introducing new practices based on what you've learned
Using the Plan-Do-Check-Act cycle as a framework
We'll explore each of these four elements in more depth in a future series. For now, the lesson is simple: quality isn't a checkbox at the end. It's the way you deliver from day one. And that shift in thinking? It changed everything for us.
Four Stages of Quality Management
When Reality Kicks In
In reality though, you won't always see every stage of quality management play out neatly. Large engineering projects can last several years, with handovers between teams and suppliers along the way. Often, you inherit a quality system already in place, or you help design one for others to follow.
In these environments, project quality management works alongside organisational or industry quality systems. As a PM, you may not own the entire cycle, but you still play a vital role: developing the approach where it's missing, executing it where it's established, and driving continuous improvement wherever you can.
When you're working on railways or other infrastructure where people's safety depends on getting it right, there's no room for error. But here's the thing, whether you're building a railway, developing software, or managing an office refurbishment, the same quality principles apply. Plan what good looks like, build quality in as you go, test before you finish, and learn from what went wrong. The context changes, but the approach doesn't.
Quality in Agile Projects
Agile takes a different view. Quality isn't a stage, it's continuous. Acceptance criteria are built into user stories, "definition of done" sets standards upfront, and reviews happen every sprint. Instead of waiting until the end, quality is checked in small, frequent cycles.
It's not less rigorous. It just spreads the effort across the lifecycle. And honestly? That makes more sense than trying to fix everything at the end.
Common Quality Failures (And Why They Happen)
From lessons learned across engineering and infrastructure projects, quality issues come from both technical and human factors. Yes, technical capability matters, getting specifications right, following standards, ensuring proper installation. But what often gets overlooked is the process and behaviour side:
End users brought in too late (classic trap)
Acceptance criteria vague or misaligned
Checklists used mechanically, not thoughtfully
Ownership of quality unclear
Teams dispersing before handover was finalised
The pattern is clear: quality fails when technical excellence isn't supported by trust, clarity, and accountability. You need both to succeed.
The Psychology Behind Quality
Quality is as much about perception as compliance.
Here's what I've learned about how people actually think about quality on projects:
People don't trust what they weren't part of. Exclude them from planning and they'll find problems later, guaranteed.
Loss aversion is real. People are wired to fear losses more than they value gains. One quality failure weighs heavier in their minds than five successful deliveries. That's why past failures raise the bar. One bad experience means your next project faces much tougher scrutiny.
Trust is built through behaviour, not documents. If teams cut corners in one phase, stakeholders assume corners have been cut elsewhere. Small slips damage perception disproportionately. Being consistent in the little things matters as much as passing the big tests.
How you frame things matters. Saying "95% compliance" feels different from saying "5% failures," even though they're the same number. Present results in a way that aligns with stakeholder concerns.
Ownership signals confidence. When someone stands up and says, "I personally confirm this is ready," it changes the room. People respond to confidence and accountability more than spreadsheets alone.
The lesson? Quality isn't just about meeting specifications. It's about managing perceptions, building confidence, and understanding what drives stakeholder concerns. Get the psychology right, and the sign-offs follow. Miss it, and you'll struggle even with perfect paperwork.
Key Takeaways
Plan for quality early and don't leave it until testing
Build quality into how you work, not just what you produce
Define "done" with the people who'll inherit the asset
Get the technical details right first time to avoid costly rework
In agile, treat every sprint as a quality checkpoint
Don't confuse paperwork with readiness
Most quality failures combine technical and communication issues
Continuous improvement is the habit that changes culture
Here's the Bottom Line
Quality can feel like an abstract idea when you're starting out - something buried in procedures, checklists, or systems. But the truth is, it's about making things that work properly and that people can trust.
You don't have to get it perfect from day one. What matters is building the habit of asking: what does good look like here, and how do we prove it? This means getting both the technical details right (specifications, standards, proper execution) and managing the human side (involvement, communication, ownership).
If you keep that dual focus at the heart of your projects, technical excellence supported by good process. You'll already be doing more for quality than many seasoned professionals. We're all figuring it out together, but that simple approach? It changes everything.
Project management is as simple as you want it to be, or as complex as you make it. Quality is no different. Start simple, build the habit, and let it grow from there.
What traps have you fallen into with quality on your projects? Drop me a message and let's compare notes.
References
APM Body of Knowledge, 7th edition. Association for Project Management. https://www.apm.org.uk/book-shop/apm-body-of-knowledge-7th-edition/
Get It Right Initiative (GIRI). "Literature Review: A Review of Quality Issues and Their Costs in Construction." https://getitright.uk.com/live/files/reports/4-giri-literature-review-revision-3-599.pdf (5% rework cost figure)
Want more practical PM insights like this?
Subscribe to The PM Notebook for regular insights straight to your inbox, or listen to The Real PM Podcast for honest conversations about what actually works.
Ready to bridge theory and practice? Try Mindcast - the first-of-its-kind interactive experiences I developed where you step through real project scenarios and make PM decisions hands-on. It's my way of helping and guiding you beyond traditional learning to build the practical judgment that only comes from doing.
Connect with me on LinkedIn for project management insights or get in touch to share your thoughts and experiences.