From the monthly archives:

September 2009

Data Ecosystems

September 30, 2009

Not so long ago, nonprofit organizations had software tools, that dealt with specific parts of their organizational process. They had fundraising tools, client management tools, volunteer management tools, HR tools, accounting tools, etc. And the data in these varied tools were siloed – there was no way for one tool to talk to another without:

  1. painstaking manual entry
  2. painstaking export/import processes
  3. tools written by the same vendor designed to talk to each other (which meant that they were generally exceedingly expensive)

Although many nonprofit organizations still find themselves in this situation, there are increasing numbers of tools available to help them out of it. And as more and more organizational processes become web-based (whether “in the cloud” or self-hosted), and as more and more nonprofit-focused software includes open APIs (with some unfortunate exceptions,) nonprofit data is looking less and less siloed, and more and more like an ecosystem – many different software parts talking to others.

NTEN is trying to get a bit of a handle on this with the Data Ecosystem Survey.

I’m very much looking forward to the result – looking to see where this new set of tools that can talk freely to each other is working … and where it isn’t – where there is still work to be done. Please take time to fill it out!

{ 2 comments }

Beth Kanter tweeted about an article by Gale Berkowitz relating to evaluation, which I found really fascinating – it is a must read. In this article, Gale points to an interesting shift within her organization (the Packard Foundation):

“Over the past four years we have been shifting from evaluation for proof or accountability (“Did the program work?”) to evaluation for program improvement (“What did we learn that can help us make the program better?”).”

In some ways, it’s a subtle shift – but as she says, the latter leads to “real time” evaluation – something that happens as one moves through projects, not just at the end.

Nonprofit organizations often have their feet to the fire to evaluate their programs and projects, because funders and contributors often demand proof that their programs work. And there has been an overall movement in the sector in the direction of increased evaluation and learning.  The community I’m a part of, the group of for-profit (“for-little-profit” as is often said – we’re small and lean)  companies that serve the technical needs of nonprofits, evaluation is generally not part of the process of the work we do. But it should be.

I’ve talked about this before. A lot. In a variety of different contexts. To me, evaluation, both internal (“how could we have done this process better?” “”How could we have worked together as a team better?”) as well as externally with the client (“How did we do?” “What could we have done better?” “How could we have communicated better?”) is a critical part of the work we do.

It’s a tough balance. We’re geeks, often busy deep in the command-line, SQL and code. We’re often extremely busy, juggling lots of projects and demands at once. The bottom line, of course, for us, is always a measure of how well we are doing, but I don’t think that’s enough. As our sector as a whole moves further and further along the path of a commitment to evaluation and learning, I think it behooves us to follow.

So, you ask, what are good strategies to start with? I can give you what we try to do. Some of it is well worked out, and some is nascent. All of these we aim to do, but it’s easy to miss the target. Evaluation is a learning process, like anything else, and the most important thing is an intention and commitment to being a learning organization. The rest will eventually follow over time.

  1. Spend time at the beginning of each project outlining evaluation steps and process for the project.
  2. Spend time at the end of every project asking internally “what worked, and what didn’t work?”
  3. Ask clients at the end of the project a set of questions about the process and the result.
  4. If its an ongoing engagement, ask periodically (we aim for every 6 months or so) for an evaluation meeting or call with the client.
  5. Write a report at the end of each project with lessons learned.
  6. When a proposal isn’t accepted, ask a few questions, both internally and externally, and write up a short report with lessons learned.
  7. Ask internally how earlier lessons learned, are being applied to current projects.
  8. Always be open to learning how to make things better.

{ 3 comments }

Links

September 11, 2009

Some great tech and nonprofit tech stuff I’ve come across lately:

{ 0 comments }