Applying the Principles for Digital Development to Real-World Challenges

It’s easy enough to talk about using the Principles for Digital Development (PDD). This set of best practices for technology usage, developed by donors, implementers, and stakeholders around the world, has been increasingly embraced the past few years and with good reason: they provide straightforward, intuitive guidance on how to choose and use appropriate technology to promote development objectives. It’s hard to argue with the ideas that technological tools should be designed with the user, that interventions should be built with sustainability in mind, or that it’s vital to protect users’ privacy and security.

But, what does it mean to actually use these principles in our work? In a practical sense, how can these guidelines help us make difficult decisions about technology usage, especially in insecure operating environments with limited connectivity?

To get a better sense of the real-world applications of the PDD, let’s consider a project that used them to answer some key questions that are common to digital development. USAID’s Promote: Women in Government (WIG) Project, based in Kabul, Afghanistan, has developed a customized management information system (MIS) that allows all staff to better track and manage project data. While building the MIS, the WIG team faced decisions that many practitioners will recognize, such as whether to buy or build a product, whether work should be outsourced or done in-house, and what functionalities are the most important. Here’s how they used the principles to guide their decisions.

Question 1: Should you buy, or should you build?

Especially for software applications, one key question is whether a project should use an off-the-shelf platform or build one from scratch. This is where Principle 2 — understand the existing ecosystem — is critical. WIG considered the local advantages and constraints that would affect the success of an off-the-shelf product, including questions like:

• What is connectivity like?
• How much training would an off-the-shelf product require?
• Are there data privacy or regulatory issues that are specific to the local context?
• What local actors would be likely to use the system, and how comfortable would they be with the off-the-shelf products available?
• How likely is it that the product will require customization to meet local needs?

The WIG team quickly realized that building a custom product made more sense. Because internet connectivity in Afghanistan is relatively slow, a platform based on a remote server would not have been able to effectively handle the volume of data required for more than 3,000 training beneficiaries and dozens of government partners. Furthermore, given that WIG’s beneficiaries are primarily women, there were additional data security concerns that required platform customization. And with a variety of local stakeholders, all of whom had different levels of technical literacy, having a locally-built solution meant that their tool could be designed for maximum ease of use.

Another principle they used in answering this question was Principle 3 — design for scale. In many cases, an off-the-shelf product can be easier to scale, as the technical “heavy lifting” is done by a vendor. In the case of WIG, however, it became clear that the cost of a software subscription and the need for ongoing feature modification made a custom-built product more scalable. By choosing an open-source platform, the team increased the likelihood that future developers could inexpensively update and maintain the product even after the project was over. This also allowed WIG to comply with Principle 6, which asks practitioners to use open-source technology when possible.

Question 2: Outsource or in-source?

Another question that often comes up in digital development projects, especially when a new tool is being built, is whether to outsource the work to a vendor or to do the labor internally. For the WIG team, one of the key principles to consider was Principle 1, design with the user. To work through this decision, WIG considered the following questions:

• Based on what we know about the users, how closely would a developer need to work with them to design the product?
• How often will the developer need to collect user feedback to continuously develop and refine the product?
• How easy or difficult would it be for an outside firm to get this information?

WIG leadership quickly realized that with MIS end users — project staff members — who had widely varying use cases and levels of technical literacy, any developer would need not only to be intimately familiar with the shifting priorities of a dynamic project but also work closely with staff on an ongoing basis to iterate on, improve, and expand the modular platform. It would have been difficult for an outside firm to gain that kind of user access given the realities of insecurity and restricted mobility in Afghanistan. Balancing cost factors, WIG recognized that these were all problems that an internal developer could easily overcome.

By building in-house, WIG was also able to emphasize Principle 4, design for sustainability. While thinking about local stakeholders who could potentially take the platform over, the team realized that they couldn’t know for sure that local partners would be willing to pay an outside firm to maintain the platform once the project was over. Recruiting a permanent, in-house MIS advisor helped WIG save on maintenance costs in the short-term and gave senior management the flexibility to choose open-source technologies that were widely known and easy to manage.

Question 3: Which features take the highest priority?

In order to design a platform that met the needs of as many people as quickly as possible, the WIG team kept in mind Principle 5, be data-driven. By looking at factors including volume of records, how many staff would immediately be able to use a given feature, and which processes were the most time-intensive, the WIG team prioritized the development of functions such as records management for training participants.

Prioritizing these features also required them to go back to Principle 1, design with the user. As WIG planned the development process, the team regularly met with staff members who would be using the MIS to get their feedback and solicit their opinions on which functions would be the most important to their day-to-day work. Understanding these priorities was essential to rolling out a platform that appropriately responds to project needs and facilitates workflow.

Data management is an essential component of virtually every development project. Across sectors — from health to conflict management — large quantities of data must be accurately collected, stored, and tracked. In low-technology environments, such as Afghanistan, this can present a significant challenge. WIG’s MIS shows that the Principles for Digital Development — far from being nice, abstract ideas — can be used to guide a wide variety of decisions, especially when the answers aren’t always clear. They won’t always provide the answers, but they’ll help you ask the right questions.

Digital development needs are highly context-specific. For WIG, which manages data for about 3,900 female interns during a year-long internship program, not only has building an MIS internally proved cost-effective, it has contributed to improved learning and adapting, simplified reporting, and facilitated job placement for women in the Afghan government.

Posts on the Chemonics blog represent the views of the authors and do not necessarily represent the views of Chemonics.