Or, How Breakdowns Prevent Breakdowns
If you are a project manager you know about Work Breakdown Structures. You probably consider them remedial reading material. But common WBS errors diminish their value for many practitioners, some of them folks you know.
Six simple rules can make your WBS deliver on its value proposition. It's an ambitious value proposition, to my mind, so that's saying something. We'll get to the value proposition later, but let's start with 6 Rules of a WBS.
None of this is earth-shaking research: it's fundamental. My goal is to set out oft-ignored information in a clear and cogent format makes it hold tight and perform for you.
- The Existential Imperative
First of all, a get-out-of-jail-free card: You can – for absolutely free – stop reading right now and ignore all WBS rules by simply failing to prepare a WBS in the first place. A WBS that doesn't exist needn't follow any rules at all.
Go ahead. It's what some of your friends are doing.
But the power of a disciplined WBS is not insignificant. I encourage you to press on.
- Nouns / Not Verbs
Always and forever, only put deliverables on the first couple levels of your WBS.
- "Requirements Gathering" does not appear on Level 1 of a WBS
- "Requirements Document" does
Only move from deliverables to tasks when you've pushed down several levels, and have gotten to packages so reasonably small and estimable that you can no longer restrain yourself.
We all badly desire to break this simple rule. So let me tackle head-on the two arguments that I think are floating around in our heads and driving us to ignore the best practices we know.
"We don't test to get a test report: we test to increase quality and reduce risk. Including the Test Report rather than the Testing is taking your eye off the ball."
Be honest, none of the steps we perform are for their own sake. They are always in support of a deliverable. Undocumented testing does not stand on its own: would you trust it? An accurate test report does stand on its own. It is a requirement imposed on delivering teams because of the value of the underlying work. To resist inclusion of the report, rather than the work, on Level 1 of your WBS, is to disrespect the imposition of the requirement.
"I already know, for instance, that I need requirements. Writing down nouns tells me nothing. I need to know the detailed steps involved. That's new information."
Please. Cave people thought through and planned steps. That's easy. Children do it. It is far more advanced to break down the deliverable (roasted mammoth steak, for instance) into its component and ancillary deliverables, to validate your action list. Otherwise you end up with a dead mammoth and no fire, or no safe cave to eat in.
- 100% Club: Exhaustive
Each level of your WBS should be exhaustive: every level, on its own, is everything you need to deliver.
The WBS exercise makes us think of completeness in a different way. It provides angle number 2 from which to view our planning. It is important that you review the WBS one level at a time. And on Level 1 you must push your team to accept that if it isn't fairly in any of the Level 1 elements, it isn't in the project.
Making each level exhaustive helps the business spot problems. For instance, if you were migrating a call center, the WBS might help you identify that a decommissioned incumbent is a necessary part of your scope.
- In/Out In Between
A WBS is not just about the core deliverables of a project: it is also for all internal deliverables. Level 1 should include all of the following, where applicable:
- Requirements Documents
- Design Documents
- Test Reports
- Production Deployment Plan
Commonly, core deliverables will be less than half of a good WBS Level 1. But this can be overdone. You have to be the judge of whether every form demanded by a PMO should be considered an internal deliverable on your WBS. As a rule of thumb, if the document reflects a great deal of information, as Design Documents do, or underlying work, as Test Reports do, then include it. If it is only a process or approval form, exclude it.
- Mutual Exclusivity
Nobody will ever produce a Venn diagram for their WBS elements. Elements of a WBS are expected to always be mutually exclusive, with no overlap at all.
In real life, our work will often blend together that which the WBS sees as distinct work packages, as when "requirements for the CRM" and "work station specifications" are documented at the same working session.
This is not a contradiction: the WBS documents non-overlapping deliverables, not tasks. But we aren't cave people. We rightly reorganize distinct deliverables to facilitate execution, killing two birds with one stone where possible.
- Structure (1.1.4)
I encourage everyone to retain the WBS structure, with element labels of the 22.214.171.124.2 variety. I do so with this exception: don't use those WBS labels unless your WBS is in fact providing the structure for your schedule.
In the absence of a logical structure, where 1.1.2 and 1.1.3 combine with 1.1.1 to make 1.1, you are doing nothing – by adding such monstrous labels – except punishing your trusting team with a burden of meaningless numbers.
Also, please – on behalf of that team – don't type WBS element labels into schedule item descriptions. Microsoft Project provides the WBS structure labels automatically (look it up), and they'll automatically adjust and update as changes are made.
Also, a hint: if you like, you can set the "WBS code definition" in Project, to replace numeric codes with human names like "Ops" or "Fixtures & Hardware." This can be a big help if you are working intensely with the business, or a non-technical team. They'll appreciate the courtesy of clear and plain English labels.
A Value Proposition You Can't Refuse
I don't believe much is worth doing that doesn't have a big concept behind it. A properly built WBS has a big idea behind it. If you haven't found the Zen of the WBS, think a bit about what the above rules mean.
A good WBS is a great tool for scope documentation. It allows the business to edit rather than compose. When you are listing tasks, each new task is an act of composition. But when you stand in front of an audience and propose that all we need is a new telephone system and a CRM, your audience doesn't compose, but edits, when it tells you that they also need office space, work stations, procedure documents and so on. Editing is a more natural task, and one people are better at, than composition.
A good WBS is a stronger tool for communicating the value of one's work than a chronological schedule. With a WBS, you can find a team member's task on a structural tree and show how it leads to a deliverable. That's far stronger than finding a task on a discretionary tree that may make little sense to them, and showing how it leads to....the next task.
A good WBS provides more meaningful progress reporting to a non-technical audience with less administrative burden. With a WBS structure, percent complete speaks to "how close are we to having this or that deliverablecomplete." Without such a structure, your statement to management is "how close are we to...the last step." And that creates fear in management: exactly what are going to try to fly without? Wings, fusillage, gas?
Is this remedial material? I don't think so. It delivers value by identifying scope, clarifying the value of work, and easing communications with management. It prevents missed requirements, helps tech teams talk to business, and facilitates a meaningful schedule sctructure. Breakdowns avoid breakdowns.