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:

Tasks

  • 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.

Advice to New (and Established) Bloggers

Aside

At this writing, I’ve posted over 420 weekly round-ups of content that I think would be of interest to IT project managers. Without counting, I’d guess about 9,000 links. Curating so many lists has naturally led me to some opinions on what makes content interesting. So, here are a few thoughts for my fellow bloggers and other content producers.

  • Visualize your audience and keep them in mind when choosing topics. Write about Why and When and How they can do something useful. Create value for them
  • I generally leave out generic stuff that reads like it was bought from internet copywriters or placed by some marketing team. Be original
  • I also bypass the topics that have already been done to death. Start a new dialog
  • Good search engine optimization technique certainly has value, but it’s no substitute for good content. Don’t let SEO get in the way of what you want to communicate
  • Use facts and diagrams. Provide links to reputable sources. Show your math
  • Don’t make unsupportable claims. Don’t present conventional wisdom as if it were controversial and don’t present the controversial as settled. Maintain your integrity
  • Read your own drafts like a skeptic. Aspire to be valued as a trusted resource
  • Let people know who you are—put your name on your work. If you have a good reason to post anonymously, you can use a pseudonym
  • Post an About page with your biography, a good headshot, and an EMail address that you don’t mind being exposed to the general public
  • Turn on comments on your blog posts. You can meet some interesting people that way
  • I took a lot of the pictures embedded in my posts, including the three on this page. Stock photos are fine, but be willing to expose your personality to your readers. Be willing to be liked
  • You are building your brand. Be mindful of what you say, but express your opinions in a way that will make your readers think. Be interesting
  • It’s good to have well-founded opinions, and most people like reading well-written, opinionated content. Try to say something profound and memorable
  • I regularly include links to opinions I disagree with, and frequently adjoin articles with differing or supplementary opinions in a “point / counter-point” sequence
  • “Omit needless words.” Read The Elements of Style, by Strunk and White
  • Use your spell checker and grammar checker. There are many bloggers whose work would benefit tremendously from proper editing
  • Write clearly—ambiguity is for Christopher Nolan films
  • Sell the good stuff; you don’t need to discredit the alternatives. Take the high road
  • Be insightful. Aspire to be quotable
  • Good expository writing is well-structured. It provides some history, explores the issues and alternatives, convinces, stimulates, and calls to action. Especially if the action is to compose a rebuttal. Aspire to start a debate or even a ruckus

Thanks to all of you who take the time to produce good content—it’s appreciated. And thanks to everyone who reads these round-ups and the other content I post here. I get a lot of enjoyment out of writing this stuff and interacting with the readers. Peace be with you!

Project Management Lessons from Paleoanthropology

In early 1987, a study of 145 mitochondrial DNA samples from women representing a variety of populations, conducted by biochemists and geneticists, was published in Nature. Using a complex analytical model based on mutation rates, the authors determined that all living people have a common ancestor, later dubbed Mitochondrial Eve, who lived in east Africa between 140,000 and 200,000 years ago. This was a blow to the multiregional hypothesis promoted by several prominent paleoanthropologists, which asserted that the fossil record showed continuous evolution over the last two million years in widely distributed locations. But recently, a team of geneticists, paleoanthropologists, and other scientists collaborated to develop a new model. And their approach has important lessons for those of us who manage teams of knowledge workers with diverse specialties.

Acknowledge Biases and Assumptions

Every well-developed knowledge specialty has its own culture, models, methodologies, favored data sources, and assumptions. Consequently, practitioners have biases that reflect their specialty. The scientists in this interdisciplinary team, led by archeologist Eleanor Scerri, wanted to avoid letting their professional biases lead to “cherry picking across different sources of data to match a narrative emanating from one [field].” So, the team met for three days to review each other’s work—challenging assumptions, noting accomplishments and problems, and learning to communicate effectively with their colleagues in other specialties. This process led to a coherent view, goodwill, and mutual respect. Lesson learned: many of our biases arise from deep knowledge in our specialty and confronting them early can facilitate cooperation and team building.

Develop a Common Vocabulary

Paleoanthropologists, geographers, geneticists, and environmental scientists have very different ways of talking about their work. Each field has its own jargon, buzzwords, and acronyms. Scerri noted, “[Our] understanding of findings tends to be influenced by the models and paradigms we have in our heads, which tend to … [affect] how we process new information.” The team had to pool their knowledge in a way that let them share data, methods, and models in a way that didn’t leave anyone out. This required them to adapt their communications to use terminology that was meaningful to the entire group and avoid a dependence on jargon. Lesson learned: time invested in establishing a common vocabulary facilitates understanding and leads to real progress.

Become Accustomed to Conflict

The researchers were able to reconcile their different theories into a cohesive story that accounts for the complexity of the different data points and leaves room for the abundant ambiguity still present. Scerri noted, “Insights from different models can help to shed light on the answers we look for … it’s all about incremental steps and changing perspectives.” Lesson learned: conflict can often be resolved, but even when it can’t, the root of the conflict is often based in some ambiguity. Acknowledging that ambiguity is a step toward a tentative agreement, pending eventual resolution of the ambiguity.

Scerri and her colleagues recognize that, like humanity itself, their model is still evolving. New data and new ideas will inevitably lead to future refinements, and they are fine with that. And that might be the most important lesson of all: you don’t need to be absolutely certain in order to deliver something of immediate and future value.

And if you’re curious, here’s a link to their paper.