Product Breakdown Structure

Index

The first steps in developing a new project schedule include understanding the project work scope, developing a PBS and OBS, understanding project funding, and reviewing pertinent agreements (e.g. contracts) and project documents.

Project schedules may be the product of both in-house and contractor efforts.

Table of Contents

Product Breakdown Structure

The development of a product breakdown structure (PBS) is crucial to the development of a valid and meaningful schedule and also for an accurate understanding of scope.

A PBS is developed from the SOW or requirements, and a trace between the documents through a SOW/PBS matrix helps to ensure that all work is captured in the PBS. A PBS provides a project structure and a framework for schedule development and financial management. The structure and numbering scheme of the schedule should match the PBS to ensure traceability and consistency in reporting. In addition to providing a framework for planning, the PBS becomes very important by allowing various reporting data to be selected, sorted, and summarized to meet the analysis and forecasting needs of project management.

A good PBS defines the effort in measurable elements for assessing schedule and cost performance. Below are several key characteristics generally found in PBS.

Care should be taken to validate that the total project SOW is included in the PBS prior to establishing the baseline for a schedule.

Building a PBS

Sometimes people have a hard time getting a PBS started because they are not sure what to put at the very top and they are uncertain about how to break the work down from there. Although there are many ways that the PBS can be started, ultimately you want to focus on products (deliverables). If you assume that the top level is the overall project (level 0), then the next level can start to describe the main products. After the products are described, the activities can be defined that are required to build the products. The project schedule is ultimately made up of activities, but the activities need to be listed in the context of the products they are helping to build.

There are a number of options for defining the PBS at level 1 (under the top level 0).

You see that level 1 can start with products or level 1 can describe another way to logically group major portions of the project. However, if you choose another way to initially organise your thinking of the project, you need to transition immediately from there to products and then move to the activities necessary to build the products.

How big should you make an activity?

When the team is creating the PBS, there are usually questions about how detailed the detailed work activities should be. The answer determines when to stop breaking the work down into smaller activities. Part of the answer is to utilise an overall estimating threshold. Other things to take into account include:

Do not make the PBS too tall

If you envision the PBS being built with Post-it notes on the wall, it is important that you not let the PBS get too tall (or too deep). Depending on your PBS approach, it may take you one to three levels to get the products defined. The general rule of thumb is that the number of levels for each product should not exceed five and even five might be too many. Smaller projects may not need more than two or three levels of activities for each product. If you have a very large project, the levels might be deeper. However, there is a point where the detail will be too complex to manage. If you find that you are defining down to five or more levels of activities for a product, stop and evaluate what you are doing. First, you may be defining the work at too low a level. Second, you may have defined your product too broadly. In that case, see if a large product can be broken up into smaller, integrated pieces. The work associated with the smaller products should not require so many levels.

Organizational Breakdown Structure

Many programs/projects require resources from more than one organization or department. The use of a project Organizational Breakdown Structure (OBS) helps to identify the responsibilities, hierarchy, and interfaces between these organizations. An OBS may be established regardless of whether the organization is structured by function, or by matrix assignment. The OBS also identifies the resources available to assign to work activities and to resource load the schedule. When combined with the PBS, the OBS is used to develop a responsibilities assignment matrix (RAM), which clearly identifies which organization is responsible for each task in the schedule. The RAM also helps ensure that no duplication of responsibility occurs. An OBS, if used, should reflect the organizational responsibilities as they pertain to the project. This may differ somewhat from the functional organizational hierarchy.

Once the schedule has been developed, it should be compared to funding availability and profiles. Any conflicts should be identified and resolved through various methods including the reduction of scope, movement of work, or attainment of additional funding. Funding levels will dictate the amount of work scope that can be accomplished.

Change Log

Changes to the schedule are expected throughout the life of the project. The project manager must establish a change management and control process to handle these changes (see Scope management). A change log to record changes to the baseline provides a good method for tracking changes and ensures traceability and documentation of changes to the schedule. Changes to start/finish dates, durations, and relationships between activities are important and should be tracked, especially for changes that negatively impact major tasks and milestones.

Change management and control processess should be recorded in the quality plan.


25 January 2009 (8)