The disparity between the increase of community demands and the diminishing public
resources that are available to meet social needs have become conspicuous in many countries
around the world. This paradox has led to the propagation of projects utilizing public-private
partnerships. Public-private partnerships are able to combine the strengths and abilities of the
different sectors in order to meet the expectations of different stakeholders.
Aadhaar project’s history, including discussion of the social and political context, is
described above and in detail elsewhere (Khanna & Raina, 2012; Mukhopadhyay,
Muralidharan, Niehaus, & Sukhtankar, 2013; Sathe, 2011; Sathe 2014). Rather than restate
what has already been well documented, the authors frame the project’s history in terms of
key success factors and how well Aadhaar has lined up with Kania & Kramer’s (2011)
foundations for success in a public-private partnership.
Key Success Factors
In order for Aadhaar to be successful, challenges need to be overcome that can broadly be
placed into three categories (Khanna & Raina, 2012): organizational, technological, and
behavioral. Additionally, Khanna & Raina identified that an enrollment ecosystem, an
application ecosystem, and device ecosystem need to be cultivated (see Figure 2). While a
“perfect score” on every factor is not required, failure on any one factor could lead to the
failure of the project as a whole.
Aadhaar Partnership Ecosystem
Figure 2: The Aadhaar Public-Private Partnership Ecosystem.
Organizational Challenges
Nilekani was required to build an organization of almost 300 professionals, but faced
constraints on staffing and structure that a private sector leader would not typically encounter.
Roughly half of the team needed to be seasoned, public sector government officials because
their experiences navigating the bureaucracy in the government of India would be invaluable.
Since Nilekani was well known, it afforded him the opportunity to select officials from a large
pool of candidates who were relatively entrepreneurial in attitude and spirit. The other half of
the team was to be recruited from the private sector. Top talents, especially technology
talents, tend to have salary expectations that generally exceed that of government pay scales.
Therefore, Nilekani leveraged his network to obtain top companies to provide the talents he
needed, and arrange sabbaticals and other forms of paid leave to secure their services.
Once the team was established, UIDAI was faced with the challenge of crafting a
mission and vision for the project that would mobilize the critical mass of stakeholders
necessary to be successful. The more information managed by the Aadhaar system, the more
valuable it would be to some stakeholders. But with complexity comes a greater loss of
flexibility and increased concerns about privacy. Streamlined information capture would
alleviate these concerns, but would leave open the question of whether any stakeholders
would find it valuable. A balance across multiple dimensions of design had to be struck. After
extensive consideration, the final design choice was oriented toward the streamlined options.
Technological Challenges
The project entailed not just providing identification for individuals, but creating the entire
support infrastructure to issue, manage, and verify those identities. First and foremost,
residents of India would need to be issued their Aadhaar numbers. This required the
development of an enrollment process and the equipment to support it. Server-side processing
would be needed to prevent two people from receiving the same Aadhaar number or one
person from receiving multiple numbers. Mechanisms for eliminating duplicates and other
errors would need to be developed for instances where they may occur (for example, as a
result of off-line processing). Lastly, in order to be taken seriously as a form of identification,
a means of authenticating Aadhaar numbers “anytime, anywhere, and any way” would need to
be developed (UIDAI, 2014).
Behavioral Challenges
UIDAI needed to overcome several important behavioral challenges if it was to be successful.
The federated structure of the Indian government affords state and local officials a great deal
of authority and corresponding ability to resist national initiatives. Moreover, even if all levels
of government were aligned in their support of Aadhaar, there was no guarantee that anyone
would actually use it. As a result, there was no way to guarantee the widespread adoption of
Aadhaar numbers. Therefore, Nilekani sought an overarching design that people would want
to use, which in turn would promote avid and voluntary adoption of the new identification
system.
Value-added services were vital to the demand-driven approach that was the
cornerstone of Nilekani’s vision. Nobody needed an Aadhaar number simply for the sake of
the number itself. It was how the number would enable an individual that would make people
and service providers want to use the program. But a service providers’ willingness to invest
in integration with the Aadhaar system only went to the extent that they believed it would be
sustained. With new elections come new elected officials who could choose to eliminate the
program or change its focus. It is a major concern that, as discussed later in this paper, turned
out to be a very real one.
At the outset, there was potential for significant confusion about what an Aadhaar
number would do and what it would not do. In some cases, UIDAI needed to explain the very
concept of identity to people who had no notion or comprehension as to what individual
identity even entailed. Identity can be so closely tied to one’s social connections that
individual identity is a somewhat foreign concept. Where stakeholders have a preconception
of identity, they might apply it to Aadhaar. Wherever government officials, technology
providers, service providers, and the general public have preconceptions about Aadhaar, some
will be accurate and some will not; likewise, some will be favorable and some will not.
UIDAI needed to address the unfavorable preconceptions, privacy concerns, and the
general skepticism about the concept of identity. Some stakeholders were interested in
whether or not the number would confer Indian citizenship or grant aid and other social
services. Different parties took different sides on these issues and once again UIDAI had a
design choice to make. In the end, consistent with the simplicity of the data structure,
government officials decided that it would not be directly tied to either citizenship or aid; the
number would be tied to residency rather than citizenship. Aid agencies could choose to use Aadhaar as a basis for recipient identification and eligibility, but it was decided to not make
this a requirement.
Systems to be Cultivated
To facilitate overcoming the technical and behavioral challenges, UIDAI cultivated three
“ecosystems” of organizations and incentives that would drive the changes far faster than
governmental mandate could hope to achieve. First, a network of qualified enrollment
agencies would support an enrollment ecosystem. At peak enrollment, it was expected that
one million users per day would be enrolled. The challenge would be ensuring that
enrollments were all executed with appropriate quality and efficiency and without creating
opportunities for corruption to take root. Through a careful training and qualification process,
third-party agencies assumed the responsibility for enrolling residents and assigning Aadhaar
numbers.
The second ecosystem supported software application development. Banks, utilities,
and any other agencies interested in reaching India’s 1.2 billion residents could leverage
Aadhaar’s unique identification number as a basis for their own enrollment processes as well
as a file record field label that would facilitate the provision of services. By developing
applications integrated with the Aadhaar system, they would lower their customer acquisition
and ongoing operations costs while also creating value-added services that would encourage
people to sign up for and use their Aadhaar numbers. And with a single identifying number in
use across institutions, dramatic improvements in service and a reduction in corruption could
be realized. For instance, a government program could make an aid payment associated with a
particular Aadhaar number to a bank account associated with the same Aadhaar number,
thereby guaranteeing fast, efficient provision of the aid while also eliminating intermediary
steps and agents, each of whom present opportunities for inefficiency or graft.
The final ecosystem UIDAI cultivated was for the hardware devices needed to support
enrollment and verification procedures. UIDAI is a government agency and not a hardware
designer or manufacturer. Therefore, partnering with device companies was inevitable. But
rather than simply contracting first the design of approved devices, then their manufacture,
UIDAI set technological standards which allowed device companies to creatively develop
hardware, often in close support of Aadhaar-reliant software applications. Thus, UIDAI
turned hardware manufacturers into contributors to the overall Aadhaar ecosystem.
Foundation for Collective Success
The key success factors provide insight into what must occur in order for the project to be
successful. Kania & Kramer (2011) address a slightly different question: What conditions
need to be in place for a collaboration of any sort to produce true alignment and achieve
powerful results? They identify five such conditions: a common agenda, shared measurement
systems, mutually reinforcing activities, continuous communications, and backbone support
organizations.
Common Agenda
Effective collaboration requires partners to share a vision of what the project is trying to
accomplish. The more aligned partners are on the project’s ultimate objective, the fewer
problems that will arise during the implementation process. Partnerships are easy when
everyone wants the same thing, but collaborations are much harder when incentives are not
aligned. UIDAI crafted an expansive enough vision for the Aadhaar project that a broad range
of partners could share in its objective. Nilekani spent much of his first year or two traveling
around India to build that shared vision. By the time the launch of Aadhaar occurred, there
appeared to be widespread, though not universal, support for its vision. The more partners that
are involved in collaboration, the more opportunities there are for cross-purposes to surface.
The Aadhaar project involves a large number of collaborators spanning a diverse range of
characteristics. So while a common agenda was established, UIDAI will likely be addressing
alignment issues over time.
Shared Measurement Systems
Collective impact is difficult to achieve without a means to measure performance across
collaborators. For Aadhaar, the key overall operational metrics were highly visible and easy
enough for all partners to see: number of enrollees, enrollment response time, and verification
response time. Every partner was naturally interested in these measures and UIDAI measured
and provided them. Information about measures of financial and other non-operational
metrics is scarce, though one might expect the private sector contributors would press for
their inclusion in the project. Progress of on-going political support, perhaps one of the most
important metrics for a public-private partnership, is also not widely discussed and it is a
potential lack of support that eventually casts the entire project in doubt.
Mutually Reinforcing
Activities
Nilekani’s ecosystem-based design specifically involves participants in such a way that one
participant will support and coordinate with other participants. The number of partners active
in each ecosystem and the number of devices, applications, and related system outputs easily
measure the success of this design. Early indications were generally positive, with some
system elements showing mixed performance (Khanna & Raina, 2012).
Continuous Communications
One of the biggest challenges UIDAI faced was promoting cooperation and developing trust
among the various partners working on the project. Kania & Kramer said that “participants
need several years of regular meetings to build up enough experience with each other to
recognize and appreciate the common motivation behind their different efforts” (p.40). The number of partners involved either directly in the project or indirectly through the ecosystems
made it impractical to have years of meetings with even a substantial portion of the
partnership. Therefore, this aspect of the foundation for collective success was set to be a
challenge for UIDAI from the outset.
Backbone Support Organizations
Since the government of India sponsored Aadhaar, UIDAI was by mandate the backbone
support organization for the Aadhaar project. With a staff of less than 300, it could not be a
direct contributor of much in the way of project implementation. Instead, it was the designer
and coordinator of the project, responsible for planning and managing the project from
inception to rollout. Wherever support beyond UIDAI was required, other government entities
were tasked with providing it.
Continue Reading... Aadhaar: Outcomes, Updates, and Future Directions
