Read an Excerpt
Fundamentals of Project Management
By Joseph Heagney AMACOM
Copyright © 2016 American Management Association
All rights reserved.
ISBN: 978-0-8144-3737-7
CHAPTER 1
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 462,000 in 2015. 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 5,000 hours) and pass an online exam that is based on the Project Management Body of Knowledge (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 create a unique product, service, or result" (PMBOK® Guide, PMI, 2013, 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 (performance, cost, time, scope) targets.
Dr. J. M. Juran, the late quality management 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
Current studies indicate mixed results regarding project management success rates. The Standish Group's recent Chaos report, with a focus on software development projects, indicates a 29 percent success rate, with 52 percent challenged, and 19 percent failed. It should be noted that success factors have been "modernized" to mean on time, on budget, and with a satisfactory result. The success rate is virtually unchanged from the 2011 report. Standish does emphasize that smaller projects have a much higher success rate than larger ones. Gartner, an IT research and advisory company, echoed these findings with recent reports that larger projects (those with budgets exceeding $1 million) have higher failure rates, hovering around 28 percent.
Most telling were the data recently reported by the Project Management Institute. PMI consistently measures the state of project, program, and portfolio management. Their 2015 "Pulse of the Profession" study reveals some positive trends but also indicates the percentage of projects meeting their goals has remained flat at 64 percent since 2012. To effect improvement, PMI suggests that organizations go back to fundamentals. The three basic areas cited are:
1. Culture. Work to create a project management mind-set.
2. Talent. Focus on talent management, continuous training, and formal knowledge transfer.
3. Process. Support project management through the establishment and adoption of standardized project practices and processes.
My own survey, based on 28 years of project management, best practice identification, project consulting, and training, reveals that the more things change, the more they stay the same. Not enough planning is being accomplished. Large or small, software, R&D, or administrative, successful projects rely on good planning. Too many project managers take a ready-fire-aim approach in an attempt to complete a project quickly. Many organizations do not allow project managers significant planning time or virtually any time at all. This often results in spending far more time and effort reworking errors, soothing unhappy stakeholders, and backing out of blind alleys. In short, the lack of adequate planning causes projects to fail.
The PMI survey states that "it is time for organizations to revisit the fundamentals of project management and, essentially, go back to the basics" (p. 4). I could not agree more. You, the reader, must lay your foundation and understand the basics presented here to ensure improvement and success as you move forward and manage your projects.
What Is Project Management?
The PMBOK® Guide definition of project management is the "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 47 logically grouped project management processes comprising the 5 Process Groups: initiating, planning, executing, monitoring and controlling, and closing" (PMBOK® Guide, PMI, 2013, p. 6).
The new PMBOK® Guide has added five new project management processes:
1. Plan Scope Management
2. Plan Schedule Management
3. Plan Cost Management
4. Plan Stakeholder Management
5. Control Stakeholder Management
This change emphasizes the requirement for the project team to plan prior to managing. The processes Plan Stakeholder Management and Control Stakeholder Engagement have been added to coincide with the addition of Project Stakeholder Management as the new (tenth) knowledge area (see page 22). This new knowledge area highlights the importance of appropriately engaging project stakeholders in key decisions and activities.
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 projects for their teams. Not only do they get no buy-in to their plans, but their plans are usually full of holes. Managers can't think of everything, their estimates of task durations are wrong, and everything falls apart after the projects are 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 all else — a leader, in the truest 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 (Crest Books, 1962). 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 parts 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 14.
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 7). 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?
The Accidental project Manager
Have you been suddenly thrust into the role of managing a project without the title "project manager" or much support? Did you consider yourself the project manager and the project team? You are not alone. Increasingly, individuals are managing work that fits the PMBOK® Guide (PMI 3, 2013) definition of a project: "a temporary endeavor undertaken to create a unique product, service, or result." There is a deadline, a scope of work to define, limited resources, and often a fixed budget. Although less formal and not requiring a project team, these projects must be planned, scheduled, and controlled. An exceptional/acceptable project product must be delivered and the customer delighted or at least satisfied.
"Essentials of Project Management for the Nonproject Manager" is a seminar that I lead for American Management Association International. It is very popular and has struck a chord with nontraditional project managers, subject matter experts, sponsors, and project contributors. Typical attendees include sales managers, administrative professionals, marketing managers, procurement specialists, and many other business types. It seems that everyone is involved with projects on some level. These attendees are not project managers in the traditional sense but must manage projects. Project management tools can help. I like to tell my attendees that project tools are universal but the value is evident in how the tools are applied.
First, assess the work. Are you constrained by scope, cost, and limited resources? Do you have a deadline? Then commit to managing the work as a project. Determine which project tools would be appropriate. For example, a project with a deadline of two weeks requires far fewer project management applications than a project due in 50 weeks. Streamline or expand your management approach to align with the length, width, depth, and breadth of the project.
The Big Trap: Working Project Managers
It is common to have individuals serve as project managers and also require 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, while allowing 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 Robert K. Wysocki and James P. 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 P, C, T, and S constraints can be written as follows:
C = f (x) (P, T, S)
In words, 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 parameters for 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 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.
(Continues...)
Excerpted from Fundamentals of Project Management by Joseph Heagney. Copyright © 2016 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.
