Aadhaar Project History


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.

Subscribe to this Blog via Email :