How to Tell Your Data Science Story (Part 4)

(This is the last of a 4 part series on managing data science projects in government. Co-authored with Kim Hicks and Blake Valenta.)

Telling your data science story is part of a successful data science project. So don’t neglect it. This article covers why you should care about storytelling in data science and how to tell your stories well.

Why you need to tell your data science story

A well-crafted story packages the hard work you did into a digestible narrative. This is an essential step in the project lifecycle and should never be skipped.

It provides an empowering and meaningful narrative to your client

With a powerful narrative in hand, your client can tell their own story about the project. This helps them define why this work matters and own and message the change.

It also helps them consolidate what they learned in a meaningful way. Depending on the complexity of your project, your client may be feeling overwhelmed or in the weeds at the end. The storytelling phase lifts them back up to the program perspective.

It provides closure

A common issue in data science projects is getting done and deciding on a service change. Storytelling as a project milestone creates closure because it forces you to confront questions like:

• What was our core issue/question?
• What did we find?
• What did we do?
• What happened as a result?

By their nature, stories have an end. Once you have your “ending,” it feels satisfying.

It leads to a virtuous solicitation cycle

Your data science stories help find new clients and projects. You can use the stories to showcase what you actually do and to inspire new ideas. This is the virtuous “Story > Solicit > Story” cycle.

How to tell your data science story

We recommend Doug Rose’s 1 hour class “Learning Data Science: Tell Stories with Data” for tips on narrative structure and more. Our team also uses the following approaches.

Start storytelling on day one

As part of our data science charter template, we have a section on visualizing success. This pushes your client to articulate their story early in their own words.

“Standardize” your structure

A standard structure makes it easier to tell your story. It also helps identify gaps in the story (e.g. our service change is still vague). At DataSF, we use the following structure:

• Background: What is the minimum (and we mean minimum) background needed to understand the service question?
• Service question: What is the key service question or problem or opportunity we are trying to address?
• Analytics: What methodological approach was used? What were the major insights from the data science?
• Service change: How did we implement the insights? What changed about how we do our service or manage our process?
• Results: Depending where you are in the project, what were the results?

Notice how small the data science portion is. Remember – this is your client’s story!

Start from scratch with a whiteboarding session

Throughout your data science project, you’ve generated many data visuals and slides. Now is the time to step back from those details. In fact, prepare yourself: you might not be able to reuse any of that content. Sorry 🙁

Near the end of a project, we have a storytelling session. In this meeting, we whiteboard the story using our standard structure. Before the meeting, everyone reviews the project briefings and charter. But once we’re in the room, it’s just us and the whiteboard. Include one or two of your most committed client point of contacts in this session.

Get visual (but not always in that data viz way)

Once you identify your major headers and story components from the whiteboarding session, you’re ready to get visual. You’ll have some sketches from the session. This is not about data visualization! You may have data visuals, but you might not. One of our data science stories didn’t involve a single data viz – it just wasn’t necessary to tell the story.

We hand sketch visuals for each major point if it’s a slidedeck or identify key visuals if it’s an article. Dan Roam’s books on visual thinking are very helpful in this phase. Once we are satisfied with our sketch prototypes and the text, we make the visuals (or just use the hand sketches). PS The Noun Project is your friend.

Create a forum to tell your story

At a minimum, plan on developing an executive or leadership briefing. We recommend a slidedeck with:

• One slide per major point
• An accompanying visual
• Ordered per your standard story structure

If you have the time and capacity, we recommend a demo day to feature multiple projects. Keep the talks short (8 min or less) using your digestible slidedecks. Invite prospective clients. Demo day also gives your clients a chance to develop their public speaking skills and gain public recognition (a rare treat in government).

If you’re feeling extra ambitious, post all your projects online. In our showcase, we include a short-form article and slidedeck (that can stand on its own) for each project. We also include client testimonials. Our showcase then helps us find new clients.

We look forward to reading your stories – tweet them to us @datasf!

And check out the rest in this blog series:

• Part 1: How to solicit and select data science projects
• Part 2: How to scope data science projects
• Part 3: How to execute and implement data science projects

Joy Bonaguro is part of the GovLoop Featured Contributor program, where we feature articles by government voices from all across the country (and world!). To see more Featured Contributor posts, click here.