You are here: Home Blogs Do You Fall Prey To These 7 Common WBS Mistakes?
Saturday, 05 December 2009 23:28

Do You Fall Prey To These 7 Common WBS Mistakes?

Written by 
Rate this item
(0 votes)

In my career I've seen a lot of project managers and organizations limp along on projects, in ways that could have been prevented with proper use of the WBS tool. There are 7 major mistakes I've seen and want you to be aware of.

This is an abridged version of a free report available at:

Mistake # 1 - Using the WBS as a task list

no_tasks_wbscoachWhen I first began managing small projects, I used a task list to plan and remember what needed to be done. This is NOT a WBS, and it's not nearly as effective as a WBS either. I was making a mistake, and it showed because conversations about scope immediately turned to how, who, and when (tasks/schedule) instead of what (deliverables). A WBS gives you this focus for initial planning and scope control throughout the project.

The level of rigor you go through will vary depending on your project size and type. I have managed projects that lasted only a few weeks, and I used a WBS for them. I've also managed large aerospace projects over 5 years in duration. The more complex your projects are, the more dire your need for proper use of the WBS tool!

Mistake # 2 - Organizing the WBS by org structure

no_org_wbscoachThis is one of those natural intuitions we have as regular people; and we must recognize that and resist the urge as project managers.

Instead of being focused on the output of the project as a WBS should be, some organize it by one of the inputs, the resources doing the work. This takes the focus off the unique product(s) being produced by the project, and leads to unexpected omission of scope.

It can also lead to scope bloat! When you try to plan a project this way, scope can creep in that is not really a part of the end product, and/or isn't really necessary to meet the requirements for your deliverables.

Mistake # 3 - Time-phasing the WBS

This may be my most controversial stance, and I have good reason for holding it.

Some people say it's OK to organize your WBS by the phases of your project. In fact, the PMBOK Guide 4th Edition even has a graphic illustrating a WBS using phases for level 2. I disagree with this approach completely.

no_phase_wbscoachI have seen how this kind of project planning can lead to unstated assumptions and missing scope in your WBS. Again, you must focus on the unique product that is going to be delivered in order to capture all of your scope in the most complete way.

Creating a WBS using these project phases is one of the biggest contributors to "unforeseen" and missing scope that I've come across. That scope eventually gets added on anyway, at a higher cost and with unhappy stakeholders.

Mistake # 4 - A lack of traceability to the WBS

Your newly created WBS should become the foundation for most other planning processes and artifacts in your project. It will also be a living document, something that is updated as scope changes on your project are approved BEFORE they become reality. Wherever applicable, it's altcritical that your project artifacts are traceable to each other. When a change in the WBS occurs, you want to be able to easily find the places in other project documentation that require analysis and updates. When there's a question about some aspect of your scope, you want to easily find all the relevant information about it.

Traceability allows for this. The WBS numbering scheme becomes a kind of common language used for nearly everything else you do on the project, from all project artifacts to general communication and reporting.


Mistake # 5 - No leverage for change control

Say a stakeholder comes to you with a change request. How easy is it for you to know for sure what impacts that change might have? How do you evaluate that? Unfortunately, a lot of project managers use intuition. Intuition is great, but there is a better way. If you've done everything I teach in WBS Coach, it's straightforward.

Remember when I said the WBS numbering scheme should become a kind of common language used for nearly everything else you do on the project?

altWhen the WBS numbering scheme is utilized across all of your project artifacts it is easy for any change's impact to be fully assessed by tracing the change across all of them. The WBS should be the central hub where you can assess what pieces of your project will be impacted by a proposed change, especially if it's an emergency change that needs to be implemented pronto.

Mistake # 6 - No support activities

Some project managers try to include only the things that are directly related to tangible deliverables on their projects, and ignore the support activities that are a necessary part of the project or track them separately.

This is a mistake for several reasons.

I cover Support elements, Project Management elements, and Analytical elements in WBS Coach. These are categories of support elements and they are very important. Activities like these have substantial costs associate with them and a dramatic impact on your projects.

altThe WBS should represent the total scope of your project. Every penny spent should track to your WBS somewhere. Anything outside of your WBS is not a part of your project, period.

Incidentally, you should also capture this work on your basis of estimates. Being complete has saved me more than a few times, like when I was at risk of losing administrative support for my project. When you can point to a place in your WBS, and then a list of tasks with good estimates showing the value being added it becomes easy to defend your team against bad decisions. You can say things like "which of these things are we going to stop doing?" and (through traceability) assess exactly what that means.

Mistake # 7 - Taking the WBS for granted

So you've created a great WBS that captures all deliverables, 100% of your project scope. Congratulations!

Now what?

On a lot of projects, the WBS just sits there. It never gets updated again, or it's just put on a schedule ("we'll check it again in a year and update it.") This approach to utilizing the WBS is almost completely worthless. It's just paperwork.

altUpdates to the WBS should be event-driven. Things like change requests, new information, etc. should trigger you as the project manager to look at your WBS. It's your first stop. And guess what? Changes to your project DON'T HAPPEN unless the WBS is updated to reflect them. The WBS IS your scope control, part of your project management baseline (PMB). It's right there....why do so many project managers "wing it" and leave their WBS to collect dust?


Josh Nankivel is founder of and the instructor for WBS Coach, a work breakdown structure training course including hours of video, audio, and a text book. He has been managing IT and non-IT projects in Computing, Financial Services, Telecommunications, and Aerospace for over a decade. Josh has a Bachelor of Science degree in Project Management, and is PMP certified.

Read 15708 times Last modified on Monday, 14 December 2009 02:40
Login to post comments

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Parse error: syntax error, unexpected end of file in /home/spektmedia/public_html/wp-content/plugins/ccode.php on line 82

Who's Online

We have 245 guests and no members online

Got something to say?