PrintThe Work Breakdown Structure
A work breakdown structure (WBS) organizes project work into manageable tasks which are necessary to carry out and complete the project. The WBS focuses on the work activities, completion of defined deliverables, and the timing of tasks (taking into account all factors and constraints that impact the start and end dates of tasks). The WBS is the "meat" of the plan because it describes the work required to meet project objectives. John Dewey (of the Dewey Decimal System) said, "a problem well-stated is half-solved". The same can be said about a project--clearly stating objectives and defining an approach for project work gets much of the way toward a successful project.
The WBS presents project tasks in a hierarchy, with major (top-level) level tasks and subtasks. Table 5-1 below shows a WBS task hierarchy for a portion of a project involving GIS database design and development. This includes a top-level Task #4 with a WBS task hierarchy 3-levels deep with subtasks and sub-subtasks.
| Task # | Task Name | Plan Start Date | Plan Finish Date |
|---|---|---|---|
| 4 | GIS DATABASE DESIGN, PREPARATION, AND DEVELOPMENT | 2/1/12 | 7/12/16 |
| 4.1 | Base Land Data Standards and Clean up | 2/1/12 | 7/12/16 |
| 4.1.1 | Establish and document data format standards for address and parcel fields. | 3/1/12 | 8/15/12 |
| 4.1.2 | Clean up address, parcel, and zoning fields in database. | 5/24/12 | 12/19/12 |
| 4.1.3 | Clean up address, parcel, and zoning feature boundaries. | 5/24/12 | 12/19/12 |
| 4.1.4 | Revise street name/address filed from street name. | 2/1/12 | 7/12/16 |
| 4.2 | Refinement of GIS Database Design and Rules | 6/28/12 | 7/10/13 |
| 4.2.1 | Evaluate current GIS data organization and define. | 6/28/12 | 12/12/12 |
| 4.2.2 | Redefine Geodatabase/Feature Class organization. | 8/9/12 | 2/6/13 |
| 4.2.3 | Establish attribute schemas for Feature Classes. | 9/6/12 | 3/6/13 |
| 4.2.4 | Define/revise basic geographic parameters. | 9/6/12 | 3/6/13 |
| 4.2.5 | Define and set up logical and connectivity rules. | 10/4/12 | 4/3/13 |
| 4.2.6 | Define default symbology. | 3/7/13 | 7/10/13 |
| 4.3 | Metadata Design and Set up | 9/20/12 | 5/1/13 |
| 4.3.1 | Design metadatabase. | 9/20/12 | 5/1/13 |
| 4.3.2 | Set up ArcGIS metadata templates. | 10/25/12 | 1/30/13 |
| 4.3.3 | Carry out initial population of metadatabases. | 10/25/12 | 4/24/13 |
| 4.4 | Quality Control Standards and Procedures | 10/18/12 | 1/13/14 |
| 4.4.1 | Define/document GIS data quality standards. | 10/18/12 | 5/15/13 |
| 4.4.2 | Define process for QC and QA checks. | 3/7/13 | 10/16/13 |
| 4.4.3 | Institute QC and QA process in database development and maintenance work. | 5/30/13 | 1/3/14 |
Some important terminology is important to understand how a WBS is created:
A summary task is any task in a WBS that has subtasks below it. In Table 5-1 above, the top-level Task #4 is a summary task as are Task #s 4.1, 4.2, 4.3, and 4.4. A subtask is any task below a summary task in a WBS hierarchy. The bottom level subtasks in a WBS hierarchy (no subtasks below them) are called work tasks or work packages. It is important to understand that these work tasks are where the work actually occurs--all summary tasks at upper levels in the WBS hierarchy just serve as headings (like outline headings) to organize the project work. Some other task type terms are used to describe special task characteristics:
- a recurring task is a work task in which a work activity occurs according to a fixed schedule (e.g., planned project status meetings that occur on a specific day at 2-week intervals);
- a milestone task is a work task that either occurs at a single point in time (e.g., submittal of a deliverable) or is presented as a single end point in a task duration;
- a split task is a work task in which there is a defined interval, within the overall task duration, during which no project activity occurs.
Take another close look at the WBS work plan excerpt above in Table 5-1. See the bold text (these are all Summary Tasks). Think of these Summary Tasks like headings in a technical report---that's what they are--just topic headings that organize the project work into groupings of related activities. The real work actually gets done in "Work Tasks" or "Work Packages"--the lowest level of a task hierarchy (e.g., Task 4.2.6). The Summary Tasks then should identify and organize ALL work in the project, and the lowest level Work Tasks should describe how that work gets done. Subtasks under a summary task should cover all work encopassed by that summary task. The trick in preparing a work plan (WBS) for any project is first to see the whole picture (i.e., project objectives and deliverables) and then to figure out how to organize the work in the way that is most efficient.
A WBS for a project may be created as a table (e.g., using Office software like Word or Excel). It has become increasingly popular for project planners to use automated project management software (e.g., Microsoft Project or Project Libre) which provide efficient tools to enter tasks, set the WBS hierarchy, establish timing relationships among tasks, and present the WBS in different types of report or "views" such as a Gantt chart (with bars showing task duration).
The WBS is often created by one of three approaches. With each approach, project planning requires some subject matter understanding about the work being planned and, most often, some research, review of past projects, and communication with other project managers, to estimate time requirements.
The analogy approach uses a similar WBS (prepared for another project) as a starting point. If you are working for a consulting firm that does similar projects for the same client, this approach may be simple and effective. Such an approach is greatly facilitated if the consulting firm keeps good records and has archives of past projects.
The top-down approach begins with the final or largest deliverables. Then, all of the components that make up these deliverables are identified. This process continues to greater and greater detail until all work packages are identified. A project manager attempting to do this alone had better have significant experience or technical background in all aspects of the project. Input from technical team members can also be vital, especially as project activities are mapped to lower and lower levels.
The bottom-up approach involves intense team participation. Members begin by identifying as many specific tasks as possible, and then group these tasks into larger project activities. These project activities may then be grouped into more and more comprehensive activities, until the final deliverables for the project are planned. This approach can be very effective for scope and time planning because it can potentially involve input and consensus from the entire team. For the same reasons, however, it can be a very time-consuming process for putting together a WBS work plan.
Whichever basic approach is used (including some combination of the above), work planning and scheduling demands some serious attention because the efficiency of work and the way in which resources are allocated depend on this. Project work planning gets easier if the organization and the project manager has past experience in similar projects. When handed an assignment for project planning for which the level of experience is not too high, it is important to ask questions, do research, and call on colleagues within and outside your organization to prepare a solid work plan that covers all work in an efficient way. Get a solid understanding of the scope and deliverables and make that WBS task hierarchy fully inclusive of all work and support activties required to get the project completed.
If only one individual is working on a project, time management for the project is pretty simple. However, if a team of individuals is working on the project, timing becomes more complex due to dependencies of work tasks with multiple people contributing to many of the tasks. In projecting timing for tasks, it is important to understand the difference between duration time and resource time. The term duration normally refers to the calendar time from the start of a task to its completion (start and end dates). This is different from resource time--which identifies the actual labor time (usually in hours or days) that a resource (e.g., person on the project team) works on the task or project. Another way to say this is that the duration of a task is its calendar time, which usually is different than the resource time or labor time. A given task (e.g., geodatabase design) may take 10 work days (2 weeks) to complete--including time for review, comment, and revision by multiple people, but the total resource (labor) time from all participants in that task might only be about 36 hours (4.5 work days). So an important trick in planning a project schedule and the timing for individual tasks, is to focus on the duration (calendar time) necessary to start and complete the task--including any time in which actual labor is not being expended.
Key factors that often impact project and task timing and which should be taken into account by a project planner include:
- Relationships among tasks (aka "linkages", "dependencies", "predecessors"): For example, one task cannot begin until another task is completed.
- Fixed dates and date constraints: for example, because of project or external factors, certain tasks might need to start or end on specific dates (e.g., fixed dates for aerial image acquisition).
- Resource loading: depending on the type of project, task timing may be influenced by the amount of resources (e.g., person-hours) that are assigned to a task (e.g., timing may be accelerated by adding more staff time).
- Expected "wait time" or delays associated with certain types of tasks (review and comment period for a document or technical specifications).
- Risk events (e.g., bad weather, technical problems) that have a good probability of occurring and impacting work progress.