Creating Waterfall Chart Project Plans and Gantt Charts

Overview

How It Works

Step-by-Step

1. Step 1: Define the Work Breakdown Structure (WBS)

   Start with your project scope and the Waterfall phases you've established (see defining Waterfall phases). For each phase, identify the major deliverables. Then decompose each deliverable into work packages — groups of related tasks that can be assigned and tracked as units. Finally, break work packages into individual tasks.

   Use the 100% rule: the sum of all child elements must equal 100% of the parent's scope. Nothing should be missing, and nothing should be duplicated. A typical Waterfall project WBS has 3-5 levels of decomposition.

   For example, the "Design" phase might decompose into deliverables like "System Architecture Document," "Database Schema," and "UI Wireframes." The "UI Wireframes" deliverable might break into tasks like "Conduct user flow mapping," "Create low-fidelity wireframes," "Conduct stakeholder review," and "Produce final wireframe package."

   Tip: Apply the 8/80 rule: no task should be smaller than 8 hours or larger than 80 hours of effort. Tasks outside this range are either too granular to manage or too vague to estimate accurately.

2. Step 2: Sequence Tasks and Map Dependencies

   With your complete task list in hand, determine the logical relationships between tasks. Ask for every task: "What must finish before this can start?" and "What can start at the same time as this?"

   Use standard dependency types:

   • Finish-to-Start (FS): Task B starts after Task A finishes. This is the most common in Waterfall.
   • Start-to-Start (SS): Task B starts when Task A starts. Useful for parallel work within a phase.
   • Finish-to-Finish (FF): Task B finishes when Task A finishes. Common for documentation that must be completed alongside development.
   • Start-to-Finish (SF): Rarely used, but occurs when a new process must start before the old one can end.

   Pay special attention to cross-phase dependencies. In Waterfall, phase boundaries are typically hard finish-to-start gates — design doesn't begin until requirements are signed off. But within phases, you'll often find opportunities for parallelism that can compress your schedule.

   Tip: Draw a network diagram (activity-on-node) before jumping into the Gantt chart. It's much easier to spot missing dependencies and circular logic in a network view than in a bar chart.

3. Step 3: Estimate Task Durations

   For each task, estimate how long it will take to complete. Use one or more of these techniques:

   • Expert judgment: Ask the person who will do the work. They know the domain best.
   • Analogous estimation: Compare to similar tasks from past projects. If last year's database migration took 3 weeks, this similar one will likely take a comparable amount of time.
   • Three-point estimation: Calculate (Optimistic + 4×Most Likely + Pessimistic) / 6 to get a weighted average that accounts for uncertainty.

   Be clear about the difference between effort (person-hours of work) and duration (calendar time). A task requiring 40 hours of effort takes 5 days if one person works full-time, but 10 days if they can only devote half their time.

   Document your assumptions. If you estimated 2 weeks for testing because you assumed a dedicated QA team of 3, write that down. When assumptions change, you'll know exactly which estimates need revisiting.

   Tip: Add contingency buffers at the phase level, not the task level. If you pad every individual task, Parkinson's Law kicks in and work expands to fill the padded time. A 10-15% phase-level buffer is more honest and more effective.

4. Step 4: Assign Resources to Tasks

   Map each task to the people, tools, and budget it requires. Start with role-based assignments ("Senior Developer," "UX Designer") and then assign specific individuals where possible.

   Build a resource calendar that accounts for holidays, vacations, part-time availability, and shared resources. A developer who is split across two projects at 50% each has very different availability than one dedicated full-time.

   Check for resource conflicts — situations where the same person or team is assigned to multiple concurrent tasks. When you find conflicts, you have three options:

   1. Re-sequence tasks so they don't overlap.
   2. Add resources (hire contractors, reassign team members).
   3. Accept the delay and adjust the schedule.

   This process is called resource leveling, and it almost always extends your initial schedule. That's normal and expected — it's better to discover this now than during execution.

   Tip: Create a resource histogram alongside your Gantt chart. It visually shows when resources are over-allocated, making it much easier to spot problems than scanning through a task list.

5. Step 5: Build the Gantt Chart and Identify the Critical Path

   Now bring everything together in your Gantt chart tool. Enter tasks in WBS order, set dependencies, input durations, and assign resources. The tool will calculate start and finish dates automatically based on your dependency logic and calendar.

   Once the schedule is populated, identify the critical path — the longest sequence of dependent tasks from project start to project finish. Any delay on a critical path task delays the entire project by the same amount. Most Gantt chart tools can highlight this automatically.

   Also identify float (or slack) on non-critical tasks. Float is the amount of time a task can slip without affecting the project end date. Tasks with zero float are on the critical path. Tasks with positive float give you scheduling flexibility.

   Structure the waterfall chart so that phase groupings are clearly visible. Use summary bars for phases, color code by team or phase, and add swimlanes if your tool supports them. The goal is a chart that a stakeholder can glance at and immediately understand the project's structure and timeline.

   Tip: If your critical path runs through tasks that are highly uncertain or risky, consider adding a 'near-critical path' view showing paths with less than 5 days of float. These are the paths most likely to become critical if anything slips.

6. Step 6: Set Milestones and Phase Gates

   Place milestone markers at key points in your waterfall chart. At minimum, set milestones at:

   • Phase boundaries: The completion of each Waterfall phase (Requirements Complete, Design Complete, Code Complete, Testing Complete, Deployment Complete).
   • Major deliverable approvals: Sign-off on the requirements document, architecture review approval, UAT sign-off.
   • External dependencies: Dates when third-party deliverables are due, regulatory submissions, hardware procurement deadlines.

   Milestones are zero-duration markers — they don't consume time, but they signal that a defined set of criteria has been met. Link them to your phase gate review process so that the project cannot progress past a milestone without formal approval.

   For each milestone, document the entry criteria (what must be true for the milestone to be considered met) and the responsible approver. This turns milestones from aspirational dates into enforceable checkpoints.

   Tip: Keep milestones visible at the summary level of your Gantt chart. Executives and sponsors rarely need to see individual tasks, but they always want to know when the next milestone is.

7. Step 7: Baseline and Communicate the Plan

   Once your waterfall chart project plan is reviewed and approved by key stakeholders, save a baseline. The baseline is a snapshot of your approved schedule that you'll compare against as the project progresses. Most Gantt chart tools let you overlay the baseline against actual progress, making it easy to see where you're ahead, on track, or behind.

   Distribute the plan in formats appropriate to each audience:

   • Executive summary: A one-page view showing phases, milestones, and the end date.
   • Team lead view: Phase-level detail with resource assignments and dependencies.
   • Individual contributor view: Their specific tasks with due dates and predecessors.

   Establish a cadence for schedule updates — typically weekly in Waterfall projects. During each update, collect actual start dates, completion percentages, and revised estimates for remaining work. Compare against the baseline and report any variance.

   Remember that the plan is a living document. When changes are approved through your change request process, update the schedule, re-baseline if the change is significant, and communicate the revised timeline.

   Tip: Store your baseline in a shared, version-controlled location. Nothing derails a project review faster than stakeholders comparing against different versions of the plan.

Examples

Best Practices

• Always build the WBS before opening your Gantt chart tool. Jumping straight to the Gantt chart leads to missed tasks and poorly structured schedules because the tool encourages linear thinking rather than hierarchical decomposition.

• Use finish-to-start dependencies as your default and only deviate when you have a clear, documented reason. Overuse of start-to-start and finish-to-finish dependencies creates complex schedules that are hard to update and prone to logical errors.

• Review the critical path weekly and after every schedule change. The critical path can shift as tasks are completed faster or slower than planned, and losing sight of it means losing control of your end date.

• Involve the people who will do the work in estimation. Top-down estimates from managers consistently underestimate duration. Bottom-up estimates from practitioners are more accurate and build team commitment to the plan.

• Keep your waterfall chart at a manageable level of detail. A 5,000-task Gantt chart is theoretically comprehensive but practically unmanageable. Target 100-300 tasks for a 6-month project, grouped into clear WBS categories.

• Document all scheduling assumptions and constraints in a companion document. The Gantt chart shows 'what' and 'when' but not 'why.' When assumptions change, you need to know which parts of the schedule are affected.

Common Mistakes

Frequently Asked Questions