What do you need to consider when building your project’s Work Breakdown Structure (WBS)? There are a number of things to keep in mind when developing the WBS in order to verify that it accurately defines both project and product scope. Here are ten things to think about when building your next WBS:
1. Which approach works best for this project? There are many ways to build the WBS for your project. Most project managers work from the top down, decomposing high-level project phases or products into the bits and pieces needed to get the job done. You can organize the project scope represented by your WBS in many ways, such as by project phase, by functional discipline, or by product.
2. Does the WBS achieve the project objectives? You need to make sure that all project deliverables and activities are included to make up your defined project scope. Don’t forget to include your project management activities and deliverables as well as the more technical work activities and deliverables for your project.
3. Can an owner be assigned for each WBS activity and deliverable? Each item on the WBS should be assignable to the project team manager or team member who is responsible for performing and reporting on that work.
4. Are the tasks or deliverables the proper size to support resource and duration estimating? Be sure to break your WBS tasks down to a level of detail low enough that resource and/or task duration estimates can be developed with the desired level of precision.
5. Has the WBS been created to the work package level to control the project? A WBS containing too few tasks or deliverables limits the project manager’s ability to control their project. On the flip side, a WBS with too many items or too much detail must be over-controlled by the project manager, and can be difficult for the team to deliver.
6. Do all WBS activities and deliverables have unique, understandable names? Make your activity and deliverable names self-explanatory and unique in the WBS. That way there is no confusion about what is being accomplished and created by the project team. Deliverables should be nouns wile activities work best named as a verb-noun phrase, such as “Develop user requirements document”.
7. Are all significant milestones included? Milestones are included in the WBS as a means of tracking high-level progress on the project once it’s underway. At a minimum, this includes a milestone for the end of each phase as well as the end of the project.
8. Are all project management activities across all knowledge areas included? Don’t overlook the project management activities in your WBS. After all, they are also part of delivering the project’s scope.
9. Are lower-level activities and deliverables subsets of their parents? Typically the lowest-level WBS tasks are in the project schedule. A clear, unambiguous hierarchical relationship across the WBS is critical to building a schedule that makes sense, with the summary and lower-level tasks at a similar level of detail.
10. Are external products and activities included in the WBS? There may be external dependencies for the project that impact project scope and success. These external dependencies should be part of the WBS and should be tracked by the project manager.
There are my top ten things for building a WBS, I hope you find them helpful as well. Let me know if you have any questions or additions to the list.