Continuing on with my theme about managing
software developers, and getting
ahead in your career as a software developer, this post discusses poor performing developers and what steps can be taken to protect the project.

It is a sad fact that the software IT industry is awash with many individuals
that claim to be expert developers in the field in which they practice, but in fact,
they lack the skills required for the simplest of software development
positions.  Often is the case that these individuals will appear to have
the necessary skills on paper to secure them a job on a development project and
the only thing to stand in their way is a good interview screening process. Therefore,
what can be done to avoid jeopardizing a project if, as a project manager, you
find yourself with a bad apple on the team?

• Recognizing a bad apple – Most managers can spot a duff developer on the team, however
  poor performing individuals can often go unnoticed on software development projects,
  especially large enterprise projects involving more than a handful of
  developers.  It is the responsibility of a good project manager to have an
  accurate understanding of every team members past and present performance
  metrics.  The typical approach taken by many project managers
  is to maintain a project plan containing project tasks assigned to
  each developer, along with original estimates and current percentage of work
  complete. Project planning tools, such as Microsoft Project, can provide project
  managers with an indication of where the bottlenecks exist in a project and
  which developers are failing to meet the quota. A good project manager should always maintain a history of all
  staff
  under his/her supervision, both for future performance reviews and for
  a
  comparison of previous accomplishments with the present.  Regular
  design and code reviews and peer-to-peer staff meetings can also
  indicate a problem brewing.

• Cauterize the wound –

  Once established that a developer is lacking performance on
  the team it is important to isolate them from any tasks deemed critical to the
  success of the project. The developer will work on less important tasks until
  the proof of increased performance and understanding of the more crucial tasks
  is evident. It is important not to chastise
  the developer for their poor performance at this stage. However, the developer should
  be aware of their failure to meet the project expectations.

• Establish a cause – There are many reasons why a team member may
  fail to meet required project expectations. Failure to complete one or many tasks in a
  designated time period is not necessary an indication that the individual is
  incompetent in their role. Other factors, such as lack of training for the task
  in hand, lack of motivation, failure to apply talent in the correct area, bad planning,
  or a long number of hours etc, can influence the ability in completing a task.
  External factors such as a stressful home life, lack of sleep, a difficult
  commute etc, are other reasons.The
  project manager should invite the developer to share an explanation of inability
  to complete tasks assigned before concluding lack of professionalism.

• Provide an opportunity to make amends
  – Once all external factors have been ruled out or addressed, the developer can show promise and future worth to the
  project when provided with an opportunity to gain the confidence of the
  project manager.  A good way to provide this opportunity is to
  assign an obtainable task, which both matches the skill set of the
  developer and occupies a short time period.  It is the duty of the
  project manager to monitor the task progress to determine if the
  developer is showing progress.  The project manager must define
  the expectations up front and the developer should be clear on what
  objectives they must meet to complete the task.  This
  “hand-holding” technique requires extra time from an otherwise busy
  project manager, but secures the project manager with an understanding
  of the ability of the developer before any drastic action is required.

• Cut your losses
  – If the developer continues to show little or no promise of becoming
  an asset to the project and continues to be a liability, the time has
  come to cut them loose.  It is a sad day when a project manager
  has to fire a member of his/her development staff, but necessary for
  the good of the project.  Stale developers that do not provide
  useful input to the project can drag a project and impede the efforts
  of other useful developers on the team.  Never terminate developer
  (or any other team member) for personal reasons.  Plenty of
  guidelines exist for terminating an employee.  In a future post, I
  list some of the ways to fire a member of staff, whilst retaining
  professionalism and avoiding uncomfortable conflict.