Why project delays usually come from client inputs, not execution: the four things we chase and why

The delay attribution problem

When a digital project slips, the first instinct is to ask what the team could have done faster. More developers, tighter design sprints, better tools. From our project work across dozens of client engagements, that instinct usually points at the wrong thing.

The pattern we see repeatedly: the team's internal work moves at the expected pace. What slows the project is waiting. Waiting for feedback that was due three days ago. Waiting for the product data that was supposed to arrive at kickoff. Waiting for hosting credentials to be provisioned. Waiting for the final logo file in the right format. Each of these waits individually looks small. Collectively, they account for most of the time between planned delivery and actual delivery.

This matters because it reframes what a project coordinator's job actually is. The highest-leverage work isn't executing faster inside the team. It's making sure the team never has to wait for inputs from outside the team. Following up on those inputs systematically, and early, is where project timelines get saved or lost.

Why follow-up isn't nagging

Project coordinators often feel uncomfortable chasing clients. Worried about seeming pushy. Worried about damaging the relationship. Worried that the client has their own priorities and should be allowed to manage their own timing.

This framing is well-intentioned and wrong. The job of a project coordinator is to protect the project's success. When inputs are late, the project's success is at risk. Following up respectfully, with clear context, is the respectful move. It tells the client: "Here's what's at stake if this slips, so you have what you need to decide whether to prioritize this or accept the timeline shift."

The alternative (waiting silently until the deadline passes, then informing the client that the project is now delayed) is worse for both sides. The client had no opportunity to adjust. The team had no opportunity to compensate. Everyone discovers the problem too late to fix it.

Chasing inputs is how you protect everyone's time and everyone's outcomes. Framed that way, the discomfort usually fades.

The domino effect

One underappreciated fact about input delays: they don't just delay one step. They cascade.

A 3-day feedback delay on design doesn't mean development starts 3 days late. It usually means:
- Development starts 3 days late.
- The next feedback window (development review) gets pushed, because the developer can't deliver to a reviewer who has other commitments.
- QA gets compressed to keep the launch date, which creates quality risk.
- Or the launch date slips by 5 to 7 days, because the downstream dependencies didn't have slack to absorb the initial 3.

Teams that say "we can make up 3 days" usually can't, because project timelines are full of interdependencies that don't compress. Naming this dynamic at the start of a follow-up makes the conversation land. "If we don't get feedback by Thursday, the launch moves from May 15 to May 22" is a different conversation than "can you send feedback soon?"

The four inputs we chase

Every digital project we run tracks these four categories explicitly. Each is a different flavor of dependency, with different owners and different rhythms.

1. Feedback

What it is: Client review on work the team has delivered: design iterations, content drafts, campaign proposals, prototype links.

Who owns it on the client side: Usually a specific named reviewer (marketing lead, product owner, founder). If the reviewer is unclear, the feedback will come slowly, because "the client" in aggregate doesn't review things. A person does.

When it's needed: Usually at the end of each design, content, or planning iteration, before the next phase begins.

How to make it easier for the client: Agree on a feedback deadline at the start of each iteration. Send the deliverable with a clear note on what kind of feedback is useful ("we're looking for structural feedback on the homepage, not visual polish yet"). Make the review as frictionless as possible, a single link with direct comment access rather than asking the client to download and annotate a PDF.

Failure mode when missing: The team either proceeds on assumption (and rebuilds later) or stalls.

2. Information

What it is: Project-specific data the team needs to do the work correctly: product details, pricing, target audience, technical specifications, legal or compliance requirements, copy or content drafts.

Who owns it on the client side: Varies by information type. Product info usually comes from product or marketing. Audience data from marketing or sales. Technical requirements from IT. Legal from legal or compliance.

When it's needed: Mostly at project kickoff, with some pieces needed at specific later milestones (e.g., legal review often happens late in the cycle).

How to make it easier for the client: List all required information at kickoff in a single checklist. Specify the format needed (e.g., "product descriptions as a Google Doc with one section per product, 150 words each"). Provide a template where useful. Don't ask piecemeal over weeks of messages.

Failure mode when missing: The team builds on placeholder content, which looks correct until real content arrives and reveals layout problems that require rework.

3. Resources

What it is: Operational assets the team needs access to in order to deliver: hosting credentials, domain access, platform admin access, software licenses, third-party API keys, analytics accounts, advertising platform access.

Who owns it on the client side: Usually IT or operations. Sometimes the original vendor who set up the system and retained the credentials.

When it's needed: At specific handoff or deployment moments, but often needs to be requested much earlier because the client has to hunt down the credentials or grant new access internally.

How to make it easier for the client: Flag the full resource list at kickoff, even if some items won't be needed for months. Explain why each is needed. Give the client time to handle internal access processes without last-minute pressure.

Failure mode when missing: Launch slips because the team can't push to production, or because analytics can't be installed, or because the ad platform account access never got granted. These are preventable, but only if the resource request happens weeks before the need.

4. Materials

What it is: Brand and creative assets the team uses in the work: logos in all required formats, brand colors and typography specifications, photography, video assets, 3D renders, stock imagery licenses. Also client-specific creative assets like product photography or executive headshots.

Who owns it on the client side: Usually marketing or brand. Sometimes an external design agency that created the original brand identity.

When it's needed: Design phases, and throughout production. Materials are iterative: logos get asked for early, additional product photography gets requested mid-project as the design takes shape.

How to make it easier for the client: Provide format specifications upfront (what file formats, what resolutions, what color modes). Flag licensing questions early (can we use this photo for paid media? Is there a license that limits duration or geography?). Accept that clients often don't know what formats they have until they look.

Failure mode when missing: Placeholder assets end up in the design, designs get approved based on placeholders, and when the real assets arrive they don't fit the approved layout. Or worse, the project ships with placeholder assets that slip through review.

How to follow up well

Follow-up is a skill, and small language moves make a big difference.

Always state the downstream impact: "I need this feedback by Thursday so development can start Monday" lands differently than "any feedback yet?" The first tells the client why the deadline matters. The second sounds like nagging because it doesn't supply the context.

Offer alternatives when possible: "If V1 is still in review, we can proceed with placeholder imagery for now, with one revision window when the real photography arrives." Shows the client you're working to keep the project moving, not just waiting for them to finish.

Keep the tone collaborative: "Wanted to check in on the product data we discussed. Let me know if it's still being pulled together, or if I can help with anything on your side to unblock it" lands better than "still waiting for the product data." Same information, different relational effect.

Escalate rarely, but clearly: If a follow-up has been ignored multiple times and the project is at real risk, a direct message to a senior stakeholder with the timeline impact is appropriate. Do this sparingly. The first few follow-ups should always assume good faith and missing context, not indifference.

Setting deadlines at kickoff

The single highest-leverage move for reducing follow-up friction is setting expectations at kickoff, not mid-project.

At project kickoff, we go through the input list with the client and agree on specific dates for each category. Not "as soon as you can," but "feedback returned within 3 business days of delivery," "product information finalized by May 10," "hosting credentials provided by May 15." These dates get into the project plan and become part of the agreed shared timeline.

This works for two reasons. First, the client has the opportunity to push back at kickoff if a date is unrealistic, instead of missing it quietly three weeks later. Second, when follow-up is needed later, it references an agreed date rather than imposing one: "you mentioned at kickoff the legal review would be done by May 20. Where are we with that?" That framing is a reminder, not a new request.

Clients generally appreciate this upfront specificity, once they see the purpose. It's not tight control. It's collaborative scheduling that respects everyone's capacity to plan.

Working with the Deliverable Checklist

Much of what we've covered lives in a single document: the Deliverable Checklist, which we write at project kickoff and reference throughout. It lists every input needed from the client, by category, with the timing and owner for each. We've written about this in more detail in a dedicated article on the three types of checklists, so we won't repeat the mechanics here.

The short version: without a checklist, input tracking lives in individual coordinator heads and gets dropped when things get busy. With a checklist, tracking is visible and shared, and nothing falls through the cracks because someone forgot to follow up.

The outcome

Projects that manage inputs well usually ship on time or close to it. Projects that don't, slip.

The team's execution speed matters, but it has a ceiling. The ceiling is set by how quickly the team gets what it needs to execute. Following up on inputs systematically raises that ceiling. It's the least glamorous part of project management, and it's also where the largest share of project outcomes actually gets determined.