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.
Provide the project management basis for planning, estimating, scheduling, and controlling the project work
Identify all the project work by tasks in a hierarchically structured framework, but not the sequence of how the work will be performed.
Document all tasks that consume resources to define and measure the work required to achieve the project deliverables
Break the overall project objectives and requirements into familiar, manageable activities and tasks
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
Provides a quality technique to communicate and build project understanding with the sponsor and customer team
Facilitates the assignment of project work to ensure accountability for results
Provides the project management task definition and basis for effective reporting and tracking of plan to actual activity and results
The baseline WBS is documented and communicated to others in the analysis work plan and project plan
The current version of the WBS should be maintained in the project notebook
Current copies of appropriate sections of the WBS should be distributed to all those actively involved in the project
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
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:
Divide up responsibility for the individual elements of the project and to relate the work to the resources involved in the project
Develop more accurate time, cost and resource estimates based on the smaller task elements
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:
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:
Project Planning - The planning of scope, project organization and what is to be delivered
WBS Development - Task identification of how the work will be accomplished in a hierarchically structured framework
Project Estimating - The estimating of time, dollars and risk for the project
Project Scheduling - The translation of time estimates into a schedule of the duration of project efforts
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:
Project title - The first (highest) level of the project that states the overall project objective, thus this is level one of the WBS.
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:
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:
Product structure - physical subsystems or components of the project (e.g., hardware, software, testing, services, information, etc.)
Business function - categories of business operations (e.g., order processing, inventory, billing, etc.)
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.)
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".
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."
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.
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.
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.
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."
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.
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.
"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:
What really is a "WBS"
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.
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:
Include all resource-consuming activities
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)
Guidelines for developing the WBS activity statements are:
The WBS and work description should be easy to understand
Since scope of effort can change during a project, every effort should be made to maintain flexibility in the WBS
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:
Define each detail task as an action verb followed by what the action is on or about. Phases and activities are typically only nouns.
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.
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.
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.
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.
Major project milestones should be defined typically for about one a month.
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.
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.
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.
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 encountered when developing a WBS are:
Using only functions, phases or organizational units instead of components or deliverables (inputs vs. outputs)
Forgetting opening and closing segments of work such as planning and assembly
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.
Not including "soft" tasks such as project communication, customer reviews, quarterly presentations, etc.
Often Forgotten Types of Tasks in a Project WBS Include:
WBS Development Steps
The following steps are effective for the development of the project WBS:
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.
Establish the purpose, deliverables, and process for the session.
Start the project discussion by discussing the project description and scope, the customer requirements, and the defined deliverables.
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.
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.
Identify and list all major phases in the project.
Identify and list all major milestones and deliverables in each phase.
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.
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.
Include the project management tasks in the project WBS. A project management checklist is provided on Page 18 & 19 of this process.
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:
Break activities into factual, measurable points.
As part of project control, regularly measure the points to evaluate status of completion.
Set up enough frequent points to minimize the chance of being out of control before the next checkpoint or milestone.
Prepare a task definition worksheet for all selected tasks that need clearer definition.
Identify the type of resource required to do the tasks. This could be the project manager, analyst, programmer, etc.
Number the WBS according to the project coding technique, or use the structure developed in the project management software tool.
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.
Prepare a written document that communicates the results of the session as quickly as possible. Distribute to the project team.
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.
Complete this process by finalizing and documenting the WBS for use in the estimating and scheduling processes.
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:
Tasks which have not been done before.
The task complexity would probably not remain the same if the assigned project resource changes, based on the uniqueness of the particular resource.
A series of similar tasks to be done by different people should be defined in a consistent manner.
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.
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
Keys to Consistent WBS Task Definition
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.
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:
Does the task called "programming" always start and stop in a similar manner?
Does it include a unit test and an inspection?
Are inspections given their own WBS task?
Ways to capture WBS task definitions include:
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.
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:
Level 1 is the summary level and consists of just the name of the project.
Level 2 usually consists of the major phases of the project.
Level 3 breaks the Level 2 phases into smaller, manageable major activities or segments.
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):
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)
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.
Hold reviews with sponsor and customers
Obtain approvals for efforts, documents, and commitments
Research existing materials
Arrange project accounting process
Interview various types of people
Develop the project summary statement
Evaluate the team resource choices
Select the team
Build the team
Organize and hold team planning meetings
Develop the project plan
Communicate project activities
Hold project team meetings
Prepare and present project reviews to management/sponsor
Track project task activities
Monitor plan vs. actual for budget, schedule and tasks
Prepare change orders
Develop project status reports
Managing problem reports
Inspect project team member's work
Obtain written acceptance of all deliverables
Communicate on project issues and questions
Resolve project bottlenecks
Perform final inspections
Prepare closure report/lessons learned
Process final charges to sponsor
Process final billings from others
Notify others of project completion
Close project accounting process
Assign future responsibility for all assets
Implement any project warranties
Complete project notebook
Complete turn-over of all appropriate materials to sponsor/management
Accomplish team recognition
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:
Setting up meetings
Maintain project tracking data (schedule and budget)
Store project files
Schedule travel arrangements
Attend unit required events/meetings
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
Project team meetings
WBS Exit Criteria
The following must be completed to move from WBS development to the project estimating and scheduling activities:
Identification of all tasks to accomplish the project deliverables and milestone events is done
Project scope and requirements are met
Project administration is covered
Project management is covered
Project task rework is handled
Project contingency is handled
Project start and closure activities are covered
For referencing descriptions of project phases for typical WBS statements as a starting point when planning the project WBS
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
For using the WBS with task estimates for the basis of the project schedule
For documenting the project WBS for the entire project through closure in the project plan
For developing the WBS for each change order and updating the WBS, estimate, and schedule as needed
For monitoring the WBS task tracking of the project using tracking reports
Project Tracking and Control
JB Danforth Company Proprietary
"); pop.document.writeln (""); pop.document.close (); count++; }; // -->