<<

. 3
( 5)



>>

• 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
morning) or discussed at biweekly status review meetings. Discourage project team members from calling or
writing to you whenever they wish to announce baseline changes.
Track baseline changes for three reasons: to wave red flags, to document and analyze problems, and to
negotiate for assistance in the most effective way. When your project gets into a crisis, do not hesitate to
address baseline changes. It is time-consuming to rework the plans, reissue them, and deal with the questions
as to why the baselines are not consistent with the plan. However, this is the juncture at which you as a project
manager need to take a bold, calculated view of reality and its impact on the balance of the project.
Establish your own baseline change procedure by following these guidelines:
Key Guidelines for Establishing a Baseline Change Procedure
• The person who is responsible for processing baseline changes should also coordinate the change
among project team members.
• Attempt to make baseline changes on a scheduled basis rather than at random.
• Do not ignore the formal baseline change process when the project gets into a crisis.
• Communicate the changes that have been made to various levels, the rest of the team members, and
the client.
• Establish predefined authority and approval points. For example, you can authorize slippage in a
task as long as it has float, but go to the client before slipping the entire project completion date.
• Define reserves in time, resources, or dollars.
• Allow changes to be made by authorized personnel only. The functional manager can authorize a
change in personnel, but a team member can™t arbitrarily trade off with someone else.
• Consider possible side effects before approving any change.
• Study alternatives. Work within the constraints given. Ask for tradeoffs only when absolutely
necessary.
• Don™t be afraid to change the baseline when necessary.
• Don™t overreact. Wait for the baseline change to take effect and its impact to be evaluated before
implementing another change.
• Document the change thoroughly: when it was made, why, and by whom it was approved. This will
help explain the rationale of decisions later and will help build a better history base for future
reference.
• Track the change to ensure that there are no unanticipated ramifications.



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 7
A Model for Project Control
In this chapter, we address an old project management adage: “Plan the work-now work the plan.” Once a
-----------
project has been properly defined, carefully worded in a scope document, and detailed according to a plan,
you as project manager enter into what is commonly referred to as the project management control cycle. The
key questions you must answer now are: Where are we? Where do we want to be? How do we get there? Are
we getting there?
In more technical terms, the question “Where are we?” asks for an assessment of the current status of the
project. “Where do we want to be?” asks for a comparison of the actual progress made against the baseline
project plan. “How do we get there?” asks for a consideration of possible corrective actions that could put the
project back on track, if necessary, or help keep it there. And “Are we getting there?” asks for an analysis of
the impact these corrective actions will have or are having on the project.
We first look at the transition between the planning process and the controlling process. Next, we discuss the
differences between formal and informal control, which leads into a discussion of what specifically belongs in
a controlling model. We also provide a series of guidelines to support the five stages of the controlling
process: updating the status, analyzing the impact, acting on the variances, publishing the revisions, and
informing management.
The last part of the chapter discusses “who”: who should be responsible for what parts of the controlling
process. The team members, of course, have a role within the process. What is that role? And is there a
rationale for employing project control specialists? What might they contribute to this process?

Transition From Planning to Controlling
A project manager does not stop planning at 5 P.M. one day and commence controlling the next morning at 9
A.M. without orchestrating the environment so that the project can be managed ” that is, so that the relevant
parties are involved and aware of the rules. Four steps belong on your transition checklist:
Transition Steps From Planning to Controlling
1. Validate plans.
2. Obtain sign-offs and freeze plans.
3. Resell the benefits of project management.
4. Create a project notebook.

Step 1: Validate plans. Before issuing the final set of plans, ensure that the plans appear to be reasonable.
Figure 7-1 provides a list of items you may want to consider. Add more items as you see fit. Validating plans
also includes updating status since work on the project may have commenced prior to the completion of the
planning.
Step 2: Obtain sign-offs and freeze plans. Sign-off procedures are a very important part of the process. More
than likely, there will be questions from those who must approve the plan. There will be fewer questions if
you have involved all the parties during the development of the plan; formatted the plan as clearly and as
professionally as possible; set up a formalized approval process; provided time for approval; and
communicated, communicated, communicated.




Figure 7-1. Validation of plans: project management system, general purpose.
In many organizations it is difficult to get clients, functional managers, and even team members to sign off or
to freeze the plans. They are afraid that their signature will be held as a club over their head. If they change
their minds, they see the plan, now frozen, as an impediment. Explain that an approved plan as the baseline is
a prerequisite to controlling a project. Remember that the baseline is valid at the moment it is approved; is not
set in concrete; should be considered a flexible management tool; is the basis for a warning signal of potential
problems looming ahead; and can be renegotiated with the proper documentation and professional
presentation.
Step 3: Resell the benefits of project management. At this point in the project™s evolution, it may be important
to resell the benefits of project management. Those involved have slogged their way through technical and
political issues in order to produce the plan; they have exerted time and effort, and finally the long-awaited
moment has arrived for the project to get underway ” at least the meaningful part of the project, which in
their minds is the design and development of the end product. They may need encouragement that all their
effort was not wasted and that these plans will help support them during the upcoming control process. The
following benefits may help sustain that buy-in and commitment:
Benefits of the Project Plan for the Control Cycle
• The plan ensures that no major tasks have been forgotten.
• The plan indicates clearly the assignment of responsibility, accountability, and authority.
• The plan predefines the interdependencies of tasks one to another, and thus functional
interdependencies as well.
• The plan becomes a yardstick against which to measure status and, ultimately, to judge the success
or failure of the project, the project manager, and the project team members.
• The plan, which will now be used as a monitoring, tracking, and controlling tool, becomes a vehicle
for communication and control.

Step 4: Create a project notebook. If you have not already done this, take some time before the controlling
process begins to organize the project notebook. Set aside sections for the project definition, communication
plan, task descriptions (work breakdown structure), estimates of each task and the background rationale, an
ongoing list of assumptions, an ongoing history log of change control and baseline changes, status reports,
and project summary (which will be produced at the end of the project).

Formal and Informal Control
The project plan is complete. It has been presented to senior management (and perhaps a client) and has been
approved. Work on the project is about to commence. It is time to ensure that the change management
procedure is in place and being adhered to by both client and project team. And it is time to define how you
will control the work during the project™s execution.
A common belief is that formal project control, which includes status reporting at the end of a week, month,
or accounting period, is the most effective means of controlling the project™s progress. This is not the case.
The most effective control is exercised daily (or almost daily) through your interaction with project team
members. A formal control, at the close of a week, month, or accounting period, serves other purposes.


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



Performing Informal Project Control
Title

Informal control is not a new idea. For years, construction project managers have walked the job, observed
work in process, and talked to the personnel doing this work. In 1982, Tom Peters and Bob Waterman
popularized the concept, which they labeled “management by wandering around,” in their book, In Search of
----------- Excellence.1 Informal control has a number of benefits:
1In Search of Excellence: Lessons from America™s Best-Run Companies (New York: Warner Books, 1982).

Benefits of Informal Control
• You learn a lot more than you do by sitting at your desk.
• You meet people in their habitat, where they may be more open and honest than they are in your
office or a conference room.
• You are highly visible to all project staff, not just your direct subordinates. You are more of a team
member.
• Your team will be delighted to explain their latest successful efforts. Nothing begets success like
success. The more you make them feel good about their accomplishments, the more they will try to
accomplish.
• You learn of brewing problems faster than waiting for them to appear on a status report or in a
meeting.
• You develop a sixth sense for what is normal within the team and then can discern potential
problems.

There is one caution: resist the urge to micro-manage by giving direction on the spot or skipping a level of
management by making decisions that are the responsibility of someone else in the project team. You
undermine the project organization you yourself established and give mixed messages to the project team as
to whom they are to follow.
Under most circumstances, informal control should be performed on a daily basis or as close to it as possible
given your schedule. Informal control is the interaction between you and your team members, during which
you have an increased awareness of the project™s current condition, in addition to items that need immediate
attention. If you do not have time to perform informal project control, then the project will suffer.
As you interact with your team, its members can ask questions and present problems. Informal control should
have the effect of increasing the team™s accessibility to you.
When performing informal control, you are forming a mental image of the project™s status or condition and
comparing this image to the project plan. You are also forming a mental image of the project™s future: a
forecast that is used to determine if the project is in trouble in any way. From this mental comparison, you can
determine if there is a need for corrective and/or preventive actions.
Corrective and/or preventive actions may be taken as part of the process of informal control. As you work
with project team members, solicit potential solutions to current problems, evaluate them with the team, and
take any necessary action. Furthermore, you can use informal control as a means of evaluating the
effectiveness of previously implemented solutions to problems. The image of the project™s condition that you
form during informal control is carried over to the formal control process.
Your accessibility is the key to informal control. If you are inaccessible, you won™t learn of issues that are in
need of attention.

Performing Formal Project Control
Formal project control is a newer concept than informal control, and it™s more of a paper than a mental
exercise. Formal control can be performed by week, month, or accounting period through the use of project
reports. Be careful that you don™t perform formal control too frequently, since the time and effort involved in
it can prevent you from performing frequent informal control.
In formal project control, you are gathering data about recently completed tasks as well as in-process tasks.
These data are used to produce status reports that indicate project performance up to the control cycle cutoff
date and to prepare analysis or forecast reports based on experiences in performing the work to date.
These status and analysis reports can serve as the basis for negotiating preventive and corrective actions in
dealing with problems being experienced in the execution of the work. Once the required preventive or
corrective actions have been taken, status and analysis reports incorporating those actions are used as the basis
for preparing summary senior management and client reports. Thus, the periodic reports give you the
information necessary to keep all concerned parties informed of the project™s condition.

Formal and Informal Control: A Comparison
The steps in formal and informal control processes are the same: data are collected concerning recently
completed tasks as well as tasks underway; status reports (historical in nature) are prepared either mentally or
on paper and are used to forecast future performance on the project; these forecasts form the basis for
determining the need for corrective or preventive actions, which are then negotiated between project manager
and project team members, and possibly with the client.
The most obvious differences between formal and informal control are medium, effort, and frequency. The
medium for informal control is the mind (although with user-friendly microcomputer-based project
management software, often project managers make copies of the most recent plans and assess the impact of
variances on the screen as well as in the mind).
The effort associated with informal and formal control depends in part on the state of the project. In both
types of control, less effort is required if the project is in good condition and being accomplished in
accordance with the plan. If the project is in trouble, more effort is required by both project manager and
team. The monthly effort associated with informal control can be measured in minutes per day. Monthly effort
connected with formal control is measured in hours per month, with most of the work occurring shortly after
the close of the formal reporting period. In reality, informal control may require as much effort as formal
control or even more, but the effort is spread out.
Frequency of informal control can be determined by the project manager, depending on time constraints and
the general condition of the project. In most cases, it will occur daily or almost daily. The frequency of formal
control is determined by management and the client, who dictate the intervals between the formal status
reports they expect to receive. In most cases, the formal control period is by month or accounting period.
In order to reconcile the results of formal and informal control, compare the status and analysis reports to the
mental image of the project condition you have formed during informal control. The reports and the image
should be consistent with each other, and there should be no surprises in the formal status and analysis
reports. If there are, you need to increase the frequency of informal control.


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



Relative Effectiveness of Formal and Informal Control
Title

To determine the relative effectiveness of formal and informal control, it is necessary to make several
assumptions. Let™s consider a case in which the organization performs formal control on a monthly basis and
the project manager, who has a wide range of responsibilities, performs informal control only once every
----------- three or four days. Assume that these broad responsibilities make it difficult for project team members to get
the project manager™s attention other than during formal or informal control interactions.
A problem in performing project work occurs on the sixth working day of the period. The team member
experiencing this problem has previously met with frustration in trying to contact the project manager.
Therefore, the team member makes no attempt now to communicate directly and immediately with the project
manager.
Under the formal control scenario, the project manager learns of the problem in the status report for the
current period, which (optimistically) is prepared on the fifth working day of the next period. In that case,
somewhere between twenty-seven and thirty calendar days have passed between the onset of the problem and
the project manager™s awareness of it. During that period, if the project manager is lucky, the problem has not
become worse. On the other hand, the situation may have become considerably worse. The team member has
been trying to solve the problem but lacks the necessary authority and resources. Now that the problem has
finally been brought to the attention of the project manager, it will be dealt with effectively ” but at higher
cost in money and resources.
Under informal control, the project manager learns of the problem within one to three days after the team
member has discovered it and can immediately exert some authority and resources to solve the problem. Since
the problem has had little time to ripen, dealing with it may not be costly. The impact of the problem on the
end date and cost at completion of the project will be less, and the organization will be better off because the
problem has been solved in less time and at lower cost.
Both informal and formal control processes are needed, but informal can be much more important to effective
project management.

Creating a Sense of Importance and Consequence
As you employ both the formal and the informal project control approaches, be sure to create a sense of
importance and consequence from the very beginning of the project. We know that on Day 1, eighteen months
looks like a long way off. However, if you are complacent about getting the project done, the rest of the team
will be, too. You can generate a sense of urgency in several ways:
Ways to Generate a Sense of Urgency
• Have a high level of focused energy from Day 1.
• Let the team know you are looking at the big picture as well as details.
• Hurry to get ahead (don™t wait to catch up).
• Hold frequent staff meetings at which you exhibit this sense of importance and consequence.
• Hold daily meetings as needed where the action is.
• Give a firm time limit for problem solution.
• Post schedules, highlighting slippages in prominent, visible areas for all to see.

Performing formal and informal control is not an either-or situation. Both are required for effective project
management. But remember that they serve different purposes. Problems surface quickly with informal
control, which affords the opportunity to deal with them before they ripen. Formal control checks the
adequacy of informal control and confirms what the project manager already knows about the project. It is the
basis of developing and delivering summary status reports for senior management and the client. To be
successful as a project manager, you must do both, and do them well.

A Five-Step Model for Project Control
Tracking and managing the project means taking steps to ensure that actual performance conforms to the
project plan. The basic tools for controlling the project are the project definition (which serves as a contract
for measuring the success of the project, the end product, and the project manager); the project plan, schedule,
resource plan, and budget; and status reports, which indicate work in progress and problems. The project plan
serves as a road map for the project team™s efforts; it sets expectations. Your job is to see that those
expectations are met. Let™s look at each of the five stages in the controlling process:
Five-Step Model for Project Control
1. Update the status.
2. Analyze the impact.
3. Act on the variances.
4. Publish the revisions.
5. Inform management.

Step 1: Update the Status
Use the systems you™ve put into place to track work accomplishment and costs and to assess the quality of the
work being done. Also look at the morale and productivity of the project team. Your job as the project
manager during the controlling process is to concentrate on the progress of the schedule, costs, quality, human
resource allocation, fixed costs, materials, and supplies.
Updating the status focuses on collecting the information necessary to assess performance on the project and
posting the information. The data, collected from the members of the project team, the cost accounting
system, and the time reporting system, are then posted so that they can be compared to the plan. The nature of
the posting process depends on the manual or automated project management system being used.
Data requirements vary; completed tasks, tasks in process, and future tasks each must be examined somewhat
differently. The schedule, resource utilization, cost, and achievement status reports are produced as a result of
the updating. Let™s first discuss mechanisms for collecting data and then how to decide the form and
substance of status reports.

Confirm or Set Up Mechanisms for Collecting Data
Mechanisms need to be in place to collect data for schedules, deliverables, costs, and problems. This
information can come from several sources:
Sources for Collecting Data
• Project manager interviews: The project manager interviews each member of the team to determine
the status of the tasks to which each member is assigned.
• Person holding prime responsibility: Task owners update the project baselines for which they are
accountable and submit them to the project manager, who then prepares a consolidated project status
report.
• Status review meetings: All members of the team inform the project manager and each other of
tasks begun, tasks completed, tasks behind schedule, and any potential problems.
• Personnel time reports, time cards, or time logs: Project team members fill out the reports. The data
are correlated and consolidated in a master status report.



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



These four sources do not excuse you from walking around or from maintaining one-on-one communication.
Title
If there is no mechanism in place, you must develop a medium for collecting data. If you design your own
data collection forms:
• Make them simple and easy to complete.
• Ensure that all the information is pertinent.
-----------
• Confirm that those preparing the information understand how it will be utilized and the need for their
input.
• Make sure people are aware of its end use.
• Make sure there are consistent “as-of ” dates.

Decide on Status Reporting Forms
In order to keep everyone informed, you will issue status reports. A number of key questions need to be
answered when making decisions concerning these reports:
Questions for Status Reports
• What will they look like? Graphic or lists? Narrative or pictures?
• Who will be on the distribution list?
• Who will receive differing levels of detail?
• How frequently will the reports be issued?
• What will the reports be used for (merely for communication? as the basis for progress reporting
meetings? as action tools to manage the project?)?
• What image do you want to portray?
• How easy is it to update the reports? (The easier, the better.)

There is a good rule of thumb: Project team members at a lower level of detail require data on a more frequent
basis and usually prefer a list format. Management prefers graphs presented to them on a less frequent basis
with a short executive summary and at a higher level of detail (see Table 7-1). Team members need
information different from that given to management:
Information for Project Team Members on Status Reports
• What you want them to do
• What authority you have delegated to them
• What results you expect
• What help they will have
• What rewards (consequences) they will be given

Table 7-1. Status reporting decisions.
Top
Immediate Supervisors Team Members
Management
Levels Less detail, Greater detail,
of more graphic, Intermediate lists,
Detail information tool action tool
Less frequently More frequently
Timing Intermediate
(minimum monthly) (minimum weekly)
Just the overview,
Everything Only the
problem isolation,
Content that is sections that
and
produced affect them
recommendations

Information for Management on Status Reports
• Where you are
• Where you should be
• Where you are going next
• How you are going to get there
• What resources are needed
• When you are going to get there

When documenting any status report, determine who is taking responsibility for what: Who is collecting the
data? Who is correlating the data? Who ensures that the data are credible? Who produces the reports? Who
distributes them? Be sure each report is communicating the information that audience needs to know ” no
more and no less. Also, be sure you choose a format and level of detail appropriate to your audience. Finally,
make reporting techniques as flexible as possible for easy updating.

Step 2: Analyze the Impact
Step 2 is subdivided into three parts:
1. Compare planned to actual results in order to reveal variance. This part requires that several
questions be answered for each task and for the whole project: Are we ahead or behind schedule? Are
we over or under budget? Are we using the staff™s time as planned? Given actual staffing levels, are we
getting the results we expected?
2. Determine cause. That is, when problems appear, look carefully to find the cause. Typical causes
include poorly defined objectives, an incomplete or ineffective plan, inadequate communication, poor
estimates, changes of scope, and staff problems. Whatever the cause of the problem is, analyze its
impact on the project schedule and budget, the project team™s morale, and the quality of the project
deliverables.
3. Prepare analysis or forecast reports in which prior progress, or the lack thereof, is extrapolated to the
future. The analysis reports indicate the forecasted completion date, the forecasted resource utilization
at completion, and the forecasted final cost.
You can use this information by comparing it to senior management or client expectations for the project. If
the comparison is favorable, no further action is required. If the comparisons are unfavorable, you need to
take corrective action and/or preventive action.
The solving of problems in an efficient and effective manner is a logical and orderly process. One systematic
approach can be stated as a series of seven steps:
Seven Steps in Problem Solving*
*A number of people suggest that items 1 and 2 be reversed. Their logic is that you cannot define the problem
until the facts are known. However, it is difficult to collect pertinent data if the problem has not been defined. In
reality, we do collect data prior to the definition of a problem, but once the problem has been defined, then we
must review the information we have and sort out the facts. It is this final screening and selection process that is
implied in Step 2.

1. Define the problem.
2. Collect all the pertinent data.
3. Determine all possible alternative solutions.
4. Analyze and evaluate alternatives.
5. Select the best alternative(s).
6. Implement the action decided upon.
7. Follow up to be sure the action is carried out.



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


1. Define the problem. One of the major problems of business today is that there are too many people
Title
who are running around with answers looking for problems that the answers will fit. A brilliant answer
to the wrong problem is not very productive. Of all the steps in this process, defining the problem is
perhaps the most difficult and certainly the most critical. Inaccuracy at this point will not only prevent
solving of the real problem but may well tend to make the matter worse.
Frequently the most apparent problem is only a symptom of a far greater problem. We can choose to
-----------
keep on treating symptoms, or we can exercise our intelligence and get at the heart of the problem. The
real test in problem definition is in the identification of the basic cause. We must be willing to probe
and dig to find the real problems, which are not always apparent. For example, alcohol is rarely the
problem of alcoholics; the basic problem is generally the condition that makes them turn to alcohol as
an escape. If we simply took alcohol away, we might be able to stop their drinking, but sooner or later
they would find another means of escape because they are still confronted with the basic cause of their
drinking. We quickly lose confidence in doctors who merely treat symptoms, and we also lose
confidence in managers who fail to probe for the basic cause.
These are only a few of the problems that project managers encounter when trying to control a project:
• Personality conflicts: All people do not automatically like all other people. There are barriers
based on education, upbringing, political posturing, and just plain bad chemistry.
• Poorly defined project objectives: If the objectives are incorrect or ambiguous, the work efforts
may be misdirected or erroneous, thus causing slippages and inability to meet the plan.
• Ever-changing external forces: These are the fateful events that were never planned. Perhaps
the equipment falls off the back end of the truck when being unloaded, or the vendor™s truck is in
an accident and is totaled. These point to the truth of Murphy™s Law: “What can go wrong will
go wrong.” And in some cases, it is even worse, as Callahan™s corollary says: “Murphy was an
optimist.”
• Lack of historical data: Estimating is difficult at best; however, estimates without a basis of
historical data are gambles.
• Changes of scope: New design requests cause an impact.
• Inefficiencies within a project: Among them are unrealistic performance standards, calendar
timing derived in a pseudoscientific fashion, skill deficiencies on the part of the project team
members, the learning curve required to bring new team members up to speed, poor
communication (upward and downward), and diminishing morale, which decreases further with
burnout.
2. Collect all the pertinent data. This step is a fact-gathering process. Attempt to collect all of the
available data pertinent to the problem, but be wary of gathering unrelated material, which will result
only in confusing the issue or clouding it, to the point where you are no longer able to focus on the
problem. This is one more reason that specific problems must be solved. If the problem has been
defined clearly, then the collection of data related to this problem ” and this problem alone ” will be
greatly simplified. The collection of pertinent material requires hard work and careful analysis, but the
rewards of doing a capable job in this step of problem solving far exceed the time required.
3. Determine all possible alternative solutions. Once the problem has been accurately defined and all
the pertinent material collected, then and only then should you begin to explore solutions. Most of us
have a great tendency to jump directly from the definition of the problem to its solution. This jumping
is a dangerous activity, for too often we jump in the wrong direction.
When we have defined a problem, the first solution we come up with seems almost brilliant to us. We
are often sure that nothing else could possibly be as good as this first answer. We may be right, but
nevertheless, often further thought results in a better solution.
One of the more dangerous things to do in this phase of problem solving is to censor your own ideas;
that is, we often immediately reject any ideas that have not been tried before, that we think others may
ridicule, that may cost money, that may threaten our own position, and so forth. When we impose these
restrictions on ourselves, ideas will not come freely. At this point, the important thing is to think up
every possible solution, no matter how strange or silly it may seem. The screening and sorting of these
ideas will come later in the process. Keep an open mind when looking for alternatives.
4. Analyze and evaluate alternatives. This is the task of separating the wheat from the chaff. Many of
the alternatives either did not meet the problem or met it only partially. You are not yet looking for the
best alternative but merely examining the choices to establish which ones have merit. Now is the time
for testing and questioning the alternatives to find out how they fit the problem at hand. Don™t reject
any alternative until it has been proved to be useless in the solution of the problem. It is here that you
draw on your experience, education, judgment, and knowledge to explore the suitability of every
alternative.
5. Select the best alternative(s). The evaluation procedure may have left you with several possible
solutions still available ” or none at all. In the latter case, start the procedure again from the beginning.
Typically, however, several alternatives will be applicable to the solutions; it is this step that pinpoints
the action that you will take. Often the final selection will be a combination of several alternatives, each
supporting the other(s). Regardless of whether the process discloses one or many courses of action, the
important aspect is that a selection has been made. You have made a decision in regard to which course
of action is the most appropriate in your judgment.
This step can be very rapid or very time-consuming, depending on the complexity of the problem
and/or the alternatives. Do not allow yourself to get into analysis paralysis ” analyzing forever and
never making a decision.
6. Implement the action decided upon. Your previous work will be nothing but a waste of valuable
time unless the decision made is put to use. Something must happen somewhere if the problem is to be
solved. There is no telling how many fine ideas and solutions are buried in file cabinets because the
individual who spent the time developing the solution did not have the courage to put it to use.
Implementation may be a gamble; you cannot always be sure the solution will work. You can take only
a calculated risk that you have been careful in your selection and that the odds are on your side. Unless
you take this step, the problem will still be with you, and all of your thinking and evaluative efforts will
go for nothing.
7. Follow up to be sure action is carried out. If you had the courage to implement the action, the whole
process can still come to nothing unless you follow up to make sure that the action was implemented in
the manner intended. The follow-up phase determines whether the problem will stay solved. This may
be accomplished through informal control.


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



Step 3: Act on the Variances
Title

There are three courses of action as a result of comparing the plan to the actual:
1. Do nothing, either because the impact is not great enough to warrant action or because the trend is
not strong enough to justify action yet.
-----------
2. Look at the plans that exist and make modifications within the schedule, resource, cost, and scope
baselines to accommodate the problem.
3. Start negotiating trade-offs ” perhaps time added to the schedule, additional resources, additional
money, and/or a resizing of the scope of the project.
The last alternative is not often considered. Let™s examine a case study to discuss how it can work.
Poor Frank. He has found himself in what appears to be an impossible situation. His position as
project manager is rapidly becoming an albatross around his neck, and he is very unhappy. His
relationship with his supervisor, the vice-president of marketing, is a disaster. And project
management is the focal point of the problem.
Frank is a conscientious project manager. When confronted with a new project assignment, his
initial plan of action is to assemble a team with the requisite skills and have them develop a
detailed plan for the achievement of the project objectives. He carefully reviews inputs from the
project team to ensure that the cost and schedule targets for the project are reasonable and
attainable but not padded. But his supervisor constantly throws monkey wrenches into the
process. At plan review time, thinking that he is motivating Frank, he ignores the carefully
prepared plan and substitutes arbitrary, capricious deadlines and budgets upon Frank. “I don™t
care about the plan, Frank. Find a way to get it done by February 1, and keep the budget under
$60,000.”
After Frank had related the story to us, we asked him how he was responding to the situation. His answer was
somewhat surprising: Most of the time he found a way to complete the project within the unreasonable
deadline established by the vice-president and within the understated budget. That was the totality of his
answer, with no explanation of how he managed to perform this feat or any mention made of the
vice-president™s reaction to this accomplishment.
We thought about Frank™s story and how he had managed to meet the deadlines and budgets arbitrarily set by
his supervisor and realized that his story revealed two problems: (1) the substantive issue of how Frank
managed to complete the work within the unreasonable time frame and understated budget and (2) the
problem of the perception, in the vice-president™s mind, created by Frank™s performance.
How can Frank manage to bring in projects in unreasonably short durations for insufficient funds? There are
several possibilities. Frank might be achieving the desired results by pushing the staff to work a significant
amount of overtime with no compensation. If this were the case, however, one would expect to find extremely
low morale within the group, as well as a higher-than-normal rate of employee turnover. When we asked
Frank if this were the case, he said that the morale of the group was high and that turnover in the unit was of
no consequence.
Another possibility is that Frank is able to achieve the desired results because his initial schedules and budgets
were overstated, and the deadlines and budgets set by the vice-president are reasonable. But when we
examined the plans, not only did they not appear to be overstated, they were based upon industry standard
estimating techniques, and the techniques were applied in a manner consistent with the directions for their
use. Frank™s plans were, if anything, slightly understated at the time that they were presented to the
vice-president.
Finally, we hit upon a likely solution and asked Frank to show us some of the deliverables he had produced by
undertaking these projects. He was reluctant to do so. Unlike most other project managers we have
encountered, Frank was not proud of the results he had achieved. Further probing revealed a single reason for
Frank™s lack of pride in his results: He had produced a series of products that were marginally functional,
extremely difficult and costly to maintain, and below his (and probably his organization™s) standards.
Frank had discovered a fairly common technique for survival in an environment characterized by
unreasonable deadlines and inadequate budgets: treat the technical objectives as a variable rather than a
constant. If the deadline is fixed and the budget is locked in, produce the quality of product attainable within
the time frame and budget rather than the quality of product stated in the specifications. Take the shortcuts
that are least likely to be noticed by the client. Don™t alter the appearance of the product; that is too obvious to
the client. Instead, alter the internals of the product, reducing quality to achieve an on-time, on-budget
performance. Gamble that no one will recognize the substandard nature of the work for some time to come.
It is important to remember that Frank was not proud of his actions or the results they had produced. He felt
cornered. His reaction was a means of survival in a situation in which he could not effectively negotiate with
his supervisor. As a consequence, the products were produced, the group™s morale remained relatively high,
but Frank became extremely unhappy with the situation. On the other hand, Frank™s supervisor was very
pleased. He set unreasonable and understated budgets and perceived that Frank consistently delivered in a
manner that fulfilled his goals. He also perceived that his technique worked and was unaware of the problems
inherent in Frank™s products. He was insensitive to the problem of Frank™s morale. Therefore, he continued to
employ the technique of applying pressure to project managers by setting arbitrary budgets and deadlines.
This lack of effective communication between Frank and the vice-president has led to a recurring cycle of
problems ”one that will eventually be revealed as the cost of supporting and maintaining the products is
reflected in the performance of the organization.
In reality, we have two problems in this situation. The first is the policy question of whether the organization
wants to treat technical objectives as a variable. If this is the case, under what circumstances and with what
controls is this accomplished? What level of authority should be required to decide that the technical
objectives of a project are to be altered to meet the schedule or to get it done within budget? Design to cost
and design to deadline can both be useful techniques in setting technical objectives, under the right set of
circumstances and with the right set of controls.
The second problem may be more difficult. It is one of lack of communication and understanding. When a
project manager, in a situation similar to Frank™s, finds it necessary to take extraordinary action to meet the
schedule or get the job done within budget, senior management must understand that the goal has been
achieved as a result of extraordinary action. The project manager must let management know how it is
possible to deliver on time and on budget. If nothing else, this will force management to face up to the issue
of whether the technical objectives ought to be treated as a variable.


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



Compromising on technical objectives to meet schedules and budgets represents a significant risk to the
Title
organization and is not a decision to be taken lightly. In most cases, it is not a decision to be made at the
project manager level in the organization, and it is not a decision to be made without analysis by management.
If the risks are both modest and acceptable to the organization, as well as legal and ethical, then it is the
responsibility of management, not the project manager, to determine that the compromise be made.
-----------
If the forecasts are at variance with the plan, you as project manager must take action to minimize the
departure from the plan. There are two types of action to be considered: corrective and preventive. Corrective
action deals with problems that have already been experienced; preventive action addresses anticipated
problems. The need for corrective action is revealed in the historical status reports; the need for preventive
action is indicated by the forecasts.
In both corrective and preventive action, the first requirement is to determine the root cause of the problem.
Then you can work with the team to develop alternative solutions, evaluate the alternatives, and select one to
be implemented. If you lack the authority necessary to implement the selected solution, obtain approval for it.
Once approved, the solution is implemented. Then monitor the effectiveness of the solution over time. The
project manager uses contingency to implement solutions to the problems experienced in the execution of the
work.
Remember not to overreact. Be sure there is a trend evident before making any major changes, but don™t wait
too long. Problems typically do not disappear on their own. There is an analogy that relates to this issue and
offers a good piece of advice. If you have a monkey (a problem) on your back, either shoot the monkey or
feed it, but never starve it. Shooting the monkey means implementing corrective action as soon as possible; in
other words, solve the problem and make it go away. The second acceptable option is to feed the monkey,
which means to work the problem until it is resolved. But don™t ignore the monkey to the point of starving it;
when you ignore a starving monkey, it dies an excruciating and raucous death. And the negative attention will
be brought to the project manager™s doorstep.
Keep in mind the basic review-and-revise process. The basic schedules have been prepared, the variances
have been analyzed, and modifications have been determined. You and the project team are revising the basic
schedules of time, resources, costs, and deliverables. While making these revisions, record the assumptions
that have been made. For example, “We are going to let Task A slip because we have been told by the
subcontractor that he doesn™t need the product from us on the delivery date; a one-week delay will not affect
his turnaround time.” It is important to record these assumptions, not only to be able to refer to them if there is
contention at a later date but also to preserve them as part of the database you will use in planning projects in
the future.

Step 4: Publish the Revisions
It is a rare month in which there are no revisions to the project plan. Since the plan is the working document
that the project team relies on for guidance, it should be updated constantly. Most corrective and preventive
actions and even minor variances create a need to publish a revised plan.
Publishing a revised plan is similar to publishing the original plan during the planning steps of the project
management life cycle. If there are any alterations to the resource demands, either in number or time frame,
new commitments must be obtained from the managers of those resources. If there is a change in the
completion date or the cost at completion, approval of the revised plan may have to be obtained from senior
management and the client. Finally, the revised plans have to be distributed to the same persons who were
recipients of the original plans.
All status reports and revisions can be published or only exception reports can be produced. Exception reports
describe key extracts of the plan, not the entire overview. When you make this decision, consider a form of
exception reporting for your own sake (as the person producing the report) as well as the sake of those on
your distribution list who have limited time and energy to read your status reports. Following is a list of
possible variations of exception reports:
Schedule
• Status of tasks on the critical path(s) that have slipped, the reason for their slippage, and the plan to
get back on target.
• High-risk tasks for which contingency plans were developed in the planning process. Also,
uncertainty paths ” those that precede the high-risk tasks ” should be tracked. If they slip, then the
high-risk tasks are in even more jeopardy.
• Tasks that are eating up their float through slippages.
• Tasks that have extended past their late start or late finish dates.
Resources
• Resources not working on committed tasks.
• Resources not possessing the required qualifications.
• Resources working more hours than planned to catch up on schedule slippage.
• Resources working on unapproved changes of scope instead of planned task work.
• Resources being pulled on and off the project erratically.
• Resources not getting along together.
• Resources working a lot of overtime and getting burned out.
Costs
• The financial impact of money being thrown into resources.
• Changes in prices or charge-out rates originally used in the plan.
• Additional dollars being spent on new design ideas that were not funded.


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



Step 5: Inform Management
Title

During the controlling process, management needs to be informed of problems being experienced on the
project so that it can respond to inquiries concerning the project. Management may be asked to provide
information or insights necessary to take corrective or preventive action in response to a problem. In addition,
----------- management must be given an overall picture of the condition of the project, the problems that have been
encountered, and the actions that have been taken in response to the problems.
Management is kept informed through:
• Informal discussions about problems being experienced in the execution of the work and requests for
input to the development of solutions.
• Formal presentations (on an infrequent basis) that provide a subjective assessment of the condition of
the project.
• Written single-project status reports, prepared each month, that convey a detailed picture of the
project.
• Tabular multiproject status reports, giving a very brief summary of the condition of a group of
projects.
When deciding whether to distribute status reports to management to keep them informed, remember that
people retain only 10 percent of what they read, 20 percent of what they hear, 30 percent of what they see, and
45 percent of what they see and hear (see Figure 7-2). This indicates that a management briefing in which you
give a presentation using good graphical representations of the project status, issues, and resolutions is the
most effective. Below are some basic guidelines to keep in mind when communicating with management:
• Objectives: Continually readdress the project objectives to keep the goal clear in everyone™s mind.
• Simplicity: Keep communications simple, clear, and concise.
• Approvals: Be sure you have obtained appropriate approvals for any changes.
• Authority levels: Permit project plans to be changed by authorized people only.
• Accuracy: Be sure that everything you display or publish is accurate. This means that all numbers
add and cross reference; it also means that reality is portrayed with integrity and honesty.
• Problem isolation: Identify project problems primarily through people, not paper. Use upward and
downward communication techniques.




Figure 7-2. Project control: steps to ensure that actual performance conforms to plan.
• Management by exception: Establish key indicators. Everything does not have to be communicated;
management is interested in just the exceptions.
• Thresholds: Establish clear thresholds under which management does not need to be informed and
thresholds over which management is to be told about the problem, preferably with recommended
solutions.
• Relevant reports: Produce only reports useful to management.
• Review meetings: Do not use project review meetings as the vehicle for presenting problems to top
management for the first time. Inform them beforehand of the issues.
The bottom line is that systems are not a substitute for leadership and effective day-to-day management.

Project Team Members™ Role in the Controlling Process
Consider status information. With respect to completed tasks, the data required include actual task start date,
actual task duration, actual person-hours, and actual costs incurred. The first three of these four items should
be available from the organization™s time reporting system, and the fourth should be available from the cost
accounting system. Therefore, it should not be necessary to ask team members for this information, diverting
attention from the work at hand.
With respect to tasks that have not yet commenced, the data required include revised duration, revised
person-hours required, and revised cost. If the organization has an adequate change management procedure,
this information should be available from the current approved plan, which consists of the original project
plan plus the approved changes to date. The project team members participated in the development of the
estimates for the changes and do not need to be asked about the impact of the change. Furthermore, if a new
change to the plan is required, the change management procedure has the team member elevate the need to the
attention of the project manager. Therefore, the project manager does not need to ask if there are any revisions
to the estimates of future tasks. Once again, the team member may be left to work undisturbed on the project.
The most complex data requirements are those with respect to tasks that are underway at the end of the
control period. Data required with respect to these tasks include actual start date, actual days worked, actual
person-hours, actual cost, estimated days to complete, estimated person-hours to complete, and estimated cost
to complete. Again, there are sources for some of these data other than project team members. Actual start
date, actual days worked, and actual person-hours should be available from the time reporting system. Actual
cost to date should be available from the cost accounting system. The estimates to complete, however, must
come from the project team members; there is simply no other source of these data.
A well-thought-out data collection effort in an organization with adequate time reporting and cost accounting
systems can reduce the number of data that have to be gathered from the members of the project team,
allowing them more time to work on the project and furthering the objectives of the organization. If the
organization™s systems are inadequate, the project team members become the primary source of all data. This
results in lower productivity and higher estimates for performing the work. Relying on the project team
members as the source of data, rather than fixing the time reporting and cost accounting systems, is a poor
long-term strategy for the organization.


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 8
Project Control Techniques: Status Reports and
Reviews
-----------

Designing and Producing Status Report Documents
Do you work in a department or division where everyone who writes a status report uses the same general
format? Our guess is that you probably do not. In several informal surveys we have taken, less than 10 percent
of project managers within the same organization have a standardized reporting format. How do you as a
status reporter know what to report if there are no guidelines? Who teaches you how to construct an
informative, concise report with which to keep management abreast of project performance? Typically a
status report contains five sections:
Format for a Status Report
Section 1. Where are we today?
Section 2. Where will we be at the next report?
Section 3. What is our budget position?
Section 4. What items jeopardize project completion?
Section 5. Who deserves recognition?

Section 1: Where are we today? This first section gives a brief synopsis of the project™s progress since the last
status report. You can do this with a list of bulleted items no more than one or two sentences each. Each item
describes recent achievements, milestones completed, and other events that have had significant impact on the
project (vendor issues, personnel items). Then provide a milestone chart giving a historical perspective of
thirty to sixty days. A chart provides a quick context, or background, for the reader to compare planned versus
actual performance. This section also provides a high-level project perspective for the purposes of
management review. In other words, it keeps the detail level low, provides concise data, pinpoints situations
that merit attention, and allows readers the opportunity to request further information as needed. Keep in mind
that your audience is inundated with written reports, memos, and other documentation. Your goal is to
provide an adequate description of the project, in a short format, that is readable”and will more than likely
be read.
Section 2: Where will we be at the next report? Once you have brought the reader up to date, describe the
project™s near-term direction”the events that will take place during the next reporting interval. Again, use
one-to-two-sentence bulleted items describing pending events, and prepare a milestone chart with a thirty-to
sixty-day forward view. This chart can be combined into a single graphic with the milestone chart from
Section 1. Most PC-based project management software packages can easily create this type of chart.
This section gives upper managers a view of the project™s immediate direction. In this way, they have the
opportunity to suggest course corrections early enough to make an impact on project progress.
Section 3: What is our budget position? It is very important that this section be a clear visual image. Detailed
charts with mounds of data and dozens of line items get ignored unless a project is in serious trouble. Prepare
a simple line graph or a bar chart that displays plan versus actual data. If there is significant variance in actual
versus plan, provide a brief explanation of the cause of the variance. This simple chart gives managers enough
basic data to assess overall project budgetary status. If they want more detail, they will request it.
Section 4: What items jeopardize project completion? HELP! That™s really what this section is about. Let
management know where there is a problem and what should be done about it. There are two criteria for an
item to be included in this section: It must place the completion of the project at risk, and it must be beyond
your capability to resolve. If both these conditions are met, ask for help in clear tones. (If not, resolve the
issue yourself and go on). Be sure you indicate clearly what action you would like management to take. This
is not an opportunity to take a monkey off your back and put it onto your boss™s. It™s your chance to call in the
cavalry. But you need to be explicit in describing the help you need.
A political side note is required here: Inform your manager of any items you intend to include in this section
before you print the report. Managers do not like to be caught unaware, and it is a politically adroit project
manager who gives a manager a chance to resolve problems before they reach print.
Section 5: Who deserves recognition? This last section is very important and often overlooked. Team
members, not just project managers, make or break a project. Their involvement, commitment, and dedication
to quality make the difference between success and failure. Yet we often overlook basic opportunities to
recognize team members who demonstrate excellence on the job, put in long days and weekends, forsake
vacations and holidays, and walk that extra mile to make a project successful. This section allows you to
acknowledge excellence and dedication. As a morale boost, it demonstrates to the project team that you are
aware of the work being done and are appreciative. It also provides visibility for the productive workers to
upper management.
Adapt these five sections to your own situation in order to improve communication with management.
Encourage your peers to adopt a format they will all employ. You will find that a short, concise status report
is a management tool, not drudgery. Managers will learn what to expect in a status report and where to find it.
The key to a status report is how effectively it communicates the state of the project to management, but it has
to be read first. Make it concise.

Charts and Graphs
There are a variety of graphic presentations that can effectively compare planned versus actual performance.
Remember that status reports give us the questions. You not only need to address these questions but also find
solutions and implement action plans.
The typical Gantt chart shown in Figure 8-1 indicates that Activities 3, 5, and 6 have started later than
planned. Some of the questions you need to be asking are the following: Are these slippages on the critical
path? If they are, is there a way to make up the lost time? If these slippages are on noncritical activities, has
the slippage eaten up all the available float? What caused the slippage?
The Gantt chart in Figure 8-2 shows a dramatic slippage on all activities. Among the questions you need to
ask are these: Why did the project start late? Why did Activity A take twice as long to complete? Critical path
Activity E has started one and a half months late. Is there any chance of completing this activity on time?
(Probably not.) Most important, why are we living with this unrealistic schedule? Where is the revised plan?
Now let™s look at Figure 8-3. This Gantt chart shows an early completion of critical path Activity E. However,
noncritical path Activity C has slipped one month. As you can see, the noncritical path Activity F has one and
a half months of float, which can accommodate the slippage in C. With the early completion of E, however,
the C,F path has now become the critical path.
Here are some questions that you should ask: What is taking so long in Activity C? If it completes within the
next half-month, we have a chance of completing the project early. If not, the initially noncritical path
Activity C could cause the project to be completed late. Could we transfer people from Activity E, which
completed early, onto Activity C? Do those people who worked on Activity E have the correct skill mix to
work on Activity C? If not, this is not a viable solution.




Figure 8-1 Typical Gantt chart.




Figure 8-2 Gantt chart with slippage.




Figure 8-3 Gantt chart with slippage on noncritical path.


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



In the resource loading chart in Figure 8-4, the original plan is the histogram outlined by a heavy line; the
Title
actual is shown by the shading. It is obvious that more resources are being used than were planned. Perhaps
priorities have changed, and resources are being poured into the project to get it completed earlier. Or
additional changes of scope, which require additional resources, have been requested. A third reason might be
that the original work effort ws underestimated, and more resources are needed to get the job done. The
----------- schedule could be slipping and resources are being expected to catch up, or less qualified resources were
scheduled to the project than planned, and therefore it is taking more time to finish the work. Without the
schedule status, it is impossible to come to a conclusion.
Cost line graphs can be analyzed easily. Figure 8-5 shows that the actual monies spent are consistently behind
the plan. This may mean that the project is progressing slower than planned. However, the trend seems to be
catching up with the plan. If we could see the schedule, it is a safe guess that money is being pumped into the
project so that it will move back into line with the schedule plan. Again, nothing is conclusive with only the
cost line graph.
The next three figures compare a schedule status report against a resource loading status report and a cost line
graph. A first glance at the schedule in Figure 8-6 gives the impression that this project appears to be in very
good shape. However, a review of the resource and cost graphs shows that a substantial amount of effort and
money appears to have been expended in order to keep on schedule.
In Figure 8-7, the schedule is slipping dramatically, yet the resources and dollars have stayed pretty much in
line. Because this schedule has slipped so much, it appears that this project will not come in on time. Has
everyone been informed that this project is going to slip its target date? A manager reviewing this report
might think, “It™s not realistic to expect that the resources will start dropping off, or the budget. Looks like we
should be negotiating to keep some of the resources on the project in order to make up for lost time. We™ll
also want to project an overbudget position at completion”and we may want to cancel the project if the
benefits planned will not be accomplished”.
In Figure 8-8, the schedule is slipping too. Completion dates for work activities have been extended, probably
because the resources planned for the project have not been available. The underbudget situation is not
necessarily good news, since the projections seem to indicate a final late completion and overbudget situation.
Figure 8-4 Resource loading chart.




Figure 8-5 Cost line graph.




Figure 8-6 Multiple baselines.




Figure 8-7 Multiple baselines with slippage.




Figure 8-8 Multiple baselines with slippage and underbudget situation.

Trend Analysis
In the preceding section, we analyzed snapshots of a project at a moment in time. However, there is more to
reporting project status than just telling people what happened as of yesterday. It is important to look at trends
and to project what will ultimately happen in terms of time, resources, and/or dollars if the trend continues.
Trend analysis is a useful tool for project control since it enables you to compare the target with the
destination. Let™s compare two illustrations in order to illustrate the benefits of trend analysis.
Figure 8-9 illustrates the cost analysis curve for a project as of the completion of a specific control period. The
target represents the current plan”what the project manager is aiming for in terms of schedule and cost. The
destination represents the current forecast for schedule and cost completion. There is usually some
discrepancy between the target and the destination. The same graph can be produced with person-hours as its
y-axis; in this case, the destination represents the current forecast for schedule completion and person-hours at
completion. The problem is that the destination changes from month to month, and the graph does not allow
the project manager to perceive the change in the destination.


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



Trend analysis, on the other hand, focuses on the changes in the destination. It allows you to see the changes
Title
over time and to decide whether the trend is alarming, though the current forecast indicates that the project
will be completed within the plan plus the contingency allocated to it. In Figure 8-10, the most recent
forecasted completion date, as of the end of the sixth month, is twelve and a half months, but the trend
indicates fourteen and a half months. Since the plan plus contingency for the project is fourteen months, it
----------- looks as if the project may be in trouble. The trend analysis has provided an early warning of the problem.
Figure 8-11 indicates that the trended cost at completion will be $25,000 over budget. Since the graph
indicates a contingency of $100,000, the cost does not appear to be a problem. In fact, the manager of this
project might do well to spend additional funds in order to shorten the period of performance, if possible.
Similarly, the resource trend in Figure 8-12 indicates that the ceiling on human resources for the project will
not be approached, given the current trend. Just over 40 percent of the reserves are forecasted to be utilized by
the trended completion date of fourteen and a half months.
The trend in the utilization of contingency can also be tracked. Here a word of warning is appropriate:
Tracking contingency utilization requires a good deal of planning. First, the risks must be identified. Then the
time frame for each risk must be anticipated. Figure 8-13 presents a sample of such a trend analysis. In this
example, contingency utilization started out well over planned utilization, dropped below planned utilization,
and has climbed again in the last month. Overall the trend is somewhat alarming.




Figure 8-9. Cost analysis curve.




Figure 8-10 Schedule trend analysis.
Figure 8-11 Cost trend.




Figure 8-12 Resource trend analysis.




Figure 8-13 Contingency utilization.

Trend analysis is not a precise tool; however, it is a critical component of an early warning system since it
enables you to see problems before they become alarming. Some form of trend analysis is appropriate on all
projects.

Preparing and Conducting Status Review Meetings
Your project has been underway for one week. Is it time for a project review meeting? Absolutely yes. In
project management, it is not a matter of whether you™ll get into trouble; rather, it is a matter of how soon you
will get into trouble and how fast you can get out of it. At the very first review meeting ask: Were the
milestones met? If the answer is yes, review the deliverables in detail. Have they been quality controlled? And
will the people or functional area(s) who will use these deliverables find them acceptable?
Slippage can create disastrous delays and backlogs. Assume the project has ten milestones that have to be met
each week, and on Week 1 you have missed five of them. Consequently, the next week, fifteen milestones
must be completed”the ten required for the second week in addition to the five that were not completed the
first week. Run this scenario out, and you will have a pyramid of delayed milestones, indicating a project in
deep trouble. When milestones are not being met, address these questions during the first project review
meeting:
• Why are the milestones not completed?
• What is the impact?
• When will the work be done?
• Is an alternative action plan needed?
• What is the date(s) required to get back on schedule?
In order to resolve these issues, you must prepare for project status review meetings.

How to Prepare for a Review Meeting
• Define the objective of the meeting clearly. Each project review meeting cannot cover in detail all of
the project issues”the schedule, budget, resource utilization, quality, technical, and design
considerations. Therefore, the objective should be focused and determined by the participants.
For example, if the attendees are the management committee and/or the customer, they will want to know
about what has gone wrong, what you have done to fix it, and what, if any, support you need from them. If the

<<

. 3
( 5)



>>