Remember the first post? Where we considered how organizations do operational stuff in support of mission stuff, and there was a hierarchy that could be read in any direction? And the second post, where we learned a bit about UX and human centered design, to consider a better way to approach a software MVP? Ah, good times!
To paraphrase a client:
“The goal is to make a system so that the people who have to capture the data are just capturing it as part of their daily work. This way the data is handy when it’s needed for reporting and analysis.”
If you take the models from the two prior posts, and mash them up, you get an approach to thinking about any operational engagement in the nonprofit space. You can use this diagram to remind yourself to engage internal stakeholders in all of these arenas. You can use this diagram to remind yourself to ask questions about data capture that ensure alignment with outcomes. You can use the diagram to help think about data producers and consumers, and their needs, as appropriate to each level.
It’s a short-hand for a way of thinking about projects that appears obvious in a blog post, but I’ve seen missing from real-world projects for my entire career. So I’m writing about it.
Everyone is a Data Consumer and Data Producer
Put another way, I find it useful to think in terms of data consumers and data producers. In your organization, everyone is a data consumer and most people are data producers. To be effective, an organization has to have its production in alignment with its consumption at all levels of the hierarchy. To construct a cross-cutting project, I need to know what data people are expected to produce or capture, and what they’re expecting to consume or use, no matter who they are.
I often enter a project at only one level of the hierarchy. Executives are frustrated because they can’t get the reports they need, so I’m brought in on a reporting or analysis project. Program staff are burning out because they’re typing in a lot of stuff, so I’m brought in on an efficiency project. The truth is, all projects have to consider all levels or they’ll fail. If the data that the program staff are capturing aren’t what the executives care about, I can’t produce reports. If the executives demand data capture that doesn’t benefit the staff as consumers, the staff won’t enter it or it will be an afterthought. A project has to address data production and consumption needs at all levels, and align those levels, to succeed.
You can think of this way – nobody wants to look like a fool, and nobody wants a hassle at work. At every level, a project can make a job easier or harder, can provide benefit in exchange for work or can just add more work. If you want something to succeed, you need to consider what’s in it for the person you’re asking to do the work. If you can make their job easier by easing their production or simplifying their consumption, you win. If you can make them badass, you win. And yes, you can make every level badass if you look across all levels instead of focusing solely on the top of the food chain.
An Example
The following example does not represent any organization, living or dead. Any similarity to your nonprofit is purely coincidental.
The consultant sits across from the ED, listening to her tale of woe. All she wants, she says, is to know how many kids from Neighborhood A are in the program, and if this year’s participation is up or down from last year. It shouldn’t be hard. They spent a lot of money on a database. And while we’re at it, it would be great to have breakdowns by age, gender, grade in school and parent’s income bracket.
This is a simple reporting problem.
The consultant goes off to talk to the program staff to get a sense of where this data is kept. His heart sinks when he learns that the data isn’t kept anywhere. The program staff know that the kids mostly come from Neighborhoods B and C, but some come from A. They know, anecdotally, that all of their kids’ parents are in the bottom two income brackets. But they admit kids into the program blind to neighborhood and income. They do keep age, gender, and allergies, because they have kids on site and that’s important information.
Pop quiz! You’re the consultant. Do you:
- Tell the ED that her problem is her folks aren’t capturing the right data, and she needs to make them do so first?
- Design a technology solution to capture all the data, because the problem is obviously that there’s no place to put it?
- Eat your tie in despair and go home?
These are the solutions I see most often. Seriously!
What’s the problem with solution 1? The ED can force her staff to enter more data, for sure. But if it isn’t needed for the program, it will become an afterthought. And if it’s an afterthought, then it will get forgotten. If it gets forgotten, the ED gets crappy, old and inconsistent data to report on. And if staff have to enter too much data that they never need, they’ll burn out. Not cool.
Whats the problem with solution 2? Well, it’s likely that there isn’t a place to put it. With data, though, if there’s a need to capture the data, people will capture the data. Shadow systems will crop up, spreadsheets will proliferate, post-it notes will adorn monitors and keyboards. People who care (and that’s most nonprofit staff) will find a way to remember what they need to remember.
Solution 3 is just not tasty, unless you have Sriracha.
If it were me, I’d call this the Big Red Flag of Misalignment and start asking more questions. It’s a little delicate to ask someone why they want data – after all, it may be none of your business. They probably have really good reasons. Probably a board member or funder asked or keeps asking, and that’s reason enough. And anyway, what does a consultant know – just write the report, yeah?
But the questions have to be asked. If the ED has good reasons for needing that data, maybe program staff are missing an important criterion in their assessments. If the program staff aren’t capturing the data, maybe the ED doesn’t realise that.
I think I’ve made my point. So I’ll stop.
It’s not something we’re used to thinking about, to question the alignment of a request at any level of an organization. Requests are usually quite reasonable and stem from a real problem. It’s uncomfortable to question a request, particularly if you do data or technology work for hire. But if you don’t keep in mind that all levels of operations, from why down to the how, you risk creating an unsustainable solution.
Nonprofits deal with enough as it is, don’t be the person who creates an unsustainable solution.
