Work Breakdown Structure (WBS) Development



Development of a project Work Breakdown Structure (WBS) is an essential practice to successfully achieve quality results in Information Technology (IT) projects. The purpose of the WBS is to develop and communicate how the detailed scope of project work will be performed by breaking it down into manageable levels and tasks for use in planning, estimating, scheduling, and controlling the project work.

Objectives

bm70115.gif
     Provide the project management basis for planning, estimating, scheduling, and controlling the project work

bm70115.gif
     Identify all the project work by tasks in a hierarchically structured framework, but not the sequence of how the work will be performed.

bm70115.gif
     Document all tasks that consume resources to define and measure the work required to achieve the project deliverables

bm70115.gif
     Break the overall project objectives and requirements into familiar, manageable activities and tasks

Benefits

bm70115.gif
     Improves the project team's understanding of how the project scope of work will be accomplished to achieve the sponsor and customer objectives and requirements

bm70115.gif
     Provides a quality technique to communicate and build project understanding with the sponsor and customer team

bm70115.gif
     Facilitates the assignment of project work to ensure accountability for results

bm70115.gif
     Provides the project management task definition and basis for effective reporting and tracking of plan to actual activity and results

Documentation

bm70115.gif
     The baseline WBS is documented and communicated to others in the analysis work plan and project plan

bm70115.gif
     The current version of the WBS should be maintained in the project notebook

bm70115.gif
     Current copies of appropriate sections of the WBS should be distributed to all those actively involved in the project

bm70115.gif
     Updates to the WBS should be incorporated into the project management software tracking tool, milestone reporting on status reports and costs and schedule estimates and reporting

WBS Development Process

Overview

The WBS communicates "how" the "what" of the detailed scope of project work will be performed. A WBS is a deliverable-oriented, coded family tree subdivision of the hardware/software, services, processes, communications and data required to produce the end product or deliverable. The WBS is structured in accordance with the way the work will be performed and reflects the way in which project costs and data will be summarized and reported.

The value gained from the WBS is to more effectively:

bm70115.gif
     Divide up responsibility for the individual elements of the project and to relate the work to the resources involved in the project

bm70115.gif
     Develop more accurate time, cost and resource estimates based on the smaller task elements

bm70115.gif
     Provide a structure from which schedules and status reporting procedures can be established

In WBS development, an important step is knowing "when" to proceed with developing the WBS. A WBS should be developed for the project work in each phase in the project life cycle (refer to the IT Project Process), however, each WBS has a different purpose. A WBS should be used for the Opportunity Identification Phase for initial planning purposes. During the Analysis, Implementation Planning and Implementation Phases, a WBS should be used for planning, tracking against a baseline and metrics reporting. It should be noted that there are two times during the life cycle of a project when a WBS is baselined for tracking and metrics reporting - at the end of the Opportunity Identification and at the end of the Implementation Planning Phases. It is from these baselines that the Analysis, Implementation Planning and Implementation Phases are tracked and measured against. During the Implementation Phase one or more change orders may be needed, making it necessary to re-baseline the sections of the WBS that the scope change impacts (refer to the Change Management Process). The graphic below illustrates the three major timing impacts to the WBS creation and tracking:


 

bm1190.gif
 

Although these are the three major timing impacts to the WBS, the development of the WBS, the estimates and the schedule are generally an iterative series of events, with changes, adjustments and additions as the project team learns more about the project. Therefore, as the project shifts, adjustments may need to be made to specific areas of the baseline plan. For example, if the approach to accomplishing a segment of work has changed, but the total number of hours planned for that segment has not, it may make sense to readjust the baseline plan for those affected tasks. This would not be a "scope" change, but an "approach" change. As a caution, the baseline should not be reset for minor schedule adjustments, but only for major approach changes if necessary. The baseline in which the project is tracked against must be meaningful and add value to the project manager and project team.

Once the technical approach for the project has been determined (e.g. the technology development or supplier evaluation/selection approach and the implementation approach), proceed with the WBS process. This is the second in a four-step iterative process to clearly define how the project will be accomplished, estimate task times and project costs, and determine the length of the project. The process steps are:

bm70115.gif
     Project Planning - The planning of scope, project organization and what is to be delivered

bm70115.gif
     WBS Development - Task identification of how the work will be accomplished in a hierarchically structured framework

bm70115.gif
     Project Estimating - The estimating of time, dollars and risk for the project

bm70115.gif
     Project Scheduling - The translation of time estimates into a schedule of the duration of project efforts

 

 

bm1200.gif
 

 

This approach improves the quality of time, cost, and resource estimates by linking the work effort planning to the estimating process and the scheduling process.

The WBS acts as a vehicle for breaking the entire project work down into smaller elements, providing a greater probability that every major and minor activity will be accounted for. The WBS is developed as the step-by-step plan of how the work will be done (task identification, not task sequence). Once the WBS is created, it is then used as the basis for project estimating (refer to the IT Project Road Map Process and the Project Estimating Process). With a defined WBS, the resources required for each task are determined and the task effort time is estimated. The task effort time is the number of hours required for a resource to actually accomplish a designated task. Total costs are developed for all tasks by calculating resource time by appropriate rates and adding in the associated purchases and overhead costs. These costs are summed up and project contingencies are developed. The result is a preliminary project budget and a task-by-task responsibility outline.

With the WBS and the task effort time, the scheduling process is used to develop the duration or elapsed time for all tasks and the overall project by applying resource availability, task precedence, and resource loading and balancing techniques. The result is the first cut at the project schedule (refer to the Project Scheduling Process). Through an iterative process of evaluation and additions/deletions/changes, the final project baseline WBS, budget and schedule are determined.

Project Management and the WBS

The concepts of the WBS were developed in the late 1960's to enable a project team to create the task identification of all the project work and to display it in a hierarchical structured format. For IT projects, the WBS is the fundamental, botTom up technique for describing the work tasks for successful accomplishment of project objectives.

Discussions with the sponsor, customer team and those involved in the project are essential to the identification of the WBS tasks and the successful development of the project budget and schedule.

Definition of WBS Terms

For the development of a consistent WBS structure format, consistency of project terms is essential. The most important terms are:

bm70115.gif
     Project title - The first (highest) level of the project that states the overall project objective, thus this is level one of the WBS.

bm70115.gif
     Phase - The second major breakdown of the overall project, or level two of the WBS. For IT software development projects, use the recommended life cycle phases defined in the IT Project Process:

bm6053.gif
     Opportunity Identification

bm6053.gif
     Analysis

bm6053.gif
     Implementation Planning

bm6053.gif
     Implementation

bm70115.gif
     Activity - The third major breakdown of the project work, which breaks the level two phases into more manageable segments of major activities. The level three activity could be relatively small and manageable in itself, thus not requiring any further subdivision. Major activities usually result in the development of the deliverables of the project, as defined in the analysis work plan and project plan.

The major activities or segments may be structured in the following ways:

bm6053.gif
     Product structure - physical subsystems or components of the project (e.g., hardware, software, testing, services, information, etc.)

bm6053.gif
     Business function - categories of business operations (e.g., order processing, inventory, billing, etc.)

bm6053.gif
     Combination - physical locations or divisions

The four guide phases may exist for each of the major work areas (such as having a full four phase sub-project individually for accounts receivable, accounts payable and payroll). Alternatively, the work areas may be categorized under each guide phase (accounts receivable, accounts payable and payroll are all under opportunity identification, analysis, etc.)

bm70115.gif
     Detail Task - The fourth, fifth, or further breakdown to the lowest level of work, which reflects the detail work that results in deliverables or end items. These deliverables may be actual project deliverables or produce smaller sub-components of the project deliverables. A discrete task consists of those work steps needed to produce a task deliverable. PMI is now referring to detail tasks as "work packages".

bm70115.gif
     Global Task -A global task is an overhead task that is normally dependent on the length of the project. These are often called "bucket" or "on-going" tasks, since they are usually on-going throughout the life of the project. An example of a global or on-going task is "Project Management."

bm70115.gif
     Summary Task -The roll-up of tasks into an activity or phase level with no assigned resources. The estimated effort hours of work for a summary task should be the roll-up of the work for the detail tasks underneath. This type of task can be at any level except the lowest level of task definition.

bm70115.gif
     Rework Task - The project team should incorporate sufficient time for reworking items that had already passed through inspection. Plan for at least ten percent of rework time in software development. The actual rework percentage may be somewhat higher where requirements will tend to change or where a new development approach is employed. Rework should not be a part of each task. It is identified as either a separate task for each deliverable or as a "bucket task" for major areas of the project, such as design or coding.

bm70115.gif
     Contingency Task -The project team should incorporate sufficient time for schedule delays or slippages that are planned to be incurred based on identified areas of risk. Contingencies are schedule "reserves" that are held to cover the negative impacts of the risk items. A contingency task should be built into the schedule at points deemed by the project manager and project team to be areas of risk, such as delays due to document approval cycles.

bm70115.gif
     Milestone - A significant event in a project at a point in time with no duration of its own. A milestone is the summary point of the tasks needed to produce it. Milestones are associated with a group of tasks necessary to achieve the significant event. In this way, the project team can easily recognize the number of tasks that needs to be completed to achieve the milestone. It is important that the milestone be an event marker (with no duration and resource), rather than a significant task. Event markers (milestones) can also indicate the entry and exit points of specific phases or activities in the project. Milestones can be easily described in a "noun-verb" (past tense) syntax; opposite from a task "verb-noun" (future tense) syntax. For example, the detail task may be to "Develop Project Plan" and the milestone would be "Project Plan Completed."

bm70115.gif
     Deliverable - A product of one or more tasks that satisfies one of the objectives or requirements of the project. A project deliverable must be delivered to the designated customer and accepted by them to be complete.

bm70115.gif
     Baseline - The purpose of project scheduling is to establish the baseline from which to measure resource time and performance against project scope. In addition, it provides a representation of the overall time for the tasks needed to accomplish the approved scope. The baseline plan is the original plan used to track progress during a project. The baseline plan includes task start and finish dates and resource and cost information. By comparing the information in your baseline plan to current information, you can monitor the progress of your project to ensure that tasks are on schedule, resources are completing their work in the time allocated, and costs are not exceeding your budget. A baseline should be established as part of the approved Analysis Work Plan and Project Plan documents. It is from this baseline plan that the Analysis and Implementation Planning and Implementation Phases of the project will be tracked and measured against.

bm70115.gif
     "Glumps" - As a special acknowledgment to Chuck Tom's (former JB Danforth Company Project Manager) frequent use of the term "glumps" in describing project work, Jeff Jacobs coined this definition as an appropriate addition to our WBS terms - Gathering of Large Undefined Masses of Project Scope.

Starting Your WBS

When starting a project WBS, the tendency is to try to accomplish everything at once. To begin, the project team needs to understand:

bm70115.gif
     What really is a "WBS"

bm70115.gif
     How the WBS is then used for project management estimating, scheduling, and tracking

A WBS is not just a "list" of tasks. Each task and grouping of tasks must be based on a scope definition and a deliverable that can later be estimated for required resources and effort time needed to complete.

General Guidelines

Once the project team has defined the scope of the project, the project deliverables and customer requirements, the next step is to develop all WBS statements for the project activity that:

bm70115.gif
     Include all resource-consuming activities

bm70115.gif
     Cover all project deliverables

Then, the process is iterated until all tasks are discrete, measurable, and complete.

The WBS "statement" consists of the coded hierarchical number, the task/activity description and the resource type (unless specific resource is known) assigned to the task. (See Example)

bm1210.gif
 

Guidelines for developing the WBS activity statements are:

bm70115.gif
     The WBS and work description should be easy to understand

bm70115.gif
     Since scope of effort can change during a project, every effort should be made to maintain flexibility in the WBS

bm70115.gif
     The WBS can be used to segregate recurring from nonrecurring tasks and costs

The function of the WBS is not to identify the sequence of the work and task dependency (or precedence) that is developed as a part of preparing the schedule and PERT chart. Tasks should be small, well-defined groupings of work steps with a clear start and completion. Tasks that continue for weeks or months, without measurable progress checkpoints, are not easily estimated and provide no visibility that a problem exists. Wherever possible, redesign long work tasks by breaking them down into the next level of detail. Utilize a review, status report, interim test, or some measurable break as a technique to establish a preliminary deliverable for the first part of the divided task.

Specific Task Guidelines

The most important guidelines for effective task management is the way in which the tasks are defined. WBS best practices for preparing the WBS tasks are:

bm70115.gif
     Define each detail task as an action verb followed by what the action is on or about. Phases and activities are typically only nouns.

bm70115.gif
     Define a detail task that is at least two hours (usually effort time). Minimize the number of tasks that are below eight hours. Generally, tasks that are 8 to 40 hours of effort time are the most manageable.

bm70115.gif
     Limit a detail task to a maximum of 80 hours (usually effort time). For tasks in the immediate future of the project, it is best to keep the tasks less than 40 hours for tracking and control purposes. Tasks that are farther out in the project time frame or that are less defined should be less than 80 hours.

bm70115.gif
     If a detail task requires more than one resource to accomplish it, generally break the task into sub-tasks for each individual resource. The task hours, resource assignment and costs need to be identified clearly for each task in order to effectively develop the schedule using a project management software tool. This is also typically needed as each resource will not be working on their part of the task for the same amount of hours as the others. An exception would be a task in which all resources are performing the same task at the same time, and spending the same amount of effort, like a specific meeting or training class where all resources attend.

bm70115.gif
     Specify a measurable deliverable or component of a deliverable for each task. Typically, the size of a task or grouping of tasks should not be greater than five to ten days in duration without measurable milestones for progress measurement.

bm70115.gif
     Major project milestones should be defined typically for about one a month.

bm70115.gif
     Develop a coded task hierarchical structure for the project WBS. If a project management software tool is being used, this will often be done auTomatically.

Depending on where the team is in the project life cycle, the level of detail that can be developed for each of the WBS phases will vary.

bm70115.gif
     In the Opportunity Identification phase, the WBS for this phase should be prepared in detail, but later project phases may only be definable in a conceptual way with only certain deliverables specified.

bm70115.gif
     When preparing the analysis work plan document at the end of the Opportunity Identification phase, the document should contain the detailed WBS for the Analysis and the Implementation Planning phases of the project, and only a high level view of the Implementation phase major activities.

bm70115.gif
     During the preparation of the project plan in the Implementation Planning phase, the document shoud contain a high level view of the WBS from the start of the project to the current point. The Implementation to project closure should consist of a detail view. This detail WBS is then a part of the approved project plan document.

Common Problems

Common problems encountered when developing a WBS are:

bm70115.gif
     Using only functions, phases or organizational units instead of components or deliverables (inputs vs. outputs)

bm70115.gif
     Forgetting opening and closing segments of work such as planning and assembly

bm70115.gif
     Using too much or too little level of detail. Tasks that are unclear or too broad will leave little ability to track and measure true progress and tasks that are too specific will cause the time sheet and reporting process to become too tedious and time consuming.

bm70115.gif
     Not including "soft" tasks such as project communication, customer reviews, quarterly presentations, etc.

Often Forgotten Types of Tasks in a Project WBS Include:

bm1220.gif
 

bm1230.gif
 

WBS Development Steps

The following steps are effective for the development of the project WBS:

bm70115.gif
     Gather the project team into a large room for a brainstorming session. Include project consultants, suppliers and customer representatives in the WBS development where feasible.

bm70115.gif
     Establish the purpose, deliverables, and process for the session.

bm70115.gif
     Start the project discussion by discussing the project description and scope, the customer requirements, and the defined deliverables.

bm70115.gif
     Review the IT Project Process and other qualified resources and documents to leverage the experience of others. Utilizing actual and Form or Standard Document Template WBS task statements are an advantage to help start the thinking process.

bm70115.gif
     Use Post-it notes, wall charts or other idea-gathering techniques to first conceptualize the project work to be done. This technique needs to be free thinking and visual to the project team, with some direction and structure from the project manager.

bm70115.gif
     Identify and list all major phases in the project.

bm70115.gif
     Identify and list all major milestones and deliverables in each phase.

bm70115.gif
     Identify and list all tasks required to achieve each specific milestone and deliverable. Concentrate on the description of the tasks to produce the project milestones and deliverables. Ignore time or logical sequence in the early development. Break into sub-teams to have small groups work on various sets of milestones or deliverables.

bm70115.gif
     Combine the small, similar or related tasks into activities. Include all efforts that consume resources. Include all efforts that are needed to produce each of the deliverable items.

bm70115.gif
     Include the project management tasks in the project WBS. A project management checklist is provided on Page 18 & 19 of this process.

bm70115.gif
     Develop a significant number of reference points between milestones to measure the progress of the project. These are called frequent factual checkpoints. Accomplish this by the following:

bm6053.gif
     Break activities into factual, measurable points.

bm6053.gif
     As part of project control, regularly measure the points to evaluate status of completion.

bm6053.gif
     Set up enough frequent points to minimize the chance of being out of control before the next checkpoint or milestone.

bm70115.gif
     Prepare a task definition worksheet for all selected tasks that need clearer definition.

bm70115.gif
     Identify the type of resource required to do the tasks. This could be the project manager, analyst, programmer, etc.

bm70115.gif
     Number the WBS according to the project coding technique, or use the structure developed in the project management software tool.

bm70115.gif
     Add in task identifiers in task descriptions where the same task name is used in various segments, i.e. "Perform unit test" for various modules would become M1 - Perform unit test, M2 - Perform unit test, etc.

bm70115.gif
     Prepare a written document that communicates the results of the session as quickly as possible. Distribute to the project team.

bm70115.gif
     Continue the refinement of the WBS until the project team reaches consensus on the tasks required to accomplish all of the project objectives and produce all the project deliverables. Plan on numerous iterations of the WBS process in early development efforts.

bm70115.gif
     Complete this process by finalizing and documenting the WBS for use in the estimating and scheduling processes.

bm70115.gif
     Use the estimating matrix spreadsheet or a copy of the current WBS to begin the transition of the WBS to the project estimating process. The spreadsheet includes the traditional elements of a WBS, such as the task number, task description, resource type, as well as task estimating parameters.

WBS Task Definitions

The best practice for developing task consistency and clarifying expectations in detail is to prepare a task dictionary. The task dictionary is the collection of the project task definitions (see the next page for the task definition worksheet format). However, not all tasks require a task definition. The following logic describes when the task definition adds value:

bm70115.gif
     Tasks which have not been done before.

bm70115.gif
     The task complexity would probably not remain the same if the assigned project resource changes, based on the uniqueness of the particular resource.

bm70115.gif
     A series of similar tasks to be done by different people should be defined in a consistent manner.

bm70115.gif
     Unique tasks, where the task includes elements/steps that most people would not normally do for this task or excludes what normally would be done.

bm70115.gif
     Tasks to be accomplished by people outside of the group/team, where the control of the effort is minimized. This could be a business group or a service supplier, but would not typically be for a contractor or supplier as their work should be defined in their contract. If the work was not defined, then task definitions could be applicable.

WBS Task Definition Worksheet

bm1240.gif
 

Keys to Consistent WBS Task Definition

bm70115.gif
     Clear definition of task entry and exit criteria; that is, the elements required before a task starts and the definition of a task deliverable that signifies the task is complete.

bm70115.gif
     The specification of assumptions in task content.

For example, as the estimator develops the tasks for programming efforts, the following questions should be answered consistently:

bm70115.gif
     Does the task called "programming" always start and stop in a similar manner?

bm70115.gif
     Does it include a unit test and an inspection?

bm70115.gif
     Are inspections given their own WBS task?

Ways to capture WBS task definitions include:

bm70115.gif
     Documenting each task definition using the task definition worksheet format. This format can be found in the Form or Standard Document Template section in PM Guide.

bm70115.gif
     Electronically capturing task definitions using the "notes" field in MS Project or a similar text field in a project management software package. These text fields can be printed along side their respective task for ease of communication.

Assistance with WBS Development

The JB Danforth Project Office can provide several helpful sources of information and tools to assist the Project Manager and project team in WBS development. For example, PM Guide contains sample Form or Standard Document Template WBS's using MS Excel for each of the four project phases. These sample Form or Standard Document Template WBS's can also be obtained in MS Project format. The JB Danforth Project Office can also provide a standard preset MS Project file containing standard views and calendar default settings for consistency and convenience. Also available is a reference library of WBS examples developed by other projects using similar technologies and approaches. The JB Danforth Project Office can also refer you to a Project Planning Analyst, a function of the JB Danforth Project Office , who can provide WBS development support. For example, the Project Planner can assist with facilitating a WBS brainstorming session, provide WBS examples applicable to your project, provide expertise based on past experiences with other projects and provide assistance in developing the WBS using MS Project.

Communicating the WBS

A consistent coding of the tasks, activities and phases is an effective way to build and display the WBS format. The planning of project levels and consistent coding of these levels also enables easier summations, billing, and tracking of task activities.

The level of information that is communicated in the typical WBS levels is:

bm70115.gif
     Level 1 is the summary level and consists of just the name of the project.

bm70115.gif
     Level 2 usually consists of the major phases of the project.

bm70115.gif
     Level 3 breaks the Level 2 phases into smaller, manageable major activities or segments.

bm70115.gif
     Level 4 and below will reflect work packages that result in deliverables or end items. Of course, a Level 3 item could be relatively small and manageable in itself, not requiring any further subdivision into a lower level.

In a typical analysis work plan and project plan, a two-level WBS is typically displayed in an outline format in the executive summary section. In the project approach / methodology section, a three-level outline format WBS is typically used. A more detailed WBS should be included in the appendices section of the project plan, as appropriate.

Typically, IT projects will be defined to at least Level 3, and not be more detailed than Level 5 or 6. The rule is to drive the WBS to at least one level lower that the project manager wants to manage. The project leaders or team members then manage the lower level, or greater if they desire. The level of complexity of the WBS changes with the type of project, the project team involved, and the customer requirements and deliverables.

Outline format for a four-level WBS hierarchy (sample from MS Project):

bm1250.gif
 

Organization chart format for a WBS hierarchy

The organization chart technique to develop and display the project WBS is used where the project team has a greater comfort level with visual "organizational view" graphic versus the previous outline of tasks. For those project teams using the IT standard project management software tool, however, it is best to develop the tasks in outline form, then enter into the software, and obtain outline display formats from the software. Currently MS Project cannot provide organization chart format displays.

 

Summary Level WBS Format Organized by Phase (sample from MS Project)

(Note - Showing WBS outline levels 1, 2, & 3 only)

bm1260.gif
 

WBS Project Management Checklist

The following project management activities and tasks should be included in the development of the WBS for most projects. For scheduling purposes, use a project management task "bucket" for those activities that do not have a defined deliverable for the project manager. For example, taken from the list below, "Communicate project activities" would be included in the overall project management task. These are lumped together into a task bucket, assigned to the Project Manager, with an assigned number of hours that typically covers a phase worth of effort time. An example, of a project management task that has a defined deliverable, again taken from the list below, would be "Develop the Project Plan". This would be a stand alone task, separate from the project management bucket task. The scope, frequency of tasks, and timing for the tasks will vary with the extent of the project and degree of project management being utilized.

bm70115.gif
     Project Planning

bm6053.gif
     Hold reviews with sponsor and customers

bm6053.gif
     Obtain approvals for efforts, documents, and commitments

bm6053.gif
     Research existing materials

bm6053.gif
     Arrange project accounting process

bm6053.gif
     Interview various types of people

bm6053.gif
     Develop the project summary statement

bm6053.gif
     Evaluate the team resource choices

bm6053.gif
     Select the team

bm6053.gif
     Build the team

bm6053.gif
     Organize and hold team planning meetings

bm6053.gif
     Develop the project plan

bm6053.gif
     Communicate project activities

bm70115.gif
     Project Control

bm6053.gif
     Hold project team meetings

bm6053.gif
     Prepare and present project reviews to management/sponsor

bm6053.gif
     Track project task activities

bm6053.gif
     Monitor plan vs. actual for budget, schedule and tasks

bm6053.gif
     Prepare change orders

bm6053.gif
     Develop project status reports

bm6053.gif
     Managing problem reports

bm6053.gif
     Inspect project team member's work

bm6053.gif
     Obtain written acceptance of all deliverables

bm6053.gif
     Communicate on project issues and questions

bm6053.gif
     Resolve project bottlenecks

bm70115.gif
     Project Closure

bm6053.gif
     Perform final inspections

bm6053.gif
     Prepare closure report/lessons learned

bm6053.gif
     Process final charges to sponsor

bm6053.gif
     Process final billings from others

bm6053.gif
     Notify others of project completion

bm6053.gif
     Close project accounting process

bm6053.gif
     Assign future responsibility for all assets

bm6053.gif
     Implement any project warranties

bm6053.gif
     Complete project notebook

bm6053.gif
     Complete turn-over of all appropriate materials to sponsor/management

bm6053.gif
     Accomplish team recognition

Administration Tasks

bm70115.gif
     When planning project tasks, be sure to distinguish between the project management type of tasks and administrative types of tasks. Administration tasks are often referred to as global or on-going tasks and would include such tasks as:

bm6053.gif
     Setting up meetings

bm6053.gif
     Prepare timesheets

bm6053.gif
     Maintain project tracking data (schedule and budget)

bm6053.gif
     Store project files

bm6053.gif
     Schedule travel arrangements

bm6053.gif
     Attend unit required events/meetings

bm6053.gif
     Ordering supplies

These are also typically lumped together into a bucket task, assigned to each project team member, with an assigned number of hours that typically covers a phase worth of effort time.

Other Examples of On-Going Tasks

bm6053.gif
     Project team meetings

bm6053.gif
     Travel

WBS Exit Criteria

bm70115.gif
     The following must be completed to move from WBS development to the project estimating and scheduling activities:

bm6053.gif
     Identification of all tasks to accomplish the project deliverables and milestone events is done

bm6053.gif
     Project scope and requirements are met

bm6053.gif
     Project administration is covered

bm6053.gif
     Project management is covered

bm6053.gif
     Project task rework is handled

bm6053.gif
     Project contingency is handled

bm6053.gif
     Project start and closure activities are covered

See also:

For referencing descriptions of project phases for typical WBS statements as a starting point when planning the project WBS

Project Process

For developing a WBS for the Analysis and Imp. Planning phases and document in the Analysis Work Plan

Analysis Work Plan

For developing the WBS as the basis for project estimating

Project Estimating

For using the WBS with task estimates for the basis of the project schedule

Project Scheduling

For documenting the project WBS for the entire project through closure in the project plan

Project Plan

For developing the WBS for each change order and updating the WBS, estimate, and schedule as needed

Change Management

For monitoring the WBS task tracking of the project using tracking reports

Project Tracking and Control

 

JB Danforth Company Proprietary