Results Without Authority: Controlling a Project When the Team Doesn't Report to You / Edition 2 available in Paperback, eBook
Results Without Authority: Controlling a Project When the Team Doesn't Report to You / Edition 2
- ISBN-10:
- 0814417817
- ISBN-13:
- 9780814417812
- Pub. Date:
- 01/29/2012
- Publisher:
- AMACOM
Results Without Authority: Controlling a Project When the Team Doesn't Report to You / Edition 2
Buy New
$17.96Buy Used
$15.27
-
SHIP THIS ITEM— Not Eligible for Free Shipping
-
SHIP THIS ITEM
Temporarily Out of Stock Online
Please check back later for updated availability.
-
Overview
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. You 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.
Product Details
| ISBN-13: | 9780814417812 |
|---|---|
| Publisher: | AMACOM |
| Publication date: | 01/29/2012 |
| Edition description: | Second Edition |
| Pages: | 288 |
| Product dimensions: | 5.90(w) x 8.90(h) x 1.00(d) |
| Age Range: | 18 Years |
About the Author
Read an Excerpt
Results Without Authority
By Calvert T. Kendrick
AMACOM Books
Copyright © 2006 Calvert T. KendrickAll right reserved.
ISBN: 0-8144-7343-1
Chapter One
Control Through Influence
IT IS OFTEN SAID that management is assigned, but leadership must be earned. One aspect of earning the role of leader is building influence both within and outside of your project team. Your working style matters a great deal, and your influence with others depends on what you have to offer them in exchange for what you need and what you do to enhance your influence 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 a lot of background and experience that relates to the assignments for which they are responsible. Generally speaking, if contributors are good at what they do, sooner or later they find themselves leading a project, not just contributing to it. The transition may be gradual and involve taking a lead role in a portion of a project that depends on several people, or it may be abrupt-resulting in yet another "accidental project manager." However it occurs, a pair of challenges comes with the territory. The transition from primarily contributing to aproject to leading one involves a different set of skills and responsibilities, 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 will now spend most of your time dealing with people and communications. To do this well, and to be successful leading a project when you have little power to coerce commitments out of people, you must establish and maintain influence over the team, stakeholders, and sponsors. This chapter outlines ideas that successful project leaders use to get their projects going and sustain progress, without having to resort to command-and-control tactics.
One of the most obvious differences 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 spent doing technical tasks. The guideline that's frequently used for purposes of project estimating is that about two-thirds of the hours in a typical workday, or roughly five to six hours, are spent doing technical work. In many cases, this is approximately accurate, with the remaining one-third of the team member's time consumed by meetings, email, telephone calls, biological imperatives, and miscellaneous other activities unrelated to the project. For a project leader, the overwhelming majority of time is consumed by meetings and communications. A study of several dozen project managers at Hewlett-Packard in the 1990s found that less than 5 percent of a leader's time was dedicated to technical work, while 85 percent was allocated to people management and project coordination. This pattern recurs in projects of all types and in all companies; project leaders inevitably become generalists, and as time goes on 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 tied up in what they do. When I was asked to be a "group supervisor" and lead a team of twelve systems programmers at DuPont (which, despite the implication of the title, is not a management position), I found the transition literally painful. I delegated work to members of the team that I knew I could do faster and better. To an engineer who's always seeking the best result, this is about even on the aggravation spectrum with being forced to watch someone incorrectly fold a map. I knew, however, that leading a team that size 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 technical task commitments. Many new project leaders learn this the hard way, at the expense of their personal life and also, frequently, the project. Some new project leaders never do make a successful transition because they can't let go of technical responsibilities, and eventually they resume their role as a project contributor (or worse).
If this were not enough for the new project leader to deal with, how your time is broken up also changes. Project contributors, like all knowledge workers, are more productive when they can concentrate and focus over longer periods of time. Interruptions are unwelcome and disruptive, so project contributors strive to protect their time blocks and minimize outside influences. The world of a project leader does not permit this; project leaders need to multitask, to work efficiently despite frequent interruptions. A technical contributor can say, "Leave me alone, I'm busy," but the leader who retains this attitude will encourage escalating project problems and increased probability of project failure.
Exactly how you spend your time as a project leader depends on the team, the project type, and a number of 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 will be spread among team meetings, one-on-one discussions, email, collecting and sending status reports, telephone calls, problem solving, and other interactions. For a leader with a small team of three or four, there is certainly capacity to be a "player/coach" who carries a part of the technical load. However, for a leader with eight to twelve team members (or more) there is very little capacity to take on technical work. Even though little of this team-management work done by the project leader typically appears on the project work breakdown structure or schedule, it is "real project work." A project leader who invests too little time in leading, managing, and communicating with the team will slow progress and lose control.
Putting sufficient time into project leadership is essential for project control, but it also must be spent doing the right things. Project leaders need to be very good at communicating, which is discussed in detail later in this chapter. Depending on the project, effective leadership may also require effort in a number of other areas that were not part of 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 with any of it before becoming a project leader. Moving into the role gradually may help, and having access to formal training and mentoring available in the organization will also make 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 will 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. In most instances, perception matters more than actual authority; what team members think of you will affect how they respond to you much more directly than your title or your place on an organization chart.
Power in organizations is of several kinds:
* Power of position
* Power to coerce
* Power to reward
* Power of expertise
* Power of personality
The most visible power in most organizations is the power managers have because they are "the boss." Formal authority grants the first two types of power, the power of position and the power to coerce. Leading using these two types of power is not possible for many project leaders because they don't have much formal authority, and over some members of the project team they may have none at all. This is not necessarily as bad 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. Overuse of this sort of power by "pulling rank" leads to 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 other people, and do other things that will be appreciated. While 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 more.
A primary and very effective source of project leader power derives from expertise. Power from your technical expertise is 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 a good deal more expert in their areas than you are. Even within the team, though, you might have an edge if you are the only 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 those who surround your project. Finally, the expertise that you and you alone possess concerns your project. You are the world's foremost authority on your project, and it can be very useful to diplomatically remind people of this fact at strategic times during your project.
The final source of power derives from your personal relationships with others. Investing in team building, informal communication, and establishing a basis for mutual trust also provides the project leader a good deal of power, which is particularly important in times of stress and trouble. You don't need to be the most gregarious, happy, outgoing person on the planet to maintain friendly, respectful relationships with the members of your team.
How you operate, day to day, during your project is another important aspect of 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 ideal spot to be in this range of options is, of course, always situational. Regardless of the project type, in a crisis or emergency where quick action must be taken, the leader may have to act quickly, without consulting the team. Similarly, faced with excessive complexity, even a five-star general or CEO who has enormous authority will solicit input before proceeding and may even decide to delegate the ultimate decision making to individuals with high levels of specialized expertise.
In your project, particularly if you have little formal authority, you may normally only have options on the right side of this operating continuum. While this may appear to be a limitation on your project control, it may not turn out to be. Using position or coercive power too often, with no input from the team, can quickly result in rebellion and loss of control. On the other hand, your team will remain more motivated when 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. Since, as project leader, you will generally facilitate the meetings and discussions, you will have ample opportunity to influence the ultimate decisions to ensure that they will serve the needs of the project. In selecting how to operate day to day, you need to consider a number of factors. If the team has mostly inexperienced team members who are new to the project work, your style will shift to the left and be somewhat more autocratic. With a team of experienced contributors who know what they need to do, you will probably be best served with a style that involves more team consensus. Collaborative planning and decision making leads to team member ownership and buy-in, which results in higher motivation, which in turn will more than compensate for the time and effort required to arrive at agreement.
When action must be taken quickly, shifting to the left is always an option, but be aware of the dangers if you do it 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 requirements.
Communication
Good communication is the foundation of effective project management, and it is also your most powerful leadership tool. What most people know about any project is shaped fundamentally by the project leader. Most status information collected is seen first by you, the project leader. You are responsible for summarizing, filtering, and reporting information to everyone who is involved with your project: to stakeholders and sponsors, to members of your team, and to 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. If things are going well, people are impressed with your work and your team. If things are not going well, factual data (just enough, never more than people need to hear) will show what you are doing to recover and provide appropriate visibility when you need to enlist help. To a great extent, what you say and how you say it determines how you are perceived as a leader, particularly by your managers and peers.
Communication methods also matter. Project communications take many forms, and project leaders must use all methods available to them. Effective project leaders tend to "overcommunicate" (running just short of being annoying) because it is always worse for people connected to your project to lack data that they require than it will be for them to receive extra copies of information that they do need to see. 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 email (to verify what was discussed and provide a permanent record). Thorough communication throughout a project is one of the most effective control tools available to the 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 to customers, stakeholders, and leaders of related projects will provide them with a window into your work and allow you to emphasize aspects of the project that you particularly need them to be aware of. Making visible the accomplishments that matter to these people will raise your profile with them and increase your influence. When you need involvement from stakeholders or leaders of other projects to resolve a problem situation, highlighting the issue will accelerate their assistance. When things are going well, reporting good progress will minimize any potential interference or unwanted "help" that might otherwise be inflicted on your project. What you say and how you say it has a very powerful effect on your overall project community.
(Continues...)
Excerpted from Results Without Authority by Calvert T. Kendrick Copyright © 2006 by Calvert T. Kendrick. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Contents
ACKNOWLEDGMENTS
1. CONTROL OF PROJECTS
Who’s in Charge?
Structure of This Book
Elements of Project Control
No One Ever Said That Projects Are Easy
2. CONTROL THROUGH PROCESS
Project Management Processes
Quality Management
Project Infrastructure
The Project Management Office
Key Ideas for Project Processes
3. CONTROL THROUGH INFLUENCE
Appropriate Leadership Styles
Getting Through Giving
Enhancing Influence
Maintaining Relationships
Key Ideas for Influencing
4. CONTROL THROUGH PROJECT METRICS
Desired Behaviors
Types and Uses of Project Metrics
Measurement Definition and Baselines
Potential Problems and Measurement Barriers
Key Ideas for Project Metrics
5. CONTROL BEGINS WITH PROJECT INITIATION
Sponsorship
Project Vision
Project Launch
Start-Up Workshops
Projects with Cross-Functional, Distributed, and Global
Team Members
Key Ideas for Project Initiation
6. BUILDING CONTROL THROUGH PROJECT PLANNING
Plan Collaboratively
Measure Your Plan
Set a Realistic Project Baseline
Use Your Plan
Key Ideas for Project Planning
7. MAINTAINING CONTROL DURING PROJECT EXECUTION
Deploying Status-Based Metrics
Status Collection
Informal Communication
Maintaining Relationships
Keeping Your Team Focused
Key Ideas for Project Execution
8. TRACKING AND MONITORING FOR PROJECT CONTROL
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
9. ENHANCING OVERALL CONTROL THROUGH PROJECT
CLOSURE
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
10. CONCLUSION
APPENDIX A: EXAMPLE PROJECT INFRASTRUCTURE DECISIONS
APPENDIX B: SELECTED REFERENCES
INDEX