Quality Management: Building It Right, Not Just Building It Fast
Hey Friend 👋
On one project, we were successfully delivering railway infrastructure. Track laid, trains running, all technical milestones hit. But handovers to the maintenance teams were taking months, sometimes stretching into years.
Looking closer, I realised the problem. 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.
That's when I learned: quality isn't just about meeting technical specifications. It's about delivering something the end user actually wants to accept.
Quality management has four stages, but here's what we got wrong.
Quality Planning, Quality Assurance, Quality Control, and Continuous Improvement. We were doing the technical work brilliantly. But we missed the most important part: involving the people who'd actually use what we built.
Here's what changed everything:
- Plan with the end user, not for them: We started involving maintenance teams at the planning stage. Built relationships early. Agreed what "done" meant together. Handovers went from months to weeks.
- Build quality in, don't bolt it on: Assurance checks during delivery, not just at the end. Caught issues early. Discussed impacts transparently. Built trust.
- Control means proving it works: Got end users involved in testing. Witnessed results first-hand. Cleared snags together. Gave them confidence to sign off.
- Learn and improve: Each site taught us lessons. Standardised templates. Cleared snags as we went. Gradually shifted the culture.
Industry studies show rework due to poor quality averages 5% of project cost. On a £10 million project, that's half a million pounds wasted. But here's the real insight: people don't trust what they weren't part of. Exclude them from planning and they'll find problems later, guaranteed.
Quality isn't perfection. It's fitness for purpose. Does it do what we agreed? Does it meet the standards? Can it actually be used? The trap is thinking quality and speed are opposites. They're not. Poor quality slows you down through rework. Good quality keeps you moving forward.
Next time you start a deliverable: Write down clear acceptance criteria before work starts. What does "done" actually mean? What must it do? What standards must it meet? Share it with the team. You'll save hours of rework.
What's your quality vs speed battle story? Hit reply. I read them all and often feature reader insights in future newsletters.
Want to go deeper? You can read more in the full deep-dive with examples on quality management, or try the Mindcast for hands-on practice making these calls in realistic PM scenarios.
Making things happen,
Bilal Jamil