Drowning in data, drafting a data checklist, and asking “WHY?”

Two poster boys of nonprofit data sanity: Bob Penna (l) and Steve Pratt (r).

Now that TNB Labs is up and running, we’re receiving a lot of requests from nonprofit organizations who are perplexed about how to manage the data that they have, before they plunge any further into data analytics or think about acquiring a new data analysis tool.  This has given me a lot of opportunities to reflect on how difficult it can be for people whose expertise lies elsewhere to orient themselves to data governance.

Steve Pratt‘s blog article “Drowning in Data?” has been a huge inspiration.  In it, he explains the importance of data inventories, and offers to send the Root Cause template to anyone who requests it.  I highly recommend that you send an email to info@rootcause.org, and ask for a copy.

At the same time, as I went over Steve’s template, I had a nagging feeling that we needed something even more elementary.  Remembering my friend Bob Penna‘s exhortation of a few months before, about asking “who, when, where, what, how, and why,” I quickly drafted a data checklist that focused on those basic questions.  When I sent it to Bob, he very quickly returned it with some excellent enhancements; the most brilliant one was to start the checklist with the question “WHY?”  As he very sensibly pointed out, if you can’t come up with a good reason why you are collecting, analyzing, reporting, and archiving information, you might as well stop there.  In the absence of a persuasive answer to the question “why?” there’s no need to ask “who, when, where, what, and how;” in fact there’s no reason to collect it at all.

With that wisdom in mind, I have tweaked the draft of the data checklist, and herewith present it to you for feedback. This version is the result of a Penna/Finn collaboration:

You can view it by clicking on this link.

Before you take a look at it, I recommend reading “Drowning in Data?”  After you’ve perused the spreadsheet, I recommend reading Bob Penna’s book, “The Nonprofit Outcomes Toolbox.”

 

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Let’s revisit the concept of failure-friendliness

Eight years ago, I wrote a blog article about failure-friendliness in nonprofit technology. It was very much inspired by my friend and colleague, Dan Scharfman. Since Dan died this week, and this is also a week when I have been thinking hard about the obstacles that nonprofit organizations face in tracking their outcomes, it seems appropriate to reprise the article here and now. Having coped with the need for failure-friendliness in nonprofit technology for years, I see that my understanding is still superficial when it comes to the difficulties that nonprofits have in acknowledging programmatic failure. I invite your thoughts on how we can be more transparent about and more open to learning from failure. Meanwhile, special thanks go out to Beth Kanter, for her outstanding blog articles on this topic.

Wed 26 Jan 2005 05:41 PM EST

The term “failure-friendly organization” was first introduced to me by a colleague I revere – Dan Scharfman of Baird Associates.

My first impression was that he was an unlikely champion of failure, since Massachusetts is well-supplied with nonprofit organizations that consider the technology services that he has provided to them very successful indeed.

However, many of us in the nonprofit sector have seen the following things happen with major implementations or upgrades:

• The technology doesn’t work, or doesn’t work nearly as well as it should;
• The intended users won’t have anything to do with the technology;
• Major changes in technology in the outside world quickly render the organization’s choices obsolete;
• Programmatic priorities change, and the technology is all but irrelevant;
• The organization has not factored in the shocking cost of customizing, tweaking, maintaining, and upgrading the technology.

Although techies vary greatly in their attitudes about projects that don’t work out, we also tend to make tacit assumptions that everyone concerned understands that we are not engaged in an exact science but in an evolving process.

Techies also tend to regard failure as pretty interesting – as a good source of information about what ought to be fixed when Version 97.53.01 of the software is released.  We also enjoy working on cool tools, even if such tools don’t actually deliver the outcomes desired by those who are underwriting the project.  This form of process orientation can be less than endearing to decision-makers in nonprofit organizations.

Oddly enough, nonprofit workers tend to be very good at process orientation when they are on familiar ground.

Sometimes this process orientation is a grim necessity, with governmental agencies strictly mandating, auditing, and enforcing protocols that nonprofits must follow in order to maintain their tax-exempt status, accreditation, or contracts for services.  These are headaches that would impel just about any organization or individual to worry a great deal about operating according to plan and documenting the process, rather than ensuring a specific outcome. This of course is a very “functional” (or “instrumental“) form of process orientation.

A more “expressive” form of process orientation is also frequently seen in nonprofit organizations – manifesting as a desire to be flexible and responsive to changing situations, or as a desire to arrive at decisions through consensus.  However, it can be difficult to extend that attitude to technology, which tends to be difficult for non-specialists to comprehend, time-consuming, and expensive.

Another challenge is that organizations and individuals (including yours truly) can be reluctant to cut their losses, and say, “This isn’t working.  Let’s stop, figure out why, and decide on some next steps.”  Of course, in some settings, the decoded version of this message is “Let’s find someone to blame and punish…maybe YOU.”

Yikes!

Is there any solution in sight?  I only wish I had something certain and simple to offer.  Here are a few ideas, although none of them come with guarantees of success:

• Techies need to understand the nonprofit organizational cultures in which they are operating.  Progress toward this goal is possible if the techies listen, ask questions, and listen some more.  These conversations should start early in the planning phase.
• Nonprofit workers need to understand how technology innovations and implementations happen in real life, and have a reasonable idea of what factors can lead to unexpected outcomes in technology projects.  Progress is possible if – yes, you guessed it – the nonprofit workers listen, ask questions, and listen some more.
• Everyone needs to cooperate in creating incentives for spotting, discussing, and correcting errors rather than evading their detection.  I freely admit that I always find it easier to do these things when the mistake was made by someone else, but am always striving to do better.

I wish I could remember who it was that first said to me, “This is not about one person against another. This is about our team against the problem.”  Anyone who can say that is a saint, a boddhisatva, a tzadik, or an unusually effective manager.