Page 242 -

You Are Accountable for the Project’s Success
A person is accountable for a task if failure to adequately perform that task carries profes-
sional consequences. These professional consequences can take one or more of four possi-
ble 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.

Grant Authority and Accountability to Team Members
When you are responsible for a software project, you are accountable for its success. How-
ever, you are not the only person accountable—you 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 engi-
neers 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,

234 CHAPTER TEN