College of Administrative and Financial Sciences

Assignment 2

Deadline: 28/March/2020 @ 23:59

Course Name: Project Management

Student’s Name:

Course Code: MGT323

Student’s ID Number:

Semester: II

CRN:

Academic Year: 1440/1441 H

For Instructor’s Use only

Instructor’s Name:

Students’ Grade: Marks Obtained/Out of

Level of Marks: High/Middle/Low

Instructions – PLEASE READ THEM CAREFULLY
· The Assignment must be submitted on Blackboard (WORD format only) via allocated folder.
· Assignments submitted through email will not be accepted.
· Students are advised to make their work clear and well presented, marks may be reduced for poor presentation. This includes filling your information on the cover page.
· Students must mention question number clearly in their answer.
· Late submission will NOT be accepted.
· Avoid plagiarism, the work should be in your own words, copying from students or other resources without proper referencing will result in ZERO marks. No exceptions.
· All answered must be typed using Times New Roman (size 12, double-spaced) font. No pictures containing text will be accepted and will be considered plagiarism).
· Submissions without this cover page will NOT be accepted.

ASSIGNMENT-2

Project Management (MGT323)

Second Semester (2019-2020)

Assignment Workload:

· This Assignment consists of Critical thinking Question.
· Assignment is to be submit by each student individually.

Assignment Purposes/Learning Outcomes:

After completion of Assignment-2 students will able to understand the
Demonstrate a deep understanding of project management concepts and theories as well as approaches to project management. (LO-1.1)
Demonstrate an understanding of the project planning process. (LO-1.6)

Assignment Regulation:

· All students are encouraged to use their own words.
· Student must apply “Times New Roman Font” with double space within their reports.
· The attached cover-page has to be used, duly filled. Submissions without the cover page will NOT be accepted
· A mark of zero will be given for any submission that includes copying from other resource without referencing it.
· Assignment -2 should be submitted on or before the end of Week-10.
· If the assignment shows more than 25% plagiarism, the students would be graded zero.

Assignment Structure:

A.No

Type

Marks

Assignment-1

Essay

5

Assignment-2

Critical Thinking

10

Assignment-3

Case study

10

Total

25

Assignment Question(s): (Marks-10)
“Failing to plan is planning to fail”, is the proverb that affect project planning. Based on this proverb you are required to answer the questions given below. For better understanding, please refer your textbook chapter-11 and answer accordingly.
1. List few consequences, which arises due to poor planning, and explain them in your words. Give an example of any product, which failed, in the market due to poor planning. (2.5 Marks)
2. Do you think systematic planning help in setting goals and making decisions? Give reasons to support your answer by choosing any event (e.g. product launch, conducting exhibitions etc). (2.5 Marks)
3. Describe the above given proverb with an example based on your understanding. (2 Marks)
4. Identify the type of planning required to establish effective monitoring and controlling in the display of products in Supermarkets and explain the process with any example of your choice. (Refer Pg-413, Figure-11-1 for your understanding). (3 Marks)

Answer:

1.
2.
3.
4.

Planning

Related Case Studies

(from Kerzner/Project

Management Case Studies,

3rd Edition)

Related Workbook Exercises (from

Kerzner/Project

Management

Workbook and PMP®/CAPM® Exam

Study Guide, 10th Edition)

PMBOK
®
Guide, 4th

Edition, Reference

Section for the PMP
®

Certification Exam

• Quantum Telecom

• Concrete Masonry

Corporation*

• Margo Company

• Project Overrun

• The Two-Boss Problem

• Denver International

Airport (DIA)

• The Statement of

Work

• Technology Forecasting

• The Noncompliance Project

• Multiple Choice Exam

• Crossword Puzzle on

Scope

Management

• Scope

Management

11.0 INTRODUCTION

The most important responsibilities of a project manager are planning,

integrating, and executing plans. Almost all projects, because of their rel-

atively short duration and often prioritized control of resources, require

formal, detailed planning. The integration of the planning activities is

* Case Study also appears in Workbook

.

41

1

11

PMBOK
®

Guide, 4th Edition
Chapter 5 Scope Management

5.2 Define Scope

necessary because each functional unit may develop its own planning documentation with little regard for

other functional units.

Planning, in general, can best be described as the function of selecting the enterprise objectives and

establishing the policies, procedures, and programs necessary for achieving them. Planning in a

project

environment may be described as establishing a predetermined course of action within a forecasted envi-

ronment. The project’s requirements set the major milestones. If line managers cannot commit because

the milestones are perceived as unrealistic, the project manager may have to develop alternatives, one

of

which may be to move the milestones. Upper-level management must become involved in the selection

of alternatives.

The project manager is the key to successful project planning. It is desirable that the project manager

be involved from project conception through execution. Project planning must be systematic, flexible

enough to handle unique activities, disciplined through reviews and controls, and capable of accepting multi-

functional inputs. Successful project managers realize that project planning is an iterative process and must

be performed throughout the life of the project.

One of the objectives of project planning is to completely define all

work required (possibly through the development of a documented project

plan) so that it will be readily identifiable to each project participant. This

is a necessity in a project environment because

:

● If the task is well understood prior to being performed, much of the work can be preplanned.

● If the task is not understood, then during the actual task execution more knowledge is gained that,

in turn, leads to changes in resource allocations, schedules, and priorities.

● The more uncertain the task, the greater the amount of information that must be processed in order

to ensure effective performance.

These considerations are important in a project environment because each project can be different from

the others, requiring a variety of different resources, but having to be performed under time, cost, and per –

formance constraints with little margin for error. Figure 11–1 identifies the type of project planning

required to establish an effective monitoring and control system. The boxes at the top represent the plan-

ning activities, and the lower boxes identify the “tracking” or monitoring of the planned activities.

There are two proverbs that affect project planning:

● Failing to plan is planning to fail.

● The primary benefit of not planning is that failure will then come as a complete surprise rather than

being preceded by periods of worry and depression.

Without proper planning, programs and projects can start off “behind the eight ball.” Consequences of

poor planning

include:

● Project initiation without defined

requirements

● Wild enthusiasm

● Disillusionment

● Chaos

● Search for the guilty

● Punishment of the innocent

● Promotion of the nonparticipants

PMBOK
®

Guide, 4th Edition
5.2 Define Scope

MASTER/DETAILED

SCHEDULES

MANAGEMENT DECISION-MAKING BUDGETS

SYSTEM REPORTS
TIME/COST/PERFORMANCE

TRACKING

FEEDBACK

•

TIME

•

COST

• PERFORMANCE
• RELIABILITY
• MAINTAINABILITY
• EFFECTIVENESS

TIME

PERT/CPM

SPECS SOW

WBS

STATES OF NATURE

PAYOFF TABLES

WORK DESCRIPTION

AND INSTRUCTIONS

NETW ORK SCHEDULING

GOALS/OBJECTIVES

• SYSTEM LEVEL

• COMPANY LEVEL

FIGURE 11–1. The project planning and control system.

$

4
1
3

S
T

R
A

T
E

G
IE

S

General Planning 41

4

There are four basic reasons for project planning:

● To eliminate or reduce uncertainty

● To improve efficiency of the operation

● To obtain a better understanding of the

objectives

● To provide a basis for monitoring and controlling work

Planning is a continuous process of making entrepreneurial decisions with an eye to the future, and

methodically organizing the effort needed to carry out these decisions. Furthermore, systematic planning

allows an organization of set goals. The alternative to systematic planning is decision-making based on his-

tory. This generally results in reactive management leading to crisis management, conflict management,

and fire

fighting.

11.1 VALIDATING THE ASSUMPTIONS

Planning begins with an understanding of the assumptions. Quite often, the assumptions

are made by marketing and sales personnel and then approved by senior management as

part of the project selection and approval process. The expectations for the final results are

based upon the assumptions made.

Why is it that, more often than not, the final results of a project do not satisfy senior

management’s expectations? At the beginning of a project, it is impossible to ensure that

the benefits expected by senior management will be realized at project completion. While

project length is a critical factor, the real culprit is changing assumptions.

Assumptions must be documented at project initiation using the project charter as a

possible means. Throughout the project, the project manager must revalidate and challenge

the assumptions. Changing assumptions may mandate that the project be terminated or

redirected toward a different set of objectives.

A project management plan is based upon the assumptions described in the project

charter. But there are additional assumptions made by the team that are inputs to the pro-

ject management plan.1 One of the primary reasons companies use a project charter is that

project managers were most often brought on board well after the project selection process

and approval process were completed. As a result, project managers were needed to know

what assumptions were considered.

Enterprise Environmental
Factors

These are assumptions about the external environmental conditions

that can affect the success of the project, such as interest rates, market

conditions, changing customer demands and requirements, changes in

technology, and even government policies.

1. See A Guide to the Project Management Body of Knowledge®, 4th ed., 2008, Figure 4-4.

General Planning 41

5

Organizational Process
Assets

These are assumptions about present or future company assets that can

impact the success of the project such as the capability of your enter-

prise project management methodology, the project management

information system, forms, templates, guidelines, checklists, and the ability to capture and

use lessons learned data and best practices.

11.2 GENERAL

PLANNING

Planning is determining what needs to be done, by whom, and by when,

in order to fulfill one’s assigned responsibility. There are nine major com-

ponents of the planning phase:

● Objective: a goal, target, or quota to be achieved by a certain time

● Program: the strategy to be followed and major actions to be taken in order to

achieve or exceed objectives

● Schedule: a plan showing when individual or group activities or accomplishments

will be started and/or completed

● Budget: planned expenditures required to achieve or exceed objectives

● Forecast: a projection of what will happen by a certain time

● Organization: design of the number and kinds of positions, along with corre-

sponding duties and responsibilities, required to achieve or exceed objectives

● Policy: a general guide for decision-making and individual actions

● Procedure: a detailed method for carrying out a policy

● Standard: a level of individual or group performance defined as adequate or

acceptable

An item that has become important in recent years is documenting assumptions that

go into the objectives or the project/subsidiary plans. As projects progress, even for short-

term projects, assumptions can change because of the economy, technological advances,

or market conditions. These changes can invalidate original assumptions or require that

new assumptions be made. These changes could also mandate that projects be canceled.

Companies are now validating assumptions during gate review meetings. Project charters

now contain sections for documenting assumptions.

Several of these factors require additional comment. Forecasting what will happen may

not be easy, especially if predictions of environmental reactions are required. For example,

planning is customarily defined as either strategic, tactical, or operational. Strategic plan-

ning is generally for five years or more, tactical can be for one to five years, and operational

is the here and now of six months to one year. Although most projects are operational, they

can be considered as strategic, especially if spin-offs or follow-up work is promising.

Forecasting also requires an understanding of strengths and weaknesses as found in:

● The competitive situation

● Marketing

PMBOK
®
Guide, 4th Edition
Chapter 5 Scope Management

1.6 General Management

Knowledge and Skills

General Planning 41

6

● Research and development

● Production

● Financing

● Personnel

● The management

structure

If project planning is strictly operational, then these factors may be clearly definable.

However, if strategic or long-range planning is necessary, then the future economic outlook

can vary, say, from year to year, and replanning must be done at regular intervals because

the goals and objectives can change. (The procedure for this can be seen in Figure 11–1.)

The last three factors, policies, procedures, and standards, can vary from project to

project because of their uniqueness. Each project manager can establish project policies,

provided that they fall within the broad limits set forth by

top management.

Project policies must often conform closely to company policies, and are usually sim-

ilar in nature from project to project. Procedures, on the other hand, can be drastically dif-

ferent from project to project, even if the same activity is performed. For example, the

signing off of manufacturing plans may require different signatures on two selected projects

even though the same end-item is being produced.

Planning varies at each level of the organization. At the individual level, planning is

required so that cognitive simulation can be established before irrevocable actions are

taken. At the working group or functional level, planning must include:

● Agreement on purpose

● Assignment and acceptance of individual responsibilities

● Coordination of work activities

● Increased commitment to group goals

● Lateral communications

At the organizational or project level, planning must include:

● Recognition and resolution of group conflict on goals

● Assignment and acceptance of group responsibilities

● Increased motivation and commitment to organizational goals

● Vertical and lateral communications

● Coordination of activities between groups

The logic of planning requires answers to several questions in order for the alterna-

tives and constraints to be fully understood. A list of questions would include:

● Prepare environmental analysis

● Where are we?

● How and why did we get here?

General Planning 41

7

● Set objectives

● Is this where we want to be?

● Where would we like to be? In a year? In five years?

● List alternative strategies

● Where will we go if we continue as before?

● Is that where we want to go?

● How could we get to where we want to go?

● List threats and opportunities

● What might prevent us from getting there?

● What might help us to get there?

● Prepare forecasts

● Where are we capable of going?

● What do we need to take us where we want to go?

● Select strategy portfolio

● What is the best course for us to take?

● What are the potential benefits?

● What are the risks?

● Prepare action programs

● What do we need to do?

● When do we need to do it?

● How will we do it?

● Who will do it?

● Monitor and control

● Are we on course? If not, why?

● What do we need to do to be on course?

● Can we do it?

One of the most difficult activities in the project environment is to keep the planning

on target. These procedures can assist project managers during planning activities:

● Let functional managers do their own planning. Too often operators are operators,

planners are planners, and never the twain shall meet.

● Establish goals before you plan. Otherwise short-term thinking takes over.

● Set goals for the planners. This will guard against the nonessentials and places

your effort where there is payoff.

● Stay flexible. Use people-to-people contact, and stress fast response.

● Keep a balanced outlook. Don’t overreact, and position yourself for an upturn.

● Welcome top-management participation. Top management has the capability to

make or break a plan, and may well be the single most important variable.

● Beware of future spending plans. This may eliminate the tendency to underestimate.

● Test the assumptions behind the forecasts. This is necessary because professionals

are generally too optimistic. Do not depend solely on one set of data.

General Planning 41

8

● Don’t focus on today’s problems. Try to get away from crisis management and fire

fighting.

● Reward those who dispel illusions. Avoid the Persian messenger syndrome (i.e.,

beheading the bearer of bad tidings). Reward the first to come forth with bad news.

11.3 LIFE-CYCLE PHASES

Project planning takes place at two levels. The first level is the corporate cul-

tural approach; the second method is the individual’s approach. The corpo-

rate cultural approach breaks the project down into life-cycle phases, such as

those shown in Table 2–6. The life-cycle phase approach is not an attempt to

put handcuffs on the project manager but to provide a methodology for uni-

formity in project planning. Many companies, including government agen-

cies, prepare checklists of activities that should be considered in each phase. These checklists

are for consistency in planning. The project manager can still exercise his own planning ini-

tiatives within each phase.

A second benefit of life-cycle phases is control. At the end of each phase there is a

meeting of the project manager, sponsor, senior management, and even the customer, to

assess the accomplishments of this life-cycle phase and to get approval for the next phase.

These meetings are often called critical design reviews, “on-off ramps,” and “gates.” In

some companies, these meetings are used to firm up budgets and schedules for the follow-

on phases. In addition to monetary considerations, life-cycle phases can be used for man-

power deployment and equipment/facility utilization. Some companies go so far as to

prepare project management policy and procedure manuals where all information is sub-

divided according to life-cycle phasing. Life-cycle phase decision points eliminate the

problem where project managers do not ask for phase funding, but rather ask for funds for

the whole project before the true scope of the project is known. Several companies have

even gone so far as to identify the types of decisions that can be made at each end-of-phase

review meeting. They include:

● Proceed with the next phase based on an approved funding level

● Proceed to the next phase but with a new or modified set of objectives

● Postpone approval to proceed based on a need for additional information

● Terminate project

Consider a company that utilizes the following life-cycle phases:

● Conceptualization

● Feasibility

● Preliminary planning

● Detail planning

● Execution

● Testing and commissioning

PMBOK
®

Guide, 4th Edition
Chapter 2 Project

Life Cycle

and

Organization

2.1 Characteristics of Project

Phases

Life-Cycle Phases 419

The conceptualization phase includes brainstorming and common sense and involves

two critical factors: (1) identify and define the problem, and (2) identify and define poten-

tial solutions.

In a brainstorming session, all ideas are recorded and none are discarded. The brain-

storming session works best if there is no formal authority present and if it lasts thirty to sixty

minutes. Sessions over sixty minutes will produce ideas that may resemble science fiction.

The feasibility study phase considers the technical aspects of the conceptual alterna-

tives and provides a firmer basis on which to decide whether to undertake the project.

The purpose of the feasibility phase is to:

● Plan the project development and implementation activities.

● Estimate the probable elapsed time, staffing, and equipment

requirements.

● Identify the probable costs and consequences of investing in the new project.

If practical, the feasibility study results should evaluate the alternative conceptual

solutions along with associated benefits and costs.

The objective of this step is to provide management with the predictable results of

implementing a specific project and to provide generalized project requirements. This, in

the form of a feasibility study report, is used as the basis on which to decide whether to

proceed with the costly requirements, development, and implementation phases.

User involvement during the feasibility study is critical. The user must supply much

of the required effort and information, and, in addition, must be able to judge the impact of

alternative approaches. Solutions must be operationally, technically, and economically fea-

sible. Much of the economic evaluation must be substantiated by the user. Therefore, the

primary user must be highly qualified and intimately familiar with the workings of

the organization and should come from the line operation.

The feasibility study also deals with the technical aspects of the proposed project and

requires the development of conceptual solutions. Considerable experience and techni-

cal expertise are required to gather the proper information, analyze it, and reach practical

conclusions.

Improper technical or operating decisions made during this step may go undetected or

unchallenged throughout the remainder of the process. In the worst case, such an error

could result in the termination of a valid project—or the continuation of a project that is

not economically or technically feasible.

In the feasibility study phase, it is necessary to define the project’s basic approaches

and its boundaries or scope. A typical feasibility study checklist might include:

● Summary level

● Evaluate alternatives

● Evaluate market potential

● Evaluate cost effectiveness

● Evaluate producibility

● Evaluate technical base

● Detail level

● A more specific determination of the problem

● Analysis of the state-of-the-art technology

Life-Cycle Phases 42

0

● Assessment of in-house technical capabilities

● Test validity of alternatives

● Quantify weaknesses and unknowns

● Conduct trade-off analysis on time, cost, and performance

● Prepare initial project goals and objectives

● Prepare preliminary cost estimates and development plan

The end result of the feasibility study is a management decision on whether to terminate

the project or to approve its next phase. Although management can stop the project at several

later phases, the decision is especially critical at this point, because later phases require a major

commitment of resources. All too often, management review committees approve the continu-

ation of projects merely because termination at this point might cast doubt on the group’s judg-

ment in giving earlier

approval.

The decision made at the end of the feasibility study should identify those projects that

are to be terminated. Once a project is deemed feasible and is approved for development,

it must be prioritized with previously approved projects waiting for development (given a

limited availability of capital or other resources). As development gets under way, man-

agement is given a series of checkpoints to monitor the project’s actual progress as com-

pared to the plan.

The third life-cycle phase is either preliminary planning or “defining the require-

ments.” This is the phase where the effort is officially defined as a project. In this phase,

we should consider the following:

● General scope of the work

● Objectives and related background

● Contractor’s tasks

● Contractor end-item performance requirements

● Reference to related studies, documentation, and specifications

● Data items (documentation)

● Support equipment for contract end-item

● Customer-furnished property, facilities, equipment, and services

● Customer-furnished documentation

● Schedule of performance

● Exhibits, attachments, and appendices

These elements can be condensed into four core documents, as will be shown in

Section 11.7. Also, it should be noted that the word “customer” can be an internal cus-

tomer, such as the user group or your own executives.

The table below shows the percentage of direct labor hours/dollars that are spent in

each phase:

Percent of Direct

Phase Labor Dollars

Conceptualization 5
Feasibility study

10

Preliminary planning

15

Detail planning 20

Execution 40

Commissioning 10

Kickoff Meetings 421

The interesting fact from this table is that as much as 50 percent of the direct labor hours

and dollars can be spent before execution begins. The reason for this is simple: Quality must

be planned for and designed in. Quality cannot be inspected into the project. Companies that

spend less than these percentages usually find quality problems in execution.

11.4 PROPOSAL PREPARATION

There is always a question of what to do with a project manager between assignments. For

companies that survive on competitive bidding, the assignment is clear: The project man-

ager writes proposals for future work. This takes place during the feasibility study, when

the company must decide whether to bid on the job. There are four ways in which proposal

preparation can occur:

● Project manager prepares entire proposal. This occurs frequently in small compa-

nies. In large organizations, the project manager may not have access to all avail-

able data, some of which may be company proprietary, and it may not be in the best

interest of the company to have the project manager spend all of his time doing this.

● Proposal manager prepares entire proposal. This can work as long as the project

manager is allowed to review the proposal before delivery to the customer and

feels committed to its direction.

● Project manager prepares proposal but is assisted by a proposal manager. This is

common, but again places tremendous pressure on the project manager.

● Proposal manager prepares proposal but is assisted by a project manager. This is

the preferred method. The proposal manager maintains maximum authority and

control until such time as the proposal is sent to the customer, at which point the

project manager takes charge. The project manager is on board right from the start,

although his only effort may be preparing the technical volume of the proposal and

perhaps part of the management volume.

11.5 KICKOFF MEETINGS

The typical launch of a project begins with a kickoff meeting involving the major players

responsible for planning, including the project manager, assistant project managers for cer-

tain areas of knowledge, subject matter experts (SME), and functional leads. A typical

sequence is shown in Figure 11–2.

There can be multiple kickoff meetings based upon the size, complexity, and time

requirements for the project. The major players are usually authorized by their functional

areas to make decisions concerning timing, costs, and resource requirements.

Some of the items discussed in the initial kickoff meeting include:

● Wage and salary administration, if applicable

● Letting the employees know that their boss will be informed as to how well or how

poorly they perform

Kickoff Meetings 42

2

TYPICAL PROJECT LAUNCH

Figure 11–2. Typical project launch.

● Initial discussion of the scope of the project including both the technical

objective

and the business objective

● The definition of success on this project

● The assumptions and constraints as identified in the project charter

● The project’s organizational chart (if known at that time)

● The participants’ roles and responsibilities

For a small or short-term project, estimates on cost and duration may be established

in the kickoff meeting. In this case, there may be little need to establish a cost estimating

schedule.

But where the estimating cycle is expected to take several weeks, and where

inputs will be required from various organizations and/or disciplines, an essential tool is

an estimating schedule. In this case, there may be a need for a prekickoff meeting simply

to determine the estimates. The minimum key milestones in a cost estimating schedule are

(1) a “kickoff ” meeting; (2) a “review of ground rules” meeting; (3) “resources input and

review” meeting; and (4) summary meetings and presentations. Descriptions of these

meetings and their approximate places in the estimating cycle follow.2

2. R. D. Stewart, Cost Estimating (New York: Wiley, 1982), pp. 56–57.

CUSTOMER

PM & APMS

(& SMES &

LEADS)

PM & APMS
(& SMES &
LEADS)
PM & APMS
(& SMES &
LEADS)

KICKOFF #1

CUSTOMER’S

SOW

KICKOFF #2

DETAIL PLANNING

WBS

DICTIONARY

WBS

DEVELOPMENT

SCOPE

MANAGEMENT

PLAN

PRELIMINARY

PLANNING
PRELIMINARY
SCOPE

STATEMENT

SCOPE

BASELINE

(PRELIMINARY

SCOPE
STATEMENT

+ W BS

+ W BS DICTIONARY)

EXECUTION

Kickoff Meetings 42

3

The Prekickoff Meeting The very first formal milestone in an estimate schedule is the estimate

kickoff meeting. This is a meeting of all the individuals who are

expected to have an input to the cost estimate. It usually includes individuals who are pro-

ficient in technical disciplines involved in the work to be estimated; business-oriented indi-

viduals who are aware of the financial factors to be considered in making the estimate;

project-oriented individuals who are familiar with the project ground rules and constraints;

and, finally, the cost estimator or cost estimating team. The estimating team may not

include any of the team members responsible for execution of the project.

Sufficient time should be allowed in the kickoff meeting to describe all project ground

rules, constraints, and assumptions; to hand out technical specifications, drawings, sched-

ules, and work element descriptions and resource estimating forms; and to discuss these

items and answer any questions that might arise. It is also an appropriate time to clarify

estimating assignments among the various disciplines represented in the event that organi-

zational charters are not clear as to who should support which part of the estimate. This

kickoff meeting may be 6 weeks to 3 months prior to the estimate completion date to allow

sufficient time for the overall estimating process. If the estimate is being made in response

to a request for quotation or request for bid, copies of the request for quotation document

will be distributed and its salient points discussed.

The Review of Ground Rules
Meeting

Several days after the estimate kickoff meeting, when the participants

have had the opportunity to study the material, a review of ground rules

meeting should be conducted. In this meeting the estimate manager

answers questions regarding the conduct of the cost estimate, assumptions, ground rules, and

estimating assignments. If the members of the estimating team are experienced in develop-

ing resource estimates for their respective disciplines, very little discussion may be needed.

However, if this is the first estimating cycle for one or more of the estimating team members,

it may be necessary to provide these team members with additional information, guidance,

and instruction on estimating tools and methods. If the individuals who will actually perform

the work are doing the estimating (which is actually the best arrangement for getting a real-

istic estimate), more time and support may be needed than would experienced estimators.

The Resources Input and
Review Meeting

Several weeks after the kickoff and review of ground rules meetings,

each team member that has a resources (man-hour and/or materials)

input is asked to present his or her input before the entire estimating

team. Thus starts one of the most valuable parts of the estimating process: the interaction

of team members to reduce duplications, overlaps, and omissions in resource data.

The most valuable aspect of a team estimate is the synergistic effect of team interac-

tion. In any multidisciplinary activity, it is the synthesis of information and actions that pro-

duces wise decisions rather than the mere volume of data. In this review meeting the

estimator of each discipline area has the opportunity to justify and explain the rationale for

his estimates in view of his peers, an activity that tends to iron out inconsistencies, over-

statements, and incompatibilities in resources estimates. Occasionally, inconsistencies,

overlaps, duplications, and omissions will be so significant that a second input and review

meeting will be required to collect and properly synthesize all inputs for an estimate.

Kickoff Meetings 424

Summary Meetings and
Presen

tations

Once the resources inputs have been collected, adjusted, and “priced,”

the cost estimate is presented to the estimating team as a “dry run” for the

final presentation to the company’s management or to the requesting

organization. This dry run can produce visibility into further inconsistencies or errors that

have crept into the estimate during the process of consolidation and reconciliation. The final

review with the requesting organization or with the company’s management could also

bring about some changes in the estimate due to last minute changes in ground rules or bud-

get-imposed cost ceilings.

11.6 UNDERSTANDING PARTICIPANTS’ ROLES

Companies that have histories of successful plans also have employees who fully under-

stand their roles in the planning process. Good up-front planning may not eliminate the

need for changes, but may reduce the number of changes required. The responsibilities of

the major players are as follows:

● Project manager will define:

● Goals and objectives

● Major milestones

● Requirements

● Ground rules and assumptions

● Time, cost, and performance constraints

● Operating procedures

● Administrative policy

● Reporting requirements

● Line manager will define:

● Detailed task descriptions to implement objectives, requirements, and milestones

● Detailed schedules and manpower allocations to support budget

and schedule

● Identification of areas of risk, uncertainty, and conflict

● Senior management (project sponsor) will:

● Act as the negotiator for disagreements between project and line management

● Provide clarification of critical issues

● Provide communication link with customer’s senior management

Successful planning requires that project, line, and senior management are in agree-

ment with the plan.

11.7 PROJECT PLANNING

Successful project management, whether in response to an in-house project

or a customer request, must utilize effective planning techniques. The first

step is understanding the project objectives. These goals may be to develop

expertise in a given area, to become competitive, to modify an existing facil-

ity for later use, or simply to keep key personnel employed.

PMBOK
®

Guide, 4th Edition
Chapter 5 Project Scope

Management
5.2 Define Scope

Project Planning 425

The objectives are generally not independent; they are all interrelated, both implicitly

and explicitly. Many times it is not possible to satisfy all objectives. At this point, man-

agement must prioritize the objectives as to which are strategic and which are not. Typical

problems with developing objectives include:

● Project objectives/goals are not agreeable to all parties.

● Project objectives are too rigid to accommodate changing priorities.

● Insufficient time exists to define objectives well.

● Objectives are not adequately quantified.

● Objectives are not documented well enough.

● Efforts of client and project personnel are not coordinated.

● Personnel turnover is high.

Once the objectives are clearly defined, four questions must be

considered:

● What are the major elements of the work required to satisfy the objectives, and

how are these elements interrelated?

● Which functional divisions will assume responsibility for accomplishment of these

objectives and the major-element work requirements?

● Are the required corporate and organizational resources available?

● What are the information flow requirements for the project?

If the project is large and complex, then careful planning and analysis must be accom-

plished by both the direct- and indirect-labor-charging organizational units. The project orga-

nizational structure must be designed to fit the project; work plans and schedules must be

established so that maximum allocation of resources can be made; resource costing and

accounting systems must be developed; and a management information and reporting system

must be established.

Effective total program planning cannot be accomplished unless all of the necessary

information becomes available at project initiation. These information requirements are:

● The statement of work (SOW)

● The project specifications

● The milestone schedule

● The work breakdown structure (WBS)

The statement of work (SOW) is a narrative description of the work to be accom-

plished. It includes the objectives of the project, a brief description of the work, the fund-

ing constraint if one exists, and the specifications and schedule. The schedule is a “gross”

schedule and includes such things as the:

● Start date

● End date

● Major milestones

● Written reports (data items)

Project Planning 426

Written reports should always be identified so that if functional input is required, the

functional manager will assign an individual who has writing skills.

The last major item is the work breakdown structure. The WBS is the breaking down

of the statement of work into smaller elements for better visibility and control. Each of

these planning items is described in the following sections.

11.8 THE STATEMENT OF

WORK

The PMBOK® Guide addresses four elements related to scope:

● Scope: Scope is the summation of all deliverables required as part

of the project. This includes all products, services, and results.

● Project Scope: This is the work that must be completed to

achieve the final scope of the project, namely the products, ser-

vices, and end results. (Previously, in Section 2.7, we differentiated between proj-

ect scope and product scope.)

● Scope Statement: This is a document that provides the basis for making future

decisions such as scope changes. The intended use of the document is to make sure

that all stakeholders have a common knowledge of the project scope. Included in

this document are the objectives, description of the deliverables, end result or

product, and justification for the project. The scope statement addresses seven

questions: who, what, when, why, where, how, and how many. This document val-

idates the project scope against the statement of work provided by the customer.

● Statement of Work: This is a narrative description of the end results to be pro-

vided under the contract. For the remainder of this section, we will focus our atten-

tion on the statement of

work.

The statement of work (SOW) is a narrative description of the work required for the

project. The complexity of the SOW is determined by the desires of top management,

the customer, and/or the user groups. For projects internal to the company, the SOW is

prepared by the project office with input from the user groups because the project office

is usually composed of personnel with writing skills.

For projects external to the organization, as in competitive bidding, the contractor may

have to prepare the SOW for the customer because the customer may not have people

trained in SOW preparation. In this case, as before, the contractor would submit the SOW

to the customer for approval. It is also quite common for the project manager to rewrite a

customer’s SOW so that the contractor’s line managers can price out the effort.

In a competitive bidding environment, there are two SOWs—the SOW used in the pro-

posal and a contract statement of work (CSOW). There might also be a proposal WBS and

a contract work breakdown structure (CWBS). Special care must be taken by contract and

negotiation teams to discover all discrepancies between the SOW/WBS and CSOW/CWBS,

or additional costs may be incurred. A good (or winning) proposal is no guarantee that the

customer or contractor understands the SOW. For large projects, fact-finding is usually

required before final negotiations because it is essential that both the customer and the

PMBOK
®

Guide, 4th Edition
5.2.3 Scope Definition

5.2.3.1 Project

Scope Statement

12.1.3.2 Contract Statement of

Work

The Statement of Work 427

contractor understand and agree on the SOW, what work is required, what work is proposed,

the factual basis for the costs, and other related elements. In addition, it is imperative that

there be agreement between the final CSOW and CWBS.

SOW preparation is not as easy as it sounds. Consider the following:

● The SOW says that you are to conduct a minimum of fifteen tests to determine the

material properties of a new substance. You price out twenty tests just to “play it

safe.” At the end of the fifteenth test, the customer says that the results are incon-

clusive and that you must run another fifteen tests. The cost overrun is $40,000.

● The Navy gives you a contract in which the SOW states that the prototype must be

tested in “water.” You drop the prototype into a swimming pool to test it.

Unfortunately, the Navy’s definition of “water” is the Atlantic Ocean, and it

costs

you $1 million to transport all of your test engineers and test equipment to the

Atlantic Ocean.

● You receive a contract in which the SOW says that you must transport goods

across the country using “aerated” boxcars. You select boxcars that have open tops

so that air can flow in. During the trip, the train goes through an area of torrential

rains, and the goods are ruined.

These three examples show that misinterpretations of the SOW can result in losses of

hundreds of millions of dollars. Common causes of misinterpretation are:

● Mixing tasks, specifications, approvals, and special instructions

● Using imprecise language (“nearly,” “optimum,” “approximately,” etc.)

● No pattern, structure, or chronological order

● Wide variation in size of tasks

● Wide variation in how to describe details of the work

● Failing to get third-party review

Misinterpretations of the statement of work can and will occur no matter how careful

everyone has been. The result is creeping scope, or, as one telecommunications company

calls it, “creeping elegance.” The best way to control creeping scope is with a good defi-

nition of the requirements up front, if

possible.

Today, both private industry and government agencies are developing manuals on SOW

preparation. The following is adapted from a NASA publication on SOW preparation3:

● The project manager or his designees should review the documents that authorize

the project and define its objectives, and also review contracts and studies leading

to the present level of development. As a convenience, a bibliography of related

studies should be prepared together with samples of any similar SOWs, and com-

pliance specifications.

● A copy of the WBS should be obtained. At this point coordination between the

CWBS elements and the SOW should commence. Each task element of the prelim-

inary CWBS should be explained in the SOW, and related coding should be used.

3. Adapted from Statement of Work Handbook NHB5600.2, National Aeronautics and Space Administration,
February 1975.

The Statement of Work 428

● The project manager should establish a SOW preparation team consisting of per-

sonnel he deems appropriate from the program or project office who are experts in

the technical areas involved, and representatives from procurement, financial man-

agement, fabrication, test, logistics, configuration management, operations, safety,

reliability, and quality assurance, plus any other area that may be involved in the

contemplated procurement.

● Before the team actually starts preparation of the SOW, the project manager should

brief program management as to the structure of the preliminary CWBS and the

nature of the contemplated SOW. This briefing is used as a baseline from which to

proceed further.

● The project manager may assign identified tasks to team members and identify

compliance specifications, design criteria, and other requirements documentation

that must be included in the SOW and assign them to responsible personnel for

preparation. Assigned team members will identify and obtain copies of specifica-

tions and technical requirements documents, engineering drawings, and results of

preliminary and/or related studies that may apply to various elements of the pro-

posed procurement.

● The project manager should prepare a detailed checklist showing the mandatory

items and the selected optional items as they apply to the main body or the appen-

dixes of the SOW.

● The project manager should emphasize the use of preferred parts lists; standard

subsystem designs, both existing and under development; available hardware in

inventory; off-the-shelf equipment; component qualification data; design criteria

handbooks; and other technical information available to design engineers to pre-

vent deviations from the best design practices.

● Cost estimates (manning requirements, material costs, software requirements, etc.)

developed by the cost estimating specialists should be reviewed by SOW contrib-

utors. Such reviews will permit early trade-off consideration on the desirability of

requirements that are not directly related to essential technical objectives.

● The project manager should establish schedules for submission of coordinated

SOW fragments from each task team member. He must assure that these schedules

are compatible with the schedule for the request for proposal (RFP) issuance. The

statement of work should be prepared sufficiently early to permit full project

coordination and to ensure that all project requirements are included. It should be

completed in advance of RFP preparation.

SOW preparation manuals also contain guides for editors and writers4:

● Every SOW that exceeds two pages in length should have a table of contents con-

forming to the CWBS coding structure. There should rarely be items in the SOW

that are not shown on the CWBS; however, it is not absolutely necessary to restrict

items to those cited in the CWBS.

4. See note 3.

The Statement of Work 429

● Clear and precise task descriptions are essential. The SOW writer should realize

that his or her efforts will have to be read and interpreted by persons of varied back-

ground (such as lawyers, buyers, engineers, cost estimators, accountants, and spe-

cialists in production, transportation, security, audit, quality, finance, and contract

management). A good SOW states precisely the product or service desired. The

clarity of the SOW will affect administration of the contract, since it defines

the scope of work to be performed. Any work that falls outside that scope will

involve new procurement with probable increased costs.

● The most important thing to keep in mind when writing a SOW is the most likely

effect the written work will have upon the reader. Therefore, every effort must be

made to avoid ambiguity. All obligations of the government should be carefully

spelled out. If approval actions are to be provided by the government, set a time

limit. If government-furnished equipment (GFE) and/or services, etc., are to be

provided, state the nature, condition, and time of delivery, if feasible.

● Remember that any provision that takes control of the work away from the con-

tractor, even temporarily, may result in relieving the contractor of responsibility.

● In specifying requirements, use active rather than passive terminology. Say that the

contractor shall conduct a test rather than that a test should be conducted. In other

words, when a firm requirement is intended, use the mandatory term “shall” rather

than the permissive term “should.”

● Limit abbreviations to those in common usage. Provide a list of all pertinent abbre-

viations and acronyms at the beginning of the SOW. When using a term for the

first time, spell it out and show the abbreviation or acronym in parentheses fol-

lowing the word or words.

● When it is important to define a division of responsibilities between the contrac-

tor, other agencies, etc., a separate section of the SOW (in an appropriate location)

should be included and delineate such

responsibilities.

● Include procedures. When immediate decisions cannot be made, it may be possi-

ble to include a procedure for making them (e.g., “as approved by the contracting

officer,” or “the contractor shall submit a report each time a failure occurs”).

● Do not overspecify. Depending upon the nature of the work and the type of con-

tract, the ideal situation may be to specify results required or end-items to be deliv-

ered and let the contractor propose his best method.

● Describe requirements in sufficient detail to assure clarity, not only for legal rea-

sons, but for practical application. It is easy to overlook many details. It is equally

easy to be repetitious. Beware of doing either. For every piece of deliverable hard-

ware, for every report, for every immediate action, do not specify that something

be done “as necessary.” Rather, specify whether the judgment is to be made by the

contractor or by the government. Be aware that these types of contingent actions

may have an impact on price as well as schedule. Where expensive services, such

as technical liaison, are to be furnished, do not say “as required.” Provide a ceil-

ing on the extent of such services, or work out a procedure (e.g., a level of effort,

pool of man-hours) that will ensure adequate control.

● Avoid incorporating extraneous material and requirements. They may add unnec-

essary cost. Data requirements are common examples of problems in this area.

Project Specifications 431

Screen out unnecessary data requirements, and specify only what is essential and

when. It is recommended that data requirements be specified separately in a data

requirements appendix or equivalent.

● Do not repeat detailed requirements or specifications that are already spelled out

in applicable documents. Instead, incorporate them by reference. If amplification,

modification, or exceptions are required, make specific reference to the applicable

portions and describe the change.

Some preparation documents also contain checklists for SOW preparation.5 A checklist is

furnished below to provide considerations that SOW writers should keep in mind in

preparing statements of work:

● Is the SOW (when used in conjunction with the preliminary CWBS) specific

enough to permit a contractor to make a tabulation and summary of manpower and

resources needed to accomplish each SOW

task element?

● Are specific duties of the contractor stated so he will know what is required, and

can the contracting officer’s representative, who signs the acceptance report, tell

whether the contractor has complied?

● Are all parts of the SOW so written that there is no question as to what the con-

tractor is obligated to do, and when?

● When it is necessary to reference other documents, is the proper reference docu-

ment described? Is it properly cited? Is all of it really pertinent to the task, or

should only portions be referenced? Is it cross-referenced to the applicable SOW

task element?

● Are any specifications or exhibits applicable in whole or in part? If so, are they

properly cited and referenced to the appropriate SOW element?

● Are directions clearly distinguishable from general information?

● Is there a time-phased data requirement for each deliverable item? If elapsed time

is used, does it specify calendar or work days?

● Are proper quantities shown?

● Have headings been checked for format and grammar? Are subheadings compara-

ble? Is the text compatible with the title? Is a multidecimal or alphanumeric num-

bering system used in the SOW? Can it be cross-referenced with the CWBS?

● Have appropriate portions of procurement regulations been followed?

● Has extraneous material been eliminated?

● Can SOW task/contract line items and configuration item breakouts at lower lev-

els be identified and defined in sufficient detail so they can be summarized to dis-

crete third-level CWBS elements?

● Have all requirements for data been specified separately in a data requirements

appendix or its equivalent? Have all extraneous data requirements been eliminated?

● Are security requirements adequately covered if required?

● Has its availability to contractors been specified?

5. See note 3.

Project Specifications 431

PMBOK
®

Guide, 4th Edition
5.2 Define Scope

12.1.3.2 Contract Statement

of Work

Finally, there should be a management review of the SOW preparation interpretation6:

During development of the Statement of Work, the project manager should ensure ade-

quacy of content by holding frequent reviews with project and functional specialists to

determine that technical and data requirements specified do conform to the guidelines

herein and adequately support the common system objective. The CWBS/SOW matrix

should be used to analyze the SOW for completeness. After all comments and inputs have

been incorporated, a final team review should be held to produce a draft SOW for review

by functional and project managers. Specific problems should be resolved and changes

made as appropriate. A final draft should then be prepared and reviewed with the program

manager, contracting officer, or with higher management if the procurement is a major

acquisition. The final review should include a briefing on the total RFP package. If other

program offices or other Government agencies will be involved in the procurement, obtain

their concurrence also.

11.9 PROJECT

SPECIFICATIONS

A specification list as shown in Table 11–1 is separately identified or

called out as part of the statement of work. Specifications are used for

man-hour, equipment, and material estimates. Small changes in a specifi-

cation can cause large cost overruns.

Another reason for identifying the specifications is to make sure that

there are no surprises for the customer downstream. The specifications should be the most

current revision. It is not uncommon for a customer to hire outside agencies to evaluate the

technical proposal and to make sure that the proper specifications are being used.

Specifications are, in fact, standards for pricing out a proposal. If specifications do not

exist or are not necessary, then work standards should be included in the proposal. The

work standards can also appear in the cost volume of the proposal. Labor justification

backup sheets may or may not be included in the proposal, depending on RFP/RFQ

(request for quotation) requirements.

Several years ago, a government agency queried contractors as to why some govern-

ment programs were costing so much money. The main culprit turned out to be the speci-

fications. Typical specifications contain twice as many pages as necessary, do not stress

quality enough, are loaded with unnecessary designs and schematics, are difficult to read

and update, and are obsolete before they are published. Streamlining existing specifica-

tions is a costly and time-consuming effort. The better alternative is to educate those peo-

ple involved in specification preparation so that future specifications will be reasonably

correct.

6. Statement of Work Handbook NHB5600.2, National Aeronautics and Space Administration, February 1975.

Milestone Schedules 43

2

TABLE 11–1. SPECIFICATION FOR STATEMENT OF WORK

Description Specification No.

Civil 100 (Index)

• Concrete 101
• Field equipment 102
• Piling 121
• Roofing and siding 122
• Soil testing 123
• Structural design 124

Electrical 200 (Index)

• Electrical testing 201
• Heat tracing 201
• Motors 209
• Power systems 225
• Switchgear 226
• Synchronous generators 227

HVAC 300 (Index)

• Hazardous environment 301
• Insulation 302
• Refrigeration piping 318
• Sheetmetal ductwork 319

Installation 400 (Index)

• Conveyors and chutes 401
• Fired heaters and boilers 402
• Heat exchangers 403
• Reactors 414
• Towers 415
• Vessels 416

Instruments 500 (Index)

• Alarm systems 501
• Control valves 502
• Flow instruments 503
• Level gages 536
• Pressure instruments 537
• Temperature instruments 538

Mechanical equipment 600 (Index)

• Centrifugal pumps 601
• Compressors 602
• High-speed gears 603
• Material handling equipment 640
• Mechanical agitators 641
• Steam turbines 642

Piping 700 (Index)

• Expansion joints 701
• Field pressure testing 702
• Installation of piping 703
• Pipe fabrication specs 749
• Pipe supports 750
• Steam tracing 751

Project administration 800 (Index)

• Design drawings 801
• Drafting standards 802
• General requirements 803
• Project coordination 841
• Reporting procedure 842
• Vendor data 843

(continues)

Milestone Schedules 43

3

TABLE 11–1. SPECIFICATION FOR STATEMENT OF WORK

(Continued)

Description Specification No.

Vessels 900 (Index)

• Fireproofing 901
• Painting 902
• Reinforced tanks 948
• Shell and tube heat exchangers 949
• Steam boilers 950
• Vessel linings 951

11.10 MILESTONE SCHEDULES

Project milestone schedules contain such information as:

● Project start date

● Project end date

● Other major milestones

● Data items (deliverables or reports)

Project start and end dates, if known, must be included. Other major milestones, such

as review meetings, prototype available, procurement, testing, and so on, should also be

identified. The last topic, data items, is often overlooked. There are two good reasons for

preparing a separate schedule for data items. First, the separate schedule will indicate to

line managers that personnel with writing skills may have to be assigned. Second, data

items require direct-labor man-hours for writing, typing, editing, retyping, proofing,

graphic arts, and reproduction. Many companies identify on the data item schedules the

approximate number of pages per data item, and each data item is priced out at a cost per

page, say $500/page. Pricing out data items separately often induces customers to require

fewer reports.

The steps required to prepare a report, after the initial discovery work or collection of

information, include:

● Organizing the report

● Writing

● Typing

● Editing

● Retyping

● Proofing

● Graphic arts

● Submittal for approvals

● Reproduction and distribution

PMBOK
®

Guide, 4th Edition
Chapter 6 Time Management

Milestone Schedules 434

Typically, 6–8 hours of work are required per page. At a burdened hourly rate of $80/hour,

it is easy for the cost of documentation to become exorbitant.

11.11 WORK BREAKDOWN

STRUCTURE

The successful accomplishment of both contract and corporate objectives

requires a plan that defines all effort to be expended, assigns responsibility

to a specially identified organizational element, and establishes schedules

and budgets for the accomplishment of the work. The preparation of this plan is the respon-

sibility of the program manager, who is assisted by the program team assigned in accordance

with program management system directives. The detailed planning is also established in

accordance with company budgeting policy before contractural efforts are initiated.

In planning a project, the project manager must structure the work into small

elements

that are:

● Manageable, in that specific authority and responsibility can be assigned

● Independent, or with minimum interfacing with and dependence on other ongoing

elements

● Integratable so that the total package can be seen

● Measurable in terms of

progress

The first major step in the planning process after project requirements definition is the

development of the work breakdown structure (WBS). A WBS is a product-oriented family

tree subdivision of the hardware, services, and data required to produce the end product. The

WBS is structured in accordance with the way the work will be performed and reflects the way

in which project costs and data will be summarized and eventually reported. Preparation of the

WBS also considers other areas that require structured data, such as scheduling, configuration

management, contract funding, and technical performance parameters. The WBS is the single

most important element because it provides a common framework from which:

● The total program can be described as a summation of subdivided elements.

● Planning can be performed.

● Costs and budgets can be established.

● Time, cost, and performance can be tracked.

● Objectives can be linked to company resources in a logical manner.

● Schedules and status-reporting procedures can be established.

● Network construction and control planning can be initiated.

● The responsibility assignments for each element can be established.

The work breakdown structure acts as a vehicle for breaking the work down into

smaller elements, thus providing a greater probability that every major and minor activity

PMBOK
®

Guide, 4th Edition
5.3 Create WBS

Work Breakdown Structure 435

will be accounted for. Although a variety of work breakdown structures exist, the most

common is the six-level indented structure shown below:

Level

Description

Managerial

levels

Technical

levels

1 Total program

2 Project

3 Task

4 Subtask

5 Work package

6 Level of effort

Level 1 is the total program and is composed of a set of projects. The summation of

the activities and costs associated with each project must equal the total program. Each

project, however, can be broken down into tasks, where the summation of all tasks equals

the summation of all projects, which, in turn, comprises the total program. The reason for

this subdivision of effort is simply ease of control. Program management therefore

becomes synonymous with the integration of activities, and the project manager acts as the

integrator, using the work breakdown structure as the common framework.

Careful consideration must be given to the design and development of the WBS. From

Figure 11–3, the work breakdown structure can be used to provide the basis for:

● The responsibility matrix

● Network scheduling

● Costing

● Risk analysis

● Organizational structure

● Coordination of objectives

● Control (including contract administration)

The upper three levels of the WBS are normally specified by the customer (if part of an

RFP/RFQ) as the summary levels for reporting purposes. The lower levels are generated by

the contractor for in-house control. Each level serves a vital purpose: Level 1 is generally

used for the authorization and release of all work, budgets are prepared at level 2, and sched-

ules are prepared at level 3. Certain characteristics can now be generalized for these levels:

● The top three levels of the WBS reflect integrated efforts and should not be related

to one specific department. Effort required by departments or sections should be

defined in subtasks and work packages.

● The summation of all elements in one level must be the sum of all work in the next

lower level.

● Each element of work should be assigned to one and only one level of effort. For

example, the construction of the foundation of a house should be included in one

project (or task), not extended over two or three. (At level 5, the work packages

should be identifiable and homogeneous.)

{

{

Work Breakdown Structure 436

FIGURE 11–3. Work breakdown structure for objective control and evaluation. Source: Paul Mali,
Managing by Objectives (New York: Wiley, 1972), p. 163. Copyright © 1972 by John Wiley & Sons.
Reprinted by permission of the publisher.

● The level at which the project is managed is generally called the work package level.

Actually, the work package can exist at any level below level one.

● The WBS must be accompanied by a description of the scope of effort required,

or else only those individuals who issue the WBS will have a complete under-

standing of what work has to be accomplished. It is common practice to reproduce

the customer’s statement of work as the description for the WBS.

● It is often the best policy for the project manager, regardless of his technical exper-

tise, to allow all of the line managers to assess the risks in the SOW. After all, the

line managers are usually the recognized experts in the organization.

Project managers normally manage at the top three levels of the WBS and prefer to

provide status reports to management at these levels also. Some companies are trying

to standardize reporting to management by requiring the top three levels of the WBS to be

the same for every project, the only differences being in levels 4–6. For companies with a

great deal of similarity among projects, this approach has merit. For most companies, how-

ever, the differences between projects make it almost impossible to standardize the top lev-

els of the WBS.

PMBOK
®

Guide, 4th Edition
Figure 5–6 Sample WBS

Validates time

and schedule

Validates total

risk and impact of
decision-making

PERT network ee

Validates management
coordination

Validates

organization charts

Work

Major

packages
objective

Objective

Subobjective al

Feeder

objective

Feeder objectives

Level 1

Matrix
Level 2

of

work Level 3
packages

Level 4

Cost flow

objective network

Validates total
costs

Corporate

Divisional

Department

Sectional

methods and

structure
objective

networks

Decision tr

Work Breakdown Structure 437

The work package is the critical level for managing a work breakdown structure, as

shown in Figure 11–4. However, it is possible that the actual management of the work

packages is supervised and performed by the line managers with status reporting provided

to the project manager at higher levels of the WBS.

Work packages are natural subdivisions of cost accounts and constitute the basic

building blocks used by the contractor in planning, controlling, and measuring contract

performance. A work package is simply a low-level task or job assignment. It describes the

work to be accomplished by a specific performing organization or a group of cost centers

and serves as a vehicle for monitoring and reporting progress of work. Documents that

authorize and assign work to a performing organization are designated by various names

throughout industry. “Work package” is the generic term used in the criteria to identify dis-

crete tasks that have definable end results. Ideal work packages are 80 hours and 2–4

weeks. However, this may not be possible on large projects.

It is not necessary that work package documentation contain complete, stand-alone

descriptions. Supplemental documentation may augment the work package descriptions.

However, the work package descriptions must permit cost account managers and work

package supervisors to understand and clearly distinguish one work package effort from

another. In the review of work package documentation, it may be necessary to obtain

explanations from personnel routinely involved in the work, rather than requiring the work

package descriptions to be completely self-explanatory.

Short-term work packages may help evaluate accomplishments. Work packages

should be natural subdivisions of effort planned according to the way the work will be

done. However, when work packages are relatively short, little or no assessment of work-

in-process is required and the evaluation of status is possible mainly on the basis of work

package completions. The longer the work packages, the more difficult and subjective the

work-in-process assessment becomes unless the packages are subdivided by objective

indicators such as discrete milestones with preassigned budget values or completion

percentages.

In setting up the work breakdown structure, tasks should:

● Have clearly defined start and end dates

● Be usable as a communications tool in which results can be compared with expec-

tations

● Be estimated on a “total” time duration, not when the task must start or end

● Be structured so that a minimum of project office control and documentation (i.e.,

forms) is necessary

For large projects, planning will be time phased at the work package level of the WBS.

The work package has the following characteristics:

● Represents units of work at the level where the work is performed

● Clearly distinguishes one work package from all others assigned to a single func-

tional group

● Contains clearly defined start and end dates that are representative of physical

accomplishment (This is accomplished after scheduling has been completed.)

Work Breakdown Structure 438

COST
ACCOUNT

COST
ACCOUNT
COST
ACCOUNT
COST
ACCOUNT
COST
ACCOUNT
COST
ACCOUNT

MODULE
D

MODULE
C

MODULE
B

MODULE
A

WORK PACKAGES

LEVEL 1

LEVEL 2

LEVEL 3

LEVEL 4

FUNCTIONAL ORGANIZATION

FIGURE 11–4. The cost account intersection.

PMBOK
®

Guide, 4th Edition
Figure 5–6 Work Packages

Organizational Procedures Links

VERIFICATION
VALIDATION

MECHANICAL
DESIGN

ELECTRICAL

DESIGN

HARDW ARE TRAINING

COMPONENT
TESTING

MANUFACTURING

SUBSYSTEM

ENGINEERING

SUBSYSTEM

PROGRAM

4
3
8

C
O

M
P

A
N

Y

M
F

G

E
N

G
IN

E
E

R
IN

G

T
E
S
T

D
E

S
IG

N

Work Breakdown Structure 439

● Specifies a budget in terms of dollars, man-hours, or other measurable units

● Limits the work to be performed to relatively short periods of time to minimize the

work-in-process effort

Table 11–2 shows a simple work breakdown structure with the associated numbering

system following the work breakdown. The first number represents the total program (in

this case, it is represented by 01), the second number represents the project, and the third

number identifies the task. Therefore, number 01-03-00 represents project 3 of program

01, whereas 01-03-02 represents task 2 of project 3. This type of numbering system is not

standard; each company may have its own system, depending on how costs are to be

controlled.

The preparation of the work breakdown structure is not easy. The WBS is a commu-

nications tool, providing detailed information to different levels of management. If it does

not contain enough levels, then the integration of activities may prove difficult. If too many

levels exist, then unproductive time will be made to have the same number of levels for all

projects, tasks, and so on. Each major work element should be considered by itself.

Remember, the WBS establishes the number of required networks for cost control.

For many programs, the work breakdown structure is established by the customer. If

the contractor is required to develop a WBS, then certain guidelines must be considered

including:

● The complexity and technical requirements of the program (i.e., the statement of

work)

● The program cost

● The time span of the program

● The contractor’s resource requirements

● The contractor’s and customer’s internal structure for management control and

reporting

● The number of subcontracts

TABLE 11–2. WORK BREAKDOWN STRUCTURE FOR NEW

PLANT CONSTRUCTION AND START-UP

Program: New Plant Construction and Start-up 01-00-00
Project 1: Analytical Study 01-01-00

Task 1: Marketing/Production Study 01-01-01
Task 2: Cost Effectiveness Analysis 01-01-02

Project 2: Design and Layout 01-02-00
Task 1: Product Processing Sketches 01-02-01

Task 2: Product Processing Blueprints 01-02-02
Project 3: Installation 01-03-00

Task 1: Fabrication 01-03-01
Task 2: Setup 01-03-02

Task 3: Testing and Run 01-03-03
Project 4: Program Support 01-04-00

Task 1: Management 01-04-01

Task 2: Purchasing Raw Materials 01-04-02

Work Breakdown Structure 440

Applying these guidelines serves only to identify the complexity of the program.

These data must then be subdivided and released, together with detailed information, to the

different levels of the organization. The WBS should follow specified criteria because,

although preparation of the WBS is performed by the program office, the actual work is

performed by the doers, not the planners. Both the doers and the planners must be in agree-

ment as to what is expected. A sample listing of criteria for developing a work breakdown

structure is shown below:

● The WBS and work description should be easy to understand.

● All schedules should follow the WBS.

● No attempt should be made to subdivide work arbitrarily to the lowest possible

level. The lowest level of work should not end up having a ridiculous cost in com-

parison to other efforts.

● Since scope of effort can change during a program, every effort should be made to

maintain flexibility in the WBS.

● The WBS can act as a list of discrete and tangible milestones so that everyone will

know when the milestones were achieved.

● The level of the WBS can reflect the “trust” you have in certain line groups.

● The WBS can be used to segregate recurring from nonrecurring costs.

● Most WBS elements (at the lowest control level) range from 0.5 to 2.5 percent of

the total project budget.

11.12 WBS DECOMPOSITION PROBLEMS

There is a common misconception that WBS decomposition is an easy task to perform. In

the development of the WBS, the top three levels or management levels are usually roll-

up levels. Preparing templates at these levels is becoming common practice. However, at

levels 4–6 of the WBS, templates may not be appropriate. There are reasons for this.

● Breaking the work down to extremely small and detailed work packages may require

the creation of hundreds or even thousands of cost accounts and charge numbers. This

could increase the management, control, and reporting costs of these small packages

to a point where the costs exceed the benefits. Although a typical work package may

be 200–300 hours and approximately two weeks in duration, consider the impact on

a large project, which may have more than one million direct labor hours.

● Breaking the work down to small work packages can provide accurate cost control

if, and only if, the line managers can determine the costs at this level of detail. Line

managers must be given the right to tell project managers that costs cannot be

determined at the requested level of detail.

● The work breakdown structure is the basis for scheduling techniques such as the

Arrow Diagramming Method and the Precedence Diagramming Method. At low

levels of the WBS, the interdependencies between activities can become so com-

plex that meaningful networks cannot be constructed.

WBS Decomposition Problems 441

One solution to the above problems is to create “hammock” activities, which encom-

pass several activities where exact cost identification cannot or may not be accurately

determined. Some projects identify a “hammock” activity called management support (or

project office), which includes overall project management, data items, management

reserve, and possibly procurement. The advantage of this type of hammock activity is that

the charge numbers are under the direct control of the project manager.

There is a common misconception that the typical dimensions of a work package are

approximately 80 hours and less than two weeks to a month. Although this may be true on

small projects, this would necessitate millions of work packages on large jobs and this may

be impractical, even if line managers could control work packages of this size.

From a cost control point of view, cost analysis down to the fifth level is advanta-

geous. However, it should be noted that the cost required to prepare cost analysis data to

each lower level may increase exponentially, especially if the customer requires data to be

presented in a specified format that is not part of the company’s standard operating proce-

dures. The level-5 work packages are normally for in-house control only. Some companies

bill customers separately for each level of cost reporting below level 3.

The WBS can be subdivided into subobjectives with finer divisions of effort as we go

lower into the WBS. By defining subobjectives, we add greater understanding and, it is

hoped, clarity of action for those individuals who will be required to complete the objec-

tives. Whenever work is structured, understood, easily identifiable, and within the capa-

bilities of the individuals, there will almost always exist a high degree of confidence that

the objective can be reached.

Work breakdown structures can be used to structure work for reaching such objectives

as lowering cost, reducing absenteeism, improving morale, and lowering scrap factors. The

lowest subdivision now becomes an end-item or subobjective, not necessarily a work pack-

age as described here. However, since we are describing project management, for the

remainder of the text we will consider the lowest level as the work package.

Once the WBS is established and the program is “kicked off,” it becomes a very

costly procedure to either add or delete activities, or change levels of reporting because of

cost control. Many companies do not give careful forethought to the importance of a prop-

erly developed WBS, and ultimately they risk cost control problems downstream. One

important use of the WBS is that it serves as a cost control standard for any future activi-

ties that may follow on or may just be similar. One common mistake made by management

is the combining of direct support activities with administrative activities. For example, the

department manager for manufacturing engineering may be required to provide adminis-

trative support (possibly by attending team meetings) throughout the duration of the pro-

gram. If the administrative support is spread out over each of the projects, a false picture

is obtained as to the actual hours needed to accomplish each project in the program. If one

of the projects should be canceled, then the support man-hours for the total program would

be reduced when, in fact, the administrative and support functions may be constant, regard-

less of the number of projects and tasks.

Quite often work breakdown structures accompanying customer RFPs contain much

more scope of effort, as specified by the statement of work, than the existing funding will

support. This is done intentionally by the customer in hopes that a contractor may be will-

ing to “buy in.” If the contractor’s price exceeds the customer’s funding limitations, then

WBS Decomposition Problems 442

the scope of effort must be reduced by eliminating activities from the WBS. By develop-

ing a separate project for administrative and indirect support activities, the customer can

easily modify his costs by eliminating the direct support activities of the canceled effort.

Before we go on, there should be a brief discussion of the usefulness and applicabil-

ity of the WBS system. Many companies and industries have been successful in managing

programs without the use of work breakdown structures, especially on repetitive-type pro-

grams. As was the case with the SOW, there are also preparation guides for the WBS7:

● Develop the WBS structure by subdividing the total effort into discrete and logi-

cal subelements. Usually a program subdivides into projects, major systems, major

subsystems, and various lower levels until a manageable-size element level is

reached. Wide variations may occur, depending upon the type of effort (e.g., major

systems development, support services, etc.). Include more than one cost center

and more than one contractor if this reflects the actual situation.

● Check the proposed WBS and the contemplated efforts for completeness, compat-

ibility, and continuity.

● Determine that the WBS satisfies both functional (engineering/manufacturing/

test) and program/project (hardware, services, etc.) requirements, including recur-

ring and nonrecurring costs.

● Check to determine if the WBS provides for logical subdivision of all project

work.

● Establish assignment of responsibilities for all identified effort to specific

organizations.

● Check the proposed WBS against the reporting requirements of the organizations

involved.

There are also checklists that can be used in the preparation of

the WBS8:

● Develop a preliminary WBS to not lower than the top three levels for solicitation

purposes (or lower if deemed necessary for some special reason).

● Assure that the contractor is required to extend the preliminary WBS in response

to the solicitation, to identify and structure all contractor work to be compatible

with his organization

and management system.

● Following negotiations, the CWBS included in the contract should not normally

extend lower than the third level.

● Assure that the negotiated CWBS structure is compatible with reporting

requirements.

7. Source: Handbook for Preparation of Work Breakdown Structures, NHB5610.1, National Aeronautics and
Space Administration, February 1975.

8. See note 7.

PMBOK
®

Guide, 4th Edition
5.3.3.1 WBS

WBS Decomposition Problems 443

● Assure that the negotiated CWBS is compatible with the contractor’s organization

and management system.

● Review the CWBS elements to ensure correlation with:

● The specification tree

● Contract line items

● End-items of the contract

● Data items required

● Work statement tasks

● Configuration management requirements

● Define CWBS elements down to the level where such definitions are meaningful

and necessary for management purposes (WBS dictionary).

● Specify reporting requirements for selected CWBS elements if variations from

standard reporting requirements are desired.

● Assure that the CWBS covers measurable effort, level of effort, apportioned effort,

and subcontracts, if applicable.

● Assure that the total costs at a particular level will equal the sum of the costs of

the constituent elements at the next lower level.

On simple projects, the WBS can be constructed as a “tree diagram” (see Figure 11–5)

or according to the logic flow. In Figure 11–5, the tree diagram can follow the work or even

the organizational structure of the company (i.e., division, department, section, unit). The

second method is to create a logic flow (see Figure 12–21) and cluster certain elements to

represent tasks and projects. In the tree method, lower-level functional units may be

LEVELS

PROGRAM

PROJECT

TASK

FIGURE 11–5. WBS tree diagram.

ELECTRICAL

MECHANICAL

CHEMICAL

INTERIOR

STRUCTURE

GINE

EN

BRAKES

NEW CAR
DESIGN

WBS Decomposition Problems 444

assigned to one, and only one, work element, whereas in the logic flow method the lower-

level functional units may serve several WBS elements.

A tendency exists to develop guidelines, policies, and procedures for project manage-

ment, but not for the development of the WBS. Some companies have been marginally

successful in developing a “generic” methodology for levels 1, 2, and 3 of the WBS to use

on all projects. The differences appear in levels 4, 5, and 6.

The table below shows the three most common methods for structuring the WBS:

Method

Level Flow Life Cycle Organization

Program Program Program Program

Project System Life cycle Division
Task Subsystem System Department

Subtask People Subsystem Section
Work package People People People

Level of effort People People People

The flow method breaks the work down into systems and major subsystems. This

method is well suited for projects less than two years in length. For longer projects, we use

the life-cycle method, which is similar to the flow method. The organization method is used

for projects that may be repetitive or require very little integration between functional units.

11.13 ROLE OF THE EXECUTIVE IN PROJECT SELECTION

A prime responsibility of senior management (and possibly project spon-

sors) is the selection of projects. Most organizations have an established

selection criteria, which can be subjective, objective, quantitative, quali-

tative, or simply a seat-of-the-pants guess. In any event, there should be a

valid reason for selecting the project.

From a financial perspective, project selection is basically a two-part process. First,

the organization will conduct a feasibility study to determine whether the project can be

done. The second part is to perform a benefit-to-cost analysis to see whether the company

should do it.

The purpose of the feasibility study is to validate that the project meets feasibility of

cost, technological, safety, marketability, and ease of execution requirements. The com-

pany may use outside consultants or subject matter experts (SMEs) to assist in both feasi-

bility studies and benefit-to-cost analyses. A project manager may not be assigned until

after the feasibility study is completed.

As part of the feasibility process during project selection, senior management often

solicits input from SMEs and lower-level managers through rating models. The rating

models normally identify the business and/or technical criteria against which the ratings

PMBOK
®

Guide, 4th Edition
Chapter 4

Integration

4.1.2 Develop

Project Charter

Tools and Techniques

Role of the Executive in Project Selection 445

SCALE

CRITERIA –2 –1 0 +1 +2

T
O

P
M

A
N

A
G

E
M

E
N

T

CAPITAL REQUIREMENTS

COMPETITIVE REACTION

RETURN ON INVESTMENT

PAYOUT TIME

W ALL STREET IMPACTS

E
N
G
IN
E
E
R
IN
G

REQUIRED EQUIPMENT

AVAILABILITY OF PERSONNEL

KNOW -HOW

DESIGN DIFFICULTY

EQUIPMENT

AVAILABILITY

PIPING LAYOUTS

R
E

S
E

A
R

C
H

PATENTABILITY

LIKELIHOOD OF SUCCESS

KNOW -HOW

PROJECT COSTS

AVAILABILITY OF PERSONNEL

AVAILABILITY OF LABORATORY

M
A

R
K

E
T

IN
G

LENGTH OF PRODUCT LIFE

PRODUCT ADVANTAGE

SUITABILITY TO SALESFORCE

SIZE OF MARKET

NUMBER OF COMPETITORS

P
R

O
D

U
C

T
IO

N

PROCESSABILITY

KNOW -HOW

EQUIPMENT AVAILABILITY

NUMBER OF XS 5 3 2 7 7

KEY: +2 = EXCELLENT
+1 = GOOD

0 = FAIR
—1 = BAD

—2 = UNACCEPTABLE

= NOT APPLICABLE

= SCORE FOR

PROJECT A

FIGURE 11–6. Illustration of a scaling model for one project, Project A. Source: William E. Souder,
Project Selection and Economic Appraisal, p. 66.

Role of the Executive in Project Selection 446

will be made. Figure 11–6 shows a scaling model for a single project. Figure 11–7 shows

a checklist rating system to evaluate three projects at once. Figure 11–8 shows a scoring

model for multiple projects using weighted averages.

If the project is deemed feasible and a good fit with the strategic plan, then the

project is prioritized for development along with other projects. Once feasibility is deter-

mined, a benefit-to-cost analysis is performed to validate that the project will, if executed

correctly, provide the required financial and nonfinancial benefits.

Benefit-to-cost analyses require significantly more information to be scru-

tinized than is usually available during a feasibility study. This can be an

expensive proposition.

Estimating benefits and costs in a timely manner is very difficult.

Benefits are often defined as:

● Tangible benefits for which dollars may be reasonably quantified and measured.

● Intangible benefits that may be quantified in units other than dollars or may be

identified and described subjectively.

CRITERIA

PROJECTS

PROJECT A

PROJECT B

PROJECT C

TOTAL SCORE

7

6

3

FIGURE 11–7. Illustration of a checklist for three projects. Source: William Souder, Project
Selection and Economic Appraisal, p. 68.

PMBOK
®

Guide, 4th Edition
5.2.2 Scope Definition

5.2.2.2 Product Analysis

P
R

O
F

I

T
A

B
IL

IT
Y

M
A
R
K
E
T

A
B

IL
IT

Y

S
U

C
C

E
S

S
L

I

K
E

L
IH

O
O

D

3 2 1 3 2 1 3 2 1

Role of the Executive in Project Selection 447

CRITERIA

P

R
O

F
IT

A
B
IL
IT
Y

P

A
T

E
N
T
A
B
IL
IT
Y

M

A
R
K
E
T
A
B
IL
IT
Y

P
R
O

D
U

C
E

A
B
IL
IT
Y

CRITERION W EIGHTS

4

3

2

1

PROJECTS

PROJECT D

PROJECT E

PROJECT F

CRITERION SCORES*

TOTAL

WEIGHTED
SCORE

69

75

63

TOTAL WEIGHTED SCORE = G (CRITERION SCORE × CRITERION W EIGHT)

* SCALE: 10 = EXCELLENT; 1 = UNACCEPTABLE

FIGURE 11–8. Illustration of a scoring model. Source: William Souder, Project Selection and
Economic Appraisal, p. 69.

Costs are significantly more difficult to quantify. The minimum costs that must be

determined are those that specifically are used for comparison to the benefits. These

include:

● The current operating costs or the cost of operating in today’s circumstances.

● Future period costs that are expected and can be planned for.

● Intangible costs that may be difficult to quantify. These costs are often omitted if

quantification would contribute little to the decision-making process.

10 6 4 3

5

10

10

5

3

7

10

10

Role of the Executive in Project Selection 448

TABLE 11–3. FEASIBILITY STUDY AND BENEFIT-COST ANALYSIS

Feasibility Study Benefit-Cost Analysis

Basic Question Can We Do It? Should We Do It?

Life-Cycle Phase Preconceptual Conceptual
PM Selected Usually not yet Usually identified but partial involvement
Analysis Qualitative Quantitative

Critical Factors for Go/No-Go • Technical
•

Cost

•

Quality

• Safety
• Ease of performance
• Economical

• Net present value
• Discounted cash flow
• Internal rate of return
• Return on investment
• Probability of success
• Reality of assumptions

• Legal and constraints
Executive Decision Criteria Strategic fit Benefits exceed costs by required margin

There must be careful documentation of all known constraints and assumptions that

were made in developing the costs and the benefits. Unrealistic or unrecognized assumptions

are often the cause of unrealistic benefits. The go or no-go decision to continue with a pro-

ject could very well rest upon the validity of the assumptions.

Table 11–3 shows the major differences between feasibility studies and benefit-to-cost

analyses.

Today, the project manager may end up participating in the project selection process.

In Chapter 1, we discussed the new breed of project manager, namely a person that has

excellent business skills as well as project management skills. These business skills now

allow us to bring the project manager on board the project at the beginning of the initiation

phase rather than at the end of the initiation phase because the project manager can now

make a valuable contribution to the project selection process. The project manager can be

of assistance during project selection by providing business case knowledge including:

● Opportunity options (sales volume, market share, and follow-on business)

● Resource requirements (team knowledge requirements and skill set)

● Refined project costs

● Refined savings

● Benefits (financial, strategic, payback)

● Project metrics (key performance indicators and critical success factors)

● Benefits realization (consistency with the corporate business plan)

● Risks

● Exit strategies

● Organizational readiness and strengths

● Schedule/milestones

● Overall complexity

● Technology complexity and constraints, if any9

9. For additional factors that can influence project selection decision making, see J. R. Meredith and S. J. Mantel, Jr.,
Project Management, 3rd ed., (New York: Wiley, 1995), pp. 44–46.

The Planning Cycle 449

11.14 ROLE OF THE EXECUTIVE IN PLANNING

Executives are responsible for selecting the project manager, and the person chosen should

have planning expertise. Not all technical specialists are good planners. Likewise, some

people that are excellent in execution have minimal planning skills. Executives must make

sure that whomever is assigned as the project manager has both planning and execution

skills. In addition, executives must take an active role during project planning activities

especially if they also function as project sponsors.10

Executives must not arbitrarily set unrealistic milestones and then “force” line man-

agers to fulfill them. Both project and line managers should try to adhere to unrealistic

milestones, but if a line manager says he cannot, executives should comply because the

line manager is supposedly the expert.

Executives should interface with project and line personnel during the planning stage

in order to define the requirements and establish reasonable deadlines. Executives must

realize that creating an unreasonable deadline may require the reestablishment of priori-

ties, and, of course, changing priorities can push milestones backward.

11.15 THE PLANNING CYCLE

Previously, we stated that perhaps the most important reason for structuring projects into

life-cycle phases is to provide management with control of the critical decision points in

order to:

● Avoid commitment of major resources too early

● Preserve future options

● Maximize benefits of each project in relation to all other projects

● Assess risks

On long-term projects, phasing can be overdone, resulting in extra costs and delays.

To prevent this, many project-driven companies resort to other types of systems, such as a

management cost and control system (MCCS). No program or project can be efficiently

organized and managed without some form of management cost and control system.

Figure 11–9 shows the five phases of a management cost and control system. The first

phase constitutes the planning cycle, and the next four phases identify the operating cycle.

Figure 11–10 shows the activities included in the planning cycle. The work break- down

structure serves as the initial control from which all planning emanates. The WBS acts as

a vital artery for communications and operations in all phases. A comprehensive

analysis of management cost and control systems is presented in Chapter 15.

10. Although this section is called “The Role of the Executive in Planning,” it also applies to line management
if project sponsorship is pushed down to the middle-management level or lower. This is quite common in highly
mature project management organizations where senior management has sufficient faith in line management’s

ability to serve as project sponsors.

The Planning Cycle 450

FIGURE 11–9. Phases of a management cost and control system.

FIGURE 11–10. The planning cycle of a management cost and control system.

11.16 WORK PLANNING AUTHORIZATION

After receipt of a contract, some form of authorization is needed before

work can begin, even in the planning stage. Both work authorization and

work planning authorization are used to release funds, but for different pur-

poses. Work planning authorization releases funds (primarily for func-

tional management) so that scheduling, costs, budgets, and all other types of plans can be

prepared prior to the release of operational cycle funds, which hereafter shall be referred to

simply as work authorization. Both forms of authorization require the same paperwork. In

many companies this work authorization is identified as a subdivided work description

(SWD), which is a narrative description of the effort to be performed by the cost center

PHASE I PHASE II PHASE III PHASE IV PHASE V

PLANNING
CYCLE OPERATING CYCLE

CUSTOMER
AND

REPORTING

WORK

AUTHORIZATION
AND

RELEASE

PLANNING

COST

ACCOUNTING

COST DATA

COLLATION
AND

REPORTING

MCCS PHASES

MCCS
BUDGET

PROGRAM PLAN

DETAILED

SCHEDULE

MASTER PRODUCTION

SCHEDULE

WORK PLANNING
AUTHORIZATION

V IV III II I
WORK BREAKDOWN

STRUCTURE
PMBOK
®

Guide, 4th Edition
4.3.2 Direct and Manage

Project Execution

Why Do Plans Fail? 451

(division-level minimum). This package establishes the work to be performed, the period of

performance, and possibly the maximum number of hours available. The SWD is multi-

purpose in that it can be used to release contract funds, authorize planning, describe activi-

ties as identified in the WBS, and, last but not least, release work.

The SWD is one of the key elements in the planning of a program as shown in Figure

11–10. Contract control and administration releases the contract funds by issuing a SWD,

which sets forth general contractual requirements and authorizes program management to

proceed. Program management issues the SWD to set forth the contractual guidelines and

requirements for the functional units. The SWD specifies how the work will be performed,

which functional organizations will be involved, and who has what specific responsibili-

ties, and authorizes the utilization of resources within a given time period.

The SWD authorizes both the program team and functional management to begin

work. As shown in Figure 11–10, the SWD provides direct input to Phase II of the MCCS.

Phase I and Phase II can and do operate simultaneously because it is generally impossible

for program office personnel to establish plans, procedures, and schedules without input

from the functional units.

The subdivided work description package is used by the operating organizations to

further subdivide the effort defined by the WBS into small segments or work packages.

Many people contend that if the data in the work authorization document are different

from what was originally defined in the proposal, the project is in trouble right at the start.

This may not be the case, because most projects are priced out assuming “unlimited”

resources, whereas the hours and dollars in the work authorization document are based

upon “limited” resources. This situation is common for companies that thrive on compet-

itive bidding.

11.17 WHY DO PLANS FAIL?

No matter how hard we try, planning is not perfect, and sometimes plans fail. Typical rea-

sons include:

● Corporate goals are not understood at the lower organizational

levels.

● Plans encompass too much in too little time.

● Financial estimates are poor.

● Plans are based on insufficient data.

● No attempt is being made to systematize the planning process.

● Planning is performed by a planning group.

● No one knows the ultimate objective.

● No one knows the staffing requirements.

● No one knows the major milestone dates, including written reports.

● Project estimates are best guesses, and are not based on standards or history.

● Not enough time has been given for proper estimating.

● No one has bothered to see if there will be personnel available with the necessary skills.

● People are not working toward the same specifications.

● People are consistently shuffled in and out of the project with little regard for

schedule.

Why Do Plans Fail? 451

Why do these situations occur? If corporate goals are not understood, it is because cor-

porate executives have been negligent in providing the necessary strategic information and

feedback. If a plan fails because of extreme optimism, then the responsibility lies with both

the project and line managers for not assessing risk. Project managers should ask the line

managers if the estimates are optimistic or pessimistic, and expect an honest answer.

Erroneous financial estimates are the responsibility of the line manager. If the project fails

because of a poor definition of the requirements, then the project manager is totally at fault.

Sometimes project plans fail because simple details are forgotten or overlooked.

Examples of this might be:

● Neglecting to tell a line manager early enough that the prototype is not ready and

that rescheduling is necessary.

● Neglecting to see if the line manager can still provide additional employees for the

next two weeks because it was possible to do so six months ago.

Sometimes plans fail because the project manager “bites off more than he can chew,”

and then something happens, such as his becoming ill. Many projects have failed because

the project manager was the only one who knew what was going on and then got sick.

11.18 STOPPING PROJECTS

There are always situations in which projects have to be stopped. Nine

reasons for stopping are:

● Final achievement of the objectives

● Poor initial planning and market prognosis

● A better alternative is found

● A change in the company interest and strategy

● Allocated time is exceeded

● Budgeted costs are exceeded

● Key people leave the organization

● Personal whims of management

● Problem too complex for the resources available

Today most of the reasons why projects are not completed on time and within cost are

behavioral rather than quantitative. They include:

● Poor morale

● Poor human relations

● Poor labor productivity

● No commitment by those involved in the project

The last item appears to be the cause of the first three items in many situations.

Once the reasons for cancellation are defined, the next problem concerns how to stop

the project. Some of the ways are:

● Orderly planned termination

● The “hatchet” (withdrawal of funds and removal of personnel)

PMBOK
®

Guide, 4th Edition
4.6 Close Projects

Handling Project Phaseouts and Transfers 453

● Reassignment of people to higher priority tasks

● Redirection of efforts toward different objectives

● Burying it or letting it die on the vine (i.e., not taking any official action)

There are three major problem areas to be considered in stopping projects:

● Worker morale

● Reassignment of

personnel

● Adequate documentation and wrap-up

11.19 HANDLING PROJECT PHASEOUTS AND TRANSFERS

By definition, projects (and even life cycle phases) have an end point.

Closing out is a very important phase in the project life cycle, which

should follow particular disciplines and procedures with the objective of:

● Effectively bringing the project to closure according to agreed-on contractual

requirements

● Preparing for the transition of the project into the next operational phase, such as

from production to field installation, field operation, or training

● Analyzing overall project performance with regard to financial data, schedules,

and technical efforts

● Closing the project office, and transferring or selling off all resources originally

assigned to the project, including personnel

● Identifying and pursuing follow-on business

Although most project managers are completely cognizant of the necessity for proper

planning for project start-up, many project managers neglect planning for project termina-

tion. Planning for project termination includes:

● Transferring responsibility

● Completion of project records

● Historic reports

● Postproject analysis

● Documenting results to reflect “as built” product or installation

● Acceptance by sponsor/user

● Satisfying contractual requirements

● Releasing resources

● Reassignment of project office team members

● Disposition of functional personnel

● Disposition of materials

● Closing out work orders (financial closeout)

● Preparing for financial payments

PMBOK
®

Guide, 4th Edition
4.4 Monitor and Control

Project Work

Handling Project Phaseouts and Transfers 453

Project success or failure often depends on management’s ability to handle personnel

issues properly during this final phase. If job assignments beyond the current project look

undesirable or uncertain to project team members, a great deal of anxiety and conflict may

develop that diverts needed energy to job hunting, foot dragging, or even sabotage. Project

personnel may engage in job searches on their own and may leave the project prematurely.

This creates a glaring void that is often difficult to patch.

Given business realities, it is difficult to transfer project personnel under ideal condi-

tions. The following suggestions may increase organizational effectiveness and minimize

personal stress when closing out a project:

● Carefully plan the project closeout on the part of both project and functional man-

agers. Use a checklist to prepare the plan.

● Establish a simple project closeout procedure that identifies the major steps and

responsibilities.

● Treat the closeout phase like any other project, with clearly delineated tasks,

agreed-on responsibilities, schedules, budgets, and deliverable items or results.

● Understand the interaction of behavioral and organizational elements in order to

build an environment conducive to teamwork during this final project phase.

● Emphasize the overall goals, applications, and utilities of the project as well as its

business impact.

● Secure top-management involvement and support.

● Be aware of conflict, fatigue, shifting priorities, and technical or logistic problems.

Try to identify and deal with these problems when they start to develop.

Communicating progress through regularly scheduled status meetings is the key to

managing these problems.

● Keep project personnel informed of upcoming job opportunities. Resource man-

agers should discuss and negotiate new assignments with personnel and involve

people already in the next project.

● Be aware of rumors. If a reorganization or layoff is inevitable, the situation should

be described in a professional manner or people will assume the worst.

● Assign a contract administrator dedicated to company-oriented projects. He will

protect your financial position and business interests by following through on cus-

tomer sign-offs and final payment.

11.20 DETAILED SCHEDULES AND CHARTS

The scheduling of activities is the first major requirement of the program office after pro-

gram go-ahead. The program office normally assumes full responsibility for activity

scheduling if the activity is not too complex. For large programs, functional management

input is required before scheduling can be completed. Depending on program size and con-

tractual requirements, the program office may have a staff member whose sole responsi-

bility is to continuously develop and update activity schedules to track program work. The

resulting information is supplied to program office personnel, functional management,

team members, and the customer.

Detailed Schedules and Charts 455

Activity scheduling is probably the single most important tool for determining how

company resources should be integrated. Activity schedules are invaluable for projecting

time-phased resource utilization requirements, providing a basis for visually tracking per-

formance and estimating costs. The schedules serve as master plans from which both the

customer and management have an up-to-date picture of operations.

Certain guidelines should be followed in the preparation of schedules, regardless of

the projected use or complexity:

● All major events and dates must be clearly identified. If a statement of work is sup-

plied by the customer, those dates shown on the accompanying schedules must be

included. If for any reason the customer’s milestone dates cannot be met, the cus-

tomer should be notified immediately.

● The exact sequence of work should be defined through a network in which inter-

relationships between events can be identified.

● Schedules should be directly relatable to the work breakdown structure. If the

WBS is developed according to a specific sequence of work, then it becomes an

easy task to identify work sequences in schedules using the same numbering sys-

tem as in the WBS. The minimum requirement should be to show where and when

all tasks start and finish.

● All schedules must identify the time constraints and, if possible, should identify

those resources required for each event.

Although these four guidelines relate to schedule preparation, they do not define how

complex the schedules should be. Before preparing schedules, three questions should be

considered:

● How many events or activities should each network have?

● How much of a detailed technical breakdown should be included?

● Who is the intended audience for this schedule?

Most organizations develop multiple schedules: summary schedules for management

and planners and detailed schedules for the doers and lower-level control. The detailed

schedules may be strictly for interdepartmental activities. Program management must

approve all schedules down through the first three levels of the work breakdown structure.

For lower-level schedules (i.e., detailed interdepartmental), program management may or

may not request a sign of approval.

One of the most difficult problems to identify in schedules is a hedge position. A hedge

position is a situation in which the contractor may not be able to meet a customer’s mile-

stone date without incurring a risk, or may not be able to meet activity requirements fol-

lowing a milestone date because of contractual requirements. To illustrate a common hedge

position, consider Example 11–1 below.

Example 11–1. Condor Corporation is currently working on a project that has three

phases: design, development, and qualification of a certain component. Contractual

requirements with the customer specify that no components will be fabricated for the

development phase until the design review meeting is held following the design phase.

REQUEST FOR
1

DETAILED SCHEDULES

AND PLANS
(LEVEL 3)

4 INDIVIDUAL
REVIEWS

5 6 VERIFICATION 7

PROGRAM
TEAM

REVIEW

8

FINALIZE
PLANS/

SCHEDULES
ROUGH
DRAFTS

9
FUNCTIONAL MANAGEMENT PROGRAM TEAM MEMBERS

CUSTOMER
PROGRAM OFFICE

DEPARTMENT/SECTION LEVEL PUBLICATIONS

10 DISTRIBUTION

CONTRACTOR PROGRAM OFFICE

PREPARE PLANS

CUSTOMER

REVIEW

VERIFY THAT ALL
FUNCTIONAL PLANS

ARE INTEGRATED

Condor has determined that if it does not begin component fabrication prior to the design

review meeting, then the second and third phases will slip. Condor is willing to accept the

risk that should specifications be unacceptable during the design review meeting, the costs

associated with preauthorization of fabrication will be incurred. How should this be shown

on a schedule? (The problems associated with performing unauthorized work are not being

considered here.)

The solution is not easy. Condor must show on the master production schedule that

component fabrication will begin early, at the contractor’s risk. This should be followed up

by a contractual letter in which both the customer and contractor understand the risks and

implications.

Detailed schedules are prepared for almost every activity. It is the responsibility of the

program office to marry all of the detailed schedules into one master schedule to verify that

all activities can be completed as planned. The preparation sequence for schedules (and

also for program plans) is shown in Figure 11–11. The program office submits a request

for detailed schedules to the functional managers and the functional managers prepare

summary schedules, detailed schedules, and, if time permits, interdepartmental schedules.

Each functional manager then reviews his schedules with the program office. The program

office, together with the functional program team members, integrates all of the plans and

schedules and verifies that all contractual dates can be met.

Before the schedules are submitted to publications, rough drafts of each schedule and

plan should be reviewed with the customer. This procedure accomplishes the following:

● Verifies that nothing has fallen through the cracks

● Prevents immediate revisions to a published document and can prevent embar-

rassing moments

● Minimizes production costs by reducing the number of early revisions

● Shows customers early in the program that you welcome their help and input into

the planning phase

SUPERVISE PREPARATION

2

3

FUNCTIONAL
MANAGEMENT

REVIEW

FIGURE 11–11. Preparation sequence for schedules and program plans.

Master Production Scheduling 457

After the document is published, it should be distributed to all program office person-

nel, functional team members, functional management, and the customer. Examples of

detailed schedules are shown in Chapter 13.

In addition to the detailed schedules, the program office, with input provided by func-

tional management, must develop organization charts. The charts show who has responsibil-

ity for each activity and display the formal (and often the informal) lines of communication.

Examples were shown in Section 4.11.

The program office may also establish linear responsibility charts (LRCs). In spite of the

best attempts by management, many functions in an organization may overlap between func-

tional units. Also, management might wish to have the responsibility for a certain activity

given to a functional unit that normally would not have that responsibility. This is a common

occurrence on short-duration programs where management desires to cut costs and red tape.

Project personnel should keep in mind why the schedule was developed. The primary

objective is usually to coordinate activities to complete the project with the:

● Best time

● Least cost

● Least risk

There are also secondary objectives of scheduling:

● Studying alternatives

● Developing an optimal schedule

● Using resources effectively

● Communicating

● Refining the estimating criteria

● Obtaining good project control

● Providing for easy revisions

Large projects, especially long-term efforts, may require a “ war room.” War rooms

generally have only one door and no windows. All of the walls are covered with large

schedules, perhaps printed on blueprint paper, and each wall could have numerous sliding

panels. The schedules and charts on each wall could be updated on a daily basis. The room

would be used for customer briefings, team meetings, and any other activities related

specifically to this project.

11.21 MASTER PRODUCTION SCHEDULING

The release of the planning SWD, as shown in Figure 11–10, authorizes the manufactur-

ing units to prepare a master production schedule from which detailed analysis of the uti-

lization of company resources can be seen and tracked.

Master production scheduling is not a new concept. Earliest material control systems

used a “quarterly ordering system” to produce a master production schedule (MPS) for plant

production. This system uses customer order backlogs to develop a production plan over a

Project Plan 459

MARKETING AND
CUSTOMER WORK
TOGETHER TO
IDENTIFY THE
MAJOR MILESTONES

FUNCTIONAL GROUP
(AND PROJECT
OFFICE)
PREPARE THE DETAIL
SCHEDULES

MANUFACTURING PREPARES

MASTER PRODUCTION
SCHEDULE

BASED UPON
FACILITY, EQUIPMENT,
MANPOWER AND MATERIAL

AVAILABILITY

MATERIAL REQUIREMENTS
FOR PROJECT WILL UPDATE
THE MAP SYSTEM

FIGURE 11–12. Material requirements planning interrelationships.

three-month period. The production plan is then exploded manually to determine what parts

must be purchased or manufactured at the proper time. However, rapidly changing customer

requirements and fluctuating lead times, combined with a slow response to these changes,

can result in the disruption of master production scheduling.11

Master Production
Schedule Definition

A master production schedule is a statement of what will be made,

how many units will be made, and when they will be made. It is a pro-

duction plan, not a sales plan. The MPS considers the total demand on

a plant’s resources, including finished product sales, spare (repair) part needs, and inter-

plant needs. The MPS must also consider the capacity of the plant and the requirements

imposed on vendors. Provisions are made in the overall plan for each manufacturing facil-

ity’s operation. All planning for materials, manpower, plant, equipment, and financing for

the facility is driven by the master production schedule.

Objectives of the MPS Objectives of master production scheduling are:

● To provide top management with a means to authorize and control manpower lev-

els, inventory investment, and cash flow

● To coordinate marketing, manufacturing, engineering, and finance activities by a

common performance objective

● To reconcile marketing and manufacturing needs

● To provide an overall measure of performance

● To provide data for material and capacity planning

The development of a master production schedule is a very important step in a planning

cycle. Master production schedules directly tie together personnel, materials, equipment, and

facilities, as shown in Figure 11–12. Master production schedules also identify key dates to

the customer, should he wish to visit the contractor during specific operational periods.

11. The master production schedule is being discussed here because of its importance in the planning cycle. The
MPS cannot be fully utilized without effective inventory control procedures.

MARKETING
MASTER PROJECT

SCHEDULE

MATERIAL REQUIREMENTS
PLANNING SCHEDULE

MASTER PRODUCTION
SCHEDULE

Project Plan 459

11.22 PROJECT PLAN

A project plan is fundamental to the success of any project. For large and

often complex projects, customers may require a project plan that docu-

ments all activities within the program. The project plan then serves as a

guideline for the lifetime of the project and may be revised as often as

once a month, depending on the circumstances and the type of project

(i.e., research and development projects require more revisions to the proj-

ect plan than manufacturing or construction projects). The project plan provides the fol-

lowing framework:

● Eliminates conflicts between functional managers

● Eliminates conflicts between functional management and program management

● Provides a standard communications tool throughout the lifetime of the project (It

should be geared to the work breakdown structure)

● Provides verification that the contractor understands the customer’s objectives and

requirements

● Provides a means for identifying inconsistencies in the planning phase

● Provides a means for early identification of problem areas and risks so that no sur-

prises occur downstream

● Contains all of the schedules defined in Section 11.18 as a basis for progress

analysis and reporting

Development of a project plan can be time-consuming and costly. All levels of the

organization participate. The upper levels provide summary information, and the lower

levels provide the details. The project plan, like activity schedules, does not preclude

departments from developing their own plans.

The project plan must identify how the company resources will be integrated. The

process is similar to the sequence of events for schedule preparation, shown in Figure 11–

11. Since the project plan must explain the events in Figure 11–11, additional iterations are

required, which can cause changes in a project. This can be seen in Figure 11–13.

The project plan is a standard from which performance can be measured by the cus-

tomer and the project and functional managers. The plan serves as a cookbook by answer-

ing these questions for all personnel identified with the project:

● What will be accomplished?

● How will it be accomplished?

● Where will it be accomplished?

● When will it be accomplished?

● Why will it be accomplished?

The answers to these questions force both the contractor and the customer to take a hard

look at:

● Project requirements

● Project management

PMBOK
®
Guide, 4th Edition
Chapter 5 Project Scope
Management

Chapter 4 Integration Management

3.2 Planning Process Group

Project Plan 461

SCHEDULES ECONOMIC

FIGURE 11–13. Iterations for the planning process.

● Project schedules

● Facility requirements

● Logistic support

● Financial support

● Manpower and organization

YES

ARE OBJECTIVES NO
SATISFIED?

YES

ARE SUFFICIENT NO
RESOURCES
AVAILABLE?

ITERATIONS

NO

YES ARE RISKS
TOO GREAT?

NO

YES
HAVE

ASSUMPTIONS
CHANGED?

FORMULATE PLAN

FINALIZE PLANS

CUSTOMER
INPUT

ENVIRONMENTAL
INPUT

Project Plan 461

The project plan is more than just a set of instructions. It is an attempt to eliminate cri-

sis by preventing anything from “falling through the cracks.” The plan is documented and

approved by both the customer and the contractor to determine what data, if any, are miss-

ing and the probable resulting effect. As the project matures, the project plan is

revised to account for new or missing data. The most common reasons for revising a

plan are:

● “Crashing” activities to meet end dates

● Trade-off decisions involving manpower, scheduling, and performance

● Adjusting and leveling manpower requests

The makeup of the project plan may vary from contractor to contractor.12 Most pro-

ject plans can be subdivided into four main sections: introduction, summary and conclu-

sions, management, and technical. The complexity of the information is usually up to the

discretion of the contractor, provided that customer requirements, as may be specified in

the statement of work, are satisfied.

The introductory section contains the definition of the project and the major parts

involved. If the project follows another, or is an outgrowth of similar activities, this is indi-

cated, together with a brief summary of the background and history behind the project.

The summary and conclusion section identifies the targets and objectives of the proj-

ect and includes the necessary “lip service” on how successful the project will be and how

all problems can be overcome. This section must also include the project master schedule

showing how all projects and activities are related. The total project master schedule should

include the following:

● An appropriate scheduling system (bar charts, milestone charts, network, etc.)

● A listing of activities at the project level or lower

● The possible interrelationships between activities (can be accomplished by logic

networks, critical path networks, or PERT networks)

● Activity time estimates (a natural result of the item above)

The summary and conclusion chapter is usually the second section in the project plan

so that upper-level customer management can have a complete overview of the project with-

out having to search through the technical information.

The management section of the project plan contains procedures, charts, and sched-

ules as follows:

● The assignment of key personnel to the project is indicated. This usually refers

only to the project office personnel and team members, since under normal oper-

ations these will be the only individuals interfacing with customers.

12. Cleland and King define fourteen subsections for a program plan. This detail appears more applicable to the
technical and management volumes of a proposal. They do, however, provide a more detailed picture than pre-
sented here. See David I. Cleland and William R. King, Systems Analysis and Project Management (New York:

McGraw-Hill, 1975), pp. 371–380.

Project Plan 463

● Manpower, planning, and training are discussed to assure customers that qualified

people will be available from the functional units.

● A linear responsibility chart might also be included to identify to customers the

authority relationships that will exist in the program.

Situations exist in which the management section may be omitted from the proposal. For

a follow-up program, the customer may not require this section if management’s positions

are unchanged. Management sections are also not required if the management information

was previously provided in the proposal or if the customer and contractor have continuous

business dealings.

The technical section may include as much as 75 to 90 percent of the program plan,

especially if the effort includes research and development, and may require constant updat-

ing as the project matures. The following items can be included as part of the technical

section:

● A detailed breakdown of the charts and schedules used in the project master sched-

ule, possibly including schedule/cost estimates.

● A listing of the testing to be accomplished for each activity. (It is best to include

the exact testing matrices.)

● Procedures for accomplishment of the testing. This might also include a descrip-

tion of the key elements in the operations or manufacturing plans, as well as a list-

ing of the facility and logistic requirements.

● Identification of materials and material specifications. (This might also include

system specifications.)

● An attempt to identify the risks associated with specific technical requirements

(not commonly included). This assessment tends to scare management person-

nel who are unfamiliar with the technical procedures, so it should be omitted if

possible.

The project plan, as used here, contains a description of all phases of the project. For

many projects, especially large ones, detailed planning is required for all major events and

activities. Table 11–4 identifies the type of individual plans that may be required in place

of a (total) project plan. These are often called subsidiary plans.

The project plan, once agreed on by the contractor and customer, is then used to provide

project direction. This is shown in Figure 11–14. If the project plan is written clearly, then

any functional manager or supervisor should be able to identify what is expected of him. The

project plan should be distributed to each member of the project team, all functional man-

agers and supervisors interfacing with the project, and all key functional personnel.

One final note need be mentioned concerning the legality of the project plan. The proj-

ect plan may be specified contractually to satisfy certain requirements as identified in the

customer’s statement of work. The contractor retains the right to decide how to accomplish

this, unless, of course, this is also identified in the SOW. If the SOW specifies that quality

assurance testing will be accomplished on fifteen end-items from the production line, then

fifteen is the minimum number that must be tested. The project plan may show that twenty-

five items are to be tested. If the contractor develops cost overrun problems, he may wish

to revert to the SOW and test only fifteen items. Contractually, he may do this without

Project Plan 463

TABLE 11–4. TYPES OF PLANS

Type of Plan Description

Budget How much money is allocated to each event?
Configuration management How are technical changes made?

Facilities What facilities resources are available?

Logistics support How will replacements be handled?
Management How is the program office organized?

Manufacturing What are the time-phase manufacturing events?
Procurement What are my sources? Should I make or buy? If vendors are not qualified,

how shall I qualify them?

Quality assurance How will I guarantee specifications will be met?

Research/development What are the technical activities?
Scheduling Are all critical dates accounted for?

Tooling What are my time-phased tooling requirements?
Training How will I maintain qualified personnel?

Transportation How will goods and services be shipped?

FIGURE 11–14. Project direction activities.

MASTER SCHEDULES

DETAILED SCHEDULES

Project Plan 463

informing the customer. In most cases, however, the customer is notified, and the project

is revised.

11.23 TOTAL PROJECT PLANNING

The difference between the good project manager and the poor project man-

ager is often described in one word: planning. Project planning involves

planning for:

● Schedule development

● Budget development

● Project administration (see Section 5.3)

● Leadership styles (interpersonal influences; see Section 5.4)

● Conflict management (see Chapter 7)

The first two items involve the quantitative aspects of planning. Planning for project

administration includes the development of the linear responsibility chart.

Although each project manager has the authority and responsibility to establish

project policies and procedures, they must fall within the general guidelines established by

top management.

Linear responsibility charts can result from customer-imposed requirements above

and beyond normal operations. For example, the customer may require as part of his qual-

ity control requirements that a specific engineer supervise and approve all testing of a cer-

tain item, or that another individual approve all data released to the customer over and

above program office approval. Customer requirements similar to those identified above

require LRCs and can cause disruptions and conflicts within an organization.

Several key factors affect the delegation of authority and responsibility both from

upper-level management to project management, and from project management to func-

tional management. These key factors include:

● The maturity of the project management function

● The size, nature, and business base of the company

● The size and nature of the project

● The life cycle of the project

● The capabilities of management at all levels

Once agreement has been reached on the project manager’s authority and responsibil-

ity, the results may be documented to delineate that role regarding:

● Focal position

● Conflict between the project manager and functional managers

● Influence to cut across functional and organizational lines

● Participation in major management and technical decisions

● Collaboration in staffing the project

● Control over allocation and expenditure of funds

● Selection of subcontractors

PMBOK
®
Guide, 4th Edition
Chapter 5 Project Scope
Management
Chapter 4 Integration Management
3.2 Planning Process Group

Total Project Planning 465

● Rights in resolving conflicts

● Input in maintaining the integrity of the project team

● Establishment of project plans

● Provisions for a cost-effective information system for control

● Provisions for leadership in preparing operational requirements

● Maintenance of prime customer liaison and contact

● Promotion of technological and managerial improvements

● Establishment of project organization for the duration

● Elimination of red tape

Documenting the project manager’s authority is necessary in some situations because:

● All interfacing must be kept as simple as possible.

● The project manager must have the authority to “force” functional managers to

depart from existing standards and possibly incur risk.

● Gaining authority over those elements of a program that are not under the project

manager’s control is essential. This is normally achieved by earning the respect of

the individuals concerned.

● The project manager should not attempt to fully describe the exact authority and

responsibilities of the project office personnel or team members. Problem-solving

rather than role definition should be encouraged.

Although documenting project authority is undesirable, it may be necessary, espe-

cially if project initiation and planning require a formal project chart. In such a case, a let-

ter such as that shown in Table 11–5 may suffice.

Power and authority are often discussed as though they go hand in hand. Authority

comes from people above you, perhaps by delegation, whereas power comes from people

below you. You can have authority without power or power without authority.

In a traditional organizational structure, most individuals maintain position power. The

higher up you sit, the more power you have. But in project management, the reporting level

of the project might be irrelevant, especially if a project sponsor exists. In project manage-

ment, the project manager’s power base emanates from his

● Expertise (technical or managerial)

● Credibility with employees

● Sound decision-making ability

The last item is usually preferred. If the project manager is regarded as a sound

decision-maker, then the employees normally give the project manager a great deal of

power over them.

Leadership styles refer to the interpersonal influence modes that a project manager can

use. Project managers may have to use several different leadership styles, depending on the

makeup of the project personnel. Conflict management is important because if the project

manager can predict what conflicts will occur and when they are most likely to

occur, he may be able to plan for the resolution of the conflicts through project administration.

Figure 11–15 shows the complete project planning phase for the quantitative portions.

The object, of course, is to develop a project plan that shows complete distribution of

Total Project Planning 465

TABLE 11–5. PROJECT CHARTER

ELECTRODYNAMICS

12 Oak Avenue
Cleveland, Ohio 44114

11 June 2001
To: Distribution
From: L. White, Executive Vice President

Subject: Project Charter for the Acme Project

Mr. Robert L. James has been assigned as the Project Manager for

the Acme Project.

Responsibility
Mr. James will be responsible for ensuring that all key milestones are met within the

time, cost, and performance constraints of his project, while adhering to proper quality
control standards. Furthermore, the project manager must work closely with line

managers to ensure that all assigned resources are used effectively and efficiently, and
that the project is properly staffed.

Additionally, the project manager will be responsible for:

1. All formal communications between the customer

and contractor.

2. Preparation of a project plan that is realistic, and acceptable by both the customer

and contractor.

3. Preparation of all project data items.
4. Keeping executive management informed as to project status through weekly

(detailed) and monthly (summary) status reporting.

5. Ensuring that all functional employees and managers are kept informed as to their
responsibilities on the project and all revisions imposed by the cu stomer or parent

organization.
6. Comparing actual to predicted cost and performance, and taking corrective action

when necessary.
7. Maintaining a plan that continuously displays the project’s time, cost, and perfor –

mance as well as resource commitments made by the functional

managers.

Authority
To ensure that the project meets its objectives, Mr. James is authorized to manage the

project and issue directives in accordance to the policies and procedures section of
the company’s Project Management Manual. Additional directives may be issued

through the office of the executive vice-president.

The program manager’s authority also includes:
1. Direct access to the customer on all matters pertaining to the Acme Project.
2. Direct access to Electrodynamics’ executive management on all matters pertaining to

the Acme Project.

3. Control and distribution of all project dollars, including procurement, such that com-
pany and project cash flow limitations are adhered to.

4. To revise the project plan as needed, and with customer approval.
5. To require periodic functional status reporting.
6. To monitor the time, cost, and performance activities in the functional departments

and ensure that all problems are promptly identified, reported, and solved.

7. To cut across all functional lines and to interface with all levels of management as
necessary to meet project requirements.

8. To renegotiate with functional managers for changes in personnel

assignments.

9. Delegating responsibilities and authority to functional personnel, provided that the

line manager is in approval that the employee can handle this authority/responsibility
level.

Any questions regarding the above policies should be directed to the undersigned.

L. White

Executive Vice-President

PMBOK
®

Guide, 4th Edition
4.1 Develop Project Charter

FIGURE 11–15. Project planning.

PMBOK
®

Guide, 4th Edition
Chapter 4 Integration Management

4
6
7

resources and the corresponding costs. The figure represents an iterative process. The proj-

ect manager begins with a coarse (arrow diagram) network, and then decides on the work

breakdown structure. The WBS is essential to the arrow diagram and should be constructed

so that reporting elements and levels are easily identifiable. Eventually, there will be an

arrow diagram and detailed chart for each element in the WBS. If there is too much detail,

the project manager can refine the diagram by combining all logic into one plan and

can then decide on the work assignments. There is a risk here that, by condensing the dia-

grams as much as possible, there may be a loss of clarity. As shown in Figure 11–15, all the

charts and schedules can be integrated into one summary-level figure. This can be accom-

plished at each WBS level until the desired plan is achieved.

Finally, project, line, and executive management must analyze other internal and

external variables before finalizing these schedules. These variables include:

● Introduction or acceptance of the product in the marketplace

● Present or planned manpower availability

● Economic constraints of the project

● Degree of technical difficulty

● Manpower availability

● Availability of personnel training

● Priority of the project

In small companies and projects, certain items in Figure 11–15 may be omitted, such

as the LRCs.

11.24 THE PROJECT CHARTER

The original concept behind the project charter was to document the proj-

ect manager’s authority and responsibility, especially for projects imple-

mented away from the home office. Today, the project charter is more of

an internal legal document identifying to the line managers and their personnel the project

manager’s authority and responsibility and the management- and/or customer-approved

scope of the project.

Theoretically, the sponsor prepares the charter and affixes his/her signature, but in

reality, the project manager may prepare it for the sponsor’s signature. At a minimum, the

charter should include:

● Identification of the project manager and his/her authority to apply resources to the

project

● The business purpose that the project was undertaken to address, including all

assumptions and constraints

● Summary of the conditions defining the project

● Description of the project

● Objectives and constraints on the project

● Project scope (inclusions and exclusions)

● Key stakeholders and their roles

PMBOK
®
Guide, 4th Edition
4.1 Develop Project Charter

PMBOK
®

Guide, 4th Edition
4.5 Integrated Change Control

Management Control 469

● Risks

● Involvement by certain stakeholders

The PMBOK® Guide provides a framework for the project charter. What is somewhat

unfortunate is that every company seems to have its own idea of what should be included

in a charter. The contents of a charter are often dependent upon where in the evolution and

life cycle of a project the charter is prepared. (See Advanced Project Management: Best

Practices on Implementation by Harold Kerzner, John Wiley & Sons, New York, 2004, pp.

101–102, 120, 629–630.) Some companies such as Computer Associates use both a full

charter (closely aligned to the PMBOK® Guide) and an abbreviated charter based upon the

size and complexity of the project.

The charter is a “legal” agreement between the project manager and the company.

Some companies supplement the charter with a “contract” that functions as an agreement

between the project and the line organizations.

Some companies have converted the charter into a highly detailed document

containing:

● The scope baseline/scope statement

● Scope and objectives of the project (SOW)

● Specifications

● WBS (template levels)

● Timing

● Spending plan (S-curve)

● The management plan

● Resource requirements and manloading (if known)

● Resumés of key personnel

● Organizational relationships and structure

● Responsibility assignment matrix

● Support required from other organizations

● Project policies and procedures

● Change management plan

● Management approval of above

When the project charter contains a scope baseline and management plan, the project char-

ter may function as the project plan. This is not really an effective use of the charter, but it

may be acceptable on certain types of projects for internal customers.

11.25 MANAGEMENT CONTROL

Because the planning phase provides the fundamental guidelines for the

remainder of the project, careful management control must be established.

In addition, since planning is an ongoing activity for a variety of different

programs, management guidelines must be established on a company-wide basis in order

to achieve unity and coherence.

All functional organizations and individuals working directly or indirectly on a pro-

gram are responsible for identifying, to the project manager, scheduling and planning

TABLE 11–6. PLANNING AND REQUIREMENTS POLICIES

Program Manager Functional Manager Relationship

Requests the preparation of the program Develops the details of the program plans Program planning and scheduling is a
master schedules and provides for and requirements in conjunction with functional specialty; the program

integration with the division composite the program manager. Provides manager utilizes the services of the
schedules. proposal action in support of program specialist organizations. The specialists

Defines work to be accomplished through manager requirements and the retain their own channels to the
preparation of the subdivided work program master schedule. general manager but must keep the

description package. program manager informed.
Provides program guidance and direction With guidance furnished by the program Program planning is also a consultative

for the preparation of program plans manager, participates in the operation and is provided guidelines by
that establish program cost, schedule, preparation of program plans, the program manager. Functional

and technical performance; and that schedules, and work release documents organizations initiate supporting plans
define the major events and tasks to which cover cost, schedule, and for program manager approval, or

ensure the orderly progress of the technical performance; and which react to modify plans to maintain
program. define major events and tasks. Provides currency. Functional organizations also

supporting detail plans and schedules. initiate planning studies involving
trade-offs and alternative courses of
action for presentation to the program
manager.
Establishes priorities within the program. Negotiates priorities with program The program manager and program team

Obtains relative program priorities managers for events and tasks to be members are oriented to his program,
between programs managed by other performed by his organization. whereas the functional organizations

programs from the director, program and the functional managers are
management, manager, marketing and “function” and multiprogram

product development, or the general oriented. The orientation of each

manager as specified by the policy. director, manager, and team member

4
7
0

Approves program contractual data Conducts analysis of contractual data
requirements. requirements. Develops data plans

including contractor data requirements
list and obtains program manager

approval.

Remains alert to new contract Remains alert to new contract
requirements, government regulations requirements, government regulations,

and directives that might affect the and directives that might affect the
work, cost, or management of the work, cost, or management of his

program. organization on any program.

must be mutually recognized to

preclude unreasonable demands and
conflicting priorities. Priority conflicts

that cannot be resolved must be
referred to the general manager.

Provides early technical requirements Provides the necessary make-or-buy Make-or-buy concurrence and approvals
definitions, and substantiates make-or- data; substantiates estimates and are obtained in accordance with

buy recommendations. Participates in recommendations in the area of current Policies and Procedures.
the formulation of the make-or-buy functional specialty.

plan for the program.
Approves the program bill of material Prepares the program bill of material.

for need and compliance with program

need and requirements.
Directs data management including

maintenance of current and historical
files on programmed contractual data

requirements.

4
7
1

The Project Manager–Line Manager Interface 473

TABLE 11–7. SCHEDULING POLICIES

Program Manager Functional Manager Relationship

Provides contractual data The operations directorate shall The operations directorate constructs
requirements and guidance construct the program master the program master schedule with

for construction of schedule. Data should include but data received from functional
program master schedules. not be limited to engineering plans, organizations and direction from

manufacturing plans, procurement the program manager. Operations
plans, test plans, quality plans, and shall coordinate program master

provide time spans for schedule with functional
accomplishment of work elements organizations and secure program

defined in the work breakdown manager’s approval prior to

structure to the level of definition release.
visible in the planned subdivided

work description package.
Concurs with detail schedules Constructs detail program schedules Program manager monitors the

construction by functional and working schedules in functional organization’s detail
organizations. consonance with program manager– schedules for compliance with

Provides corrective action approved program master schedule. program master schedules and
decisions and direction as Secures program manager reports variance items that may

required at any time a concurrence and forwards copies impact division operations to the
functional organization to the program manager. director, program management.

fails to meet program
master schedule

requirements or when, by
analysis, performance

indicated by detail

schedule monitoring
threatens to impact the

program master schedule.

problems that require corrective action during both the planning cycle and the operating

cycle. The program manager bears the ultimate and final responsibility for identifying

requirements for corrective actions. Management policies and directives are written specif-

ically to assist the program manager in defining the requirements. Without clear definitions

during the planning phase, many projects run off in a variety of directions.

Many companies establish planning and scheduling management policies for the

project and functional managers, as well as a brief description of how they should inter-

face. Table 11–6 identifies a typical management policy for planning and requirements,

and Table 11–7 describes scheduling management policies.

11.26 THE PROJECT MANAGER–LINE MANAGER INTERFACE

The utilization of management controls, such as those outlined in Section

11.25, does not necessarily guarantee successful project planning. Good

project planning, as well as other project functions, requires a good work-

ing relationship between the project and line managers. At this interface:

● The project manager answers these questions:

● What is to be done? (using the SOW, WBS)

PMBOK
®

Guide, 4th Edition
1.6 Interpersonal Skills

The Project Manager–Line Manager Interface 473

● When will the task be done? (using the summary schedule)

● Why will the task be done? (using the SOW)

● How much money is available? (using the SOW)

● The line manager answers these questions:

● How will the task be done? (i.e., technical criteria)

● Where will the task be done? (i.e., technical criteria)

● Who will do the task? (i.e., staffing)

Project managers may be able to tell line managers “how” and “where,” provided that

the information appears in the SOW as a requirement for the project. Even then, the line

manager can take exception based on his technical expertise.

Figures 11–16 and 11–17 show what can happen when project managers overstep their

bounds. In Figure 11–16, the manufacturing manager built a brick wall to keep the project

managers away from his personnel because the project managers were telling his line peo-

ple how to do their job. In Figure 11–17, the subproject managers (for simplicity’s sake,

equivalent to project engineers) would have, as their career path, promotions to assistant

project managers (APMs). Unfortunately, the APMs still felt that they were technically

FIGURE 11–16. The brick wall.

PRESIDENT

V.P. MARKETING V.P. ENGINEERING
V.P.

MANUFACTURING

PROJECT
MANAGERS

OTHERS
PROJECT

ENGINEERING
OTHERS

P.M.

Configuration Management 475

FIGURE 11–17. Modification of the brick wall.

competent enough to give technical direction, and this created havoc for the engineering

managers.

The simplest solution to all of these problems is for the project manager to provide the

technical direction through the line managers. After all, the line managers are supposedly

the true technical experts.

11.27 FAST-TRACKING

Sometimes, no matter how well we plan, something happens that causes

havoc on the project. Such is the case when either the customer or man-

agement changes the project’s constraints. Consider Figure 11–18 and let

us assume that the execution time for the construction of the project is one

year. To prepare the working drawings and specifications down through level 5 of the WBS

would require an additional 35 percent of the expected execution time, and if a feasibility

study is required, then an additional 40 percent will be added on. In other words, if the exe-

cution phase of the project is one year, then the entire project is almost two years.

Now, let us assume that management wishes to keep the end date fixed but the start

date is delayed because of lack of adequate funding. How can this be accomplished with-

out sacrificing the quality? The answer is to fast-track the project. Fast-tracking a project

means that activities that are normally done in series are done in parallel. An example of

O P W ND WI M S

ENGINEERING

M. A.P. A.P.M.

PROJECT
MANAGER

PMBOK
®

Guide, 4th Edition
2.1 Characteristics of the Project

Life Cycle

Configuration Management 475

INFORMATION EXPLOSION

DURING WORKING DRAWINGS &

SPECIFICATIONS

100

85

15

—75 —35 0

0

+75 +100

APPROXIMATE PERCENT OF CONSTRUCTION TIME

FIGURE 11–18. The information explosion. Source: R. M. Wideman, Cost Control of Capital
Projects (Vancouver, B.C.: A.E.W. Services of Canada, 1983), p. 22.

this is when construction begins before detail design is completed. (See Chapter 2, Table

2–5 on life-cycle phases.)

Fast-tracking a job can accelerate the schedule but requires that additional risks be

taken. If the risks materialize, then either the end date will slip or expensive rework will

be needed. Almost all project-driven companies fast-track projects, but there is danger

when fast-tracking becomes a way of life.

11.28 CONFIGURATION MANAGEMENT

A critical tool employed by a project manager is configuration management

or configuration change control. As projects progress downstream through

the various life-cycle phases, the cost of engineering changes can grow

boundlessly. It is not uncommon for companies to bid on proposals at 40 percent below their

own cost hoping to make up the difference downstream with engineering changes. It is also

quite common for executives to “encourage” project managers to seek out engineering

changes because of their profitability.

Configuration management is a control technique, through an orderly process, for for-

mal review and approval of configuration changes. If properly implemented, configuration

management provides

● Appropriate levels of review and approval for changes

● Focal points for those seeking to make changes

● A single point of input to contracting representatives in the customer’s and con-

tractor’s office for approved changes

CONCEIVE

IMPLEMENTATION PHASE

CONCEPTUAL DESIGN

TENDER & AWARD

COMMISSION

OPERATE

CONSTRUCTION

WORKING DRAWINGS

ECONOMIC STUDIES

FINISH EXECUTE DEFINE DEVELOP

OPERATION
FEASIBILITY PHASE

PMBOK
®
Guide, 4th Edition
4.5 Integrated Change Control
P
R

O

J
E

C
T

B
R

IE
F

C
O

N
T

R
A
C
T

P
E

R
C

E
N

T
O

F
P

R
O
J
E
C
T

I
N

F
O

R
M

A
T

IO
N

Configuration Management 475

At a minimum, the configuration control committee should include representation

from the customer, contractor, and line group initiating the change. Discussions should

answer the following questions:

● What is the cost of the change?

● Do the changes improve quality?

● Is the additional cost for this quality justifiable?

● Is the change

necessary?

● Is there an impact on the delivery date?

Changes cost money. Therefore, it is imperative that configuration management be

implemented correctly. The following steps can enhance the implementation process:

● Define the starting point or “baseline” configuration

● Define the “classes” of changes

● Define the necessary controls or limitations on both the customer and contractor

● Identify policies and procedures, such as

● Board chairman

● Voters/alternatives

● Meeting time

● Agenda

● Approval forums

● Step-by-step processes

● Expedition processes in case of emergencies

Effective configuration control pleases both customer and contractor. Overall benefits

include:

● Better communication among staff

● Better communication with the customer

● Better technical intelligence

● Reduced confusion for changes

● Screening of frivolous changes

● Providing a paper trail

As a final note, it must be understood that configuration control, as used here, is not

a replacement for design review meetings or customer interface meetings. These meetings

are still an integral part of all projects.

11.29 ENTERPRISE PROJECT MANAGEMENT METHODOLOGIES

Enterprise project management methodologies can enhance the project planning process

as well as providing some degree of standardization and consistency.

Companies have come to the realization that enterprise project management method-

ologies work best if the methodology is based upon templates rather than rigid policies and

Enterprise Project Management Methodologies 477

procedures. The International Institute for Learning has created a Unified Project

Management Methodology (UPMM™) with templates categorized according to the

PMBOK® Guide Areas of Knowledge13:

Communication

Project Charter

Project Procedures Document

Project Change Requests Log

Project Status Report

PM Quality Assurance Report

Procurement Management Summary

Project Issues Log

Project Management Plan

Project Performance Report

Cost

Project Schedule

Risk Response Plan and Register

Work Breakdown Structure (WBS)

Work Package

Cost Estimates Document

Project Budget

Project Budget Checklist

Human Resources

Project Charter
Work Breakdown Structure (WBS)

Communications Management Plan

Project Organization Chart

Project Team Directory

Responsibility Assignment Matrix (RAM)

Project Management Plan
Project Procedures Document

Kickoff Meeting Checklist

Project Team Performance Assessment

Project Manager Performance Assessment

Integration

Project Procedures Overview

Project Proposal

Communications Management Plan

13. Unified Project Management Methodology (UPMMTM) is registered, copyrighted, and owned by
International Institute for Learning, Inc., © 2005; reproduced by permission.

Enterprise Project Management Methodologies 477

Procurement Plan

Project Budget
Project Procedures Document
Project Schedule
Responsibility Assignment Matrix (RAM)
Risk Response Plan and Register
Scope Statement
Work Breakdown Structure (WBS)
Project Management Plan
Project Change Requests Log
Project Issues Log

Project Management Plan Changes Log

Project Performance Report

Lessons Learned Document

Project Performance Feedback

Product Acceptance Document

Project Charter

Closing Process Assessment Checklist

Project Archives Report

Procurement

Project Charter
Scope Statement
Work Breakdown Structure (WBS)
Procurement Plan

Procurement Planning Checklist

Procurement Statement of Work (SOW)

Request for Proposal Document Outline

Project Change Requests Log

Contract Formation Checklist

Procurement Management Summary

Quality
Project Charter
Project Procedures Overview

Work Quality Plan

Project Management Plan
Work Breakdown Structure (WBS)
PM Quality Assurance Report
Lessons Learned Document
Project Performance Feedback
Project Team Performance Assessment

PM Process Improvement Document

Risk

Procurement Plan
Project Charter

Project Audits 479

Project Procedures Document
Work Breakdown Structure (WBS)
Risk Response Plan and Register
Scope

Project Scope Statement

Work Breakdown Structure (WBS)
Work Package

Project Charter

Time

Activity Duration Estimating Worksheet

Cost Estimates Document

Risk Response Plan and Register Medium

Work Breakdown Structure (WBS)
Work Package
Project Schedule

Project Schedule Review Checklist

11.30 PROJECT AUDITS

In recent years, the necessity for a structured independent review of various parts of a busi-

ness, including projects, has taken on a more important role. Part of this can be attributed

to the Sarbanes–Oxley law compliance requirements. These independent reviews are

audits that focus on either discovery or decision-making. The audits can be scheduled or

random and can be performed by in-house personnel or external examiners.

There are several types of audits. Some common types include:

● Performance Audits: These audits are used to appraise the progress and perfor-

mance of a given project. The project manager, project sponsor, or an executive

steering committee can conduct this audit.

● Compliance Audits: These audits are usually performed by the project manage-

ment office (PMO) to validate that the project is using the project management

methodology properly. Usually the PMO has the authority to perform the audit

but may not have the authority to enforce compliance.

● Quality Audits: These audits ensure that the planned project quality is being met

and that all laws and regulations are being followed. The quality assurance group

performs this audit.

● Exit Audits: These audits are usually for projects that are in trouble and may need

to be terminated. Personnel external to the project, such as an exit champion or an

executive steering committee, conduct the audits.

● Best Practices Audits: These audits can be conducted at the end of each life-cycle phase

or at the end of the project. Some companies have found that project managers may not

be the best individuals to perform the audit. In such situations, the company may have

professional facilitators trained in conducting best practices reviews.

Project Audits 479

11.31 STUDYING TIPS FOR THE PMI® PROJECT MANAGEMENT

CERTIFICATION EXAM

This section is applicable as a review of the principles to support the knowledge areas and

domain groups in the PMBOK® Guide. This chapter addresses:

● Scope Management

● Initiation

● Planning

● Execution

● Monitoring

● Closure

Understanding the following principles is beneficial if the reader is using this text to

study for the PMP® Certification Exam:

● Need for effective planning

● Components of a project plan and subsidiary plans

● Need for and components of a statement of work (both proposal and contractual)

● How to develop a work breakdown structure and advantages and disadvantages of

highly detailed levels

● Types of work breakdown structures

● Purpose of a work package

● Purpose of configuration management and role of the change control board

● Need for a project charter and components of a project charter

● Need for the project team to be involved in project-planning activities

● That changes to a plan or baseline need to be managed

In Appendix C, the following Dorale Products mini–case studies are applicable:

● Dorale Products (C) [Scope Management]

● Dorale Products (D) [Scope Management]

● Dorale Products (E) [Scope Management]

The following multiple-choice questions will be helpful in reviewing the principles of

this chapter:

1. The document that officially sanctions the project is the:

A. Project charter
B. Project plan
C. Feasibility study
D. Cost-benefit analysis

2. The work breakdown structure “control points” for the management of a project are the:
A. Milestones
B. Work packages
C. Activities
D. Constraints

3. One of the most common reasons why projects undergo scope changes is:
A. Poor work breakdown structure
B. Poorly defined statement of work

Studying Tips for the PMI® Project Management Certification Exam 481

C. Lack of resources
D. Lack of funding

4. Which of the following generally cannot be validated using a work breakdown structure?
A. Schedule control
B. Cost control
C. Quality control
D. Risk management

Answer questions 5–8 using the work breakdown structure (WBS) shown below (numbers in

parentheses show the dollar value for a particular element):

1.00.00

1.1.0 ($25K)

1.1.1

1.1.2 ($12K)
1.2.0

1.2.1 ($16K)

1.2.2.0

1.2.2.1 ($20K)
1.2.2.2 ($30K)

5. The cost of WBS element 1.2.2.0 is:
A. $20K
B. $30K
C. $50K
D. Cannot be determined

6. The cost of WBS element 1.1.1 is:
A. $12K
B. $13K
C. $25K
D. Cannot be determined

7. The cost of the entire program (1.00.00) is:
A. $25K
B. $66K
C. $91K
D. Cannot be determined

8. The work packages in the WBS are at WBS level(s):

A. 2 only
B. 3 only
C. 4 only
D. 3 and 4

9. One of the outputs of the PMBOK® Scope Planning Process is:
A. A project charter
B. A scope statement and management plan
C. A detailed WBS
D. None of the above

10. Which of the following is (are) the benefit(s) of developing a WBS to low levels?
A. Better estimation of costs
B. Better control

Problems 482

C. Less likely that something will “fall through the cracks”
D. All of the above

11. The PMBOK® Scope Verification Process is used to verify that:
A. The budget is correct.
B. The scope is correct.
C. The schedule is correct.
D. A life-cycle phase or the end of the project has been completed successfully.

12. Financial closeout, which is often part of following the Scope Verification Process, is used to:
A. Close out all charge numbers
B. Close out all charge numbers for the work performed and completed
C. Amend the work authorization forms
D. None of the above

13. One of your contractors has sent you an e-mail requesting that they be allowed to conduct
only eight tests rather than the ten tests required by the specification. What should the proj-

ect manager do first?

A. Change the scope baseline
B. Ask the contractor to put forth a change request
C. Look at the penalty clauses in the contract
D. Ask your sponsor for his or her opinion

14. One of your contractors sends you an e-mail request to use high quality raw materials in
your project stating that this will be value-added and improve quality. What should the proj-

ect manager do first?

A. Change the scope baseline
B. Ask the contractor to put forth a change request
C. Ask your sponsor for his or her opinion
D. Change the WBS

15. What are the maximum number of subsidiary plans a program management plan can contain?
A. 10
B. 15
C. 20
D. Unlimited number

16. The change control board, of which you are a member, approves a significant scope
change. The first document that the project manager should updated would be the:

A. Scope baseline
B. Schedule
C. WBS
D. Budget

ANSWERS

1. A

2. B

3. B

4. C

5. C

Problems 483

6. B

7. C

8. D

9. B

10. D

11. D

12. B

13. B

14. B

15. D

16. A

PROBLEMS

11–1 Under what conditions would each of the following either not be available or not be nec-

essary for initial planning?

a. Work breakdown structure
b. Statement of work

c. Specifications

d. Milestone schedules

11–2 What planning steps should precede total program scheduling? What steps are

necessary?

11–3 How does a project manager determine how complex to make a program plan or how

many schedules to include?

11–4 Can objectives always be identified and scheduled?

11–5 Can a WBS always be established for attaining an objective?

11–6 Who determines the work necessary to accomplish an objective?

11–7 What roles does a functional manager play in establishing the first three levels of

the WBS?

11–8 Should the length of a program have an impact on whether to set up a separate project or

task for administrative support? How about for raw materials?

11–9 Is it possible for the WBS to be designed so that resource allocation is easier to identify?

11–10 If the scope of effort of a project changes during execution of activities, what should be

the role of the functional manager?

11–11 What types of conflicts can occur during the planning cycle, and what modes should be

used for their resolution?

11–12 What would be the effectiveness of Figure 11–3 if the work packages were replaced by

tasks?

Problems 484

11–13 Under what situations or projects would work planning authorization not be necessary?

11–14 On what types of projects could hedge positions be easily identified on a schedule?

11–15 Can activities 5 and 6 of Figure 11–11 be eliminated? What risks does a project man-
ager incur if these activities are eliminated?

11–16 Where in the planning cycle should responsibility charts be prepared? Can you identify

this point in Figure 11–11?

11–17 For each one of the decision points in Figure 11–13, who makes the decision? Who
must input information? What is the role of the functional manager and the functional team

member? Where are strategic variables identified?

11–18 Consider a project in which all project planning is performed by a group. After all plan-

ning is completed, including the program plan and schedules, a project manager is selected. Is
there anything wrong with this arrangement? Can it work?

11–19 How do the customer and contractor know if each one completely understands the

statement of work, the work breakdown structure, and the program plan?

11–20 Should a good project plan formulate methods for anticipating problems?

11–21 Some project managers schedule staff meetings as the primary means for planning and

control. Do you agree with this philosophy?

11–22 Paul Mali (Management by Objectives, New York: John Wiley, 1972, p. 12) defines

MBO as a five-step process:

● Finding the objective

● Setting the objective

● Validating the objective
● Implementing the objective

● Controlling and reporting status of the objective

How can the work breakdown structure be used to accomplish each of the above steps? Would

you agree or disagree that the more levels the WBS contains, the greater the understanding and
clarity of those steps necessary to complete the objectives?

11–23 Many textbooks on management state that you should plan like you work, by doing one

thing at a time. Can this same practice be applied at the project level, or must a project man-

ager plan all activities at once?

11–24 Is it true that project managers set the milestones and functional managers hope they
can meet them?

11–25 You have been asked to develop a work breakdown structure for a project. How should

you go about accomplishing this? Should the WBS be time-phased, department-phased,
division-phased, or some combination?

11–26 You have just been instructed to develop a schedule for introducing a new product into

the marketplace. Below are the elements that must appear in your schedule. Arrange these ele-

ments into a work breakdown structure (down through level 3), and then draw the arrow diagram.
You may feel free to add additional topics as necessary.

● Production layout ● Review plant costs

● Market testing ● Select distributors

Problems 485

● Analyze selling cost ● Lay out artwork

● Analyze customer reactions ● Approve artwork
● Storage and shipping costs ● Introduce at trade show

● Select salespeople ● Distribute to salespeople

● Train salespeople ● Establish billing procedure

● Train distributors ● Establish credit procedure

● Literature to salespeople ● Revise cost of production

● Literature to distributors ● Revise selling cost
● Print literature ● Approvals*

● Sales promotion ● Review meetings*

● Sales manual ● Final specifications
● Trade advertising ● Material requisitions
(* Approvals and review meetings can appear several times.)

11–27 Once a project begins, a good project manager will set up checkpoints. How should this

be accomplished? Will the duration of the project matter? Can checkpoints be built into a
schedule? If so, how should they be identified?

11–28 Detailed schedules (through WBS levels 3, 4, 5, . . .) are prepared by the functional

managers. Should these schedules be shown to the customer?

11–29 The project start-up phase is complete, and you are now ready to finalize the opera-

tional plan. Below are six steps that are often part of the finalization procedure. Place them in

the appropriate order.

1. Draw diagrams for each individual WBS element.
2. Establish the work breakdown structure and identify the reporting elements and

levels.

3. Create a coarse (arrow-diagram) network and decide on the WBS.
4. Refine the diagram by combining all logic into one plan. Then decide on the work

assignments.

5. If necessary, try to condense the diagram as much as possible without losing clarity.
6. Integrate diagrams at each level until only one exists. Then begin integration into

higher WBS levels until the desired plan is achieved.

11–30 Below are seven factors that must be considered before finalizing a schedule. Explain

how a base case schedule can change as a result of each of these:

● Introduction or acceptance of the product in the marketplace
● Present or planned manpower availability
● Economic constraints of the project
● Degree of technical difficulty
● Manpower availability

● Availability of personnel training
● Priority of the project

11–31 You are the project manager of a nine-month effort. You are now in the fifth month of

the project and are more than two weeks behind schedule, with very little hope of catching up.

The dam breaks in a town near you, and massive flooding and mudslides take place. Fifteen of

your key functional people request to take off three days from the following week to help fel-

low church members dig out. Their functional managers, bless their hearts, have left the entire

decision up to you. Should you let them go?

Problems 486

11–32 Once the functional manager and project manager agree on a project schedule, who is

responsible for getting the work performed? Who is accountable for getting the work per-

formed? Why the difference, if any?

11–33 Discuss the validity of the following two statements on authority:

a. A good project manager will have more authority than his responsibility calls for.
b. A good project manager should not hold a subordinate responsible for duties that he

(the project manager) does not have the authority to enforce.

11–34 Below are twelve instructions. Which are best described as planning, and which are

best described as forecasting?

a. Give a complete definition of the work.
b. Lay out a proposed schedule.
c. Establish project milestones.
d. Determine the need for different resources.

e. Determine the skills required for each WBS task or element.
f. Change the scope of the effort and obtain new estimates.
g. Estimate the total time to complete the required work.
h. Consider changing resources.

i. Assign appropriate personnel to each WBS element.
j. Reschedule project resources.
k. Begin scheduling the WBS elements.
l. Change the project priorities.

11–35 A major utility company has a planning group that prepares budgets (with the help of

functional groups) and selects the projects to be completed within a given time period. You are

assigned as a project manager on one of the projects and find out that it should have been started

“last month” in order to meet the completion date. What can you, the project manager, do about

this? Should you delay the start of the project to replan the work?

11–36 The director of project management calls you into his office and informs you that one

of your fellow project managers has had a severe heart attack midway through a project. You

will be taking over his project, which is well behind schedule and overrunning costs. The

director of project management then “orders” you to complete the project within time and

cost. How do you propose to do it? Where do you start? Should you shut down the project to

replan it?

11–37 Planning is often described as establishing, budgeting, scheduling, and resource allo-

cation. Identify these four elements in Figure 11–1.

11–38 A company is undertaking a large development project that requires that a massive

“blueprint design tree” be developed. What kind of WBS outline would be best to minimize the

impact of having two systems, one for blueprints and one for WBS work?

11–39 A company allows each line organization to perform its own procurement activities

(through a centralized procurement office) as long as the procurement funds have been allo-

cated during the project planning phase. The project office does not sign off on these functional

procurement requisitions and may not even know about them. Can this system work effec-

tively? If so, under what conditions?

11–40 As part of a feasibility study, you are asked to prepare, with the assistance of functional

managers, a schedule and cost summary for a project that will occur three years downstream,

Problems 487

if the project is approved at all. Suppose that three years downstream the project is approved.

How does the project manager get functional managers to accept the schedule and cost sum-

mary that they themselves prepared three years before?

11–41 “Expecting trouble.” Good project managers know what type of trouble can occur at the

various stages in the development of a project. The activities in the numbered list below indi-
cate the various stages of a project. The lettered list that follows identifies major problems. For

each project stage, select and list all of those problems that are applicable.

1. Request for proposal
2. Submittal to customer
3. Contract award
4. Design review meetings
5. Testing the product
6. Customer acceptance

a. Engineering does not request e. The project–functional interface
manufacturing input for end-item definition is poor.

producibility. f. Improper systems integration has

b. The work breakdown created conflicts and a
structure is poorly defined. communications breakdown.

c. Customer does not fully realize the g. Several functional managers did
impact that a technical change will not realize that they were

have upon cost and schedule. responsible for certain risks.

d. Time and cost constraints are not h. The impact of design changes is
compatible with the state of the art. not systematically evaluated.

11–42 Table 11–8 identifies twenty-six steps in project planning and control. Below is a

description of each of the twenty-six steps. Using this information, fill in columns 1 and 2 (col-

umn 2 is a group response). After your instructor provides you with column 3, fill in the
remainder of the table.

1. Develop the linear responsibility chart. This chart identifies the work breakdown
structure and assigns specific authority/responsibility to various individuals as

groups in order to be sure that all WBS elements are accounted for. The linear
responsibility chart can be prepared with either the titles or names of individuals.

Assume that this is prepared after you negotiate for qualified personnel, so that you
know either the names or capabilities of those individuals who will be assigned.

2. Negotiate for qualified functional personnel. Once the work is decided on, the
project manager tries to identify the qualifications for the desired personnel. This

then becomes the basis for the negotiation process.

3. Develop specifications. This is one of the four documents needed to initially define
the requirements of the project. Assume that these are either performance or mate-
rial specifications, and are provided to you at the initial planning stage by either the

customer or the user.

4. Determine the means for measuring progress. Before the project plan is finalized
and project execution can begin, the project manager must identify the means for

measuring progress; specifically, what is meant by an out-of-tolerance condition and
what are the tolerances/variances/thresholds for each WBS base case element?

5. Prepare the final report. This is the final report to be prepared at the termination of
the project.

Problems 488

TABLE 11–8. STEPS IN PROJECT PLANNING AND CONTROL

A
c
ti

v
it

y

Description

C
o

lu
m

n
1

:

Y
o

u
r
s

e
q

u

e
n

c
e

C

o
lu

m
n

2
:

G
r
o

u
p

s
e
q

u
e
n

c
e

C
o
lu
m

n
3

:

E
x

p
e
r
t’

s
se

q
u

e
n
c
e

C
o
lu
m

n
4

:

D
if

fe
r
e
n

c
e
b

e
tw

e
e
n

1
&

3

C
o
lu
m

n
5

:
D
if
fe
r
e
n
c
e
b
e
tw
e
e
n

2
&

3

1. Develop linear responsibility chart

2. Negotiate for qualified functional

personnel

3. Develop specifications

4. Determine means for measuring

progress

5. Prepare final report

6. Authorize departments to begin work

7. Develop work breakdown structure

8. Close out functional work orders

9. Develop scope statement and set

objectives

10. Develop gross schedule

11. Develop priorities for each project

element

12. Develop alternative courses of action

13. Develop PERT network

14. Develop detailed schedules

15. Establish functional personnel qualifications

16. Coordinate ongoing activities

17. Determine resource requirements

18. Measure progress

19. Decide upon a basic course of action

20. Establish costs for each WBS element

(continues)

Problems 489

TABLE 11–8. STEPS IN PROJECT PLANNING AND CONTROL (Continued)

A
c
ti
v
it
y

Description

C
o
lu
m
n
1
:
Y
o
u
r
s
e
q
u
e
n
c
e

C
o
lu
m
n
2
:
G
r
o
u
p
s
e
q
u
e
n
c
e

C
o
lu
m
n
3
:
E
x
p
e
r
t’
s
se
q
u
e
n
c
e

C
o
lu
m
n
4
:
D
if
fe
r
e
n
c
e
b
e
tw
e
e
n

1
&
3

C
o
lu
m
n
5
:
D
if
fe
r
e
n
c
e
b
e
tw
e
e
n

2
&
3

21. Review WBS costs with each functional
manager

22. Establish a project plan

23. Establish cost variances for base case
elements

24. Price out WBS

25. Establish logic network with
checkpoints

26. Review base case costs with director

6. Authorize departments to begin work. This step authorizes departments to begin the actual
execution of the project, not the planning. This step occurs generally after the
project plan has been established, finalized, and perhaps even approved by the customer or

user group. This is the initiation of the work orders for project implementation.

7. Develop the work breakdown structure. This is one of the four documents required
for project definition in the early project planning stage. Assume that WBS is

constructed using a bottom-up approach. In other words, the WBS is constructed
from the logic network (arrow diagram) and checkpoints which will eventually

become the basis for the PERT/CPM charts (see Activity 25).

8. Close out functional work orders. This is where the project manager tries to prevent exces-
sive charging to his project by closing out the functional work orders (i.e., Activity 6) as

work terminates. This includes canceling all work orders except those needed to adminis-
ter the termination of the project and the preparation of the final report.

9. Develop scope statement and set objectives. This is the statement of work and is one
of the four documents needed in order to identify the requirements of the project.
Usually, the WBS is the structuring of the statement of work.

10. Develop gross schedule. This is the summary or milestone schedule needed at
project initiation in order to define the four requirements documents for the project.
The gross schedule includes start and end dates (if known), other major milestones,

and data items.

11. Develop priorities for each project element. After the base case is identified and
alternative courses of action are considered (i.e., contingency planning), the project

team performs a sensitivity analysis for each element of the WBS. This may require

Problems 491

assigning priorities for each WBS element, and the highest priorities may not
necessarily be assigned to elements on the critical path.

12. Develop alternative courses of action. Once the base case is known and detailed
courses of action (i.e., detailed scheduling) are prepared, project managers conduct
“what if” games to develop possible contingency plans.

13. Develop PERT network. This is the finalization of the PERT/CPM network and
becomes the basis from which detailed scheduling will be performed. The logic for

the PERT network can be conducted earlier in the planning cycle (see Activity 25),
but the finalization of the network, together with the time durations, are usually

based on who has been (or will be) assigned, and the resulting authority/-
responsibility of the individual. In other words, the activity time duration is a func-

tion not only of the performance standard, but also of the individual’s expertise and
authority/ responsibility.

14. Develop detailed schedules. These are the detailed project schedules, and are con-
structed from the PERT/CPM chart and the capabilities of the assigned individuals.

15. Establish functional personnel qualifications. Once senior management reviews the
base case costs and approves the project, the project manager begins the task of con-
version from rough to detail planning. This includes identification of the required

resources, and then the respective qualifications.

16. Coordinate ongoing activities. These are the ongoing activities for project execution,
not project planning. These are the activities that were authorized to begin in
Activity 6.

17. Determine resource requirements. After senior management approves the estimated
base case costs obtained during rough planning, detailed planning begins by deter-

mining the resource requirements, including human resources.

18. Measure progress. As the project team coordinates ongoing activities during project
execution, the team monitors progress and prepares status reports.

19. Decide on a basic course of action. Once the project manager obtains the rough cost
estimates for each WBS element, the project manager puts together all of the pieces
and determines the basic course of action.

20. Establish costs for each WBS element. After deciding on the base case, the project
manager establishes the base case cost for each WBS element in order to prepare for

the senior management pricing review meeting. These costs are usually the same as
those that were provided by the line managers.

21. Review WBS costs with each functional manager. Each functional manager is pro-
vided with the WBS and told to determine his role and price out his functional

involvement. The project manager then reviews the WBS costs to make sure that
everything was accounted for and without duplication of effort.

22. Establish a project plan. This is the final step in detail planning. Following this step,
project execution begins. (Disregard the situation where project plan development
can be run concurrently with project execution.)

23. Establish cost variances for the base case elements. Once the priorities are known
for each base case element, the project manager establishes the allowable cost vari-

ances that will be used as a means for measuring progress. Cost reporting is mini-
mum as long as the actual costs remain within these allowable variances.

24. Price out the WBS. This is where the project manager provides each functional man-
ager with the WBS for initial activity pricing.

25. Establish logic network with checkpoints. This is the bottom-up approach that is often
used as the basis for developing both the WBS and later the PERT/CPM network.

Problems 491

26. Review base case costs with director. Here the project manager takes the somewhat
rough costs obtained during the WBS functional pricing and review and seeks man-

agement’s approval to begin detail planning.

11–43 Consider the work breakdown structure shown in Figure 11–19. Can the project be

managed from this one sheet of paper assuming that, at the end of each month, the project man-

ager also receives a cost and percent-complete summary?

11–44 During 1992 and 1993, General Motors saved over $2 billion due to the cost-cutting

efforts of Mr. Lopez. Rumors spread throughout the auto industry that General Motors was con-

sidering a plan to offer subcontractors ten-year contracts in exchange for a 20 percent cost

reduction.

These long-term contracts provided both GM and the subcontractors the chance to develop

an informal project management relationship based on trust, effective communications, and

minimum documentation requirements.

a. Is it conceivable that the cost savings of 20 percent could have been realized entirely

from the decrease in formalized documentation?

b. Philosophically, what do you think happened when Mr. Lopez departed GM in the
spring of 1993 for a senior position at Volkswagen? Did his informal project man-

agement system continue without him? Explain your answer.

11–45 During the recession of 1989–1993, the auto industry began taking extreme cost-

cutting measures by downsizing its organizations. The downsizing efforts created project

2000 2001

FIGURE 11–19. Work breakdown structure.

PROJECT I. M.P.S.

TASK I. SYSTEM OVERVIEW

II. SYSTEM DESIGN SPEC .

III. PROGRAM SPEC S.

IV. PROGRAMMING & TEST ING

V. IMPLEMENTATION AND

TRAIN ING

PROJECT II. SHOP CONTROL

TASK I. SYSTEM OVERVIEW
II. SYSTEM DESIGN SPEC .
III. PROGRAM SPEC S.
IV. PROGRAMMING & TEST ING
V. IMPLEMENTATION AND
TRAIN ING

PROJECT III. STACKER

TASK I. SYSTEM OVERVIEW
II. SYSTEM DESIGN SPEC .
III. PROGRAM SPEC S.
IV. PROGRAMMING & TEST ING
V. IMPLEMENTATION AND
TRAIN ING

A
P

R
IL

M
A
Y

J
U

N
E

J
U

L
Y

A
U

G
.

S
E

P
T

.

O
C

T
.

N
O

V
.

D
E

C
.

J
A

N
.

F
E

B
.

M
A

R
.

A
P
R
IL

M
A
Y

J
U
N
E

J
U
L
Y

Problems 491

management problems for the project engineers in the manufacturing plants.

With fewer resources available, more and more of the work had to be

outsourced, primarily for services. The manufacturing plants had years of

experience in negotiations for parts, but limited experi- ence in negotiations for

services. As a result, the service contracts were drastically overrun with

engineering changes and schedule slippages. What is the real problem and

your recommenda- tion for a solution?

11–46 When to bring the project manager on board has always been a

problem. For each of the following situations, identify the advantages and
disadvantages.

a. The project manager is brought on board at the beginning of the
conceptual phase but acts only as an observer. The project manager

neither answers questions nor provides his ideas until the
brainstorming session is completed.

b. When brainstorming is completed during the conceptual phase,
senior management appoints one of the brainstorming team members
to serve as the project manager.

Planning