Accelerated Development

Mistake #1: Writing a Proposal

For the last year I’ve effectively been working as a funder of NGOs and CSOs. Some of this is direct, through the mySociety CEE project, and some of it is more indirect, by giving advice to OSI on other project applications they receive. One thing I’ve learned in doing this is how much I hate reading proposal documents. I’d say at least 95% of the ones I’ve seen have been woeful. And I don’t mean that in a small way. I mean that most of them want me to pry my eyes out with a spoon.

Part of the problem is that I don’t speak NGO lingo. There’s so much jargon, and taking two paragraphs to say one sentence that my eyes glaze over almost instantly. I like things that say in plain language what you’re going to do and what impact you hope that will have. Proposals never do that. They’re much more convoluted, telling you in depth all the things you don’t need to know, and glossing over all the things you do. I’ve lost count of the number of proposals that even after a third reading still make no sense to me whatsoever.

When we launched the CEE project we tried to bypass lots of this by asking instead that people simply filled out a web-based form. In hindsight even this was probably a bad move. Instinctively I knew even back then that getting people to write long proposal documents was bad, so I tried to shorten that. But now I think that the whole approach is completely wrong. Instead, we should have asked people to show us version 0.1 of what they wanted to build.

Some people have gotten very good at writing proposals that seem plausible without actually saying anything. The trap as a funder is to simply project onto that what you think they should be building, and assume that that’s what they were saying they would. Forcing people to show what they’re going to build bypasses that completely.

But I’m not simply talking about building a prototype here. I’m talking about building something that’s actually useful, and launching it to the world. This forces you to work out what the key element of your project really is, and focus intently on building that. You’ll discover really quickly then whether it’s a good idea or not.

The beauty of the modern internet landscape is that you can often do that extremely cheaply and extremely quickly. Most NGOs can’t grok that yet, however. I’ve been involved with four Social Innovation Camps now, and they highlight this well. The basic idea is to get about 40-50 geek activists with a variety of skills together for a weekend, divide them into five or six teams and have them compete against each other to see who can build the best project in 48 hours. When we did this in Bratislava last year, part of the outcome was slightly hilarious, but very revealing. The event was co-situated with the CEE Trust’s Civil Society Forum event. Whilst everyone downstairs was pontificating on the future of the third sector, a bunch of people upstairs were simply getting on with building useful things. Then, at the end of the conference, the SICampers proudly presented what they’d created.

Some of the CSF attendees, however, simply couldn’t accept that the projects being demoed had been built in two days. That was so far outside their worldview that they simply couldn’t hear that. Instead they decided that the teams must have spent the last two days creating the presentations, relating to projects that they’d clearly been working on for six months or a year or more.

But the reality is that these days it’s often quicker to build the initial version of what you want than it is to write a funding document describing it.

Obviously, you don’t stop there. You iterate rapidly off this first version, learning from user feedback and usage patterns etc. where you can add the most value next. We’ll come back to some of that later in the series. But for now the message is simple: don’t spend your time writing about what you want to build. Instead, spend that time building it. It’ll help funders decide better whether to give you money or not, it’ll teach you much more about what you’re trying to do, and you might even find out you don’t actually need the funding anyway.

Post to Twitter Post to Facebook

This entry was posted in Abecedary. Bookmark the permalink.

2 Responses to Accelerated Development

  1. Joe McCarthy says:

    I like this idea of showing vs. telling, and building vs. proposing, and suspect the belabored proposal writing, reviewing and acceptance process is diminishing the potential impact in other realms as well, e.g., computer science research.

    I’ve just started reading Douglas Rushkoff’s book, Program or Be Programmed, and see this article as another strong argument for broader – and deeper – technological literacy.

  2. Pingback: Gode råd til udvikling | Hennings blog

Leave a Reply

Your email address will not be published. Required fields are marked *