🔊 Take a moment and listen

Bhuwan Chandra Joshi,
Technology Architect UIDAI HQ, New Delhi

I began career with a PSU, BHEL, Haridwar in year 1999.I worked there for six and half years during this period I designed, developed, implemented and maintained many automation applications with various complexities. Development was completely in house, so we could start a project with a small informal meeting with concerned department and could develop complete application step by step in much iteration. Turnaround time was fast as one or two approvals were needed for whole process and there were no cost implications. So development was mostly a collaborative project between concerned dept. and IT dept. SME of concerned dept. used to become part of our team and remained available for any issue and consultation Roll out was easy as that SME used to work as an ambassador for our project. This approach was very close to agile where it was acceptable to have issues in different versions as issues were quickly resolved in next releases. Using this approach we had made quite successful application with various complexities one of them had same functionality as “Production Planning Module” of an ERP.

This approach worked for BHEL, Haridwar wonderfully well and almost every function even auxiliary services like canteen, dispensary, petrol pump, house allotment become online/automated. But the major limitation of this approach manifested when BHEL as an enterprise started integration of all core areas like material management, contract management, HR, Payroll etc. of various units. Due to lack of standardization and enterprise wise application guidelines, integration became a nightmare.

From BHEL where development was quite participative and continuous changes in the application were a constant feature, I moved to IBM where client did not interact with the development team directly and development was strictly against the sign off documents like Use case, design, Test Plan, Project Plan etc. Deviation from the requirements used to result in a change request. Processes were well defined and adhered to religiously. A lot of attention was given to requirement gathering, application design and following best practices of coding to ensure a scalable, robust and maintainable system. Another good thing was that maintenance was always a part of contract which used to vary from one year to many years. This used to give ample time for system to stabilize and contract to succeed.

But this model lacked customer’s direct interaction/participation in development due to which there used to be lots of surprises for customers as well as for us during first releases. In my project which was a large government project for an European country. In subsequent releases we decided to deliver iteratively and involve the customer in testing informally before production deployment. This resulted in smooth deliveries and increase in customer satisfaction.

My association with IBM lasted for four and half years then I moved to “Aadhaar” project and it has given me the exposure to e-Gov projects. I have lead three-four applications till now and except one all are now live and performing nicely. Aadhaar project is somewhat different to other e-Gov initiatives as in it application initiative is lead and owned by domain experts (Tech Architects, Consultants/Tech project managers).

But during these two years I found that in most of the e-Gov projects ownership is not defined clearly. Every project has an anchor mostly a senior government official. That official sometime has some domain expertise of that department but not always. So in most of the cases there is no SME of that area at customer level which makes requirement gathering very difficult and later acceptance of application. Projects having strong anchors sail through and the rest of them fail or not succeed as expected. So the project success is highly subjective.

The root cause of the failures are ambiguous requirement, lack of ownership, shoddy project management at client and vendor side, lack of participation of client , lack of standardization, no or minimal UAT at customer end and selection of lowest cost vendor. Another major issue for failure is lack of maintenance provision in most of the contracts. Maintenance support is essential for the success of any project as bug fixing and small enhancements are required in any software project across the world for success of any application. As e-Gov projects takes a long time to roll out this support is required for a long time.

Currently every arm of the government is coming up with new e-Gov initiatives to provide speedy and transparent service delivery to citizens and other stake holders. Success of these initiatives is very important for the government as well for the citizens. For success of these initiatives it is required that we mix participative and process oriented approach. IT vendors have a major role to play in this, they have to come up with new models of delivery having a mixed approach because government neither can become an enterprise nor adhere to a tight SDLC process nor they can become as participative and flexible as required for agile process. We have to find a middle path. I am highlighting some of key action points which could be taken by both the government and the vendors for the successful execution of e-Gov projects.

Government Action Points:

• Create an empowered committee (powers for taking all decisions related to application) having a leader and one or two experienced department employees and make development of application their key task. This will help in quick requirement collection and improve collaboration. Good collaboration will help in creating good application and easy signing off the project.
• Get initial buy in from all important internal stakeholder on major business requirement and objective of system e.g. portal should have a self service page for citizens where one can carry out complete process himself/herself, should have an interface for assisted mode where  the agent can fill details on behalf of citizens etc., before RFP stage itself so that vendors have more clarity on scope.
• Call pre bid meetings and explain your entire requirement and clarify their doubts. This really helps in good estimation and later on in success of the project.
• Make provisions for iterative delivery in contract and ask for prototype (mock screens flow) for signing off requirements.
• Keep provision in contracts to provide advantage for vendors who have good track records in delivering successful e-Gov projects. Good and experienced vendors follow lots of best practices which will help project a lot.
• Keep Provision for continuous maintenance and support in all IT contracts and make successful roll out part of one of the main payment condition.
• Plan for User Acceptance Testing of delivered product. This testing can be done by the committee members and could be a basic functional testing. This will ensure that the product provides at least the basic functionalities.
• Clearly Plan for the deployment setup like earmarking of a DC, Production & Staging Servers and basic infrastructure for hosting the application.
• Identify a technical expert for evaluating the technical details of the solution and adherence to the standards and guidelines specified for e-Gov projects.
• Choose design/approach where product could be maintained centrally rather than distributive.
• Always ask for detailed planning having all the milestones clearly defined from vendors. It helps later in monitoring the progress of the project and shows vendor’s seriousness in delivering the project.
• Always ask vendors to provide mechanisms to report issues preferably through a tool. This really helps in tracking and planning releases.
• Make successful implementation of application at one or two sites a mandatory condition for payment release.
• There should be comprehensive guidelines/Checklist for developing e-Gov applications e.g. all applications should use open architecture so that there is no vendor lock in, should have open interface which could be called by other external applications. Some of them exist currently but covering specific areas like interoperability, quality. These guidelines will really help in information sharing across Government dept. For example a person’s education details could be directly fetched from education board or university application programmatically without any human intervention.
• There should be standard NFR requirements (Response Time, Uptime, Peak Load, Availability, Disaster Recovery etc. ) for IT application which can be used across all the e-Gov applications.
• There should be a common IT infrastructure for all government projects probably a cloud based setup for hosting e-Gov applications. This will really help in standardization of H/w and speedy roll out of projects.

IT Vendors Action Points:

• Always use prototyping techniques to get the sign off on requirements. It gives users a clear picture which one does not get from the documents.
• Plan for an iterative delivery and take incremental sign off. Sign off could be informal.
• Always suggest departments to have an empowered committee to discuss requirements and other issues of system development continuously. Make periodic review meetings with committee member’s part of project plan and your proposal. This is a very important aspect as all the stakeholders should have continuous information about the progress and the bottlenecks of the project.
• Do design to accommodate changes as requirement does change. Design should be able to accommodate changes easily without major rework.
• Do not under quote to get a project. Remember that good resources are required to create good products and good products only provide customer satisfaction and more business.
• As government projects have cost constraints, use open source technologies aptly.
• Do more interaction with the customer and keep him/her updated about the progress. In case of delays be transparent. Remember trust makes a lot of difference in any project.
• Always keep adequate contingency in your estimates as in e-Gov projects new requirements can come at any stage due to hierarchal reviews. One should be able to handle small changes without much fuss.
• Treat e-Gov projects similar to enterprise projects and apply all best practices. Think in terms of creating reusable asset as lots of components in e-Gov projects can be reused like Authentication and Authorization module, Notification sending module etc.
• Remember Quality control will help much more in e-Gov project then in enterprise project as here you will not have much buffer for rework and bug fixing.

It can be summarized that to make every e-Gov initiative success both government and IT vendors have to take some innovative and pragmatic steps. Government has to understand and follow some of the best practices of IT industry and IT vendors have to shrug off their traditional approach towards software development, delivery and maintenance. Vendors need to find new business models for delivery which are low cost and are effective in government scenario.

Be a part of Elets Collaborative Initiatives. Join Us for Upcoming Events and explore business opportunities. Like us on Facebook , connect with us on LinkedIn and follow us on Twitter, Instagram.