Product Management For Dummies
Book image
Explore Book Buy On Amazon
As organizations grow, the complexity of who is responsible for doing what becomes greater. Product managers have a long list of responsibilities, and making sure that everyone is clear on what they need to be involved in and what they can safely pass onto other roles is important to document.

There are two management tools that are useful for making sure that everyone knows who participates in finishing an activity and who makes a decision about a particular topic:

  • RACI: Who is responsible for completing certain tasks?
  • DACI: Who decides on a course of action for a particular task or function?
Depending the whether the issue is one for responsibility or decision making will guide the product manager in which tool to use.

Going the RACI route

A key concept that solves the responsibility part of the puzzle is called RACI. The acronym stands for the following:
  • Responsible: Who is responsible for participating in completing an action?
  • Accountable: Who is accountable for making sure an action is complete?
  • Consulted: Who is consulted during the process of completing an action?
  • Informed: Who is informed about the state of an action?
An example is planning a company potluck beach party. Preparing for an event means that anyone responsible for bringing food or other materials as part of the event is listed as responsible. Volunteers for food, blankets, and so on are accountable for making sure that commitments are met. Executives are consulted on key matters as the event is rolled out. And anyone who isn't a volunteer is simply informed as to the state of affairs.

The table shows a completed RACI chart for an Agile development group that uses scrum methodologies. Creating this chart as a group will allow the product manager or product owner to clarify who is responsible for which tasks and decrease confusion among group members.

Agile Group RACI Chart

Agile Group RACI Chart Product Manager Product Owner Scrum Master Engineer User Experience Quality Assurance Mgmt
Develop QA tests I I I C I R I
Attend daily standups C R R R R R I
Create product vision R C I I I I C
Estimate story points I C C R R C I

Taking a DACI direction

For many organizations, creating a RACI chart like the one in the preceding section works well. Product managers face further complications. They're trying to move forward on various fronts. Without clear decision making, entire projects can stall while everyone gets to the point of saying yes. This situation is why many product managers turn to a DACI chart. It's just one letter different, but the organizational impact is dramatic when all levels in the company adopt it.

DACI stands for

  • Driver: Who drives a decision to a conclusion?
  • Approver: Who approves a particular decision? For best results, keep the number of approvers low.
  • Contributor: Who contributes to a decision?
  • Informed: Who is simply informed about the final decision?
The DACI model is great for clearing up decision confusion. For the picnic example in the preceding section, the vice president of human resources is the driver. She wanted a team building event for the company. The CEO is the approver for the plan to have a picnic, and the contributors are the employee activity council who helped the vice president of human resources with decisions like inviting employee family members or not. The rest of the company employees are informed about the event.

It's the same event, but there's a world of difference between who drives and who is responsible. Multiple people can be responsible, but only one driver is allocated in the DACI model. Who is in charge is crystal clear. Who is allowed to approve, who can contribute a point of view, and who can stop the project is also very clear, as shown here.

Agile Group DACI Chart

Agile Group DACI Chart Product Manager Product Owner Scrum Master Engineer User Experience Quality Assurance Mgmt
Decide on product vision D C I I I I A
Decide when product is ready for release A C C C C D I
Get a user story ready for the team to review C D C I I I I
Agree that user story is ready to be made part of the sprint I C C D C C I

Using RACI and DACI effectively

The best time to create a RACI and DACI chart is at the beginning of a project. Program management would be called in to assist in working through the details since this is a company process If you wait to create this agreement after conflict arises about who does what and who can decide what, agreement is harder to reach. Depending on which issues you expect in your project, plan a working meeting to detail every task that needs to be finished and then clearly allocate responsibility. If your team is having difficulty making and sticking to decisions, hold a DACI meeting and hash the issues out. You may need a facilitator. Human resource personnel or trainers often have training in facilitation. Ask them to run the meeting for you so that you get impartial results. And a key decision maker is always welcome at the meetings to provide weight in a tie-breaking situation.

Once you have agreed on a DACI or RACI configuration, you can reuse it from project to project. If you find yourself in disagreement again or there's a large turnover in the team, it might be worth hashing out a new one.

One last benefit: If you're drastically overworked, a RACI chart makes this imbalance obvious to everyone. Then you can negotiate taking certain tasks off your plate.

About This Article

This article is from the book:

About the book authors:

Brian Lawley is the CEO and founder of the 280 Group, the world's leading product management consulting and training firm. Pamela Schure is director of products and services with the 280 Group. She has worked in product management, product marketing, and marketing for Apple and Adaptec, among other companies.

This article can be found in the category: