skip to content

Presenting to Partner Leadership

Intended audience: DataKind Volunteers

You set your project up for success at the beginning by making sure that the partner organization’s leadership was bought in, now continue that investment by concluding with a presentation to the organization’s leadership, and maybe even their board, to demonstrate what you built, how they can use it, and why they should care. It is never appropriate to just send a zip file to your partner organization and be done with things. Continued leadership investment makes an organization more likely to adopt and continue using your deliverables

Some tips to keep in mind when presenting to the partner organization’s leadership team:

Do:

  • Take advantage of DataKind’s presentation template, which you can find a copy of in your project’s google drive folder already (“5 Share” → “2 Presentations”) if you used the DataKind standard folder structure. Otherwise, make a copy of the template here.
  • Start with the “so what”, then add the details (graphs, analyses, etc.). What is the finding and why should the organization care?
  • If possible, frame your work in the form of a story or narrative. This typically helps people remember the information that you present.
  • Get to the point. Your partner organization’s staff are busy and want to know how your work will help address their business challenge - make it relevant to their needs and present the information in a concise way.
  • Structure your report or presentation around the objective of your project. Any technical details that you introduce should be in service of explaining how your project accomplishes its objective.
  • Define technical terms or know when you can skip them altogether. Your audience are experts in their field, not necessarily in data science (examples of terms to define or skip: regression, correlation, p-value).
  • Employ visual aids (e.g. graphs, charts, diagrams) when possible, and explain all visuals and graphs.
  • Explain any scope changes and why! Include specific reasons and how they can be addressed in the future.
  • Explain project challenges without criticizing the organization (not having the right data, data quality issues, etc.).
  • Over-communicate the risks inherent in your product and what the organization should do to spot and mitigate them.
  • Show sensitivity. Assume that all stakeholders, including the recipients of the programs, are going to be reading this report. Remember the data points are often about people.
  • Keep an eye out for any indications that the organization is not bought-in or will not invest enough time and resources to use the tool well (e.g., leadership that is zoned out or that suggests using the tool incorrectly). Use this opportunity to make sure your work gets adopted and used properly.
  • In refining the slide deck, use mostly visuals (although some bullet points are okay). Speaker notes are a must!
  • Recognize the project partner team. Being in front of leadership provides an opportunity to publicly recognize the partnership of their role.

Don’t:

  • Be overly negative. Avoid casual negativity - in other words, “We couldn’t do this project because the data on data.gov is woefully out of date because government agencies are too slow and don’t keep things maintained and would never respond to our calls!” Instead, say “The data on data.gov was insufficient for our purposes because it was out of date, however if this data could be retrieved for the past 12 months, we could do…”
  • Undersell your team’s work. It’s good to be humble but don’t downplay what you have accomplished, even if it’s not what you had hoped to achieve setting out. You may wish you could have taken an analysis further, figured out the solution, or hadn’t had to cut back on the scope of work. Don’t forget the many wins along the way though! A “small win” to you may actually be a game changer for the organization.
  • Make offhand suggestions. A slight allusion to how something could be used that isn’t fully statistically rigorous can be heard by your audience as “we should use it that way, and it’s good to use it that way right now.”
  • Provide a line-by-line explanation of your code - the details will almost certainly drown out your main point. Be cognizant of what is and isn’t necessary for a non-technical audience to know to understand your work.
  • Show off all of the volunteers’ work at the expense of understanding. Stick to digestible and actionable info.

Contributer(s): Benjamin Kinsella, Shanna Lee

Contact us

If you would like to learn more about us, partner with us, or get in touch, email us at community@datakind.org

Subscribe to our newsletter
Subscribe