Community Data-Sharing 101: Building Partnerships

Last month, I wrote about the basic steps in engaging partners in your data warehouse project. Now it’s time to delve into the intricacies of bringing all of those individual partners together into a functioning whole.




The first step is to bring all the partners together to discuss on the specifics of the data warehouse you’ve gathered to create. For example, here would be the time to come to agreement on the basics of creating a data warehouse that we discussed in earlier blog entries, such as framing the questions your data warehouse is going to investigate and making some early decisions on your data warehouse design.


This is as much about laying the groundwork as it is about turning a diverse group of community leaders into a workable team. The stakes here are much higher than in your normal multi-agency meeting. Remember: they have to feel comfortable sharing data not just with you, but with one another. You’re not just building a system; you’re building mutual trust.


This process can take months.  In the Quad Cities, it took more than two years.  But we made good and sure, before our very first data point was uploaded, that we were all in complete agreement on the following points:


  • What question are we collecting data in order to answer?
  • What data would we need to collect (and from whom, and how often) to be able to answer that question? Also, do we want to collect demographic data as well, so we can measure disparities between different populations?
  • Who needs to have access to the data in order to answer these questions, and what confidentiality regulations come into play with that access?
  • What is the end goal? What will knowing the answer to our question change in the work the community is undertaking?

This all may seem like just going over old territory; after all, you’ve been having these exact same discussions for months while trying to bring everyone to the table.  The important thing to remember, though, is that, although each individual partner has had these discussions with you, they have not had the opportunities to discuss these things with one another.  Every person sitting at that table may think there is agreement on basic points, but only open discussion on those topics will ensure that everyone is actually on the same page.




These discussions quickly get very intricate and detail-oriented. It’s not only about what you measure, but how you measure it. In the Quad Cities, for instance, our leadership wanted to track how many middle school students missed more than 18 days of school each year. This sounded straightforward to me at the time: a ten minute discussion, tops. But the superintendents at our table didn’t see it that way. They got into long, detailed debates, eventually spanning three separate meetings, on minor points that the non-school partners at the table had never considered.


There was, for example, a conversation about whether or not to count tardy students as absent, and if so, how many hours they’d have to be late (or leave early) before a “present” became an “absent.”  This distinction was way too granular for our purposes; we just wanted a standard measurement so we could track population-wide, annual trends. But it was a priority for the superintendents, so it was a priority to the rest of us as well. I sat through more conversations about the definition of an “absence” that summer than I’d ever imagined would be possible. In data, nothing is ever simple.


It is important not to lose patience during this process. Staying at the negotiating table until all eight superintendents approved our standard definition of an “absence” not only ensured the clarity of our data findings, but it was also an invaluable way to demonstrate to those superintendents that we were taking their data just as seriously as they did.




Do be careful at this stage of partnership-building. I have seen several communities get to this point and end up stuck there. They’re so busy painting pictures of the paradise they’ll be able to build once everyone is sharing data that they never actually get around to collecting any. Talking about creating a Data Warehouse is easier and (believe me) more enjoyable than actually putting in the work to accomplish it.  But your partners will soon figure out there’s no momentum, and they will melt away.


The main way to avoid this trap is to not bite off more than you can chew. The Quad Cities Data Warehouse is currently designed to serve five distinct purposes (ranging from demographic breakdowns of needs indicators to the tracking of highly-mobile students as they move from one district to another), but it didn’t start out that way. We started out with just a single function, and a single question we wanted to answer: “What academic performance indicators best serve as early warning signs that a student will ultimately not complete high school?”


In order for our Data Warehouse to be able to carry out this one function, we needed to have all of the conversations on the bullet points above—and during that process build a strong working relationship between partners and also higher levels of trust.  By the time we had put together a rudimentary Data Warehouse to carry out our one, original function, those relationships and that trust were so strong that our partners felt comfortable coming to us and saying, “With a few tweaks, we can also use this same Warehouse design to do X and Y.” Incorporating these suggestions (and, it cannot be stressed enough, by letting our partners have some say in the evolution of the project) got us to the multi-functional Warehouse design we have today. In the end, it wasn’t high ambitions, but humble ones, that brought us as far as we’ve come.


The side benefit of this rule is that it’s much easier to catch it—and nip it in the bud—when the conversation starts going off on a tangent. Some of your partners may have their own special projects they want to pursue, and/or their own agendas. Others will keep busy trying to point out ways in which your project could fail. To both of these partners, you can simply say, “Let’s just focus on this one thing for now.” Keep your goals achievable, your movements small, and handle barriers only as they arise. Trust me: humble goals are difficult enough to achieve (especially at the very beginning). There will still be plenty of work to go around.




After all the time and effort it will take you to bring everyone onto the same page and mold them all into a single, cohesive group, it is time to decide which of your partner organizations will serve as the project lead.  There are several vital considerations in making this choice, which I’ll cover in next month’s blog.



Community Data-Sharing 101 Blog Series



To learn more about the Quad Cities’ educational initiatives and how nFocus Solutions is impacting the community, read the case study, The Quad Cities: Making Shared Data a Reality.


Alex Kolker

Dr. Alex Kolker is Community Impact Manager of United Way of the Quad Cities Area in Davenport, Iowa. Over the last three years, the Quad Cities has been using nFocus’ Community Solutions Data Warehouse software to create a community-wide, multi-partner, multi-disciplinary data warehouse linking student achievement data from 8 different school districts – in two states – with outcomes data from local non-profits and post-secondary achievement data.