⇓ More from ICTworks

How DFID Does Development in a Principled Way

By Guest Writer on April 27, 2016


The Washington DC conference ‘Digital Development: from Principle to Practice’ was a great opportunity for organisations to compare how they’re delivering aid programmes based on the 9 Digital Principles.

There’s been a lot of interest in the Department for International Development’s (DFID) approach to digital and how we’re putting the Principles into practice. During my attendance at the conference I gave a lightning talk on our approach. In the spirit of openness, I’m sharing here the main points I made.

Good practice for digital projects

DFID is required by UK government rules to assure all digital and ICT spend. We’ve introduced a process where our programme managers come to us with their digital proposals. We then provide expert advice and support, prior to inception stage. This ensures that approaches are agile and designed around user needs, and that budgets are proportionate and flexible.

Two examples of DFID-funded programmes that follow the Principles are LEGEND, a project that will enhance land rights protection for vulnerable people, and NigeriaElections.org, the website that showed voter turnout at all polling stations and live election results.

We apply the Principles to the tools and services that we build inside DFID too, including the Development Tracker that was built in an agile way. It uses open data and is designed and around user needs. It’s open source and the code is shared on GitHub.

Getting the message out

It’s essential to communicate this message so we hold digital workshops for both our staff and our key suppliers to explain how we want them to deliver in a way that meets the Principles. There’s been a sea change in our procurement process regarding the delivery of the digital elements of programmes, with a requirement to adhere to the Principles included in the Invitations to Tender.

It’s taking time to bed in but so far we’ve had a favourable response to the Principles from our partners and suppliers. They appreciate our clarity in describing the way we want them to deliver, and they tell us that the Principles are in line with their ways of working and are good practice.

Key Principles for DFID-funded programmes

I recommend reading From Principle to Practice: Implementing the Principles for Digital Development. This excellent report has resources, case studies and insights from the community. While DFID supports ALL the principles, these three stand out for us:

  • Design with the user. The report notes on Principle #1 that “too often in the field of international development digital tools are created, or digitally supported projects and systems are designed, without sufficient input from the stakeholders whose engagement and ownership are critical to longterm success.
  • Understand the ecosystem — “to reduce duplication of effort, Principle #2 provides recommendations about how to ensure projects and programs are built, managed, and owned with consideration given to the local ecosystem.”
  • Re-use and improve — “despite a rich base of technologies available for use, too often scarce development resources are spent building new tools when instead existing resources could be adapted and improved. Principle #7 suggests how to avoid reinventing the wheel.”

Do leave your comments here. But better still, please share your ideas and case studies on the Digital Principles website.


Further info

My name is Frances Sibbet and I’m the Digital Service Lead at DFID. I advise DFID’s country programmes on digital delivery. We’ll publish our exciting new digital strategy explaining DFID’s ambitions in the summer.

This post was original published as Doing development in a principled way.

Filed Under: Funding, Thought Leadership
More About: , , , ,

Written by
This Guest Post is an ICTworks community knowledge-sharing effort. We actively solicit original content and search for and re-publish quality ICT-related posts we find online. Please suggest a post (even your own) to add to our collective insight.
Stay Current with ICTworksGet Regular Updates via Email

3 Comments to “How DFID Does Development in a Principled Way”

  1. Matt Haikin says:

    I was under the impression that DFID doesn’t support the “design for scale” because of the perceived tension between this and agile development principles (this came from one of your colleagues as well as from inference from other reading). Have I misunderstood this?

  2. Hi Matt – that’s a good point to discuss here.
    The Principles are guidance, not rules, so as a donor, DFID requires suppliers and implementing partners to set out their approach to each Principle. So if they explain to us why they wouldn’t design for scale initially, or they’d use proprietary software not open source in a particular instance as it’s better value for money, then we’d listen and discuss.

    Our view at DFID is that designing for scale from the outset is sometimes appropriate and other times not. If you design in an agile way around user needs, you won’t know at the alpha stage whether the solution you’re working on is suitable to scale up until it’s been tested with users (ie beta). You might have to throw it away and start again after doing more research. You’re just trying to solve a single problem at that stage. We wouldn’t want innovators and start ups to be hamstrung by thinking they had to design for scale from the outset.

    At the conference someone suggested this Principle could be renamed Design for Diffusion – then it fits well with the Principle of reusing and improving.

    It would be useful if as a community we devise some guidance or prompts on each Principle.

    I’d be interested to hear views from yourself and others on this.

    • Matt says:

      Not sure about the name ‘design for diffusion’ but i wholeheartedly agree with the way you outlined things above.

      I think a lot of seeming-disagreement between different players could be settled if people understood this nuance – for example “open source by default” doesn’t mean NEVER use, build or support proprietary solutions – just that you should have a good and clear reason to justify doing so!

      I agree that some guidance – epsecially on those principles which seem – at first glance – to conflict (like scale/agile), would be very helpful.

      Thanks 🙂