Project Roles and Responsibilities

The Roadtrip Metaphor

I love metaphors and this one is one of my favorites. Imagine a project as a roadtrip with some friends. Sometimes you will be driving, sometimes you will be in the passenger seat, sometimes in the back seat. There are people, like your parents, who just want to know where you are, but they aren’t specifically on the trip.

Your project is the roadtrip. The people in the car and at home are the people you work with. If you are driving and crash into a tree, everyone will die. If someone else is driving and you see they are about to drive off the road, you have a responsibility to say something. You are all in the car and are responsible to each other. This is true whether you are driving or asleep in the back seat.

People have different roles during different parts of the project. It’s even possible that two people are driving two aspects of the project separately. I will break it down, but these stages are not linear and serial. They are parallel and can sometimes go out of order. Let’s define the roles in general, then we will talk about the stages of the project.


DACI (or RACI) is a framework I learned about in 2006 at Intuit.

D – Driver
A – Approver
C – Contributor
I – Informed

Basic DACI acronym

Driver is the person who is actively moving the project forward. They are making decisions and producing deliverables. They have the steering wheel.

Approver is the person who is the consumer of the deliverable of any particular driver’s work. If they can’t use the deliverable, then they can’t Approve or Accept it. (I will give examples in a moment)

Contributor is someone helping. They aren’t directly making the deliverables, but they are contributing. This usually takes the form of meetings, but could be more.

Informed are your parents. They just want to know what is going on and be in the loop. They are not contributing to any deliverable. This is typically people like project managers or executives who care about the project but not involved in every detail.

Stages of a Project with DACI Map

Market ResearchProd MgtProd StrategyDesignEngineering
Problem PrioritizationProd MgtProd StrategyDesignAll
Problem DefinitionProd MgtDesignDesign / EngAll
General ApproachDependsDependsEngineeringProd Strategy
Design SpecDesignEngineeringProd MgtAll
Build ProcessEngineeringQADesignProd Mgt
Quality ControlQAProd MgtEngineeringDesign
Documentation/TrainingDoc WritingSupportAllAll
Go to MarketProd MgtSales / SupportMarketingAll

Note: This map is assuming a STRONG design team. If your design team is weak, then PM will take more responsibilities. However, it is a good thing to have a strong design team.

Deliverable Dishes

Another metaphor. As a driver, you own a restaurant and cook the food. The Approver is the customer. For every project, every stage of the project, whomever is in the Driver seat, they are cooking the meal. The approver is eating the meal. As a good restaurant owner and chef, you want to make sure your customers are happy. You should ask them, what do you like to eat? How do you want it prepared? How spicy should it be. Here is a map of deliverables.

Deliverable Map

Market ResearchCompetitive Analysis
Buyer and User Personas
Opportunity Assessment
Problem PrioritizationRoadmap
Portfolio Investment Levels
Problem DefinitionPRD
Use Cases
Capabilities Requirements
General ApproachUML Diagram
Presentable prototype
*Which ones of these depends on situation
Design SpecFigma Prototype
JIRA details (if needed)
Build ProcessCode
Quality ControlTest Plan
Go to MarketWebinars
Website Changes

Note: There can be other deliverables, but these are the basics

Other Responsibility Details

Some things are important and people argue over who is the driver. Here is a limited list of some of those items and who I think the DACI is. It’s a good idea to get on the same page about these items in advance.

Microcopy – This includes labels, small bits of text in the UI, button text, tabs, and the names of objects in the system. I think the design team is best suited to write this copy.

User Interface and Information Architecture – This is one that drives me nuts. The product design team are not there to make it pretty. We are there to design how the system is used. Product management is not the Driver, nor are they the approver. Design is the driver and engineering is the approver. If you have a weak design team, PM will try and dominate this part of the decision making. This troubling dynamic is what makes designers hate their jobs. Please, if you are a PM, please realize that doing UI and IA is a design job and you are just a contributor, not the approver, not the driver.

Timeline and Budget – The driver here is Product Management. It’s not OK for the design team to make a design that takes 8 weeks to engineer if the budget is 3 engineering days. With a limited budget, you get a limited product, but sometimes that is the right decision. Design is the approver (accepter) of the timeline and budget. We need to say if something is impossible, but if it is possible, we need to adopt those constraints and accept the budget.

General Approach – This totally depends on your team. Sometimes there is an engineer who is great at this. Sometimes a PM does it. I personally love doing this job, especially for projects that are heavy on the UI side. You need to look at your organization and see who has talent for this task and make them the driver. Be open minded where you find the talent.

Milestone Strategy – Although design plays a heavy role in this, the driver is sometimes confusing here. It’s a collaborative effort between everyone in the car. I could make a whole post of techniques about this, but that is for another day.

Voila. There we go. What did I miss?


One response to “Project Roles and Responsibilities”

  1. Lu Zhang Avatar

    This is a very good reading to me, I love the metaphor of driving a car. The DACI map helps me clarify many thoughts I have recently regarding to effectively contribute and take initiatives within a product team. To understand the role I’m in and take the appropriate actions based on product development life cycle is the golden key to a higher maturity team. Thank you for the share!

Whatya think?