Outcome or Process, Choose One

IT enabled Governance (ITeG) is gaining acceptance and momentum. The Electronic Service Delivery Bill now under consideration of the government is expected to give further thrust to e-enablement. With Aadhaar (unique id) getting better traction, Aadhaar integration in the service delivery also is providing stimulus in ITeG initiatives.

The complexity and challenges relating to the e-enablement vary across departments. On one end of the spectrum, the processes are quite mature and well defined, and computerization is primarily a means for improvement in productivity. On the other end of the spectrum, what is required is not just automation of existing processes, but a total transformation solution which involves significant process re-engineering, re-alignment of the role of various stakeholders which may also result in some stake holders role getting redundant or less important, innovative use of technology, phased implementation, continuous monitoring and many mid-course corrections.

In both cases Information Technology is a critical component; but often it is forgotten that IT is a means to an end and not and end in itself. I do not intend to discuss the other dimensions of ITeG in this post (take a look at ‘An amateur’s guide to e-Governance”). This note is about how the IT component is managed by government departments. Most government departments have limited in house skill to undertake these activities and therefore they outsource these to private sector service providers. Most of the IT service providers who take up these jobs of the System Integrators often do not have a total solution orientation or they are not capable to offer one. So they end up being suppliers to staff.

The predominant skill set for them is writing software for the specification given by the solution architects because our domestic software industry is often drunk with the $ from being technicians and cybercoolies and not architects and engineers. The user requirement study is "Tell me what exactly you want me to automate, I will program it" and not "Tell me what your dream is, we will work together on how technology can make it happen". So their approach is that of manpower provider than a solution provider. They don’t share the risk of a failed system (the limitation of liability clause adequately takes care of this) nor do the government comfortable to share the reward in the form of outcome based payments.

Often service providers influence how the RFP is made which ends up being an enquiry for supply of bodies than outcomes. So RFP gives more importance to the CV of the team instead of making them responsible for the outcome. Subsequently these contracts make the client to pay for rectifying the bugs in the programs and also make him spent for much more hardware than needed. Augmenting this problem is the purchase decision based on the lowest price quoted by the vendors. No proper matrices for measuring the outcome are defined and the department attempts to micromanage the CV, the attendance, hardware specification and so on. Then either the shoddy service providers takes the contract or the selected vendor develops shoddy solutions. That is the reason many ITeG don’t live up to the expectations.

When people are told exactly what and how to do something, they stop thinking for themselves-and they can't learn and grow. ~ unknown