If you watched the World Series this past week, you know that one of the toughest decisions that baseball managers have to make is when to keep a pitcher in the game and when to take the ball away and go to the bull pen. It’s as much art as it is science, and the ability to make the correct call is often the difference between being hailed as a genius or denounced as a fool.

In this column, I want to discuss a similar problem facing IT managers: When do you pull a project leader off of an effort and put someone else in that spot? While every situation is unique, I’ll offer some warning signs to look for.

Establishing the principle
For some technical managers, even having a discussion about removing a project leader is counterproductive, because those managers don’t believe that leaders should be replaced until the project is completed or cancelled. They believe this to be true whether the project is going well or turning into a disaster. Their reasons for this belief fall into three categories: ethical, practical, and personal.

Ethical objections to replacing a project leader
Some IT managers view lead assignments as a kind of covenant between the organization and the team leader. The leader agrees to accept responsibility for running the project, and the organization agrees to give the leader the resources and support necessary to complete it. In this way of thinking, replacing a project leader is in some way breaking a promise the organization made to that man or woman. Whether the strategy is effective or not, it’s not ethical—at least, that’s the theory.

There is some truth to this. You can’t make someone responsible for a project without giving him or her the tools to do the job—and your support is one of those tools. That said, remember that we’re talking about a failing project. Commitment runs both ways, and if the project leader is failing to drive the project as promised, you’re under no obligation to keep the leader in charge until failure is assured.

Practical objections to replacing a project leader
Not all objections to replacing a failing project leader center on ethics. Some technical managers believe that replacing the project leader won’t solve the problem and may in fact cause new problems. They point out that changing leaders in the middle of a project can cause dissensions within the group and cause havoc with deadlines as the new leader transitions into the role. They also note that even a bad project leader likely has more institutional knowledge of the project than a replacement. For these reasons, some technical managers argue against replacing project leaders midstream.

These are legitimate concerns. If nothing else, they illustrate that taking the ball away from a project leader is a big step and something you shouldn’t do lightly. However, the truth is that some projects are so important that success is vital to the organization. If someone is dragging down such a project, he or she may have to be replaced.

One further point about morale is in order. While it’s true that replacing a project leader midstream can cause dissension, the opposite is also true. Some project leaders can become so divisive that removing them will actually improve team morale.

Personal objections to replacing a project leader
The last major set of objections to removing a troubled project’s leader centers on the action’s effect on the leader. In other words, some IT managers shy away from replacing a team leader because it might hurt the individual’s career, or at least damage his or her confidence. In making this argument, some technical managers will relate personal experiences, such as when they were removed from a task or project for spurious reasons. This makes it easy for them to sympathize with the project leader in question and, consequently, much harder for them to pull the trigger and put someone else in charge.

Of course, there is a human cost to many decisions we have to make as managers. We can’t ignore that fact without losing part of our humanity. On the other hand, managers get paid to make tough calls—much as we might wish it were otherwise. Further, ask yourself a question. Which is more compassionate, pulling a project leader off a project or allowing him or her to fail? (The question of when you should allow your subordinates to fail is an interesting one for another column but is beyond the scope of today’s discussion.)

Warning signs of impending project failure
Hopefully, by this point, I’ve convinced you that there are occasions when you have to pull someone off a project. Now the question is what to look for to determine when you need to think about replacing a team leader. While every project is different, here are some warning signs that a project might be in trouble:

  • Increase in CYA e-mail: This might seem like an odd place to start, but one of the things I always look for is an increase in the amount of project e-mail devoted to the sender’s attempts to cover his or her posterior. Not only will the amount of such e-mail increase but the distribution will also widen, as supervisors get sucked into the fray.
  • Missed milestones: This is the obvious red flag. If a project is in trouble, deadlines will start to slip.
  • Side meetings: As a project starts to slip into chaos, more meetings are scheduled. However, these side meetings typically don’t involve the whole project team, as people start to take sides.
  • Lack of project updates: Understandably, as a project starts to fail, the project leader is unenthusiastic about publishing that fact. Therefore, the regular, weekly project updates are sent out less frequently.

This isn’t a comprehensive list, but it’s a start. While pulling a project leader is never fun, it’s sometimes necessary.

When projects go south

What warning signs have you seen that signal a failing project? What steps did you take to rescue the project? Let us know by posting a comment. Each week, the person who posts the best comment to an Artner’s Law column will win a nifty TechRepublic coffee mug.