主页 Results Without Authority: Controlling a Project When the Team Doesn't Report to You

Results Without Authority: Controlling a Project When the Team Doesn't Report to You

ItÆs tricky enough to spearhead a big project when youÆre the boss. But when youÆre the leader of a team of people who donÆt report to you, the obstacles are even greater. Results Without Authority is the definitive book for project managers looking to establish credibility and control. A groundbreaker in the field, it supplies a start-to-finish system for getting successful project results from cross-functional, outsourced, and other types of teams. The completely updated second edition includes new information on: ò Agile methods and evolving project management tools ò Strategies for working with virtual teams ò Analytical versus ôblinkö decision processes ò The use (and misuse) of social media in project environments ò The myth of multitasking. For project leaders lacking clear-cut authority, getting everyone on boardùand keeping them thereùcan be a challenge. Results Without Authority is the must-have guide for getting the best results from your team
Second Edition
EPUB, 816 KB
下载 (epub, 816 KB)

You may be interested in Powered by Rec2Me


Most frequently terms

You can write a book review and share your experiences. Other readers will always be interested in your opinion of the books you've read. Whether you've loved the book or not, if you give your honest and detailed thoughts then people will find new books that are right for them.
Results Without Authority—Controlling a Project When the Team Doesn’t Report to You, Second Edition

Chapter 1: Control of Projects

Projects are everywhere. 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.

Elements of Project Control

Every project leader has a number of levers available that increase project control. Three principal elements of control are:

1. Project processes

2. Influence

3. Metrics (measurement)

Project processes provide the structure necessary for control and can serve as an effective substitute for organizational authority. You can build influence in many ways, and the more you are able to sway, encourage, or win over those you are working with, the better you will be able to control your project. Measurement quantifies results and drives behavior, so metrics are useful for both understanding the status of your project and encouraging cooperation. With these three techniques, you can control and be successful with any type of project.

Project Processes

Some years ago, a good friend celebrated a fiftieth birthday at a bowling alley with about a hundred friends. (Names are withheld to shield the guilty.) Because most of us in attendance were of roughly the same age and few had bowled more than once in the previous three decades, the initial frames we bowled were spectacularly pathetic. In the intervening years, the gutters on either side of the lanes seemed to have developed an almost magnetic attraction for bowling balls. Some people were halfway through their initial game and still trying to knock down their first pin.

Fortunately, the alleys had bumpers on either side, which we soon flipped into position on almost all of our lanes. These bumpers ran the length of the lane over the gutters, so balls that would have otherwise fallen out of play were bounced back onto the lane. With more balls rolling toward the pins (if not exactly in the center of the alleys), scores improved dramatically.

Good processes for projects are analogous to bumpers in bowling. Well-defined processes, properly applied, keep projects from rolling off into the gutter. Project processes are a source of substantial control, and they are usually owned by project leaders because much of the work is their personal responsibility.

Early in a new project, a project leader can easily influence even project processes that others own as they are being established. Most people can recall the unpleasant results caused on projects that lacked sufficiently defined processes. Your team members, stakeholders, managers, and sponsors are all likely to agree to process discipline that addresses past problems and inefficiencies. When initiating your overall project infrastructure, work to define all processes affecting your project team, and to get them accepted by everyone in advance.

Processes permeate the project life cycle. Some are related to specific phases of project work, such as those for requirements definition, scope freeze, baseline planning, risk identification, and project review. Other processes apply throughout a project, such as those for communication and change management. Whatever their timing, clearly defined processes are bumpers that enable the project leader to keep the ball rolling toward the final objective. Project processes are the main topic of Chapter 2.


In projects, as in most situations, people tend to work on the things that they want to work on. Even when a leader’s authority is absolute, ordering people to do something doesn’t make them want to do it. Using command-and-control authority to force people to do things unwillingly leads to resentment and demotivation. Malicious compliance is also a risk; people may find ways to appear to cooperate while actually harming the project. In extreme cases, some people will fail to do as they are asked even when the personal consequences of non-compliance are severe. If generals and admirals cannot always expect automatic obedience, what chance does a project leader have?

Nevertheless, as project leader, you have a fairly good chance of gaining support if you use the correct approach. Getting cooperation is much easier when you have a two-way relationship of trust and respect with your team members. Effective project leaders create this essential foundation for influence through team-building activities, formal group events (such as project start-up workshops), and informal one-on-one interactions. The surest path to cooperation starts with establishing strong social relationships in which people don’t want to disappoint each other.

Another way to enlist willing cooperation is to involve your project staff in activities that they want to work on. When a team member is enthusiastic about the project work, there’s no trick to it; the project leader has little more to do than assign ownership and stay out of the way. When project work does not appeal to the members of your project team, however, you must work to create interest in it. The principal technique begins with an understanding that everyone’s favorite call letters are WIIFM: What’s in it for me? Leaders in any field invest the time to understand what the people they are working with really care about. Effective project leaders identify opportunities to align the project’s needs with what the individuals want to do, and they assign responsibility for project activities accordingly. The tools of influence rely on reciprocity —an exchange of something that the individual wants for the commitment to complete work that the project requires.

Another key to influence is effective communication. Either project leaders are good communicators, or they are not project leaders for long. Communication is the one absolutely undisputed responsibility owned by the project leader, regardless of project type, other responsibilities, or authority. To succeed and retain control, you must manage information and always communicate effectively.

Formal project communication includes written documentation for your project, such as plans and progress reports. Using the power of your pen, you can control your project through filtering and summarizing and by deciding how best to distribute information and when.

Informal communication is also an essential component of project control. Influence and relationship building depend on frequent conversations and other casual interactions. Often you will learn about project problems much earlier through informal discussions than from formally collected project status. The earlier you can detect problems, the more options you have. Control depends on the quick resolution of issues and problems. You can also influence others by asking revealing (and sometimes embarrassing) questions. When your authority is insufficient to avoid situations that could harm your project, asking a pointed question or two at the right time can have the same effect. Your perspective as the project leader—understanding the work, the capacities of your team, and the project’s priorities—enables you to guide people to rational conclusions that are consistent with project success.

Establishing and using influence for project control is explored in detail in Chapter 3.


Control in any environment relies on measurements. Without clearly defined limits, the very concept of control lacks meaning. In addition to the obvious role of metrics in determining overall project performance, metrics also affect the behavior of the project team. As Bill Hewlett, founder of the Hewlett-Packard Company, is reputed to have said, “What gets measured gets done.” Measuring a few key things on a project and publishing the results powerfully affect your project’s progress.

A small set of well-defined project metrics gives the project leader a powerful tool for managing project initiation, execution, and closure. Effectively using project measurement for project control is the topic of Chapter 4.

No One Ever Said That Projects Are Easy

One analogy I like to use is that running a project is like driving a vehicle down a steep hill. Control of a moving vehicle involves the use of the steering wheel, the accelerator, and the brake. Having all three is nice. With projects, however, someone else’s foot is on the accelerator, and, if you brake, you will be late. You do have both hands on the steering wheel, though. So you steer with process, influence, and metrics, keeping your trajectory as true as you can. With adequate preparation, diligence, and attention to detail, you can reach your destination, exhausted but exhilarated, with no casualties and only a few scratches, dings, and minor dents here and there. Project control starts at project initiation, and it requires your full attention all the way to the end. Applying the concepts you find in this book will carry you safely to your destination: project success.

Chapter 2: Control Through Process

Most modern projects are difficult. Lacking effective project management processes, most projects fall into certain chaos. Projects undertaken using practical methods have a much better chance of success, especially when the project leader has little formal authority.

The foundation of effective project management has been established for a very long time. Proposing—and gaining support for—clearly defined project processes that make sense in your environment can significantly improve control over your projects. Adopting proven project practices with your team provides structure and guidance that provides you with additional levers to use in influencing your team. When you lack (or prefer not to rely on) formal authority, employing good processes that your contributors understand and use can keep your project moving in the right direction.

This chapter outlines important processes that can be used to improve your ability to keep a project under control. We also explore the benefits of a well-defined project infrastructure and how to take advantage of a structured project office.

Project Management Processes

Successfully managing a project involves at least three separate activities: achieving project objectives, managing the project processes, and leading the team. The overall objective, the most visible of the three, depends heavily on processes and leadership. The best project leaders spend much, if not most, of their time interacting with people, and productive team leadership is the main topic of Chapter 3. The focus of this chapter is on managing processes. Project leaders who collaboratively fine-tune the project processes used by their teams gain control in two ways. Using processes that project contributors and stakeholders participate in defining augments the trust and collaborative environment that successful projects depend on. In addition, getting voluntary commitment to use well-defined processes encourages appropriate behavior; it’s a lot more straightforward to lead a project by helping people follow agreed-on processes than by ordering your team to do things because you say so.

Some project processes are built in; that is, your organization does things in a certain way, and you and your project team have little choice but to conform. Even when the principal processes are mandated in advance, however, some processes belong solely to the project leader, and still other project processes involving your team and project stakeholders are at least partially yours to influence and control. Gaining the necessary buy-in and commitment needed to adopt new project processes or to improve existing processes may require some effort on your part. The effort is easily justified in most cases, though, especially when defining processes that can make the difference between a project you are able to keep on track and one that tumbles into chaos. Some project processes that can help are:

 Life cycles and methodologies

 Project definition and charter

 Project planning, execution, and tracking

 Change management

 Information management

 Project management software tools

 Contract and procurement management

 Risk management

 Quality management

 Issue management

 Decision making

Before doing a lot of work defining (or redefining) processes, assess where your organization stands on project management generally. Project management processes are far more effective in organizations that place value in developing and applying project management skills and methods. High-performing project management organizations have:

 Easy access to project management training, mentoring, and support

 A process for project manager/leader selection that is orderly and that creates few accidental project managers

 Programs that reward project achievements and teamwork instead of individual heroism

 Strong standards for project documentation, with periodic meaningful review of project information

 Ongoing support and sponsorship by higher-level managers throughout projects, not just at the start

If your environment lacks these attributes, establishing effective processes is more difficult, and the processes you do adopt may be easily undermined by management or other stakeholders. Adopting well-defined processes is still worthwhile, but gaining meaningful support and commitment for them is more difficult and it may require you to exert your influence, as discussed in Chapter 3.

Although many organizations lack much of a project management culture, some organizations overdo it. In either case, periodically reviewing recent project problems at the organization level enables you to identify the root causes of issues that arise either from insufficient process focus or from excessive project overhead. All projects are unique. The process specifics that work best tend to be highly situational. Some projects benefit from elaborate, formal, PMI PMBOK® –influenced structures and practices. In these cases, project leaders can build a solid foundation on these processes for project control. In other organizations, more informal, agile, or adaptive methods are more appropriate, and these processes can also provide an effective framework for enhancing your control. It doesn’t matter a great deal what specific processes you adopt as long as they make good business sense, have meaningful support from your team and stakeholders, and are actually used. As long as the methods you adopt for your project are well understood and consistently applied, any effective approach can enhance your overall control.

Life Cycles and Methodologies

Life cycles (or stage gates, phase reviews, or any other sequential project timing structure) and methodologies impose discipline on projects. Life cycles serve primarily to coordinate related projects and provide defined checkpoints, whereas methodologies strive to ensure consistency in how project work is done. Mandatory process aspects of either (or both) may be used to significantly enhance your project control.

Life Cycles

Nearly all projects have at least an informal life cycle that provides an overall structure and consistency for major project milestones. There are two main families of project life cycles. One is the waterfall type, made up of a single arc through a series of sequential phases (such as analysis, definition, design, development, testing, and release). The other is the agile type, in which projects are comprised of a succession of step-by-step, iterative cycles, each delivering an incremental result that approaches the final deliverable. Whatever the life cycle type, the specific details must always be customized to meet particular business, project, and customer needs. Literally thousands of variations are possible, and even within a single organization you may find significant differences. Whatever the life cycle type, the requirements for documentation, specific deliverables, and communication that are embedded in the defined milestones or reviews afford structure and implicit authority to any project leader.

The larger the project, the more likely it is that the life cycle will contain formal, explicit requirements, especially in organizations responsible for coordinating related projects running in parallel. In these cases, life cycles are set up more as management tools to assist upper-level and program managers than as processes for the project leader, and they are generally structured to determine progress at defined checkpoints, to ensure compliance with organizational standards, and to improve visibility and communications. Because life cycles of this sort are not primarily defined for the benefit of project leaders, they can represent excessive overhead that impedes progress and diverts resources from other project work. For this reason, project leaders should analyze the requirements for the chosen life cycle and seek to tailor it to improve the project’s chances of success. For each requirement in the life cycle, ask two questions:


Why is this necessary? (If it’s not, work to minimize the potential impact of any valueless overhead.)


How might I use or modify this particular requirement to enhance my control over the work?

Any requests or recommendations you make supported by life cycle requirements carry much more force than they would otherwise. It’s much more difficult for team members to ignore things that are reviewed by managers and other outsiders, so look for opportunities to align project deliverables, documentation, and plans with the defined checkpoints and reviews that make up the life cycle. Doing so can help you to minimize control problems or at least help you identify issues early enough in your project to do something about them.

Life cycle requirements are also a powerful tool for managing potential conflicts among different functional groups with contradictory interests. The team members contributing to your project may represent many functions, such as engineering, finance, manufacturing, quality, sales, support, documentation, training, facilities, system management, and testing. If everyone commits to meeting well-defined project life cycle requirements, there will be fewer conflicts over what is due and when. Activities in the project plan arising from a life cycle are easier to control because they depend on the organizational culture behind them, not just on your personal clout (or lack of it).

Although specific life cycles vary a great deal, a project leader can use at least a few universal opportunities to eke out additional control. One example relates to managing the initial scoping process. Even agile-type project life cycles begin with an effort aimed at defining requirements and doing deliverable investigation. Completing this effort requires documentation that describes what the project is expected to produce. The more precise and thorough you can make these initial requirements, the easier it is to develop practical plans that you can use to manage the work. Up-front precision also helps in determining the consequences of later changes, and intelligently managing evolving specifications is essential to project control. Nailing down scope for a project is never easy, but you will be much more successful in achieving scope stability with the help of mandatory life cycle requirements.

A common issue with initial scoping, especially with waterfall-type life cycles, involves listing musts and wants to describe what the project will produce. Musts are fine as long as they are well justified. Wants, however, are a problem because they fail to set firm boundaries around what your project is expected to produce. The early, disciplined assessment of all wants—and either promoting them to musts or excluding them from the project—forces earlier decisions and makes the project much easier to control.

Even better is to mandate explicit boundary definitions for the project through Is and Is-not lists that make clear exactly what will and won’t be produced. An effective Is-not list for a project is not a random list of silly things that would be illogical to include. It is a list of valid and, in some cases, potentially valuable requirements that you and your sponsors have explicitly decided not to include in the present project. All Is-not items listed will probably be considered when scoping a future project or perhaps even in a later phase or iteration of the current project. Many of these out-of-bounds features will eventually be delivered in the future—but not now, and not on your project. Failing to make an Is-not list part of project scoping increases the likelihood that different people, looking at the project from their own perspective, will make wildly varying—and dangerous—assumptions about what is in your scope.

Explicit life cycle requirements can also be useful in improving project control by ensuring that all testing, validation, and sign-off criteria are adequately specified at the same time as the requirements are set, and before any development work begins. Ultimately, the success of your project depends on acceptance of what you produce. Leaving the details of how your results will be evaluated undetermined until late in the project is extremely dangerous. As a requirement for entering the execution phase (or phases) of any life cycle, mandate a thorough plan for testing all deliverables, including measurable criteria, owners, and test participants, and any hardware or equipment that will be needed. Passing a test when you know all the questions in advance is easy. Leaving final acceptance criteria to the last minute is very risky.

You may be able to embed many other possible opportunities for enhancing your overall control in the exit criteria of a life cycle phase or iteration. Begin looking for them by identifying problems and difficulties you have had on past projects relating to the sequence or timing of key deliverables, information, and decisions. If you change nothing, past problems tend to recur, so consider ways to better or more clearly define interim project deliverables, or to schedule them earlier in the project timeline. Using compelling data from earlier problems, you should not find it difficult to get buy-in for customized exit criteria for your life cycle. Sufficiently severe past consequences may even allow you to make permanent changes to the process used throughout your organization.

Even life cycles for short-duration projects or having a series of brief incremental development phases can provide control levers for the project leader. Projects undertaken using agile management techniques involve a substantial focus on teamwork and collaboration. Structuring the work, reviews, and communication around effective practices defined by and for the team provides the project leader with a good deal to work with. By working with the team to create processes and standards that everyone buys into, a project leader can establish a robust structure to work with, especially when the team enthusiastically accepts and uses collaborative practices for close interaction. Whether the project you are working on is following an iterative, agile life cycle or a more traditional waterfall structure, working with your team to fine-tune process aspects of your life cycle requirements is a great way to gain support and build teamwork that will aid you in guiding your team. Chapter 3 offers a lot more on collaborative leadership; the following section on methodologies and other sections throughout this book provide details relating to agile methods.


Methodologies are similar in many ways to life cycles, though they generally go well beyond the life cycle criteria. In addition to specifying project milestone and review requirements, methodologies provide explicit guidance for how work is to be done. The process definitions generally include templates, checklists, forms, and other materials that project leaders are either required or strongly encouraged to use. Methodologies are even more specific to a single type of project than life cycles, and they generally provide a high level of detail. Product development methodologies often include specific advice on which tools and systems to use and how to use them. IT methodologies include standards for version control, documentation, and other aspects of system development. Software methodologies often have defined variations that are specific to implementations of a single vendor’s system or application. Methodologies that employ iterative or cyclic phases (such as extreme programming [XP], scrum, lean development, and other agile methods) mandate processes for estimating, working in small teams, and using short-turnaround, time-boxed intervals for interim deliverables.

Methodologies are typically defined in organizations for use on all projects of a given type. Most project leaders have little choice on whether to use them. When methodologies are mandatory and carry the authority of upper management, they can be a significant source of project control for you as a project leader. When considering the effect of an aspect of a methodology, always think of how it could be used as leverage in gaining project contributors’ commitments that might otherwise be problematic. If the methodology requires specific documentation to be written in a certain format during development, take full advantage of this to ensure that it is done. If the methodology provides checklists and questionnaires that can be used to highlight project issues, exploit them to improve visibility and assist you in resolving issues. Widely adopted methodologies can also facilitate your management of dependencies with other departments, suppliers, and related projects.

Structural requirements such as life cycles and methodologies can cut both ways, however. Although they can provide a solid set of well-established boundaries that you can use to keep the project moving forward, they may also consume effort and project resources doing work that may not help the project much. As with any process, you need to consider the overall benefits of any methodology and to work, when possible, to adjust the methodology wherever it fails to help your project.

Project Definition and Charter

Clear, unambiguous, high-level project documentation is essential for project control. Whether a specific document and format is defined formally for your organization or is mandated as part of an adopted methodology, developing and communicating a thorough description of your project set the stage for all subsequent work. No matter how or why you create your project definition, establish written documentation for your project that is readily available to all your project stakeholders and team members.

Project definitions take many forms and go by many different names: project charter, proposal, project datasheet, plan of record, project specification, statement of work, or even simply a project definition document. Although the name “project charter” is used here, the principles outlined in this chapter apply to any project definition document—whatever it may be called.

Project charters begin with top-down information on the desired results from the project sponsor and other stakeholders. Start your project documentation using the information you have, and wherever it is incomplete or not sufficiently clear, interview your sponsor (or others, as necessary) to learn the exact business need, problem statement, or other rationale for the project. Work to uncover any known constraints, and ask questions to understand any significant assumptions the sponsor and initial stakeholders have about the project regarding timing, staffing, and other project parameters.

Begin by assembling project charter information in an appropriate format. Use your organization’s requirements for project documentation if these exist, but whether using a set format or one you have devised, be as thorough and clear as possible in the following areas:

 Project objective statement (providing in a short paragraph a high-level description of the project deliverable, the project deadline, and anticipated cost or staffing)

 Project priorities (rank ordering among scope, schedule, and resources)

 Project benefits (including a business case or return on investment analysis)

 Available information on user or customer needs

 A scope definition listing all anticipated project deliverables

 Goals for cost and timing

 Significant constraints and assumptions

 Descriptions of dependencies on other related projects

 High-level risks, new technologies required, and significant issues

Strive to include as much specific detail as you can, and, as you proceed, validate the content of your charter with the project sponsor and stakeholders.

A project charter is a living document that may grow and evolve over the course of the project, but maintaining an unambiguous, easily accessed description of the project currently approved by your sponsor and others in authority is a very powerful tool that you can use to keep your project under control. Throughout the project, the charter facilitates rejecting proposed changes that conflict with what is in the charter. Constraints that are documented in the charter, such as interim milestone deliverables or mandated compliance with published standards, are more effective as a rationale for your requests than just your say-so. A thorough charter document forms the basis for detailed scoping, planning, tracking, and periodic project reviews. Chapter 5 discusses the development and use of the project charter in initiating a project.

Project Planning, Execution, and Tracking

As a project leader, you can establish a solid basis for control by making a strong case for planning, tracking, and execution processes. Control depends on getting buy-in for these processes from your project team and then using them throughout your project.

Involving all the team members in planning and tracking activities builds buy-in and motivation. Wise project leaders encourage broad participation and include contributions from everybody in the resulting outputs from these processes. When people invest effort and see their influence on the project as it comes into focus, the project quickly shifts from someone else’s project to our project. Controlling a project that people care about makes the project much easier and ultimately more likely to be successful than trying to manage one with an indifferent team. Using project management processes collaboratively also encourages cooperation among your team members, which also simplifies your job.

Chapter 6 includes details on using project planning processes to improve project control. Chapters 7 and 8 go into the specifics for maintaining control through the execution and tracking processes. Even for the project leader who has little or no formal authority, the disciplined use of these project management processes are essential to keeping things moving forward.

Project infrastructure decisions in all these areas are summarized later in this chapter and detailed in Appendix A. These decisions are a useful way to gain both feedback and broad acceptance of specific project management practices, and basing the decisions on team consensus enables you to enforce them without the need to pull rank.

Change Management

For projects that have initially well-defined deliverables and that are undertaken with a waterfall life cycle, one of the most difficult control problems can be managing specification changes. For projects that have high novelty and that are approached using an agile, iterative approach, change can also be problematic. In both cases, coherent processes aimed at evaluating scope modifications and accepting only those having solid business justification are essential to maintaining project control.

Phased Projects

One of the most troublesome problems for technical projects is excessive and poorly managed specification changes. When the main cause of this is a fuzzy or uncertain notion of the final deliverable, one helpful approach is to abandon the phase gate life cycle and adopt a more flexible, iterative agile approach (discussed below). If the root of your change management challenges is either beginning your work without an adequate understanding of the deliverable or stakeholders who can’t seem to make up their minds (or both), solving the problem involves two things: (1) thoroughly documenting and freezing project scope when setting the project baseline and (2) adopting an effective process for managing changes throughout the remainder of the project.

Thoroughly defining scope may require a good deal of effort because you’ll need to canvass all your stakeholders and work with them and your sponsor to document a consistent and coherent set of requirements that everyone can agree to. Using an Is and Is-not approach and the other ideas discussed in the preceding section on project definition is an effective way to draw clear boundaries around the scope to be delivered. When what you are and are not committing to is made clear, it significantly minimizes future changes.

Project leaders with little formal authority are also particularly dependent on a well-defined, documented process for managing scope changes; without one, scope creep and other general scope meanderings can easily render a project unmanageable. How formal the control process needs to be varies quite a bit, but even on trivial projects, a written process will help you avoid chasing a moving target. A project whose deliverable constantly changes is perpetually out of control.

Change management processes that contribute to your ability as leader to keep things under control have several things in common:

 Specific requirements for submitting change requests to ensure that all proposed changes (regardless of the source) provide consistent, sufficient information on each change

 A bias against accepting changes, to minimize unnecessary change

 Standards for timely response on change requests and clear, public visibility for all decisions

 A review process for changes that includes the costs and consequences of accepting a change, in addition to any potential benefits

 Unambiguous authority for the owner of the process to make final decisions, including decisions to reject changes

When you, as the project leader, are the owner of the process, then you actually have a good deal of formal authority over your project. But even if you don’t have ultimate responsibility for making decisions on proposed changes, there’s still hope. You can still write or at least influence the process to be used and facilitate the process to ensure that it meets the criteria you require to control project scope. You can also work to establish a strong relationship with the people who do own the process so that your inputs and opinions are used in making the final decisions.

A typical change management process flowchart appears in Figure 2-1. Simply having a process that your team, sponsor, and project stakeholders all accept is a powerful tool for overall project control. It puts people on notice that changes will be carefully examined before being accepted and establishes the hurdle of adequate documentation for changes being proposed.

Figure 2-1: A Typical Change Management Process

A project leader can exert additional control at several key points in the change control process—namely, when ensuring that the submission is credible and when considering all options for disposition of changes.

Project leaders are among the first people to see proposed changes, and they have responsibility, or at least shared responsibility, for the proposal-complete decision point. When reviewing a change, look for a clear, compelling description of the business case for the change. If the reason for a change (the why) is inadequately documented, send it back to the submitter with a request for a quantitative assessment of the change’s benefits. Be skeptical of change requests that specify narrowly defined technical solutions because the submitters may not be in a position to judge the best technical changes for a specific problem situation. If the requested change includes too much focus on a solution and too little on the actual problem, return it with a request to emphasize the business situation that inspired the requested change. Finally, ensure that the consequences of not adopting the change are credible and sufficiently detailed for analysis and that any estimates on expected impact to project timing, cost, effort, or other factors are realistic. If you disagree with any of the information provided, send the change request back to the submitter with suggested changes or specific guidance where additional or better information is needed. Give particular attention to any change that you would characterize as an enhancement because these types of changes tend to be described with exaggerated benefits and grossly underestimated consequences. The first line of defense against unnecessary change is keeping people honest.

Another point in the process when a project leader may exercise control is the accept/reject decision. Again, the main principle involves maintaining credibility. Whether they are ultimately responsible for each decision or are primary contributors of data, project leaders have two opportunities to guide the process. The first is to check the analysis information for each change to verify that it is realistic. Seek credible answers for all the following questions:


Is the business benefit for the change well documented and believable?


Does the proposed change represent the best available response?


Do you have good reasons to believe that the change is feasible?


Is the change likely to obtain the desired result?


Will this change affect the project baseline? Are all estimates associated with the change credible? What milestones will change?


How much additional effort will the new or changed project activities require? Do you have people willing and able to staff the work?


Who will bear any additional expense for equipment, material, training, rework, scrap, and contractual changes?


What are any potential unintended consequences of the change?


Will this change affect other projects?


Does your sponsor support the change?

Use the answers to these questions to review each change and to ensure that everyone involved in deciding how to proceed considers both the reasonably expected benefits and the costs and other consequences associated with the change. Keep in mind that the information provided to support proposed changes can be highly uncertain. Always probe for what the estimates are based on, and ask for worst and best cases or ranges for all estimates, particularly estimates of projected benefits.

The second opportunity to provide guidance for the decision process is by keeping all four potential responses visible: approval, approval with modification, deferral, and rejection. Rejection should always be the default decision, applied to all change requests for which the analysis fails to provide a compelling, credible business case. Even for beneficial changes, you can test the proposal to assess whether all the proposed change is needed right now and then counterpropose, accepting only the urgent part of a change. Acceptance with modification can effectively minimize the impact on the project while including key portions of the requested change. For desirable changes, determine the effect of delaying them to a later project. If the cost of accepting the change in the current project is larger than the estimated cost of delay, “not yet” may be your best decision. Work to approve changes sparingly and only when they are solidly supported by a strong business case.

Agile Projects

Controlling a project undertaken in small, time-boxed chunks can pose significant problems for project leaders, even those who have substantial authority. When the deliverable to be created in each work iteration is dynamically defined at the end of the previous iteration based on evaluation feedback, the lack of a solid process can result in a meandering, never-ending project that consumes time, money, and effort with little to show for it all. Managing changes and scope additions using a well-defined process is key to successfully controlling agile projects.

Before even embarking on an agile project, determine whether this approach is the best one. For projects that can define things reasonably thoroughly in advance, agile methods are always more time-consuming, expensive, and overhead-intensive. It is a bad idea to use agile methods primarily because you prefer not to define and plan things in detail up front. You need to do all this eventually anyway, and the day-at-a-time incremental approach only results in work performed out of sequence, more meetings, rework, and even doing work that was not actually necessary. Agile methods are best applied on projects that are novel, highly innovative, and when it is not feasible to define the work in advance.

Even when the flexibility of agile methods is appropriate, you must determine at least a few things in advance. Although you may not be able to determine all the specifics of your deliverable, you do need to clearly frame the problem to be solved or the overall opportunity that you are pursuing. Without a clear idea of what you are trying to accomplish, you are embarking on a fishing expedition, and your objective may never come into focus. You also need to define, at least generally, the staffing, other resources, and overall timing to be allocated to the project, and gain sponsorship to support the commitment.

The overall plan for an agile project includes specifics for the initial phase of work that:

 Defines the first increment of deliverable functionality.

 Identifies the participants in development, testing, and evaluation.

 Lays out the communication and reporting required.

 Specifies the process and duration for all subsequent phases of work.

When working without much authority, a clear process for evaluating feedback and defining the content of the next phase of work is essential. As with the criteria for changes in a phased project, the project leader is best served by a process that clearly defines how the proposed scoping for future phases will be evaluated and prioritized, using objective standards and delegating unambiguous authority for final decision making. Keep the process open, and strive for consensus decision making; the strength of agile methods relies on collaborative teamwork and cooperation. It is also good practice to develop straw man descriptions for several phases into the future and to adjust the work and deliverables on the horizon as you progress so that the trajectory is clear and seen by all as realistic and appropriate.

Information Management

Archiving project data serves as another foundation for project control. Information that is stored in your project management information system (PMIS), or whatever you may choose to call it, provides a solid foundation for project reference and communication. The project leader’s power of the pen over the wide variety of formal documents can be a significant source of project control.

How and where the documents are stored can be equally influential. Public storage of project documents is an essential aspect of control. You can support your requests and guide decisions throughout your project using archived project documents and reports. Your documents and plans form the foundation for your project, and the project contributors and stakeholders who helped to create them and gave their approval (or at least did not object at the time) are obligated to cooperate with you in delivering on what they say. The longer that documents are available publicly, the more force and influence they have.

Project information is an essential project resource, so consider carefully where you put it and how you set up access. Some projects use Web sites, networked servers, or knowledge management systems to store key project data. For some projects, groupware applications are used both to maintain the project document archive and to provide e-mail and other services. Online electronic storage allows easy access to a single master copy of each project document that everyone associated with the project can read at any time. Updates are instantaneous, leaving minimal chance that team members will have out-of-date information. If you do implement an online PMIS, verify that all software tools, Web browsers, and other applications that team members use are up-to-date and compatible. Carefully consider any hierarchical structures you plan to use to store information, and set them up from the perspective of your team members and stakeholders. Although a structure that is oriented functionally may not be the easiest for you, it can enable team members to easily find what they need, making it far less necessary for them to come to you for project information. If your online document repository has knowledge management facilities, use them. Set up your information system to take full advantage of flexible search, key-word-in-context indexing, alias capabilities (allowing a single real document to be listed multiple places in a complex hierarchy), and other query and retrieval functions. To enhance your control without limiting people’s access to information, fine-tune the security settings for individual access to permit many contributors to read the shared documents but only a few to edit them. To minimize the possibility of losing critical data, strictly limit the number of people who can delete information, and take advantage of version history archiving to retain earlier versions of project documents.

For small, co-located project teams, the PMIS might be a filing cabinet or even a notebook stored in a common area. Whatever method you select for storing project data, ensure that all project team members have adequate access at all times to at least hardcopy versions of project information. Provide current project documents in an easy-to-find place, and clearly mark or remove all out-of-date information so that it is not used for project work.

In the PMIS, set up a logical structure to store project definition documents (such as the project charter and requirements definition), project planning documents (work breakdowns, Gantt and network charts, risk registers), and project execution documents (including status reports, issue logs, and other communications). For PMIS implementations that are not online (or for emergency backup), establish a method for distributing document copies to all the places where the project contributors are located. Implement a process to keep all sites synchronized and to ensure use of only the most current project documents.

Processes involving project documentation may not be the most exciting part of a project, but, if you invest in setting up a useful, easy-to-access repository for the information that people need to have, it pays benefits throughout your project. A well-established, orderly project management information system adds immeasurably to the influence of any project leader because it is very compelling to back up your requests and actions using documents that are the product of collaborative development and review—especially documents that have been available to the whole project team for weeks or even months.

Project Management Software Tools

Project management tools are another potential source of project control for project leaders without a lot of power. Some software tools useful for project management relate to general project information, as discussed in the previous section. Other tools relate to general communication (explored in Chapter 3).

Many general-purpose project management and scheduling tools are available, and processes around them can also enhance your overall control. For large projects in which multiple people will be using scheduling tools themselves to plan and document work delegated to them, the choice of tools is where process-oriented control begins. When all the pieces of the overall plan are created using the same or at least compatible tools, the project leader’s job of integrating everything into a coherent overall plan is more straightforward. Using the same tool also provides opportunities for mentoring and guidance; the leader is able to establish a position of expertise. You may also guide and influence the planning through templates that ensure thorough planning and consistent formatting.

When only the project leader or a designated planning expert is using a software tool, there are still ways to use the process to gain control. Consider the structure of the plan, and choose a work hierarchy that makes it easy for you to tailor schedule views for your subteams and individual contributors. Tips on dealing with plan complexity can be found in Chapter 6.

Also, explore the options for graphical tools outputs. Do what you can to exploit them to create easily accessed and clear images that show how your project work will proceed. Use PDF or bitmap extracts to distribute project information by e-mail, and store the information in your PMIS. Create large, poster-sized versions for meetings and common workspaces that provide visible reminders of what is planned. Carefully crafted pictures of your planned workflow can be worth many words, especially for team members who may not be very familiar with project scheduling techniques and terminology. Exactly how you use project graphics is particularly critical because it can just as easily work against you. If your project graphics prove to be too complicated or confusing, they can diminish your overall control.

Contract and Procurement Management

However much influence and authority you have within your own organization, you will probably have even less day-to-day control over project contributors who work for other companies. Although it is not always feasible, a tactic for improving your project control is to outsource as little work as possible.

If you must depend on the services of people outside your organization, you face control challenges. One way to mitigate this situation is to adhere scrupulously to the standards and requirements that your organization has for outsourced services. These processes provide you with firm boundaries and guidance that are particularly effective in initiating and executing contract project work (as well as keeping you in the good graces of your management). Before considering the use of contractors or outside consultants on a project, review your organization’s overall procurement process. Identify people you can go to for help (for example, in your procurement, legal, human resources, or other departments) who have experience with setting up the required service contracts. If any part of the required process is unclear to you, have someone who has expertise explain it to you, or get that person’s commitment to assist you. Identify all the functions and people who will be involved, other resources you’ll need, and all the forms, approvals, and communication required. Following tried-and-true processes will enhance your project control; failing to do so will result in delay, lead to chaos, and may even get you and your organization in trouble.

Establishing a successful outsourcing relationship takes time and effort. Determine when you need to start working on it so that you have all the details in place and contracts signed in time to meet your project’s deadlines. Taking shortcuts and rushing into a contractual relationship almost always leaves you with far less control than you would like.

Control begins with detailed specification of all the deliverables that you intend to outsource. Document the detailed feature specifications, measurable performance and acceptance criteria, any other relevant requirements, and the necessary timing. Ensure that the definition data is included in the contract, with all responsibilities clearly defined. Discuss these requirements with all the suppliers you may be considering throughout the process so that your expectations are clear, and make a particular effort to ensure that the supplier who is ultimately selected clearly understands the contract terms.

Establish clear-cut language in the contract for managing changes, so that all parties know the process and the consequences of any modifications. You can also improve your overall control of outsourced work by including in the contract specific incentives for early or exceptional performance and penalties for nonperformance. If-then clauses in the contract provide you with more options for control than the basic do-this-and-we-will-pay/fail-and-we-won’t language that is the starting point in standard contracts. When considering the inclusion of penalty or incentive terms in your contracts, work with appropriate experts in your organization.

As you proceed with the process, present periodic updates on your progress to your project sponsor and to other stakeholders who need to approve or sign the contract. Identify any outstanding issues and correct problems as you work so that, before signing, you have both a contract that includes all that it requires and the quick approval needed to get started.

Chapter 6 provides additional specifics on negotiating and planning for improving control of outsourced work, and Chapter 8 discusses ideas for maintaining control over contract work.

Risk Management

Risk management is an important part of project planning, and much of the work required to do it well occurs during the initial analysis, scheduling, estimating, and other activities of planning. However, keeping a focus on risk throughout your project reinforces the overall goals and keeps your team’s attention on the upcoming work. You can better control your project when you maintain a clear notion of what lies ahead.

Some regard risk management in projects as a discretionary activity, but a project leader with limited authority should not. The processes of risk management, in fact, enable you to do more thorough planning, highlight potential troubles and build consensus on how to deal with them, and remove (or at least mitigate) serious project problems.

To maximize the effectiveness of your risk management efforts, make risk identification a parallel activity throughout project planning. Look for incomplete understanding of project activities as you develop the work breakdown structure. Probe for risks when assigning activity ownership and developing estimates. Identify risks associated with dependencies both within and outside your project. When resources are scarce or inadequate for project tasks, or when you are dependent on a single individual for project work, note the risks. Analyze assumptions and constraints to find exposures, and encourage all who are involved in planning to consider worst-cases and potential difficulties throughout the development of the plan. Risk analysis, both qualitative and quantitative, assists you in displaying the consequences of project risks and makes your requests for modifications to the initial plans to reduce or avoid risks far more persuasive. Specifics on integrating risk processes into project planning are detailed in Chapter 6. The more robust you can make your plan, the more likely it is that you will be able to navigate through your project successfully.

Risk management also provides a lever for control throughout your project through monitoring of risk trigger events, the implementation of risk responses and contingency plans, and the periodic reexamination of the project risk list. Enhancing your control through diligent focus on risk management throughout project execution is described in Chapter 8.

Quality Management

Quality management offers another set of processes that provide project structure and that can put teeth into requests from a project leader that might otherwise be ignored. Standards for quality that relate to projects are of two kinds: (1) global standards that are adopted within industries (and in some cases may be mandatory) and (2) quality standards that are unique to a specific organization or even to a single project.

Adopted Standards

If your organization has adopted or is subject to standards for quality, review what they require of you and your project team. Specific examples of such standards include organizational compliance with ISO 9000 standards, Six Sigma, and commitment to maintaining a maturity level within the Capability Maturity Model defined by the Software Engineering Institute. Use your review to identify and integrate the checklists, quality processes, and other required elements into your project planning and execution. The specific documented steps, reports, and evaluations that your project must comply with provide much more compelling motivation for team members to do things in a certain way than just your requests to do so. Because processes related to quality management can be overdone, thus adding inappropriate and expensive overhead to projects, prudent project leaders identify and emphasize processes and standards that add value, that enhance their control over the work, and that minimize overkill processes that can slow the project.

Determine who in your organization has ultimate responsibility for quality management, then ensure that the individual or group understands and approves of your approach. If quality specialists have specific responsibilities and deliverables for your project, get their commitment in advance, and don’t hesitate to enlist their help when issues related to quality threaten the progress of your project. As with adopted project methodologies, quality standards convey authority to a project leader because the standards are backed up by the more influential managers responsible for their definition and compliance.

Project-Specific Quality Planning

Because quality standards, whether based on defined standards or general principles such as Total Quality Management or Six Sigma, are oriented toward consistently delivering what a customer requires, quality management is closely related to scope management. Another opportunity for better control that quality management processes offer the project leader is to align project requirements with the “voice of the customer.” Strong emphasis is always added to what you say when it is clearly and directly connected to a stated customer or user need. Market research, benchmarking, and customer interviews are useful for assessing and documenting user needs and in defining the value of your project requirements. Understand what matters to your ultimate customers, and use what you learn to steer your project. Whatever you say or do will be moreeffective when you are acting with your customer standing behind you. This is particularly true when using agile project management methods, where there are many effective techniques for initiating and maintaining frequent customer collaboration.

Incorporate quality-related activities into your project, such as process audits, tests, reviews, inspections, and approvals. For every process that you adopt, explicitly document how the result is important to your customer. Before detailed planning commences, determine and document the final approval criteria for your project as early as possible, and review acceptance tests and evaluations that are required for scope verification with stakeholders and customers. Periodically review and update completion and evaluation criteria throughout your project, especially following approved scope changes.

Issue Management

With projects, issues inevitably arise. At the start of your project, define a process to manage project issues relating to resources, timing, priority, and other matters. Get buy-in from your team for a disciplined process to recognize, track, and resolve issues promptly. Establish an issue-tracking process that uses a visible log of current issues and includes information on each current issue, such as:

 A description of the issue

 An identifier or code associated with the issue (to facilitate communications)

 The date opened

 An assigned owner

 The current status

 The due date for closure

The process for dealing with open issues is not complicated. It defines how new items are identified and listed. It provides for a periodic review of open items (often at regularly scheduled project meetings and with adequate reporting), and it states how to deal with overdue issues. The power of an issue-tracking process for a project leader who does not have much authority comes largely from reporting on issue status and due-date information. Once an owner has accepted responsibility for an issue and committed to a resolution date, you may report on any variance and may in fact be obligated to do so. Whether the issue owner is a team member, someone from another project or organization, or even your manager, no one likes to see his or her name with a large red stoplight indicator next to it. The public nature of an issues list provides the project leader who manages it a good deal of influence and control.

For overdue issues that cannot be resolved by an owner within the team, the process should also define a time limit for escalation to someone with the authority to deal with it. Using escalation should never be the first option, though, because escalating too frequently can produce unintended consequences and erode confidence in you and your team.

Decision Making

Projects require many decisions, and making them quickly and well is essential to project control. A well-established process for group decision making is useful even when the project leader has a good deal of authority because decisions made with shared input result in more team buy-in and can be expected to deliver better results.

Decisions are rarely easy in projects, and the spectrum of opinions on a diverse project team generally makes them even more contentious and difficult. A documented process for dealing with questions and options that the project contributors have agreed to use streamlines the process and delivers decisions that everyone will accept. Work with your team early in the project to develop a process for decisions or to adopt, perhaps with modifications, an existing process. A good decision process provides powerful support for control of your project.

Your decision process should reflect the specifics of the situation, including the complexity and urgency. Regardless of the decision, the process should include the following steps:

 Develop a clear, unambiguous statement of the question that must be answered.

 Obtain team support by involving all project team members who need to be involved with the decision or who are affected by the decision; get their commitment to participate in the decision process.

 Review the problem statement and decision needed among your project team, and modify it if necessary so that everyone interprets it the same way.

 Brainstorm and generate ideas and options for the decision among your team.

 When you have an adequate number of alternatives, consider them as a team. If the decision is not complicated or the timing is urgent, work to develop group consensus using discussion, tapping into the “gut feel” of your contributors. For more complicated decisions that would benefit from in-depth analysis, use an analytical approach (such as the one described next), but even when you do this, pay attention to the initial impressions and feelings of your team. Complicated decision processes do not necessarily result in the best decisions, and they may in fact be inferior to the instantaneous “blink” feelings that people have before they bog themselves down in a quagmire of data.

 Select with your team what you feel is the best option, striving for broad consensus. Consider the consequences of adopting the favored alternative. If there are no objections, come to closure and implement the decision.

 Document the decision, and communicate the results to others on the team and to appropriate stakeholders.

 Implement the decision and track the results. Be prepared to revisit and adjust the decision if you fail to achieve the desired results or if there are significant unintended consequences.

For complicated decisions requiring detailed analysis, approach the assessment and consideration of options using an analytical approach such as:

 Set a time limit for making a decision, and tailor the overall process to conform.

 Brainstorm and discuss potential criteria to use in making the decision (such as cost, time, usefulness, completeness, feasibility, or other considerations). Select criteria that relate to your defined goal, that are measurable, and that can be evaluated objectively by the project contributors who will assess them to make the decision.

 Work with the team to prioritize the criteria by giving each one a relative weight (where the weights of all criteria could sum to 100 percent).

 Generate as many ideas and options for the decision as possible in your allocated time. Seek to develop multiple ideas that could be acceptable to the whole team.

 Use group voting techniques, if necessary, to filter the list down to no more than about six options before considering each one in detail. Analyze the options using objective assessments of how they conform to the established decision criteria.

 Quantify any objections that come up in discussion to the ideas, adding additional criteria for the decision if necessary.

 Sequence the options using the assessments and weighted criteria.

 If the rank-ordering of your options seems wrong to anyone or if reasonable issues are voiced about the top alternative, revisit the criteria and weightings to make adjustments wherever they may be needed.

Again, even when using weighted criteria for rank-ordering and selecting preferences, keep your eyes open and ensure that the outcome is acceptable and appropriate. A “perfect” decision that lacks support may lead to more problems than another option that your team feels better about.

Running a Successful Volunteer Fundraiser

Bob Montevaldo has been an experienced project manager in high-tech companies for many years. However, he recently found himself with a challenge while serving on the all-volunteer board of directors for Ombudsman Services, a nonprofit organization that serves the elderly in San Mateo, California. Recent tough economic times resulted in significant funding cutbacks for the organization, and the board decided that finding additional funding sources was necessary. At the time, Ombudsman Services was also celebrating its 30th anniversary, so an event combining an anniversary celebration with a fundraiser seemed like a good plan. As the board treasurer and resident project management guru, Bob offered to start investigating such an event.

Because the undertaking needed to raise funds, it had to be an entirely volunteer activity. Bob started by enlisting the help of several people who had a long history with Ombudsman Services to hash out ideas for the event’s theme, location, date, and budget. Bob documented all this in a proposal that he brought to the board for discussion. The board endorsed the proposed dinner dance concept at a local country club, and the event was approved for October, about 10 months away.

The initial group Bob had brought together had good chemistry, so he requested them to continue as the core team, each with specific responsibilities for the event. The group started meeting on a regular basis, and Bob reported their progress to the monthly board meetings. A key process Bob adopted early on was ensuring frequent communication between the board and the core team. Communication was essential because the commitment and enthusiasm of the board members were needed for obtaining auction items, securing sponsorships, and selling tickets. Bob also saw to it that the members of the core team had regular feedback from the board, and the team knew that they had continuing strong support from the board.

As the work proceeded, ideas flowed from the team to the board, and the board offered many helpful suggestions for the core team. (One board member even committed her husband’s jazz band to play at the event, resulting in a significant savings.) Event planning moved forward quickly. Core team members took responsibility for sponsorship, program planning, ticket sales, event logistics, and the event auction, and Bob reported on their progress and accomplishments. Board members worked with the team to identify sponsorship prospects, solicit auction items, and make commitments for how many tickets they could sell.

As with any all-volunteer effort, there were some lapses and disappointments, but because of the overall visibility and clear documentation of assignments, they were rare. In the month prior to the event, there was much complicated activity, but the high level of communication that Bob had established paid off with commitments met and the continued enthusiasm of everyone involved. Many people even volunteered to do extra work.

One challenge the core team faced was that this was the first fund-raising event of its type that Ombudsman Services had ever done. With so little organizational experience, Bob knew that a few last-minute issues and problems were bound to come up. To deal with this possibility, just before the event he set up a walk-through with all the volunteers. In this exercise, they managed to find and fix most issues that they had missed.

The event was a great success; the ballroom was filled to capacity, and ticket sales and auction results exceeded their financial goals. Many attendees asked as they were leaving when the next dinner dance would be held. In addition, an important byproduct of the event was that it raised awareness of the organization within the community, especially with local politicians and businesses.

The final thing the core team did was to hold a postmortem to document things that went especially well, and areas that could be improved before the next event. All agreed that the key success factor was keeping all volunteers engaged through effective planning, communications, documentation, and monitoring of commitments.

Good processes always matter, and never more so than when everyone on the project is a volunteer.

Project Infrastructure

All projects have an infrastructure. Most have an infrastructure that is a combination of organizational standards and generally accepted defaults. Other projects have an infrastructure created by adding to or changing some key decisions that the project leader believes could materially help the current project. Establishing processes for your project sets a firm foundation for project control. Determining exactly how you apply these processes requires a framework of decisions for project planning, execution, and tracking. Documenting your decisions clarifies how you will operate and provides you with enhanced support for overall project control.

Making infrastructure decisions may require only a short team meeting for smaller projects, but you may need to make a considerably larger investment for a major program. As with most project management matters, the time spent depends on the project scale. The best time to consider infrastructure decisions is at the start of a project. Once a project is fully underway, no one has much time or inclination to think about infrastructure questions.

Key Decisions

One way to begin establishing an infrastructure for your project is to list key questions that you would like to answer, working with your project team. Your list can be one of your own making, one from an earlier project, or a template used by your organization, or it may be based on a generic template, such as the one in Appendix A. However you proceed, include questions that relate to problem areas from earlier projects, things that could become control problems for you, and issues that may lead to trouble on your current project. A few examples are:

 Planning questions (related to project initiation, plan development, outsourced work, deliverables, and planning participants and tools)

 Execution questions (related to project status and metrics, the PMIS, meetings and informal communications, team concerns, life cycles, methodologies, and quality assurance)

 Control questions (related to project reporting, scope and specification control, individual performance problems, project reviews, project cancellation, and project closure)

Detailed, specific project infrastructure decision questions for each of these areas are contained in Appendix A.

Fine-Tuning Your Infrastructure

The point is worth repeating: Take the time to develop the list of questions and decisions you would like to address with your team during project initiation, before people become overwhelmed with project deadlines. Trying to change the way you are doing things midproject is difficult—like trying to change the tire on a vehicle while it is speeding down a freeway.

Distribute the list of questions and issues to your team, and ask each person to begin thinking about options for how the project would best operate. If the team is very senior and has been involved with many projects, the list of questions alone is likely to be enough to generate ideas. For a less experienced team, some thoughts that you have on alternatives worth considering can be useful for getting the discussion going.

To make decisions, set up a meeting (or teleconference) to gather the team’s thoughts and to discuss the alternatives. Set a time limit of no more than about ten minutes for each issue, and be scrupulous on timekeeping. When there is little or no disagreement, document the consensus and move on to other issues. When there is contention, you have several options:

 Extend the discussion slightly to seek closure.

 Delegate the issue to the people who are most vocal in their objections, and have them bring a proposal to a future meeting.

 Make the decision yourself, explaining your justification.

For each question that you complete, document your decision and your key assumptions. Communicate your decisions to stakeholders and to others involved in your project, and summarize the infrastructure decisions in your PMIS. Adopt the decisions to manage your project, and adjust your project processes as needed to conform to what you have decided.

Throughout your project, particularly following major changes and during project reviews, review your infrastructure decisions and consider any needed adjustments.

The Project Management Office

One last process-oriented source of control is the project management office (PMO). Some organizations invest in them and others do not, but if you are in an organization that has established a project office (or a program management office, center of excellence, support team, or similar group), plan to use it to bolster your project control.

Although there may be variations, the three most common functions for a PMO are auditing, enabling, and executing. Combinations of these functions are not unusual, and the precise nature of each project office depends on the organizational needs.

 Auditing. Some project management offices are established to serve as process police, responsible for audits of methodologies and compliance with quality or other standards. Working closely with this type of project office potentially yields benefits similar to the adoption of the process standards discussed earlier in the chapter. However, this type of project office tends to believe that “if some is good, more is better.” Use your judgment in determining how much help is appropriate, and consider carefully places where process overhead can start to make things worse.

 Enabling. A second type of PMO works to improve the maturity and effectiveness of project leaders throughout an organization. Using a team of internal consultants, the enabling PMO provides training, assistance in setting up organizational processes, and help in tailoring life cycles. The consultants get involved when the challenges may exceed the capabilities of a particular leader or team. This type of PMO may be useful in boosting your credibility and authority as a project leader because people tend to listen more carefully to apparently knowledgeable strangers. (One definition of an expert is someone who doesn’t know any more than anyone else but is from more than 50 miles away.) In many enabling PMOs, staff is available to help with initiating, planning, and closing projects.

 Executing. Other PMO implementations are even more actively engaged; they are responsible for actually facilitating and doing the project work. This type of PMO has a staff of planners, administrators, and supervisors who coordinate and guide the execution of the project. For large programs, they ensure consistent planning among all the component projects. Again, the presence of outsiders who support (or even mandate) activities and processes that you need to keep your project under control can significantly enhance your apparent authority.

Potential areas where project office help can be effective are:

 Facilitating project start-up workshops

 Support for project planning efforts and help with complex software tools

 Communications and meeting planning

 Enforcement of planning standards and auditing for completeness

 Establishment of templates and checklists for common project types

 Setup of a central PMIS repository for sharing information among projects

 Organization-wide standards and reporting for change control

 Assistance with project escalations and recommendations for resolution

 Collection and analysis of organization-wide project metrics

 Assistance with the setup and execution of processes for conflict resolution, decision making, quality management, and other project processes

 Assistance with project reviews and follow-up

 Facilitation of postproject retrospective analyses and organization-wide storage of results

 Management of organizational change

Although involving staff members from a project office in your project can considerably enhance the productivity and effectiveness of your project, too much involvement can result in it no longer being your project. Sharing leadership responsibility with a PMO can end up being difficult, like sharing a banana with a gorilla.

Key Ideas for Project Processes

 Get team buy-in for structured project management processes, and clearly document how you will use them.

 Review past projects for problems related to structure, and work with your team to make project infrastructure decisions to resolve them.

 Take advantage of organizational expertise and project office capabilities, but resist surrendering control over your own project.

Chapter 3: Control Through Influence

It is often said that management is assigned, but leadership must be earned. One aspect of earning the role of project leader is building influence both within and outside your project team. Your working style matters a great deal. Your influence with others also depends on what you have to offer them in exchange for the commitments you need and on what you can do to build and maintain relationships with your team, your sponsor, and your project stakeholders.

Appropriate Leadership Styles

The introduction that most people have to project work, especially in a business context, is as a contributor. Project contributors draw on background and experience that relate to the assignments for which they are responsible. If contributors are good at what they do, sooner or later they are likely to find themselves leading a project, not just contributing to it as a team member. The transition may be gradual, such as beginning to coordinate the work of several other people on a small part of a larger project, or it may be abrupt—resulting in yet another “accidental” project manager. However it occurs, the transition comes with a pair of challenges. Moving from primarily contributing to a project to leading one requires a different set of skills, and new leaders usually have very little or no formal authority. Becoming a successful project leader means that, instead of spending most of your time with “things” and “stuff,” you now spend most of your time dealing with people and communications. To do these tasks well and to be successful at leading a project when you have little power to demand or coerce commitments from people, you must establish and maintain influence over your team, stakeholders, and sponsors. This chapter outlines ideas that successful project leaders can use to get their projects going and sustain progress, without having to resort to command-and-control tactics.

An obvious difference between the typical day of a project contributor and the day of a project leader is how time is spent. For project team members, most time is dedicated to technical tasks. The guideline that’s frequently used for purposes of project estimating is that about two-thirds of the time in each team member’s typical workday (roughly five to six hours) can be spent doing technical work. This estimate is approximately accurate because the remaining third of each contributor’s time is consumed by meetings, e-mail, telephone calls, biological imperatives, and other activities unrelated to assigned project tasks. For a project leader, though, the overwhelming majority of time is consumed by meetings and communications. A study of project managers at Hewlett-Packard some years ago found that less than 5 percent of a leader’s time was dedicated to technical work, whereas 85 percent was allocated to people management and project coordination. This pattern seems to recur in projects of all types and in all companies. Successful project leaders inevitably become generalists, and over time they assume less and less personal responsibility for technical project work.

This transition can be extremely difficult because the image most people have of themselves is closely tied to what they do. Early in my project management career, I was asked to be a group supervisor and lead a team of 12 systems programmers at DuPont (which, despite the implication of the title, was not a management position). I found this transition quite painful. Particularly hard for me was delegating work to members of my team that I knew I could do faster and better. To those of us who are good at problem solving and who tend to seek the best results, delegation can be very frustrating. I knew, however, that coordinating the work of a dozen people while continuing to own significant technical responsibility would require me to do two full-time jobs: all day dealing with the team, communicating, and leading meetings, and all night catching up with my technical task commitments. Many new project leaders discover this the hard way, at the expense of their personal life and perhaps even the success of their projects. Some new project leaders never make a successful transition because they won’t let go of technical responsibilities, and eventually they return to their role as a project contributor (or worse).

If this were not enough for a new project leader to deal with, the basic structure of your workday also changes. Like any knowledge workers, project contributors are most productive when they can concentrate and focus over longer periods of time. Interruptions are unwelcome and disruptive, so project contributors strive to protect sizable time blocks and to minimize outside influences. The world of a project leader does not permit this luxury; project leaders must be accessible and work effectively despite frequent interruptions. Whereas a technical contributor can get away with saying, “Leave me alone, I’m busy,” any project leader with this attitude suffers escalating project problems and faces increased probability of project failure.

Exactly how you spend your time as a project leader depends on the team, the project type, and many other factors. What tends not to vary is that effective team leaders spend about 10 percent of their time per team member throughout the project. This time is spread among team meetings, one-on-one discussions, e-mail, collecting and sending status reports, telephone calls, problem solving, and other interactions. A leader of a small team of three or four certainly has the capacity to be a player/coach and to carry part of the technical load. However, a leader with 8 to 12 team members (or more) has little capacity to take on project tasks. Even though little of the leader’s time spent in team management is visible in the project work breakdown structure or schedule, it is real project work. A project leader who invests too little time in leading, interacting, and communicating with the team slows progress and loses control.

Project control is never just a matter of allocating sufficient time for project leadership; you must also ensure that you are doing the right things. Project leaders must be very good at communicating (discussed in detail later in this chapter). Depending on the project, effective leadership may also require effort in a number of other areas that are alien to the role of project contributor, such as:

 Staffing and hiring for the project

 Communicating a project vision and representing the project as a whole

 Managing the relationships with customers, stakeholders, and sponsors

 Serving as liaison to external suppliers, contributors, and leaders of related projects

 Facilitating the project planning process

 Mastering project scheduling and other needed software applications

 Being responsible for project budgets, contracts, and other financial matters

 Managing project changes

 Escalating problems and issues when necessary

None of this is easy, and few project contributors have much relevant experience prior to becoming a project leader. Moving into the role gradually may help, and having access to formal training and mentoring available in the organization also makes a difference.

You can improve your project control by building appropriate project leadership skills in areas such as:

 Finding and using an appropriate operating style

 Facilitating productive communications

 Motivating the team

Operating Style

Project leaders need to determine what operating style or styles work best for their project teams. The best style to use depends on a lot of things: the specific needs of the team, team location (or locations), and the type of project. A leader may need to adopt a variety of styles to work effectively during different parts of a project or with separated parts of a project team.

The leadership style that you adopt will determine how members of the team perceive you. Most of the time, this perception matters more than actual authority. What team members think of you affects how they respond to your requests much more directly than your title or your position on the organization chart.

Power in organizations is of several kinds:

 Power of position

 Power to coerce

 Power to reward

 Power of expertise

 Power of personality

In most organizations, the most visible power is the power managers have because they are bosses. Formal authority grants the first two types of power: the power of position and the power to coerce. Employing using these two types of power is not possible for many project leaders because they don’t have much formal authority, and for some members of the project team they may have none at all. This situation is not necessarily as hopeless as project leaders, especially new ones, assume. Even managers with a great deal of formal authority are wise to use their position and the power to threaten and punish people sparingly and only as a last resort. Overusing this kind of power through pulling rank leads to problems, including resentment, demotivation, malicious compliance, and ultimately turnover.

More effective are the other types of power. The power to reward is not the exclusive province of higher-level managers; anyone in the organization can nominate others for rewards, praise people, and do other things that are appreciated. Although the upper managers in an organization may be able to grant bigger rewards, a project leader who remains alert for opportunities can thank and reward people frequently and thoughtfully, often with rewards that are appreciated a great deal.

A primary and very effective source of project leader power derives from expertise. Power based on what you know is always effective with your sponsors, managers, and stakeholders; they did, after all, put you in charge of the project. Your technical expertise may not be a great source of power on your team because many, if not most, of your team members are probably considerably more expert in their areas than you are. Even within the team, though, you might have an edge if you are recognized as a competent generalist among a group of specialists in rather narrow fields. Your expertise in project management is also a source of power, both within your team and with your stakeholders. Finally, one type of expertise that you and you alone possess derives from your project. You are the world’s foremost authority on your project, and it can be very useful to diplomatically remind people of this at appropriate times during your project.

The final source of power in the list derives from your personal relationships with others. Investing in team building, informal communication, and establishing a basis for mutual trust can also provide the project leader a good deal of power—a type that is particularly useful in times of stress and trouble. Maintaining friendly, respectful relationships with the members of your team is invaluable.

How you operate, day to day, during your project is another important part of your leadership style. Figure 3-1 shows a continuum of operating styles, with command and control on the left side and unanimous team consensus on the right. The “best” place to be in this range of options is, of course, highly situational. Regardless of the project type, in a crisis or emergency when quick action is required, the leader probably may need to act quickly without consulting the team. Similarly, faced with excessive complexity, even a five-star general or CEO with enormous authority solicits copious input before proceeding and may even decide to delegate the ultimate decision making to individuals with high levels of specialized expertise.

How Is Project Direction Determined?

Figure 3-1: Operating Styles

In your project, particularly if you have little formal authority, your options may be mostly on the right side of this operating continuum. Although this style may look like a limitation on your project control, things may not turn out that way. Using position or coercive power too often, without getting input from the team, quickly leads to rebellion and the loss of control. On the other hand, your team remains motivated if they feel that they have a say in what they are doing. When the ultimate decisions and plans that the team has contributed to are consistent with what the project requires, operating with team consensus improves your control. Because, as project leader, you generally facilitate the meetings and discussions, you have ample opportunity to influence the ultimate decisions as required by the needs of the project.

In selecting how to operate day to day, you must consider a number of factors. If the team has mostly inexperienced team members who are new to the project work, your style may shift to the left and be more autocratic. With a team of experienced contributors who know what they need to do, you are probably best served by a style that involves a lot of team consensus. Collaborative planning and decision making are effective ways to increase team member ownership and buy-in. The engagement and higher motivation that result often more than compensate for the time and effort required to arrive at agreement. Agile and other project management methods that explicitly rely on cooperation and collaboration work only if everyone is fully engaged, but control on projects of any type benefits from the ongoing and meaningful engagement of all contributors.

When action must be taken quickly, shifting to the left is always an option, but be wary of doing this too often. Good project leaders usually operate somewhere in the middle of the range, balancing the need for team discussion and buy-in with timing and other project constraints.


Good communication is the foundation of effective project management, and it is also your most powerful leadership tool. To succeed, you need to influence both project communications and other communications.

Project Communications

What most people know about any project is based primarily on what they hear from the project leader. As the project leader, you collect the project status information, so you see it first. You are responsible for summarizing, filtering, and reporting the information to everyone involved with your project: to stakeholders and sponsors, to members of your team, and to the leaders of related projects. Providing clear, factual information that conveys the current status of your project is essential, and doing this well can be a source of substantial influence. When things are going well, people are impressed with your work and your team. If things are not going well, factual reporting that describes the situation and shows what you are doing to recover provides appropriate visibility and assists you when you must enlist help. To a great extent, what you say and how you say it will determine how you are perceived as a leader, particularly by your managers and peers.

The methods you use for communication also matter. Project communications can take many forms, and project leaders must use all available methods that make sense. Effective project leaders tend to overcommunicate important information. It is always worse for people connected to your project to lack data that they need than to occasionally hear something more than once. In fact, effective project leaders employ some important types of seemingly redundant communication practices—for example, following up complicated written communications with a telephone call (to clear up any potential confusion) and documenting the content of a phone call or discussion in a follow-up e-mail (to verify what was discussed and provide a permanent record). Thorough communication throughout a project is one of the most essential control tools available to a project leader.

Leadership also involves communication outside your project team. Regardless of your authority or formal position, as the project leader you are responsible for providing periodic project updates and presentations. Your communications with customers, stakeholders, and leaders of related projects provide them with a window into your work. What you report allows you to emphasize aspects of the project that you particularly want others to be aware of. Increasing the visibility of accomplishments that matter to these people raises your profile with them and improves your influence. When you need involvement from stakeholders or leaders of other projects to resolve a problem situation, clearly describing the consequences of the issue can accelerate their assistance. When things are going well, reporting good progress minimizes any potential interference or unwanted help that might otherwise be inflicted on your project. What you say and how you say it very powerfully affects your overall project community.

Communications with people you report to, such as sponsors and managers, are equally important. Your reporting permits you to build a great deal of influence with stakeholders having direct authority over your work. In addition, communication with sponsors and managers can allow you to turn the tables on those people when necessary. One key lever of control for the project leader is the assignment of task ownership (the relationship between ownership and project control is explored in more detail later in this chapter and in Chapter 6). As project leader, you have an obligation to report on the progress of each identified activity in your project, naming the individual who is assigned responsibility for it. Savvy project leaders, especially those who have minimal authority, formally assign activities such as approvals, decisions, and other responsibilities that the project leader may not be empowered to complete to their managers and sponsors—with their agreement, of course. Reporting that project progress is stalled—including a big, red stoplight indicator next to a manager’s name as