Real World Project Management: Beyond Conventional Wisdom, Best Practices and Project Methodologies

By Richard Perrin

If you're a project manager, you need this guide to fill in the gaps in the PM canon. The Project Management Institute's Body of Knowledge, fails to fully explain certain PM tools and how they work, among other failures. Real-World Project Management fills in those major gaps with irreverence, wit, and wisdom. For any kind of project you’re managing, this book presents the high-quality tools and tactics you need to succeed.

• Language: English
• Publisher: Wiley
• Release date: Feb 5, 2015
• ISBN: 9780470573761

Book preview

Introduction

The concept for this book originally grew out of feedback received over several years while I served as a director of development, a senior program/project manager, and corporate trainer teaching Project Management and PMP (Project Management Professional) preparation. Many aspiring and experienced project managers have noticed that there can be a substantial disconnect between how A Guide to the Project Management Body of Knowledge (PMBOK), published by the Project Management Institute, describes the framework of project management (PM) and how projects actually unfold in the real world. Given that project management is not for the faint of heart, one imagines that over the years some science of project management has evolved to help keep projects on track, on time, and on budget, and with a minimum of confusion. True, the theory is neat and tidy, but real life is very messy.

In addition to the mess most PMs must address, the story being spin-doctored by the senior executive suite of most businesses paints a picture of project discipline and process that bears little resemblance to the daily realities PMs face in managing projects. The PM is left with the somewhat schizophrenic task of attempting to reconcile what the business tells the world it is doing versus what it is actually doing. Most of the examples and cases are delivered from the point of view of the PM practitioner looking up from the trenches at what executive management claims is happening but dealing with what is actually happening. Thus, the entire first section of the book is addressed from the point of the practitioner looking up at the belly of the beast and dealing with it as best he or she can.

Finally, previous versions of the Guide (1996 and 2000 editions) contain a bewildering array of tools and techniques mentioned in passing, only a few of which are described even at the 50,000-foot level. Many PMs have experienced frustration in having to locate a wide variety of sources from which to obtain some information about each tool and technique, which has proved very time consuming and frustrating for most.

Therefore, this book is designed to help project managers, or anyone else faced with having to make a decision about anything, understand and utilize some of the most useful tools and techniques cited in the PMBOK, and to provide some depth and background in the use of these tools with some practical hints and tips in their execution. In addition, some specific recommendations are given that can be utilized to implement the decision tools without spending a fortune on software or requiring a PhD to understand. Most of the tools can be easily implemented utilizing Microsoft Excel or any other commercial spreadsheet package that contains a good library of statistical functions. In addition, there is a recommended reading list at the end of various chapters for those who are interested in pursuing any of the areas in greater depth.

Although we are merely scratching the surface of some areas that have significant depth and require significant study to know inside-out, this guide will at least get you to the point of understanding what they are and enable you to hold an intelligent conversation with anyone about the tools and techniques contained herein. As the saying goes, Project managers are a mile wide and an inch deep, meaning that they know something about everything but without requiring in-depth detail knowledge. The goal of this guide is to continue to be a mile wide but increase knowledge to about a foot deep.

Remember, the title of the PMBOK starts out with the words, A Guide…. It is not the Definitive Be-All-End-All Reference for Every Project Management Concept and Practice in the Entire Known Universe. Don’t worry about trying to learn everything—take the hitchhiker’s approach: Learn key tools and skills you can master and they will take care of you 99% of the time. (That’s better odds than you will get in the stock market.)

So, whether you are a novice PM, an experienced PM, or someone just looking for some help trying to decide what thinking or decision process to use to select the best new car, keep track of costs, schedule a home-improvement project, pick the best investment, analyze a business plan, or accomplish any other endeavor that involves complex decision making—try Real World Project Management on for size.

And when all else fails, developing a keen sense of humor will get you through the issues with fewer headaches, ulcers, and nightmares.

Richard J. Perrin, PMP SSBB QFDGB CSM

November 2007

Section 1

In the Project Trenches

Chapter 1

So … Where Are We with Project Management and What’s with All These Tools Anyway?

There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened.

—Douglas Adams

So MUCH HAS BEEN written about project management (PM) in the last 15 to 20 years that it’s difficult to find the few books that actually contain the information you need to be effective in project management. A lot of strange things have also been written about project management and project managers (PMs)—some of them insightful, some of them outright loony, and some completely inaccurate. However, all of these sources generally say that effective project management is a necessary thing to do if you want your projects to succeed.

So the first thing we will do is dispel some myths and inaccuracies about project management:

Myth #1: Project management fundamentally deals with soft skills.

This leaves the reader with the impression that mastering project management simply means quoting pop-psychology gurus and sitting around a campfire eating granola. I’m okay—you’re okay—group hug everyone!

Nope. Sorry folks, that’s not it. Even the so-called soft skills of negotiation and team building require study, understanding, and practice.

Myth # 2: Project managers spend most of their time in bean-counting microdetails that would only make a Vogon1 happy.

This is not exactly true. Project managers need to be detail oriented, but in reality, they spend most of their time communicating with the project team members and the project stakeholders to make sure everyone is on the same page. Many of the communication skills require the ability to take complex material and simplify it for senior management so that they get the big picture. Most C-levels don’t have time for excruciating detail.

Myth # 3: Project management is really just fluff—a lot of process for the sake of process.

If you analyze what a business does, something should become obvious: The business is either in production, that is, in an operational mode in which the product of the company is being marketed, manufactured, and delivered to customers, or undertaking projects to create, improve, or enhance a product, service, or process. Since at least half of what a business does can be considered a project, that’s a lot of business activity to be assigned to the fluff category. If you’re still not convinced, see the rebuttal in the section below.

Before we dive into this dissertation we need to address an important year for project management—1969. Here are some significant facts:

The Project Management Institute (PMI) was founded.

The United States landed a human being on the surface of the moon and returned him safely to Earth without being too much the worse for wear.

IBM was running its mainframe on punchcards.

In 1969, I worked for a small engineering company and was devoting my days and nights to the Apollo Program, designing and building launch critical hardware for the first stage of the Saturn booster. What you are about to read comes from first-hand experience.

In 1969, there was no IT industry to speak of—certainly the PC did not exist and mainframe computers were the stuff of science fiction. However, this was all about to change because of the U.S. manned moon landing. One of the problems NASA was facing was that they needed a mainframe-type computer on board the Apollo Command Module: Mainframes usually took up medium-sized rooms stuffed with vacuum tubes and machinery, and the Command Module only had room for a mainframe the size of a breadbox.

Enter Texas Instruments (TI). TI developed the CMOS chips that enabled the miniaturization of the cumbersome, multi-ton mainframes down to the size of a breadbox. What no one knew at the time, except for a few forward-thinking visionaries, is that this miniaturization would bring about the birth of products never before seen in the marketplace. The first of the products began to appear about eight years after the manned moon landing in the form of something called a personal computer (PC). In 1977, we had the Apple II, the Commodore PET, and Radio Shack’s TRS-80 (affectionately dubbed the Trash 80). Even TI entered the fray with the first 16-bit microprocessor in the TI-99/4 in 1979, and later with the much-improved TI-99/4A in 1981; and with that the PC and the modern IT industry was born.

Twenty-seven years later, the ubiquity of the PC, workstation, and server models all connected via LAN/WAN technologies makes the IT component a requirement for any business. Nothing runs without computers, from the mainframe to your cell phone/PDA—IT is everywhere.

PMI woke up to this fact in the early to mid-1990s and realized that the PMBOK model increasingly needed to address the management of software and IT projects. Thus, various software deployment models were added to the PMBOK to accommodate software/IT project concerns. Most of the discussions that follow will focus on this aspect of project management.

WHERE ARE WE WITH PROJECT MANAGEMENT?

Maybe a better question would be, "Where aren’t we with project management?"

The Standish Group, the 800-pound gorilla in researching IT project failure in the U.S. Fortune 1000, has produced some eye-opening studies that bear mentioning here. The Standish Group produces something called the CHAOS Report, which assesses the failure and success rates of IT projects in the United States. In 1994, the CHAOS Report showed the following startling results:

Total project expenditures: $250 billion

Total project success rate: 17%

Total project challenged rate: 52%

Total project failure rate: 31%

Cost of failed or challenged projects: $140 billion

Average cost overrun (for failed/challenged projects): 180%

The first time I read those statistics I had to find my jaw and reattach it to my head. Even more jaw-dislocating is the fact that, in terms of GDP, the money wasted on failed IT projects in the United States in 1994 made the cost of U.S. IT project failure the 23rd largest economy in the world. (GDP of all countries was taken from the 1994 CIA Factbook.) This represents the outcome of work done by people who possessed the necessary hard skills to do the job—that is, programming, networking, telecommunications, and so on.

Fast forward to 2004: After 10 more years of research, and 40,000 projects later, the January 2004 CHAOS Report showed the following startling results:

Total project expenditures: $255 billion

Total project success rate: 34%

Total project challenged rate: 51%

Total project failure rate: 15%

Cost of failed or challenged projects: $55 billion

Average cost overrun (for failed/challenged projects): 43%

In other words, the project success rate doubled, the project failure rate was more than cut in half, $85 billion dollars were saved, and cost overruns were cut by more than 75%.

Most of this change was attributable to implementing effective project management controls where none or inadequate controls existed before and the development of repeatable, predictable process in the form of quality improvement.

This $85 billion reduction in waste and the elimination of failed projects is what occurred when the so-called soft skills that are described in Myth #1 were implemented. That’s a lot of hard currency saved just from eating granola. There is measurable, documented, hard improvement from implementing effective project management processes in an organization. The improvements are substantive and real.

Yet, in spite of the improvements and the trending in the right direction, we are still a long way from numbers that most evaluations would deem a success. Consider the following:

A grade of 34% correct on any exam in the U.S. public school system would earn the student a failing grade. This puts the 2004 CHAOS Report project success rate into a slightly different perspective, doesn’t it? A grade of 34% on any test I took in high school would have gotten me grounded for a week. However, in this case, the score is more a reflection on the quality and effectiveness of the instruction than on the desire to learn or the natural ability of the student. We continue to fail at effectively educating our people. More interesting than that, the executive suite consistently ignores the data that points to the issues and consistently fails to do anything about it. We will address some of those issues in this book and prescribe some cures that are proven to work.

After 10 years, more than half the projects continue to be challenged. A challenged project means, according to The Standish Group, that the project (1) was past the due date, (2) was over budget, (3) was lacking in critical features, or (4) was missing written requirements. The fact that this number has barely changed in 10 years is disturbing to say the least. It points to an ongoing failure of most U.S. companies to properly scope, define, or get the necessary buy-in for at least half the projects that are attempted.

Although PMI has put forth a usable framework for project implementation, there still remain gaps in the application of the framework that confuse many practitioners. Part of the issue lies in the PMBOK itself. Many students and colleagues have expressed dismay with the framework even after passing the PMP (Project Management Professional) examination and achieving the certification of Project Management Professional. There continues to be an ongoing disconnect between how the framework states a project should be managed and how projects are actually managed in the real world.

This is not as much of an issue in industries where the project process has existed in essentially the same form for years and is well understood, such as in the construction industry. A practitioner can utilize well-documented estimates for construction processes, such as are found in the publications offered at the R.S. Means web site. Here, the practitioner can obtain the construction cost estimation price guide used by professional construction estimators to obtain accurate pricing, by U.S. region, for almost every conceivable job that occurs at a construction site.

However, for the software industry, no such guide yet exists. While there are guides that discuss best practices, there exists no guide that offers price points or time estimates for well-defined software components or products. The practitioner is faced with the option to either go online to CDW or some similar distributor and perform a competitive price comparison for shrink-wrapped software applications, or create requests for proposals (RFPs) to obtain competitive bids for custom software development.

While the construction industry is considered an area consisting of well-established mature processes and technology (after all, the Pyramids are still standing after thousands of years), the software industry is, in contrast, more like a cantankerous, obstinate, argumentative teenager fraught with post-pubescent angst and the occasional suicidal depression who will fly into a rage whenever a parent (the business) requests that he clean his room or suggests that his behavior appears erratic or unfocused, or that his bad habits continue to be (defiantly) repeated despite numerous requests to conduct himself to the contrary. After all, the electronic data storage medium that finally replaced punchcards for the mainframe—the IBM 3380 disk pack—came into existence only in 1980, merely 27 short years ago. It took until 1990 for IBM to roll out the first PS/1 PC equipped with a 286 CPU. Sixteen years later, this machine is considered an antique. However, in spite of the geometric improvements in the quality and capability of hardware and software tools in the last 16 years, the parallel development of comparable business processes has been painfully slow. As a result, a project manager can effectively manage a construction project utilizing the PMI framework with little difficulty; but managing a software or IT project, especially a complex one, is a very different story.

Yet, in spite of this disconnect, many businesses look at project managers with the PMP certification as a magic bullet that will somehow make their troubled projects suddenly work. At many companies seeking skilled project managers to manage the ever-increasing number of IT projects—with fewer resources—a PMP certification is a prerequisite to being hired, even if you have an MBA or a PhD!

Part of the issue lies with the PMBOK framework itself. There is little guidance from PMI regarding the priority of the defined process areas, leaving readers at loose ends:

Which of the inputs, outputs, and tools and techniques in each of the process areas are of the most value to the practitioner? These elements are not prioritized in any way.

Some descriptions in the PMBOK are not clear and leave the reader confused.

Some of the more important and relevant tools are only mentioned in passing or glossed over in the PMBOK.

Here is a list of tools that are referenced in some detail, simply mentioned in passing, or implied in passing by the 2000 or 2004 editions of the PMBOK in each process area. They are organized by the chapters in the PMBOK in which they are referenced in each Tools and Techniques section:

Project Integration Management: Monte Carlo analysis, project management information system, earned value management, change control system

Project Scope Management: Decision trees, forced choice, Analytic Hierarchy Process, logical framework analysis, cost/ benefit analysis, work breakdown structure (WBS), functional decomposition

Time Management: Precedence diagramming method, analogous estimating, critical path method, PERT, GERT, Monte Carlo analysis, variance analysis

Cost Management: Parametric modeling, analogous estimating, bottom-up estimating, earned value management, discounted cash flow (implied processes: present value (PV), net present value (NPV), and internal rate of return (IRR) calculations)

Quality Management: Cost/benefit analysis, design of experiments (DOE) (implied process: Taguchi designs), flowcharting, control charts, Pareto charts, cause-and-effect diagrams, statistical sampling, trend analysis, audits, histograms

Human Resource Management: Team-building activities (implied process: conflict resolution), reward/recognition systems, collocation, training, organizational theory (implied processes: Theory X/Y, Maslow’s Hierarchy of Needs, Herzberg’s Hygiene Theory, expectancy theory, achievement theory, contingency theory)

Communications Management: Variance analysis, trend analysis, earned value analysis, sender/receiver models (implied process: lines of communication calculation)

Risk Management: Brainstorming, Delphi technique, checklists, cause-and-effect diagrams, influence diagrams, SWOT analysis, Monte Carlo analysis, risk analysis matrix, sensitivity analysis, decision tree analysis, earned value analysis

Procurement Management: Make-or-buy analysis, contract type selection, weighting system, screening system

The PMBOK does a reasonable job of describing the precedence diagramming method and the computation of earned value—we will not rehash them in detail here. The focus we will take in this book is first on some of the critical tools that the current millennium PM must master, because the tools usually provide a measurable, quantifiable output that enables the project manager, management, and stakeholders to deal with issues based on data and fact.

Because the PMBOK is an overview, most of these critical tools are mentioned only in passing, leaving the user with the daunting task of performing extensive web searches to find whitepapers, books, and tutorials on the subjects mentioned. It is these tools and their implementation that will be the focus of this book, specifically Monte Carlo analysis, decision tree analysis, design of experiments, Ishikawa tools, analytical hierarchy process, and lean process tools.

All these tools provide critical data and fact in the following PMBOK areas: human resource conflict management, schedule and timeline management, communication planning, stakeholder analysis, risk management, risk identification prioritization, and procurement management selection criteria. The quality tools such as the Pareto chart, cause-and-effect diagrams, and SPC charts are similarly glossed over in the PMBOK. We will devote considerable time to these processes so that they are demystified and made useful to the novice or experienced PM.

The remaining tools will be detailed to the extent that the PM will be able to add them to his/her PM toolbox and be knowledgeable in their use as well as when to use them for the best result.

You might be a novice PM, an experienced PM, doing PM tasks without having the formal title of PM, or making a decision about:

Which job offer you should take

What neighborhood to move into

Where to send the kids to school

What family car to buy

Evaluating the best IRA investments

Finding the most enjoyable vacation you and your family can go on

Which project provides the strongest financial benefit to the company

What tools are best for collecting project metrics

Designing and building your dream house

The best contractor to rebuild your kitchen

Deciding the critical features of your company’s new ERP system

Deciding on the best construction company for your new corporate headquarters

How to solve the city’s bussing issues

How to mange new product/project development given that the PMI framework doesn’t seem to fit your company’s needs

What would be the best process to make crops grow—in the desert

How to determine the real probability that your project will complete within the given timeline and budget, and how to manage the risk

The effectiveness of your decision tools, decision processes, and your ability to execute will make the difference between success and potential disaster.

Finally, from the perspective of organizational project management, it is always better to plan how the organization will implement the project lifecycle in an organization; how the Project Management Office will be organized, with its strategic and tactical purpose; how PMs will be trained; what standards, tools, and techniques will be implemented, and so on. It is best to do this kind of planning with a clear head and an eye for what the organization hopes to accomplish 5 or 10 years down the road.

Yet, most organizations do their organizational project planning in crisis, aka Monsoon mode (i.e., trying to fix the hole in your roof that is gushing water while in the middle of a monsoon). At best, the process is haphazard and produces minimally useful PM disciplines and processes. At worst, the processes gradually fall into disuse, leaving the organization as bad as or worse off than it had been because management never fully supported the effort from the start. Do yourself a favor and do your planning in an unstressed state—you’ll make better decisions.

NOTE

1. The Hitchhikers Guide to the Galaxy, by Douglas Adams, Del Ray 1995. If you don’t know what a Vogon is, read the book or see the movie.

Chapter 2

The Quality Lesson—Can We Get It Right This Time?

Politicians use statistics like a drunken man uses a lamp-post: for support rather than illumination.

—Attributed to Andrew Lang

THE ABOVE QUOTE APPLIES equally to the CEO, CIO, CFO, or CTO of your organization. If it did not, Sarbanes-Oxley would not be necessary and the incredible financial malfeasance at Enron, WorldCom, and Global Crossing would have never occurred at the disastrous levels that brought these companies and their CEOs down.

Nonetheless, it did happen and there were huge losses—not only to the companies in question, but to their employees and society at large. We are all worse off because of the almost incomprehensible fraud perpetrated by the leaders of these organizations. The loss to society is a key concept that keeps coming back in the writings of all the quality gurus of the last 50 years. From Deming, Juran, and Crosby, to Ishikawa, Akao, and Taguchi, the message is the same: When quality suffers, everyone suffers.

Probably one of the most problematic chapters in the PMBOK is the chapter on quality. The most recent version of the PMBOK (2004) has made some minor improvements, but fundamental issues remain. A case in point follows that describes the Cost of Quality (COQ)—paragraph 8.1.2.4:

Quality costs are the total costs incurred by the investment in preventing non-conformance to requirements, appraising the product or service for conformance to requirements and failing to meet requirements (rework)…. Failure costs are also called cost of poor quality.

This paragraph implies that the costs for preventing nonconformance constitute the greatest costs for quality, followed in descending order by appraisal costs and failure costs. It also implies that there is an additional cost to implement quality above and beyond the normal cost of doing business that has to be accounted for separately in the project budget.

This statement is curious given that in 1999, the PMBOK framework was certified as ISO 9000 compliant. ISO elaborates, if nothing else, a set of specifications that define minimum quality standards across a wide variety of industries. In essence, the entire PMBOK is a quality process.

In reality, PMI’s definition of quality costs misses the point: When is it not cheaper to do the work right the first time? That’s what implementing quality does for your project.

Phil Crosby, the VP for Quality at ITT under the legendary CEO Hal Geneen, in his 1979 book, Quality Is Free, said it best:

The cost of quality is the expense of doing things wrong. It is the scrap, rework, service after service, warranty, inspection, tests, and similar activities made necessary by non-conformance problems.1

Reading through the chapter on quality, it appears PMI’s message is that quality is not something that is inherent in the project, but something that is tacked onto project processes that has to be managed and controlled, just like the budget, the timeline, and scope. This promotes the idea that quality is something you obtain from a vending machine or can install like a laser-jet printer or a desktop PC. To me, the concept of Quality Control is an oxymoron: Why would anyone attempt to control quality?

Instead of looking at a project as a series of vending-machine handles that the user pulls to obtain a cost bucket, a timeline bucket, a scope/requirements bucket, a risk bucket, a human resources bucket, a procurement bucket, a communications bucket, and, yes, even a quality bucket, let’s turn the paradigm on its head and approach the project from the only perspective that makes sense from the customer’s point of view: Deliver a product or process that guarantees predictable quality, predictable costs, and a predictable timeline and that meets or exceeds my expectations.

In other words, if we wrap the entire project in an envelope of quality and ensure that we are delivering customer value at every step in the process, every process in the project framework becomes a quality process: from the elaboration of scope, to the development of the project timeline, costs, risk assessment, human resource allocation, vendor management, and so on.

In order to see how we implement the project from a quality perspective, some history from the quality leaders of the past 70 years is in order. The first step we shall take is to answer a fundamental and obvious question: What exactly do we mean by quality?

The International Organization for Standardization (ISO) defines quality as:

The totality of characteristics of an entity that bear on its ability to satisfy stated or implied needs. (ISO 8402, 1994).

That’s a fairly succinct and straightforward definition, albeit terse and vaguely clinical. It encompasses the basics but leaves most of us with a nebulous, unsatisfied feeling. Most people ask me, What do they mean by ‘stated or implied needs?’ You have to extrapolate that statement a bit to divine what is meant here. Stated needs are what the user or stakeholder tells you. Implied needs are what the stakeholder or user doesn’t tell you. If you didn’t take that college course—Requirements Clairvoyance 101—you might have real trouble deducing the implied needs. (We will address the implied needs concept in a later chapter).

There may be any number of reasons for the presence of implied needs: from an assumption that you completely understand the user’s business, and therefore no explanation is necessary, to deliberate obfuscation on the part of the user. (The latter happens more than anyone cares to admit.) In any case, determining implied needs takes experience, skill, finesse, tenacity, and the ability to build trust with the stakeholders so that they will share what is really on their minds.

A better, more understandable definition for quality was put forth by Peter Drucker:

Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for. A product is not quality because it is hard to make and costs a lot of money, as manufacturers typically believe. This is incompetence. Customers pay only for what is of use to them and gives them value. Nothing else constitutes quality.2

The reason Drucker’s definition is much more satisfying is that he implies that the idea of quality is fundamentally relational in nature. Other than wanting to implement predictable, repeatable processes that save the business time and money, why bother to implement quality processes at all? Why do we go through all the effort? The payoff is that when the product exceeds expectation or delights your customer (because it works so well), you have