Why We Fail to Learn in Development

We monitor what works, and explain away what didn’t, but never think about truly monitoring and evaluating our failures to properly learn from them. Imagine the money saved on projects that do nothing if we focused equally on learning about what doesn’t work as we do on what does.

Why don’t we want to learn about our failures? Our preference is to sweep them under the rug. We feel failure gives development a bad name and jeopardizes future money from the donors who funded the projects that didn’t go well or failed outright. Ironically, rather than worry about one failed project giving development a bad name, we should be wary of the fact that not learning from the mistakes that were made is what will give development a bad name because we risk repeating those mistakes again and again.

It seems to me that when it comes to learning in development we have a very narrow view of what that means - specifically, good practices emanating from successful projects to be shared widely with other partners and potential beneficiaries. This type of ‘learning’ makes us look good. And ‘good’ is what we want.

Admittedly, who wants to talk about the mistakes that were made? No one, obviously. In the private sector and government, scandals erupt periodically about mistakes or errors costing millions that have been swept under the rug. ‘Heads will roll,’ and all that. Certainly, development organizations and practitioners fear the same. But should they? When actual theft has taken place, or there has been a complete disregard for the fundamental principles of development and human rights, then yes, they should.

However, on balance, development organizations and practitioners should not fear failure. Why? Because unlike government or the private sector, development is just a little bit different. Development aims to find solutions to complex problems and so risks need to be taken and untried approaches applied. A bit like a research lab, or the test kitchens of the world’s most famous chefs, there is no foregone conclusion when a development project is implemented. Failure does not necessarily mean mismanagement or corruption. Sometimes it does, yes, and there are consequences for that. But that’s a risk for any enterprise that is almost singularly human resource based.

The key to differentiating between a development failure due to mismanagement and due to approach is monitoring. You know, the actual going-out-there-and-talking-to-people part of the project management cycle. Regular monitoring using good indicators and appropriate data collection tools will give you a fair picture of where your project is heading…. and why. The ‘why’ is the most important part. If you’re reporting to your donor and say ‘This is happening, we weren’t anticipating it, but we’re going to investigate a bit further and try options a, b, and c to see if that makes a difference,’ I can almost guarantee that the donor will say ‘Ok, thank you for being so candid. Please keep us updated regularly.’ (Unless of course the desk officer is a true low life. But that’s also part of the business). Donors want to learn too. They invest time and money into understanding what works and where; what they learn from your project can benefit them elsewhere.

But if you try to use your monitoring data to paint a slightly different picture, that of a project on track and speeding towards the finish line, well, your donor, not to say your organization’s management, will be none too pleased. Trust me, I’ve been there. Reading reports from a project that read wonderfully, which I put on the back burner because other projects needed some trouble shooting and outright intervention, ‘At least there’s one project I don’t have to worry about,’ I thought. Right. The shock - the sheer horror - of receiving an independent evaluation of the project by the donor that needed to be colour-coded for senior management ‘yellow - not good, green - terrible, blue - best if you just skip over this part.’ It took more than one year to resolve the mess the project management team had made because they didn’t know how, or didn’t want to, read the changing political situation on the ground in a post-conflict region. It still stands out as one of the most stressful years of my career. I’ll be honest and tell you tears were involved. The donor was not happy - particularly when we figured out that the project team, in an effort to cover up the imminent disaster they had created, had lied to senior management, to the government AND the donor. New and extremely arduous quality assurance mechanisms were implemented, and donors invited along on quality assurance missions. The project team was let go…

I like to think back and imagine what could have been if the project team had said, even off the record, ‘Hey, we’re having a problem with this. The approach isn’t working since the provincial elections.’ I envision discussions with the donor about the fluidity of post-conflict contexts and the implications for projects working on reconciliation. I imagine a scenario where the donor agrees that a re-evaluation of the context and restructuring of the project is necessary. And I know the donor would have been appreciative of candidness over a cover-up. Imagine what could have been learned and shared with other such projects regionally and globally. Imagine what the project could have achieved rather than turning into a big waste of money, time and unnecessary stress for a whole lot of people.

Development is not a science, so failure is possible and probable. And to be honest, we learn a lot more from failure than we do from success. If the project I described had not encountered any problems, we would have done nothing more than pat ourselves on the back and probably produced some sort of ‘best practices’ report based on our own egos rather than any true understanding of the factors that were at play. It was a missed opportunity to learn about what can happen when government changes early in a reconciliation process…. Something that would have been far more valuable, indeed.