DEVELOPING PROJECT WBS

It is always difficult to suggest that any one activity is the most significant one to support the management and work control processes, but there is heavy evidence from industry researchers that indicates failure to properly define project scope creates problems later and often leads to decreased success rates. One proven technique that has been found to be of broad value in the project planning and control process is the WBS. Our bias is that a properly created WBS is the most important planning and control artifact and it has broad impact across the various project management processes. A well-developed WBS is the best tool available to define and communicate various aspects of scope and status for the project. In this section, we will review some of the key concepts and mechanics related to this activity.

As the project definition moves from a high-level vision-oriented definition of requirements toward the technical “what’s” there is a need to translate the original plain language specification verbiage into something more akin to a structured techni- cal work definition. This translation process is the fundamental role of the WBS. The value of this approach is that it serves as a good communication tool between user plain language requirements and the technical work required to produce those requirements. Both technical and nontechnical groups can understand the result, and it provides a communications bridge to confirm that the stated requirements are being produced by the defined project work units.

Before jumping too deeply into this topic let us illustrate a WBS with a simple example. Figure 12.2 shows how a house construction project can be represented in WBS format.

House Level 0 Level 1 Framing Utilities Project mgt Level 1 (cont.) Landscape Finish work Roofing

Site prep Foundation

Walls

The nine subcomponents are meant to identify major skill and work areas necessary to complete the project. The role of each component is to deliver a defined portion of the overall project requirement. Collectively, these combined boxes represent the total scope of the project. Note that a box dedicated to project management is included in the scope definition since it is a required work activity and consumes resources.

Various sources describe general rules of thumb regarding the WBS construction process. As an example, PMI’s Practice Standard for Work Breakdown Structures pro- vides guidance and sample templates for various types of projects (PMI WBS, 2001). The accepted approach shows the top WBS box with a short name of the project or pro- gram that is being defined. The second level would contain names of the project, project phase, or major subsystem depending on the scope and type of project plan. The third level continues the scope decomposition and by this point, the structure should begin to reflect the major work groups and/or key deliverables. According to the Department of Energy (DOE) methodology, the first three levels of a WBS are

Level 1: Shows major project-end objectives.

Level 2: Contains major product segments or subsections of the end objective. Major segments are often defined by location or by the purpose served.

Level 3: Shows definable components, subsystems, or subsets, of the Level 2 major segments (DOE, 1997).

Even though standard construction rules have logical value for future project com- parison and potential reusability, there is no one right answer for constructing a WBS. Its primary role in the process is to describe the work structure from the eyes of those responsible for delivering the output and that structure is variable depending on project size, technical approach to the effort, and the organizations doing the work. There are several ways to construct a proper WBS structure. Samples of these are the following: 1. Using standard templates from similar recurring project types

2. Modifying the structure used from a similar effort

3. Defining the major work organization groups and then decomposing the struc- ture from the top-down

4. Start with lower-level defined work elements and aggregating them upward into a logically defined hierarchical structure

5. Packaging the structure using the required deliverables as guidance (Schwalbe, 2004, p. 163).

Regardless of the method used or resulting structure, the final WBS view should eventually contain a set of reasonably small WPs at the lowest level. These collections of defined work effort represent the total scope of the project. In other words, proj- ect requirements should be mapped to specific WPs to ensure that all user-approved requirements have been defined in the technical work structure. Envision a WP as a defined and managed unit of work. As another metaphor, these are the molecules in the chemical compound—we might need to expand this analogy to include the view that the human and material resources assigned to these molecules are then the atoms.

As mentioned previously the general sizing rule of thumb for a WP is that it should be approximately 80 h of work and 2 weeks in duration. For large projects this might be too restrictive and for small projects it might be excessive, but it gives a general sizing metric. For operational reasons a WP should normally be linked to a single organiza- tional work group, or at least have a single manager assigned responsibility for the effort.

Scope Management • 129

What is not obvious at this point is that the WP will be the basic item used for detailed planning, execution, and control. In order to construct the project plan, it is necessary to define the related work content, resource requirement, schedule, and budget, plus other requirements relevant to the individual WPs. As the project progresses, actual status will be collected for these items. All WBS summary aggregations above the WP level are simply groupings of their lower level items. Be sure that you have a clear understanding of the WP concepts introduced thus far. These items are the basic technical and manage- ment building blocks for the project and they are the items that must be in place to help drive the project to successful completion.

In addition to the visible project activities related to product delivery, there are other supporting activities that should be reflected in the WBS. A sample of these follows: 1. Developing product approval processes with the future user

2. Project planned meetings (team and external) 3. Team management/customer interfaces activities 4. Quality inspections and defect repair processes 5. Training activities (team and users)

6. Project management activities

7. Project formal communication requirements (status reporting and presentation preparation)

8. Additional project-related management processes that need to be developed (i.e., change control, quality assurance, etc.)

9. Project startup activities

10. Planning for deployment of the project output and ongoing support

11. Creation of future operational service level agreements with outside support groups

12. Project closeout

13. Defining stakeholders involved with the WP

Many of these activities represent key life cycle management decisions more than product work unit specification; however, if issues such as this are not accounted for, the required staffing level will be inaccurate. What this means is that the WBS must also include environmental work activities that on the surface do not look like requirements. These additional items are put in place to improve the probability of success.

The WBS structure is a great tool for showing the basic work organization of the effort, but it is weak on task definition. To supply needed details to this structure a companion document called the WBS Dictionary is used. The purpose of this document is to provide needed descriptive detail for each WBS component. Specifically, the following details should be recorded for each WP element shown in the structure (PMI, 2013, p. 132): 1. Statement of work (SOW) description

2. Codes to support tracking of organizational resources and project financial details (i.e., WBS or organizational accounting codes)

3. Deliverables 4. Acceptance criteria

5. Associated activities/tasks (predecessors and successors) 6. Milestones

7. Responsible organization for the work 8. Resource estimates

9. Start and stop schedules (this may be kept in the Project plan) 10. Quality requirements and metrics

11. Technical reference 12. Contract information

13. Constraints and assumptions (PMI, 2013, p. 132). 14. Risk level

Because of the data-intensive nature of the dictionary items defined above, many organizations skip lightly through this process. It is possible to avoid having a single data source dedicated to document many of these items, but for future ease of access this class of data needs to reside in a formally defined location. If the project plan supporting data is documented in a formal computer-based repository, the internal project team can have ready access to needed work items. Searching for data can be a very wasteful activity for team members. Details related to items such as schedule, budget details, resources, organizational assignments, and task relationships should all be contained in the formal project repository (see Appendix B for more details on the repository).

Each WP requires a SOW that can be used by the assigned resources to execute the requirement. In addition, quality and related technical reference items should also be kept in the WBS Dictionary. The combination of a WBS, its dictionary, and the cor- responding project plan provides a formal communication source for the project stake- holders. Regardless of the data capture strategy, appropriate specification of these data elements is fundamental to the project management activity.

Development of a good WBS structure is not an easy task and the guiding principle is that it helps both the project team and external stakeholders understand how the project is structured. In order to be of maximum value, the project plan structure should map to the WBS, therefore, one approach to developing the WBS structure would be to align it around the development methodology being used. In many cases, there are supple- mental activities that are external to a standard product development methodology. In these cases the project plan becomes a hybrid of the basic technical methodology with supplemental management and support work efforts attached.

Recognize that a WBS will not always be fully decomposed to the WP level during the planning phase. At some point in the planning process, the decision could be made that the requirements are sufficiently defined and then leave further elaboration for the execution phase. This means that some segments of the WBS would contain work units at a higher level of definition than described thus far. This also means that there is a higher potential error in the resulting planned values. These higher-level work units are called planning packages. They have the same general definitional needs as a WP and would be mechanically dealt with as schedules and budgets are derived. Regardless of the work unit level reflected in the planning phase, each box in the structure would be linked to some specified organizational entity. Prior to actual work being performed on a particular unit, a more detailed work unit plan should be completed. This form of plan evolution is called the rolling wave approach.