One Deliverable, One Person

Every deliverable should have a single person who is responsible for its completion. Everyone working on the project should clearly understand who is responsible for the delivery of each item. Actual development of the item may involve a large group of people, but ultimate responsibility for ensuring it's on time completion, and for understanding the technical issues surrounding that item, should be associated with one person.

Too often, especially in highly politicized environments, responsibilities are shared, especially when things are a little fuzzy at the beginning of a project. People like to be responsible for highly visible items that they know are going to be successful. No one wants to be held responsible for something they know is going to be a failure. In the beginning of a project, sometimes responsibilities are shared because a deliverable, and its associated risks, are not fully understood. No one really wants to step up and assume responsibility for a vague task.

Sometimes, a deliverable is so juicy that you end up with multiple people who want to assume responsibility for it yet, not wanting to rock the boat, management doesn't assign specific responsibility to one person for fear that others will get upset. Either way, you are setting the stage for much larger problems down the road.

If there is a problem associated with a deliverable, one individual who is ultimately responsible for it is much more apt to notify the team early, since they know they will be held accountable. When time is tight, people have a tendency to assume that anything which they are not held personally accountable will be handled by someone else. That is how things fall through the cracks. As software project manager, you end up with a crisis on your hands.

Second, as the project moves on, it is simply much more efficient for all team members, especially newcomers, to know exactly who to speak to regarding any issue. If you have a question, you want to make sure you are asking the right person, the expert associated with the topic at hand. And, if the expert doesn't know the answer, they will get it for you. You shouldn't have to spend your time chasing down an answer for something you don't fully understand in the first place.

Finally, sometimes (alright, often), projects don't turn out as expected. If people aren't held accountable for their actions (or inactions), you'll never be able to fix the problems that occur and group dynamics will suffer. Few issues are more disruptive to team performance than the group wasting time trying to decide who to blame for failure with a "group" assignment.

You don't want to turn this into a contentious means of assigning blame, but rather a means of properly distributing responsibility. And, when a deliverable comes in early and under budget (or at least on time and within budget), it's good to know who deserves the praise.