Free Report: Top 7 WBS Mistakes Project Managers Make
The Work Breakdown Structure is one of those tools in project management that in my experience gets used incorrectly quite a bit. That might be due to how it gets glossed over in many textbooks, or how many people jump right into building one without understanding the fundamentals clearly.
It could also be due to illustrations in the PMBoK Guide text which display WBS Graphics that are completely wrong based on my experience.
Either way, I think it’s a big problem.
I just released a free report that relates heavily to my new training course, WBS Coach. In the free report, I point out the top 7 mistakes I see other project managers make (and that I have made myself) and discuss them in detail. There are other mistakes I’ve seen, but I hold myself back to just the top 7 for this report.
You can get access to the report here:
http://wbscoach.com/7-mistakes
P.S. My materials are not made for test preparation of any kind; they are designed to teach proper WBS techniques and fundamentals, as well as tool-specific video demonstrations, etc. My method most closely aligns with the DoD standard but is scaled for any size project. Where I disagree with PMI or other institutions I point it out specifically in the materials.
Nov 28th, 2009 at 5:08 pm
Josh – Good job on the WBS Mistakes Free Report. Great job bringing focus to this under- and mis-used tool. I’ve downloaded my copy. It will serve well in my PM Fundamentals course to encourage participation in the follow-on course where I’ll leverage your WBS Coach package as the teaching material. Thanks again for the bulk license, BTW.
Reply
Nov 29th, 2009 at 9:02 am
Josh — I would only take issue with one of your “mistakes.” I don’t have a problem organizing a WBS by phase, as long as those phases are product-oriented. In essence, the phase-end deliverable (requirements document, design document, etc.) becomes the product that you are focused on. In fact, I think this is the ONLY way to organize a WBS unless you are responsible for a single phase (e.g., construction, development) where the scope is essentially given to you.
Organizing by phase also requires that you recognize that you CANNOT develop a WBS for the entire project right from the start. How can you possibly develop a complete WBS when the product has not been specified yet? When you are still in the process of discovering and defining what scope is going to be?
USDoD uses a different approach, but that is really (at least in my opinion) because they are using the WBS as a contractor monitoring tool rather than as a project manager tool.
Duncan
William R. Duncan, Project Management Partners
Director of Certification for asapm
Primary author of the original version of “A Guide to the Project Management Body of Knowledge”
Reply
Nov 29th, 2009 at 9:31 am
Thanks for the comment Bill. I don’t recommend phase-based organization at the high levels of the WBS because I’ve seen it lead to missing scope due to loss of focus on
the end product. Perhaps in some environments there are other controls for this, but especially in the informal or less mature PM environments this is a big problem.
I agree that you can’t expect to flesh out your entire WBS in detail initially, in fact I cover this in detail in the training including the sample project walk-through.
I’ve worked for other federal agencies (not the DoD) but I have modeled many DoD practices on my projects. While the WBS was a contract document, it’s function was much broader and very critical to me as the PM.
Reply
Bill Duncan Reply:
November 30th, 2009 at 5:16 am
Josh — if you are running a project with multiple phases (e.g., discovery, requirements, design, development, turnover or something similar), how would you organize the top level of your WBS? DoD says to make it “product-oriented” which works if you have a template telling you what the product breakdown looks like, but this simply forces the phases into a lower level where it is harder to see and coordinate them.
By the way … the DoD WBS standards are oriented toward a single phase (delivery). I once asked a senior DoD Acquisitions official how I could use the DoD standards to develop a WBS for Feasibility Study or a Design project, and his response was “why would you want a WBS for a Feasibility Study?”
I agree that the WBS is a vital project management tool. I was not criticizing the tool; I was commenting on how DoD appears to use it. When you have work packages (the lowest level of a DoD WBS) that span 2-3 months and involve $10 million or more in costs, it’s hard to argue that the CWBS is a project management tool.
Duncan
[By the way ... I tried to embed this comment as a reply to yours, but nothing happened when I clicked the "reply" link.]
Reply
Josh Nankivel Reply:
November 30th, 2009 at 10:08 am
Thanks Bill, it looks like it threaded your comment OK…I’ll keep an eye out for any other issues with the comment threads…
(I’ll spell out acronyms for anyone reading this who may not be familiar with the terms)
So on my last project the major phases were SRR (System Requirements Review), PDR (Preliminary Design Review), CDR (Critical Design Review), Readiness Testing, etc. These occurred at an element level, segment level, ground system level, and mission level.
Part of NASA’s mission WBS was our ground system, and immediately beneath the ground system was its constituent parts, for instance our DPAS segment. Phase-based deliverables absolutely show up underneath, and I’m not saying it’s forbidden to think about phase requirements at all when developing the WBS. We absolutely had to find out what level of maturity and artifacts would be required at the various phases to ensure 100% of the scope was captured.
Phase-based organization is a schedule activity though. On a larger and more complex project like this it’s the IMS (Integrated Master Schedule) interfacing with all of the intermediate and detailed schedules. This is where the phases really come together. It is helpful to have an identifier in the schedule that identifies relationships with phases.
Even (especially?) on smaller projects without an IMS I’ve observed how basing WBS structure on phases (and the other mistakes in my report) take the focus away from the end-result and muddy the waters when it comes to scope/schedule.
Sometimes we’d need to move functionality forward or back based on circumstances…the scope of the project didn’t change, just the timing. I don’t touch the WBS unless the scope of the project is changing.
Thanks for the great discussion here Bill.
P.S. When I said my method aligns most closely with DoD standards, it’s not because DoD standards are the basis of it. I came to that conclusion after my WBS training had already been developed.
I can’t defend DoD’s particular implementation or guidelines (Glen Alleman probably could), but taking a look at them post-hoc it certainly appears I agree more with the DoD guidelines than disagree.
My WBS training doesn’t go into the complexities of large government contracts, it’s meant to be a broader approach that can be used on any length of project. I give some examples from large aerospace projects but also many more from small IT and non-IT projects.
That was a long P.S!
Reply
Bill Duncan Reply:
November 30th, 2009 at 10:33 am
Josh — I don’t think we disagree in any fundamental way. Your project is a subproject where some level of definition has been done by the owner/customer (NASA), so keeping the product components above the phases would be my preference as well.
I only recommend phases at the top when it’s not clear what the scope is. For example, one of the participants in a recent class of mine was the PM for the owner of a major real estate development project. His phases were Feasibility Study, architectural design, front-end engineering design, EPC (engineering-procurement-construction), and turnover. He had these phases at the top of his WBS and added detail to later phases based on the results of earlier phases.
Reply
Josh Nankivel Reply:
November 30th, 2009 at 11:14 am
Ah, I see what you mean. In the example project I walk through in the WBS training something similar is happening. It’s a single WBS, and I show how it develops over time with an example of what it might look like initially, and then again after a significant milestone yields more information.
So I still am recommending steering clear of phase-based organization of the WBS, even in that case. Really, almost all of the projects I’ve managed or helped manage have had a component of this…
Reply
John Greenwood Reply:
December 10th, 2009 at 4:34 pm
Josh, Bill,
I’ve been mulling over the same points about whether phases are the highest level of the wbs for a few days now, spurred on by Cornelius’s review in his podcast, and I still come down aligned with Bill.
If the highest level deliverable is the project, then, as Bill suggests, the next level can be the phases, of which the first may be the requirements phase.
This breaks down into the requirements documentation, together with some sort of strategic approach to testing /demonstration – to scope out the UAT (User Acceptance Test)at an early level. Normally this phase would also include plans for getting to the end of the next phase (say, design).
This is consistent with delivering projects by stages (phases) as per PRINCE2 and the OGC Gated reviews (UK).
The end stage review allows the PM to establish an agreed baseline with all of the stakeholders – acceptance of the work from that stage, and commitment to support the plan for the subsequent stage.
John Greenwood PMP
Reply
Josh Nankivel Reply:
December 10th, 2009 at 5:21 pm
Thanks for the comment John. Of course we disagree with each other on this point, but I want to point out that either way is not problematic re: delivering projects using stages or gates.
My focus is on using the WBS as a scope tool and draw a clear line between scope and schedule this way. What I’ve seen in the past is project managers that jump into temporal thinking too soon when they should be focusing on scope, and because of that missing scope.
Reply
Dec 15th, 2009 at 1:33 pm
All this time I felt I understood the WBS, and I used it to some extent in my projects as the “static” WBS you described in your audio interview. It held great importance for me to define my scope, but I did not use it beyond determining scope!
I freely admit my short-sightedness as a PMP. And that is where listening to broadcasts such as yours are so valuable to serious professionals. Thank you for making this freely available to listen to. I would never have listened otherwise. My thanks to you on an enlightening broadcast, you have significantly changed my perspective on the WBS!
Reply
Josh Nankivel Reply:
December 15th, 2009 at 1:47 pm
That’s awesome David, thank you so much for sharing that feedback with me!
Reply
Dec 15th, 2009 at 3:03 pm
I can appreciate the distinctions in the threads above. But the distinctions are lost, I think, in the smaller, informal (or less formal) project environments where I work and about which I write.
In these informal environments, PMs may be struggling to gain initial knowledge of these tools themsleves or may be struggling to get use those tools effectively in a relatively unsupportive environment. In such cases, I think Josh’s approach has great merit.
By drawing a line around the WBS to focus on scope and deliverables through the project, I think you introduce a lot more opportunity for shared understanding of scope and impact of changes among both project team members and stakeholders. Further, by clearly separating scope tools from scheduling tools, you solved for me a lot of confusion I was left with even after certifying PMP. The one leads much more clearly to the other for me now, and the WBS has much more impact and leverage.
Reply
Jan 26th, 2010 at 12:43 pm
Josh,
First, thanks for all you do for the PM community. Your work is first class and your positive approach/attitude are second to none.
With that said, we’ll have to disagree on this topic. I’ve found it impossible to steer clear of using a phase-based WBS approach when so much of my work is life cycle based, thus inherently phase oriented.
With so many differing opinions (and strongly held ones at that!) and personal experiences, I’m inclined to believe that there is rarely a single right or wrong WBS for any project. That the WBS can be structured differently for any project,and still be “correct”. Use the format that your most competent with … and that best suits the job.
Reply
Josh Nankivel, BSc PM, PMP Reply:
January 26th, 2010 at 5:23 pm
Thanks for the comment Worthey!
I know that one is sensitive, and you can see that Bill and John from earlier comments don’t necessarily agree with me either.
It’s a good point you make about the WBS suiting the job. I do have my own guidelines that I never break, but then again I can’t think of anything else I’m as dogmatic about as the way to do a WBS. It’s actually a bit strange since I’m very open to lots of approaches to just about everything else.
I picture the whole upper level of the WBS moving sideways through phases in the schedule. Phase-specific elements are called out underneath the deliverables and those may light up as the schedule moves on. That’s the way I’ve come to do things after trying both ways, but as you said it’s important to do what works best for you and helps you deliver successful projects.
Reply