lecture notes on software project management and lecture notes on project planning and management pdf free download
An Overview of
hat’s all the fuss about, anyway? Since the first edition of
this book was published, in 1997, the Project Management
Institute (PMI ) has grown from a few thousand members to
nearly 450,000 in 2011. For those of you who don’t know,
PMI is the professional organization for people who manage
projects. You can get more information from the institute’s
website, www.pmi.org. In addition to providing a variety of
member services, a major objective of PMI is to advance project
management as a profession. To do so, it has established a certi-
fication process whereby qualifying individuals receive the Proj-
ect Management Professional (PMP ) designation. To do so,
such individuals must have work experience (approximately five
thousand hours) and pass an online exam that is based on the
Project Management Body of Knowledge, or the PMBOK Guide.
A professional association? Just for project management? Isn’t
project management just a variant on general management?
Yes and no. There are a lot of similarities, but there are
enough differences to justify treating project management as a
discipline separate from general management. For one thing, proj -
ects are more schedule-intensive than most of the activities that
American Management Association • www.amanet.org2 Fundamentals of Project Management
general managers handle. And the people in a project team often
don’t report directly to the project manager, whereas they do re-
port to most general managers.
So just what is project management, and, for that matter,
what is a project? PMI deﬁnes a project
as “a temporary endeavor undertaken to
PMI defines a proj -
produce a unique product, service, or
ect as “. . . a tem-
result” (PMBOK Guide, Project Man-
agement Institute, 2008, p. 5). This
means that a project is done only one
time. If it is repetitive, it’s not a project.
A project should have deﬁnite starting
produce a unique
and ending points (time), a budget
(cost), a clearly deﬁned scope—or mag-
nitude—of work to be done, and speciﬁc
performance requirements that must be
met. I say “should” because seldom does
a project conform to the desired deﬁnition. These constraints on
a project, by the way, are referred to throughout this book as
the PCTS targets.
Dr. J. M. Juran, the quality guru, also deﬁnes a project as a
problem scheduled for solution. I like this deﬁnition because it re-
minds me that every project is conducted
A project is a
to solve some kind of problem for a com-
pany. However, I must caution that the
word “problem” typically has a negative
meaning, and projects deal with both
positive and negative kinds of problems.
—J. M. Juran
For example, developing a new product is
a problem, but a positive one, while an environmental cleanup
project deals with a negative kind of problem.
In fact, the Standish Group (www.standishgroup.com) has found
that only about 17 percent of all software projects done in the
American Management Association • www.amanet.orgAn Overview of Project Management 3
United States meet the original PCTS targets, 50 percent must
have the targets changed—meaning they are usually late or over-
spent and must have their performance requirements reduced—
and the remaining 33 percent are actually canceled. One year,
U.S. companies spent more than 250 billion on software devel-
opment nationwide, so this means that 80 billion was com-
pletely lost on canceled projects. What is truly astonishing is that
83 percent of all software projects get into trouble
Now, lest you think I am picking on software companies, let
me say that these statistics apply to many different kinds of proj -
ects. Product development, for example, shares similar dismal
rates of failure, waste, and cancellation. Experts on product devel-
opment estimate that about 30 percent of the cost to develop a
new product is rework. That means that one of every three engi-
neers assigned to a project is working full time just redoing what
two other engineers did wrong in the ﬁrst place
I also have a colleague, Bob Dudley, who has been involved
in construction projects for thirty-ﬁve years. He tells me that
these jobs also tend to have about 30 percent rework, a fact that
I found difﬁcult to believe, because I have always thought of con-
struction as being fairly well deﬁned and thus easier to control
than might be the case for research projects, for example. Never-
theless, several colleagues of mine conﬁrm Bob’s statistics.
The reason for these failures is consistently found to be inad-
equate project planning. People adopt a ready-ﬁre-aim approach
in an effort to get a job done really fast and end up spending far
more time than necessary by reworking errors, recovering from
diversions down “blind alleys,” and so on.
I am frequently asked how to justify formal project manage-
ment to senior managers in companies, and I always cite these sta-
tistics. However, they want to know whether using good project
management really reduces the failures and the rework, and I can
only say you will have to try it and see for yourself. If you can
achieve levels of rework of only a few percent using a seat-of-the-
pants approach to managing projects, then keep doing what you’re
doing However, I don’t believe you will ﬁnd this to be true.
American Management Association • www.amanet.org4 Fundamentals of Project Management
The question I would ask is whether general management
makes a difference. If we locked up all the managers in a company
for a couple of months, would business
continue at the same levels of perfor-
mance, or would those levels decline? If
they decline, then we could argue that
ment is application
management must have been doing
of knowledge, skills,
something positive, and vice versa. I
doubt that many general managers
tools, and tech-
would want to say that what they do
doesn’t matter. However, we all know
niques to project
that there are effective and ineffective
activities to achieve
general managers, and this is true of proj-
ect managers, as well.
What Is Project
management is ac-
The PMBOK Guide deﬁnition of proj-
ect management is “application of
the application and
knowledge, skills, tools, and techniques
to project activities to meet the project
integration of the
requirements. Project management is ac-
complished through the application and
integration of the 42 logically grouped
ment processes of
project management processes compris-
ing the 5 Process Groups: initiating,
planning, executing, monitoring and con-
trolling, and closing” (PMBOK Guide,
ing and controlling,
Project Management Institute, 2008,
p. 6). Project requirements include the
PCTS targets mentioned previously.
The various processes of initiating,
planning, and so on are addressed later
in this chapter, and the bulk of this book is devoted to explain-
ing how these processes are accomplished.
American Management Association • www.amanet.orgAn Overview of Project Management 5
It would be better if the PMBOK Guide speciﬁed that a proj-
ect manager should facilitate planning. One mistake made by in-
experienced project managers is to plan the project for the team.
Not only do they get no buy-in to their
plan, but that plan is usually full of holes.
The first rule of
Managers can’t think of everything, their
estimates of task durations are wrong,
and the entire thing falls apart after the
ment is that the
project is started. The ﬁrst rule of project
people who must
management is that the people who must
do the work should help plan it.
do the work should
The role of the project manager is
help plan it.
that of an enabler. Her job is to help the
team get the work completed, to “run
interference” for the team, to get scarce resources that team
members need, and to buffer them from outside forces that
would disrupt the work. She is not a project czar. She should
be—above everything—a leader, in the true sense of the word.
The best deﬁnition of leadership that I have found is the one
by Vance Packard, in his book The Pyramid Climbers. He says,
“Leadership is the art of getting others
to want to do something that you be-
“Leadership is the
lieve should be done.” The operative
art of getting
word here is “want.” Dictators get oth-
ers to do things that they want done. So
others to want to
do guards who supervise prison work
do something that
teams. But a leader gets people to want
to do the work, and that is a signiﬁcant
you believe should
The planning, scheduling, and con-
trol of work represent the management
or administrative part of the job. But,
without leadership, projects tend to just
satisfy bare minimum requirements. With leadership, they can ex-
ceed those bare minimums. I offer a comprehensive application
of project leadership techniques in Chapter 13.
American Management Association • www.amanet.org6 Fundamentals of Project Management
It Is Not Just Scheduling
One of the common misconceptions about project management
is that it is just scheduling. At last report, Microsoft had sold a
huge number of copies of Microsoft Project , yet the project fail-
ure rate remains high. Scheduling is certainly a major tool used to
manage projects, but it is not nearly as important as developing a
shared understanding of what the project is supposed to accom-
plish or constructing a good work breakdown structure (WBS) to
identify all the work to be done (I discuss the WBS in Chapter 6).
In fact, without practicing good project management, the only
thing a detailed schedule is going to do is allow you to document
your failures with great precision
I do want to make one point about scheduling software. It
doesn’t matter too much which package you select, as they all have
strong and weak points. However, the tendency is to give people
the software and expect them to learn how to use it without any
training. This simply does not work. The features of scheduling
software are such that most people don’t learn the subtleties by
themselves. They don’t have the time, because they are trying to
do their regular jobs, and not everyone is good at self-paced learn-
ing. You wouldn’t hire a green person to run a complex machine
in a factory and put him to work without training, because you
know he will destroy something or injure himself. So why do it
When is managing a project not project management? When
only one person is involved.
A lot of people are sent to my seminars to learn how to manage
projects, but they are the only person working on their projects.
Now it is true that a one-person job can be called a project, because
it has a deﬁnite starting point, target, end date, speciﬁc perfor-
mance requirements, deﬁned scope of work, and a budget. How-
ever, when no one else is working on the project (including outside
vendors), there is no need for a critical path schedule. A critical
American Management Association • www.amanet.orgAn Overview of Project Management 7
path schedule is one that has a number of parallel paths, and one of
them is longer than the others and determines how long it will take
to complete the job or, ultimately, whether the given end date can
be met. When you’re working on a job by yourself, there aren’t any
parallel paths—unless you are ambidextrous
One-person projects do require good self-management, or
good time management, but all you need is a good to-do list,
which comes from a task listing. However, unless you are coordi-
nating the work of other people, you aren’t practicing true project
The Big Trap—Working Project Managers
It is common to have individuals serve as project managers and
require also that they do part of the actual work in the project.
This is a certain prescription for problems. If it is a true team, con-
sisting of several people, the project manager inevitably ﬁnds her-
self torn between managing and getting her part of the work done.
Naturally, the work must take precedence, or the schedule will
slip, so she opts to do the work. That means that the managing
does not get done. She hopes it will take care of itself, but it never
does. After all, if the team could manage itself, there would be no
need for a project manager in the ﬁrst place (remember our argu-
ment about whether project management matters?).
Unfortunately, when the time comes for her performance
evaluation, she will be told that her managing needs improving.
Actually, she just needs to be allowed to practice management in
the ﬁrst place.
Yes, for very small teams—perhaps up to three or four people—
a project manager can do some of the work. But, as team sizes in-
crease, it becomes impossible to work and manage both, because
you are constantly being pulled away from the work by the needs
of your team members.
One of the reasons for this situation is that organizations don’t
fully understand what project management is all about, and they
think that it is possible for individuals to do both. The result is that
nearly everyone in the company is trying to manage projects, and,
American Management Association • www.amanet.org8 Fundamentals of Project Management
as is true in every discipline, some of them will be good at it and
others will have no aptitude whatsoever. I have found that a far
better approach is to select a few individuals who have the apti-
tude and desire to be project managers and let them manage a
number of small projects. This frees “technical” people (to use the
term broadly) to do technical work without having to worry about
administrative issues and allows project managers to get really
good at their jobs.
It is outside the scope of this book to discuss how to select
project managers, but, for the interested reader, the topic is cov-
ered in a book by Wysocki and Lewis titled The World-Class Proj-
ect Manager (Perseus, 2001).
You Can’t Have It All
One of the common causes of project failures is that the project
sponsor demands that the project manager must ﬁnish the job by
a certain time, within budget, and at a given magnitude or scope,
while achieving speciﬁc performance levels. In other words, the
sponsor dictates all four of the project constraints. This doesn’t
The relationship among the PCTS constraints can be written
C = f(P, T, S)
In words, this says, “Cost is a function of Performance, Time, and
Scope.” Graphically, I like to show it as a triangle, in which P, C,
and T are the sides and S is the area. This is shown in Figure 1-1.
In geometry, we know that if we are given values for the
sides of a triangle, we can compute the area. Or, if we know the
area and the length of two sides, we can compute the length of
the remaining side. This translates into a very practical rule of
project management: The sponsor can assign values to any three
variables, but the project manager must determine the remain-
American Management Association • www.amanet.orgAn Overview of Project Management 9
Figure 1-1. Triangles showing the relationship
between P, C, T, and S.
So let’s assume that the sponsor requires certain performance,
time, and scope from the project. It is the project manager’s job to
determine what it will cost to achieve those results. However, I
always caution project managers that they should have a para-
medic standing by when they give the cost ﬁgure to the sponsor
because she will probably have a stroke or heart attack, and the
paramedic will have to revive her.
Invariably, the sponsor exclaims, “How can it cost that
much?” She had a ﬁgure in mind, and your number will always
exceed her ﬁgure. And she may say, “If it’s going to cost that
much, we can’t justify doing the job.” Exactly And that is the de-
cision she should make. But she is certain to try to get the project
manager to commit to a lower number, and, if you do, then you
only set up yourself—and her—to take a big fall later on.
It is your obligation to give the sponsor a valid cost so that she
can make a valid decision about whether or not the project should
be done. If you allow yourself to be intimidated into committing to
a lower number, it is just going to be a disaster later on, and you are
far better off taking your lumps now than being hanged later on.
Of course, there is another possibility. If she says she can afford
only so much for the job, then you can offer to reduce the scope.
If the job is viable at that scope level, then the project can be done.
Otherwise, it is prudent to forget this project and do something
else that can make proﬁts for the company. As someone has said,
American Management Association • www.amanet.org10 Fundamentals of Project Management
there is a higher probability that things will accidentally go wrong
in a project than that they will accidently go right. In terms of cost
estimates, this means that there is always
There is a higher
a higher likelihood that the budget will
be overrun than that the project will
come in below budget. This is just an-
things will acciden-
other way of stating Murphy’s law, that
“whatever can go wrong will go wrong.”
tally go wrong in a
project than that
The Phases of a Project
they will acciden-
There are many different models for the
phases a project goes through during its
tally go right.
life cycle. One of these captures the all-
too-frequent nature of projects that are not managed well and is
shown in Figure 1-2.
I have shown this diagram to people all over the world, and
they invariably laugh and say, “Yes, that’s the way it works.”
Figure 1-2. Life cycle of a troubled project.
American Management Association • www.amanet.orgAn Overview of Project Management 11
I suppose the comfort I can take is that we Americans are not the
only ones who have the problem, but the bad news is that there
are a lot of dysfunctional projects if everyone recognizes the model.
At the simplest level, a project has a beginning, middle, and
end. I prefer the life-cycle model shown in Figure 1-3, but there are
other versions that are equally valid. In my model, you will notice
that every project begins as a concept, which is always “fuzzy,” and
that the project team must formalize the deﬁnition of the job before
doing any work. However, because of our ready-ﬁre-aim mentality,
we often start working on the job without ensuring that we have a
proper deﬁnition or that the mission and vision for the job are
shared by everyone. This invariably leads to major problems as the
project progresses. This is illustrated by the example that follows.
Some years ago, a project manager in one of my client companies
called me and said, “I’ve just had a conference call with key
members of my project team, and I realized that we don’t agree
on what the project is supposed to accomplish.”
I assured him that this was common.
“What should I do?” he asked.
I told him that he had no choice but to get the team members
Figure 1-3. Appropriate project life cycle.
CONCEPT DEFINITION PLANNING EXECUTION CLOSEOUT
Marketing DoallWork FinalReports
Input Monitor Lessons-
Develop Implementation Progress Learned
Competition Corrective Review
WriteMission Risk Action
American Management Association • www.amanet.org12 Fundamentals of Project Management
all going in the same direction by clarifying the mission of the proj-
ect. He asked me to facilitate a meeting to do this.
At the meeting, I stood in front of a ﬂip chart and began by
saying, “Let’s write a problem statement.” Someone immediately
countered by saying, “We don’t need to do that. We all know
what the problem is.”
I was unmoved by this comment. I said, “Well, if that is true,
it’s just a formality and will only take a few minutes, and it would
help me if we wrote it down, so someone help me get started.”
I’m going to be a little facetious to illustrate what happened
next. Someone said, “The,” and I wrote the word on the chart,
and someone else said, “I don’t agree with that”
Three hours later, we finally finished writing a problem
The project manager was right. The team did not agree on
what the problem was, much less how to solve it. This is funda-
mental—and is so often true that I begin to think we have a de-
fective gene in all of us that prohibits us from insisting that we
have a good deﬁnition of the problem before we start the work.
Remember, project management is solving a problem on a large
scale, and the way you deﬁne a problem determines how you
will solve it. If you have the wrong deﬁnition, you may come up
with the right solution—to the wrong problem
In fact, I have become convinced that projects seldom fail at
the end. Rather, they fail at the deﬁnition stage. I call these proj-
ects headless-chicken projects because they are like the chicken
that has had its head chopped off and runs around spewing blood
everywhere before it ﬁnally falls over and is “ofﬁcially” dead. Proj-
ects work the same way. They spew blood all over the place, until
someone ﬁnally says, “I think that project is dead,” and indeed it
is. But it was actually dead when we chopped off its head in the
beginning—it just took a while for everyone to realize it.
Once the project is deﬁned, you can plan how to do the work.
There are three components to the plan: strategy, tactics, and lo-
gistics. Strategy is the overall approach or “game plan” that will be
followed to do the work. An example of strategy was related to
me by a friend who is into military history.
American Management Association • www.amanet.orgAn Overview of Project Management 13
During World War II, defense contractors were under great pres-
sure to build weaponry at an intense level. To accelerate con-
struction of ships and planes in particular, many new assembly
methods were invented. Avondale shipyards, for example, worked
on the method of building ships. The traditional way had always
been to build the ship in an upright position. However, ships built
from steel required welding in the bottom, or keel area of the
boat, and this was very difﬁcult to do. Avondale decided to build
its ships upside down, to make the welding easier, and then turn
them over to complete the structures above the top deck. This
strategy was so effective that Avondale could build boats faster,
cheaper, and of higher quality than their competitors, and the
strategy is still being used today, nearly seventy years later.
This phase includes tactics and logistics. If you are going to build
boats upside down, you must work out the details of how it will
be done. A ﬁxture must be constructed that will hold the boat
and allow it to be turned over without being damaged. This is
called “working out the tactics.” It also includes the sequence in
which the work will be done, who will do what, and how long
each step will take.
Logistics deal with making sure the team has the materials
and other supplies needed to do their jobs. Ordinarily we think
about providing teams with the raw materials they need, but if
the project is in a location where they can’t get food, work will
soon come to a grinding halt. So provisions must be made for the
team to be fed—and possibly housed.
Execution and Control
Once the plan has been developed and approved, the team can
begin work. This is the execution phase, but it also includes con-
trol, because, while the plan is being implemented, progress is
monitored to ensure that the work is progressing according to the
plan. When deviations from the plan occur, corrective action is
American Management Association • www.amanet.org14 Fundamentals of Project Management
taken to get the project back on track, or, if this is not possible,
the plan is changed and approved, and the revised plan becomes
the new baseline against which progress is tracked.
When all the work has been completed, the closeout phase re-
quires that a review of the project be conducted. The purpose is
to learn lessons from this job that can be applied to future ones.
Two questions are asked: “What did we do well?” and “What do
we want to improve next time?”
Notice that we don’t ask what was done wrong. This ques-
tion tends to make people defensive, and they try to hide things
that may result in their being punished. In fact, a lessons-learned
review should never be conducted in a blame-and-punishment
mode. If you are trying to conduct an inquisition, that’s different.
The purpose of an inquisition is usually to ﬁnd who is responsible
for major disasters and punish them. Lessons-learned sessions
should be exactly what the words imply.
I have learned during the past few years that very few organi-
zations do regular lessons-learned reviews of their projects. There is
a reluctance to “open a can of worms.” And there is a desire to get
on with the next job. The problem is that you are almost sure to re-
peat the mistakes made on the previous project if no one knows
about them or has an understanding of how they happened so that
they can determine how to prevent them. But, perhaps most im-
portant, you can’t even take advantage of the good things you did
if you don’t know about them.
It has been said that the organizations that survive and thrive
in the future will be those that learn faster than their competitors.
This seems especially true for projects.
The Steps in Managing a Project
The actual steps to manage a project are straightforward. Accom-
plishing them may not be. The model in Figure 1-4 illustrates
American Management Association • www.amanet.orgAn Overview of Project Management 15
Figure 1-4. The steps in managing a project.
Define the Problem
Plan the Project
What must be done?
Who willdo it?
How willitbe done?
When must itbe done?
How much willitcost?
What do we need todo it?
Execute the Plan
Monitor & Control Progress
Are we on target?
If not, what must be done?
Should the plan be changed?
What was done well?
What should be improved?
What else didwe learn?
Subsequent chapters of this book elaborate on how each step
is accomplished. For now, here is a brief description of the actions
American Management Association • www.amanet.org16 Fundamentals of Project Management
Define the Problem
As was discussed previously, you need to identify the problem to
be solved by the project. It helps to visualize the desired end re-
sult. What will be different? What will you see, hear, taste, touch,
or smell? (Use sensory evidence if things can’t be quantiﬁed.)
What client need is being satisﬁed by the project?
Develop Solution Options
How many different ways might you go about solving the prob-
lem? Brainstorm solution alternatives (you can do this alone or
as a group). Of the available alternatives, which do you think will
best solve the problem? Is it more or less costly than other suit-
able choices? Will it result in a complete or only a partial ﬁx?
Plan the Project
Planning is answering questions: what must be done, by whom,
for how much, how, when, and so on. Naturally, answering these
questions often requires a crystal ball. We discuss these steps in
more detail in Chapters 2 through 4.
Execute the Plan
Obvious. Once the plan is drafted, it must be implemented. In-
terestingly, we sometimes ﬁnd people going to great effort to put
together a plan, then failing to follow it. If a plan is not followed,
there is not much point in planning, is there?
Monitor and Control Progress
Plans are developed so that you can achieve your end result suc-
cessfully. Unless progress is monitored, you cannot be sure you
will succeed. It would be like having a roadmap to a destination
but not monitoring the highway signs along the way.
Of course, if a deviation from the plan is discovered, you
must ask what must be done to get back on track, or—if that
seems impossible—how the plan should be modified to reflect
American Management Association • www.amanet.orgAn Overview of Project Management 17
Close the Project
Once the destination has been reached, the project is ﬁnished,
but there is a ﬁnal step that should be taken. Some people call it
an audit, others a postmortem (sounds a bit morbid, doesn’t it?).
Whatever you call it, the point is to learn something from what
you just did. Note the way the questions are phrased: What was
done well? What should be improved? What else did we learn?
We can always improve on what we have done. However, asking
“What did we do wrong?” is likely to make people a bit defen-
sive, so the focus should be on improvement, not on placing
blame. More on this later.
The Project Management Body of
Knowledge (PMBOK )
The Project Management Institute has attempted to determine a
minimum body of knowledge that is needed by a project manager
in order for him or her to be effective. As I mentioned earlier
when I deﬁned project management, there are ﬁve processes
deﬁned by the PMBOK Guide, together with nine general areas
of knowledge, and I will give brief summaries of them. If you
want a complete document, you can get one by visiting the PMI
A process is a way of doing something. As previously mentioned,
the PMBOK Guide identiﬁes ﬁve processes that are used to man-
age projects. Although some of them will be predominant at cer-
tain phases of a project, they may come into play at any time.
Broadly speaking, however, they tend to be employed in the se-
quence listed as the project progresses. That is, initiating is done
ﬁrst, then planning, then executing, and so on. In the event that
a project goes off course, replanning comes into play, and if a proj-
ect is found to be in serious trouble, it may have to go all the way
back to the initiating process to be restarted.
American Management Association • www.amanet.org18 Fundamentals of Project Management
Once a decision has been made to do a project, it must be initi-
ated or launched. There are a number of activities associated
with this. One is for the project sponsor to create a project char-
ter, which deﬁnes what is to be done to meet the requirements of
project customers. This is a formal process that is often omitted in
organizations. The charter should be used to authorize work on
the project; deﬁne the authority, responsibility, and accountability
of the project team; and establish scope boundaries for the job.
When such a document is not produced, the team members may
misinterpret what is required of them, and this can be very costly.
One of the major causes of project failures is poor planning. Ac-
tually, I am being kind. Most of the time the problem is caused by
there being no planning The team simply tries to “wing it,” to do
the work without doing any planning at all. As I have explained
earlier in this chapter, many of us are task oriented, and we see
planning as a waste of time, so we would rather just get on with
the work. As we will see when we turn to controlling the project,
failing to develop a plan means that there can be no actual con-
trol of the project. We are just kidding ourselves.
There are two aspects to the process of project execution. One is
to execute the work that must be done to create the product of
the project. This is properly called technical work, and a project is
conducted to produce a product. Note that we are using the
word “product” in a very broad sense. A product can be an actual
tangible piece of hardware or a building. It can also be software
or a service of some kind. It can also be a result—consider, for ex-
ample a project to service an automobile that consists of changing
the oil and rotating the tires. There is no tangible deliverable for
such a project, but there is clearly a result that must be achieved,
and if it is not done correctly the car may be damaged as a result.
American Management Association • www.amanet.orgAn Overview of Project Management 19
Executing also refers to implementing the project plan. It is
amazing to ﬁnd that teams often spend time planning a project,
then abandon the plan as soon as they encounter some difﬁculty.
Once they do this, they cannot have control of the work, since
without a plan there is no control. The key is to either take cor-
rective action to get back on track with the original plan or to re-
vise the plan to show where the project is at present and
continue forward from that point.
Monitoring and Controlling
Monitoring and controlling can actually be thought of as two
separate processes, but because they go hand in hand, they
are considered one activity. Control is exercised by compar-
ing where project work is to where it is supposed to be, then
taking action to correct for any deviations from target. Now
the plan tells where the work should be. Without a plan, you
don’t know where you should be, so control is impossible, by
Furthermore, knowing where you are is done by monitoring
progress. An assessment of quantity and quality of work is made
using whatever tools are available for the kind of work being
done. The result of this assessment is compared to the planned
level of work; if the actual level is ahead or behind of the plan,
something will be done to bring progress back in line with the
plan. Naturally, small deviations are always present and are ig-
nored unless they exceed some pre-established threshold or show
a trend toward drifting further off course.
In too many cases, once the product is produced to the cus-
tomer’s satisfaction, the project is considered ﬁnished, or closed.
This should not be the case. A ﬁnal lessons-learned review should
be done before the project is considered complete. Failing to do a
lessons-learned review means that future projects will likely suffer
the same headaches encountered on the one just done.
American Management Association • www.amanet.org