I first started getting excited about the possibility of applying lessons learned in silicon valley to the world of international development projects when I stumbled upon the blogs of Steve Blank (http://steveblank.com) and Eric Ries (http://www.startuplessonslearned.com) and the idea of the Lean Startup. The problems they described seemed to parallel a lot of what I was seeing in development projects in Ghana. I wrote about this briefly a long time ago in this post exploring the similarities between startups and development projects. At the time I mentioned a series of posts comparing the two, but never delivered. This is my attempt to get back on that train, which I’ll be tagging with #lean4dev.
Today I want to start exploring one of the ideas that Eric Ries writes and talks about called “achieving failure”. You can check out Eric’s post on the subject here: http://www.startuplessonslearned.com/2009/01/achieving-failure.html
While in a lot of ways the development sector needs more room for failure and the discussion of failure, it does not need more of this type of failure. Eric introduces the concept with this paragraph:
“We spend a lot of time planning. We even make contingency plans for what to do if the main plan goes wrong. But what if the plan goes right, and we still fail? This is the my most dreaded kind of failure, because it tricks you into thinking that you’re in control and that you’re succeeding. In other words, it inhibits learning.”
I believe this is also the type of failure that is the most wasteful for development projects. I would argue that it is also much worse in the development sector because these types of failures are never recognized as failures at all.
The basic assumption that underlies much of the way that many development projects operate is a two-phase design-implement model, much like an engineering project. This facilitates all sorts of things that bureaucrats love, with multiple bidders (and sometimes separate bids for the two phases), and a fair process that goes to the lowest bidder who can demonstrate they can competently meet the project goals. This process is great for engineering projects. It sucks for development projects.
Engineering is mostly science with a little art. A design can be made from day one, and based on experience and some critical thinking, there is a high likelihood that the design will be adequate and will succeed if implemented properly. This rarely if ever can work in the development sector. The nuance of human behaviour and changing environments means that a design can’t possibly be correct on day one. Even if a project is implemented perfectly to spec, it’s likely it won’t meet the objectives of actually helping people get out of poverty.
Compounding this problem is the difficulty of properly measuring success. Profitability on its own is not always a sufficient indicator of success in business, but it is at least a necessary indicator, and companies that are not profitable will fail. The basic measure of success for a development project is much less clear, and much more difficult to measure. Ultimately this means that development projects never “fail” in the way that businesses fail. A development project doesn’t depend on results for the poor to continue – the project is approved for a certain number of years and expected to implement until the money runs out. Of course there are mid-term reviews, and possible extensions, but it is the donor, not the beneficiaries who decide whether the project should continue.
All of this conspires to create a development sector that achieves failure over and over, in both big and small ways. The work gets done, boxes get checked and implementers trumpet their successes, but for your own sanity I wouldn’t ask the difficult questions about what has actually changed. Conferences achieve failure by bringing together academics, government workers and practitioners with no useful action or behaviour change as a result. Yet the conference is called a success based on participation and “fruitful dialogue”. Projects achieve failure by checking off the activities in their work plans and finding ways to appease the donors, without any lasting change for farmers. Individual trainings achieve failure by reaching the prescribed number of participants, but poorly targeting content and having no clear plan for measuring whether anything has changed in the real world. Exit surveys of participants always show positive feedback – unless your free lunch was of substandard quality or you didn’t provide an afternoon snack. As Dery explained to me after lying to a project a staff about the usefulness of a training in the village, “People want to come and do something good for us, so we can’t make them feel bad for trying.”
It’s hard to live in a city like Tamale without developing a jaded view of the development sector, whose branded vehicles choke these streets. There is another way. Ideas for dealing with these types of problems exist in many places. Design thinking, ideas from Lean Manufacturing and the Lean Startup Movement to name a few. There are plenty of people calling out the flaws in the sector, and some who are working equally hard for change. While there are days where I wish the influence of the development sector could be ignored, it can’t be. It is important to push for the changes that will see an industry that achieves failure more often than not become one that is able to deliver on the good intentions that are the foundation for its disappointments.