<< . .

. 8
( : 16)



. . >>


Figure 5-19. Periodic cost spread sheet.




Figure 5-20. Cumulative cost spread sheet.




Figure 5-21. S-curve/cost line graph.
Specific Risk Factors
Schedule
• Tasks on the critical path
• Tasks that have several predecessors
• Tasks that have minimal float
• Optimistically estimated tasks
• Tasks reliant on external dependencies, such as vendor shipments
• Major milestones
Resources
• Tasks with one individual working alone
• Tasks with many people assigned
• Tasks using scarce resources
• Underskilled or unqualified people
• Illness and turnover
Budget
• Uncertainty of funds
• Shifts in budget priorities
• Uncertain resource costs
Scope
• Uncertainty of new product development
• Dynamics of customer requirements
• Availability of tools and/or techniques
• Large number of defects

Follow these key guidelines for developing contingency plans:
Guidelines for Contingency Planning
Revise the schedule by:
• Negotiating deadlines of high-risk tasks to accommodate potential slippage
• Scheduling tasks that can be postponed or canceled if necessary later in the project
• Conservatively estimating durations of tasks on the critical path
• Generating a schedule that takes the contingency into account
Revise plans by:
• Reassigning strong staff to high-risk and critical path tasks
• Assigning a person, if only minimally, as a backup to any tasks where the loss of a team member
would be damaging
Make and document backup plans including:
• Preventive actions that will be taken to reduce or remove risk
• Contingent actions that can be implemented should a problem occur
• The circumstances that would trigger each contingency plan into action




Figure 5-22. Contingency planning worksheet.
For each risk, ask the following questions and then assign a value of high, medium, or low: (1) What is the
probability this risk will occur? (2) What would be the impact if this risk should occur? For risks with high
rankings for either impact or probability, take preventive steps by making revisions to the schedule or
adjusting resource assignments or negotiating a contingency fund and by generating backup contingency
plans. For each backup contingency plan, specify the circumstances that would trigger the plan into action
(see Figure 5-22).
Contingency is essential to good project management; without it, corrective action cannot be taken when
problems are encountered in the execution of the work. Keep in mind that it is not prudent to hide or bury
contingency within the estimates of budgets or durations, or the budgets of the tasks. Contingency should be
based on the amount of risk associated with the project, and a risk assessment must be prepared as the project
plan is being developed. Some risks have the potential to affect the entire project, others might affect only one
phase of it, and still others might affect only a single task. Your goal should be to return the contingency to
the general funds of the organization at the conclusion of the project. Unexpended contingency increases the
profitability of the project or the return on investment associated with the project.


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 6
Managing Project Change
Change affects our lives dramatically, ruining our plans, causing us to destroy completed work, and forcing us
-----------
to plan, replan, replan, and replan again. We work, rather consistently, to discourage it, and yet it is inevitable.
An efficient change management process can make the difference between project success and project failure.
Changes to the project will inevitably occur in the baseline of the schedule, resource allocation, and budget, as
well as in the scope of the end product. These changes must be analyzed, their impact determined, and
corrective action taken when necessary. In this chapter, we focus on two major types of change that affect
projects: scope changes and baseline changes. We discuss the different sources for each of these changes and
recommend procedures for successfully managing these all-important dynamics of your project.

Scope Changes
Sources of Scope Changes
Changes in the scope of a project refer to the additions, modifications, or deletions made to the end product or
service. In most organizations, changes in scope occur within the areas of the project requirements and design,
as well as the overriding technology, business cycle, and, last but certainly not least, personnel:
• Requirements changes: This common type of scope change originates with the client, who may need
an additional capability or feature that was not specified in the original scope definition. In most cases,
clients are not attempting to cause extra work. Rather, they probably have not considered this particular
feature before and now are placing great importance on including it within the scope of the project.
• Design changes: During the effort, the designers may find a much better way to produce or provide
the end product. Usually this type of change occurs within the natural flow of idea generation and
testing. As in the case of requirements changes, designers may place great importance on including the
design change within the project scope.
• Technological changes: As a project evolves, new types of technology in equipment, materials, or
expertise may become available. These technological discoveries must be addressed in terms of
changes to the original project scope.
• Business changes: Nothing stands still, especially time. And with the passage of time, circumstances
within the business environment change. If a competitor announces a new product or the value of the
dollar declines, for example, the project scope can be affected to a greater or lesser degree. There is a
need for proactive response mechanisms to adjust the project scope.
• Personnel changes: As circumstances change, so do people. The client may leave, additional clients
may be brought into the loop, or the project manager may be pulled off the project. With each of these
possible changes come adjustments to project requirements, design, technology, and business
perceptions.
The initiation of changes in scope due to any of these sources must be tracked and evaluated by employing a
sound change control procedure. If change control is not in place, you become so involved in taking care of
bits and pieces that the original project outcomes (time, dollar, and/or resource baselines) cannot be achieved
as planned. Once baselines start slipping, questions arise that you must address in terms of proving who is
responsible for the overages caused by the scope changes. To cope with these issues, you need a mechanism
for change control.

Procedures for Managing Scope Changes
Scope changes have an enormous impact on the project because they deal with the end product or end service.
Change control procedures should be based on three objectives to facilitate efficient and effective scope
changes:
Key objectives for Change Control
1. To define what the project manager can and cannot do when a change of scope occurs
2. To establish an agreed-upon process for submitting the change and evaluating its impact on the
current project baseline
3. To show how to approve and disapprove”based on sound business premises”the time, effort,
and dollars required for the change

Five major steps are necessary for accomplishing these three objectives.
Step 1: Either you as project manager or the person requesting the change of scope completes the section of
the change control form (Figure 6-1) that describes the change (what) and its benefits (why). We suggest that
the person requesting the change complete this section since he or she is most familiar with the full scope of
the request. In some cases (for example, within politically sensitive project environments), the project
manager may need to complete the form and reconfirm with the client.
Step 2: The change controller (the project manager or a team member) assigns the document a change
number, indicates the date the change control form was received, and logs the change control request on a
change control log (Figure 6-2), which documents the change control number, the date submitted, a short
description of the change, and the department and telephone number of the person requesting the change. The
change controller then places this change on the agenda for the change control committee to address in Step 3.
Step 3: The change control committee is composed of members from the technical and the business arenas, as
well as a decision maker from the organization who will be paying for the investigation and implementing the
requested change. The committee should meet frequently to review pending change control forms and to
decide whether the change of scope warrants further action by the investigation team. If the change of scope is
canceled, the procedure stops here. If the change of scope is deemed worthy of further investigation, the
committee agrees to its funding. The members sign and date the change control form and assign it to the
appropriate individuals who will perform Step 4. The change controller then updates the change control log,
noting the approval date for the change control investigation and to whom it has been assigned.




Figure 6-1. Change control form.
Figure 6-2. Change control log.

Step 4: The investigation team, which may be comprised of the same members as the change control
committee, analyzes the impact this change of scope will have on the project and makes appropriate
recommendations. The length of this team™s investigation varies according to the nature of the change
requested. The team may find that the impact will be to lengthen the target date, to require additional
resources, to extend the budget, to have political ramifications, or to place the organization in a position of
jeopardy. These impacts suggest negative implications, but this is not always the case. A change of scope can
have a positive impact, such as shortening the duration of the project or improving the end product. Keep in
mind that scope changes submitted early in the project life cycle are more likely to have less negative impact
upon the baseline. In other words, if the change is requested during the design effort, there will probably be
fewer adverse effects than if the change surfaces during production/development. The investigation team
completes its assessment and returns the change control form to the change controller, who is then responsible
for getting the request on the agenda for the next approval committee meeting (Step 5).
Step 5: The approval committee is made up of the same members as the change control committee with the
possible addition of other appropriate decision makers. This committee evaluates the potential impact of the
scope change, as reported by the investigation team, and decides whether to approve the request. The decision
should take into consideration not only the positions of each of the individual contributing departments, but
also the impact on the organization as a whole. If a change is approved, the approval committee may also set
priorities as well as sign off on the document. The project manager is given a copy, and the change controller
completes the log designating approval or disapproval, the date, and to whom the work has been assigned.
This procedure is appropriate for large changes of scope that have major ramifications for the project but can
be too formal for small, seemingly insignificant or discrete change requests. An alternative is a one-page
document that describes the change of scope requested and compares the current expected completion date,
effort exerted, project personnel, and project costs with the changes that would occur in these areas if the
change of scope were implemented (Figure 6-3). There is space in the document for recommendations and for
signatures of appropriate personnel. If only one line is required to document the change of scope, a change
control log sheet (Figure 6-2), describing who made the request for the change of scope, who approved it,
who accomplished it, and the impact of the change, is adequate.


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Baseline Changes
Title


Sources of Baseline Changes
Now let™s look at the ways in which you and the project team can identify and properly record all
-----------
requirements to change the project baseline. Project baseline specifically refers to the project specifications,
applicable standards, schedule target, cost target, and resource and asset utilization targets. Baseline changes,
which deal with the project plan, are easier to anticipate than scope changes because they can be tracked
against actual performance by the project manager, functional manager, and team members.
There are four primary sources of baseline changes to the project (Figure 6-4): client driven, regulatory
driven, externally driven, and internally driven, each with a number of different subtypes. Some types of
change commonly occur and can be identified and acted upon very quickly. Others are far more subtle and
can sneak up on the project team, causing unacceptable cost increases and schedule delays.
In some organizations, the project team is responsible for monitoring the potential for change from various
sources. Other organizations have work units established specifically to monitor sources of change and alter
the project plans when something is afoot that might affect them. In Chapters 7 and 8, we discuss how these
baseline changes can be monitored through project control concepts and techniques, respectively. For now,
let™s take a closer look at each of these four sources of baseline changes and their accompanying subtypes.

Client Driven
The client is the owner, or future owner, of the product being developed by the project team. You need to
know who the client is”and who is authorized to speak for the client in dealing with the project team.
Client-driven change occurs for a variety of reasons, but there are three basic interrelated issues for it:
1. Scope: All facets of the end product are of concern to the client. At any time during the project
cycle, the client may alter the characteristics of the end product by initiating a change to the scope.
(When we talk about scope changes here, we are focusing on baseline changes that are brought about
by the client™s desire to alter the characteristics of the end product.)
Figure 6-3. Project review chart.




Figure 6-4. Sources of change to the baseline.
2. Cost: The client is concerned with total cost as well as periodic cost (fiscal year, quarter). The client
may find it necessary to alter either, thereby changing the baselines given to the project team. While it
is most common to think in terms of reducing the cost of the project, the client may sometimes seek to
increase the cost. For example, the client may be faced with a budgetary surplus for a quarter and may
want to increase the cost of the project during that quarter as a means of dealing with the surplus. The
client may be looking at cost exclusively or at cost-schedule relationships.
3. Schedule: The client is often concerned with completion dates and with interim milestone dates. For
a variety of reasons, the client may seek to alter these delivery dates. While it is most common to deal
with a client who is seeking to advance the date(s), it is not unheard of to receive a request to delay the
delivery of the end product, often for cost-related reasons.

Regulatory Driven
Regulatory-driven changes originate with organizations or individuals having the authority to impose
mandatory directives on the project team. It is best to think of regulatory change as a matrix (see Figure 6-4).
On one side of the matrix are international, national, state, and local sources of change. On the other side are
governmental, quasi-governmental or institutional, corporate, and divisional sources of change. Thus, there is
a sixteen-cell matrix of potential regulatory changes to the project baseline.
1. Governmental change: The top left cell of the matrix is governmental change of an international
nature. For example, the European Economic Community recently instituted changes in the
requirements for registering pharmaceuticals, a change that directly affects the growing number of
project teams in the pharmaceutical industry. The next cell, national governmental change, may be the
most obvious source of regulatory change, but it is also the most complex because a large number of
federal government regulations affect many organizations. A common question regarding national
govenmental regulations is whether a particular agency has the right to regulate certain types of work
and production effort. Obviously, the answers are as varied as the types and natures of the regulations
within particular industries.
Many state governments duplicate and expand upon these national regulatory functions. For example,
project teams in environmental industries frequently deal with the federal Environmental Protection
Agency as well as a state equivalent, such as the Department of Environmental Quality. The most
common example of local government regulations is building codes. These codes typically vary from
municipality to municipality and must be complied with by project teams in or affiliated with the
construction industry.
2. Institutional change: The next row of cells deals with institutional or quasi-governmental (affiliated
with the government) regulators that affect the project baseline. The first cell in this row encompasses
international institutional regulators. One of the most prominent examples is the International
Consultative Committee on Telephony and Telegraphy (ICCTT), which sets hardware and software
standards for voice and data communications that all telephone companies and most communications
corporations must comply with. The next cell deals with national institutional regulators, such as the
Underwriters Laboratories, Inc., a profit-making corporation of the American Society for Testing and
Materials (ASTM), which is a quasi-governmental agency. The third cell refers to state institutional
regulators, such as Connecticut™s Historical Preservation Society, which may have an impact on the
construction project plans of corporations or homeowners. The final cell in this row contains local
institutional regulators, such as the architectural control boards established by a number of cities or
local zoning commissions that determine what use may be made of the land within a municipality.
3. Corporate change: The third row of cells deals with corporate regulators. The number of relevant
cells in this row depends on the size and global reach of the corporation. The first cell in this row refers
to international corporate regulations that emanate from the organization™s world headquarters. In the
second cell are national corporate regulations”those issued by the office responsible for all operations
of the corporation within the country. The third cell includes regulations of the local operating unit of
the corporation, such as a division. Regulations that come from the plant or facility in which the project
team is situated comprise the remaining cell in this row.
4. Divisional change: The final row of cells in the regulatory matrix refers to the division or strategic
business unit in which the project team is located. The four cells of international, national, state, and
local regulations are crossed with the appropriate business unit.
Not all of these regulatory cells will affect every project. The project team should first identify the cells with
the potential to affect the project baseline and then monitor any regulatory changes.


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Externally Driven
Title

Externally driven change emanates from the environment in which the project team™s organization operates.
There are three types of environmental change that can affect the project: economic, political, and social.
Economic change can affect the way the project progresses rather than the end product itself. For example, the
----------- baseline of a hardware project may change because the cost of computer chips has tripled over the recent
quarter or the chips are not available. Politically driven change might be caused by an event or circumstance
that alters the customer or consumer environment for the organization (e.g., the impact of the Valdez oil spill
on Exxon). Finally, there is socially driven change”for example, when it became unacceptable for businesses
to have dealings with the Republic of South Africa.

Internally Driven
Internally driven changes are typically forces on the project team because of altered conditions or problems
within the organization. There are several different types of change within this general area:
1. Change necessitated by scope or technical problems: For example, a project team may have
difficulty meeting the technical objectives of the project due to organizationwide changes in
information systems processing. The team therefore may need to make technical modifications. If the
organization is unable to deliver a product that meets technical objectives, the client should be
approached in an attempt to change the scope of the project.
2. Change necessitated by problems in meeting the schedule: These problems may be associated with
or independent of resource considerations. Regardless of the source, when an organization knows that it
cannot meet the delivery date for an end product, renegotiating the project baseline with the client is
appropriate and necessary.
3. Change because of cost problems: When an organization forecasts that the cost at completion of a
project will exceed the maximum amount the client is willing to invest, the baseline must be altered.
4. Change because of resource demands: Either other projects and/or work units or the project team
may be creating excessive demands for resources that the organization cannot accommodate. In either
case, the schedule and/or the cost baseline of the project will more than likely have to be renegotiated.

Procedures for Managing Baseline Changes
As much as we would like to think of baselines as static, they are not. They will change as the project evolves
because of these various reasons:
Sources of Baseline Changes
• Time targets will not be met.
• Tasks will slip their deadlines.
• Milestones will be missed.
• Jobs won™t always get started on time.
• Resources will not be available as planned.
• Equipment capacity will be overestimated.
• People will not produce at peak performance.
• Budgets will be either overspent or underspent (depending on the degree of adherence to the
schedule and resource allocations).
• Work accomplishment will exceed or not meet with the plan.

There are three general steps for managing baseline changes, and they will help you manage your time more
efficiently:
Step 1: Ensure that baseline changes are committed to by one person”you! As project manager, you are the
focal point for all changes because you have total perspective or overview of the project and can evaluate the
total impact of the change on the balance of the project baseline. In some cases, you must approve the change.
In other cases, you merely must be informed of it.
Step 2: There is some discussion as to whether project managers should be informed of every change or just
of changes that will have an important impact on the project. For example, if a task that has three weeks of
float is going to slip two days, do you have to be informed? Probably not. However, project team members
should know the point at which you must be informed of baseline changes. This information should be
communicated to you before the slippage in the task creates a new critical path. If there is any concern that
uncontrollable baseline changes may occur, then follow this rule: All changes must be automatically
communicated to the project manager.
Step 3: Tracking baseline changes can be a laborious, time-consuming effort. As a result, establish rules for
timing the submission of them. For example, they should be submitted at specified times (e.g., each Tuesday

<< . .

. 8
( : 16)



. . >>