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

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.

Influence

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 noncompliance 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.

Metrics

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:

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

2. 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

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