When work packages are integrated with organizational units, a control point is created called a

7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 1/35

Page 100

PRINTED BY: lttlemntate@email.phoenix.edu. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

CHAPTER FOUR

Defining the Project

Defining the Project Step 1: Defining the Project Scope Step 2: Establishing Project Priorities Step 3: Creating the Work Breakdown Structure Step 4: Integrating the WBS with the Organization Step 5: Coding the WBS for the Information System Responsibility Matrices Project Communication Plan Summary

7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 2/35

Page 101

PRINTED BY: lttlemntate@email.phoenix.edu. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Select a dream Use your dream to set a goal Create a plan Consider resources Enhance skills and abilities Spend time wisely Start! Get organized and go

… it is one of those acro­whatevers, said Pooh.*

Project managers in charge of a single small project can plan and schedule the project tasks without much formal planning and information. However, when the project manager must manage several small projects or a large complex project, a threshold is quickly reached in which the project manager can no longer cope with the detail. This chapter describes a disciplined, structured method for selectively collecting information to use through

all phases of the project life cycle, to meet the needs of all stakeholders (e.g., customer, project manager), and to measure performance against the strategic plan of the organization. The method suggested is a selective outline of the project called the work breakdown structure. The early stages of developing the outline serve to ensure that all tasks are identified and that participants of the project have an understanding of what is to be done. Once the outline and its detail are defined, an integrated information system can be developed to schedule work and allocate budgets. This baseline information is later used for control. In addition, the chapter presents a variant of the work breakdown structure called the process breakdown

structure as well as responsibility matrices that are used for smaller, less complex projects. With the work of the project defined through the work breakdown structure, the chapter concludes with the process of creating a communication plan used to help coordinate project activities and follow progress. The five generic steps described herein provide a structured approach for collecting the project information

necessary for developing a work breakdown structure. These steps and the development of project networks found in the next chapters all take place concurrently, and several iterations are typically required to develop dates and budgets that can be used to manage the project. The old saying “We can control only what we have planned” is true; therefore, defining the project is the first step.

7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 3/35

Page 102

PRINTED BY: lttlemntate@email.phoenix.edu. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Step 1: Defining the Project Scope Defining the project scope sets the stage for developing a project plan. Project scope is a definition of the end result or mission of your project—a product or service for your client/customer. The primary purpose is to define as clearly as possible the deliverable(s) for the end user and to focus project plans. As fundamental and essential as scope definition appears, it is frequently overlooked by project leaders of well­managed, large corporations. Research clearly shows that a poorly defined scope or mission is the most frequently mentioned barrier to

project success. In a study involving more than 1,400 project managers in the United States and Canada, Gobeli and Larson (1986) found that approximately 50 percent of the planning problems relate to unclear definition of scope and goals. This and other studies suggest a strong correlation between project success and clear scope definition (cf., Ashley et al., 1987; Pinto and Slevin, 1988; Standish Group, 2009). The scope document directs focus on the project purpose throughout the life of the project for the customer and project participants. The scope should be developed under the direction of the project manager, customer, and other significant

stakeholders. The project manager is responsible for seeing that there is agreement with the owner on project objectives, deliverables at each stage of the project, technical requirements, and so forth. For example, a deliverable in the early stage might be specifications; for the second stage, three prototypes for production; for the third, a sufficient quantity to introduce to market; and finally, marketing promotion and training. Your project scope definition is a document that will be published and used by the project owner and project

participants for planning and measuring project success. Scope describes what you expect to deliver to your customer when the project is complete. Your project scope should define the results to be achieved in specific, tangible, and measurable terms.

Employing a Project Scope Checklist Clearly, project scope is the keystone interlocking all elements of a project plan. To ensure that scope definition is complete, you may wish to use the following checklist:

1. Project objective. The first step of project scope definition is to define the overall objective to meet your customer's need(s). For example, as a result of extensive market research a computer software company decides to develop a program that automatically translates verbal sentences in English to Russian. The project should be completed within three years at a cost not to exceed

7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 4/35

Page 103

PRINTED BY: lttlemntate@email.phoenix.edu. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

$1.5 million. Another example is to design and produce a completely portable, hazardous waste, thermal treatment system in 13 months at a cost not to exceed $13 million. The project objective answers the questions of what, when, and how much.

2. Deliverables. The next step is to define major deliverables—the expected, measurable outputs over the life of the project. For example, deliverables in the early design phase of a project might be a list of specifications. In the second phase deliverables could be software coding and a technical manual. The next phase could be the prototype. The final phase could be final tests and approved software. Note: Deliverables and requirements are often used interchangeably.

3. Milestones. A milestone is a significant event in a project that occurs at a point in time. The milestone schedule shows only major segments of work; it represents first, rough­cut estimates of time, cost, and resources for the project. The milestone schedule is built using the deliverables as a platform to identify major segments of work and an end date—for example, testing complete and finished by July 1 of the same year. Milestones should be natural, important control points in the project. Milestones should be easy for all project participants to recognize.

4. Technical requirements. More frequently than not, a product or service will have technical requirements to ensure proper performance. Technical requirements typically clarify either the deliverables or define the performance specifications. For example, a technical requirement for a personal computer might be the ability to accept 120­volt alternating current or 240­volt direct current without any adapters or user switches. Another well­known example is the ability of 911 emergency systems to identify the caller's phone number and location of the phone. Examples from information systems projects include speed and capacity of database systems and connectivity with alternative systems. For understanding the importance of key requirements, see Snapshot from Practice: Big Bertha.

5. Limits and exclusions. The limits of scope should be defined. Failure to do so can lead to false expectations and to expending resources and time on the wrong problem. Examples of limits are: local air transportation to and from base camps will be outsourced; system maintenance and repair will be done only up to one month after final inspection; client will be billed for additional training beyond that prescribed in the contract. Exclusions further define the boundary of the project by stating what is not included. Examples include: data will be collected by the client, not the contractor; a house will be built, but no landscaping or security devices added; software will be installed, but no training given.

6. Reviews with customer. Completion of the scope checklist ends with a review with your customer— internal or external. The main concern here is the understanding and agreement of expectations. Is the customer getting what he or she desires in deliverables? Does the project definition identify key accomplishments, budgets, timing, and performance requirements? Are questions of limits and exclusions covered? Clear communication in all these issues is imperative to avoid claims or misunderstanding.

Scope definition should be as brief as possible but complete; one or two pages are typical for small projects. See Snapshot from Practice: Scope Statement on page 105.

https://jigsaw.vitalsource.com/books/1259822338/epub/OEBPS/14_chapter04.xhtml#page105
7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 5/35

Page 104

PRINTED BY: lttlemntate@email.phoenix.edu. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

SNAPSHOT FROM PRACTICE Big Bertha II versus the USGA's COR Requirement*

© Time & Life Pictures/Getty Images

In 1991 Callaway Golf Equipment introduced their Big Bertha driver and revolutionized the golf equipment business. Big Bertha—named after the World War I German long­distance cannon—was much larger than conventional woods and lacked a hosel (the socket in the head of the club into which the shaft is inserted) so that the weight could be better distributed throughout the head. This innovative design gave the clubhead a larger sweet spot, which allowed a player to strike the golf ball off­center and not suffer much loss in distance or accuracy. Callaway has maintained its preeminent position in the golf industry by utilizing space­age technology to extend the accuracy and distance of golf equipment. In 2000 Callaway introduced the Big Bertha ERC II forged titanium driver. The driver was technologically superior

to any driver on the market. However, there was one big problem. The new version of Bertha did not conform to the coefficient of restitution (COR) requirement established by the United States Golf Association (USGA). As a result it was barred from use by golfers in North America who intended to play by USGA's Rules of Golf. The USGA believed that the rapid technological advances in golf equipment made by Callaway Golf and other golf

manufacturers were threatening the integrity of the game. Players were hitting balls so much farther and straighter that golf courses around the world were being redesigned to make them longer and more difficult.

7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 6/35

So in 1998 the USGA established performance thresholds for all new golf equipment. In order to prevent manufacturers from developing more powerful clubs, the USGA limited the COR of new golf equipment to 0.83. The COR was calculated by firing a golf ball at a driver out of a cannon­like machine at 109 miles per hour. The speed that the ball returned to the cannon could not exceed 83 percent of its initial speed (90.47 mph). The USGA called the ratio of incoming to outgoing velocity the coefficient of restitution (COR). The intent of the USGA COR threshold was to limit the distance that golf balls could be hit since studies indicated that 0.01 increase in COR resulted in two extra yards of carry. The Big Bertha ERC II's COR was 0.86. After numerous efforts to get USGA to change its technical requirements, Callaway's engineers went back to the

drawing board and in 2002 introduced Great Big Bertha II, which conformed to USGA's 0.83 COR restriction.

* John E. Gamble. “Callaway Golf Company: Sustaining Advantage in a Changing Industry,” in A. A. Thompson, J. E. Gamble, and A. J. Strickland, Strategy: Winning in the Marketplace, Boston: McGraw­Hill/Irwin, 2004, pp. C204–C228.

7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 7/35

Page 105

PRINTED BY: lttlemntate@email.phoenix.edu. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

SNAPSHOT FROM PRACTICE Scope Statement

PROJECT OBJECTIVE To construct a high­quality, custom home within five months at cost not to exceed $500,000.

DELIVERABLES

A 2,200­square­foot, 2½­bath, 3­bedroom, finished home. A finished garage, insulated and sheetrocked. Kitchen appliances to include range, oven, microwave, and dishwasher. High­efficiency gas furnace with programmable thermostat.

MILESTONES

1. Permits approved—March 5 2. Foundation poured—March 14 3. Drywall in. Framing, sheathing, plumbing, electrical, and mechanical inspections passed—May 25 4. Final inspection—June 7

TECHNICAL REQUIREMENTS

1. Home must meet local building codes. 2. All windows and doors must pass NFRC class 40 energy ratings. 3. Exterior wall insulation must meet an “R” factor of 21. 4. Ceiling insulation must meet an “R” factor of 38. 5. Floor insulation must meet an “R” factor of 25. 6. Garage will accommodate two large­size cars and one 20­foot Winnebago. 7. Structure must pass seismic stability codes.

LIMITS AND EXCLUSIONS

1. The home will be built to the specifications and design of the original blueprints provided by the customer. 2. Owner is responsible for landscaping. 3. Refrigerator is not included among kitchen appliances. 4. Air conditioning is not included but prewiring is included. 5. Contractor reserves the right to contract out services. 6. Contractor is responsible for subcontracted work. 7. Site work limited to Monday through Friday, 8:00 A.M. to 6:00 P.M.

CUSTOMER REVIEW John and Joan Smith

7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 8/35

The checklist on pages 102–103 is generic. Different industries and companies will develop unique checklists and templates to fit their needs and specific kinds of projects. A few companies engaged in contracted work refer to scope statements as “statements of work” (SOW). Other organizations use the term project charter. However, the term project charter has emerged to have a special meaning in the world of project management. A project charter refers to a document that authorizes the project manager to initiate and lead the project. This document is issued by upper management and provides the project manager with written authority to use organizational resources for project activities. Often the charter will include a brief scope description as well as such items as risk limits, customer needs, spending limits, and even team composition. Many projects suffer from scope creep, which is the tendency for the project scope to expand over time—

usually by changing requirements, specifications, and priorities. Scope creep can be reduced by carefully writing your scope statement. A scope statement that is too broad is an invitation for scope creep. Scope creep can have a positive or negative effect on the project, but in most cases scope creep means added costs and possible project delays. Changes in requirements, specifications, and priorities frequently result in cost overruns and delays. Examples are abundant—Denver airport baggage handling system; Boston's new freeway system (“The Big Dig”); China's fast train in Shanghai; and the list goes on. On software development projects, scope creep is manifested in bloated products in which added functionality undermines ease of use.

https://jigsaw.vitalsource.com/books/1259822338/epub/OEBPS/14_chapter04.xhtml#page102
https://jigsaw.vitalsource.com/books/1259822338/epub/OEBPS/14_chapter04.xhtml#page103
7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 9/35

Page 106

PRINTED BY: lttlemntate@email.phoenix.edu. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

If the project scope needs to change, it is critical to have a sound change control process in place that records the change and keeps a log of all project changes. The log identifies the change, impact, and those responsible for accepting or rejecting a proposed change. Change control is one of the topics of Chapter 7. Project managers in the field constantly suggest that dealing

with changing requirements is one of their most challenging problems.

Step 2: Establishing Project Priorities Quality and the ultimate success of a project are traditionally defined as meeting and/or exceeding the expectations of the customer and/or upper management in terms of cost (budget), time (schedule), and performance (scope) of the project (see Figure 4.1). The interrelationship among these criteria varies. For example, sometimes it is necessary to compromise the performance and scope of the project to get the project done quickly or less expensively. Often the longer a project takes, the more expensive it becomes. However, a positive correlation between cost and schedule may not always be true. Other times project costs can be reduced by using cheaper, less efficient labor or equipment that extends the duration of the project. Likewise, as will be seen in Chapter 9, project managers are often forced to expedite or “crash” certain key activities by adding additional labor, thereby raising the original cost of the project. One of the primary jobs of a project manager is to manage the trade­offs among time, cost, and performance.

To do so, project managers must define and understand the nature of the priorities of the project. They need to have a candid discussion with the project customer and upper management to establish the relative importance of each criterion. For example, what happens when the customer keeps adding requirements? Or if, midway through the project, a trade­off must be made between cost and expediting, which criterion has priority? One technique found in practice that is useful for this purpose is completing a priority matrix for the project

to identify which criterion is constrained, which should be enhanced, and which can be accepted:

Constrain. The original parameter is fixed. The project must meet the completion date, specifications and scope of the project, or budget. Enhance. Given the scope of the project, which criterion should be optimized? In the case of time and cost, this usually means taking advantage of opportunities to either reduce costs or shorten the schedule. Conversely, with regard to performance, enhancing means adding value to the project.

FIGURE 4.1 Project Management Trade­offs

https://jigsaw.vitalsource.com/books/1259822338/epub/OEBPS/17_chapter07.xhtml#chap7
https://jigsaw.vitalsource.com/books/1259822338/epub/OEBPS/19_chapter09.xhtml#chap9
7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 10/35

Page 107

PRINTED BY: lttlemntate@email.phoenix.edu. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

FIGURE 4.2 Project Priority Matrix

Accept. For which criterion is it tolerable not to meet the original parameters? When trade­offs have to be made, is it permissible for the schedule to slip, to reduce the scope and performance of the project, or to go over budget?

Figure 4.2 displays the priority matrix for the development of a new wireless modem. Because time to market is important to sales, the project manager is instructed to take advantage of every opportunity to reduce completion time. In doing so, going over budget is acceptable though not desirable. At the same time, the original performance specifications for the modem as well as reliability standards cannot be compromised. Priorities vary from project to project. For example, for many software projects time to market is critical, and

companies like Microsoft may defer original scope requirements to later versions in order to get to the market first. Alternatively, for special event projects (conferences, parades, tournaments) time is constrained once the date has been announced, and if the budget is tight, the project manager will compromise the scope of the project in order to complete the project on time. Some would argue that all three criteria are always constrained and that good project managers should seek to

optimize each criterion. If everything goes well on a project and no major problems or setbacks are encountered, their argument may be valid. However, this situation is rare, and project managers are often forced to make tough decisions that benefit one criterion while compromising the other two. The purpose of this exercise is to define and agree on what the priorities and constraints of the project are so that when “push comes to shove,” the right decisions can be made. There are likely to be natural limits to the extent managers can constrain, optimize, or accept any one

criterion. It may be acceptable for the project to slip one month behind schedule but no further or to exceed the planned budget by as much as $20,000. Likewise, it may be desirable to finish a project a month early, but after that cost conservation should be the primary goal. Some project managers document these limits as part of creating the priority matrix. In summary, developing a priority matrix for a project before the project begins is a useful exercise. It

provides a forum for clearly establishing priorities with customers and top management so as to create shared expectations and avoid misunderstandings. The priority information is essential to the planning process, where adjustments can be made in the scope, schedule, and budget allocation.

7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 11/35

Page 108

PRINTED BY: lttlemntate@email.phoenix.edu. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Finally, the matrix is useful midway in the project for approaching a problem that must be solved. One caveat must be mentioned; during the course of a project, priorities may change. The

customer may suddenly need the project completed one month sooner, or new directives from top management may emphasize cost saving initiatives. The project manager needs to be vigilant in order to anticipate and confirm changes in priorities and make appropriate adjustments.

Step 3: Creating the Work Breakdown Structure

Major Groupings Found in a WBS Once the scope and deliverables have been identified, the work of the project can be successively subdivided into smaller and smaller work elements. The outcome of this hierarchical process is called the work breakdown structure (WBS). Use of WBS helps to assure project managers that all products and work elements are identified, to integrate the project with the current organization, and to establish a basis for control. Basically, the WBS is an outline of the project with different levels of detail. Figure 4.3 shows the major groupings commonly used in the field to develop a hierarchical WBS. The WBS

begins with the project as the final deliverable. Major

7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 12/35

Page 109

PRINTED BY: lttlemntate@email.phoenix.edu. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

project work deliverables/systems are identified first; then the subdeliverables necessary to accomplish the larger deliverables are defined. The process is repeated until the subdeliverable detail is small enough to be manageable and where one person can be responsible. This subdeliverable is further divided into work packages. Because the lowest subdeliverable usually includes several work packages, the work packages are grouped by type of work—for example, design and testing. These groupings within a subdeliverable are called cost accounts. This grouping facilitates a system for monitoring project progress by work, cost, and responsibility.

FIGURE 4.3 Hierarchical Breakdown of the WBS

How WBS Helps the Project Manager The WBS defines all the elements of the project in a hierarchical framework and establishes their relationships to the project end item(s). Think of the project as a large work package that is successively broken down into smaller work packages; the total project is the summation of all the smaller work packages. This hierarchical structure facilitates evaluation of cost, time, and technical performance at all levels in the organization over the life of the project. The WBS also provides management with information appropriate to each level. For example, top management deals primarily with major deliverables, while first­line supervisors deal with smaller subdeliverables and work packages.

7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 13/35

Each item in the WBS needs a time and cost estimate. With this information it is possible to plan, schedule, and budget your project. The WBS also serves as a framework for tracking cost and work performance. As the WBS is developed, organizational units and individuals are assigned responsibility for executing work

packages. This integrates the work and the organization. In practice, this process is sometimes called the organization breakdown structure (OBS), which will be further discussed later in the chapter. Use of the WBS provides the opportunity to “roll up” (sum) the budget and actual costs of the smaller work

packages into larger work elements so that performance can be measured by organizational units and work accomplishment. The WBS can also be used to define communication channels and assist in understanding and coordinating

many parts of the project. The structure shows the work and organizational units responsible and suggests where written communication should be directed. Problems can be quickly addressed and coordinated because the structure integrates work and responsibility.

A Simple WBS Development Figure 4.4 shows a simplified WBS to develop a new prototype tablet computer. At the top of the chart (level 1) is the project end item—the E­Slim Tablet x­13 Prototype. The subdeliverables levels (2–5) below level 1 represent further decomposition of work. The levels of the structure can also represent information for different levels of management. For example, level 1 information represents the total project objective and is useful to top management; levels 2, 3, and 4 are suitable for middle management; and level 5 is for first­line managers. In Figure 4.4 level 2 indicates there are two major deliverables—Hardware and CPU, or central processing

unit. (There are likely to be other major deliverables such as software, but for illustrative purposes we are limiting our focus to just two major deliverables.) At level 3, the CPU is connected to three deliverables— Power Supply, Flash ROM, and I/O Controller. The I/O Controller has three subdeliverables at level 4—USB Slots, Internet, and Touch Screen. The many subdeliverables for USB Slots and Internet have not been decomposed. The Touch Screen (shaded) has been decomposed down to level 5 and to the work package level.

7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 14/35

Page 110

PRINTED BY: lttlemntate@email.phoenix.edu. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

FIGURE 4.4 Work Breakdown Structure

7/15/2017 University of Phoenix: Project Management: The Managerial Process

https://phoenix.vitalsource.com/#/books/1259822338/cfi/6/30!/4/248/2/2@0:0 15/35

Page 111

PRINTED BY: lttlemntate@email.phoenix.edu. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without publisher's prior permission. Violators will be prosecuted.

Note that level 2, Hardware, skips levels 3 and 4 because the final subdeliverables can be pushed down to the lowest manageable level 5; skipping levels 3 and 4 suggests little coordination is needed and skilled team members are already familiar with the work needed to complete the level 5 subdeliverables. For example, Hardware requires four subdeliverables at level 5—Frame, Cameras, Speakers, and Antenna. Each subdeliverable includes work packages that will be completed by an assigned organizational unit. Observe that the Cameras subdeliverable includes four work packages—WP­C1, 2, 3, and 4. The Back Light, a subdeliverable of Touch Screen, includes three work packages—WP­L 1, 2, and 3. The lowest level of the WBS is called a work package. Work packages are short­duration tasks that have a

definite start and stop point, consume resources, and represent cost. Each work package is a control point. A work package manager is responsible for seeing that the package is completed on time, within budget, and according to technical specifications. Practice suggests a work package should not exceed 10 workdays or one reporting period. If a work package has a duration exceeding 10 days, check or monitoring points should be established within the duration, say, every three to five days, so progress and problems can be identified before too much time has passed. Each work package of the WBS should be as independent of other packages of the project as possible. No work package is described in more than one subdeliverable of the WBS. There is an important difference from start to finish between the last work breakdown subdeliverable and a

work package. Typically, a work breakdown sub­deliverable includes the outcomes of more than one work package from perhaps two or three departments. Therefore, the subdeliverable does not have a duration of its own and does not consume resources or cost money directly. (In a sense, of course, a duration for a particular work breakdown element can be derived from identifying which work package must start first [earliest] and which package will be the latest to finish; the difference from start to finish becomes the duration for the subdeliverable.) The higher elements are used to identify deliverables at different phases in the project and to develop status reports during the execution stage of the project life cycle. Thus, the work package is the basic unit used for planning, scheduling, and controlling the project.