PREFACE

As we’ve paid increasing attention to project management practices over the last few years, we’ve formalized and “technocratized” the world of projects by setting up project management offices, cranking out Gantt charts and work breakdown structures, installing project management software, compressing critical paths, and comparing the actual cost of work performed against the budgeted cost of work performed. We’re focusing more on project management than we ever have before, but we’re still not making the progress we should be. And that’s because we’re focused mostly on project mechanics and not nearly enough on what really does and doesn’t make projects work—the “looser” pieces, the people pieces, the tuning-into-the-project-environment pieces.

Sure, we’re making progress on “keeping it tight”—project managers (PMs) are more educated than ever before; the number of Project Management Professionals (PMPs) is growing; and there’s a greater emphasis on project disciplines. But we’ve got some work to do when it comes to keeping it loose. We seem to have forgotten—or never developed—the critical skills needed to keep our projects light, fast, and flexible.

Effective project management doesn’t mean a slavish adherence to a mechanical set of practices. The repeated application of the same PM “stuff” the same way for every project quickly reveals the flaws in that approach: It falters because projects differ not just by size, but also by complexity, as reflected in the degree of risk and uncertainty inherent in them and in the number and variety of stakeholders involved with them.

Competencies, Processes, and Tools (CPTs)

Project management competencies—the Cs—are much more important than project management processes—the Ps—which in turn, are much more important than the project management tools—the Ts. Therefore, this book focuses on competencies first, processes where necessary to support competencies, and tools if (and only if) they’re required to support processes. (And by tools, I mean project management software in general.)

PMs first need to develop and then master the fundamental competencies of effective project management. They need to know how to manage stakeholders effectively, assess risk accurately, and look for and get agreement on the objective measures of project success, for example, before they bring processes and tools to bear.

The competency associated with effectively managing and communicating with stakeholders, for example, can be supported by the stakeholder breakdown process (see Chapter 11), but it certainly doesn’t require a software tool. Competent risk assessors may use the impact and probability assessment process (see Chapter 17) to communicate the risks that they’re seeing and how they’re seeing them from an impact and probability perspective, but that doesn’t require a software tool either. And PMs can establish workable measures of success for a project by using the Three Key Questions (see Chapter 9), but they don’t need PM software to manage against them. Tools don’t even come into the picture until far into project planning—if they’re required at all—and they’re really the last and the least important element of the Cs, Ps, and Ts.

Effective project management should never start with PM software. But I’ll bet you know a PM or two who wants to grab on to MS Project right from the start, to build a Gantt chart or a project evaluation and review technique (PERT) chart before, honestly, they understand what the project they’re cramming into the software is really all about. Some PMs take erroneous comfort in loading their project data into a PM tool, and they mistakenly assume that they now have a proxy for control. (“I have a Gantt chart … now we’re getting somewhere.”) This isn’t true: What these PMs are really doing is acting out the old saying, “If your only tool is a hammer, every problem looks like a nail.”

But we know better. We know that starting with a tool is never a good idea, and PM tools, in fact, aren’t even that important to a successful project. They’re so unimportant, in fact, that you won’t find them discussed in this book.

Flexibility

I don’t care what your manuals or textbooks say. The competencies, processes, and tools you bring to bear on a project shouldn’t be the same every time. Instead, the CPTs you choose should depend entirely on the kind of project you’re dealing with. Notice that I said kind of project, not size of project; choosing an approach to managing a project based simply on its size (which is often expressed as its expected cost) is overly simplistic and often less than useful.

To illustrate: Which project is “bigger” and more complicated to manage—one expected to cost $100 million or one expected to cost $25 million? What if I said that the $100 million project was about replacing an old pipeline with new pipe and that $80 million of its $100 million budget was for the purchase and installation of standard steel pipe on the preexisting pipeline right-of-way? And then what if I told you that the $25 million project was all about developing facial recognition software for the U.S. Department of Homeland Security? The pipeline project is certainly “bigger” than the software project in terms of cost, but it’s also much less complex, and it would be an amateur’s error—an error that’s made all the time—to assume that the CPTs the PM should bring to the table should be more comprehensive for the “bigger” project.

Size alone, then (and even more certainly, cost), is not a particularly good criterion by which to decide on the right CPTs. But complexity is. What are the best criteria to help determine a project’s level of complexity? How about risk? How risky is this project? How much don’t you know going in? Have you and your team ever done a project like this before? Does the amount of risk involved suggest what CPTs you might use and to what extent? It should.

How about uncertainty? Are you so experienced with what you’re doing this time that your early estimates can be considered “tight” and dependable based on previous experience, or are you estimating for something you’ve never done before? What CPTs would be most appropriate for a highly uncertain project?

And what about the number and variety of project stakeholders? Do you have a small, well-aligned stakeholder group or a large and diverse group with varied (and possibly contradictory) expectations of the project? What CPTs best support a diverse project stakeholder community?

The CPTs you choose to bring to the table for a project should be at least as dependent on risk, uncertainty, and stakeholder community as project size. Your response should be flexible but still within a consistent framework of CPTs.

Doing the same things, the same way, every time, on every project? That isn’t being much more than a project “mechanic.” The expert PM, on the other hand, demonstrates a consistent discipline in a considered and context-appropriate approach.

And that’s what this book represents: a flexible, looser, more stakeholder-aware framework of Cs, Ps, and Ts—the competencies, processes, and tools to use as appropriate and to the extent required by the characteristics of the project you’re managing.

But don’t think for a minute that this looser approach means a lack of rigor and discipline. This book is all about rigor and discipline in areas that PMBOK® Guide and PRINCE2 don’t cover as well. The CPTs presented here can each be used individually, but they’re even stronger when used together, where they complement, support, and interact with each other—and that’s where the real strength in the approach lies.

Help Right Here, Right Now, and in Context

Each of the CPTs I’ll describe can be used quickly, effectively, and independently of each other, and each should be seen as adding to rather than replacing the traditional disciplines that project managers and project management organizations have been building up over time.

Although they’re most powerful when they’re used as an integrated set, the CPTs are not prescribed as a comprehensive methodology. Most methodologies are too inflexible to be effective, so this book doesn’t propose to represent one. Instead, the book is set up so that you can dip into it at any point, find something you can use right away, and apply it immediately to the situation at hand.

In talking about the CPTs, I’ll deliberately focus on project management context as much as content, and I’ll explain them in the context of real-world situations and real projects I’ve worked on, and with real examples wherever confidentiality constraints will allow. This approach will, I hope, lead to you to say: “Yeah, I’m in a situation like that, and I can see how that C or P or T will help me in dealing with it.”

If I’ve got it right, this book should enable you to:

Clearly understand and communicate why a project is undertaken in the first place, and ensure that your measures of success and project stakeholders are aligned accordingly.

Get control of a project quickly by building a deliverables-and performance-based plan that explicitly reflects risk and uncertainty, that demonstrates a clear link to the expectations of the project stakeholder community, and that concentrates on the critically important communications that align the expectations of the stakeholder community right from the beginning and throughout the life of the project.

Start delivering value early by tracking and communicating the completion of important deliverables instead of activities. An interesting thing about PMs (and PM tools) and their fascination with activities: No one, especially the executives we report to, really cares much about activities, unless those activities specifically produce the deliverables they do care about. In Chapters 13 and 22, we’ll talk about measuring and reporting results and deliverables as a project progresses.

Look ahead, to forecast, rather than just report on what’s happened in the past and on money that’s already spent. It seems as if most of our reporting systems are based on telling us what’s already occurred, as if that were a satisfactory proxy for forecasting the future. It isn’t. Managing a project based on historic reporting seems to me rather like driving a car by looking in the rear-view mirror: “We’re pleased to report that we missed that mailbox one block back, and we’re glad to say we didn’t hit that fire hydrant, either.” We’ll talk here instead about forecasting costs, schedules, and the one key element that we tend to report on badly, if at all: project performance.

Finish cleanly and decisively—everyone agrees that we are, indeed, finished—with results objectively reported against measurable, well-communicated, and demonstrable criteria and ensure that project lessons learned are documented and shared across the organization for the benefit of the next project and the next team.

How This Book Is Organized

This book isn’t meant to be comprehensive, and you may even call it somewhat selective. What I’m aiming to share here is additive information: good stuff that can enrich and add depth to the competent project manager’s knowledge.

Throughout this book, we’ll take a look at some of our time-honored project management practices that, at times, can actually represent really dumb ideas. We’ll talk about the circumstances under which good, traditional PM ideas become dumb ideas and when and where these otherwise good ideas really are best applied. To be clear: I’m not suggesting that these dumb ideas (like steering committees, project kickoff meetings, and red-and yellow-and green-light project status indicators) are inherently bad; most often, they’re only really dumb in the context in which they’re used or at the time at which they’re applied. Many otherwise good project management practices become dumb ideas when applied slavishly, sloppily, pedantically (“‘cause it’s part of the methodology, that’s why!”), or at the wrong time.

The first part of the book is about the “guts” of an effective PM, the kind of thinking and acting that underpins everything that follows. Most of this stuff isn’t new or radically different, but it certainly isn’t common, either.

With the effective “thinking and acting” stuff in place, we’ll move to project planning, which is unfortunately usually mixed up in the broader definition of project management, and that’s a mistake. Project planning is a distinct and critically important undertaking that’s most often rushed and too often poorly done. Project planning must be seen as a necessary and separate precursor to managing a project, and the two shouldn’t be confused: project management starts after the planning is finished and approved, when management says, “Yes, this makes sense, and the formal baseline [costs, duration and performance], reflective of risk and uncertainty, is now set.”

And, by the way, a project should never be “kicked off” before planning is complete because it sends the wrong signal to your stakeholders: “They’re kicking off, they must have a solid plan, right?” Without a complete plan, what exactly are you kicking off? If your management is under the impression that your project has started once you begin planning, disabuse them of this incorrect assumption immediately. They need to be made to understand that we don’t start to manage projects until we have cost, duration, and performance targets to manage against.

Far and away, the biggest part of this book is devoted to project planning, reflecting the work and effort that should be put into it. With planning complete, the project management stuff—managing to the plan—is fundamentally a matter of:

Managing against a well-structured plan (the product of effective project planning)

A disciplined change-control process, if the planning was done well in the first place

A steady eye on the measures of success for the projects, those measures of success that arise from the reason(s) the project was chosen in the first place.

So to begin with the guts: Just what kind of fundamental thinking underlies all the Cs, Ps, and Ts covered in this book? What are the “keep it loose, keep it tight” things that we just feel in our unconscious, reptilian project manager brains, things that we just know in our guts are right, that we can build on and formalize?

The good news is that everything we need to know to be successful is accessible, commonsense, and decidedly nontechnical. It’s nothin’ you can’t handle—let’s get started.

Ken Hanley
October 2010