When do You Replace a Project Leader?
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.
|
|
[Home] [About
Us] [Services] [Events] [Register] [search] [Contact
us] [Members] [Web
board] |