I meet a lot of software project managers. One of the things I see a lot of is people building schedules with tasks that have more than one person assigned to them. You know, like "Write documentation, 10 days, Billy & Suzy".
This is an example of a tool giving a user just enough rope to hang themselves. Most people wouldn't look at that and think twice about it. But let me ask you the following questions:
- Who's on the hook if the task isn't done when it is supposed to be?
- Who's the decision maker for the task if choices need to be made?
- Who's responsible for the time estimate of the task?
If your answer to any of those questions are "both Billy and Suzy", you've got an accountability problem. The trouble with thinking that 2 people can both be accountable for a single unit of work is that it only works in concept. In reality, what people do is take a single "conceptual" task, and break it up into sub-tasks so that they can each do some. Unless they are both using the same pencil, the same sheet of paper, or the same keyboard and sitting in the same chair, then that one conceptual task should be further broken down into sub-tasks until you get one person assigned to one thing at a time.
As long as there are two names beside a particular task, each person has an increase of 100% in the number of people they can blame for things going nutty.
As long as there is more than one name beside the task, each person inherits the excuse that "I thought someone else was taking care of that."
Often times, people confuse "who's responsible" with "who's doing the work". It may in fact be that the odd task does take literally several people to accomplish (and those are rare), but even so, you're much better off choosing one of those people to be on the hook. One person to represent the others. This one person is responsible for the time estimate for the task. This person is on the hook for delivery of the task. This person can make decisions regarding the task if something comes up during it. Without a single point of responsibility, authority and contact for a single task, real accountability dwindles and risk increases with every name added to the list.
If what you're trying to do is simply show that 5 people are booked during a particular task and are unavailable for other work, consider assigning a separate task to each of the 5. There are very few "work items" in software that get produced by more than one person, if you really break it down. The only think I can think of that truly takes more than one person in a software project, is a conversation, or a meeting. Hardly worth cramming into the schedule unless it lasts at least a half day or more.

Comments