By Louis Rosas-Guyon
In any organization there are jobs that need to get done. These jobs are usually defined by the table of organization. The sales department handles prospecting, customer service deals with irate customers and so on. However, there are the inevitable situations where jobs are orphaned. These tasks must be handled by someone somewhere but they become a corporate hot potato. And in not time flat, these jobs become the source of frustration and fighting between departments as everyone battles desperately to ensure that they do not get blamed for dropping the ball.
I see this most often during the deployment of new technology systems. No one wants the aggravation or the extra work involved in taking ownership of a new project. Usually this happens because senior management makes a decision to implement something new without assigning responsibility for oversight. So, there I am looking for someone that can answer questions or make decisions that could affect the entire corporation. How am I supposed to know if you prefer FIFO or LIFO?
This is why it is important for companies to always assign someone that is responsible for a project. Incidentally, they must also have the corresponding authority to make decisions for the company! There is nothing that will guarantee frustration and failure faster than forcing someone to shoulder a responsibility without also granting them the authority to see it through. Responsibility without power just slows everyone down because every time a decision must be made, the responsible party runs to find someone else to make the choice.
This is why many IT projects fail. Just like the famous quote says, "victory has a hundred fathers, but defeat is an orphan." It seems that many projects are doomed to failure from the beginning because everyone in a position to make a difference is too busy running from potential failure. When stated in those terms it seems ridiculous, but I have seen it in more situations than I care to remember. I have seen Vice Presidents that rule their departments like feudal lords run for cover when a new project is announced. They hedge and try to work every angle to push the project onto someone else. They claim they are too busy, too poorly funded or too under-staffed. Strangely, these are usually the same executives that will make my life complicated with ridiculous requests and demands. These executives are not taking ownership of the project and are part of the problem.
But what do I mean when I say someone has to take ownership of the project? Always remember that power can not be given or transferred. Power must be seized. If the person given the responsibility and authority never takes ownership of the project, they will never be anything more than a caretaker. They will be afraid to make decisions and will run to their supervisor for answers in a perpetual CYA game. Unless someone takes ownership of the project, the likelihood of success declines drastically.
SOME IMPORTANT GUIDELINES FOR TASK OWNERSHIP
The teams 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
We 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.
In any organization there are jobs that need to get done. These jobs are usually defined by the table of organization. The sales department handles prospecting, customer service deals with irate customers and so on. However, there are the inevitable situations where jobs are orphaned. These tasks must be handled by someone somewhere but they become a corporate hot potato. And in not time flat, these jobs become the source of frustration and fighting between departments as everyone battles desperately to ensure that they do not get blamed for dropping the ball.
I see this most often during the deployment of new technology systems. No one wants the aggravation or the extra work involved in taking ownership of a new project. Usually this happens because senior management makes a decision to implement something new without assigning responsibility for oversight. So, there I am looking for someone that can answer questions or make decisions that could affect the entire corporation. How am I supposed to know if you prefer FIFO or LIFO?
This is why it is important for companies to always assign someone that is responsible for a project. Incidentally, they must also have the corresponding authority to make decisions for the company! There is nothing that will guarantee frustration and failure faster than forcing someone to shoulder a responsibility without also granting them the authority to see it through. Responsibility without power just slows everyone down because every time a decision must be made, the responsible party runs to find someone else to make the choice.
This is why many IT projects fail. Just like the famous quote says, "victory has a hundred fathers, but defeat is an orphan." It seems that many projects are doomed to failure from the beginning because everyone in a position to make a difference is too busy running from potential failure. When stated in those terms it seems ridiculous, but I have seen it in more situations than I care to remember. I have seen Vice Presidents that rule their departments like feudal lords run for cover when a new project is announced. They hedge and try to work every angle to push the project onto someone else. They claim they are too busy, too poorly funded or too under-staffed. Strangely, these are usually the same executives that will make my life complicated with ridiculous requests and demands. These executives are not taking ownership of the project and are part of the problem.
But what do I mean when I say someone has to take ownership of the project? Always remember that power can not be given or transferred. Power must be seized. If the person given the responsibility and authority never takes ownership of the project, they will never be anything more than a caretaker. They will be afraid to make decisions and will run to their supervisor for answers in a perpetual CYA game. Unless someone takes ownership of the project, the likelihood of success declines drastically.
SOME IMPORTANT GUIDELINES FOR TASK OWNERSHIP
The teams 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
We 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.
No comments:
Post a Comment