Rules of Thumb for Creating a Work Breakdown Structure

I think a lot of us have wondered whether our work breakdown structure (WBS) would seem reasonable to our peers. A Redditor on the projectmanagement subreddit recently asked, “How many rows deep is your typical MS Project plan for a complex project lasting 1 year? Am at 1000 rows now. Am I above or below average?”

I don’t think there is a meaningful “average” to cite because a WBS is based on too many specifics. I think a more actionable question is, “Will this breakdown allow us to communicate the work to be done and assess progress and work remaining?” That said, there are a lot of rules of thumb out there for creating a work breakdown structure (WBS). I find these to be generally useful:


  • A task should be something that takes from 2 days to 2 weeks to complete.
  • If you have a small number of tasks assigned to one or two resources that individually take less than 2 days, put them in a checklist and make completion of the checklist a task. Checklists are our friends.
  • If you have a single task that takes more than 2 weeks, maybe it should be divided into smaller pieces. Agile teams commonly break an epic into two or more stories.
  • Think in terms of deliverables. If a task doesn’t produce a deliverable or further the evolution of a deliverable, should it really be a task?
  • If person A produces a deliverable, person B inspects the deliverable, and person C approves the deliverable, you have at least three tasks.

Structuring The Work

  • A WBS should include three types of entries: detail tasks, describing the work to be done; summary tasks, which group detail tasks on some meaningful basis; and milestones, which allow us to note progress based on completion of selected detail tasks.
  • A WBS should be in the form of an outline, with two or more levels of indenture. It is common to have a summary task with multiple child summary tasks, and so on. The term ragged pyramid is descriptive of many WBS.
  • There are two primary audiences for a WBS: the people who will be assigned to perform the tasks (and the people they report to) and project stakeholders who want to understand how the project will affect them. Keep both audiences in mind.
  • Design your WBS for dependencies. If you have six detail tasks under a single summary task, to be performed one after another, and there is a single dependency running from the summary task to the next detail task under some other summary task, it will probably be easier to explain to both audiences than some rat’s nest of links going all over the place.
  • If a summary task only has two detail tasks under it, maybe the details should be merged into one of the peers of the summary task, or moved up to the same level as the summary. Similarly, a summary task with so many detail tasks that you have scroll through them might be a candidate for reorganization.
  • When I have multiple teams working in parallel, I often put each team’s tasks under their own summary task. When they reach a milestone that requires a hand-off to another team, that outbound dependency is located in the top summary task. Especially useful when I have one or more vendors participating.

Considerations for Managing the Work

Make your structure as detailed as needed to facilitate an understanding of the work, but not so detailed that it becomes unmaintainable. If your 1000 row WBS includes 800 or so detail tasks and they average a week in duration, then you will average 16 tasks initiated and another 16 closed out each week over the course of a year. If that doesn’t seem manageable to you, or those assumptions aren’t reasonable, consider your alternatives, from delegating administration of task updates to fissioning into two projects.

If anyone would like to add a rule, or dispute one of mine, leave a comment below.

Because You Purchased …

A couple of months ago, I purchased a copy of Roy Underhill’s “The Woodwright’s Eclectic Workshop” at a bricks-and-mortar store and gave them my Email address. I just got an Email from them with recommendations based on that purchase. The list included six more books on traditional woodcraft by Roy, one on woodworking in colonial America by Keith Wilbur, and “Gun Digest Guide to Concealed Carry Handguns” by Dick Jones.


Still worried about Artificial Intelligence taking your job?


Five Boxes, Three Ways

I read a lot of articles every week in curating these round-ups, and not all of the content is produced by project managers. Probably less than half, most weeks. I see a lot of excellent content from non-project managers, and a lot of gibberish, in about the same ratio that I see from project managers. Not everyone shares the same understanding of project management methodologies, even among the practitioners. I typically use the general classifications “Established” or “Traditional” methods and “Agile” methods while some folks refer to a methodology called “Waterfall.” So, in an effort to over-simplify these three commonly referenced methodologies, I’d like to show five boxes, three different ways.

This first version is frequently referred to as “waterfall.” Back in the 80’s, there were a few projects that were actually run in a fashion similar to this. Most failed, because you have to monitor while executing, or you don’t catch the errors until it’s too expensive to correct them. Ever seen that poster of two teams, building a bridge from opposite shores of a river, getting to the middle and suddenly realizing that they’re not matching up? Yeah, like that.


The second version is the way most projects have been managed for the last few decades: complete the planning stage, and then move on to execution, while monitoring the process and quality as you go. This is especially critical in civil engineering projects, like the apocryphal bridge, but also for those where compliance with some external protocols or requirements is required, or where powerful stakeholders have to be satisfied, or where a lot of sub-contractors, inspectors, or other contributors are involved.


These days, many projects are being run using Agile methods: plan enough to begin execution, monitor more-or-less continuously, and re-plan based on what you learn as you go. This is great for certain kinds of software and consumer product development projects; not so much for civil engineering, pharmaceutical development, and other projects where the product will have a lot of potentially catastrophic failure modes and a very long life.












Note that the contents of the boxes have not changed. Poor execution will doom a project, no matter what else is going on. Initiating the wrong project or starving the right one for resources will generate a negative ROI, no matter how you manage it. And failing to monitor scope, schedule, cost, quality, and the mood of the stakeholders will burn any project to the ground. Simply re-arranging the boxes, like re-arranging the deck chairs on the Titanic, won’t change the outcome. But there will always be people who want to try.