Request for information on Admin Area Registry System - Government of Tanzania

[Eden Mathew]

Dear Colleagues,

The Government of Tanzania through President’s Office Regional Administration and Local Government (PORALG) plans to implement an Administrative Area Registry.  The purpose of the Administrative Area Registry is to facilitate the maintenance, continual update and accessibility of data (ie lists and boundary data) about administrative areas (eg districts, wards, villages etc).

 

The following are some of the features that are expected to be included in the registry:

Allowing for configuration of a complex hierarchical structure with different levels, and allowing for changes to that configuration over time

1.                   allowing roles-based updates of different data by different users (Government officials and institutions) in a collaborative way

2.                   incorporating tracking of real changes (for example splitting up or merging of administrative areas, creation of new areas, re-allocation of sub-areas to parent areas) over time,

3.                   allowing for and tracking corrections of errors, e.g boundaries

4.                   allowing recording of proxy boundaries while awaiting formally surveyed boundaries, with tools to facilitate drawing of those boundaries including overlaying and comparison with other available geo spatial data layers

5.                   allowing attaching of legal documents (PDFs,) to each administrative area

6.                   making the data and maps available via an online interface

7.                   making the codes, lists and boundary data available for other software’s to subscribe to via an API

8.                   Ability to read or create, export and import various geospatial vector data such as shapefile, Keyhole Markup Language (KML), GDB (File Geodatabase), etc

We are currently researching possible software platforms, tools and technologies which could be used to build the administrative area registry and would welcome your suggestions and ideas.

 

Your ideas/suggestions/information/recommendations   should be sent to:

yasint...@tamisemi.go.tz

mathe...@gmail.com 

 

Thank you in advance for your collaboration.

Regards 

[Elaine Baker]

Hello colleagues

I realised that the email settings for this group (which I have now updated) meant that many of you may have missed the email below.

Eden is working with the President's Office Regional Administration and Local Government (PORALG) in Tanzania, who are currently preparing to develop (with the assistance of software development organisations) and implement an Administrative Area Registry.

It would be great if this group of experts could help suggest technologies, tools and platforms which could be used during the development of the administrative area registry in Tanzania, which would support the kinds of features which Eden describes below.  You can either contact him directly, or post in this group if you think the information would be useful to the broader group also.

We have a great set of people in this group, and it would be good to get to know each other better.  To facilitate this, I have compiled a list of group members in this google sheet https://docs.google.com/spreadsheets/d/1b9HH3a1bVl3B3hnK5ChM1jypzpBdzpNfa53qI_NKWU4/edit#gid=0 - feel free to edit your own entry and/or browse the list to get to know other group members.

Best wishes

Elaine

[sva...@irex.org]

Dear Eden, 

Thanks for the opportunity to contribute to this exciting and important project. My suggestions are derived from experiences supporting data systems and tools related to health, water, and education sectors in Tanzania at the subnational and national level, with stakeholders including local and national government MDAs.

I frame my comments according to three sections: diagnosing why some digital platforms fail (so you can avoid these trappings); framing your selection process to ensure the final product is sustainable, lasting, and actually usable over time; and proposing some existing platforms or tools that could be re-purposed as part of the technology stack you will develop.

Diagnosing why some digital platforms fail (and how to avoid those trappings):

• Focusing on the technology instead of the ecosystem. The World Bank's 2016 World Development Report argued that most ICT and IT investments fail - or incur costs far beyond initial budget - because of an excessive focus on technology and an insufficient emphasis on what it called "analog" components - that is, offline components like training, obtaining user feedback, socializing and integrating the tool into everyday practice, etc. These costs are nontrivial. To mitigate this:
• Require the firm to propose a substantial non-technology budget for things like:
• Training different users on how to use the system
• Convening meetups and user feedback / design feedback sessions
• Communicating about the tools to different stakeholders (especially if it is a tool that could be re-purposed by others)
• Assume that less than 50% of the budgeted costs will be for the technology itself. The other 50% could include the above, as well as other tasks such as finding and cleaning datasets (a substantial effort that cannot be underestimated), launch and socialization events, etc. Evaluate with skepticism any firm that claims this is primarily a technology investment and whose proposed budget leans too heavily towards just the software.

• Sustained dependency on proprietary technology. When you select a firm or consortium to implement these TORs, consider the risks of choosing a vendor which offers a proprietary system or solution. A proprietary system or solution is one where elements of it - like its software code, for instance - are privately owned and held by the company that develops it. This can lead to various negative impacts for your team. For instance, "vendor lock-in" occurs when a company or vendor builds a digital tool or system, but then retains or closely manages rights to access, change, or manipulate parameters of that system even after the implementation period. For example, the codebase might be proprietary, so if you want to change a feature, you are required to return to that company to edit and update the code. This dependency can be time consuming and expensive. (It's important to recognize that no system is entirely proprietary or open-source. Most systems use a combination of proprietary and open-source tools. What's important is that key tools are open-source, such as the front-end web application, so that ). To mitigate this:
• Include in your TORs a "strong preference" for software and systems that contribute to a "public good", including for instance contributing software code to popular open-source repositories like Github so that others (including your team in the future) can re-use and adapt it (see open-source section below).

• Underestimating the different elements of the "technology stack". A tech stack can be described as the suite of digital tools required to make a system work. For instance, this particular system might require a database (to store GIS files), a file editor (to edit GIS files), a website application (to view/ interact with those files), and a server (to host all the content). Often, TORs for work like this focus mostly on only one layer of the stack (such as the website application or software interface), while neglecting to ensure that other layers are also clearly articulated. To mitigate this:
• Require the firm to work together with you to define the entire technology stack and how it will be maintained over time, particularly after the period of implementation. This could include server costs, equipment costs, maintenance costs, etc.
• Make an effort to understand the technology stack so that your team can engage critically with the firm as they develop it. Be wary that it might be in the firm's interest to convince you that the stack is too complex and should be left to the IT specialists to make technical decisions, but this sells you short: You can easily understand the basics and this will equip your team to ensure you get the maximum value from the vendor and from your important investment.

• Building custom technology when existing resources already exist. It is tempting - and alluring for some vendors - to build a bespoke, custom-made set of software for your needs. Of course, some degree of customization is always necessary. But if you invest in new technology when existing tools already exist, you lose the opportunity to maximize return on investment and spend your valuable money where it's most needed. To mitigate this:
• Ask the firm to conduct a landscape assessment of existing tools that could be re-purposed, to save you and them time and money. If they propose building new tools instead of existing ones that serve similar purposes, ask for a rationale.
• Use communities like this one (as you already are doing) to propose existing tools that can serve different layers of the "stack" referenced above, or to provide feedback on proposals from the implementing firm (see next bullet).
• Develop an "advisory committee" of interested stakeholders with technical backgrounds (perhaps this group is a good start) to provide technical input on issues like this. There is in Tanzania a community of public good technologists who would be keen to ensure that this investment has lasting impact for the broader public, and you can take advantage of them to lighten your load here.

• Prescribing all features up-front. Although you are an expert in your field, it is always likely that new features or requirements will emerge even through implementation. For instance, in two years' time, your team may learn that this system is so widely used and desired that even civil society organizations seek to use these boundaries in their work (such as a local media outlet creating a map of a district). So, you might want to build a new user profile (with limited permissions) for these kinds of users. But if you had not predicted this when developing the TORs, you will miss the opportunity to ensure that media organizations use approved and accurate local boundaries. Of course, this is just a hypothetical example, and you won't ever be able to articulate all potential features. To mitigate this :
• Require the firm to initiate implementation with a "Discovery" period, where they engage with potential users to understand the ecosystem over a period of time. The output from this period should be an "Initial Insights" report that proposes specific features or feature rounds (see "sprints", below) based on this period of discovery. This offloads the pressure from your team to predict all features in advance, while ensuring the requirements are grounded in real need.
• Require the firm to conduct periodic requirements-gathering and -testing throughout implementation, working in "sprints" instead of in one long production to collect feedback and new ideas from users. The firm must have capacity and familiarity with what is called "agile" IT development (in contrast to the conventional "waterfall" approach).
• Require the firm to open-source key portions of the system, such as the front-end web app. By publishing the code for others to re-use (and accompanying that software code with good documentation), then even after the period of implementation concludes, your team can use in-house talent or hire new resources to manipulate and add new features, to maximize the value of your initial investment.

• Assuming that open-source tools are cheaper or more sustainable. Although my recommendations above reveal my preference towards open-source tools, it is important to acknowledge that open-source systems aren't necessarily cheaper or more sustainable that proprietary solutions. For instance, open-source tools often rely on community-contributed software updates, and so if the community doesn't update the software, your solution could suffer. These tools also often rely on in-house or subsequent expertise manage and maintain the system, including costs associated with maintenance or hosting that other proprietary solutions might offer as part of a package. That said, there is a fundamental "public good" argument that suggests that contributing to an open-source community will help the chances that the system or tool can be adopted by other areas or communities at lower costs. To mitigate this:
• Write an "open-by-default" clause into your TORs, requiring all software components to be published under an open-source license (such as the MIT or GPL licenses), unless a valid case is made for keeping certain components proprietary. This case could be for instance related to costs of maintenance, quality of technology, etc. This approach ensures that you default to producing and using public good technology, while giving you the opportunity to get maximum value for dollar if and when a proprietary component or solution makes sense.

With these common challenges diagnosed and mitigation strategies proposed, please find below some general recommendations for framing your selection process to ensure you get maximum value from this investment:

• Require the implementing firms to espouse the Digital Development Principles. The Principles are a set of guiding questions to ask whenever developing a digital tool. They were designed specifically for the type of project you're exploring here by a global community of ICT practitioners. PATH endorsed these in 2016, and by ensuring your implementer knows and understands how to put these Principles into practice, you are on a strong start towards a good investment.
• Seek out firms with expertise in human-centered design. As mentioned earlier, building a tool that lasts far beyond the implementation period, that has a community of users within and across local governments, and that is actually useful and user-friendly means that you are not just doing a conventional IT development project. This is a design project, meaning that the ideal firm is one that understands agile methodologies (referenced earlier), user-centered design strategies (which can build ownership within organizations that adopt these tools, so that the technologies aren't abandoned after deployment), and open development processes. With this in mind, seek out consortia that offer both technology/IT skills as well as human-centered design capacity.
• Write TORs that are process-focused, not product-focused. Your current TORs below are a helpful start, but consider focusing mostly on the process that you wish the implementer to espouse when developing this system. Although I do not know how much initial research and "discovery" has already been done by your team, it is possible that by focusing on hiring a firm with proficiency in the right process, you will develop the right product in a last way. For instance, perhaps you can frame the TORs in the following way:
• Discovery:
• Interview and engage with potential stakeholders to identify different user types (Deliverable: three priority user profiles or personas)
• Stocktaking of existing GIS and admin boundary tools in the ecosystem, within govt and other institutions (Deliverable: Spreadsheet list)
• Stocktaking of existing GIS and admin boundary datasets, their custodians, their status, etc. (Deliverable: Spreadsheet list)
• Design:
• Conduct 3-10 feedback sessions with representatives of the three priority user types, presenting them with progressively more advanced mockups of the interface/system to understand how they engage with it and what features to add (Deliverable: User feedback session report and recommendations for review by your team)
• Creating a "user group" of power users within government - 2 or 3 champions who might use this often and seem excited, based on early feedback sessions - to offer quick, ad-hoc feedback on design improvements/mockups virtually (if possible; recognizing that this may be too aspirational)
• Deliver:
• Build a minimum viable prototype (MVP) of a system to collect early feedback as part of the Design process, and to test the feasibility of the intended technical infrastructure arrangement (e.g. hosting on local servers vs remote, cloud-based servers). Follow on this MVP with subsequent versions, each one adding new features based on design feedback sessions;
• Contribute open-source code to a publicly available code repository, accompanied with meaningful documentation for others to re-purpose downstream or develop derivative products;
• Train key users within government and other institutions on upkeep, use of the platform, etc.
• Create and execute a "sunset strategy" to ensure equipment, infrastructure, etc. are transferred to the appropriate local organizations if relevant.

Framing these TORs in this way might help offload the pressure from your team to articulate all requirements up-front while ensuring you are involved in a collaborative process with the implementer to define them on an iterative basis.

Finally, here are just a couple resources I'm aware of that could be useful or relevant to repurpose or leverage:

• I'm aware of two GIS repositories in Tanzania based on the Geonode platform, an open-source GIS content management system. Perhaps this tool could be repurposed for your needs. Geonode's API would enable third-party access to and innovation on the data, to ensure that other stakeholders use correct, government-certified admin boundaries consistently and correctly in their derivative products.
• OpenStreetMap is an open-source public platform that serves as a "wikipedia" of maps. Its data is open source and used by a wide variety of organizations, startups, and institutions seeking to access and use free map data. Although OSM itself is not an official source of data (anyone can edit its content), it is possible to repurpose its database/underlying engine to customize it for your needs (for instance, to enable local government staff to draw/edit boundaries collaboratively). 

Thanks for your time. I welcome the opportunity to discuss further and look forward to learning more as the project continues. Best,

Samhir