Home arrow Blogs arrow Plan and Deliver arrow On Task Ownership
On Task Ownership PDF Print E-mail
Written by Peter Schuh   
Thursday, 18 January 2007

The teams that I work with have two very important rules around task ownership. First, regardless of the number of people doing work on a task, each task should only have one person's name on it. Second, regardless of who is actually doing the work, the task should always belong to an active member of the team.

 

Only One Owner Per Task
 
Tasks that belong to more than one person lend themselves to confusion. Each owner thinks the other is on top of it, so the task goes nowhere. Or, one owner says the task is done but the other says it's not done. Or, the occasional team freeloader wants his name on every task he is remotely associated with, so it looks like he's doing a lot when he in fact has done very little.
 
One owner per task ensures accountability. Even when another team member is responsible for some of the work on the task, the owner has a vested interest in seeing that the work is done or escalating the issue if the work is not done. There is no one else to whom the buck may be passed.
 
Yes, some effort put in by other team members may not be accounted for and may fall through the cracks. That's fine. Our primary concern as a team is timely delivery of product, not exact time-keeping.
 
Only Team Members Own Tasks
 
I often see project plans that include task owners who are not on the team that owns the project.  I wonder whether these people know (and even when they know do they really care?) that they have been made responsible for completing work on another team's plan? The answer in almost all cases, I'd argue, is no. These people have their own teams and their own plans. They have enough to do before worrying about the responsibilities that other teams are trying to throw on them.

It all comes back to accountability. People who are not team members are not accountable to the team. Naturally, they will complete work for their own team first, often unintentionally leaving tasks on other teams' plans to languish. Tasks slip by undone. External dependencies stack up. Bad things happen.

The key to dealing with work that needs to be completed by non-team members is to assign responsibility for the work to the team member who most depends upon it. So, instead of assigning a task to someone who is not on the team and does not see the plan, you assign a task to someone who is not only accountable to the team but also has a vested interest in seeing that the work is done. It is then the team member's responsibility to coordinate with external resources, keep them appraised of the team's needs and timelines, and either confirm that the work is completed by the external resources or escalate through team management when it is not.


Typically, the estimate for this sort of "tracking" task is relatively small. We only care about the effort expended by our own team members, not individuals on other teams. Those other teams should have their own mechanisms for tracking what they work on and they almost certainly don't care whether we are actually accounting for their effort--as long as we are coordinating with them and getting their buy-in to complete the work we need them to do for us.

Comments (2)add feed
PeterSchuh: ...
Thanks for reinforcing my point!
1

July 24, 2007
anonomous: ...
I disagree with trying to get external team members to work on tasks that they don't care about and possibly didn't even sign on to work on. If teams have a dependency on a separate team and their members then SLA need to be put in place and ownership and accountability needs to be established. Otherwise the external group can have no knowledge of tasks you wish them to do and may never be required to do it if their management chain never agree to it. Then your team is left holding all of the work.
2

July 02, 2007
Write comment


Write the displayed characters


busy
Tags:
Click to add your tags...,
 
< Prev   Next >

Video News

Agile Poll

Select all that Apply
How are you building an Agile organization?
 
 
 
 
 
 
 
ThoughtWorks Mingle 2.0
 

Coming Up - Editorial Calendar

  • August 13 - Quality Agile Development
  • September 10 - Agile News
  • October 08 - Valuable Agile Practices
  • November 12 - Introducing Agile to the Organization
  • December 10 - The State of the Agile Community
See the full 2008 Editorial Calendar >
Copyright © 2006 CMC Media, Inc. All rights reserved. All marks are trademarks of CMC Media Reproduction in whole or in part in any form or medium without the express written permission of CMC Media, Inc. is prohibited  
 
 CM Yellow Pages | ALM Expo | CM Today | Configuration Management Journal | CM Crossroads