A Critique of
Shelly A. Brotherton, PMP
Robert T. Fried, PMP
Eric S. Norman, PMP, PgMP
“Applying the work breakdown structure to the project management lifecycle”
Table of Contents
Aligning with Scope
Going from WBS to Scheduling
To some the Work Breakdown Structure (WBS) can be a burdensome chore. To others it is a necessary tool in which to define the tasks, and only the tasks needed, to complete a project successfully. Today, project managers are discovering the high value associated with creating work breakdown structures (WBS) early in the course of project management and a projects success may be attributed specifically to use of a WBS.
Project Managers know that many things can and do go wrong with projects. Much of the failures can be attributed directly to poor planning, and especially with poor development of a WBS. Ms. Brotherton, Mr. Fried, and Mr. Berman article discusses in detail the concepts and usage of a deliverable-oriented WBS in project management. This paper discusses their views on using a WBS in a project, its development and usage throughout the project, and compares their analysis with the goals of the class syllabus.
The Work Breakdown Structure (WBS) is used in project management to identify and organize the tasks needed in which to complete a project successfully. It only calls for those tasks needed, and only those tasks needed, in which to reach a successful outcome (PMBOK, 2013).
The WBS can be very basic or it can be very sophisticated. WBS’s can be simple, perhaps too simple. The Project Manager (PM) has to be careful not to create a WBS that is too simple that it fails to adequately identify and describe the tasks needed to complete the project. This poorly developed WBS causes misunderstanding, rework, and leads to costly delays. It can also make it difficult to identify when problems arise due to an inability to identify what needs to be done and in what order.
The WBS can also be over-complicated, from decomposing work packages too much so that it over defines how the work is to be done, to having so many work packages with short durations it makes it difficult, if not impossible, to manage.
Ms. Brotherton, Mr. Fried, and Mr. Berman article, “Applying the work breakdown structure to the project management lifecycle” discuss in detail how a deliverable-oriented WBS is applied to a project and focuses on why the WBS is needed while also pointing out some of the pitfalls to be aware of. They point out that project success can be directly attributed to creating a well thought out WBS (Brotherton, 2008). Poorly developed or planned WBS can result in detrimental project outcomes including re-planning, rework, unclear work assignments, scope creep, increasing budget costs, missed target dates, unusable products and/or delivery features. Even worse, you have a very unhappy project sponsor.
When planning a project the project manager needs to determine the work that needs to be done to complete the project successfully. He does this by creating a Work Breakdown Structure (WBS). A WBS is the process of subdividing the project deliverables and project work into smaller and smaller elements commonly referred to as work packages (PMBOK, 2013).
The WBS provides a common framework from which to organize all the work needed to complete the project. A WBS can be made up of different levels with the number of levels determined by the project needs. The first three levels will usually reflect the integrated efforts of the project. Level one, sometimes called the “home” level, concerns the authorization and release of work. Another rule to keep in mind is the 100% rule (Kerzner, 2009). The 100% rule represents 100% of the total work of the project. Each level below the previous level has to add up to 100% of the level above it. Level two is reserved for budgetary information; level three usually involves scheduling. Levels four and lower make up the work packages of the project. The sum of the work of the child level must equal 100% of the work at the parent level. Each level is planned in sequential order identifying dependencies and order of completion keeping in mind that some tasks can be done in parallel to others.
Each of these work packages need to be manageable, independent or have minimal interface with other ongoing elements, be Integratable and measureable. It has to have clearly defined start and end dates. All objectives must be linked to company goals. Responsibilities for each element is determined and assigned using a responsibilities assignment matrix (RAM). The focus should be on deliverables deriving tasks and organizing those tasks into work packages (Brotherton, 2008).
A work package represents a decomposition of the upper level deliverables into fundamental elements where the components are verifiable and measurable. Verifying the level of decomposition only requires doing the amount of work that is necessary and sufficient to complete the deliverable required by the project. Ideal packages are usually 80 hours or two to four weeks in length (PMBOK, 2013).
Aligning with Scope
One important aspect of a WBS is to ensure that each of the deliverables and associated tasks align with the goals of the project and the company. The PM can do this using a scope sequencing process to show dependencies between different elements identified in the WBS. Like in building a house, you need to show the sequence of the different parts of the deliverables identified in the scope of the project; first you need the foundation, then the walls, than the roof. The PM can show this relationship by using a dependency diagram (Brotherton, 2008):
Going from WBS to Scheduling
One issue bothersome to PM’s has always been taking the various levels of the WBS from definition to actual scheduling. Brotherton points out the PMBOK guide shows the PM specifically how to go from a deliverable-oriented WBS to scheduling in five easy steps (Brotherton, 2008).
First: The PM defines the activities. The tools used here are decomposition, rolling wave planning, and expert judgment (PMBOK, 2013)
Second: Sequencing the activities. As just stated, you need to set the order in which the activities are to be done. You do this by identifying the relationships and the dependencies between elements.
Third: Estimating the resources needed. How many people are needed for which task. This part of the process will help with determining the budget for the project.
Fourth: Estimating project durations. Here the PM, using tools like past history and expert judgment, determines how long each task should take. Combined with number three above a total budget can be estimated.
Fifth: Develop the project schedule. With all of the above information, a project schedule can be determined thus documenting the total time it should take to complete the execution portion of the project. Add in a start date and a completion date can be determined.
The WBS is a very important piece of a project. It further defines the scope of the project so that by its completion the sponsor, the steering committee and the project team will have a fully approved understanding of what their project entails. It will provide a detailed description of all the tasks needed to complete the required deliverables within the scope of the project. It will show the sequence in which the work needs to be done. It will be a useful tool in determining the scheduling of the project and for being able to track those activities to ensure the project is on schedule and within the scope and cost of the project since everything within the WBS is trackable (Fleming, 2010).
Brotherton, S. A., Fried, R. T., & Norman, E. S. (2008). Applying the work breakdown structure to the project management lifecycle. PMI. Retrieved from http://www.pmi.org/learning/applying-work-breakdown-structure-project-lifecycle-6979
Fleming, Q. W., & Koppelman, J. M. (2010). Earned value project management. Newtown Square, PA: Project Management Institute.
Kerzner, H. (2009). Project management: A systems approach to planning, scheduling, and controlling. Hoboken, NJ: John Wiley & Sons.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.