Section 10.1. Take Responsibility


10.1. Take Responsibility

The world is full of frustrated project managers. Frustrations come in many forms. Some project managers are assigned projects, but have to fight for the people to do those projects. Others have inadequate office space, computers, or networks. Many project managers are constantly clashing with other managers because of "dashed-line" organization structures where their teams do not report directly to them. Some find that their project team members are routinely pulled off of their projects without warning, or that their projects are reprioritized and thrown into disarray.

There is a common root cause of most, or all, of these problems. The cause is that the project manager is told that she has responsibility for her projects, but, though she is held accountable for their success, she is not given sufficient authority to do her job.

Managers routinely throw around the word "responsibility," often in the context of a subordinate "not taking responsibility" for a task. To many of them, "take responsibility for this task" is synonymous with "go away and don't bother me until the task is complete." This is an unfortunate attitude, and it is a root cause of failed projects and depleted morale in organizations around the world. A good project manager must have a more sophisticated understanding of responsibility in order to avoid these problems.

A person has responsibility for a task only if he is given sufficient authority to perform the task and is held accountable for the results. When you assign a task to your project team, you must ensure that each team member has sufficient authority to perform the task, as well as an understanding of his or her accountability. For the project to be most effective, the team members should understand these concepts as well.

10.1.1. Ensure That You Have Authority to Do the Project

A person has authority to perform a task only if he is has adequate control over the resources necessary to complete the task. Giving a project manager authority to carry out a project means giving him control over the resources (people, office space, hardware, software, etc.) required to complete it. Since resources cost money, sufficient budget for the project must be allocated within the organization.

This does not mean that the project manager must have direct control over these resources. For example, the team members do not necessarily need to report to him. However, if they do not report to him, he must have the full cooperation of the direct manager of each resource assigned to the project, so that he can assign tasks to the team members directly without having to obtain permission for each task. If there is a single person on the project whose involvement is not guaranteed from the outset, the project manager cannot say with certainty that he has all of the resources that he needs to complete the project. In this case, he does not have sufficient authority to do his job.

In the same way, the project manager does not need to have a corporate credit card to buy the necessary hardware or software. But he does need to have a guarantee from the person who has the budgetary authority that he will be allowed to obtain these resources. Without this guarantee, his authority will still be incomplete.

10.1.2. You Are Accountable for the Project's Success

A person is accountable for a task if failure to adequately perform that task carries professional consequences. These professional consequences can take one or more of four possible forms:

  • His reputation is damaged among his peers and in the organization.

  • His manager gives him a poor performance review.

  • His compensation is reduced.

  • His responsibilities are changed (or taken away altogether, if he is fired).

When someone is held accountable for a task, he must have some understanding of the professional consequences if he fails. If there are no consequences, or those consequences are not particularly damaging, then there is little incentive to complete the task.

That does not mean that someone who does not have incentive to complete a task will do a poor job. She may still perform it well, usually out of a sense of duty, loyalty, or personal responsibility. But if failure does not carry consequences, she is not really accountable. She is doing the task as a favor, and any success is coincidental.

10.1.3. Grant Authority and Accountability to Team Members

When you are responsible for a software project, you are accountable for its success. However, you are not the only person accountableyou must distribute that accountability fairly among the project team. The way to do that is to make sure each team member is responsible for her task by ensuring that she has sufficient authority to carry it out and understands how she will be held accountable for its completion.

The best way to ensure that each team member has sufficient authority is to discuss it directly at team meetings. When you discuss the status of a project, verify that each person has everything necessary to perform her assigned tasks.

The most common way that authority is removed is when a team member is pulled off of the task. If you have been given a person's time for your project, you must be able to depend on that to last for the course of the project. Many people will not tell you that they have additional demands on their time unless you ask them directly.

Never assign a task to a person who does not have the authority to perform it. All engineers must have control over their time. Requirements analysts must be allowed to call meetings with stakeholders. User interface designers must be allowed to make UI design decisions without having to clear them with a string of senior managers. Programmers must be allowed to use the tools and techniques that they need. Testers must be allowed to request requirements specifications, technical specifications, and preliminary builds, and must feel free to report defects without being blamed.

If the project is late or runs into problems, you must give every project team member your guarantee that you will work hard to identify the root cause of the problem. For example, many delays that are introduced due to poor planning or scope creep are not recognized until late in the project, during the testing activities. The testers may have done their jobs and met all of their estimates, but, since they are in charge of the active task at the time that the project delay is discovered, they are held accountable for problems that they had no authority to prevent. It is your job to prevent this from happening by holding the people responsible for the delay accountable. You must share in the consequences because you failed to recognize the problem until too late. And you must take steps to prevent it in future projects, by implementing additional tools and techniques.

10.1.4. Defend Your Project Against Challenges to Your Authority

If resources are pulled off of your project, your authority is being challenged. You only have authority to do a task if you can command the resources necessary to complete it, and, when people are pulled off of your project, those resources are no longer available to you. However, the accountability is still in place. If you want to avoid being held accountable for the project's failure, you must recognize the challenge to your authority and defend your project against it. This is difficult, and often requires patience and negotiation.

For example, it is very common for programmers to be interrupted "for just an hour or two." If a senior manager or executive needs help with something smallsay, he's having trouble using a program that he knows the programmer wrote a few months agohe will often approach the programmer directly, without your knowledge. This puts the programmer in a difficult position, because she does not feel like she can tell this senior person that she is too busy to help. She will want to be helpful, and may simply take on the extra work without mentioning it to you.

If something like this happens, it is your job to address the situation. Though it seems innocuous, this is an indirect (though probably unintended) challenge to your authority, because a resource has been pulled off of your project. It is also a challenge to the programmer's authority, because she no longer has enough time to do her task. This is a difficult situation to fix. You might approach the senior manager directly and explain that this will cause a delay in the project, and that both you and your programmer will be held accountable for her delay. If the senior manager balks, you might ask him to share the accountability by writing an email to the project's stakeholders explaining why the project will be delayed, so that you won't get blamed.

You may have to be creative in how you solve this problem, because this can be a politically charged situation. Approach it with a cool head. Do not accuse people of trying to interfere with your project. Remember that the person you are talking to is just trying to do his job, and he probably did not realize that he was putting your project at risk. Try to talk about how this affects you and your project team, and be very specific about the consequences. Give examples of how a delay in the programmer's task will ripple down the project and cause additional delays. Most importantly, make sure that you have your facts straight before you meet with the other manager, and make sure that your own manager knows everything you are about to say, and approves.

If your manager does not back you up in defending your authority, your hands are tied. You will either have to renegotiate the schedule or accept the consequences. This is hard for many people to deal with. The best way to prepare is to make sure that you have plenty of documentation, so that when you are called upon to explain the delay, you can show what caused it and, if necessary, that your manager knew about it and did not let you fix the situation.



Applied Software Project Management
Applied Software Project Management
ISBN: 0596009488
EAN: 2147483647
Year: 2003
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net