stakeholder-experiences.md

Stakeholder Experiences

Introduction

\

“Around the world, over 1 billion people are invisible, living without a legal identity.”

\

The importance of having a legal identity is undeniable, and well understood by those working for child protection and economic development. The digital transformation of civil registration introduces the need for systems that protect the confidentiality of a country and its citizens. Deploying the infrastructure and software requires an orchestration of stakeholders.

\

This study included conversations with a variety of stakeholders who have been involved in engagements to deploy digital systems or to advise on their expansion. The interviews used the lens of the stakeholder experience to discover decisions made during deployment processes, challenges and concerns over threats to the system’s success. This report surfaces key findings.

\

Stakeholders

In any effort to build, implement, maintain, or improve a digital system, a variety of stakeholders will be involved. For efforts to digitize civil records, the government generally leads with sponsors, advisors, and technical support providing guidance, funding or loans, and services.

\

In countries where UNICEF operates, these CRVS digitization efforts are closely linked to the Child Protection programmes; as civil registrations are a key aspect of ensuring children have a future. It was clear from the research that UNICEF has a strong reputation and is a trusted advisor to governments.

\

We’ll divide our understanding of stakeholders into the following categories:

1. Government
2. Technology
3. Advisory
4. Workers
5. Citizens

\

1) Government
Each government has its own structures and departments that will be involved in CRVS digitalization. Depending on the country, different departments of a government or ministry will be engaged. Government stakeholders that may be involved include:

• Civil Registration Office
• Ministry of Home Affairs (or Ministry of Interior)
• Ministry of Health
• Digital transformation unit
• Ministry of Technology
• Department of National Statistics
• Newborn programs
• Municipalities
• State directors

\

2) Technology
Depending on which technology decisions are made or platform and vendors are selected, the stakeholders in the technology portion will vary. For example, if a government is building a system from scratch, they may hire a 3rd party software development team to build it, then move the project to their in-house development team to maintain. Other governments may choose to use a digital public good, like OpenCRVS or DHIS2. If this is their starting point, their process and partners will look very different. Technology stakeholders that may be involved include:

• Internal development teams
• 3rd party software companies
• Implementation coordinator for the technology platform
• Technology platform’s community of developers
• System integrator
• Green developers

\

3) Advisory
Several stakeholders fall into an advisory role to the government. This category includes UNICEF staff, along with other (civil) organizations that can provide guidance or funding.

\

UNICEF stakeholders include:

• UNICEF Country Program Officer (Child Protection)
• UNICEF Regional Program Officer (Child Protection)
• UNICEF Regional T4D Manager(Technology for Development)
• UNICEF Social Policy
• UNICEF ICTD (Information and Communication Technology Division)

\

Child Protection and Social Policy are the 2 main custodians of CRVS on UNICEF projects. They are at the forefront of the process in interactions with the government. Technology for Development (T4D) typically gets involved later in the process after the Terms of Reference (TOR) is established.

\

Other advisory stakeholders may include:

• World Bank
• Plan International
• Vital Strategies
• UNICEF’s Office of Innovation (OoI)Innovation Office in Sweden
• UN ESCAP (Economic and Social Commission for Asia and the Pacific)
• Business Analysts

\

4) Workers
The individuals responsible for recording the registrations and vital statistics are key stakeholders. These people are unique in each country, but can include nurses, community health workers and tribal chiefs. In their user documentation, OpenCRVS maps out system roles. They include:

• Field agent
• Registration agent
• Registrar
• National registrar
• Local system admin
• National system admin
• Performance manager

\

5) Citizens
Digitization documents the people living without a legal identity, as well as those who are registered in paper systems. They include parents of newborns, immigrants, individuals living in urban areas, families in remote villages, and the list goes on. The situations and reality of citizens varies vastly and affects their ability and motivation to register.

Experiences

Every engagement looks different. In this section we’ll cover:

• Sample Engagements
• Experiences With Government
• Challenges That Persist
• Insights

Sample Engagements

Every engagement looks different. The samples below illustrate how engagements to consult with governments on CRVS digitalization can look.

Nepal

The system in Nepal reflects a slow movement toward digitalization by the government over many years. Built from scratch, a trusted vendor developed during a time that predated the Digital Public Goods movement. This evolving development of digital systems is true for many countries in South Asia. UNICEF’s Child Program in Nepal began to provide support several years after the system was developed. They were brought in to help expand coverage. They have helped the country make decisions on interoperability. They have assisted with: developing data standards, integrating CRVS registration with the health system, and solving problems that come up as coverage expands to make registration quicker and easier, especially for citizens living in the mountains.

Nuie

The establishment of a system in Niue also reflects a process with history. One that is relational. Between people. Prior to 2020, the founders of OpenCRVS were engaged in conversations with the individuals that would later pioneer the implementation of the open-source software, and the CRVS infrastructure in the country. OpenCRVS worked directly with the government through all phases of implementation. They led with an agile process, adapting to new needs and defining requirements as they saw how the system performed among the people. Local implementers integrated the open source code into a fashion that built an in-country, secure, confidential system for collecting, storing and accessing citizen information.

\

Experiences With Government

Research participants reported that working with governments can be quite comfortable. Here are some of the reasons, or rather factors, that contribute to this feeling and ease:

• When there’s buy in and coordination from all levels
• When the civil registration department is directly involved
• When there’s good, trusted relationships
• When expectations on the process and timelines are aligned
• When there’s a framework for influencers and advisors to be involved in strategy and future planning. A task force provides such a framework.

\

In some cases, working with the governments is not comfortable, or easy. Generally this is due to poor coordination, beyond the control of advisors. Processes and systems suffer from uninformed decisions, decisions driven by personal motives or different values, decisions made under the pressure to get numbers on a short timeline, or decisions made without the perspective of critical infrastructure expertise or that lack the foresight and vision that conceptualization and user research brings to the effort.

\

“There’s always pressure on pace.”

People operate with the mentality that they’ve been given an order and need to get it done.

\

Three government norms showed up as themes in the research:

1. Pressure (time, budget, tiny teams)
2. Turnover
3. Lack of agile thinking and software development practices

\

Challenges That Persist

Regardless of whether the experience with the government has been comfortable or difficult, the same challenges exist in many CRVS-related processes.

Specifically:
\

1. Knowledge gaps
   This speaks to the need for both capacity building and integration of the right expertise at the right time. The section below expands on the challenges faced.
   \

2. Lack of policies or adherence to policies
   It’s common for governments to have policies regarding infrastructure and data privacy in place. Oftentimes, they are not adhered to. It’s also common that a country lacks policies on e-governance and privacy legislation all together.

Knowledge Gaps

The stakeholders making decisions need subject matter expertise. The current gap in knowledge leads to decisions that can create problems or limitations in the future.
\

“[It’s challenging] if governments already have an idea and it’s not necessarily an informed decision [...] or it may be informed by different criteria.”

• “Often you’re working with people who don’t understand what it means to develop a product technically. Even if they say they understand the process you teach them, that understanding doesn’t always materialize. It’s difficult to educate people on the process.”

\

Subject matter experts are needed. Critical infrastructure and business analysts were two of the knowledge experts mentioned in the research.

\

“The in-house team doesn't have a business analyst. They don't speak business, and can't ask the right questions. For example, they will connect two systems without asking what the future of this is. A lot of them have not worked in the subject matter.”

• “The people with expertise in critical infrastructure are not doing this work. Rather people that lack the know-how and skill.”
• “Companies come in and do a pilot. Then it’s scaled. But it’s not considered as critical government infrastructure. And thus, not treated as such.”

\

Depending on the country and the system they are using or building, the developers and specialists writing the code and setting up the infrastructure vary. In some cases, the implementers are simply not the right team. They lack the experience or required skills.

\

“Implementers are not always the right team.”

• “Not a lot of people are willing to work for the government, so it's difficult to get talent. Good vendors often don't work with the government.”

\

There are several initiatives to build capacity among local developers. Participants mentioned that working with green developers requires a lot of time, and emphasized the importance of having realistic budgets and aligned expectations on time.

\

“It takes a lot of time to build capacity; and therefore the budget for it.”

\

Turnover in government and on local development teams is common. You could have one person in government that knows everything, then leaves.

\

“As soon as people get skills, people leave and get a better job to get paid more.”

\

Insights

1. Missing expertise: Many times the people that need to be involved are not involved at all or until it's very late in the process when decisions have already been made. Business analysts and critical infrastructure expertise were two mentioned in the research.
2. Need to understand local context and people: When designing service delivery models, training and change management, stakeholders need to understand health workers, community leaders and others that could be working in the field as registrars. Here’s a sampling of things to understand or question to ask: If you’re going to use health workers, how are you going to use them knowing that they are super busy? Have you been to the hospital? Do you know if there’s a charger? Is there wifi? If you need to use data, who’s paying for it? Which devices will be used? You will find health workers all across Africa with 4 different phones for 4 different projects. If using personal phones, how will you manage access?
3. Importance of enabling environments: Technology is the enabler. It needs an enabling environment. Change management, communication, and getting buy-in from stakeholders and end users are all factors that facilitate effective deployments.
4. Gender consideration: Every digitization project should consider the experience of female users. In several parts of the world, women have unique digital realities and often face greater limitations. The advice to always ask these questions was provided by a participant: What have you found out about female users? What did you do differently because of this?
5. Importance of interoperability: Interoperability was a recurring theme when discussing digitalization experiences. In some cases it’s been the reason why a technology platform is selected. In other cases, it’s been an important capability to add in order to make registering and updating vital statistics easier. There’s a need for data standards and interoperability with National Statics data.

Archetypes and Choice

CRVS advisors consult governments at different stages of digitalization. They can be viewed as three archetypes:

1. Governments with custom-built CRVS systems
2. Governments with no CRVS system
3. Governments that have a CRVS system that isn't performing well or requires new capabilities

\

The technology choices made will first depend on which category the government falls into. During this research, participants were asked why certain systems or approaches were selected by governments. Several that have been custom built are a reflection of the country’s move toward digitalization in an era that predated the digital public goods (DPG) movement. Other reasons for technology choices organize themselves into three themes: values, ease & interoperability, trust & confidentiality.

\

Values

• Choosing systems that align with the values of sponsors or advisors: Open source solutions have been promoted by UNICEF. Ara is supported by the World Bank.
• Not choosing systems that use biometrics

\

Ease & Interoperability

• Choosing a system that is already deployed for other systems. For example, DHIS2 is already deployed across Africa for health.
• Custom built systems also mentioned that as they expanded the system, it needed to be interoperable with the health system so documents could be sent automatically rather than by foot.

\

Trust & Confidentiality

• Countries that have selected OpenCRVS usually pick them because they’ve met or heard about them.
• Some people don’t want foreigners bringing solutions from the North. There’s also the mentality of “African solution for African problems” that is embraced by some governments.
• Some governments don’t want to expose their national data to anyone outside of the country. They want everything housed in the Ministry of Home Affairs.
• • “The government wants all details of citizens private and confidential.”
  • “The government did not want to participate in this [audit by an international team]. They said they were not ready to allow others to see it.”

\

Threats to Success

This section is an accumulation of insights that inform what could threaten the success of a system. It includes challenges stakeholders face, pitfalls that have sabotaged programs, and threats stakeholders are worried about.

\

1. Vendor lock-in: Locking into a vendor offering proprietary software can limit access to the system. Further, it can lead to very high costs to maintain and improve the software.
2. Data loss: Either due to vendor lock-in and entire generations not being accessible or due to written records not being digitized.
3. Not having buy-in: Where a project gets buy-in depends on the government structure. Having buy-in is important for success.
4. Expertise: Lack of expertise during planning and at key stages in development and improvements: The lack of involvement of critical infrastructure expertise, researchers and business analysts can result in decisions that result in limitations in the future.
5. Premature scaling
6. Poor planning: Poor planning for ongoing costs and support models.
7. Deployment: Poor planning for deployment, service delivery models and hardware: Understanding how registrations will be made, who will be responsible for getting them, their literacy level, and the constraints of the environment ensure that the system will perform well and produce numbers.
8. Lack of change management: People reject change. The added complexity in the environments that are digitizing is the lack of digital literacy, lack of trust in government, and lack of trust in a digital system. Effective change management knows the thoughts and mentality of users and how to best communicate to get them onboard. Without change management, people will end up not using a system.
9. Hackers
10. Evolving technology and threats: Participants recognized that any of the threats outlined during the interview were possible, even if they weren’t a current concern. Those threats include:
11. 1. Criminal hackers
    2. Someone inside getting paid off
    3. Government using data for oppression or genocide

\

Recommendations

As part of this project, guidance on conducting holistic security audits for UNICEF staff working on digital transformation will be delivered. Informed by this research, the recommendations below should be considered when writing the guidance. The section tips for the guidance may be also useful for other projects with a similar goal. The following recommendations relate to the guidance being provided by Guardian Project for UNICEF staff working on digitization projects.

Tips for Guidance

1. Emphasize the right expertise at the right time. After talking with stakeholders, it’s clear that digitization projects can look very different; no one adheres to a step-by-step process. Stakeholders need to be responsive to the decisions that need to be made in a specific context at a given moment in time. When providing guidance, organize information in response to the problem faced or decision to make. Consider including information about what expertise or skills are needed, who should be involved in advising or doing the work, and which critical infrastructure questions should be asked. The ‘topics’ list below highlights several parts of the process that stakeholders are making decisions around.
2. Make the content interactive. It could start with a problem statement. Like, which of these issues has your deployment faced? Or, what are you looking for today? Once they make a choice, it can give them a heads up on what they might need. For example, if they are looking for tips on hiring technology vendors, it could provide information about what they need to think about (budget, qualifications, contract terms).
3. Remember the audience. Child Protection and Social Policy are the 2 main custodians of CRVS on UNICEF projects. They are at the forefront of the process in interactions with the government. Technology for Development (T4D) typically gets involved later in the process after the Terms of Reference (TOR) is established.

\

“I was there to interface between the government and also the vendor. Then sometimes we will bring our regional colleagues, and we have a discussion about all of the system requirements.” — Country Program Participant

Be mindful of the resources that trickle down to program specialists or are given to them directly. The kind of information they need and language is very different from T4D. As an example, here is some insight from the program perspective: When asked to do a vulnerability test, these are the things that are helpful to know:

1. The type of person to hire
2. The expected outcome
3. How much it should cost

\

“We are not technology people.” — Program Participant

"You really have to understand who the audience is. If it's program people, you cannot expect them to digest something that is very technical from a pdf. It has to be interactive for them. It has to make sense for them." — Research Participant

\

Topics

These all reflect decisions that need to be made or parts of the holistic process that were mentioned during the research.

• Deployment planning: Service delivery, research, gender-informed design, training, change management, communication with government and users
• Hardware
• Ongoing Costs: servers, hardware, software maintenance
• Vendors: If proprietary software, skills, plan for support, managing turnover, working with a local implementation partner
• Implementation practices: Proving models to scale, working with dependencies, capacity building, upskilling IT departments, having critical infrastructure expertise (what are the requirements for this, what type of person needs to be involved early in the process, what knowledge base does this person have)
• Interoperability with the health system
• Data privacy (also referred to as citizen confidentiality)
• System security: Dealing with Russian hackers, staying ahead, access control
• Support models: for features, functionality, or upgrades
• Service delivery: Timely registration, simple process
• Increasing registrations: Expanding territory, making the registration process easier
• System performance: Is it performing well? Are we getting numbers?
• System assessments
• Data standards

\

Possible Intro Content

The purpose of the Introduction to Understanding portion of the guide is to show that we have done our research and have some understanding of the holistic processes, people and environments this guidance fits into.

• Positioning the guidance within the frame and initiative of digital public goods
• The different government digitization archetypes
• How the resources here are relevant for custom built systems
• • How audit fit in; which ones to run when
  • Ideas, values or checklists to be borrowed
• Link to research paper (TBD)

\