Driver Mapping

During the workshop stakeholders take full ownership of the process from start to finish, as they progress quickly from concept to fully functioning collaboration.

Identify relevant stakeholders, map out related requirements and use them to identify work items and decisions that need to be made, distribute work and define an initial structure for collaboration.

You can use Driver Mapping to:

• organize start-ups
• kick-off projects
• tackle major impediments or opportunities
• implement strategy
• develop organizational structure to better enable the flow of value

The outcome of a driver mapping workshop is typically:

• a distribution of work, categorized in a number of domains, centered around the needs of stakeholders.
• a bespoke organizational structure that brings it all together, including interlinking domains for managing dependencies.
• a first draft of prioritized governance and operations backlogs for each identified subdomain.
• delegation of influence and the distribution of people to the subdomains through self-selection and nomination.

Although Driver Mapping is often used for identifying and defining new domains, there are also applications for identifying and distributing governance and operational drivers among existing domains in an organization, e.g. when an initiative will be dealt with by existing teams in an organization, or if a group feels they’re stuck in their current structure and are looking for inspiration for how to incrementally adapt it. The group can decide if they would map to existing domains and figure out which new ones they’d need to create, or even create a new structure from scratch.

In a small team or circle (max. 6-8 people), when it’s not a priority to distribute work, the team might only use steps 1-5, to understand the scope and fill the operations and governance backlog, and then use proposal forming or some other approach for identifying strategy and/or next steps.

In preparation:

• Invite people that can make a relevant contribution to this project. Send out the agenda for the workshop ahead of time.
• Send out a description of the primary driver and the main requirement you’ll work with, and in case of an existing domain, the domain description for the project/initiative in advance so people can familiarize themselves with it. Aim to resolve any objections before the workshop.
• Attendees may already prepare by thinking through and recording ideas of actors and relating needs.
• Prepare a poster with the domain description to present in the first step. You will also need A5 and rectangular sticky notes, pens and a wide wall to work.

The Driver Mapping Process:

These are the steps to follow:

1. Why are we here?

Present and consent to the primary driver and main requirement.

• Present the primary driver and main requirement, to the group
• Consent to the driver and requirement– Is the description of the driver and requirement clear enough? Is this an organizational driver? Is this driver relevant for the group to respond to? And, is the requirement suitable?
• Clarify any existing constraints from the delegator, e.g. budget, due date, expectations, etc. In the case of an existing domain, present the domain description.Invite further questions that help deepen understanding about what’s happening and what’s needed.
• Make explicit the level of commitment expected from the participants. E.g. people are expected to be here for the duration of the workshop only, or for the duration of the initiative, etc.
• Record any relevant information that comes up.

2. Who will be impacted?

Who will be impacted as we fulfill the related requirement? Consider who can help, stand in the way, benefit, lose, or be harmed.

• List actors on sticky notes and display them on a board
• Focus on actual people that will be impacted by this initiative (groups or individuals), and avoid making assumptions about future roles (such as Project Manager) or other domains (e.g. Marketing) at this stage.

3. What is needed?

Consider the various actors and describe what is needed: what do they need in context of the primary driver and main requirement, and what do we need from them?

• Write each suggestion on a separate sticky note (requirement card)
• Describe the requirement as well as the anticipated impact of fulfilling the requirement
• Use the format “We/they need … so that …”
• Add the name of the actor in the top left corner of the card
• Add your name in the top right corner of the card

4. Identify experience and expertise

Identify who has experience or expertise in responding to these needs, so that later, when people respond to a specific need, they know who might have valuable input.

• Take time to familiarize yourself with the various requirement cards.
• Add your name to those requirement cards you have experience with, or ideas how to address, so that later in the process people can consult with you if helpful.
• Consider adding names of people who are not present if you think they would have a valuable contribution to make.
• Write the name(s) of these people at the bottom of the requirement card.
• Adding your name to a card in this step, doesn’t mean you’re taking responsibility for the requirement, only that you’re able and willing to contribute to finding a solution if that’s helpful later.

5. Identify Domains

Cluster actors and/or requirements according to relevance, into coherent domains as a starting point for sorting and prioritizing needs. Consider how to optimize end-to-end delivery of value to the various actors that you identified in step 2.

Ways to identify domains:

• Cluster groups of similar actors (actor-centric)
• Cluster groups of similar requirements (needs-centric)
• A combination of both (of the above) is common

Consider this step complete, as soon as you’ve agreed on a first iteration of a meaningful distribution of work. Remember, you can make changes to the domains you defined at any time (later during the workshop or afterward), so you only need to aim for something that’s good enough to start.

As a facilitator, gently support the group in self-organizing, and be mindful of people dropping out of the conversation. This process often includes a phase that appears chaotic to some participants, which might make them feel uncomfortable. To test if a result is achieved, ask for objections to the domains being good enough for now.

6. Populate & define Domains

People organize into smaller teams around the different domains, then define the domain and give it a name.

• Form small team around the domains according to experience and interest
• Add at least 1 or 2 people with expertise first. Use the information on the cards,
• Check all domains are sufficiently accounted for
• In each group:
  • agree on a name for the domain.
  • define the primary driver and main requirement for the domain (and draft a brief domain description if helpful).
• Finally, have each group briefly present their domain, and during each report look out for dependencies and any overlap of these domains.

In this phase some people might wander between domains until they find one they feel they can contribute to.

7. Refine the Backlogs

Organize the work that lies ahead in each domain, ensure things are prioritized and described clearly.

• For each domain, copy the template below to a flip chart
• Sort all remaining requirements into the two backlogs on the flip chart:
  • operations backlog: needs that can be acted on
  • governance backlog: needs that would benefit from or necessitate a decision
• Combine and rephrase cards as necessary, so that description on each card is clear. Consult the author of the card when in doubt.
• Prioritize the cards in each board.
• Archive any requirement cards that appear superfluous.
• Consider the domain and describe and prioritize other requirements that may not have been identified.
• Pass on cards that appear to be the accountability of another domain to address.
• Put aside cards relating to multiple domains. You can deal with them in Step 8.

As a facilitator of the driver mapping process, provide a space to collect cards concerning multiple domains so that they can be addressed later.

Regularly pause to share reports between the various domains. Note: Some domains might dissolve, change or merge with others.

8. Connect Domains

Create structure to manage dependencies and deal with matters that extend beyond the scope of one domain or concern the wider organization

• For a new organization or project, consider Delegate Circles, Service Circles or Double-linking between domains.
• For an existing organization, also consider connecting to existing domains in the organization.

9. What else?

Take a moment to check if anything’s missing.

What else do we need to consider …

• … to run safely?
• … to effectively fulfill the main requirement?

10. Celebrate!

Take a moment to celebrate your achievements in getting your organization or initiative started!