The recent overhaul of the electronic portal for income tax filings has been in the news for all the wrong reasons. Since going live more than four months ago, it has continued to be plagued by technical errors, prompting calls by taxpayers and the Union Ministry of Finance to have the problems fixed immediately.

Some even suggested returning to the old system. Infosys, the firm in charge of the final leg of the project, has faced strong criticism and taking cognisance of the difficulties faced by the taxpayers in filing returns, the deadline for filing of returns has been extended to December 2021.

One would imagine that given the established nature of the Indian information technology industry, such criticism where a vendor is severely criticised for failing to perform on a large public-facing project would be a rare occurrence. Unfortunately, time and again, we come across instances of established technology services firms delivering projects with plenty of teething issues.

For instance, Wipro faced similar issues while working on the Employee State Insurance Corporation and Tata Consultancy Services while building India’s passport project and the Indian Railways’ IRCTC website.

In fact, this is a symptom of a larger problem in the way in which large technological systems are built for the government in India. The problem begins with the complex nature of the tasks but is further exacerbated by the peculiar way in which the working styles of Indian bureaucracy interact with the rollout of a privately managed software systems development project.

It is less about technical competence or technological challenges and more about structural issues relating to who commissions and provides inputs in the creation of tech solutions and who ultimately uses it.

Finding best solution

The complexity starts with the articulation of the problem. Quite often the technical possibilities of what a project can or should achieve are only vaguely known. To articulate that vague idea into a formal “Request for Proposal”, as the government procurement system mandates, is where the first break from reality occurs. Given the limited technical expertise within the government system, often an informal articulation of how the system can be built is solicited from a host of software service providers.

Each one of them articulates a solution based on their unique strengths or past experience. In the interest of arriving at a “best solution”, disparate components of such solutions that independently appear useful are stitched together as the “official requirement” in the final Request for Proposal that gets floated. Often, the contours of a system described in the Request for Proposal are unfeasible, unrealistic or plain inefficient. The service provider that eventually gets the mandate to develop the system is hence locked into providing a system that will be hard to deliver.

While the project is on the ground and several components of the project are already underway, new requirements by the government continue to be added. This affects not only the pace at which the project can be delivered but also often adds to the unyielding bulkiness of the final software solution delivered.

The hoops jumped through to accommodate the additional requirements often disrupt the workflow and may (in some extreme cases) even compromise the architectural structure of the software. This change in scope of the project is most likely to happen when there is a leadership change in the government. Given the uncertainty this may cause for fulfilments of payments, private service providers are often unable to push back on the suggested changes.

Tacit knowledge

Another way in which the development of software solutions gets affected is by changes in leadership (both at the government and service provider end). It often translates into a loss of expertise and tacit knowledge. The knowledge that is often not amenable to being recorded in standard operating procedures and process documents and more susceptible to loss when individuals bearing the information move on.

Very often designed systems fail or are rendered unwieldy or complicated when tacit knowledge does not translate into the process flow of the system. Since these nuances are behavioural and implicit in nature, they are tougher to capture through a documentation process.

The only workaround to this is extensive user testing. Very often given the political expediency in getting the systems rolled out in time, grossly inadequate attention is paid to getting all relevant use cases to be tested by relevant stakeholders. Oftentimes the decision-makers during the software development process are not the same as the users or implementers. If testing does not include the ultimate users, the product inevitably falls short on the implementation end.

Way forward

In order to reduce the systematic issues in the software development process for the government bodies, a few measures can be taken. First, meetings should be scheduled at each milestone to discuss the achievements and the next steps to ensure transparency amongst multiple stakeholders. Second, a bottom-up approach needs to be implemented from the start of the process as it would bridge the gap between decision-makers and implementers.

In addition, once the software is ready, deployment in the real world should be preceded by mandatory and extensive field tests by all the stakeholders before the final deployment of the software. Third, cultivate technical expertise within the government to advise on digital systems with appropriate training.

Last but not the least, involve the academics from premier technology institutes with a deep understanding of enterprise systems at an early stage to understand the problem from a technical perspective.

Hemant Adarkar is a visiting senior fellow and technology advisor, Meenaz Munshi is a project manager – Data Governance Network, and Anushka Bhansali is an analyst at the IDFC Institute.