Ensuring Quality While the Project Is Moving
Planning quality and ensuring it are different sports. The plan is written in a calm week; ensuring happens in the loud ones, when the demo is tomorrow, the partner moved a date, and someone asks, very reasonably, whether we really need the full regression run this time. Everything in this post is about that moment, because quality on a live project is decided there, not in the document. I covered the plan itself separately; this is the execution half.
Make "done" non-negotiable at the ticket level
The single highest-leverage habit: the definition of done executes on every ticket, enforced by the board, not by memory. Review done, tests passing, deployed to staging. When done is negotiable per ticket, quality becomes a per-person mood, and under pressure the mood is always "later." The tracker is a better enforcer than the PM, because it does not get tired and nobody argues with a column.
Weight your inspection by risk
Uniform scrutiny is a budget error. A typo-level change and a payments change do not deserve the same review depth, and pretending they do means the payments change gets a typo-level look on a busy day. I keep an explicit short list of high-blast-radius areas per project: money movement, data sync boundaries, anything touching partner integrations. Changes there get slower review by named people, and everyone knows why. Boundary code earns its place on that list over and over; two systems, each correct alone, produce their best surprises where they meet.
Read the defect stream as telemetry
Individual bugs are noise; the pattern of bugs is signal. When defects cluster in one module, that module is telling you about its design or its owner's workload. When the same class of defect recurs, your process has a hole where prevention should be, which is exactly what root cause analysis with corrective action is for: the fix for this bug, then the fix for this kind of bug. Incident work taught me to treat every recurrence as a process defect wearing a technical costume. One recurrence is bad luck. Two is a system.
Keep QA close to the work, not downstream of it
The expensive layout is testers at the end of the pipe, discovering in week eight what was decided in week two. The cheap layout is quality presence at the decision points: test cases sketched when the story is written, testability raised in design review, a tester in the sprint instead of after it. Defects found at the design table cost a conversation. The same defects found in UAT cost a milestone, and found in production they cost a weekend plus a little bit of the team's trust in itself.
When someone proposes skipping the check
It happens on every project under pressure, and it should be a decision, not a drift. My script is boring on purpose: that check guards a named risk; skipping it means accepting the risk for this release; who accepts it? Sometimes the honest answer is yes, ship without the full run, the change is contained. Fine, that is risk management. What I refuse is the silent version, where the check just quietly doesn't happen and nobody signed anything. Quality erodes by unsigned exceptions.
The quiet metric
The metric I watch to know whether quality is actually holding is not the defect count. It is rework share: how much of the team's time goes to redoing things versus doing things. Rework is where poor quality hides in plain sight, billed as normal busyness. When rework trends down, the prevention habits are paying. When it trends up, somewhere upstream a corner is being cut, and the defect counts will confirm it a few weeks from now, at retail price.
Nguyễn Hải Nam
Project Management Lead. 16+ years from code to delivery. PMP®. Writing here about project management and engineering.