|Edition description:||New Edition|
|Product dimensions:||7.00(w) x 10.00(h) x 0.57(d)|
About the Author
Read an Excerpt
Neal Whitten's No-Nonsense Advice for Successful Projects
By Neal Whitten
Management Concepts PressCopyright © 2005 Management Concepts, Inc.
All rights reserved.
Mind Your Own Business
When you start work each day, do not focus on moving your company forward. If possible, do not focus on your company at all. Yes, you read correctly.
Instead, channel your energies toward successfully completing your assignments — your domain of responsibility. If everyone in your company focused on his or her domain of responsibility, the company would do just fine. In fact, your company would probably be more successful than it is today.
Do what's best for your domain of responsibility, because that is ultimately what's best for your company
Your domain of responsibility includes all responsibilities and commitments that fall within the scope of your assignment. In short, it is the area for which you are accountable. Whether you are a one-person project, a member of a 10-person project, or a member of a 1,000-person project, your project's success — and, therefore, your company's success — is directly related to how well you perform within your domain of responsibility.
There is a direct relationship between the success of the parts and the success of the whole
If you reach outside your domain of responsibility and attempt to fix or improve something there, I view this as extra credit in terms of your actions and your performance. I am not a proponent of pursuing extra credit if it is at the sacrifice of successfully completing your commitments within your domain of responsibility. It has been my experience that if you focus superbly within your domain of responsibility, your contributions and overall career will shine brightly — even without the extra credit.
It usually is ill-advised to pursue extra credit at the sacrifice of your own responsibilities and commitments within your domain of responsibility
It is important to understand the difference between your domain of responsibility and extra credit. Let's look at an example:
You are a project manager of a new project. You also are a member of an organization that has many projects managed concurrently. The organization does not have well-defined project management best practices that you can adopt for your project. Therefore, you (or others at your direction) must define practices to be followed on your project. The pursuit of these tasks is not extra credit because you need well-defined practices to support the success of your project.
However, the project management practices you define should be created only for your project. They should not be designed and documented to become institutionalized for other projects to use. If they are prepared in a manner to be used beyond your project, then these actions are examples of extra credit. Performing the extra credit would require that much more time be invested, at the expense of your project.
In the course of performing your commitments, any action that you feel you must perform to complete your commitments successfully becomes part of your domain of responsibility. It is often easy to shrug off being accountable for actions that you require from others, but if these actions are required to complete your commitments successfully, it becomes your duty to ensure that they occur.
Your domain of responsibility includes any activities and actions that are necessary to support the success of your commitments
Examples of items that are in a project manager's domain of responsibility, but often are weakly pursued, include:
Seeking out a project sponsor and establishing an effective relationship
Adopting/defining project management best practices for your project
Ensuring client participation
Obtaining commitments from others and then holding them accountable
Escalating project-related issues to achieve their timely closure
Enforcing effective change control to manage scope creep
Defending the right project plan to the project sponsor, executives, or client
Boldly driving your project to a successful completion, not waiting for someone else to do it for you.
Focusing on your domain of responsibility doesn't mean that you don't care about your company. Your actions demonstrate the opposite. The success of your assignments strengthens the success of your company. If you care about the success of your company, then care about the success of your domain of responsibility. Focus on you and your team members being accountable for your respective domains of responsibility and the rest will follow.
If you want to turn a company around, then turn around the thinking of the members of that company
Let's Talk: Questions & Answers
Q1.1As project manager of a project with 10 members, are you saying that my domain of responsibility includes the performance of those 10 members?
A1.1 Yes, for starters. As the project manager, your domain of responsibility not only includes the performance of the 1 0 members as it relates to your project, but it includes perhaps dozens of other people as well. For example, if the successful launch, execution, and delivery of your project includes working with many other people, departments, divisions, companies, vendors, and contractors, then all of these people and the relationships you have with them are included in your domain of responsibility. Anything that can impact the success of your project is within your domain of responsibility.
Q1.2As a project manager, does my domain of responsibility include other projects on which my project members may also be working?
A1.2 No, not directly, because you are not responsible or accountable for the success of those projects. Your focus must be on your project. You do, of course, care that your project members meet their commitments on your project. Your objective is to do whatever is necessary to help them be successful on your project. That could include working with the project managers of other projects that your project members also work on so that you can more carefully balance the workload of your members to help ensure their success on your project.
A project manager's domain of responsibility is almost always far broader than first assumed
Q1.3What if another project is in trouble and its project manager seeks help from me and from members of my project? Should I help?
A1.3 If anyone ever asks for two hours of your time or two hours of time from any of your project members, you say "yes." Why? Because as a mature professional you should almost always be able to find two hours to help someone. However, if the request for help would cause your project to miss its external commitments, then you must say "no." A project manager does not have the authority to change externally committed dates; only the project sponsor or client has that authority.
However, as a good companywide team player, after saying "no," you can then suggest, if appropriate, that the two of you go to a person or committee that has the authority to prioritize projects. Then, whatever the outcome, you willingly comply because it's in the best interests of the business. The person or committee that makes the decision has the power of authority over the two projects; in other words, that committee's domain of responsibility may include managing the portfolio of projects in which these two projects are included.
Q1.4Isn't it good for my career to go after "extra credit," as you call it?
A1.4 The first best thing that you can do for your career is to focus on your domain of responsibility and perform well in that arena. If everyone in a company focused on consistently performing successfully within their domains of responsibility, the company would benefit greatly. If you choose to go after extra credit, be careful that you do not sacrifice the successful completion of commitments that fall within your domain of responsibility. So, yes, extra credit can be a good thing for your career — but only if your domain of responsibility is well serviced.
By the way, if the "extra credit" becomes part of your overall duties, it no longer is extra credit. It now falls within your domain of responsibility.CHAPTER 2
Are You a Benevolent Dictator? You Should Be!
"Nothing strengthens the judgment or quickens the I conscience like independent responsibility." — Elizabeth Cady Stanton, American 19th century women's rights leader
In running a country, democracy (more specifically, a republic) appears to be the best thing going to date. However, in running a business or project, my experience has shown that the benevolent dictator style is the most effective.
A benevolent dictator leads by actively soliciting information and opinions from project members and others — listens, then demonstrates the leadership, courage, and boldness to personally make the right decision and stand accountable for that decision.
A benevolent dictator also holds his or her subordinates accountable for their decisions; they, in turn, hold their subordinates accountable for their decisions; and so on. In other words, everyone is encouraged and expected to make the decisions that affect their own domain of responsibility — and to stand by them.
Micromanaging, consensus management, and democratic rule all can be highly ineffective leadership styles
When defining a benevolent dictator, I am not talking about micromanaging. Micromanaging occurs when a leader chooses to make decisions for anyone and everyone within the leader's influence. The micromanaging "leadership" style is highly offensive; it neither teaches the importance nor capitalizes on the promise of accountability. It should only be used in rare instances, for very short periods of time, and in cases where the reason for doing so is clearly understood.
Those who are micromanaged lose their deepest passion and sense of accountability
Many organizations and projects attempt to operate on either consensus or democratic rule. Consensus, which has been overhyped for years, can be an ineffective tool in managing teams and projects. Consensus is obtaining buy-in from a team by adjusting the final decision to a position with which everyone can live. For other than the most highly trained teams, consensus often causes the most important decisions to be compromised, i.e., watered down. In an attempt to satisfy all team members so that they buy into the team's decision, the solution is often non-optimal and, frankly, is often without vision and personal commitment. Consensus can drive mediocrity.
What's that? You say there is personal commitment in a consensus-driven team because everyone had a say in the decision? Yes, everyone had an opportunity to speak their mind, but my experience shows that many don't speak up or they are quick to compromise or live with someone else's proposal — even if they feel it is weak. It is not unusual for the most reserved and shy members of a consensus-forming team — often those not heard from — to be among those who have the best ideas. Moreover, many members of a group consensus don't feel personally committed. They hide behind the facade of the team.
Good business is not about everyone agreeing on an outcome; it's about achieving the best outcome
What do I mean by personal commitment? Personal commitment is when you, personally, are charged with making a decision and then you, personally, are held accountable for the outcome of that decision. Teams cannot feel this level of accountability; only individuals can.
Individuals, not teams, are charged with accountability
What about using the democratic voting process? Projects or organizations that consistently reach decisions by democratic rule frequently can be more ineffective than those reaching decisions through consensus. Why? Because the majority vote is usually enough to lock in a decision. Unfortunately for the bigger picture — say a project — everyone with a vote to cast is looking out after his or her own personal interests or the personal interests of the team he or she represents. Consequently, the right business decision for the project can easily be overlooked or dismissed.
Reaching a project-related decision through a democratic process often leads to a solution that may not be in the best interest of the project
You might be asking about now, "If the benevolent dictator concept is so effective, then why don't more leaders adopt this style of leading?" The biggest reason is that to be a benevolent dictator we have to make decisions that will, at times, be unpopular. Many of us have a hard time making decisions that are criticized by others. In fact, the primary reason project managers fail is because they are too soft and have difficulty making the tougher decisions. (See Chapter 8, Are You Too Soft?)
The No. 1 reason why leaders fail is that they repeatedly demonstrate behavior that is too soft to be consistently effective
I often hear project managers and resource managers say they cannot adopt the benevolent dictator approach because they have a serious shortage of project members and employees with the good business sense — the leadership skills — to make the tough decisions expected of a benevolent dictator. I strongly disagree! For most of us, I believe we do have the people we need; they just haven't been trained properly. After all, they watch how we manage and imitate our styles.
All of us need to be trained, coached, and mentored in the skills and behaviors that make for the most effective leaders. Nearly everyone will rise to the expectations that we set for them, provided that we constructively nurture them along the way. If you want your project to be run like a business where decisions are made based on what's best for the business, and you want your project members to consistently take accountability for their own actions, then teach and encourage the powerful benevolent dictator concept at all levels of a project and organization. It's good leadership and it's good business!
The benevolent dictator is not an elitist position. Everyone on a project must think and behave as a benevolent dictator within their own domain of responsibility
Let's Talk: Questions & Answers
Q2.1Why do you say that everyone on a project should behave as a benevolent dictator? Doesn't this role belong exclusively to the project manager?
A2.1 Let's look at a project of 15 members. There is one project manager, say four team leaders, and 10 team members. The project manager and the team leaders operate as benevolent dictators within their domains of responsibility. They have project members assigned to work under their direction. They are held accountable for the performance of their teams and the quality and timeliness of their deliverables. However, the 10 team members, although not leaders of other people, find themselves working with many people from across the core team or from outlying areas such as the human resources department, contractors, vendors, procurement, and IT. The team members are accountable for their own performance and for the plethora of decisions that they must make on a day-to-day basis. They, too, are benevolent dictators within their own domains of responsibility. When this technique is in place and is working well, it complements teamwork, not distracts from it.
Excerpted from Neal Whitten's No-Nonsense Advice for Successful Projects by Neal Whitten. Copyright © 2005 Management Concepts, Inc.. Excerpted by permission of Management Concepts Press.
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
Part One: Leadership, Soft Skills, and You,
Chapter 1: Mind Your Own Business,
Chapter 2: Are You a Benevolent Dictator? You Should Be!,
Chapter 3: Ask for Help — or Become Part of the Problem,
Chapter 4: What Good Is a PM Mentor?,
Chapter 5: Is Your Professional Behavior Respected?,
Chapter 6: Recognizing and Dealing with Professional Immaturity,
Chapter 7: Behaviors to Master When Dealing with Your Leaders,
Chapter 8: Are You Too Soft?,
Chapter 9: Foster Interpersonal Communications,
Chapter 10: Turn Criticism into an Asset,
Chapter 11: Dealing with Difficult People,
Chapter 12: Don't Fear Failure,
Chapter 13: A Silver Bullet?,
Part Two: Roles and Responsibilities,
Chapter 14: Duties of the Effective Project Manager,
Chapter 15: Duties of the Effective Resource Manager,
Chapter 16: Duties of the Effective Project Sponsor,
Chapter 17: How Technical Must a Project Manager Be?,
Part Three: Project Initiation,
Chapter 18: Are You Learning from Project to Project?,
Chapter 19: Create the Desired Culture for Your Project,
Part Four: Project Planning,
Chapter 20: Should You Be Given a Project End Date?,
Chapter 21: Meet Minimum Requirements — Anything More Is Too Much,
Chapter 22: Do Not Make Long-Term Project Commitments,
Chapter 23: The Effect of Multitasking on Productivity,
Chapter 24: Contingency Buffer: Expect the Unexpected,
Chapter 25: Scope Creep: Runaway Train or Good Business?,
Part Five: Project Execution and Control,
Chapter 26: The Project Tracking Meeting,
Chapter 27: The Day After,
Chapter 28: Manage to Your Top Three Problems,
Chapter 29: Treat All Project Members Equally,
Chapter 30: Inspect What You Expect,
Chapter 31: Escalate Is Not a Dirty Word,
Chapter 32: Declare Your Project's Risk Value,
Chapter 33: How to Run an Effective Meeting,
Chapter 34: The S-Shape Curve 50/70 Rule,
Part Six: Project Closeout,
Chapter 35: Conducting a Post-Project Review,
Part Seven: Promoting the Advancement of Project Management beyond Your Projects,
Chapter 36: Project Review Mentoring Workshops,
Chapter 37: The Project Manager/Resource Manager Leadership Workshop,
Chapter 38: How to Institutionalize Improvements in Your Organization,
Part Eight: Some Final Thoughts,