Waterfall Project Management: A Practical Guide for Agencies
Waterfall gets blamed for rigidity. The real problem is usually agencies running waterfall without discipline. You quote a fixed scope. You promise a launch date. You hand off between teams without checklists. The client approves a design verbally over Zoom. Three weeks later, the build phase is 40% over and nobody remembers what was actually agreed.
This guide is about how agencies run waterfall project management well. The phase gates that catch problems early. The sign-off structure that makes approvals explicit. The handoff documentation that stops context loss between phases. And the failure modes that kill waterfall projects when any of those are skipped.
What Is Waterfall?
The waterfall methodology is a sequential approach to project management. Work flows through five waterfall phases: Requirements, Design, Build, Test, Launch. Each phase hands off to the next with a clear deliverable. Scope is defined upfront and locked. Changes mid-project are the exception, not the rule.
The waterfall model is named after a 1970 paper by Winston Royce, who actually used the term as a warning. He presented the sequential model and immediately critiqued it.
"I believe in this concept, but the implementation described above is risky and invites failure." - Winston Royce, Managing the Development of Large Software Systems, 1970
Royce proposed iteration and customer involvement even in 1970. The man who named waterfall warned against pure waterfall. That is the central tension this guide addresses.
For the full comparison with agile, see our agile vs waterfall guide. For running iterative methodologies in parallel, see our Scrum for agencies guide.
Why Waterfall Breaks at Agencies
Most waterfall content treats the method as a definition. The practical question for agencies is different: why does waterfall break in agency work, and what do you do about it?
Four patterns show up every time.
The first three break without phase gate discipline. The fourth breaks without sign-off structure. All four compound when handoffs are informal.
| Breakdown pattern | What it looks like at an agency |
|---|---|
| Requirements looked clear, weren't | Client signed a scope doc in week one. In week four they say "obviously we also need X." The scope was an executive summary, not a working specification. |
| Design handoff loses context | A Figma link gets dropped in Slack. Dev team builds what they see. Six spacing decisions, three font fallbacks, and the mobile breakpoint were never documented. |
| Client approval is informal | "She said it looked great on the call." Two weeks later she says that is not what she approved. There is no written record of what was signed off. |
| Late-phase rework compounds | The client sees the QA build and wants design changes. Now you're redoing Design work in Test phase. Timeline slips, margin disappears, team demoralizes. |
Phase Gates: The Execution Core
A phase gate is a decision point between phases. Work does not proceed until the gate is reviewed and approved. The review is not a meeting that happens when the work is already done. It is a structured checkpoint with explicit entry criteria and a documented outcome: go, no-go, or hold.
Most agencies skip gate reviews because they feel like overhead. That is exactly why waterfall fails at those agencies. The review is not overhead, it's the whole point.
"The major distinguishing feature of the spiral model is that it creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process." - Barry Boehm, A Spiral Model of Software Development and Enhancement, 1986
Boehm made this argument about spiral models, but it applies directly to waterfall phase gates. The gate is not a box to tick, itis a risk check. What could go wrong in the next phase if we proceed today?
Each phase has specific entry criteria, a review checklist, and named approvers. Here is what that looks like across the five phases.
| Phase | Entry criteria | Review checklist | Typical timeline |
|---|---|---|---|
| Requirements | Kick-off complete, stakeholders identified | Scope doc reviewed, success criteria defined, assumptions logged, out-of-scope items listed | 3-5 days |
| Design | Requirements signed off | Wireframes annotated, design system defined, responsive breakpoints specified, accessibility notes, copy locked | 5-7 days |
| Build | Design assets handed off with handoff meeting complete | Code review complete, test plan ready, QA environment prepared, deployment plan drafted | 5-7 days (weekly checkpoints) |
| Test | Build phase marked complete | All known issues documented, workarounds noted, client test checklist prepared, regression tests passed | 3-5 days |
| Launch | QA sign-off received | Production deployment checklist, rollback plan, monitoring configured, post-launch support plan | 1-2 days |
Sign-Offs and Handoffs Between Phases
A phase gate only works if someone is accountable for the approval. That is what sign-off structure means. It is not a signature on a PDF. It is a named human who owns the decision, a documented checklist of what they reviewed, and a written record of their approval.
Agencies get sign-offs wrong in two ways. First, they leave the approver ambiguous ("the client will review"). Which client? The person who signed the contract, or the junior marketer cc'd on emails? Second, they accept informal approval ("she said it looked great on the call"). Informal approval evaporates the moment scope changes.
The fix is an authority matrix. Every phase deliverable has a named approver, a named reviewer, and a documented escalation path if the approver is unavailable.
Handoffs are the other half of gate discipline. When Design hands off to Build, what exactly moves? A Figma link is not a handoff. A handoff is the file plus the spec plus the responsive breakpoints plus the font and color variables plus a 30-minute handoff meeting where the Build team can ask questions. If the Build team starts without this, the phase will overrun. Guaranteed.
| Phase deliverable | Approves (named human) | Reviews | Escalation path |
|---|---|---|---|
| Project scope document | Client primary contact, agency PM | Stakeholders, finance | Project sponsor |
| Visual designs | Client primary contact, design lead | PM, dev lead | Account manager |
| Build deliverable | Dev lead, PM | QA, client (informational) | Engineering or tech lead |
| QA test report | Client primary contact, QA lead | PM, dev lead | Account manager |
| Final launch | Client primary contact, PM, ops lead | Stakeholders, executive sponsor | Account manager |
Waterfall for Creative Agency Work
Waterfall guides are usually written for software with a wide amount of examples covering engineering projects. For agencies running brand, design, campaign, and web work, the phase structure translates directly.
Brand identity is the clearest fit. Research, concepts, refinement, guidelines, rollout. Each phase has a clear deliverable. Each phase ends with client review. Jumping ahead (starting logo work before research is signed off) leads to rework and client friction, waterfall saves creative work from scope creep.
Website projects are similar. Discovery, information architecture, wireframes, visual design, development, QA, launch. The first four phases are sequential. The Build phase can run agile sprints inside it, but the phase gate is waterfall. Do not let Design changes slip into Build because the client had a new idea after sign-off. That is a change request, not a sprint adjustment.
Marketing campaigns follow a compressed version. Strategy, creative, production, QA, launch. Creative can iterate inside the Creative phase (three rounds of concepts is common). Once the client picks a direction, the direction is locked. Production executes on what was picked.
Common Waterfall Mistakes at Agencies
Five patterns show up across agencies that try waterfall and struggle. Each one maps back to missing discipline in gates, sign-offs, or handoffs.
"'Aggressive schedule,' I've come to suspect, is a kind of code phrase, understood implicitly by all involved, for a schedule that is absurd, that has no chance at all of being met." - Tom DeMarco, Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, 2002
DeMarco's framing applies directly to phase timelines. Agencies quote three weeks for Design phase because it sounds reasonable to the client, not because the team can actually deliver quality work in three weeks. Then the phase overruns, Build starts late, and the launch date gets defended by cutting QA. Realistic phase timelines with buffer built in prevent this compounding failure.
| Mistake | Fix |
|---|---|
| Scope creep despite a signed scope doc | Formal change request process with impact analysis. New work is a change order, not a phase adjustment. |
| Build phase overruns from incomplete Design handoff | Handoff checklist, 30-minute handoff meeting, 48-hour review window before Build starts. |
| Client approval bottleneck stalls the project | Review cadence communicated at kick-off. Named primary and backup approvers. Weekly async status update. |
| Late-phase rework (design changes during QA) | "Design locked after sign-off" policy. Any change after the gate is a change request with new timeline and scope impact. |
| Aggressive phase timelines with no buffer | Realistic phase estimates with 15-20% buffer. Never promise a timeline before phase scope is locked. |
Running Waterfall in Rock
Rock is not a Gantt chart tool. If you need enterprise-level PMO dashboards or resource leveling across fifty parallel projects, Microsoft Project or Smartsheet will serve you better. What Rock gives you for waterfall is simpler, and often enough to get the project done: phase structure in task lists, milestone due dates, handoff documentation in notes, and sign-off threads in task comments.
What we see many agencies doing at Rock: one space per client project. Each phase is a task list inside the space (Requirements, Design, Build, QA, Launch). Phase end-dates sit on the milestone task at the top of each list. Handoff documentation lives in a shared note per phase transition. Sign-off happens in the task comment thread on the milestone task, with the client tagged as approver. The audit trail is permanent. Clients see what they have signed off, and what they have not.
For the setup walkthrough, see the project planning template. For how phases fit into the broader methodology landscape, see our project management framework guide.
Getting Started with Disciplined Waterfall
Do not try to roll out phase gates across every project at once. Pick one.
Step 1. Pick one project. Ideally a fixed-scope project that is about to start: a brand identity, a website build, a campaign launch. Not a retainer. Retainers fit Kanban, not waterfall.
Step 2. Write the phases into task lists. One task list per phase. Each list has a single milestone task at the top with the phase end-date.
Step 3. Define gate criteria per phase. For each phase, write down what must be true to exit the phase. What is reviewed, what must be signed, who signs.
Step 4. Name the approver for every gate. By name, not role. If the primary approver is unavailable, name a backup.
Step 5. Write the handoff checklist. What moves from each phase to the next. File structure, documents, meeting format, known issues.
Step 6. Run the project. Keep the gates honest. If Design isn't ready, do not open Build "just to get started." That is the rigidity trap. Waterfall works when you respect the gate.
Step 7. Retrospective at project end. Which phases overran? Which gates got skipped? What would change next time? Disciplined waterfall gets better with iteration, the same way retrospectives improve agile work.
Waterfall without discipline is the rigidity trap. Waterfall project management with phase gates, named sign-offs, and documented handoffs is how agencies deliver predictable work at fixed prices. Royce knew this in 1970. Agencies who run it well know it now.
Run waterfall for agencies without the enterprise overhead. Rock combines chat, tasks, and notes in one workspace. One flat price, unlimited users. Get started for free.
