12.4 Decision Making

< Day Day Up >

Sometimes, on large projects, your team leads will get caught up in some controversy that from your perspective is trivial, if not manufactured. It might be technical, logistical, or far more social in nature, something we used to call "clashing egos." In a group setting, practically any minor issue can turn into a big one in which team leads get at each other's throats, and you feel compelled to intervene.

Throughout this book, the idea of consensus has been stressed with regard to teamwork. Unlike more traditional business units, project teams work best under the principles of democracy as opposed to alternative forms of governance. The vision of the American founding fathers asserted that:

The majority rules.
That majority is based on sensible discourse, not gamesmanship.
The minority graciously accepts the will of the majority.
The majority does not lord over the minority.

Adopting these principles is very important, because you want buy-in from the whole team once an issue has been debated and its potential outcomes weighed with honesty and fairness. Without buy-in, people's future cooperation cannot be assumed, and you wind up fighting more battles than you have the time, energy, or guile to win. Schisms in the team will appear. If you have made enemies, they will lobby against you, possibly at every turn, just because that is how the real world works. This may be done behind your back while they smile in your face. "Et tu, Brutus?" could be the final words of a bleeding project manager about to share Caesar's ignominious fate.

With buy-in, however, you have cooperation. Those opposed to a particular decision are more likely to take on the air of the loyal opposition than guerrilla warriors. This is because they feel they have an equal chance of being on the winning side the next time around. This is definitely the mood you want to pervade your team. The sharp, high energy level that healthy competition creates is okay, too, and is far more desirable than having a team of saboteurs or apathetic "yes men" for that matter.

There is also the practical matter that the democratic environment encourages team members to work together, possibly without your occasional knowledge or participation. Control freaks who pose as managers will shudder at this vision, of course; however, five will get you ten that if you insist on being looped into every project conversation or decision, you will become an anathema to the team and burn yourself out to boot.

This is not to say, however, that the majority is always right or that your project is immune to power plays that corrupt the decision-making process. I have seen instances where team leads articulate bogus arguments to advance personal agendas. Perhaps the worst I ever saw was a consultant looking to increase billable hours by creating confusion regarding "technical issues" - a tactic to which he felt the project manager was vulnerable. Vendors are also notorious for muddying the waters in this manner, although their agendas are usually pretty transparent unless you are incredibly gullible. I have also seen my share of the "we would tell you but then we would have to shoot you" approach by a clique within a project team when their rationale was challenged. Quite frankly, calling their bluff is not a bad response, but that depends one's personal sense of adventure.

Anyhow, at some point you are likely to find yourself suspending democracy long enough to mandate a decision. Your heart may be pure when you do this, but the team or portions thereof may react to your momentary lapse into dictatorship with rebellion. Parents often resort to saying, "because I said so" when their managerial prerogative is questioned by their offspring. You will be lucky to pull that off more than once in your project management career.

The trick is to have previously established yourself as an even-handed player and one who is willing to make that occasional deal. Fairness is important in that you want to be seen as a manager who does not let the same people lose all the time. I have seen cabals take over projects to the detriment of team unity and the project manager's reputation. These undesirable consequences can taint the project and linger on well past the here and now. Here are a few ways to tread lightly on this one:

Be sure that the loser does not feel that way for too long.
Give a team lead a discrete heads up that you will be throwing your weight behind an opposing point of view or player.
If you proffer an olive branch, make it count. Sincerity of intent counts for naught. If you tell someone you will make it up to them, do so in a meaningful and timely manner.
If you are a person of integrity, people will give you the benefit of the doubt even when you rule against them. They will understand that you are doing so with the project's interest in mind, not to throw a bone to some other project posse. The loser may take time off for a good sulk, but, as a rule, they will return to the fold.
Do not socialize with one part of the group to the exclusion of the others. Breaking this rule is the best way to ruin your reputation, with the possible exception of getting caught in a bold-faced lie or some other duplicitous act.

I decided not to plumb my experience for instructive examples for this topic out of respect for previous and current relationships. Suffice it so say that if you take this section to heart, sooner or later you will find yourself in one of these scenarios and the appropriate remedy will reveal itself to you.

< Day Day Up >