WBS to Gantt chart: a step-by-step example

How to convert a WBS into a Gantt chart

1. Check the scope. List every deliverable, including approvals, handover and project management work.
2. Define activities. Each work package may need one task or several, such as draft, review and revise.
3. Group and assign. Use useful summary groups and give each activity an accountable owner.
4. Estimate durations. Check effort, availability, waiting time and the working calendar.
5. Add dependencies and milestones. The WBS hierarchy does not decide the sequence.
6. Check the result. Review the critical path, resource clashes and the forecast against the deadline.

What does a WBS do that a Gantt chart doesn't?

A WBS answers one question: what are we going to produce? A Gantt chart answers a different one: when does each piece of work happen, and what has to finish first? They are two views of the same project, and the WBS comes first because you cannot schedule work you have not listed.

PMI describes a WBS as a hierarchy of the project's total scope. Paul Burek's paper on the WBS distinguishes that deliverable hierarchy from the schedule. The outline tells you what belongs in the project; it does not, by itself, provide activity dates or dependencies.

The rule that keeps that list complete is the 100% rule. Each level of the breakdown has to account for all of the work in the level above it, no more and no less. Eric Norman's PMI paper on elaborating a WBS spells out the consequence: the WBS covers the whole project scope, including internal, external and interim deliverables and the project management work itself, and anything outside the scope has no place in it.

Use the 100% rule to check coverage. If the site needs redirects from old URLs, include them in the scope before scheduling the work. Otherwise a tidy plan can still leave visitors landing on missing pages.

A website redesign, broken down

Here is the scope for a small company website redesign: about 25 pages, a content management system, a contact form and a booking form. The outline uses six branches and the deliverables under each. It is enough detail to check coverage before defining the activities.

• Website redesign
  • Discovery
    • Stakeholder interview notes
    • Content audit
    • Sitemap
  • Design
    • Wireframes
    • Homepage and page template designs
    • Style guide
  • Content
    • Rewritten page copy
    • Images
    • Redirect map from old URLs
  • Build
    • CMS setup
    • Page templates
    • Contact and booking forms
    • Loaded content
  • Launch
    • Tested site
    • Live site with redirects and analytics
  • Project management
    • Project plan
    • Weekly status reports
    • Launch review

Three things about it are worth noticing before it goes anywhere near a chart.

• Every item is a noun. Burek's shorthand for keeping a breakdown focused on deliverables is that the WBS is nouns and the schedule is verbs.
• Project management is a branch of its own, because the 100% rule includes it. The plan, the status reports and the launch review are work someone has to do, even though nobody outside the team will see them.
• The second level is organised by phase of work rather than by part of the website. That choice matters more for the chart than for the WBS, and the section on levels below explains why.

When should you stop breaking the work down?

Stop when each work package is clear enough to assign, estimate and control. Writing deliverables as nouns is a useful check: "Wireframes" names an output; "Draw wireframes" names an activity. It is a drafting aid, not a rule that every project must have the same depth.

For a Gantt chart, three practical checks sit well on top of the noun test. A work package is about the right size when:

• one person can own it, even if others help;
• the owner can explain the work and produce a defensible estimate;
• progress can be checked at your reporting interval, either through completed activities or measurable outputs.

"Wireframes" may need separate drafting, review and revision activities if different people own those handoffs. For this small example, we assume one owner can manage them inside one task. Keep a page-by-page checklist for the copy unless individual pages have dates or dependencies worth showing.

Avoid turning every checklist action into a bar. More WBS detail can stay in supporting records; it does not all need to appear in the view you send to a client.

Which WBS levels become phases, and which become tasks?

Use the project as the chart title and choose summary groups that help readers follow the work. Then define the activities required by each work package. "Wireframes" becomes "Draw wireframes" here, but could become drafting, review and revision on a larger project. Keep enough traceability to see which activities deliver each work package.

This is also the moment to put a name on every task. Ganttile has no assignment field, so the owner goes at the front of the task name with a colon, as in "Sam: draw wireframes". The name then sits on the bar, where everyone reading the chart can see who the work package belongs to.

Choosing phases or deliverables as groups

You can group a WBS by deliverable, phase or another structure that suits the project. This example uses phases because they make the client view easy to scan. Grouping by homepage, service pages and forms may be better when different teams deliver those parts independently.

What happens to the project management branch

Include project management work when checking capacity, even if you hide routine status reports from the client view. For this simplified delivery schedule, the table shows the launch review; planning and weekly reporting are handled separately within the owners' availability. Add kickoff, design sign-off and site live as milestones, using links to the work they mark. Ganttile draws a milestone as a one-day marker, so link each one where it adds no day: Kickoff start-to-start to the interviews and the content audit, Design sign-off finish-to-finish from the designs, and Site live finish-to-finish from the go-live task. Every other link in this example is finish-to-start.

Where do the durations come from?

Estimate each activity with its owner, using comparable past work where possible. Check whether the estimate includes reviews and waiting time; estimating task durations covers the methods.

Example settings: the dates below use working days, with Hide weekends and Auto schedule on in Ganttile, and the milestones linked as described above.

In the redesign the estimates come out like this: four days of stakeholder interviews, five for the content audit, three for the sitemap, five for wireframes, ten for the designs, three for the style guide, fifteen for the page copy, five for images, three for the redirect map, four to set up the CMS, ten to build the templates, three for the forms, four to load the content, five for testing, one to go live and one for the launch review.

The listed task durations sum to 81 working days. That is neither the project duration nor a total of effort hours: some tasks overlap, and some durations include waiting. The dependency network determines the schedule length.

What decides the order, if the outline doesn't?

Ask what each activity needs before it can start. Links can cross WBS branches, and neighbouring items may run in parallel. In this example, Design sign-off sits on the last day of the homepage and template designs; the style guide can finish alongside the build.

With those links, the site goes live at the end of working day 43, Site live sits on that same day, and the launch review takes day 44. The controlling chain runs through the content audit, sitemap, wireframes, designs, templates, content loading, testing and go-live. Page copy, the longest single task, has ten working days of float before loading starts. Finding the critical path explains that calculation.

Two cautions before you trust the end date.

• Link only what really blocks. Out of habit, the style guide could be chained in front of the build, but the templates do not need it to start, so nothing waits for it. The guide to task dependencies covers where to draw links and where to leave them out.
• Check each name down the task list. Ganttile has no resource view, so if Priya ends up with two bars in the same week, the chart will not warn you. Priya's redirect map and image sourcing were placed after the sitemap and the wireframes partly so that they do not overlap.

With Auto schedule turned on under Settings, moving a task moves the tasks its links point to. If the designs run three days long, the templates, content loading, testing and go-live all move with them, and the chart shows the new launch date straight away.

Should you keep the WBS once the chart exists?

On a small team, the chart may become the working schedule, but keep the scope outline if it records agreed deliverables. The schedule table above deliberately omits routine reporting; it cannot replace the full scope record. For contractual work, retain the approved WBS and the mapping from work packages to activities.

When scope changes, update the deliverables first, then the activities, estimates and links. A new careers section may mean pages, an application form, copy and testing. Adding only a "build form" bar misses some of that work.

If someone needs the plan in another tool, Ganttile exports to Excel and Microsoft Project XML as well as PDF and PNG, so the structure travels with it.

Before you break down your own project

How many levels should a work breakdown structure have?

Use enough levels to make scope clear and work packages manageable. A small project may need only a short outline; complex deliverables need further detail. Choose depth based on ownership, estimating and control, not a fixed number of levels.

Can Ganttile draw the WBS as a tree diagram?

No. Ganttile has no WBS view, tree diagram or WBS numbering. Draft the outline in a document or on a whiteboard, then use lists to group the scheduled activities that deliver its work packages.

Do you need a WBS for a small project?

Not as a separate document. For a project of a few weeks, spending ten minutes writing the deliverables as an indented list before you build the chart does the same job: it catches missing pieces, like the redirects or the launch review, before they turn into surprises.

Turn the scope into a workable schedule

A complete breakdown prevents omissions. Activities, durations and dependencies turn that scope into a forecast. Check the owners' availability before accepting the date the chart produces.