Losing team members

Every project has its own unique risks.  Some of them involve cost overruns, others may focus on lack of participation or turnout and many risks revolve around getting tasks completed on time.  Recently, however, I was reminded that the biggest risk that could affect any given project could be the loss of core team members.  During a recent trip to Germany, I learned that many of the issues my firm encountered with a major project over the past few months were due to severe illnesses.  This year two team members have been out with illnesses for multiple months, one of them for most of the year.  The team in Germany has been coping as best they can, but due to the nature of the illnesses, they were never sure if the two coworkers would come back one week to the next.

One of the many questions this points out, is how in the world can a project manager actually plan for the risk of someone being gravely ill?  Or to take a less somber approach – how would a project manager handle a key team member quitting halfway through a project?  For some teams and organizations, the answer might be easier than for others.  For example, perhaps there’s a suitable backup or fill-in available, which may very well be the case in large organizations.  But of course that person has other responsibilities or projects too.  Another option may be to hire a replacement, which sounds like a good solution if the project still has some time until completion, but in reality, we have all seen how long the hiring process can take (not to mention training).  Other options could include having different team members pick up part of the slack.  As long as the skillset isn’t proprietary within the organization to that single individual, this may be the best short term option.  But if the skills are not seen within other team members, then the project manager is forced to look at outsourcing or hiring contractors to fill in.

Both of the latter choices were pursued by my company in our example, with other team members filling in for the business process side of the project, and contractors hired on for pure coding / development work.  Thankfully the other team member’s had some amount of knowledge in the missing area, and my company had already worked with outside contractors on an ongoing basis.  Neither of the options were ideal, but the team has struggled along as best they can.

So although it’s impossible to anticipate these types of risks, the loss of key team member for any reason should be considered when assessing a project and managing risks, especially for longer term projects.  Even if an ideal solution isn’t available, the next best alternate for each key player should be known at project start.

How have you dealt with losing team members in the past?  How would you deal with something as difficult as an unknown illness affecting your team?

Project plans for the rest of us

There are very few people I have encountered in my career that have seen project planning as a truly joyful exercise.  Some professional consultants live and breathe projects, and therefore the prospect of a well executed project plan may elicit anticipation of success, or a sense of accomplishment in a plan in a well designed plan.  And there are others that can simply crank plans out in their sleep; having done so many throughout the course of their careers that it becomes second nature.  And perhaps a select few project management professionals eagerly anticipate putting together that next glorious plan, the next chance to show off their skills.

But for the rest of us, project planning is often a necessary evil.  So evil in fact, that I have seen many projects within my own corporation fail or miss project targets because the project champion decided to do as little as humanly possible in planning.  These pseudo-plans contain the bare minimum tasks, responsibilities and due dates, without much else.  And this comes out of successful managers and contributors, even star employees.  Because project planning is only done as a perfunctory step, rather than actually managing the plan.

From what I’ve seen, this is most often due to managers not realizing that an in-between project plan is possible.  That it doesn’t have to be either a list of tasks or a monumental MS Project disaster.  That is the reason most often given when the managers I’ve worked with (and myself included) discuss why a better plan was not created.  “The plan will take longer than the project” or “I don’t know how to use MS Project” or “No one follows those things anyway” are all common excuses given.

So instead of pushing my colleagues towards a full blown project plan, I believe there are a few key additions that could take the basic task list to a true project plan:

1. Add links between tasks & precedents-

Many projects have been postponed or delayed only because the sequence of events was not well defined.

2. Include actual effort estimates in the task, not just calendar days to complete-

Many people don’t actually add up the hours needed to complete a task – they just pick a random calendar day

3. Make more detailed tasks-

Broad tasks that people don’t even remember what they mean two weeks later don’t help anyone


These simple additions can go a long way towards taking a task list and making it a reasonable plan.