Inconsistent Delivery Is Five Different Problems, Not One

Churn, burnout, and margin erosion get blamed on lots of things. Inconsistent delivery is almost never on that list.

I think it flies under the radar because it’s not one problem. It’s several, and they look nothing alike. They also share a single symptom, which is work that comes back needing another pass, so everyone treats them as one thing and reaches for one fix.

Five problems that all look like one

If quality is bumpy, it’s usually that nobody has defined what “great” looks like for that deliverable. People are guessing and their guesses are different. That needs an example of finished work, not a document about the process.

If a senior person can’t hand something off, the process is probably still in their head. The steps are real, they’ve just never been broken down into something a second person can pick up and run with.

If the output looks different every time it goes out the door, that can be a template problem. People copy the last client’s doc and edit from there, so every deliverable carries decisions made for a different situation.

If things are late or getting dropped, look at the PM system first. The tasks don’t reflect how the work really moves, so the real status ends up living somewhere else, usually in one person’s head or a Slack thread nobody else is in.

If a workflow is inefficient, that’s usually a tooling issue. Either the process is being run fully manual or the underlying stack is broken or outdated. AI has made this much more obvious, and much easier to fix, than it used to be.

Five different causes. Five different fixes. One symptom.

They don’t cost the same to fix

This is the part that gets skipped, and it’s why the wrong one gets picked.

Defining what great looks like is cheap in hours and expensive in ego. You pull three past deliverables, pick the best one, and say out loud why it’s better than the other two. That’s an afternoon. The hard part is that it requires telling good people their work wasn’t the standard.

Getting a process out of someone’s head is a couple of sessions with that person, plus a first attempt by somebody else that comes back wrong. Budget for the wrong attempt. It’s the part that actually surfaces what was missing.

Templates are the fastest win on the list and the one most agencies never get to, because nobody owns them and they don’t feel urgent on any given Tuesday.

The PM system is the expensive one. Not the tool, the migration. Every agency I’ve watched do this underestimates what it takes to get a team to actually change where they look in the morning.

Tooling has gotten dramatically cheaper in the last two years, which is genuinely new. Work that justified a hire in 2023 is a weekend build now.

Why everyone reaches for SOPs anyway

Almost everyone reaches for documentation as the solution regardless of which one it is, and I totally get why. Documentation is the thing you can point at when you’re done.

It’s also the only one of the five that feels like progress the entire time you’re doing it. Defining what great looks like means arguing about work your team already shipped. Fixing the PM system means admitting the last one didn’t take. Writing an SOP means an afternoon and a finished document, and nobody has to be wrong.

Sometimes documentation is the answer. More often it’s the last step rather than the first.

The version that costs the most is the six-month process initiative. A whole quarter of senior time goes into a system nobody asked for, and at the end the deliverables still come back needing heavy revision, because the actual problem was that three people had three different pictures of what finished looks like. Worse, the initiative burns the team’s patience for process work, so the fix that would have worked is now a harder sell than it was before you started.

Diagnose it in an afternoon

Take the last three deliverables that came in below standard or needed heavy revision. Name what specifically was wrong with each one.

If the same answer comes up twice, start there, and fix it for one deliverable type before you touch anything else.

If you get three different answers, you don’t have one process problem. You have three smaller ones, and a big process project would have missed all of them.

The instinct at that point is to run all three at once, since they’re each small. Don’t. Every one of them changes how somebody works, and a team can absorb one of those at a time.

This is the second of five things I look at inside an agency, and the one most people have already tried to fix unsuccessfully.