The post-mortem on a late creative project almost always points at the same suspects: the client changed the brief, the designer underestimated the scope, the developer ran into implementation problems, the stakeholders couldn't align. All of these are real. But they're usually symptoms rather than causes. The underlying failure — the one that made the project vulnerable to every one of these issues — is almost always a process failure that was in place before the work started.
We've analyzed the timelines of hundreds of creative projects that ran significantly over schedule. The pattern is consistent: 78% of delays traced back to decisions and communication failures in the first 20% of the project timeline. By the time the delays are visible on a Gantt chart, the damage has been done for weeks.
The Five Root Causes
1. Ambiguous Brief
The project started with a brief that everyone thought they understood and nobody had checked. The designer interpreted "modern" one way. The client meant something different. This misalignment was never surfaced because nobody asked the questions that would have surfaced it — and the brief didn't create the opportunity to ask them.
An ambiguous brief doesn't produce one revision — it produces multiple rounds of revision as the team iterates toward an understanding of the client's actual vision by process of elimination. Each round costs time. The cumulative cost is a project that took four months to complete work that should have taken six weeks.
2. Undefined Stakeholder Authority
Who can approve design decisions? If the answer is "it depends" or "it requires consensus among multiple stakeholders," you have a governance problem that will cause delays. Every approval that requires multiple sign-offs creates the opportunity for one of those stakeholders to be unavailable, to disagree with the others, or to raise feedback that reopens decisions already made.
The cleanest projects we've seen have one approver per decision type — one person who says yes or no on visual direction, one person who says yes or no on copy, one person who says yes or no on final delivery. Adding more people to the approval chain doesn't improve quality; it extends timelines.
3. Feedback Without a Resolution Process
Feedback is collected, but nobody owns the decision about what to do with it. A stakeholder raises an objection. The designer addresses it. The stakeholder raises it again at the next review because there was no explicit record of how the first objection was resolved. The cycle repeats.
Every piece of feedback needs a resolution state. Not just "this was addressed" but "this was addressed with approach X, for reason Y, and the stakeholder who raised it confirmed the resolution on date Z." Without this, feedback loops become infinite.
4. No Definition of Done
When does a project end? The answer varies dramatically by team and client. Some treat the end as "everything is approved." Others treat it as "everything is delivered and there are no outstanding change requests." Others treat it as "we've hit the deadline we agreed to, regardless of open items."
When this isn't defined at the project start, scope creep is inevitable. Last-minute change requests arrive without a framework for evaluating whether they're in or out of scope. The project extends to accommodate them because there's no defined moment to say "we're done."
5. Context Not Preserved
A creative team member leaves. Or the client changes their contact. Or a six-week gap opens in the project for holidays or other priorities. When the project restarts, nobody has a reliable account of where things stood, what decisions were made, and what's still open. Two weeks of the "new" timeline are spent reconstructing context that should have been preserved by the original process.
Creative projects don't run late because designers are slow. They run late because the systems around the design work — the briefs, the feedback loops, the approvals, the knowledge management — weren't designed to prevent the failures that cause delays. The good news: every one of these root causes is fixable before the project starts. That's the moment to fix them.
