Understanding Agile in Development Cooperation

Development Cooperation is a large and diverse field. To meet the spending commitment of 0.7% GNI every year, EU member states and the EU Commission give more than 120bn Euro to projects that are classified as Official Development Assistance (ODA). ODA aims to promote economic development and welfare of over 140 developing countries that face a range of development challenges from access to drinking water and basic medical services to supporting the improvement of human rights standards. The sheer volume and variety of projects being implemented in those countries mean that there is an almost infinite number of challenges in terms of impact, implementation, and transparency.One of these challenges comes exactly from the sheer size of the development cooperation arena. On both donor (the organization giving the funds that are used for development) and beneficiary (the organization that gets the funds from the donor) sides there are many large organizations, which could be described as ‘market leaders’ in their own right, and that implement projects across many countries and often across fields of expertise. What all these organizations have in common is looking to achieve, and in particular, demonstrate results. The donor (e.g., the European Commission) wants to show that what they are supporting has a development impact, while the beneficiary (e.g., a large multinational CSO [Civil Society Organisation]) is looking to show that the work it is doing is in alignment with the donor priorities and that it is making an impact, making it therefore worthy of donor funds.However, the way that organizations often go about their daily business and getting results is something that the ‘for-profit sector’ is slowly moving away from. This is the idea that ‘unified’ organizational structures bring better results because they improve transparency and certainty. Unified structures mean template-based internal structures that have hierarchical or structural clarity as their prime purpose and vary little depending on project/product. In development cooperation, this is a symptom of two interconnected problems. The first one is to define every part of the structure and thereby provide certainty, while the second one is seeking (and failing) to define the exact flow of the project, also to provide certainty.The logical fallacy lies in assuming that certainty in structure plus certainty in project flow are equal success. However, focusing on command-and-control structures and planning everything in a field of work that to a large degree depends on so many external factors is impractical, time-consuming and non-responsive. The structures appear to be designed to fit formalistic and internal purposes of controlling and reporting, and following a set agenda, rather than being designed with adapting to different development environments and challenges in mind. In other words, defining structures and defining project flow don’t allow for change in scope to adapt to the circumstances. Moreover, even when change to adapt to circumstances is possible (more commonly within organizations) the required procedures take a long time and could mean that it is too late by the time the decision has been made. In the spirit of ensuring certainty through controlling and reporting, a good proportion of work ends up being reporting on work that has been done – i.e., not what we need to do it better and how we move forward because the focus is on the structures, instead of the impact.

Why Agile can help make the difference

In development cooperation, sometimes it is not possible to do the work in a particular context that you’ve planned to do when setting out the scope of the project, simply because the circumstances have changed. For example, there has been an unexpected change of government, and there is no possibility to start a litigation process that you’ve planned in the project for anymore. Instead, what you would like to do is help local organizations engage in advocacy work to start the process at a later time or consider changing the context (i.e., location) of the project. In both cases, you are looking to alter the scope.In practice, changing the scope of the project needs to be approved by the donor. The donor can be internal such as the Programme Head Office in a large CSO or an external institution giving funds. The process in-turn means that time is lost, while it is also uncertain that the change in scope will be approved. To overcome this problem a less rigid definition of scope at the start of the project needs to be considered; along with the ability of the project team to make the changes required by inspecting and adapting throughout the project. The objective is to ensure that overall goals and desired impact are clear and in stronger focus than fulfilling procedural demands of projects that have been set-out sometimes a year before the project even begins. The team implementing the project should instead be encouraged to inspect and adapt by looking to engage donors (as customers) and final beneficiaries (as users) at regular intervals. The donors themselves need to adopt a more flexible approach and be ready to act as partners that appreciate efforts of adapting to new environments. This is not to say that projects become chaos without a plan. To the contrary, rather than having a plan and following it, it is about constantly being able to plan to achieve your desired impact based on the input that you are getting from the world around you.Another example for the case of inspecting and adapting, thus keeping the scope of projects flexible, are projects where it is no longer desirable to do what you’ve planned out to do at the start. An example can be building up a network of organizations in a particular country that will form a coalition to support youth engagement. An organization has been granted a project to do this work, but soon after the start realizes that another organization is already doing this kind of work with the support of another donor. The outcome of this can be that the beneficiaries implementing the project do not inform the donor in the fear that one of the projects will no longer be supported. It could also be the case that both donors will decide the go their way regardless of funds being effectively wasted. The ability to adapt to changing circumstances and alter the scope of projects would allow for potential duplication to be recognized. The resources would instead be pooled based on a common objective, and a higher-quality project with more impact could be delivered.

You don’t deliver for donors, but the users.

Becoming agile gives organizations the ability to inspect and adapt together with those that support you as well as the people and groups you are supporting. Getting development right is more than writing a proposal, getting it accepted, following a recipe you have set-out, and reporting to your donor. It is about creating partnerships and engaging with your donor and in particular end-beneficiaries. The impact can be created by inspecting what you are doing and adapting to changes as you go, always with the idea of what is the change you want to achieve.Creating impact in development cooperation is not about writing a project and defining a goal; it is about the process which takes you to that goal. To start improving impact in development cooperation, we need to challenge the structures that prevent us from focusing on those for whom we do development in the first place.Foto: Pixabay