Let us know what type of content you'd like to see more of. Fill out our three question survey.
Changes in Open-Data Policy in Global Development are a Game Changer
Jul 3, 2019
You saw it coming. You’ve been collecting geospatial data on your projects for years. Maybe uploading it to a faraway server or sharing it with local partners…or stashing it away on your laptop or external hard drive. But no one else was ever able to use it. And you were sort of irritated that you had to ask a million people for the same data every time you started a new development project in a different country.
Now someone has done something to fix that. It may take a bit more work to prep your data. You may need to think more about how you document it, where you store it, and how you report it—but at least we can stop reinventing the wheel. And, you are helping improve humanity. One shapefile at a time.
Picture from pxhere.
In case you aren’t familiar with data policies of the U.S. Agency for International Development (USAID), the important one to know about in this context is ADS, Chapter 579. The Automated Directives System (ADS) simply refers to the policies and procedures that guide USAID’s programs and operations. Launched in 2014, it is USAID’s nod to federal open-data laws providing guidance on data sharing for contracts and cooperative agreements. It also established the process for submitting this data to the Development Data Library (DDL). Last July, USAID quietly released an update with new supplemental and additional resources for geo-located data. These have the exciting names of 579 SAA: Geographic Data Collection and Submission Standards and 579MAB: Activity Location Data. The short version is: All activities and programs will require activity location data, and that data will need to be reported to the DDL.
5 Ways This Will Change the Way We Think About Our Data
1. Others have already collected the data you need, and it’s (hopefully soon to be) available—The ideal situation coming from these new regs is that with all this great collecting and reporting comes sharing. So, in theory, down the line, we will all benefit from USAID’s investments and stop reinventing the data wheel in every country. This will be especially meaningful for countries with a large USAID presence where many partners operate.
2. Metadata Rules—No, really, there are now rules governing all the metadata for the features you are collecting. While in some cases these can be a little prescriptive, they also provide clear and concise standards beyond just what datum to collect your lat/long!
3. Building infrastructure from within—In producing these standards, USAID is taking a step toward centralizing country-level standards, which is super exciting! Missions will now be able to provide guidance on which datasets to use locally within a country so you don’t have to decide which of the five agencies you should get your admin boundaries from, or which one is the “correct” authoritative source. While these new regs don’t explicitly lay out this guidance (yet) they do put the onus on Mission staff to help guide in this process and suggest that local authoritative data should be used when possible.
4. Data protections are balanced with data sharing—The guidance on identifying data risk is very clear. Data risk is explained and there is a lot of detail on how to evaluate and mitigate risks. So, though the intent ultimately is to create a greater avenue of data sharing, USAID has identified ways to safeguard and secure sensitive data as well.
5. We will have to think about our spatial data—While this sounds obvious, spatial data is rarely included in our organizational data architecture discussions. It’s often seen as an “implementation activity.” Unlike monitoring and evaluation results data, financial data, or other project deliverables, it is rarely thought much about…unless you are the GIS Specialist. This should change as companies realize the implications for compliance, and the need for better spatial data management.
What Challenges Will We Face with Implementation?
-
Not all datasets are equal—why treat them like they are? As the regulations currently stand, we should be reporting everything. In some cases, we need to be reporting all the datasets used to derive the layers we use in our findings or maps so that the analysis could be replicated like a scientific study. This could literally mean uploading hundreds of layers to the DDL. We should be reporting activity locations for every event. Every activity. EVERYTHING. The amount of time and management this will require is daunting and it seems unlikely that this is the spirit with which the reg was intended.
-
Costs for all this new managing—This is going to cost implementing partners extra money to manage. Full stop. While it is an allowable expense, there would potentially be competitive reasons to eliminate these costs from any proposal budget. Clarity from USAID on this would be helpful for all implementing partners since a level playing field would benefit the ability to comply with the changes.
-
Assumption of data literacy where it may not exist—These changes will require a real culture shift in how we think about and manage data. The regs set high expectations on data management, but the realities within Missions and local partners are that data literacy is sometimes a struggle.
Why it Could Be Great
Imagine a new project is starting up in Country X. Your team is preparing the workplan and starting activities. You search the DDL and discover several reliable datasets submitted by another USAID partner in the region. In talking to the Mission, you realize they have established a platform to host and share data locally. You are excited because these 30 minutes of searching just saved you months of discussions and back-and-forth emails. You hit the ground running, and you have the standards needed to add your own project’s contributions to the mix. We are not quite there yet, but these new regs open up a world of possibilities for what is to come for spatial data down the road.
Carmen Tedesco is the Data and Technology Lead for DAI’s Managing for Development Results team.