top of page

Data Driven Development Decisions

Mistake number one is calling it monitoring or evaluation or results. The data collection task is one that is integral to everything a development programme should be doing. You need to know what you don’t know, what you can know, and what you have experiment to find out.

Essentially, the job of a development programme aiming to stimulate systemic change, is to get one over on the system. Systems are pretty knowledgeable. Of all the things there are to know, they know most of them. You have to find out (or try to find out) something that it doesn’t know in a way that benefits the poor. That might be a business model that the system didn’t know was profitable, a function that the system didn’t know was needed to improve efficiency, or an input that the system didn’t know was more cost effective. One thing that systems – particularly in developing countries - aren’t that great at is producing and aggregating information into nice little digestible packages. So, in order to find the little nuggets of information that might allow you to change the system, you need to put in the effort – and that effort is in data collection.

Data collection – often presented in the guise of the misnomers highlighted above – should be integral to everything that a development programme does. Data allows you to decide what to do, determine whether what you’re doing is working, and redesign what you’re doing according to your results. Two further mistakes that development programmes make are key in this regard.

Firstly, people. Development programmes tend to recruit two types of people – development people and ‘experts’. Both may be valuable but neither are inherently so. Without an inquisitive mind and a willingness to learn, you’re not going to be able to reveal any information that the system doesn’t already know. Further, as both a development person and an ‘expert’ - whether that’s an expert in a sector, a country, or a technical solution such as mobile technology – you’re likely to arrive with preconceptions about the programme and what ‘should’ be done. Developing country contexts are dynamic and information can quickly become outdated. The fact that you’ve been working in an industry for four decades does not mean you’re best placed to produce new information on the ways it might be changed. The first task of any development programme should be to find out about the areas in which they’re working – who the actors are, where the actors are, what they do, how they interact. Sector experts may be able to use their experience to satisfy some of these information needs more quickly, but they should want to challenge their preconceptions and verify whether the information still stands.

Secondly, structure. Information is crucial to all aspects of a development programme, from operations and budgeting, through intervention design, and impact assessment. Therefore, inquisitiveness, and some of the basic tools to allow this curiosity to be satisfied, should be hardwired into the culture of development programmes. Setting an M&E function apart from the rest allows others within the organisation to think it’s ‘their job’ as opposed to everyone’s job. A programme monitoring function should be set up up-front and should act as an advisory to all others within the organisation on some of the systems and tools for data gathering that might be employed.

Ultimately, data collection and analysis should drive the decisions of all development programmes and the collection of data should be seen as one other core programme function. Those unable or unwilling to engage in data collection and learning have no place on a development programme.

 

* this article was originally posted on the Springfield Centre website

bottom of page