Governments across the world are adopting e-Governance. In each department and in each state government, one finds a plethora of IT projects in various stages of implementation – conceptualization, implementation, deployment and up-gradation to latest technology. One also finds many abandoned projects. For each successful project, one can count an equal if not higher number of failed IT projects.
A survey of e-Governance projects by a Professor in Development Informatics in the University of Manchester in developing and transition economies revealed that as many as 85 percent e-Governance projects are either partial failures for not having attained all the intended goals, or total failures- having been abandoned soon after implementation.
The common reasons for such failures include lack of internal ownership; absence of vision or strategy, poor project management, inadequate technological infrastructure, unwillingness to adopt IT enabled governance techniques and obstacles in transitioning legacy government data to a computerized format.
Traditional governance systems are usually not amenable to computerization, and insufficient business process re-engineering is also cited as a major reason for the failure of e-Governance projects. I present here some ideas for enhancing the success rate of e-Governance projects.
Think Big, Start Small, Scale Fast
Keeping it simple by taking baby steps is more likely to succeed. In other words, evolutionary ideas are likelier to succeed than revolutionary leaps. This is because of limited capacity of the government on the technological and human front. Therefore, e-Governance projects should build carefully and sustainably on the existing ICT usage base. Instead of directly trying to implement large scale process re-engineering and backend computerisation, the stages of e-Governance should be kept in mind.
In the first phase, e-Governance merely means a simple presence on the web which provides the public with relevant Government to Citizen (G2C) and Government to Business (G2B) information. In the second phase, the interaction between government and the public (G2C & G2B) is stimulated with various applications. People can ask questions via e-mail, use search engines, and download forms and documents, saving time and money. In phase three, complete transactions should be enabled so that they may be conducted without the citizen having to visit a government office.
Examples of such services are filing tax returns, extending/renewal of licenses, online application for visa and passports, online voting and e-procurement applications. Phase three is made complex because of security and personalization issues, such as the necessity of digital (electronic) signatures to enable legal transfer of services.
It is also the phase which requires maximum process re-engineering and change management within the government functioning. The fourth phase is when all information systems are integrated and the public can get G2C & G2B services at a single virtual counter. One single point of contact for all services spanning all departments which is accessible from the citizen’s home is the ultimate goal.
As we set out on our path of e-Governance,we need to remember that we should commence our projects from simple provision of information online, and slowly work our way towards the long term vision of a unified platform for e-delivery of services, for we must walk before we can run.
Avoid Big Bang Waterfall Method
Requirements for regular run of the mill projects in the IT industry are usually captured to the last detail in various project documents such as functional requirement study, requirement traceability matrix, high level design, system requirement study, low level design etc which are duly vetted by the client.
These requirements are then communicated by business analysts to the software development team so that they may translate the requirement into software, working peacefully in their zones of comfort. Once the development is completed, the client checks the software against the earlier documented requirements and acceptance testing is done. The project is thus rolled out as in a smooth waterfall model, without much change in requirements from one stage to the next.
On the other hand, adopting the waterfall method for e-Governance applications runs the risk of failure since this method is not capable to cater to the change in requirements and priorities, which is the rule rather than exception in the government setup. Government departments typically perform multiple functions involving complex processes. New tasks, schemes and projects are added ever so often.
For many functions, there are no documented standard procedures and processes. For others, the actual practice varies from one office to another even within the same department. Such continually evolving and non-standardized processes compound the problem of capturing and freezing the requirements for software development in a single cycle. Information/ requirements which were relevant at the time of initial study by the software development team may become redundant by the time the product is readied for user acceptance by the concerned department.
This would cause initiation of another cycle of study, documentation, development and testing, causing a hiatus in the project roll-out. By the time the next version of software is presented, the department officials may have lost interest or even more likely, priorities may have changed, especially with a new boss at the helm of affairs who would be keen to put his stamp on the project. This leads to an endless loop of requirement study and subsequent development- a sure recipe of failure.
Therefore, adopting the traditional waterfall method for software development within the e-Governance domain is likely to be time consuming, especially if application software is to be developed de novo or even if there is a commercial off the shelf product readily available.
Adopt Agile
Instead of taking years to completely automate all the processes of a department or an activity using the traditional waterfall software development life cycle, an agile methodology is more likely to succeed.
Agile software development is an interactive process that allows small development teams to develop software in a collaborative environment that is responsive to business change. Development is done in short iterations, each iteration adding incremental functionality to the software.
This methodology involves prototyping – the use of a working model of the final system, which users can see, comment on, and have revised before the final version is produced. This ensures that the design matches real user needs. It also provides the flexibility to quickly react to changes in the environment. From the government officials’ perspective, however, it needs greater involvement, commitment and focus on the working product.
The e-Mitra application software for the Common Service Centers and the LITES project (MIS for the Pending Government Court Cases) are examples of successful of e-Governance implementations in Rajasthan following the agile methodology.
Government procurement framework, however, does not facilitate adoption of agile methodology, since it is typically based fixed cost models. Rajasthan, as also some other states have found a way out for building software using agile methodology by getting work done on man-month rates, discovered through open bidding processes.
It is suggested that even in cases where traditional waterfall methodology is used, software can be built incrementally in stages. A related methodology is prototyping – the use of a working model of the final system, which users can see, comment on, and have revised before the final version is produced. Another recommended practice is piloting – implementing the e-government system on a small scale at a single site or office; learning and improving the system; and only then rolling out on a large scale to all sites. Adoption of these methods has been shown to increase the chances of project success.
Internal Ownership, External Facilitation Are Both Necessary
Because of their very nature, e-Governance projects need external facilitation and encouragement. In fact, an e-Governance project may not even be conceived without external support and encouragement. However, without ownership within the department for whom the e-Governance project is being implemented, e-Governance initiatives may never be successful. Not only should the strategic and critical components be decided by the internal users but they should take complete ownership of the project. Any project, IT or non- IT, is doomed for disaster if totally outsourced.
While the role of vendors in triggering the conceptualization of a project should be welcomed, it should not so happen that the government department loses control and the project is totally vendor driven. Private companies can definitely play the part of subject matter experts and update government functionaries with the latest technological developments and trends in e-Governance across other states thereby aiding them in conceptualizing and implementing IT projects. However, at the end of the day, it is the responsibility of the concerned government department to freeze requirements and specifications in keeping with their needs rather than in line with the features of COTS software.
It may be noted that the Government Department of Information Technology or e-Governance Societies and companies, which most of the States have established, in this sense, are also outsiders and cannot totally take over the role of the end user government department, when they are asked to implement a project.
The requirements of the departments are best understood only by internal department users, and so, a project executed independently by the state IT Company, Society or Department for another government department without involvement and ownership by the client department is also likely to fail.
The role of the State IT departments is to encourage and facilitate e-Governance and act as a change driver; establish the IT infrastructure including the data center, network and the CSCs for use by other government departments; build generic and application software for use by multiple departments; act as the technology consultant to government departments and build standards and meta data.
Top-down Approaches Are Likely to Result in Failure
After long drawn out consultations with senior officers of all involved government departments, we in Rajasthan built software for application for and delivery of various certificates – bona fide residence, caste, income, solvency, etc. Government orders were issued by the departments providing legal sanctity to these certificates.
The objective was to make available at the doorsteps of villagers digitally signed certificates through the CSCs so as to reduce the time and money involved in traveling to the tehsil office. The application was launched with great fanfare by the Hon’ble Chief Minister. It was expected that this citizen centric scheme would be demand driven as it would save not only money and time but also provide hassle free services to the citizens.
However, the scheme did not take off as expected even after a couple of months despite training and publicity.
A quick evaluation revealed that it had increased the burden of the sanctioning officers (the Tehsildars) as the process of affixing digital signatures was very slow and cumbersome. The application software was then improved to be more user friendly for Tehsildars and computerized issuance of digitally signed certificates quickly gained popularity, amongst both citizens and department officials.
An important lesson was learned in the process. The first attempt at the project – which took a top-down approach – was a failure. The second attempt ensured that the lower and middle level users were involved with the project. Their ideas were incorporated into the design, and the process of involvement also helped develop their commitment. Involvement of the lowest level of functionaries right from the beginning is essential for gaining the support of the users.
The Project Must Answer “What’s in it For Me?” for all Key Stakeholders
Key stakeholders – officers, employees, operators, users, citizens, etc – must support an e-Governance initiative. To garner stakeholder support in any project, it must prove advantageous to that stakeholder. Many e-Governance projects fail as the employees feel that their job is threatened or their position undermined.
While allaying such fears, the application software should offer benefits like reducing filing hassles or repetitive work. Benefit to the citizens, especially, must be kept uppermost in mind while conceptualizing e-Governance projects. If a project offers no or little utility to citizens, it is likely to die a natural death.
In other words, the e-Governance project must provide each stakeholder with at least some positive answer to the question: “What’s does this project have in it for me?”
Project Management Skills are Critical for Success
It is well documented that e-Governance projects have cost and time overruns. Very often, major risks and issues in the project are not addressed in a timely fashion. The end product is often not in line with the user requirements. Such phenomena point to poor project management.
It needs to be understood that project management is different from general management, especially so in the e-Governance arena. If a manager is managing his department well, it is not necessary that he will be a good project manager.
Use of project management software is recommended. Since knowledge of project management tools is limited in the government, option to use the project management software of consultants and system integrators should be explored.
Sustained Leadership is a Pre-requisite
Yeates, D. & Cadle, J. (1996) in their book Project Management for Information Systems differentiate between managers and leaders as follows–
“The difference between leadership and management was once summed up in the following way by someone looking out of our office window in Convent Garden in central London:
‘Imagine there’s a sudden power failure in the London underground rail system. The system halts and all the lights go out. In the central control room someone is marshaling resources, implementing the standby facilities, rescheduling the trains, calling the emergency services. That’s management. Someone else is walking along the darkened platform with a torch bringing a trainload of people to safety. That’s leadership.’”
e-Governance projects are complex; involve multiple stakeholders, many times interdepartmental; and entail re-engineering age-old governmental procedures and change management. They need effective managers as well as inspirational leaders.
Effective leadership is needed to ensure a strong focus while directing, pushing or encouraging the government officials in the implementation of e-Governance projects. Moreover, the leadership has to be sustained as these projects are long term. Frequent change in government functionaries puts e-Governance projects in jeopardy. e-Bhumi and Aadhaar based PDS system of Andhra Pradesh are but a couple of examples which have succeeded due to sustained and effective leadership.
L1 Based Selection May Prove To Be Penny Wise Pound Foolish
Much work has already been done across India in e-Governance. Wherever possible, don’t reinvent the wheel. Implementing a ready-made, tried and tested solution with minor customization saves effort, time and money. Rajasthan was able to quickly and successfully roll-out e-Procurement because it used the ready-made GePNIC solution developed by National Informatics Centre.
If ready-made software is not available and its development is indeed to be outsourced, one needs to think twice before choosing the L1 or Least Cost Based Selection (LCBS) methodology for selecting the software development company. This mechanism may be suited for procuring standardized items likely computer hardware, licenses for generic computer software etc.
However, it is not likely to yield the desired application software required for complex e-Governance projects. Software is an intellectual property, which cannot be developed by a vendor selected on cost considerations alone.
The quality of the software will depend on the quality of the software development professionals and the development and testing processes used by the vendor. A Combined Cost and Quality Selection method is, thus, highly desirable. Moreover, the technical scoring criterion needs to be appropriately designed. A criterion giving high weight to the size, experience and repute of a company may not suffice. The quality of the whole project team, the development methodology and the testing strategy and tools should also be scrutinized while evaluating the proposals.
Success entails 99%, perspiration 1% inspiration
e-Governance projects are not technology projects as much as they are governance projects. Indeed, the ‘e’ in e-Governance is only a small element. Getting the ‘governance’ right is the harder task as the road from project conceptualisation to implementation involves a multitude of tasks and activities including procurement, stakeholder management, process re-engineering, change management, training and capacity building, etc.
This requires sheer hard work and perseverance, motivated by a strong desire to serve the public and an unwavering commitment to improve governance.
