Encontre seu próximo livro favorito

Torne'se membro hoje e leia gratuitamente por 30 dias.
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

Ler amostra

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

4/5 (1 avaliação)
477 página
8 horas
Lançado em:
Jan 29, 2012


For project managers looking to establish credibility and drive winning results, author Tom Kendrick’s groundbreaking system provides the key to leading cross-functional, outsourced, and other types of teams through every stage of the project cycle. Results without Authority is the definitive book on control--teaching the three principal levels of control, including project process, influence, and metrics, among other important areas. Readers learn the surefire way to keep projects moving forward: by relying only on these factors. The book’s 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, and the myth of multitasking. For project leaders lacking clear-cut authority, getting everyone on board--and keeping them there--can be a challenge. Whether you’re managing small, team-level projects or major organizational initiatives, Results without Authority is the must-have guide to getting the best outcomes for your company.
Lançado em:
Jan 29, 2012

Sobre o autor

TOM KENDRICK, PMP has over 35 years of project and program experience, including senior positions with Hewlett-Packard and Visa. A respected author, he received PMI's David I. Cleland Project Management Literature Award for the previous edition of this book.

Relacionado a Results Without Authority

Livros relacionados
Artigos relacionados

Amostra do Livro

Results Without Authority - Tom Kendrick



Controlling a Project When the Team Doesn’t Report to You



Special discounts on bulk quantities of AMACOM books are available to corporations, professional associations, and other organizations. For details, contact Special Sales Department, AMACOM, a division of American Management Association, 1601 Broadway, New York, NY 10019.

Tel: 800-250-5308. Fax: 518-891-2372.

E-mail: specialsls@amanet.org

Website: www.amacombooks.org/go/specialsales

To view all AMACOM titles go to: www.amacombooks.org

This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional service. If legal advice or other expert assistance is required, the services of a competent professional person should be sought.

PMI and the PMI logo are service and trademarks of the Project Management Institute, Inc. which are registered in the United States of America and other nations; PMP and the PMP logo are certification marks of the Project Management Institute, Inc. which are registered in the United States of America and other nations; PMBOK, PM Network, and PMI Today are trademarks of the Project Management Institute, Inc. which are registered in the United States of America and other nations; ... building professionalism in project management… is a trade and service mark of the Project Management Institute, Inc. which is registered in the United States of America and other nations; and the Project Management Journal logo is a trademark of the Project Management Institute, Inc.

PMI did not participate in the development of this publication and has not reviewed the content for accuracy. PMI does not endorse or otherwise sponsor this publication and makes no warranty, guarantee, or representation, expressed or implied, as to its accuracy or content. PMI does not have any financial interest in this publication, and has not contributed any financial resources.

Additionally, PMI makes no warranty, guarantee, or representation, express or implied, that the successful completion of any activity or program, or the use of any product or publication, designed to prepare candidates for the PMP® Certification Examination, will result in the completion or satisfaction of any PMP® Certification eligibility requirement or standard.

Library of Congress Cataloging-in-Publication Data

Kendrick, Tom.

Results without authority: controlling a project when the team doesn’t report to you / Tom Kendrick.—2nd ed.

p.    cm.

Includes bibliographical references and index.

ISBN-13: 978-0-8144-1781-2

ISBN-10: 0-8144-1781-7

1. Project management. I. Title.

HD69.P75K463 2012

© 2012 Tom Kendrick.

All rights reserved.

Printed in the United States of America.

This publication may not be reproduced, stored in a retrieval system, or transmitted in whole or in part, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of AMACOM, a division of American Management Association, 1601 Broadway, New York, NY 10019.

Printing number

10    9    8    7    6    5    4    3    2    1




Who’s in Charge?

Structure of This Book

Elements of Project Control

No One Ever Said That Projects Are Easy


Project Management Processes

Quality Management

Project Infrastructure

The Project Management Office

Key Ideas for Project Processes


Appropriate Leadership Styles

Getting Through Giving

Enhancing Influence

Maintaining Relationships

Key Ideas for Influencing


Desired Behaviors

Types and Uses of Project Metrics

Measurement Definition and Baselines

Potential Problems and Measurement Barriers

Key Ideas for Project Metrics



Project Vision

Project Launch

Start-Up Workshops

Projects with Cross-Functional, Distributed, and Global Team Members

Key Ideas for Project Initiation


Plan Collaboratively

Measure Your Plan

Set a Realistic Project Baseline

Use Your Plan

Key Ideas for Project Planning


Deploying Status-Based Metrics

Status Collection

Informal Communication

Maintaining Relationships

Keeping Your Team Focused

Key Ideas for Project Execution


Scope and Specification Change Management

Overall Control

Formal Communication

Rewards and Recognition

Project Reviews for Lengthy Projects

Project Cancellation

Control Challenges

Key Ideas for Project Tracking and Monitoring


Delivering Your Results and Getting Sign-Off

Employing Retrospective Project Metrics

Administrative Closure

Celebration and Team Rewards

Capturing Lessons Learned

Key Ideas for Project Closure






RESULTS WITHOUT AUTHORITY benefits from the hard-earned experience of hundreds of excellent project leaders and managers who have so generously shared their experiences over the years. In particular, I need to thank Terry Ash, Ron Askeland, Ron Benton, Scott Beth, Alfonso Bucero, Craig Chatterton, Karel de Bakker, Al DeLucia, Anup Deshpande, Randy Englund, Tom Fader, Wayne Goulding, Bob Gudz, Esteri Hinman, Rosemary Hossenlopp, Nancy McDonald, Bob Montevaldo, Joe Podolsky, Patrick Schmid, Richard Simonds, Ted Slater, Jim Sloane, Jose Solera, David Straker, Arun Swamy, Peter Vogel-Dittrich, Ashok Waran, J. D. Watson, and Todd Williams, who provided examples, feedback, and encouragement throughout the process of pulling this book together. I also want to thank my long-suffering spouse, Barbara Kendrick, who repeatedly read and reread the text of this book, attacking the confusion and untangling the knots.

Although these friends (and many others) deserve a great measure of the credit for what is in this book, any errors, omissions, or unnecessary complexity are all on me. If you find any, or just want to provide feedback, please let me know.

Getting results without authority involves more than a little luck. Yet luck is what happens when preparation meets opportunity. I hope in this book you find ample guidance for your preparations, and all of your opportunities result in successful projects.






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.


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

Você chegou ao final desta amostra. Inscreva-se para ler mais!
Página 1 de 1


O que as pessoas pensam sobre Results Without Authority

1 avaliações / 1 Análises
O que você acha?
Classificação: 0 de 5 estrelas

Avaliações de leitores

  • (4/5)
    This simple book made a huge difference for me. Above and beyond validating my gut-level common sense, Results Without Authority provided me with realistic and specific advice that worked in practice.