"For enghanyez"

wllks

06ch_barkley_management.pdf

Home >Business & Finance homework help >Operations Management homework help >"For enghanyez"

6 Work Breakdown Structure and Scheduling

Cavan Images/Stone/Getty Images

Learning Objectives

By the end of this chapter, you will be able to:

• Discuss the creation of a project work breakdown structure.

• Describe the scheduling process.

• Explain how to create schedules.

CO_CRD

CO_LO

CO_TX

CO_BL

co-cn

co-cr

co-box

co-intro

co-photo

bar81677_06_c06_173-198.indd 173 9/9/14 10:52 AM

Section 6.1 The Work Breakdown Structure

Pretest

1. To prepare a work breakdown structure for a project, the project manager starts from the project’s end point and works backward. a. True b. False

2. Project schedules can act as constraints rather than efficiency tools. a. True b. False

3. Using a project template is recommended for simplifying the scheduling process. a. True b. False

Answers can be found at the end of the chapter.

Introduction If you have ever been part of a team effort where it was unclear who was doing what, then you have experienced the consequences of not planning out project work. When a team takes on a project, there must be a plan for the work, a way to identify all the work tasks that must be done in sequence to produce the project deliverable. In project management, this is called the work breakdown structure. The WBS is the “what” in the question of who does what. Later, team members are assigned to the work, but the first step is deciding what the work is.

This chapter will cover the process of defining and breaking down project work and schedul- ing work tasks and milestones. It will focus on the WBS and scheduling process and the issues involved in effective scheduling. This is important because outlining what needs to be done to produce a project’s requirements and deliverables is a proven technique in producing a suc- cessful project. This process of breaking down project work is a bread-and-butter function in the project management field.

This chapter covers the definition of project work using a top-down WBS and scheduling the work from the bottom up. It will illustrate the process and identify ways to reflect risk and uncertainty in the scheduling process.

6.1 The Work Breakdown Structure A WBS is a valuable description and documentation of the work involved in producing the project deliverable. Sometimes the WBS is easy to define, but in more complex projects it is a complicated and detailed listing of work tasks, milestones, and resources (resources include personnel, materials, equipment, supplies, facilities, and other assets used in a project). The WBS is the structure of the work, not the components of the product. Although some work is directly related to product parts, the purpose of the WBS is to enable an accounting of the costs of the project and the sequence of work activity and resource use so these can be scheduled.

sec_n sec_t

bar81677_06_c06_173-198.indd 174 9/9/14 10:52 AM

Design Develop Get

acceptance Deliver

New information system

Top-level tasks:

Subtasks: Package

and deliver

Concept Draft Create model

concept

Create product

Test Get

acceptance

Project deliverable:

Section 6.1 The Work Breakdown Structure

Breaking down project work, sometimes called decomposition, and getting commitment to the work as described is complicated because it involves working with people. The WBS and scheduling process is not linear and routine, but rather dynamic and sometimes even coun- terintuitive. The process should engage the project team members in thinking through their roles and the project process as a whole. It should raise issues of change and innovation, of new ways of doing their work, and applications of new technologies and tools to speed up the flow of work. Most customers and clients of project work expect the project team to exceed their expectations. Figure 6.1 shows an example of a WBS.

In this example, top-level tasks are shown in a flow of work to produce the deliverable. Lower level tasks are shown supporting the production of each top-level task.

The way in which a WBS breaks down project work and tasks can encourage collaboration and innovation. A WBS can enable high performance when work task definitions stretch team members to be creative, collaborative, and efficient in accomplishing them.

If the WBS is out of line with the real work—that is, the tasks are unclear and fail to include the goals and objectives of the work—the task definition and schedule can lead team mem- bers to underestimate the effort necessary to accomplish project goals, especially if the task

Figure 6.1: Work breakdown structure for development of new

information system

In this work breakdown structure, a new information system is developed through top-level work tasks defined as design, develop, get acceptance, and deliver, all supported by lower level subtasks.

Design Develop Get

acceptance Deliver

New information system

Top-level tasks:

Subtasks: Package

and deliver

Concept Draft Create model

concept

Create product

Test Get

acceptance

Project deliverable:

bar81677_06_c06_173-198.indd 175 9/9/14 10:52 AM

Section 6.1 The Work Breakdown Structure

requires collaboration and interdependence with other project team members. This can lead to performance and morale issues down the road because the real work of fitting the task into the project process is undefined.

Sometimes the biggest challenge in project management is identifying the necessary tasks and functions that must be carried out to complete the project deliverable. Especially in complex projects, it is easy during the planning process to miss some tasks that turn out to be critical to the project. To make sure all tasks are included in project planning, it is useful to prepare a WBS and schedule early and to distribute these to obtain feedback from all the project players.

Four Levels in a WBS

There can be four (or more) levels in a typical project work breakdown: task, subtask, work package, and level of effort. The task is the highest level, denoting the major milestones in the project; subtasks are the next level down, with more detailed work below subtasks termed work packages; and individual or small group work tasks called levels of effort.

For instance, in a building construction project, the first level, or tasks, would be to complete the building design. The subtasks include preparing the building requirements document and the building blueprint. The third level, work package, involves conducting meetings and focus groups with customers and users in order to outline their needs, and locating blueprint templates for the type of building being constructed. Finally, the last level, or levels of effort, includes hiring and assigning the layout technician and facilitators for focus groups.

Rolling up this list, you first must hire people to do the work (level of effort), then conduct meetings and find templates for the building design (work package), then prepare the require- ments document and blueprint (subtask), in order to complete this task, or building design.

Backward Mapping

Preparing a WBS requires a technique called backward mapping. This approach to proj- ect planning starts from the project’s end point. It defines the last major chunks of work or resources that must be completed and integrated to produce the final deliverable, and then moves backward to each major chunk that is needed prior to that step. Once these tasks are defined, the project manager will identify the subtasks necessary to complete the task and show them below the task, and so on down the line to the most detailed work effort.

In effect, the work is defined from top to bottom. You start with the lowest work and roll up to the higher levels until the major milestones have been identified. This approach identifies all the tasks necessary to complete the project. If you begin simply by defining what you will do first and work toward the end point, you are more likely to miss important milestones at the end, so it is good practice to define the WBS from the top down and the bottom up.

For instance, in the new information system project shown in Figure 6.1, there would be both top-down and bottom-up planning. Top-down decisions are made on which high-level tasks are necessary to produce the new system. They are determined by experts for design, develop, acceptance, and delivery. Bottom-up decisions are made by deciding what subtasks

bar81677_06_c06_173-198.indd 176 9/9/14 10:52 AM

Section 6.1 The Work Breakdown Structure

are necessary to roll up to produce each high-level task. For instance, to complete the design there are two steps: concept (define the concept in general, indicating performance require- ments) and draft (produce draft drawings and graphics that provide detail on how the system will work). By looking down from the top, it is easier to envision what needs to come together to produce the deliverable. By looking from the bottom, it is easier to see what individual and small group work needs to occur to reach task completion.

The WBS should be shared with sponsors, stakeholders, project team members, and custom- ers so that all the parties to project success see the work that is being planned. Sometimes, having new eyes evaluate what is considered the final WBS will uncover new tasks that were not considered during its preparation.

Templates

Startup managers usually do not have to start from scratch in preparing a WBS. Some projects have a WBS built in because the process for creating, designing, developing, and producing the deliverable has already been specified and proved over many years. These processes often need only minor tweaking to accommodate the project outputs.

For instance, the software development process provides a template (platform or frame- work) for this kind of project, oriented to work to design concepts, develop prototypes, and test them. On the other hand, a construction project WBS template will incorporate work tasks related to construction, like identifying requirements, preparing blueprints and engi- neering plans, procuring supplies, and building the facility from the ground up.

Defining Major Milestones

Once the WBS is prepared, the scheduling process can begin, which specifies task durations, required resources, team member assignments to tasks, and dependencies, or task prede- cessors, as shown in a Gantt chart. A schedule (the timing of each task, durations, start and finish dates, and dependencies, shown against a calendar) for the most complex project can be shown clearly through this process to enable team members to know where their task fits into the project’s big picture as the schedule is updated.

The WBS and schedule are inextricably linked. Project managers cannot do much with the WBS to define the timeline of the project and task interdependencies until they prepare the schedule. They also cannot do scheduling without the WBS in one form or another. (The WBS is the organization chart of the project showing all tasks in a hierarchy, from top-level tasks to lower, more operational subtasks.)

The schedule represents a critical agenda item for most project meetings, and certainly for the phase-gate reviews at the end of a major project phase. Microsoft Project® or a similar software program will enable the project manager to present any aspect of the project on a screen or in a virtual project meeting, including the timeline, critical tasks, remaining work, estimated cost, upcoming milestones, planned and consumed resources, contractor progress (contract work can be highlighted), and the impact on scheduling of project risks. The project manager can tai- lor presentations to the audience, such as by showing only top-level tasks to top management.

bar81677_06_c06_173-198.indd 177 9/9/14 10:52 AM

Task Name% Complete FinishStartDuration

473

461

101

346

256

155

4 1

Procurement Solicitation

Website Project

Solicitation Documents

Contract Work: Produce Website

Design

Prototype

Document Design

Choose User Group

Final Performance Test

Requirements

Procurement

Award

Requirements

Develop

Configure

User Acceptance Testing

Conduct Test Sessions

Project Closeout Deliver

Predecessors

11/26/14

12/04/14

12/12/14

03/13/15

05/22/15

07/31/15

09/11/15

09/03/16

12/01/14

11/26/14

12/11/14

12/12/14

05/22/15

07/17/15

09/11/15

02/01/16

09/17/16 09/16/16

11/28/14

09/16/16

12/10/14

09/16/16

05/21/15

07/16/15

09/10/15

01/29/16

09/16/16

12/03/14

12/11/14

03/12/15

09/16/16

07/30/15

09/02/16

09/21/16 09/16/16

Section 6.1 The Work Breakdown Structure

Gantt Chart: Tasks, Schedule, and Resources The WBS and Gantt chart help team members define and account for the work they are assigned and help the project manager identify major milestones (points along the way where key deliverables or decisions are due), monitor the work, and ensure that the key milestones are actually met. When a key milestone is not met, the project manager will typically follow up to see if the original duration estimate for the task was wrong or, perhaps more impor- tantly, find out why the work is not on schedule.

The Gantt chart shown in Figure 6.2 is a sample Gantt chart without a bar chart; it shows project tasks and their durations, start and finish dates, predecessors (tasks that precede other tasks), and resource names. Tasks are outlined in a Gantt chart to show the same hierarchy of tasks, subtasks, and lower level tasks that are shown in a WBS organization chart. In the Gantt chart, note that the higher level tasks are not indented, but the lower level tasks are indented to show how they roll up to complete higher level tasks. For instance, see that the high-level task, pro- curement, is completed when the four lower level tasks supporting it—procurement solicita- tion, requirements, solicitation documents, and award—are completed.

Figure 6.2: Sample Gantt chart without bar chart

This Gantt chart shows all tasks being completed in a total of 473 days, with a due date of 9/16/16. The project is scheduled to close out 9/21/16.

Task Name% Complete FinishStartDuration

473

461

101

346

256

155

4 1

Procurement Solicitation

Website Project

Solicitation Documents

Contract Work: Produce Website

Design

Prototype

Document Design

Choose User Group

Final Performance Test

Requirements

Procurement

Award

Requirements

Develop

Configure

User Acceptance Testing

Conduct Test Sessions

Project Closeout Deliver

Predecessors

11/26/14

12/04/14

12/12/14

03/13/15

05/22/15

07/31/15

09/11/15

09/03/16

12/01/14

11/26/14

12/11/14

12/12/14

05/22/15

07/17/15

09/11/15

02/01/16

09/17/16 09/16/16

11/28/14

09/16/16

12/10/14

09/16/16

05/21/15

07/16/15

09/10/15

01/29/16

09/16/16

12/03/14

12/11/14

03/12/15

09/16/16

07/30/15

09/02/16

09/21/16 09/16/16

bar81677_06_c06_173-198.indd 178 9/9/14 10:52 AM

Build a Candidate List

Select Candidate

Define Criteria for Selection

Screen Candidates

Interview Candidates

Reference Checks

Q3Q4Q3Task Name

Q1 Q2 Q4 Q1 Q2 Aug SepJul May JunAprFeb MarJanNov DecOctAug SepJulMay JunAprFeb MarJanNov DecOct

Compile Information

Distribute Information

Conduct Selection Process

Build a Candidate List

Define Criteria for Selection

Screen Candidates

Interview Candidates

Reference Checks

Compile Information

Distribute Information

Conduct Selection Process

Start Date

07/28

09/08

08/19/

08/21

04/25

05/16

09/05

06/03

08/18

08/20

04/02

02/09

04/22

05/13

06/03

End Date

Dur- ation

485

249

149

125

176

Prede- cessor

8, 6

Select Candidate

Section 6.1 The Work Breakdown Structure

Figure 6.3 is another Gantt chart showing task durations, with durations, start and finish dates, and a bar chart on a calendar. The bar chart helps show how the tasks play out against real dates.

Note that in both examples, durations and start and finish dates are shown for each task and the bar chart shows task interdependencies with lines connecting the bars.

The WBS Organization Chart A second way to show the WBS is through an organization chart of the work, such as a tradi- tional organization chart for a company or agency. Here the top-level tasks begin the chart, with lower level tasks below, building to completion of the major tasks. Figure 6.4 depicts the same project as Figure 6.1, the website project, but in the form of a WBS organization chart. You can see how each task in the Gantt chart in Figure 6.2 is shown in Figure 6.4.

Figure 6.3: Sample Gantt chart with bar chart

This Gantt chart shows all the tasks in another project, all at the same level, with a bar chart to show tasks in bars on a real calendar to facilitate scheduling and planning.

Adapted from Smartsheet.com.

Build a Candidate List

Select Candidate

Define Criteria for Selection

Screen Candidates

Interview Candidates

Reference Checks

Q3Q4Q3Task Name

Q1 Q2 Q4 Q1 Q2 Aug SepJul May JunAprFeb MarJanNov DecOctAug SepJulMay JunAprFeb MarJanNov DecOct

Compile Information

Distribute Information

Conduct Selection Process

Build a Candidate List

Define Criteria for Selection

Screen Candidates

Interview Candidates

Reference Checks

Compile Information

Distribute Information

Conduct Selection Process

Start Date

07/28

09/08

08/19/

08/21

04/25

05/16

09/05

06/03

08/18

08/20

04/02

02/09

04/22

05/13

06/03

End Date

Dur- ation

485

249

149

125

176

Prede- cessor

8, 6

Select Candidate

bar81677_06_c06_173-198.indd 179 9/9/14 10:52 AM

Procurement

Award

Solicitation documents

Requirements

User acceptance testing

Document design

Choose user

ConfigurePrototype

Design Conduct test

sessions

Requirements

Procurement solicitation

Website project

Contract work

Deliver

Final performance test

Develop

Project closeout

Section 6.1 The Work Breakdown Structure

You can probably see now that the WBS can be a useful tool to build a project plan by defin- ing all the necessary tasks and relationships between tasks to complete the work. Perhaps most importantly, this planning tool allows the project manager to share a “picture” of the project with the team, the customer, and key stakeholders to make sure all necessary work is included as seen by many different interests.

The Links Corporation Private Sector Case Study

The Links Corporation leadership is trying to change the company culture from emphasiz- ing traditional manufacturing and production to one equally focused on new product and internal improvement projects.

The CEO, Phillip Johnson, and the vice president for operations, Ben Roberts, are discuss- ing the subject of developing a single project management methodology for breaking down project work and setting key milestones.

(continued)

Figure 6.4: Organization chart

Here you can see the three major tasks in this project, at the top of the WBS: procurement, contract work, and project closeout. Although the work is broken down to lower and lower levels, the actual work starts at the bottom and builds up to the major tasks.

Procurement

Award

Solicitation documents

Requirements

User acceptance testing

Document design

Choose user

ConfigurePrototype

Design Conduct test

sessions

Requirements

Procurement solicitation

Website project

Contract work

Deliver

Final performance test

Develop

Project closeout

bar81677_06_c06_173-198.indd 180 9/9/14 10:52 AM

Section 6.1 The Work Breakdown Structure

Since the whole effort will consist of three projects making up a program, Johnson wants to ensure that these first few project teams succeed in meeting milestones and controlling their costs and schedules.

Roberts assures Johnson that the way to do this is to promote a single methodology and sys- tem for defining work and scheduling it, identifying milestones, and controlling contractors. Roberts wants some of the best employees in the manufacturing department to be trained and developed in project management. They already have experience with scheduling, but in a volume production environment rather than a single project system.

Johnson then asks how they can reassure those in the manufacturing department that a proj- ect designed to help them will not interfere with their schedules.

Roberts’s response is that this can be accomplished by including manufacturing personnel in the project team and working with scheduling to find windows of time to intervene in the production line when there is no high-urgency work to be completed. He believes that if they can slip the project into manufacturing’s schedule and help it improve its efficiency in getting the product out while simultaneously promoting new products into the system, they will have succeeded. Their main challenge is to set milestones for the project that will not conflict with manufacturing’s schedule.

Question for Discussion

1. Why is top management worried about coordinating new product project schedules with manufacturing schedules in the company?

The Links Corporation Private Sector Case Study (continued)

Now that we have explored the importance of planning project tasks and schedules using the Gantt chart and other tools, consider that all projects are different and therefore have unique task structures and schedules. The following section discusses the case of an office building project in which tasks reflect those generally applied to construction projects but still con- form to the WBS format.

Case: Constructing an Office Building

Defining project work and scheduling requires a constant sensitivity to risk and risk-based scheduling. Risk-based scheduling means reflecting risks in estimating task durations and costs, usually through defining durations and costs in ranges. It is conducted because esti- mates of the duration and costs associated with high-risk tasks are often inaccurate, since team members or contractors assigned to these tasks often protect themselves from failure by overestimating the time necessary to complete the task.

This practice, though understandable since team members feel accountable for meeting key milestones, distorts the execution phase and can substantially delay project completion. A better way to deal with risks is to reflect them in the estimating process by displaying dura- tions and costs in ranges and then adjusting estimates as more is learned about the risks associated with the task.

bar81677_06_c06_173-198.indd 181 9/9/14 10:52 AM

Project: The Building Task: 1.1 Architectural drawings Subtask: 1.1.1 Hire an architect Work Package: 1.1.1.1 Build list of candidate architects Level of Effort: 1.1.1.1.1 Develop criteria for selection 1.1.1.1.1.1 Involve the customer in developing criteria 1.1.1.1.2 Screen candidates 1.1.1.1.2.1 Conduct a peer review on candidates to offset biases in project team 1.1.1.1.3 Interview candidates, conduct reference checks 1.1.1.1.3.1 Confirm references with second opinion 1.1.1.1.4 Compile candidate information 1.1.1.1.4.1 Scrub information to assure credibility 1.1.1.1.5 Distribute candidate information 1.1.1.1.6 Convene meeting 1.1.1.1.7 Conduct process of selection 1.1.1.2 Prepare preliminary blueprint 1.1.1.3 Check standard blueprint template 1.1.2 Building supplies 1.1.3 Ventilation system 1.1.4 Water system 1.1.5 Electrical system

Section 6.1 The Work Breakdown Structure

Using a construction project as an example, organizing the project involves two basic steps:

1. Customer requirements 2. Work breakdown structure and task list

The deliverable in this case is an office building, and the customer is a real estate property manager.

Customer requirements. Requirements are the technical and functional requirements for the building. The customer requirements document is the project manager’s definition of cus- tomer requirements, developed from information gleaned from the customer. In this case the requirements would include building specifications suited to the customer’s intended use of the building.

Work breakdown structure and task list. The WBS includes the task list as a project out- line, as shown in Figure 6.5.

Now that we have looked at how to organize project tasks and show them graphically, we next move on to the role of scheduling. Scheduling is important because most customers and stakeholders depend on projects to be delivered on time.

Figure 6.5: Example of a WBS with a task list

A sample work breakdown structure with a task list for a construction project.

bar81677_06_c06_173-198.indd 182 9/9/14 10:52 AM

Section 6.2 Scheduling

6.2 Scheduling Although the project WBS and schedule process are often unstructured and unsystematic, there are at least five managerial actions that project managers take at some point in the planning process. In a matrix organization where the project is assigned team members from various functional departments, the project manager generates the scheduling process, while the department manager serves as a resource on product functionality, quality, and depart- ment resources and assures that the technical procedures are in place to complete the work. This process only works effectively with a constant dialogue between the project manager, department managers, and the team.

We will use a new product development project to illustrate the scheduling process involv- ing five steps, culminating in the product deliverable. The general sequence is to first define the work from customer requirements; structure the work into an outline or WBS; define an overall, top-level task structure and work flow; identify tasks, durations, risks, and interde- pendencies; and then develop department staffing plans to accomplish the work, estimate the costs, and kick off, monitor, and close out the program.

Table 6.1 outlines the five functions, a description of the function, and the roles of the project manager and functional department manager.

Table 6.1: The scheduling process

Scheduling function Description of function Project manager role

Department manager role

Develop top-level work Develop top-level project structure

Lead role, working with the team and department management

Participates in devel- oping top-level struc- ture; confirms risks

Flesh out schedule, establishing tasks and subtasks, durations, risks, interdependency, and constraints

Identify tasks and risks, prepare risk matrix, prepare pre- liminary schedule

Lead role with inputs from department staff, works to find ways to acceler- ate work in concurrent tasks when feasible and to address risks

Helps define scheduled work and inherent risks, can take advan- tage of prior work, supports concurrency in work schedules

Assign resources to schedule, estimating hourly requirements for each task

Establishes resource needs to support schedule, assigns work from scheduled tasks to staff, confirms resource availability

Works with departments to identify project team and meet other resource requirement

Lead role, responsible for staffing the project with competent, adequately trained personnel and provid- ing adequate resources and quality guidelines

Establish risk-based schedule baseline

Save schedule as baseline

Takes lead to kick off project

Participates in kickoff meeting, supports resource usage plan

Monitor performance against schedule baseline, report on performance, variances, and cost to complete, manage change

Enter actual data on percent complete and cost data from time sheet project codes, revises start and finish dates as appropriate

Gets percent complete and other performance infor- mation from project team members, reports weekly to director of product development

Reviews actual and planned data and makes recommendations

Project Risk Management by Bruce T. Barkley. Copyright © 2004 The McGraw-Hill Companies, Inc.; Project Management in New Product Development by Bruce T. Barkley. Copyright © 2008 The McGraw-Hill Companies, Inc.

bar81677_06_c06_173-198.indd 183 9/9/14 10:52 AM

Section 6.2 Scheduling

The following are the key points that must be completed in each step.

Step 1: Develop top-level work.

Whereas there are general templates available for various kinds of projects, the project man- ager should have a basic familiarity with the project and its major components. For instance, a project to produce an electronic consumer product will inevitably involve concept, design, software development, electrical and mechanical systems, and testing. These are the top-down tasks in such a project, tailored to the particular requirements of the target deliverable.

But what is often lost in the top-down process, particularly for technology projects, is the “soft” function of high-level activity of communication and information exchange. If commu- nication and information needs are not met at each phase, the technical system may succeed but the project may fail simply because the focus was on technical rather than socioeconomic factors. Since the high-level structure can determine the whole breakdown of the work and its scheduling, it is extremely important to make sure the top-level tasks are identified.

Step 2: Flesh out schedule and interdependencies.

Sometimes a network diagram is useful to establish interdependencies, because such a graphic will show the flow of work without referencing time or cost. The key in fleshing out the schedule is to define the process of completing each high-level task and to identify the sequences and interdependencies between subtasks. There is a certain logic to each project that determines this interdependence. For instance, in a construction project, the logic that is followed is presented in Table 6.2.

Table 6.2: The logic in a construction project follows the logical model

Input ———————> Process ———————> Output

The design team Conduct design process Final facility design

Facility design Test design Validate design

Validated design Procure supplies Assemble supplies

Assembled supplies Construction process Finished facility

The logic is that the first input is the design team that conducts a design process to produce a final facility design output. Then this design output becomes an input to the process of testing the design in order to produce a validated design. Then this validated design output becomes an input to the procurement of supplies and final assembly of supplies in preparation for con- struction. Then this assembled supplies output becomes the input to the actual construction process that produces the final output, a finished facility.

Step 3: Assign resources.

People resources are assigned to a project based on the work to be done, and task leaders are assigned to high-level tasks. Then necessary supplies and materials are identified by the task leader and acquired by the procurement office. All people and physical resources are then

bar81677_06_c06_173-198.indd 184 9/9/14 10:52 AM

Section 6.2 Scheduling

assigned to tasks in project management software, and costs are estimated and updated when procured. When assigning resources, it is important to involve the project team in developing the resources necessary to do their jobs as defined in the WBS.

Step 4: Establish risk-based schedule.

Schedules should be risk based; that is, they should reflect the analysis of risks, particularly those with inherent and substantial scheduling risk. Most project management software will help calculate the duration impact of various risks (to be covered in Chapter 7). The impacts will create ranges of duration depending on the risk event occurrence.

Step 5: Monitor performance against schedule.

Schedules are monitored by entering actual durations and comparing them to planned dura- tions for each task. The key in monitoring is to not look back at the original schedule for variance as much as to look forward to the remaining work and the impact of risk and other factors in terms of time and cost. The objective is to use the schedule as an indicator of change and actual performance for the purpose of looking forward to necessary adjustments to ensure project success.

Baselining the Schedule

After a preliminary schedule is prepared and approved by the project manager, sponsor, and department managers, the schedule is baselined, meaning that those dates are the point of departure for monitoring and tracking the execution phase. Baselining is the process of docu- menting the final project plan and schedule as a point of departure for kicking off the project. It signifies the official approval and kickoff of the work and indicates the organization’s com- mitment to the schedule and resource plan. The baseline is saved in a project document in project management software, and signals that the project schedule is complete. Establishing the baseline schedule is a significant action in the project management process and is docu- mented in the project management plan.

The purpose of baselining is to create a schedule that captures all of the work to be done. This schedule does not change unless the basic project scope of work changes. Once agreement is reached, the project manager confirms the baseline by saving it and making it available on the network. It shows all interdependencies, linkages, and resource requirements; includes all tasks necessary to get the work done; and shows impacts on parallel programs and resources. All procurements and test equipment are covered in the schedule.

The baseline schedule is also resource leveled. This means that there are no overcommitted resources and that the work can be implemented with current, available, or planned resource acquisition. It means that assigned staff members from all departments are aware of the com- mitments and have signed on to complete their tasks to meet milestones. This means that the project manager has assurance from all project players that they have scheduled their project tasks into their calendars.

A baseline meeting is held to arrive at a final agreement on the schedule and resources committed before the baseline is saved to the network. The project manager facilitates the

bar81677_06_c06_173-198.indd 185 9/9/14 10:52 AM

Section 6.2 Scheduling

meeting, whether virtual or on-site, and all department managers come prepared to confirm commitment of their resources to the final, agreed-upon baseline schedule. The final review of the schedule at the baseline meeting involves reviewing all stages and tasks, linkages, and resources assigned, line by line.

The baseline schedule is monitored weekly, with actual percent complete data and changes in start and finish dates entered weekly and reported at the program review. Risk contingencies from the risk matrix data are plugged into the schedule and durations estimated along with other tasks. A risk-based schedule is prepared.

Controlling Change in Schedules

Schedules change for many reasons. It is the project manager’s job to control changes and document them as the project proceeds through the planning and execution phases. Changes in the deliverable, or the project product specification, which can impact schedules, are approved by the project manager and departments involved.

The project manager documents two kinds of changes: schedule updates based on track- ing information, such as percent complete, and more fundamental changes from customer inputs, design change notices, and other more substantial changes in the scope of work. Affected department managers and the appropriate project manager must agree to all sched- ule changes. After the baseline schedule is saved, the project manager and project sponsor must approve any slips or changes in key milestones.

Managing Project Schedules on a Company or Agency Network

The basic objectives of network management of project schedules are to (a) enable the program management office (PMO) to document control schedule updates and schedule versions, and (b) provide department managers and staff with an easy way to review and provide input to schedules and schedule assumptions as the project progresses. The follow- ing are the steps involved:

1. All schedules are housed on the server in individual project manager folders. 2. A central resource pool file is established. Its purpose is to capture all organization

personnel commitments to all projects. Individual project schedule baselines are inte- grated with the central resources pool to assure that resources are not overcommitted.

3. Project managers and the project team have “write” access to the schedules. Depart- ment managers have “read” access to program schedules.

4. The PMO is responsible for maintaining and updating program schedules on the network. Once the project manager and department managers agree on a proposed schedule baseline or update, the schedule is linked to the resource file, and resource conflicts are identified and resolved. The project manager then saves the schedule as a baseline schedule, and it is placed in a designated directory. The baseline schedule is the only version of that schedule housed on the network (except for archives) and serves as the source of “planned versus actual” tracking information.

bar81677_06_c06_173-198.indd 186 9/9/14 10:52 AM

Section 6.2 Scheduling

Resource Planning and Control

Scheduling is essentially the process of planning to use personnel and equipment resources. Good project management requires a process to plan for the acquisition of future resources, to allocate current and projected resources to schedules, and to make shifts in resource man- agement as required. The process provides for a central resource pool to identify impacts of project schedules and assure the efficient utilization of the workforce. The resource pool information on the network is shared with management staff and all team members to allow each team member to evaluate the scheduled work assigned and to provide guidance on task definition, durations, start and finish dates, and interdependencies.

In the fast pace of a project, it is often difficult for a project manager to know how the proj- ect is doing based simply on reports. Work done on a project is typically tracked as percent complete. The project manager can get up-to-date information by collecting actual work done from time sheets to gain an accurate assessment of actual work completed. These sheets col- lect hours of work against the project account-numbering scheme.

The project manager is responsible for establishing the account numbers for charges to the project and for assuring that time sheets are kept for all work on the project. The PMO is responsible for working with the finance department to collect data each week and enter it into appropriate schedules.

Selecting the Team Around the WBS One of the unique aspects of project management is the connection between the specific work to be done and select- ing the people to do it. Team memb- ers are not necessarily chosen because of their backgrounds, training, or edu- cation, although these are important. They are chosen because of their proven capacity to do the tasks required well and efficiently.

Team composition is determined by the work to be done. This means it is useful to think about selecting team members during and after the work is defined in a WBS, not before. The proj- ect manager should define the work. Team members should not determine

the work in isolation, but rather be part of the process. It is important to separate the work to be done from those who will do it so that expectations are not compromised by a team mem- ber’s personal view of the work and how to do it.

Wavebreak Media/Thinkstock

Members of project teams should be selected for their ability to accurately and efficiently perform the tasks required. What would you look for in a project team member?

bar81677_06_c06_173-198.indd 187 9/9/14 10:52 AM

Section 6.2 Scheduling

Aligning Resources With Project Tasks and Schedule Alignment is an important project management concept not only for a project’s people resources but also for the capital and physical resources required to do the job. The scheduling process involves more than scheduling work, people, and tasks. Required project resources, including equipment, supplies, and product components, must be acquired—preferably “just in time”—to serve the project, but many resource decisions are made outside the project team process.

For instance, the procurement office will buy equipment, product components, facilities, and supplies for the project manager, but not always on the project timeline. This is because many procurement acquisition buys are made on an enterprise-wide basis by volume or price, which could delay availability of resources when they are needed by the team. This potential risk is mitigated when the project manager works closely with the procurement office to assure procurement supports the project and its goals. If necessary, the project manager will request separate buying authority to acquire necessary resources outside the normal buying process.

Tracking, Project Review, and Phase-Gate Reviews The project manager tracks the project progress on an ongoing basis and updates the schedule each week. The project management plan and schedule are updated as changes in plans warrant.

The project manager will hold regular program review meetings for the team, either virtual or on-site, to discuss project issues such as cost, resources, technology, schedule, project team performance, and risk mitigation.

Additionally, periodic reviews are held with the project manager and program team in prepara- tion for reporting and to support task assignments and feedback, either as a single meeting with all functions represented or as a series of meetings with major functional areas represented at each meeting. Project managers report progress to their project sponsors and stakeholders.

At the end of each phase, the project manager will typically schedule a phase-gate review with top management for a high-level picture of the project and determine whether work will pro- ceed to the next phase. This review is intended to provide top management with feedback and to enable termination of projects that show no promise. The project manager is responsible for preparing presentations for the project and phase-gate reviews and identifying key agenda items. Department managers and team members attend project review meetings as appropriate.

Scheduling Uncontrollable Tasks and Activities

Project schedules often include tasks, milestones, and activities that are on the critical path but that are not in the immediate control of the project team. There is a clear risk that resources will not be there when required.

bar81677_06_c06_173-198.indd 188 9/9/14 10:52 AM

Section 6.2 Scheduling

For instance, a project to develop and produce a new instrumentation suite for a business aircraft might require a company aircraft for testing. But that aircraft might be used for other company purposes and could be unavailable when necessary in the project schedule. This is a project risk that requires a risk-based scheduling decision to insert an alternative task in the schedule—a risk-based task—to rent or otherwise procure a test aircraft should the original plan to use the company’s resource not work out.

A New Theory: Focus on Start Dates

As you can see from the discussion of WBS and project scheduling tools, the assumption behind this approach is that project managers can estimate when tasks will start and finish. In fact, the whole system of planning depends on the capacity of the project team to antici- pate issues and control task durations. The traditional scheduling approach assumes that task durations and interdependencies can be accurately estimated. But as project managers do so, they may be constraining the team to a plan and schedule that locks in the team and holds it back from doing the work faster and better.

In the real world of project work, this assumption may not always stand up because of risk; project tasks are often so unpredictable that estimating task durations is impossible. Dura- tions are a function of many factors, including the amount of other work assigned to team members that can divert their attention from the target project. When this dynamic of multi- tasking and uncertainty occurs, team members will often make arbitrary estimates.

When estimates of a project’s many tasks are uncertain, the project schedule can become a constraint on successful completion, rather than a tool of efficiency. In effect, when start and finish dates are locked in, work on any given task can expand to the amount of time available to complete it, because many estimates are made to protect the task leader from failure.

In addition to this issue in traditional scheduling, there is good evidence that many tasks that are planned in sequence can be completed in parallel through close collaboration and coor- dination between task leaders (Kerzner, 2013b). Thus, the traditional linear approach tends to lead to longer project timelines because task start dates are inaccurate and can delay the project unnecessarily.

Because of these dynamics, the theory of open-ended scheduling has emerged that places more emphasis on start dates, rather than finish dates. The idea is that projects can be com- pleted faster and better when project team members complete tasks as quickly as possible, rather than within a predetermined start and finish window.

Although this can make the project deliverable due date softer and more unpredictable, it can also lead to remarkable project performance. This is because this approach encourages innovation and creativity in designing and conducting a task or project activity. While the traditional approach to estimating assumes a given way to accomplish a task, this approach does not. Therefore, the task leader must think through how to accomplish the task as soon as possible instead of doing the work in “the way we always do it.”

bar81677_06_c06_173-198.indd 189 9/9/14 10:52 AM

Section 6.3 Creating Schedules

This approach also assumes that project task leaders are assigned more or less full time to project tasks instead of being assigned tasks from a variety of projects all at once. This requires a different approach to how companies and agencies plan to complete projects when they have many projects on line. This also means that a company or agency avoids multitask- ing by scheduling projects to be completed one by one rather than all at once. This way, proj- ect team members work on one project at a time, complete their work, and then move on to other projects. Although this arrangement is not always possible, given that project tasks are not planned all at once, it favors reducing multitasking as much as possible.

6.3 Creating Schedules It is relatively easy to find a template, or generic framework, for almost any project on the Internet, but relying on templates presents risks. Templates provide a model process for a given project, such as new product development, construction, or IT, based on the proven experiences in other similar projects. But there is a danger in the mindless use of such templates because they assume that there is one way to complete a project and one process to pursue.

Recent experiences with project management suggest that most templates are grounded in the traditional linear approach to project planning and implementation. This approach does not typically accommodate innovation and creativity in how a project team works together. Tasks like product design and development that are presented sequentially may not need to be linked to each other in this manner. Concurrent engineering approaches now encourage parallel work in design and development so that designers and developers work together in an iterative way to produce a new product concept and prototype.

Project templates can make it too simple to follow someone else’s model process rather than finding new ways of producing project outputs on time and within budget. And although it is inviting for the organization to find ways to simplify a project—perhaps by using generic templates—and provide a hassle-free procedure to get the job done, there is a danger in that approach. This is because process counts. The way a project is planned and managed influ- ences its quality, cost, and schedule and, more importantly, can impact the achievement of basic project goals. In this sense, even the PMBOK guidelines can impede creativity and inno- vation if the process models are accepted blindly.

A good example of this dynamic is the production of a website for an elementary school. The standard scheduling template for website development will essentially describe a process that begins with concept and design, goes to development and prototype, and then to testing. Finally, the website is tested with users. This is the traditional approach to website develop- ment and, in fact, all IT.

If the team follows a typical template for this process, that is the process it will use. But what if the team wants to avoid all the costs of design and development to meet technical require- ments that might produce a website that users do not like and will not use? What if the team

bar81677_06_c06_173-198.indd 190 9/9/14 10:52 AM

Section 6.3 Creating Schedules

decides to “dummy up” a website as a first step to expose a user group to various optional website frames to find out what the users really want—and then produce it?

Innovation in the way projects are carried out can make a difference, and may even result in breakthrough outputs and outcomes that traditional projects never reach.

Therefore, although the project manager wants the team to see how a given project has been done before, and learns different approaches through exploring templates, he or she does not want blind acceptance of templates or generic solutions to drive the project. Rather, the team should tailor approaches to the target project and try new methods, especially if the customer is open to using the project to make a major breakthrough that might change an industry’s approach to its work.

Aligning Personal Calendars With Project Schedules

One of the major challenges in project management is getting resources, both people and capital, committed to the project when they are needed. This means that a team member who commits to completing a task in 2 months will commit that time in a personal calendar as well as in the project schedule. This sounds simpler to do than it is, because team members have different ways of planning and controlling their time.

In companies that employ time sheets and charge codes for projects, there is an incentive for associates to have a full agenda of chargeable time in the future to assure that the work they are doing is billable to a customer and not charged to overhead or administrative work. This kind of firm will typically incorporate personal calendars with project schedules so that there is direct alignment of individual and project team agendas for the future. However, many firms do not employ these tools, and must assure their project team members that project schedules are incorporated into personal schedules as much as possible—and perhaps pro- vide supporting network software to support the process.

Project Cost Codes and Schedule Controls

In order to capture a project’s costs, completed task work must be documented using a project coding and time sheet system. This requires the team member to charge time to various project codes. This is not always popular with the workforce because it encourages review of work–output relationships and unit costing (Baker, 2011).

Unit costing leads to standards on tasks such as software design that indicates that it “should” take 4 days for a professional software engineer to write code with X lines. As unpopular as this approach can be, it is one way of controlling schedules and costs as long as the project manager monitors the process regularly.

bar81677_06_c06_173-198.indd 191 9/9/14 10:52 AM

Section 6.3 Creating Schedules

Scheduling Issues in Contract Management

Many scheduling problems occur with projects that are fully or partially outsourced, in which work is completed by contractors. While there are many factors involved, the primary reason is that contractors typically bid on projects and win awards based on low bid (Guth, 2008). The low bid is usually based on an optimistic scenario rather than a realistic one, and the con- tracting firm or agency is attracted to the low cost and most optimistic proposal. Sometimes contracts contain incentives to make deadlines that are effective in offsetting delays, but in practice these kinds of contracts almost always experience schedule delays and associated budget overruns.

There are several approaches to controlling contractor schedule delays:

1. In selecting contractors, the lowest bidder should not automatically be selected unless there is clear evidence that all costs associated with task durations and project schedules are accurate. Task durations and schedule assumptions should be scrubbed, and internal project team members should review planned schedules in contractor proposals.

State Department of Health and Human Services Public Sector Case Study

The secretary, Robert Mikawa, and assistant secretary for programs, Rebecca Dawson, hold a meeting to discuss the subject of a single project management methodology for disciplined contract management and schedule control.

Mikawa is concerned about controlling the project schedule. Once schedules for deliver- ables, such as their website, are made public, all stakeholders will have expectations based on those dates. He asks Dawson what they will do if there are problems with state regula- tions or with a contractor and a date is missed or the website does not work.

Dawson already has the answer. She says that they need to control expectations by pro- moting the concept of “conditioned” due dates. In other words, once the schedule is devel- oped, they will prepare a statement of assumptions, conditions, and contingencies, meet with stakeholders to get them on board, and then go to the media. That way the media will publish a due date with assumptions and conditions, and the agency will be transparent with them through the process regarding the assumptions and conditions.

She believes the real issue is that their project is a high-level framework for “nesting” other projects. She thinks they should see their project WBS and schedule as a high level, program framework for many lower level projects that implement it. She wants to continue viewing the project at a higher level in order to more accurately view quality and compatibility.

Question for Discussion

1. Why is the discussion centering on how the HHS project schedule is to be “nested” in all the other schedules of network participants?

bar81677_06_c06_173-198.indd 192 9/9/14 10:52 AM

Summary and Resources

2. Scope creep should be avoided since delays in project schedules often occur because contractors do not stay within the project scope. Contract statements of work should be clear on what is and is not included in the work. Contractors must be included in project team deliberations and decisions. Close monitoring of contractor progress will avoid schedule problems.

3. Disincentives should be used to avoid schedule delays in the contract. This approach integrates schedule adherence into the contract itself and penalizes contractors if schedules are not met. Disincentives are more effective than incentives because con- tractors place more urgency on avoiding penalties that may reduce planned profits than on maximizing profits beyond the contract budget.

4. Contractor schedules should be linked into project schedules to emphasize interde- pendencies. It pays to ensure that contractors use the same project management and control methodologies that are used in the project as a whole; thus, there is common language, and schedule information can be easily inserted in project management software.

5. Three risk-based schedules should be identified: pessimistic, optimistic, and expected. Encourage contractors to use the three optional views of schedule dura- tions and to report anticipated work due dates that diverge by more than 10% from the expected task duration.

6. Contractors should be included in regular project schedule and key milestone reviews and phase-gate reviews. The more that contractors are included in project review decisions, the more they will share in expectations of the whole project team, not only on schedules but also on all facets of the project.

7. Focus on start dates, not finish dates, and incorporate this approach into the proj- ect itself. If the project is focused on research and development, or on new product designs and testing, then assume schedule delays will occur. Place more emphasis on milestones that are decision points, not deliverables, and stay focused on project reviews at key milestones.

In sum, remember that schedules are not worth the paper they are printed on unless all project and project-related staff “own” them. That is, if the schedule outlines work tasks correctly and represents a true indication of the intent of all the project actors, then the schedule is viable. If not, the schedule is just a figment of the imagination, even though it may be documented.

Summary and Resources

Chapter Summary • Projects should be broken down into tasks and subtasks to show what work needs

to be done and by whom. • The work breakdown structure is a useful way to show high-level tasks and their

interdependencies and lower level subtasks and how they support the completion of higher level tasks.

• The Gantt chart is a proven tool to help show the project as a whole with all tasks, durations, start and finish dates, predecessors, and resources.

• Scheduling not only involves showing task dependencies and calendar dates, but also plays a role in committing the project team members to their tasks in the “win- dows” shown.

bar81677_06_c06_173-198.indd 193 9/9/14 10:52 AM

Summary and Resources

• It is important to add costs to the project using the Gantt chart and to track actual work through time sheets that are coded to project tasks.

• New theories of scheduling provide more flexibility to team task leaders in finishing tasks when possible, not necessarily when scheduled.

• Schedules for contract work should be incorporated in the contract and managed closely to ensure that contractors support the overall project schedule and do not establish their own timelines.

Posttest 1. The ultimate purpose of a work breakdown structure (WBS) is to __________. a. demonstrate the project’s alignment with organizational goals to top

management b. communicate team members’ roles to functional department managers in a

matrix organization c. understand the project’s costs, task sequence, and resource needs so a schedule

can be created d. share information about resource and material needs to meet the project

deliverable

2. A(n) __________ approach to project management is MOST likely to succeed. a. team-driven b. customer-driven c. enterprise-driven d. process-driven

3. Entering completion percentages and cost data from time sheets is a part of which scheduling function?

a. establishing a risk-based schedule baseline b. monitoring performance against schedule baseline and reporting on perfor-

mance, variances, and cost to compete c. fleshing out the schedule, establishing tasks and subtasks, durations, risks, inter-

dependency, and constraints d. developing top-level work

4. In a new theory of project scheduling, what approach is believed to be best to com- plete tasks more quickly?

a. using traditional, tried-and-true task processes that are already mapped out b. inserting alternative, risk-based tasks into their schedules c. working on several tasks at once to take advantage of any gaps in work d. having the freedom to choose their own methods of completing the tasks

5. Using project templates can result in a lack of __________. a. simplicity b. linear approach c. innovation d. ease

bar81677_06_c06_173-198.indd 194 9/9/14 10:52 AM

Summary and Resources

6. Which of the following is NOT a recommended step toward avoiding schedule delays that often come with hiring contractors?

a. Do not automatically award the job to the lowest bidder. b. Offer incentives to contractors who adhere to the contract schedule. c. Ensure that statements of work clearly delineate what the contract work does

and does not entail. d. Include all contractors in the regular reviews of the schedule, key milestones, and

phase gates.

Review Questions 1. Who is responsible for defining the project work in a WBS? Who are the participants

in the process? 2. What is involved in the development of a WBS? 3. Who is responsible for preparing the project schedule? Who are the participants in

the process? 4. When and how are capital and physical resources scheduled along with tasks and

people? 5. Why must a schedule be balanced between the objective of control versus innova-

tion and flexibility?

Think About It! Reflective Exercises to Enhance Your Learning 1. Take a simple project, like building a deck on a house, and prepare a WBS and

schedule. 2. Take the schedule prepared and identify the risks in a few tasks. Then develop three

optional durations for these tasks: expected, optimistic, and pessimistic.

Additional Resources Barkley, B. T., & Saylor, J. (2001). Customer-driven project management: Building quality into project processes (2nd ed.). New York: McGraw-Hill.

Buttrick, R. (2000). The interactive project workout. Hoboken, NJ: Prentice Hall.

Kendall, G., & Rollins, S. (2003). Advanced project portfolio management and the PMO. Planta- tion, FL: Ross.

Project Management Institute. (2001). Practice standard for work breakdown structures. Newtown Square, PA: Project Management Institute.

Royer, P. S. (2002). Project risk management: A proactive approach. Washington, DC: Manage- ment Concepts.

bar81677_06_c06_173-198.indd 195 9/9/14 10:52 AM

Summary and Resources

Ryan, N., & Morris, M. (2010). Estimation survey: #1 Classic mistake, poor estimation, IT project retrospectives: Learning from the past through a program of action research. Pro- ceedings of the Sixteenth Americas Conference on Information Systems, Lima, Peru, Univer- sity of Virginia, McIntire School of Commerce.

Wideman, R. M. (1992). Project and program risk management: A guide to managing project risks and opportunities. Newtown Square, PA: Project Management Institute.

An article on project scheduling and the importance of accurate tasks linkages: McDonald, J. (2013). How to schedule a better project. Retrieved from Project Management Hut website: http://www.pmhut.com/how-to-schedule-a-better-project

Search the MindTools site for “Project Schedule Development: Planning the Timing and Sequence of Project Activities,” for an article on project scheduling that emphasizes the impor- tance of aligning task sequences and hand-offs: http://www.mindtools.com/index.html

Answers and Rejoinders to Chapter Pretest 1. True. Project managers use a technique called backward mapping to prepare the

WBS. They start from the end point of the project and define the work required to complete the final deliverable. From there, they define the tasks and subtasks neces- sary to reach that final point.

2. True. Under certain circumstances, the project schedule can hinder project comple- tion rather than facilitate it. This occurs when team members have made arbitrary estimates of their task durations, often due to the unpredictability of the task or the amount of other work assigned to them. When the duration estimates of many tasks are uncertain, the project schedule can become a constraint.

3. False. Exploring various project templates can be helpful for learning ways a type of project has been tackled before. However, relying on a template to plan a project can introduce risks and promote the incorrect idea that there is only one right way to complete a project.

Answers and Rejoinders to Chapter Posttest 1. c. The WBS is a detailed listing of milestones, tasks, and resources. Its purpose is to

make possible an accounting of project costs and sequence of work activity and resource use so that the project can be scheduled.

2. b. Both requirements and risks are customer-driven. A customer-driven project is most likely to succeed because the customer’s needs, expectations, and require- ments are defined first, before the scope of work.

3. b. In this scheduling function, actual data about costs and percentage of work com- plete is entered based on time sheet project codes. In a matrix organization, the project manager is responsible for obtaining this information. The department manager reviews the data and makes recommendations.

4. d. In the new theory of scheduling, the emphasis is on completing each task as fast as possible rather than within a predetermined time frame. To accomplish this, each task leader is encouraged to find his or her own best methods for accom- plishing the task quickly.

bar81677_06_c06_173-198.indd 196 9/9/14 10:52 AM

http://www.pmhut.com/how-to-schedule-a-better-project

http://www.mindtools.com/index.html

Summary and Resources

5. c. Project templates can be found in abundance for different projects, such as new product development. However, the traditional linear approach that templates often follow can hinder innovative and creative ways to develop new processes to accomplish a project.

6. b. Contractors that are awarded projects are usually those who bid the lowest and offer to do the most, which is not always realistic and can result in delays. Tips for avoiding delays include not choosing the lowest bidder unless there is evidence that the bid is accurate, avoiding scope creep by setting clear statements of work, and monitoring contractor progress closely. Incentives for adhering to schedules have not been found to be as effective as disincentives.

Key Terms

backward mapping A planning tool used to plan how to get to a final product or outcome by starting from the end point and going back to previous tasks.

baseline The final version of a project plan, schedule, and budget, used as a starting point for a project.

decomposition The process of breaking down the work into smaller and smaller pieces, from task, to subtask, to work pack- age, to level of effort.

level of effort The fourth level down in a WBS; work that leads to completion of a work package.

resources Labor and capital; labor is all personnel resources, and capital is all other resources, such as equipment, supplies, facilities, and system hardware.

schedule The plan for the sequence of tasks to be completed along with task durations, interdependencies, and resources associated with each task.

subtask A task at the second level in a WBS leading to completion of a task.

task The highest level of project work, com- pleted by rolling up subtasks, work pack- ages, and levels of effort; in other words, complete product design.

template A graphic framework or format that can be used generally, such as a tem- plate for a project schedule.

work package The third level in the WBS; tasks that lead to completion of subtasks.

bar81677_06_c06_173-198.indd 197 9/9/14 10:52 AM

bar81677_06_c06_173-198.indd 198 9/9/14 10:52 AM