Applying the Agile Development Methodology to Funding: an open letter to Donors

I have discussed in my previous blog post the possible application of the Agile Development methodology to development projects, and specifically to ICT4D projects. Now the next question is, why is this methodology not being used, even if its value seems to be pretty straight forward?

One of the main problem is, according to me, related to donors and how the funding systems in the development community works. So, I would like to make this blog post an open letter to donoros, and would love to see some of them to actually think about what I am writing here and maybe start experimenting with new methodologies.

But let’s start from the beginning.

When big donors put out calls for proposals or expression of interests, NGOs and big organizations start putting in motion their “project proposal” design mechanism.

STEP 1: what do we know about the country we want to implement the project in.

When a call for proposal is out, most NGOs and organizations need to collect and gather as many information as they can about the country they want to implement the project in. Most calls for proposals in fact are specifically design to target predefined countries.

There are 2 possible options here: one is that the organization presenting the proposal is already in the country and has money already – to spend from its own budget – to do some comprehensive research, assessments and collaborative design with the beneficiaries to come out with a meaningful project proposal. This case is very rare. Assessments, research and collaborative mechanisms costs a lot of money, and you have to be willing to spend those money not knowing if you will indeed get the money to actually implement the project.

The second option is that you do not have indeed all those money and you may also not be permanently in the country. What you do in this case is to collect as much information as you can from there – partners and local organizations – and try to figure out what would make sense to do. This is often the case. In this situation, your project design is based mostly on assumptions and “second hand” information.

STEP 2: Deliverables and objectives.

The most interesting part of what I have seen so far in a lot of calls for proposals is that you are being told what is the problem that your project should address. In a lot of cases, not only you are told what the problem is, but also what the solution should be. Especially ICT4D projects tend to propose solutions or methodologies that are suggested by the donors. In a lot of cases, those topics and issues respond to political choices of the donors or to “priorities” that donors have listed and decided in advance.

Most of the time NGOs and organizations working on the ground know that those “issues” are not really the real issues – or should not be addressed in that way.

So what to do? They design projects that address the problem as requested by the CFP, so that in this way they are able to get the money that can allow them to also continue doing their work. This is basically a little game: applicants learn how to design a project that adresses gender based violence when the problem is actually an economical problem, how to design a project that address Open Data issue when the problem is actually governance, or how to design a project that addresses security when the problem is actually resilience.

STEP 3: Create your work-plan and the timeline.

This part of the project is almost always a completely random- guessed- almost completely invented part of the project design. Even if you are in the country, you do not know all the possible variables that could come into play, what could go wrong, partners that could not be able to deliver, beneficiaries that could not be at all happy with what you want to do once you start doing it. Even knowing at your very best the country and the partners in advance, and even with a solid participatory design process at the beginning, you can only guess at your best all those components of the project design. In addition to that, once you have chosen your activities and your work-plan, it is going to be very hard to change them in the course of the project. As well as it is very hard, if you do not have in advance money to be allocated to that, to actually use a collaborative process to design those activities.

STEP 4: list all the possible challenges that you can find and how you intend to address them.

Again as the section before, this part of the project is almost all a big guess. You guess what the issues you will face are and you also guess what the solution will be. Since you have not faced the problem already, you really do not know what the best solution will be.

What in fact happen is that once you have written those things in a project proposal and you get the money to actually implement it, you have some power to make changes, but not for everything. Normally donors accept changes that happen either without changing the budget or inside a certain range of budget changing. If you find out in the middle of your project that what you are doing is completely useless, or that the beneficiaries do not really like it and want to change it, or that you should be using a completely different strategy, it is normally very hard to change it without a laborious renegotiation of the grant or the risk to lose the grant entirely.

Mitchell Toomey wrote about this already a year ago:

” The traditional model of international development aid could be said to operate in a waterfall model – long term plans dictate specific requirements and success criteria, and these plans take a really long time to design, negotiate and agree upon. We often see that by the time a multi-year plan is finally signed, conditions on the ground have changed, and the agreed framework and reporting cycle is not responsive to the emerging development needs.

In a similar way, the long-term projects that are the foundation of traditional country development programmes are also designed and “fixed” in this long-term, highly documented way. In more cases than not, the original plan for how to design and execute a project needs to be revised and altered to fit with new conditions (regime changes, natural disasters, economic crises, famine, disease outbreak etc.).

The work effort that must be dedicated to administering and managing these highly scripted long term projects is significant, since the success of the entire enterprise is measured against the original design plans.

In a similar way, the procurement processes that a project manager is required to follow assume that long-term, detailed plans are not only possible, but preferred, so that very specific deliverables are identified long in advance and detailed, tightly bound contracts with partners can be drawn up and bid upon.

Of course, if you are a donor that is giving out a million dollar for a project, you do want to know what people will be doing with it, how and when exactly in advance. I do understand that. But how about we take a more “agile” approach also to grant proposals?

Here there are some of the suggestions I have, which for sure are not the golden key to solve the problem, but I believe can actually really help out in solving this endless issues with donors requirements and project efficacy:

1. Ask for methodologies more than for activities: project proposals should concentrate on the methodologies that organizations will use to decide, plan and implement their activities. We should be giving money to people that know how to do things, not that will do things just because they have the money to do them. The focus here should not be what activities you are planning to do in advance, but how you will use collaborative processes, agile methodologies and iterations to make sure that your activities do indeed make sense considering your objectives.

2. Ask for positive changes more than for deliverables. We should stop focusing on how many people will benefit from the project, how many workshops will be done, how many households will get aid and so on. We should focus on what is the expected changes that the project  is supposed to trigger. The activities to achieve those results may be changing and should be – if we follow the agile methodology we should iterate and continue adapting our activities to the situation on the ground. Deliverables end up most of the times as mere lists of numbers of people or activities, and much less as qualitative measurement of changes that the project is creating on the ground.

3. Ask for collaborative design approaches more than for “local partners”. Workplans that do not have beneficiaries as one of the stakeholders in a project should not be even considered. We are in 2012, I think that only stones by now do not understand how the partecipation of beneficiaries is one of the main factor that can make a difference between a successful project and a not successful one. Most of donors focus a lot on local partners thinking that this is the key to “beneficiaries” participation, but this is not the case in most of the places. The exclusion of local authorities, local chiefs, local communities is very much embedded in the fact that local partners is normally refereed to “institutionalized” local organizations that not always are the actual voice of beneficiaries.

4. Ask for business plans more than for budgets. Most NGOs and development organizations, not to speak about Humanitarian organizations, do think that they cannot and should not work with businesses and the private sectors. On the contrary, I think they should learn a lot from business. Actually they should have business plans in all their projects, and they should make sure that whatever they crate is 100% sustainable. I know that if you are doing a distribution of food, most likely this is not gonna be sustainable, but if you are doing education programs, protection programs and so on, you MUST have a long term plan, long term expected results that will make either your project not meaningful anymore – you achieve the goal so you are not needed – or able to continue without you. What you need to do is to create business. That’s what makes a project sustainable. not a budget. A business plan!

5. Fund assessments in advance. If you want a good project to be designed, divide your call for proposals in 2 sections: one is the preliminary assessment and the other one is the project design. Pay up front for the people you think have chances to win the grant to actually do their work in advance and do researches and assessments on the ground. Or, if you REALLY want to be serious: do the research and assessments in advance for them, get them the means to design and think about processes in a much better way. Be part of the collaborative process in a meaningful way. Chose with them the problem and the possible solutions and not the contrary. Unless you have an ongoing presence on the ground most likely your vision of the problem and the issue is not that accurate.

6. Ask for real and independent M&E and not quarterly reports.  I know how much big donors like fancy quarterly reports, with pictures and “catchy” quotes and cool graphs. Those reports takes time to be made and can tell you everything and anything your grantee wants you to believe (apart from the fact that we all know, almost no one reads them). This is how it works: everyone knows about how stupid this practice is and everyone plays the same game so that everyone is happy. NGOs and organizations on the ground spend an incredible amount of time preparing those reports and they take this time of the actual project implementation.

If you really want to know what a project is achieving or not on the ground, pay independent, ongoing M&E teams, that follow the development of the project and that can tell you what is going on without having to bother the people actually doing the work. A project is not just the numbers and the fancy pictures in it, a project is the actual daily implementation, the little challenges of the day to day work. On going monitoring is super costly and normally the budget allocated to it is very little. M&E should not be a side part of the project, they should be the entire base of the project.

I know: what I am proposing here is not that easy. But I believe it is easier than continuing throwing money in the bucket making the work of NGOs and agencies on the ground difficult . Organizations are forced to be part of this system to be able to get the money to survive, while they know that they will end up most of the time  implementing projects that are meant to fail.

In today’s world we have the means to change the way we do things to make sure we are accountable and we deliver meaningful and sustainable projects. I am sick of sitting down with colleagues and hear discussions about those same very problems over and over. I believe that no one working in the development and humanitarian world will find any of the issues listed in this blogpost new. We all know what is the game we are all playing. Then we should just change the game. We should get serious if we really want to achieve changes. And we should start getting some serious accountability based on real measurement of achievements and not on fancy pictures on a quarterly report.

Gallery | This entry was posted in Humanitarian Affairs, ICT4D. Bookmark the permalink.

8 Responses to Applying the Agile Development Methodology to Funding: an open letter to Donors

  1. Pingback: Should ICT4D Be More Agile? | Laptop Burns

  2. Tony Roberts says:

    Anahi I have put the link to that research in this reply to your blogpost
    http://laptopburns.wordpress.com/2012/08/30/should-ict4d-be-more-agile/

  3. andydearden says:

    Anahi, that certainly sounds about right. I see your discusssion with Tony about monitoring and evaluation (it needs to be independent, and it needs to be deeply participatory).

    I really like your points 3 (supporting iterative processes) and 5 (funding initial assessment activities in advance).

    I am currently in a bidding process for some funds where we will have one block of funding to evaluate a situation and co-design a project with beneficiaries, and then (if our co-design is deemed reasonable), we will have a very high probability of securing funds to do the project. We hope that this will alllow time for network building, exploration and iterative design, before we start using up the larger resources. I think this has a much greater chance of addressing real needs.

  4. Totally agree. It’s discussed almost exactly the same thing (though not as well put) with OCHA two months ago. We still follow the waterfall methodology when what we should do is agile implementation. I think this is even a problem in many in-house ICT projects in the non-profit world: Because it’s so hard to get a budget approved by the board, people tend to write unrealistic project proposals. In my experience, this is not even primarily to justify the *amount*they are asking for, but because they know they can only approach the board every other (or so) budget cycle. So instead of starting small, then evaluating the situation and then coming back to the board (rinse and repeat) you try to get everything in at once.

  5. Thanks Anahi, it would be great indeed of CFP were offered in this way, would make so much more sense, at Butterfly Works we made a video about co-creating digital development projects, http://vimeo.com/42137096
    and Andy, I’d also be interested in the process you describe.

  6. Thanks for this awesome post. With regard to your step 5, funding assessments in advance, you might be interested in the engine room’s TechScape assessments: Would love feedback on the project. Link: https://www.theengineroom.org/projects/techscape/

  7. Pingback: On the Meedan Radar – November 2012 « Meedan.org

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s