Work Breakdown Structure Guidelines (Category K)
The following questions should stimulate thought when developing a WBS to manage the project:
Think through the entire project. (Look at dividing high-level deliverables.)
Think deliverables. (What is to be provided/what is required?)
Think with the end in mind. (How will this component contribute to the finished deliverable?)
Think through the production of the deliverables. (What methods? What special processes? What quality requirements? What inspections?)
Have you formulated a vision of the final product in your mind?
What are its constituent parts?
How do the pieces work together?
What needs to be done?
The following steps describe the general process for developing a WBS:
Step 1: Identify the final product(s) of the project—what must be delivered to achieve project success. A thorough review of high-level project scope documents (inputs such as statement of work [SOW], technical requirements documents, and so on) is recommended to ensure consistency between the WBS and the project requirements.
Step 2: Define the product’s major deliverables, which are often predecessor deliverables necessary for the project, but that in themselves do not satisfy a business need (e.g., a design specification).
Step 3: Decompose major deliverables to a level of detail appropriate for management and integrated control. These WBS elements normally tie to clear and discrete identification of stand-alone deliverable products.
Step 4: Review and refine the WBS until project stakeholders agree that project planning can be successfully completed and that execution and control will successfully produce the desired outcomes.
FACTORS TO BE CONSIDERED
In developing a WBS, the following basic assumptions should be considered:
Each WBS element should represent a single tangible deliverable.
Each WBS element should represent an aggregation of all subordinate WBS elements listed immediately below it.
Each subordinate WBS element must belong to only one single parent (or superior) WBS element.
The deliverables should be logically decomposed to the level that represents how they will be produced (designed, purchased, subcontracted, fabricated). The partitioning of deliverables from higher levels within the WBS to lower levels must be logically related.
Deliverables must be unique and distinct from their peers, and should be decomposed to the level of detail needed to plan and manage the work to obtain or create them.
Deliverables should be clearly defined to eliminate duplication of effort within WBS elements, across organizations, or between individuals responsible for completing the work.
Deliverables should be limited in size and definition for effective control—but not so small as to make cost of control excessive and not so large as to make the item unmanageable or the risk unacceptable.
The WBS development process should provide a vehicle for flexibility, particularly when the scope of the project effort may change. A well-managed project, however, will incorporate a rigorous change control process to document and manage scope changes. When work scope changes do take place, the WBS must be updated.
Each entry in the WBS representing subcontracted or externally committed deliverables should directly correspond to matching entries in the subcontractor’s WBS.
All deliverables are explicitly included in the WBS.
All significant reporting items (e.g., review meetings, monthly reports, test reports, and so on) are included and identified in the WBS.
All WBS elements should be compatible with organizational and accounting structures.
A coding scheme for WBS elements that clearly represents the hierarchical structure when viewed in text format should be used.
Technical input should be obtained from knowledgeable technical subject matter experts (SMEs), and communicated to and validated by other key SMEs assigned to the project.
WBS MEASUREMENT CONSIDERATIONS
It is strongly recommended that project management activities foster measurement of work accomplishment, as opposed to goal achievement by providing an integrated view across project components. Proper linking between the WBS and associated cost and schedule is critical if integrated analysis of cost, schedule, and performance is to be accomplished.
Cost and schedule impacts can be determined only if there is a clear link between performance parameters and budgeted work packages via the WBS. This link is accomplished in order to obtain a “performance budget baseline” or the budget associated at the work package level.
All work in the WBS must be estimated, resourced, scheduled, budgeted, and controlled. The WBS has two parts: the structure and the component definition. It is the mechanism that divides and organizes the work scope into units of work so that each unit can be estimated, resourced, scheduled, budgeted, and controlled while progress is reported.
Where there is a clear link between performance parameters and budgeted work packages via the WBS, the linkage should be made at a high level within the WBS. All work packages can then be associated with the performance parameters.
Separate WBS elements should be included for integration tasks where several components are being brought together to create a higher-level WBS element. By identifying the integration work separately where ever the above occurs, performance measurement information will provide a timely indication that problems are emerging. Cost and schedule variances occurring in WBS elements that contain integration work can also indicate potential future rework in areas that have previously been completed. When these trends are projected, the result could be a far greater impact on revised estimates at completion than from projections of trends in other areas. Technical experts can
provide guidance regarding potential integration problems, which can help the project manager decide whether or not to create these separate integration and assembly (I&A) WBS elements.
Identification and tracking of performance metrics in a disciplined and systematic fashion helps provide significant early warning of potential problems and their nature.
CHALLENGES TO BE CONSIDERED
Challenges associated with developing the WBS include:
Balancing the project definition aspects of the WBS with the data collecting and reporting requirements. (Remember that the primary purpose of the WBS is to define the project’s scope through the decomposition of deliverables.) Each WBS is a tool designed to assist the project manager with decomposition of the project only to the levels necessary to meet the needs of the project, the nature of the work, and the confidence of the team. Excessive WBS levels may require unrealistic levels of maintenance and reporting.
Developing a WBS that defines the logical relationships among all the components of the project. This is generally clarified through the use of a dependency network in the project schedule.
Ensuring the development and utilization of the WBS. Omitting WBS development and proceeding directly to the network diagram (such as a Gantt chart, CPM Schedule, or Precedence Diagram) may lead to unforeseen and unexpected difficulty, including project delay.
Avoiding the creation of WBS elements that are not deliverable-focused (for example, structuring the WBS strictly by process or organization). WBS elements that are not deliverable-focused may lead to project failure.
Defining WBS elements representing opening and closing stages such as planning, assembly, and testing.
Identifying and detailing all key project deliverables (e.g., regulatory permits, packaging, distribution, or marketing).
Preventing the use of WBS elements that define overlapping responsibilities for the creation of a deliverable(s). Each WBS element must have one person who is clearly accountable for its completion.
Identifying key project management work such as:
process management
services and provisioning
information/communication
administrative documentation, training, and software.
Determining Appropriate WBS Level of Detail
Should the WBS be decomposed further? Questions for consideration:
Is there a need to improve the accuracy of the cost and duration estimates of the WBS element?
Is more than one individual or group responsible for the WBS element? While there may be a variety of resources assigned to a WBS element, there should be one individual assigned overall responsibility for the deliverable created during the completion of the WBS element.
Does the WBS element content include more than one type of work process or more than one deliverable?
Is there a need to precisely know the timing of work processes internal to the WBS element?
Is there a need to separately define the cost of work processes or deliverables internal to the WBS element?
Are there dependencies between deliverables within a WBS element to another WBS element?
Are there significant time gaps in the execution of the work processes internal to the WBS element?
Do resource requirements change over time within a WBS element?
Do prerequisites differ among internal deliverables within the WBS element?
Are clear, objective criteria missing for measuring progress for the WBS element?
Are there acceptance criteria applicable before the completion of the entire WBS element?
Are there specific risks that require focused attention to a portion of the WBS element?
Can a portion of the work to be performed within the WBS element be scheduled as a unit?
Is the WBS element clearly and completely understood to the satisfaction of the project manager, project team members, and other stakeholders—including the customer?
Is there a stakeholder interested in analyzing status and performance of only a portion of the work covered by the WBS element?
The Relationship between Project Risk and the WBS
The following questions should be addressed for each WBS element when considering project risk:
Are the deliverables completely and clearly defined?
Will the quality of the work be evaluated through efforts such as testing and inspection?
What is the likelihood of change?
Is the technology changing faster than the project can be accomplished?
Have manpower, facilities capability, availability of internal resources, and potential suppliers been checked?
Is extensive subcontracting expected?
Is management committed to the project and will they provide the support needed?
Are requirements defined and approved?
Has a formal change process been defined and implemented?
Have metrics been defined for how the deliverables will be measured?
Have resource requirements been identified for development of the project deliverables?
Have other risks been identified, including stakeholder buy-in, public relations, management approval, team understanding, and project opposition?
Has a communication plan (internal and external) been defined and implemented?
Are third-party dependencies understood and monitored for change?
Have alternate suppliers of required products, supplies, or expertise been identified?
Resource Planning and Management
In order to prepare for adequate resource planning against the WBS, consider the following when examining the WBS level of detail:
Is all the work planned to a degree of detail necessary to make and keep commitments?
Is there an ability to establish and manage individual work assignments with the reporting structure indicated by this WBS?
Can work assignments be established from a progressive expansion of the WBS?
How will work generally be assigned and controlled?
Will it be possible to reconcile individual work assignments to the formal scheduling system?
How will budgets be established?
Will it be possible to relate the budget to the proposed work assignments?
Is the level of detail in the WBS appropriate for effective planning and control?
Is the work defined by the WBS grouped in a logical manner?
Is more than one organization involved (indicating the need to validate the WBS with others before doing detailed resource planning)?
How will the status of work in progress be determined?