Read an Excerpt

PROJECT PLANNING, SCHEDULING & CONTROL

McGraw-Hill

Chapter One

The news traveled from the palace to the Valley of the Kings with incredible speed—Nefertari, the beloved wife of Ramses the Great, Nineteenth Dynasty pharaoh of Upper and Lower Egypt, had just borne him another son. The messenger was out of breath as he entered the murky darkness of the burial chamber and greeted Ashahebsed, builder of the tombs for the family of the great king.

"The new child has just arrived," he announced breathlessly, "a son." Ashahebsed was well aware of who he meant by "the new child." The pregnancy of Nefertari, one of two royal wives of Ramses, was well known throughout the kingdom.

Ashahebsed shook his head. Another tomb would have to be added. How many was this now? At last count, the king had sired 30 sons and as many daughters. With two royal wives, two Hittite princesses acquired through diplomatic marriage, and four of his own daughters whom he had married, following Egyptian tradition, Ramses was more than prolific. At 60 years of age, he was still fathering children at an alarming rate.

"By the great god Amun," Ashahebsed exclaimed, "at this rate, I'll never finish this project!"

"You're right," said the messenger. "I have been instructed to inform you that Isetnofret is pregnant again."

"The second royal wife of Ramses," thought Ashahebsed. "And so are the two Hittite princesses," he groaned.

"Don't forget Bant-Anat," the messenger offered.

This was Isetnofret's child, one of the four daughters that the pharaoh had married.

"It is clear that I will be on this project until the pharaoh dies," said Ashahebsed.

"It looks that way," agreed the messenger, as he turned to go out into the blinding Egyptian sun.

Ashahebsed may very well have endured the most scope changes, over the most extended period, of any project manager in history. Ramses the Great had more than 100 sons and daughters over his 90 years. He was pharaoh for nearly 65 years, and no doubt the building of tombs for his progeny extended over much of that time. The best that can be said is that Ashahebsed had job security. The worst is that the project just kept on going and going and going ...

WHAT IS A PROJECT?

The Project Management Institute (PMI®) is the professional association for project managers (more about them later). In the latest edition of the Project Management Body of Knowledge, or PMBOK® GUIDE (2008), the PMI defines a project as "a temporary endeavor undertaken to produce a unique product, service, or result." Temporary means that every project has a definite beginning and end. Unique means that this product, service, or result is different from others that may have preceded it.

Unfortunately, textbook definitions often don't reflect the real world. Ashahebsed's project definitely was not temporary; as the scope kept changing, the ultimate completion date slid out ever further until it disappeared over the horizon. And of course the budget had to change accordingly.

So this was certainly no textbook project. (In fact, if any of you know of a project that conforms to the textbook definition, please e-mail me about it so that I can write a case study!)

In reality, the only part of the definition that fits all projects is that all of them are jobs that produce something unique. Perhaps it would be better to say that they are intended to be temporary in nature, meaning a one-time job. A repetitive job is not a project. Neither is performing a single task. Nevertheless, a substantial number of jobs do qualify as projects, and there are many people managing them (or at least trying to).

Tom Peters (1999) has argued that as much as 50 percent of the work done in organizations can be thought of as projects. I believe that in many organizations, this number is far greater. This means that, even though not everyone who is running these operations is called a project manager, these people are de facto managing projects anyway. And, while they may not need the formality of critical path schedules and earned value analysis, they do need some skills in project planning and control.

Dr. J. M. Juran has also said that a project is a problem that is scheduled for solution. I like this definition because it makes us realize that a project is conducted to solve a problem for the organization. However, the word problem almost always conveys something negative. When someone says, "We have a problem," that is usually bad news. Environmental cleanup projects might be thought of as solving the "bad" kind of problem. But developing a new product or software program is also a problem—a positive problem. So problem is being used here in a very broad sense, and projects deal with both kinds of problems, positive and negative.

WHAT IS PROJECT MANAGEMENT?

The 2008 edition of the PMBOK® GUIDE defines project management as "application of knowledge, skills, tools and techniques to project activities to meet project requirements. Project management is accomplished through the application and integration of the project management processes of initiating, planning, executing, monitoring and controlling, and closing" (p. 6). These processes are further defined in the PMBOK® GUIDE, and the objective of this book is to explain how all of these are accomplished in practice.

I think it is important to mention that these processes do not fully capture the essence of project management. Much of project management consists of dealing with political issues, trying to get team members to perform at the required level, and negotiating for scarce resources. These activities are not really captured by the PMBOK® GUIDE processes, and no single document can do justice to the true complexity of project management.

"Instant-Pudding" Project Management

In December 1999, I met with a project manager in Germany, and we discussed whether project management in Germany was the same as it is in the United States. I showed him my model of project management, which I call The Lewis Method®, and compared it to his process. We found that his method and mine were nearly identical.

"I have been trying to explain project management to senior management here, but I'm afraid with very little success," he said sadly. "In one meeting, one of our vice presidents got very frustrated and said, "I don't understand why we don't just buy Microsoft Project® and do it!'" He added, "Meaning, of course, why don't we do project management."

I almost laughed. "It's the same in the United States," I assured him. "Senior managers there also assume that project management is just scheduling and that if they buy a scheduling tool for everyone, they will have instant project managers."

He looked a bit relieved.

"I think we should put the scheduling software in a box and rename it "Instant Project Manager,'" I said. "On the side of the box, the instructions would say, "Just add water, stir, shake, bake, and you will have instant project managers'—sort of an "instant-pudding' approach to project management."

He thought for a moment. "That's actually what we are doing now, isn't it? Practicing instant-pudding project management!"

"Yes," I agreed. "And I can tell you that this approach is followed throughout much of the world."

Tools, People, and Systems

Project management is not just scheduling.

It is not just tools.

It is not a job position or a job title.

It is not even the sum total of these. But my experience shows that few people understand this. They believe that project management is scheduling and that if a person can do some technical job (using the word technical in a very broad sense), then that individual can manage a project.

This is a pervasive problem. We forget that there are two aspects to all work, including projects—the what and the how. The what is the task to be performed. The how is the process by which it is performed. But process also applies to how the team functions overall—how its members communicate, interact, solve problems, deal with conflict, make decisions, assign work, run meetings, and every other aspect of team performance. The tools they use—such as scheduling software, computers, project notebooks, and daily planners—help with both the what and the how. But the tools do not make an instant project manager of a person who has not been trained in the how. (See Figure 1.1.)

Organizations and project teams are people. I think we forget this. An organization has capital equipment, buildings, inventory, and other paraphernalia for the sole purpose of enabling human beings to do work that will result in desired organizational outcomes.

Yet managers often focus on everything but people. I have been told of many managers who are brilliant with computers but absolutely horrible at dealing with people. They are rude, condescending, and dictatorial. You wonder how such individuals survive in their jobs, but they do.

In any case, the message should be understood—organizations are people, and people engage in processes to get results. If the people do not function well, neither will the processes; and if the processes don't work, task outcomes will suffer. The sad thing is that we know more about how to get performance from capital equipment than about how to get it from people.

As I have already said, project management deals with tools, people, and systems. The tools are work breakdown structures, PERT scheduling, earned value analysis, risk analysis, and scheduling software (to name a few). And tools are the primary focus of most organizations that want to implement project management.

Tools are a necessary but not a sufficient condition for success in managing projects. The processes or techniques are far more important, because if you do not employ the correct processes for managing, the tools will only help you document your failures with great precision.

A simple example is that you give a person an automobile so that he can get around, but you give him no training in how to drive the car. He must learn by trial and error. By the time he has become a competent driver (if he ever does), he will have battered up the car pretty badly, and in the process done quite a bit of damage to others. This is what happens when you give people scheduling software with no training in how to use it properly.

On the other hand, training someone who has no car how to drive is a waste. Absent the car, the training is irrelevant.

In short, the PMI definition of project management is not bad, as long as you understand that you must include dealing with politics, exercising leadership, and, for good measure, having a small dose of public relations expertise.

The Four Project Constraints

It has been common to talk about the triple constraints in project management—performance, time, and cost. Colloquially, they are often referred to as good, fast, and cheap, and as the saying goes, "Good, fast, or cheap—pick two." The point is that you can dictate only two of them, and the third will have to vary.

When I wrote the first edition of this book, I realized that there was a fourth constraint—scope. The magnitude or size of the job is also related to the other three constraints, and I started pointing out that you could assign values to any three of them, but the fourth must be allowed to vary. In fact, scope changes probably cause more missed project deadlines and cost overruns than any other factor short of defining the project requirements incorrectly to begin with.

I have learned during the past couple of years that many people are confused by the term performance, so I want to clarify it here. A project is intended to produce a result of some kind. Construction projects produce buildings for people to occupy, roads for them to travel on, or dams that provide water to communities. Product development projects provide products for people to use; software projects do the same.

There are two kinds of performance requirements, which together are called specifications. One is functional requirements. These describe what the deliverable is supposed to do. The other is technical requirements, which describe the features of the deliverable. They may specify dimensions, weight, color, speed, horsepower, thrust, or any of a million other specifications that can apply to a deliverable. As a former engineer, I used to ask if a change would affect the form, fit, or function of a product. You can see how this relates to what has just been said.

Defining project requirements is a major aspect of project definition, and doing so incorrectly or inadequately is, I believe, the single most common cause of project failures. I was once told a story by a fellow that illustrates this beautifully. He had a friend over at his house one day, and they were doing some yard work. He said to his friend, "You see this small tree in front of my house? How about trimming the limbs off this tree to a height about like this?" He indicated what he meant by holding his hand a certain distance above the ground.

He then left his friend to trim the tree and went to the back of the house to do some work. When he returned to the front of the house, his friend had just finished the job. It was nicely done, except for one significant detail. His friend had cut all of the limbs off the top of the tree, down to the proper height, when what the fellow wanted was to have the limbs trimmed off the trunk of the tree from the ground up to the height he had indicated!

What happened here is all too common. "Trim the tree" meant something different to each of them. We call this is a communication problem. And because communication problems happen so frequently, we had better take care to achieve a shared understanding of what is supposed to be done in the project. We will talk about how this is done in Chapter 5.

Elsewhere, I have said that project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. These requirements are defined by the PCTS targets and are the constraints on every project, no matter how large or how small. Because you can never escape them, you must understand how they interact.

The relationship between them is given by the following expression:

C = f(P, T, S)

In other words, cost is a function of performance, time, and scope. Ideally, this could be written as an exact mathematical expression. For example,

C = 2P + 3T + 4S

However, we are always estimating the values of these variables, so their exact relationship is never known.

One way to think of the relationship that exists between the PCTS constraints is to consider a triangle, as shown in Figure 1.2. P, C, and T are the lengths of the sides, while S is the area. If I know the lengths of the sides, I can compute the area. Or, if I know the area and the lengths of two sides, I can compute the length of the third side.

What is important about this illustration is that I cannot arbitrarily assign values to all three sides and the area. If three are specified, the fourth can be determined, but if you try to assign values to all four, they will "fit" only by accident.

In projects, however, it is common for the project sponsor or some other manager to want to dictate values for all four. This is, in fact, a common cause of project failures. As a project manager, it is my job to tell the sponsor what I need if I am to do a project. So consider the most common case, in which values for P, T, and S are given. It is my job to tell the sponsor the cost to achieve those targets.

It is also true that when I do so, the sponsor may have heart failure. The response is often, "My goodness, how can it cost so much!!?" followed by protests that, "We can't afford it!"

Then my response is, "Tell me what you can afford, and I'll tell you what I can do." This means that either the scope will be reduced or perhaps the time will be extended. In general, it is not acceptable to reduce performance.

Notice that this is a common trade-off that we make at home. We have a list of things that need to be done. The roof is leaking and needs to be repaired before it ruins the house. The car is making a strange noise. My 13-year-old daughter needs braces on her teeth, which will cost a bundle. And on and on.

Trouble is, I can't afford it all.

(Continues...)

---

Excerpted from PROJECT PLANNING, SCHEDULING & CONTROL by JAMES P. LEWIS Copyright © 2005 by James P. Lewis. Excerpted by permission of McGraw-Hill. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---