By delivery components I mean the parts that make delivery repeatable, and two matter most to me: automated CI/CD pipelines and automated testing. Together they are how I like quality to get into a project: built in, not checked on at the end.
Why the end of the line is the wrong place
A defect found by a person at the end of the line has already travelled through design, development and integration. Everything built on top of it has to be reopened. A defect found minutes after the change that caused it costs almost nothing to fix, because the person who wrote it still remembers what they meant.
What built in means
In practice, it means a few things I ask the team to treat as non-negotiable:
- Every change goes through the pipeline. No builds made by hand on someone's machine.
- Automated tests run on every change, and a failing test stops the line until it is fixed.
- The same path to every environment. Deployment is rehearsed many times before go-live, so the final one is routine.
- Results visible to everyone, including the client when it helps the conversation.
Where it starts
I raise the pipeline in the first weeks, with the tech lead, before feature work piles up. Adding one to a project that is already late is possible but hard, because by then nobody has time to stop and build the thing that would save time.
What it gives a project manager
An early signal, mostly. If the tests are green, I know something real about the state of the work, without waiting for a status meeting. Releases become predictable events instead of risky ones, and that supports one of my working principles: no surprises. It also changes the UAT conversation, because the client receives software that has already been through hundreds of checks nobody had to perform by hand.
It also helps the team. Nobody enjoys a release that has to be held together by hand, and the first thing automation removes is the dread around deployment day. That belongs to my people-first view of delivery as much as to the quality argument.
I do not need to read code to use it. A short list is enough: do the builds pass, how long do they take, how often does the line stop, and how quickly is it restarted. A line that is always stopped says something about the design or the pace. A line that is never stopped may mean the tests check too little.
Quality is a property of how the work flows, not a phase at the end.
What it does not do
Automation checks only what someone thought to check, so it does not replace UAT or a good understanding of the business. Tests also need maintenance, and a pipeline takes time to set up. On a fixed price I therefore want that time in the estimate as a line of its own, not as a favour the team does in the evenings.
The investment is made once, early, and it pays back on every change after it. I would rather explain that line in an estimate than explain a late defect in a steerco.