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

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

Stage	Driver	Approver	Contributor	Informed
Market Research	Prod Mgt	Prod Strategy	Design	Engineering
Problem Prioritization	Prod Mgt	Prod Strategy	Design	All
Problem Definition	Prod Mgt	Design	Design / Eng	All
General Approach	Depends	Depends	Engineering	Prod Strategy
Design Spec	Design	Engineering	Prod Mgt	All
Build Process	Engineering	QA	Design	Prod Mgt
Quality Control	QA	Prod Mgt	Engineering	Design
Documentation/Training	Doc Writing	Support	All	All
Go to Market	Prod Mgt	Sales / Support	Marketing	All

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

Stage	Deliverable
Market Research	Competitive Analysis Buyer and User Personas Opportunity Assessment
Problem Prioritization	Roadmap Portfolio Investment Levels
Problem Definition	PRD Use Cases Capabilities Requirements
General Approach	UML Diagram Presentable prototype Whiteboard Confluence *Which ones of these depends on situation
Design Spec	Figma Prototype JIRA details (if needed)
Build Process	Code
Quality Control	Test Plan
Documentation/Training	Docs
Go to Market	Webinars Emails Website Changes Etc

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?