eBookFourth Edition (Fourth Edition)
Available on Compatible NOOK devices, the free NOOK App and in My Digital Library.
Related collections and offers
Overview
Product Details
| ISBN-13: | 9780814417492 |
|---|---|
| Publisher: | AMACOM |
| Publication date: | 09/15/2011 |
| Sold by: | HarperCollins Publishing |
| Format: | eBook |
| Pages: | 208 |
| File size: | 3 MB |
About the Author
Read an Excerpt
Fundamental of Project Management
By JOSEPH HEAGNEY
AMACOM
Copyright © 2012 American Management AssociationAll right reserved.
ISBN: 978-0-8144-1749-2
Chapter One
An Overview of Project Management
What'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 certification process whereby qualifying individuals receive the Project 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, projects are more schedule-intensive than most of the activities that general managers handle. And the people in a project team often don't report directly to the project manager, whereas they do report to most general managers.
So just what is project management, and, for that matter, what is a project? PMI defines a project as "a temporary endeavor undertaken to produce a unique product, service, or result" (PMBOK® Guide, Project Management 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 definite starting and ending points (time), a budget (cost), a clearly defined scope—or magnitude—of work to be done, and specific performance requirements that must be met. I say "should" because seldom does a project conform to the desired definition. 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 defines a project as a problem scheduled for solution. I like this definition because it reminds me that every project is conducted to solve some kind of problem for a company. However, I must caution that the word "problem" typically has a negative meaning, and projects deal with both positive and negative kinds of problems. 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.
Project Failures
In fact, the Standish Group (www.standishgroup.com) has found that only about 17 percent of all software projects done in the United States meet the original PCTS targets, 50 percent must have the targets changed—meaning they are usually late or overspent 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 development nationwide, so this means that $80 billion was completely 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 projects. Product development, for example, shares similar dismal rates of failure, waste, and cancellation. Experts on product development estimate that about 30 percent of the cost to develop a new product is rework. That means that one of every three engineers assigned to a project is working full time just redoing what two other engineers did wrong in the first place!
I also have a colleague, Bob Dudley, who has been involved in construction projects for thirty-five years. He tells me that these jobs also tend to have about 30 percent rework, a fact that I found difficult to believe, because I have always thought of construction as being fairly well defined and thus easier to control than might be the case for research projects, for example. Nevertheless, several colleagues of mine confirm Bob's statistics.
The reason for these failures is consistently found to be inadequate project planning. People adopt a ready-fire-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 management to senior managers in companies, and I always cite these statistics. 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 find this to be true.
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 performance, or would those levels decline? If they decline, then we could argue that management must have been doing something positive, and vice versa. I doubt that many general managers would want to say that what they do doesn't matter. However, we all know that there are effective and ineffective general managers, and this is true of project managers, as well.
What Is Project Management?
The PMBOK® Guide definition of project management is "application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. Project management is accomplished through the application and integration of the 42 logically grouped project management processes comprising the 5 Process Groups: initiating, planning, executing, monitoring and controlling, and closing" (PMBOK® Guide, 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 explaining how these processes are accomplished.
It would be better if the PMBOK® Guide specified that a project manager should facilitate planning. One mistake made by inexperienced 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. Managers can't think of everything, their estimates of task durations are wrong, and the entire thing falls apart after the project is started. The first rule of project management is that the people who must do the work should help plan it.
The role of the project manager is 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 definition 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 believe should be done." The operative word here is "want." Dictators get others to do things that they want done. So do guards who supervise prison work teams. But a leader gets people to want to do the work, and that is a significant difference.
The planning, scheduling, and control 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 exceed those bare minimums. I offer a comprehensive application of project leadership techniques in Chapter 13.
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 failure 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 accomplish 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 learning. 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 with software?
One-Person Projects
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 definite starting point, target, end date, specific performance requirements, defined scope of work, and a budget. However, when no one else is working on the project (including outside vendors), there is no need for a critical path schedule. A critical 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 coordinating the work of other people, you aren't practicing true project management.
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, consisting of several people, the project manager inevitably finds herself 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 first place (remember our argument 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 first 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 increase, 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, 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 aptitude 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 covered in a book by Wysocki and Lewis titled The World-Class Project 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 finish the job by a certain time, within budget, and at a given magnitude or scope, while achieving specific performance levels. In other words, the sponsor dictates all four of the project constraints. This doesn't work.
The relationship among the PCTS constraints can be written as follows:
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 remaining one.
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 paramedic standing by when they give the cost figure 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 figure in mind, and your number will always exceed her figure. And she may say, "If it's going to cost that much, we can't justify doing the job." Exactly! And that is the decision 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 profits for the company. As someone has said, 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 a higher likelihood that the budget will be overrun than that the project will come in below budget. This is just another way of stating Murphy's law, that "whatever can go wrong will go wrong."
(Continues...)
Excerpted from Fundamental of Project Management by JOSEPH HEAGNEY Copyright © 2012 by American Management Association. Excerpted by permission of AMACOM. 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.
Table of Contents
Contents
Figure List....................ixPreface to the Fourth Edition....................xi
Acknowledgments....................xv
Chapter 1 An Overview of Project Management....................1
Chapter 2 The Role of the Project Manager....................24
Chapter 3 Planning the Project....................32
Chapter 4 Developing a Mission, Vision, Goals, and Objectives for the Project....................45
Chapter 5 Creating the Project Risk Plan....................55
Chapter 6 Using the Work Breakdown Structure to Plan a Project....................68
Chapter 7 Scheduling Project Work....................81
Chapter 8 Producing a Workable Schedule....................93
Chapter 9 Project Control and Evaluation....................112
Chapter 10 The Change Control Process....................125
Chapter 11 Project Control Using Earned Value Analysis....................141
Chapter 12 Managing the Project Team....................156
Chapter 13 The Project Manager as Leader....................168
Chapter 14 How to Make Project Management Work in Your Company....................180
Answers to Chapter Questions....................185
Index....................189
About the Authors....................201