Project Rescue Tip #5
Tip #5 in the 10 tips for project rescue deals with fixing
the team. There are variety of reasons that projects fail (hence 10 tips),
including a team that is performing poorly. The various causes of project
failure are not mutually exclusive so the fact that a project is experiencing
problems because of a bad job of capturing requirements does not exclude the
possibility it also suffers from poor team performance. The rescue manager will
need to examine the project thoroughly for evidence of poor performance even if
they have already identified problems in other areas.
A word of caution here: don’t mistake evidence of poor
morale for evidence of poor performance. The place to look for poor performance
is the project schedule. Project management tools allow the project manager to
assign resources, effort estimates, forecast start and completion dates to
tasks in the WBS and this should be your first source of evidence of poor
performance. Start by looking for tasks whose forecast completion date has
slipped significantly, or has been re-forecast several times. Failure to
complete the task with the amount of effort estimated is not the only reason
for slipped completion dates of course. They may be slipped because of a bad
estimate, or excessive time spent on activities other than the project task.
There are several ways of determining the cause of the slippage. The effort
expended on the task can be checked against the organization’s time tracking
system, if such a system exists. Check on the time the resource has identified
with the task. If that agrees with the effort duration captured in the schedule
you’ve either got a performance problem or a bad estimate.
One way of distinguishing between poor performance and bad
estimates is to compare performance by team members that are assigned similar
tasks. If only one or two have problems meeting their deadlines, there is a
performance problem. If everyone performing similar tasks fails to meet their
deadlines the problem is with the estimates not the team. Poor estimates will
have to be corrected by applying the lessons learned from the work completed to
date to the work in the future to draft a more realistic schedule.
There are three main causes of poor performance:
- The team member was distracted by activities outside
the project. This is especially common where the team member only works on the
project part time.
- The team member lacks the skills and experience
required to perform the work with the proficiency called for by the project.
- The team member is deliberately sabotaging the
Investigation to determine which of the 3 causes you are
faced with will have to be conducted with the team member by interviewing them.
If the first cause is offered by the resource it should be checked against the
organization’s time tracking tool first to verify time is being charged to the
project honestly. If not, you’ve got two problems: charging time against your
project dishonestly and the source of the distraction. If the source is with a
project stakeholder you can tackle the issue yourself or ask the sponsor for
help. In either case you must identify the problem to the sponsor and other
stakeholders. If the source is outside the project, ask the sponsor for help.
Dishonesty in charging time to your project worked on other activities is an HR
issue and should be tackled in accordance with the organization’s HR policies
and with the HR departments help.
A lack of necessary skills can usually be addressed by
training. The training will have to be identified and added to the Human
Resources Management plan. This plan may not be separate from the project
schedule (e.g. training may only be identified in the MS Project plan) in which
case the training should be added to that document. The training will also
change the project’s budget.
Experience is a more difficult deficiency to make up. The
only way a lack of experience can be made up is by replacing the inexperienced
resource with a more experienced one. If that’s not feasible or desirable the
inexperienced resource can be paired with a coach or mentor to speed the
maturation process. Keep in mind that the resource must be willing to accept
the coaching and a willing coach must be found. Coaching will also detract from
the coach’s productivity on their own work and this reduction in productivity
must be accounted for in the schedule. The remedy chosen to address a lack of
experience will depend on the magnitude of the problem. Is the sponsor willing
to allow the extra schedule time to allow for the lack of experience? Is the
payback in resource development worth the cost?
There is one exception to the above and that is when a
contract resource has misrepresented their skills, training or experience.
Service contracts are made for skill sets and experience. If a contractor was
hired based on a misrepresentation of these they are in breach of contract and
the project manager has every right to terminate their contract and replace
The worst case scenario lies behind door number 3: a
resource that is sabotaging the project. The sabotage may be overt or covert
but is the only explanation for poor performance when estimates have been
verified and the resource has the skills and experience necessary to meet the
original deadlines. An interview with this resource should either verify or
discount this explanation. Resources that would be happy to see the project
fail will usually have some reason for this attitude such as dissatisfaction
with their project role or a dispute with another team member. The poor
performer may be seeking to prove that the estimator was out to lunch or that
an approach to the work that they proposed but was turned down in favour of an
alternative was the right one. This information will come out in an interview
if open ended questions are asked. Don’t be drawn into a debate with the team
member; listen to what’s said and observe the behaviour. If you suspect they
are trying to mislead you look at their body language for clues. Turning away
from you or avoiding eye contact are some indications of dishonesty.
Once you’ve verified that the poor performance is
deliberate, your remedies will be constrained by HR policies. The ideal
solution is to remove the saboteur from the team but this may not always be
possible. If it isn’t you should work with the sponsor and HR to determine an
approach that would correct the problem. If your sponsor wants you to attempt
to correct the situation explain the risk to project should correction attempts
fail. You also need to account for the time and effort that a correction would
take providing that correction is not possible on the spot. Again, contractors
are an exception to this approach. A contractor that is sabotaging the project
should be shown the door.
So far I’ve only discussed the WBS, schedule, and time
tracking system as sources of information for evidence of poor performance but
they aren’t the only sources for this information. The project’s Lessons
Learned, Issue Log, Action Register, Decision Log, Risk Register, and RAID Log
are also likely sources of information. Issue Logs or Action Registers that
show a team member consistently missing completion dates is a possible
indication of a performance problem. If this evidence is corroborated with the
evidence already discussed you have a performance problem. Action items that
have multiple forecast completion dates assigned are another symptom.
Risks can sometimes be a self-fulfilling prophesy. Someone
who has identified a risk to the project may feel motivated to see the risk
event occur. Check the register for risk events that have occurred that relate
to or appear to have caused the schedule slippage. The risk event may be
attributed to other causes in the register but if the risk event coincides with
other evidence of poor performance then poor performance is likely to be at
least part of the cause. Controversial decisions are another indicator of
conflict that can lead to poor performance. Evidence of the controversy may be
captured in the log as dissent or may be captured in the Issue Log. The
disagreement may lead to overt or covert sabotage of the results of the
Lessons Learned are another great source of evidence of poor
team performance. Don’t expect the evidence of poor performance to be explicit.
Look for things that went wrong that don’t seem to have a good explanation or
remedy. Multiple lessons that involve one team member’s work may be a sign that
the cause is a performance issue with that team member. Completed Lessons
Learned sessions should have a "what should be done differently” component that
can provide some clues that would indicate poor performance. If you’re
undertaking the Lessons Learned sessions yourself and you’re using a
brainstorming session look for defensive behaviour when there has been no
explicit criticism. Also look for team members who express their opinion in a
circuitous manner; they may be attempting to communicate something they are
reluctant to articulate in the group. These are signs that you may be dealing
with performance issues.
Regardless of how you discover the performance issue,
dealing with it before you complete the re-formulation of the project plans is
essential. Avoiding a confrontation will only validate the behaviour and it is
likely to get worse. A lack of training will cause more slippage the further
into the work you get and the saboteur will treat avoidance as a validation of
their behaviour. The only exception to this is lack of experience. An otherwise
good worker handicapped by a lack of experience will improve as they gain the
experience. People who perform well under pressure are likely to respond to the
pressure of a project rescue with their best performance.
A fringe benefit of addressing performance issues as part of
the project rescue is the effect this has on team morale. The team, or at least
everyone on the team that isn’t out to sabotage the project, will be
demoralized by the failure of the project to meet expectations. This will be
doubly so for those team members who have worked their socks off only to see
their hard work devalued by another member’s poor performance. The other side
of this coin is the disastrous effect a failure to address poor performance
will have on the team. Those members who have contributed their best efforts to
date may be demotivated to the point that they no longer want to contribute at
that level. Mature professionals very seldom display "passive/aggressive”
behaviour; they are much more likely to look for a way out of the project. Once
this dissatisfaction reaches critical mass, your sponsor will soon figure out
that it’s less costly to dump you than to dump all the "stars” on the team.