Distinguishing authority, responsibility, and accountability

The following concepts can help you define and clarify how team members should relate to each other and to their assigned tasks:

• Authority: The ability to make binding decisions about your project’s deliverables, schedule, resources, and activities. Examples include your ability to sign purchase orders that don’t exceed $3,000 and your ability to change a scheduled date by no more than two weeks.
• Responsibility: The commitment to achieve specific results. An example is your promise to have a draft report ready by March 1.

• Accountability: Bringing consequences to bear in response to people’s performance, such as your manager noting in your annual performance appraisal that you solved a tough manufacturing problem.

  Unfortunately, many people think accountability means only paying the price when you foul up. This fear of having to be accountable for mistakes often leads people to shy away from accountability. Paying a price when you foul up is certainly half of the concept, but the other (better!) half is being rewarded for doing a good job. This positive reinforcement is far more effective than negative reinforcement for encouraging high-quality results.

Although these three terms are related, each term is a distinct and necessary element of defining and reinforcing team roles.

Understanding the difference between authority and responsibility

Both authority and responsibility are upfront agreements. Before you start your project, you agree who can make which decisions and who will ensure particular results. However, authority focuses on processes, while responsibility focuses on outcomes:

• Authority defines the decisions you can make but doesn’t mention the results you have to achieve.
• Responsibility addresses the results you must accomplish but doesn’t mention the decisions you can make to reach those results.

Keep in mind, too, that you can transfer the authority to make decisions to another person, but you can’t transfer the responsibility for the results of those decisions. For more about delegating authority and sharing responsibility, check out the later section “Making Project Assignments.”

Suppose you have the authority to issue purchase orders up to $5,000 for your project. Assume no policy or instructions specifically prevent you from giving some or all of this authority to someone else, so you give Charlotte, one of your team members, authority to sign purchase orders for your project not to exceed $4,000. However, if Charlotte mistakenly issues a $3,000 purchase order for ten units of widget A instead of a $1,500 purchase order for the five units of widget B that she really needs, you’re still responsible for her error.

You can always take back authority that you gave to someone else, but you can’t blame the person for exercising that authority while they have it. Remember that authority focuses on processes, while responsibility focuses on outcomes.

Delving into delegation

Delegating is giving away something you have (we know other definitions of delegating exist, but to keep it simple for our purposes, to delegate is to give away). In the following sections, we help you decide what to delegate and understand different degrees of delegation; we also explain how to support your delegations and achieve the best results possible.

You can delegate authority, but you can only share responsibility. You can completely transfer your decision-making power to someone else so they can make the decisions with no involvement or approval from you. However, when another person agrees to assume a responsibility of yours, you’re still obligated to ensure that they achieve the desired results. See the later section “Sharing responsibility” for more on this.

Sharing responsibility

The decision to delegate authority is unilateral; it doesn’t require the agreement of both parties. You can choose to give someone the authority to make a decision whether or not they want that authority. After you give your authority to another person, they are free to pass it on to someone else (if you haven’t specifically told them not to).

Responsibility is a two-way agreement. You ask me to respond to a customer inquiry, and I agree that I will. Because you and I agree that I’ll handle the inquiry, I can’t decide to give the assignment to someone else and then not worry about whether they’ll handle it. I committed to you that the inquiry would be addressed; the only way I can free myself from this responsibility is to ask you to agree to change our original understanding.

Suppose Elena, your supervisor, asks you to prepare a report of your organization’s latest sales figures. You know where to get the raw sales data, and you figure that you can prepare the text of the report in Microsoft Word and ask Bill, a member of your staff, to prepare any necessary graphics in Microsoft PowerPoint. So you accept Elena’s assignment, and you then ask for and receive Bill’s agreement to prepare the graphics for you.

A week later, Elena asks how you’re doing on the report. You tell her that you’ve completed the text, but Bill hasn’t finished the graphics yet. You suggest that she check with Bill to find out how he’s doing and when he’ll be finished. How do you think Elena will respond to your suggestion?

After a moment’s silence, Elena reminds you that you agreed to prepare the report and, therefore, ensuring all parts of the work are complete is your responsibility, not hers. In other words, because you accepted the responsibility for completing the report, you can’t choose unilaterally to give away part of that responsibility to someone else.

Elena was correct in refusing to deal directly with Bill for other reasons:

• If Elena had agreed to check directly with Bill, she would have tacitly been telling him that whenever you give him assignments in the future, he should be concerned about satisfying her rather than you. In other words, she would have undermined your leadership position.
• Following up with Bill would’ve been difficult for Elena to do, even if she had wanted to, because she didn’t know exactly what you asked him to do or when you asked him to have it done.

The only way you can relieve yourself of some or all of the responsibility you accepted is to ask Elena to agree to a revised plan.

Holding people accountable — even when they don’t report to you

People who make promises, fail to keep them, and then suffer no consequences create some of the worst frustrations in a project (or any!) environment. Observe these guidelines to encourage people to honor commitments to you:

• If you’re responsible, you should be held accountable. In other words, if you make a promise, you should always experience consequences based on how well you keep your promise.

• If you’re not responsible, you shouldn’t be held accountable. When something goes wrong but you weren’t responsible for ensuring that it was handled correctly, you shouldn’t face negative consequences (of course, you shouldn’t receive accolades when it goes well, either).

  Holding people accountable when something they aren’t responsible for goes wrong is called scapegoating. Assigning blame indiscriminately only encourages people to avoid dealing with you in the future. It’s demoralizing and will erode the respect you’ve worked hard to earn, not only from the affected team member, but also from your entire team and stakeholders.

When a person who doesn’t report to you administratively promises to do something for you, holding them accountable can be a touchy issue. You may not try to hold them accountable because you think it’s inappropriate (after all, you’re not their supervisor) or because you don’t know how to do so. But remember: Holding people accountable is appropriate and necessary when they’ve accepted a responsibility. Accountability helps people know that they’re on the right track, and it enables you to acknowledge when they’ve completed the promised assignments. You don’t need authority to hold people accountable; the people just need to have accepted the responsibility.

Use the following approaches to hold people accountable when you don’t have direct authority over them:

• Find out who has direct authority over the person and bring that supervisor into the process. Consider soliciting the approval of the person’s manager when you ask them to accept responsibility for a task. When you do so correctly and at the right time, you can improve the chances for success. If a person’s manager is unaware that their staff member agreed to perform a task for you, your chances of getting the manager’s help when the person fails to perform as promised are small. However, if the manager supported their staff member’s offer to help you when it was made, the manager and their staff member shouldn’t be surprised if you solicit the manager’s help when the staff member doesn’t do the task.
• Put it in writing. Have you ever noticed how strangely people react when you put an informal agreement in writing? All of a sudden, they act as if you don’t trust them. Don’t let this reaction deter you. Put your agreement in writing to formalize it, to clarify the terms, and to serve as a reminder to both you and the person agreeing to do the task. If the person asks whether you want to have a written agreement because you don’t trust that they’ll do what they promise, explain to them that if you didn’t trust them, you wouldn’t work with them in the first place!
• Be specific. The clearer you make your request, the easier it is for the person to estimate the effort they need to respond to the request and to produce the correct result the first time. You may feel that being too specific is inappropriate because you have no direct authority over the other person. But recognize that putting a request in writing doesn’t make it an order; it just clarifies its specifics and makes it easier to perform.
• Follow up. Negotiate a schedule to monitor the person’s performance and to address any issues or questions that arise. Be sure to:
  • Negotiate a follow-up schedule at the outset of the agreement. If you call unannounced at random times, you’ll appear to be checking up and micromanaging, maybe because you don’t trust the person.
  • Base your follow-up schedule on when the person plans to achieve certain intermediate milestones to ensure you have objective criteria for an assessment.
• Make the person accountable to the team. Your most valuable professional asset is your reputation. When a person promises to do something for you, let others on your team know about the promise. When the person lives up to that promise, acknowledge their accomplishment in front of their colleagues. If the person fails to live up to the promise, work with them to develop a plan to course-correct and update the team with this information, including the details of the plan to “right the ship.”
• Get commitment. When a person indicates that they’ll help you out, be sure to get a firm, specific commitment that the desired result will be achieved by a specific time and for a specific cost. Beware of vague declarations like “I’ll give it my best effort” or “You can count on me.”
• Create a sense of urgency and importance. You may want to minimize any pressure the person feels by offering to understand if they can’t perform to your expectations because of one reason or another. Unfortunately, this approach suggests that the work you’re asking them to do isn’t really that important and increases the chance that they won’t complete it. Instead, let the person know how their work influences other activities and people on the project. Let them know why they need to perform to expectations and what the consequences will be — to the project and the organization — if they don’t.

The nearby sidebar “Holding the line when someone else drops the ball” provides an example of holding someone accountable when they aren’t your direct report.

Introducing the elements of a RAM

The RAM is a table that depicts each project audience’s role in the performance of different project activities (see Chapter 4 for more on project stakeholders). A RAM’s format is as follows (see Figure 12-1, which illustrates a portion of a RAM for designing and conducting a customer needs survey):

• Project deliverables are in the left column.
• Project stakeholders are in the top row.
• The role each stakeholder will play in performing the work to produce each deliverable is in the intersections of the rows and columns.

The RAM in Figure 12-1 indicates which of the following three roles people can have in this project’s activities:

• Primary responsibility (P): You’ll ensure the results are achieved.
• Secondary responsibility (S): You’ll ensure some portion of the results is achieved.
• Approval (A): You’re not actually working on the deliverable, but you approve the results produced by others who are.

The RAM is just a format. For each project, you define and assign the roles you feel are appropriate. You may, for example, decide to use the following roles in addition to the three already defined in Figure 12-1:

• Review (R): You review and comment on the results of an activity, but your formal approval isn’t required.
• Output (O): You receive products from the activity.
• Input (I): You provide input for the activity work.

The roles included in a project RAM describe the work different people must do to help accomplish the project activities. To help your team members increase their contributions to the entire team as well as the quality of their own work, base their project assignments on their skills, knowledge, and experience and on the behaviors they tend to exhibit on tasks they perform. Examples of behavioral roles that people play include the following:

• Encourager: One who praises and accepts the ideas of others
• Harmonizer: One who relieves tensions and resolves conflicts
• Gatekeeper: One who encourages other team members to participate
• Follower: One who follows the lead of others
• Group observer: One who gives feedback while maintaining their distance

Reading a RAM

To illustrate how you read the RAM, consider the deliverable questionnaire design listed in Figure 12-1. The chart suggests that three people work together on this activity as follows:

• The project team member has primary responsibility for the questionnaire’s content, format, and layout. On this project, the project team member reports to the task leader, who, in turn, reports to the project manager.
• The task leader performs selected parts of the questionnaire design under the general coordination of the project team member. Also, the task leader must approve all aspects of the questionnaire design before work can proceed to the next step.
• The project manager must approve the entire questionnaire, even though they aren’t doing any of the actual design or layout.

Unless otherwise stated, the top row of a RAM doesn’t indicate any hierarchical reporting relationships between or among the stakeholders listed. A convenient way to depict such relationships is by showing them in an organization chart; see Figure 12-2 for an example.

The organization chart in Figure 12-2 shows the hierarchical reporting relationships for the New Product Needs Assessment project team, which includes the project manager, the task leader, and team members A and B. The chart indicates that the task leader reports to the project manager, and team members A and B report to the task leader. The work breakdown structure (WBS) codes in Figure 12-1 indicate that this RAM only includes WBS components for part of the total project (see Chapter 6 for more on WBS). Therefore, the fact that team member B has no assignments in this RAM suggests they must be assigned to WBS components in a different part of the project.

You can analyze any RAM vertically by audience and horizontally by activity for situations that may give rise to problems. For an example, check out Table 12-1, which notes some observations about the assignments displayed in Figure 12-1 and issues they may suggest. After you identify these situations, you can decide how to address them.

After identifying a potential issue with your project’s role assignments, you can choose how to deal with it. Possibilities include:

• Ignoring the issue: For example, you may decide that three approvals are necessary to print the questionnaires and that’s just the way it is.
• Taking simple steps to minimize the risk of a problem: For example, you may ask the task leader to thoroughly document all important information in case they leave the project unexpectedly.
• Addressing the issue further in a formal risk management plan: See Chapter 10 for a discussion of how to analyze and plan to manage risks.

Developing a RAM

Despite the straightforward nature of the information included in the RAM, getting everyone to agree on people’s roles can be time-consuming. The following steps can help you get people’s input and approval with the least time and effort:

1. Identify all people who’ll participate in or support your project.

   See the discussion of project stakeholders in Chapter 4 for details.

2. Develop a complete list of deliverables for your project.

   See Chapter 6 for details on creating a work breakdown structure.

3. Discuss with all team members how each of them will support the work to produce the different project deliverables.

   For each of their assignments, discuss the level of their responsibility and authority, as well as the specific work they’ll perform. Also discuss with them any involvement that others will have on their activities. If specific people haven’t been identified for certain activities, consult with people who have done those types of activities before.

4. Prepare an initial draft of your RAM.

   Draw the table for your chart, and enter your project’s deliverables in the left column and the people who will support the activities in the first row. In the cells formed by the intersection of each row and column, enter the roles that each person will have (based on the discussions you have with your team members in Step 3).

5. Have all your team members review and approve your draft chart.

   If people agree with the chart, ask them to indicate their agreement in writing. If they express concerns about some aspects, ask them to note their concerns in a memo or an email.

6. If some of your team members don’t approve the draft chart, revise the chart to address their concerns and ask everyone who gave input to review and approve the revised chart.

   If you make any changes to the draft RAM, have all your team members review and approve the revised chart, especially people who already approved the prior version.

7. Go back to Step 5 and continue the process until everyone you consulted in Step 3 approves the chart.

Ensuring your RAM is accurate

For complex projects, the RAM can be quite large, and keeping the chart current and consulting throughout the project with all the people identified can be time-consuming. However, having a chart with incorrect information can result in duplicated efforts and overlooked activities. The following sections offer you suggestions for how to keep your RAM accurate and current throughout the project.

Developing a hierarchy of charts

Including 50 or more activities on the same RAM can be cumbersome, so consider developing a series of nested charts for larger projects (also known as a hierarchy of charts). Prepare a high-level chart that identifies responsibilities for higher-level components in your work breakdown structure (such as project phases and major deliverables), and then develop separate charts that detail responsibilities for lower-level deliverables and work packages (see Chapter 6 for details on phases, deliverables, and work packages in a work breakdown structure.)

Suppose you’re planning a project to design and implement an information system. Figure 12-3 illustrates how you may create two layers of RAMs to depict the project team members’ roles. First, prepare a high-level RAM that details the roles for major phases, such as requirements, system design, and system test. Then display in a second chart the roles of the team leader and their group in terms of the activities that comprise requirements.

Realizing why a person micromanages

Unfortunately, no simple rules define when or why a person is micromanaging. If you think your manager is getting a little too close for comfort, let them know you feel that their oversight is a bit excessive. Try to give them some objective indicators to explain why you feel the way you do.

If the person doesn’t change, you need to figure out why they continue to micromanage you. Think about whether one or more of the following explanations may be the reason and try the suggested approaches:

• The person is interested in and enjoys the work. Set up recurring touchbases to discuss interesting technical issues with the person.
• The person is a technical expert and feels that they can do the job best. Review your technical work frequently with the person and give them opportunities to share their technical insights with you.
• The person may feel that they didn’t explain the assignment clearly or that unexpected situations may crop up. Set up a schedule to discuss and review your progress frequently so that the micromanager can promptly uncover any mistakes and help you correct them.
• The person is looking for ways to stay involved with you and the team. Set up scheduled times to discuss project activities. Provide the micromanager with periodic reports of project progress, and make a point to stop by and say hello throughout the project.
• The person feels threatened because you have more technical knowledge than they do. When talking about your project in front of others, always credit the micromanager for their guidance and insights. Share key technical information with the person on a regular basis.
• The person doesn’t have a clear understanding of how they should be spending their time. Discuss with the person the roles they would like you to assume on project activities. Explain how the person can provide useful support as you perform the work.
• The person feels that they have to stay up on the work you’re doing in case anyone else asks about it. Discuss with the person what type of information they need and how frequently they need it. Develop a schedule to provide progress reports that include this information.

Gaining a micromanager’s trust

Your supervisor may be micromanaging you because they don’t yet have full confidence in your ability to perform. Instead of being frustrated or resentful, take the following steps to help your supervisor develop that confidence:

• Don’t be defensive or resentful when the person asks you questions. Doing so makes you appear like you’re hiding something, which only makes the person worry more. Instead, willingly provide all the information the person asks for.
• Thank the micromanager for their interest, time, and technical guidance. Complaining about what you perceive to be excessive oversight strains your relationship and increases the person’s fears and insecurities. After you explain that you value and will incorporate their input, you can try to develop a more acceptable working relationship.
• Offer to explain how you approach your tasks. Seeing that you perform your work using appropriate, high-quality techniques increases your manager’s confidence that you’ll successfully complete the assignment they gave you.
• Work with the person to develop a mutually agreeable schedule for sharing progress and accomplishments. Develop meaningful and frequent checkpoints. Frequent monitoring early in your work reassures both of you that you’re performing the assignments successfully.

Working well with a micromanager

You can reduce or even eliminate most micromanagement by improving your communication and strengthening your interpersonal relationships. Consider the following tips as you work with a micromanager:

• Don’t assume. Don’t jump to conclusions. Examine the situation and try to understand the motivations of the person who’s micromanaging you.
• Listen. Listen to the micromanager’s questions and comments; see whether patterns emerge. Try to understand their real interests and concerns.
• Observe the person’s behavior with others. If the person micromanages others, the micromanagement likely stems from their feelings of insecurity rather than from your actions and performance. Find ways to address the person’s real interests and concerns.
• If at first you don’t succeed, try, try again. If your first attempts to address the situation are unsuccessful, develop an alternative strategy. Keep at it until you succeed.