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.

Tagged: accountability, audit, blame, boddhisatva, championing failure, charity, consensus, dan scharfman, decisions, effective manager, error, expressive, fail, failure, failure-friendliness, grim necessity, implementation, improvement, incentives, instrumental, mandate, ngo, nongovernmental organization, nonprofit, nonprofit management, nonprofit programs, not an exact science, nptech, obstacles, organizational culture, outcomes, outcomes management, outcomes tracking, problem solving, process orientation, programmatic failure, programmatic outcomes, protocol, punishment, redux, revisited, success, techies, transparency, trouble-shooting, tzadik, upgrade, user