<< . .

. 10
( : 16)



. . >>

• 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.

<< . .

. 10
( : 16)



. . >>