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 – DriverBasic DACI acronym
A – Approver
C – Contributor
I – Informed
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 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|
|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.
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.
|Market Research||Competitive Analysis|
Buyer and User Personas
Portfolio Investment Levels
|General Approach||UML Diagram|
*Which ones of these depends on situation
|Design Spec||Figma Prototype|
JIRA details (if needed)
|Quality Control||Test Plan|
|Go to Market||Webinars|
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?