Better public procurement for IT in India

by Ashok Pal Singh, Karthik Suresh, and Susan Thomas.

Information technologies (IT) are now ubiquitous in government. The Government of India has more than tripled its expenditure in real terms on large-scale “mission mode projects” over the last fifteen years. Yet, we see persistent evidence of failures (see examples here, here, and here). Failures in IT services therefore affect not only convenience but also people’s ability to comply with the law. At the same time, there is a wide gap between contracting volumes and contracting capabilities in the Indian state. This makes government IT systems particularly vulnerable to changes in scope, features, and scale that may happen during the course of a project. These problems pose challenges for contract design through which this flow of change requests is processed by private vendors without exorbitant monopolistic pricing. IT systems are not one-off jobs that is akin to building bridges or even repeat jobs like purchasing medicines. This is a tricky problem to address.

In our new paper, Better public procurement for IT in India, we delve into three cases of large-scale IT projects in India — Aadhaar, Passport Seva, and MCA-21. We ask, what factors drive the performance of IT procurement by the Indian government? We answer the question by analysing the performance of contracts and the underlying factors driving this for IT projects using a contract life-cycle approach. This involves looking at six aspects of each project: (i) the vision, purpose, and objectives of the project which help the government write the specifications and delegate all the other aspects of the project; (ii) the project’s governance structure, (iii) the project’s contracting model, (iv) how each project dealt with change requests, (v) how did the project deal with closure and transition into newer versions of the IT system, and (vi) did the project reasonably abide by cost and time estimates.

Our general findings are that the Indian government finds it difficult to take on the IT project after the vendor has completed the contract. Further, the government is unable to communicate, handle, and account for change requests in IT projects efficiently. IT projects carry some level of inherent risk and they require some level of adaptive contracting. At the same time, government projects are conducted using public funds and there are rules against profligate spending. Therefore, IT contracts should be designed in such a way that they confine to the strictures of the rules on public spending, while at the same time they are flexible enough to allow the project managers to adapt to change requests, technological improvements, and other developments. On these lines, we suggest the following prescriptions:

• Restricting the mandate of the project to a single goal/ outcome when multiple goals conflict with each other.
• Sufficiently empowering the project leadership team in terms of skillsets, administrative competences, and spending capabilities.
• An inter-disciplinary team that can complement each other’s skills and allow for a space for deliberation, while also guarding against technological solutionism.
• Evidence-based decision making that follows the scientific process of discovery, evidence, and analysis.
• Government should take ownership of the project and use the services of consultants and experts for specific outcomes within the project framework.
• Transition management is as important as project management — a well-defined transition plan that is written into the project document for the first iteration itself.
• Government’s IT system should be available in the open source domain. There are significant positive spillovers when government IT systems are digital public goods i.e., open-source code on published websites which speak open APIs.
• Highly specialized IT projects are susceptible to opportunistic hold-ups and sunk costs. Bidders in India therefore tend to price these costs ex-ante i.e., by overstating the bid. This in turn incentivizes the government to use state power to pay only the marginal production cost to the bidder. As a solution, the literature suggests that the government “owns” the system/ asset.
• Contracts are differentiated on the basis of financial risks, operational risks, and ownership. In our view, the government should procure a working proof-of-concept, after which it can scale up the project.

Government IT projects can be thought of as being implemented in the following three phases: Phase 1 being the development of a system that demonstrates the proof of concept (PoC) ending in the delivery of a pilot implementation; Phase 2 where the pilot is scaled up to the state or national level; and Phase 3 where the project then moves into running an operational system. Successful implementations of public IT systems ideally are a mix of “make” and “buy” rather than just “buy”. Phase 1 should done through “make” — where the government itself builds the PoC and delivers a pilot implementation. Once the PoC is established, the IT system is like a well-defined product. With this in place, scaling up of the system over a state or the entire country can be optimally done through “buy”, where private vendors can be contracted to deliver on a clearly defined output.

Ashok Pal Singh is a retired civil servant who served in various positions, including that of Deputy Director General with the Unique Identification Authority of India. Karthik Suresh is Assistant Professor at the National Law School, Bengaluru. Susan Thomas is Co-founder and Senior Research Fellow at XKDR Forum.