Tom Kendrick the former Program Director for the project management curriculum at UC Berkeley Extension, and lives in the Bay area near San Francisco, California. He is a past award recipient of the Project Management Institute (PMI) David I. Cleland Project Management Literature Award for "Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project" (now in it's fourth edition). Tom is also a certified PMP and serves as a volunteer for both the PMI Silicon Valley Chapter and PMI.org.

CHAPTER 1

Control of Projects

P R O J E C T S AR E E V E R Y W H E R E. Some of these projects succeed; others do

not. Many projects fail because the project leader lacks sufficient control to

keep things moving toward a successful conclusion. Insufficient project control

is a result of many factors: lack of authority, geographically distributed teams,

excessive project change, competing priorities, and inadequate planning—just

to name a few.

Increasingly today, projects are undertaken in environments where the

project leader has little formal authority. Even for project managers with formal

authority, significant portions of project work are done by contributors who

work for other managers, often for a different company. Projects where no one

is in charge are almost certain to fail. As the leader of your project, you must

assume control, whether or not you possess organizational authority. As unlikely

as it may sometimes seem, any project leader can do much to establish

and maintain project control. This book has many ideas for achieving project

success using techniques that don’t depend on organizational position or on

formal authority.

Who’s in Charge?

In classes, workshops, and informal discussions of project management that

I’ve been a part of, one of the most common questions is, ‘‘How can I manage

my project if I have no power or authority?’’ This issue comes up so often that

I developed a list of things that project leaders can (and should) take control

of, regardless of their position or power in an organization. None of these

things requires any authority beyond what is implicit when you are delegated

responsibility for a project, and some don’t even rely on that.

Factors That Any Project Leader Can Control

• Measurement

• Reporting cycles

• Milestones

• Communication

• Project reviews

• Change management

• Rewards and recognition

• Constructive criticism

• Reciprocity and exchange

• Risk monitoring

Project leaders can use these means, along with many others in this book,

to enhance their control in any project environment. Because the techniques

outlined in the next several chapters don’t rely on the command-and-control

authority of the project leader, they are effective in cross-functional, agile, matrix,

heavily outsourced, virtual, volunteer, and other challenging environments.

In fact, even project managers with substantial authority will benefit from the

practices described in this book because they avoid the potential resentment

and demotivation that can result from pulling rank.

Structure of This Book

The first half of this book explores three elements of project control: process,

influence, and measurement. This introductory chapter introduces these elements,

and Chapters 2–4 dig into the details and show how to apply them in

your project environment.

The second half of the book examines when to use these three elements

for control throughout the life of a typical project. The Guide to the Project

Management Body of Knowledge (PMBOK Guide), from the Project Management

Institute, identifies five process groups: initiating, planning, executing,

monitoring and controlling, and closing. Chapters 5–9 map these topics, describing

how to better control your project from its beginning to its end. Where

the PMBOK Guide tends to assume that a project manager has formal power,

the discussion throughout this book focuses on controlling project work even

when you do not have such direct authority.

Each chapter begins by outlining the principal concepts for that chapter,

then explores each idea in detail using examples. Each of Chapters 2–9 concludes

with a summary of key ideas, and Chapter 10 summarizes the fundamental

ideas of the book and offers some final thoughts on applying them to your

projects.

This book contains many ideas—far more than any single project would

ever need. The advice ranges from tips useful on small projects to ideas for

dealing with the complexity of large, multiteam programs. Read through the

book using your own judgment to determine which ideas are the most effective

and helpful for your specific situation. To get started, pick an idea or two from

each section that you think will help you with your project. When you encounter

a problem, use the table of contents to locate pointers to deal with it, and

adapt the practices outlined there to move things back under control. Don’t

overcomplicate your project with processes that aren’t needed; if two approaches

to a project issue are equally effective, always choose the simpler one.