Project Management

“Problem” Team Members

One of my office neighbors asked me about how I handle “problem” team members. His examples were:

  • the team member who doesn’t provide good estimates
  • the team member who doesn’t stop talking in meetings

In each case, and I argue, in most cases, there are no problem team members. I firmly believe that most people want to do their job well. However, people are often misunderstood, or they don’t understand what they’ve been asked to do.

As project managers, we must ensure that we don’t jump to conclusions. Just because we have a clear picture of what needs to be done, that doesn’t mean that anyone else shares that understanding. We must use the tools of project management, especially the Work Breakdown Structure, the Schedule, and the Risks List, to build that shared understanding.

Here’s my take on the answer to my friend’s specific questions. First, the person who has trouble estimating has a lot of company. Few people estimate well when they start out. That’s why I’m such an advocate for time tracking. Until a person builds up a history of how it long it takes to do certain tasks, it’s very hard to develop accurate estimates. I use Liquid Planner every day, and I take advantage of its timing feature to keep track of how well my effort estimates match my actuals. Second, when dealing with someone (like myself) who talks a lot in meetings, it’s important that the meeting facilitator explicitly asks the quieter members of the team to speak. There are kind and gentle ways of telling the extrovert that you’re grateful for her comments, but that you’d like to hear from others as well.

Project Management

Project Risk and Task Estimation

It’s common knowledge that I love Liquid Planner. In my opinion, it allows me to to do magic and foresee the future.

::geek mode on::

Liquid Planner allows you to use probabalistic modeling for any or every task in your schedule. This means that instead of saying that a task will take 5 days, you use statistical language to describe the likely range of days. Once this has been done for a number of tasks, then the model of the entire schedule can be described using probability.

::geek mode off::

This concept is fundamental to successful project management. Because of the uncertainty inherant in projects, it is insane to try to predict exact task durations. We might as well pretend to be psychics wearing gypsy headscarves. However, we can hone our estimation skills to the point where we can make educated predictions.

Liquid Planner is cool because it removes much of the emotion from the calculation of date ranges. However, it is important to note that the assignment of the probability distribution to each task is still a human activity. There’s no magic formula or supercomputer that can tell you exactly how likely a given outcome will be. And thus, garbage in/garbage out.

The take-home lesson is that when you’re planning a project, don’t get trapped into giving your management an exact date when the project will be complete. Provide a range of dates that accurately describes the amount of uncertainty. If it’s early in the project and much is still unknown, say “second half of the year” or “third quarter.” As you refine the project plan and remove some of the uncertainty, you can provide finer granularity by stating the month when you expect to complete the project. The only time you can be certain of your completion date is the day you’re done.

Much more information is available in Steve McConnell’s Rapid Development and Software Estimation: Demystifying the Black Art.