The 77 Deadly Sins of Project Management

Management Concepts Press

• Publisher: Berrett-Koehler Publishers
• Year: 2009
• Print ISBN:
  9781567262469
• Edition: 1
• eBook ISBN:
  9781567262933
• Topic: Business
• Subtopic: Forecasting
• Index: Business

Combat the Deadly Sins of Project Management!
Project management is a tough business. Not only must project managers contend with schedules, budgets, and a host of stakeholder demands, but they must also deal with sometimes vexing human behaviors, such as whining, indecision, opposition, inflexibility, complacency, and tunnel vision, to name a few. Projects can be negatively impacted by common "sins" that hinder, stall, or throw the project off track.
In The 77 Deadly Sins of Project Management, the contributors focus on each "deadly sin" and probe its manifestations and consequences for projects. By sharing their personal experiences, as well as some historical events, the contributors spotlight the effects and costs — both financial and human — of failing to get a handle on these sins and reign them in. Through anecdotes and case studies, The 77 Deadly Sins of Project Management will help you better understand how to execute the myriad aspects of today's projects.
• Identify danger signs and solutions for each "sin"
• Learn proven methods for tackling project mishaps
• Gain practical and hands-on information from seasoned professionals
• Keep a variety of "sins" from derailing your project
BONUS!Each book comes with a "77 Deadly Sins of Project Management" poster!

1 Acquiescence

Acquiescence is the act or condition of giving tacit assent; agreement or consent by silence or without objection; compliance. In project management, acquiescence can create a false sense of consensus.

The Sin

The best way to define acquiescence in the context of project management is to consider the Abilene paradox. The Abilene paradox is a management concept observed and articulated by Jerry Harvey, professor emeritus at George Washington University. It refers to the behavior of a group of people when they make a collective decision that is counter to the wishes of anyone in the group. Simply put, it’s the tendency of groups to make decisions that no one individually really likes or supports. People in the group go along without questioning the decision because of fear, a need to conform, or perhaps an attempt to avoid conflict with the group or their superiors. The acquiescence, or tacit agreement, of each individual on a project team results in a decision that appears to be a consensus decision but in reality is not supported by the team.

Part of our social behavior, acquiescence is evident in social interactions everywhere. In organizations, acquiescence is usually an outgrowth of organizational culture. An organization that is very consensus-oriented, and that actively or passively discourages individual drive, is one that foundationally supports and could nurture harmful acquiescence. Interestingly, acquiescence can be manifested on projects positively or negatively.

Positive acquiescence is manifested when a project team is moving toward a decision, team members agree with the decision, and they give their tacit agreement through silence to expedite the decision. In such a situation, acquiescence is helpful because team members are supporting the operation of the project team through their behavior.

Negative acquiescence is manifested when a project team is moving toward a decision, team members do not agree with the decision, and they enable future conflict or disruption by giving their tacit agreement through silence. In such a situation, acquiescence is not helpful because team members are hindering the operation of the project team through their behavior.

A Case of Acquiescence

On agile teams, the person who represents the business organization is designated the “product owner.” The product owner is responsible for maximizing the financial return of the product by defining business value, facilitating the creation of product features, prioritizing those features, and deciding the order and combinations in which the product features are released. The product owner’s role is crucial; he or she must not only be knowledgeable about the business, but must also be empowered by the business organization to make decisions on its behalf. Because agile teams operate in short, time-boxed iterations or sprints, time is of the essence every day. Therefore, the speed of an agile team (and its success or failure) hinges on good decisions made quickly by the product owner.

One of the organizations with which I worked enthusiastically embarked on an agile initiative; unfortunately, they just could not seem to empower their product owners. Besides having a deep interest and commitment to its teams and associates, this organization had an overly consensus-driven culture. Any decision had to have the agreement of all parties involved, including almost the entire management chain of command. This meant that when a product feature was being considered, the product owner had to take the discussion back to management and get its approval before moving forward. The resulting lag in decision-making seriously hampered the team’s ability to deliver customer value.

In this case, acquiescence on the part of multiple team members resulted in compliance with organizational culture to the detriment of the team. The project manager and other team members, although openly unhappy with the situation in team meetings, failed to raise the non-empowerment of the product owner as an issue with senior managers and other stakeholders in project retrospectives and reviews. The product owner and senior managers also gave their tacit agreement to the norms of the organizational culture, even though they knew those norms were in conflict with the rapid decision-making required for an agile approach to succeed.

The short-term cost of the problem was that project deliverables took much longer than necessary because of the delay in decision-making. The long-term cost of the problem was that the teams were not able to achieve the rapid, incremental delivery that agile methods are designed to facilitate, and therefore the investment in agile methods was not as profitable as it could have been.

Danger Signs

Acquiescence is a very difficult problem to identify, surface, and resolve. It sometimes requires active disagreement and even conflict on the team, which may not be comfortable for some members. To address negative acquiescence effectively, a project manager needs to understand each team member’s personality and style. For example, if a team member who is usually loquacious quietly goes along with a decision, it might be worth taking that person aside and discussing the decision privately. Danger signs of acquiescence include significant decisions being agreed on by all members of the team too quickly and an increase in private conversations taking place outside regular team interactions.

Solutions

The problems caused by acquiescence can be hard to detect. Awareness is a key first step toward overcoming negative acquiescence. It’s important to recognize that organizational culture and norms may be encouraging or rewarding this behavior.

The solution to resolving negative acquiescence lies in getting better at managing agreement. Primarily, project managers need to understand that this is more a problem of managing agreement rather than of managing conflict.

Tips for Addressing Acquiescence

• 

  Ensure that all affected team members actively contribute to the discussion around team decisions.
• 

  Facilitate an organized discussion, with each person getting an explicit turn to speak his or her mind, voicing at least one concern even with a decision they support.
• 

  Capture and circulate the team’s agreement in writing to avoid any misunderstandings.
• 

  Create an environment where team members are not afraid to speak their minds.

2 Assuming

Assuming is taking for granted without proof, supposing, or postulating. We all need to make assumptions in order to simplify life and make decision-making more manageable. However, we must recognize that assuming is dangerous: We could assume something that turns out to be wrong. In project management, that wrong assumption could cause significant problems for our project.

The Sin

An assumption is a guess about the future (see guessing). No one knows the future with any useful degree of certainty, so we all make assumptions of various kinds to be able to make decisions about how to proceed. In daily life we make numerous hidden assumptions without realizing that we’re doing it, and most of the time that is a perfectly safe and sensible thing to do. Sometimes we also make explicit assumptions, usually about the big issues where it matters if we get things right or wrong.

Projects take place in the future, and when we plan them we have to think about how the future might turn out. Just as in many areas of “normal life,” there are lots of things we don’t know about what the future might hold for our projects, so we have to make assumptions, or guesses. Projects involve several important types of assumptions, including:

• 

  Scoping assumptions. For example, we may assume that our project includes the requirement to produce a full set of documentation, that it needs to be provided in English only, and that we can supply it in electronic format.
• 

  Planning assumptions. For example, we expect all named members of the project team to be available when we require them, to stay on the project for the full duration, and to have the skill set they need to perform their assigned tasks.
• 

  Estimating assumptions. For example, we assume that the cost of a novel task can be derived by multiplying the number of people on the task and a standard daily rate by the average number of days that this task has taken on previous similar projects.

Assuming takes place most often in the pre-project planning stages, when key parameters of the project are being determined, answering the questions of why, what, how, when, who, how much, and how long. It is common practice to record these assumptions in the project charter, business case, or statement of work, although in most cases this is not done well and the list of assumptions is usually incomplete.

Of course, in many cases it is quite safe to assume something about our project, particularly if the chance of our assumption turning out to be wrong is very small or if the consequence of a wrong assumption would be insignificant. But if we make an unsafe assumption about something important, our project could really be in trouble if it turns out that we guessed wrong.

A Case of Assuming

A well-known example where assuming caused a major problem is the case of the National Aeronautics and Space Administration (NASA) Mars Climate Orbiter mission in September 1999. NASA lost the $125 million orbiter because the contractor’s engineering team used English units of measurement (feet and inches) while the NASA team used the more conventional metric system (meters and centimeters) for a key spacecraft operation. This resulted in a navigation error that pushed the spacecraft too close to Mars, and it consequently broke up upon entry into the Martian atmosphere. Each team assumed that the other team was using the same units, and no one checked.

Solutions

Fortunately there is a simple way to avoid committing the sin of assuming, by using the technique of assumptions analysis and linking it to the risk management process. Assumptions analysis involves three steps:

1. List assumptions
2. Test assumptions
3. Identify risks.

The first step is to list all the assumptions that have been made about the project. This requires the ability to think reflectively and creatively, as w...

Table of contents

• Cover
• Title Page
• Copyright
• Contents
• Preface
• Chapter 1 - Acquiescence
• Chapter 2 - Assuming
• Chapter 3 - Avoidance
• Chapter 4 - Barriers
• Chapter 5 - Blaming
• Chapter 6 - Blinders
• Chapter 7 - Bureaucracy
• Chapter 8 - Carelessness
• Chapter 9 - Chaos
• Chapter 10 - Charity
• Chapter 11 - Close-Mindedness
• Chapter 12 - Cluelessness
• Chapter 13 - Complacency
• Chapter 14 - Conflict
• Chapter 15 - Confusion
• Chapter 16 - Consensus
• Chapter 17 - Copying
• Chapter 18 - Cowardice
• Chapter 19 - Creep
• Chapter 20 - Democracy
• Chapter 21 - Despair
• Chapter 22 - Deviation
• Chapter 23 - Dispassion
• Chapter 24 - Disrespect
• Chapter 25 - Dysfunction
• Chapter 26 - Ego
• Chapter 27 - Excess
• Chapter 28 - Exclusion
• Chapter 29 - Excuses
• Chapter 30 - Failure
• Chapter 31 - Favoritism
• Chapter 32 - Fragmentation
• Chapter 33 - Gaming
• Chapter 34 - Guessing
• Chapter 35 - Haphazardness
• Chapter 36 - Helplessness
• Chapter 37 - Hope
• Chapter 38 - Immaturity
• Chapter 39 - Inattentiveness
• Chapter 40 - indecision
• Chapter 41 - inefficiency
• Chapter 42 - Inflexibility
• Chapter 43 - Isolation
• Chapter 44 - Lateness
• Chapter 45 - Laziness
• Chapter 46 - Magical Thinking
• Chapter 47 - Malfeasance
• Chapter 48 - Meetingitis
• Chapter 49 - Misalignment
• Chapter 50 - Miscommunication
• Chapter 51 - Mismanagement
• Chapter 52 - No Authority
• Chapter 53 - Not-Invented-Here
• Chapter 54 - Obtuseness
• Chapter 55 - Omission
• Chapter 56 - Opposition
• Chapter 57 - Politics
• Chapter 58 - Poor Planning
• Chapter 59 - Poor Requirements
• Chapter 60 - Popularity
• Chapter 61 - Powerlessness
• Chapter 62 - Prevarication
• Chapter 63 - Procrastination
• Chapter 64 - Promises
• Chapter 65 - Quitting
• Chapter 66 - Rebelliousness
• Chapter 67 - Resource Reallocation
• Chapter 68 - Rigidity
• Chapter 69 - Satisficing
• Chapter 70 - Scapegoating
• Chapter 71 - Shoddy Quality
• Chapter 72 - Shortsightedness
• Chapter 73 - Silence
• Chapter 74 - Surrender
• Chapter 75 - Suspicion
• Chapter 76 - Tunnel Vision
• Chapter 77 - Whining
• Assessment Tool: Which Sins Are Plaguing Your Project?
• Assessment Tool: What Are the Challenges on Your Project?
• About the Contributors
• Related Project Management Resources