E governance project conceptualisation to implementation

E-Governance Project – Conceptualisation to Implementation

E-Governance Project Life Cycle

Requirements of the Government ( Scope of Work) have to be stated in a comprehensive manner at the RFP Stage Very little margin for change of scope of work during Project Implementation Selection process of Vendor should be deemed to be fair Should follow due process Should follow various guidelines issued by Government – CVC, General Financial Rules, PWD Vendor selection guidelines Selection can be challenged in court This can delay implementation Specific issues in Government Procurement of e-Governance Projects

Most e-Governance Projects complex unlike Public Works project Most projects are first of a kind, may not be exactly repeatable Limited understanding of Government Staff Issues like Open standards vs. Open source, free software vs. open source Vendors extremely savvy Subtle changes in Tender documents can lead to certain vendors being favored Issues ( Contd..)

E-Governance Project Implementation Process

What outcomes need to be achieved Broadly a rough condensed DPR Can facilitate Consultations both within the Government , with experts and prospective Vendors To obtain approvals , budgetary allocation Initial brief note on the project

Implementation of Pilot is essential for First of a Kind Solutions Testing out the solution with limited exposure Identifying implementation issues / human issues / peak load issues To enable realistic estimation of timelines for implementation Provides experience to the Government to manage full roll out Enables testing of alternatives Mitigates risk of failure E – Seva – Started with TWINS – gradually rolled out Bhoomi – Started with 5 talukas, gradually rolled out Caveat Pilots are expensive Pilots need dedicated focus of the Implementation Agency Implementation of Pilot

Vendors bring knowledge of implementation in other state Best Practices Upcoming technologies Need for establishment of Framework for Consultation with Vendors Drawbacks May lead to charges of favouritism Consultation with Vendors

RFP and DPR Commonalities and Differences Project Costing As-is , To -be Business Model Scope of Work Pre-Qualification Criteria Guidelines for submission of Technical bid Vendor Evaluation Criteria Roles and Responsibilities Risk Factors Technology Architecture Legislative Changes Tasks to be done by the Government Contract Document / MSA Commercial Bid Change Management DPR is an internal Government Document , it forms the base for the RFP, The RFP is finally circulated to the Vendor

Study Current processes and practices in the Department Service Delivery metrics, bottlenecks, Issues Bangalore One As –is Citizens have to waste a lot of time in payment of Bills Bill payment mechanism of most utilities Customer unfriendly, Standing in line outside a window For each utility a citizen has to go to a different venue for bill payment High cost of collection of bills by Utility companies like BESCOM, Not a Core Task for utilities As- is Study

Create a solution to mitigate issues that have been ascertained in the To-Be Study Identify factors that will enable implementation of Solution Legislative Changes Government Change Management issues Operational Model – Type of Vendor / Costs / Business Model Rationalize Government Processes – GPR - (“ Government Process Re-engineering”) to facilitate implementation Bangalore One To –be Modern Citizen Service Centres Software solution for Bill payment PPP Model for ensuring delivery of high quality services to Citizens Passport Seva Project To ensure speedy delivery of Passport, Police Verification conducted post issue of Passport to Citizen To-Be / BPR

Needs to be as detailed as possible Should elucidate measurable outcomes desired from the Project Scope of Work should cover Implementation model Technical Specifications Manpower Requirements Vendor will take advantage of vagueness in their favour Vagueness in defining SOW may lead to good organizations thinking the project to be too risky and not participating Winning party may have made a miscalculation and may delay delivery Scope of Work

Technology model will be based on Scope of Work of the Project Evaluation of technology choices Centralised Architecture vs. Client Server Thin Clients vs. PC’s Wireless connectivity vs. Wired connectivity Open source vs. proprietary software Each has implication on costs and technical performance and are not comparable Combination of outcome orientation vs. detailed specification of each subcomponents Bangalore One – Service delivery metrics have been fixed , however hardware sizing has been left to vendor Desirable to prepare specifications that promote widespread competition and are not restrictive Technology Model

Technology Architecture of Bangalore One

Prepare Benchmark costing Hardware Software Licenses – Most licenses are processor based hence cost will increase when hardware is upgraded Software development Implementation Data digitisation Development of facilities ( front offices) Manpower Overheads Later at the RFP stage Should be compared with Commercial bid and reasons for variance + ve or – ve ascertained Costing

Timelines for Delivery Milestone wise timelines for each component Timelines for Bangalore Timelines should be realistic Should not be Vendor Driven, Should enable fair competition and not biased towards incumbent Should not be based on internal Government deadlines / exhausting budget Sl No Milestone Time for Completion 1 Signing of PPP agreement with successful bidder ( Govt and Vendor Joint Responsibility) T1 2 Handing over of site ( Govt Responsibility) T1+8 weeks 3 Development of Application Software ( Vendor Responsibility) T1+14 weeks 4 Establishment of Centers, including Networking ( Vendor Responsibility T1+14 Weeks 5 Testing & Certification of Software Solution ( Vendor Responsibility T1+16 Weeks 6 Training ( Vendor Responsibility T1+18 Weeks 7 System ready for launch (XX No. of Services at YYY No. Service Centers) ( Vendor Responsibility T1+20 Weeks

SLA’s need to be specified against each deliverable of the vendor SLA during Solution Development, Equipment Installation phase SLA during Operation and Maintenance phase Timeline and Quality of service needs to be mentioned Penalty for not meeting SLA Penalty for “Material Breach” of SLA Termination of Agreement in case of continued breach of some SLA’s SLA – Service Level Agreement

SLA’s need to be SMART Objective – Reach office 95% of days prior to 9.00 AM for January to December 2008 vs Come to Office on time S Specific Yes M Measurable Can be measured through electronic attendance monitoring system A Achievable Since it is 95% , probably can be achieved R Relevant Punctuality will improve the environment of the department T Timely Definition of time period Jan – Dec 2008

SLA’s are of two types Operational SLA’s ( Performance SLA’s) – Relate to delivery of Service Levels during Project Operation phase, i.e. Uptime of Servers, response time of Servers These SLA’s form part of DPR Implementation SLA’s ( Timeline or Rollout SLA’s) – Relate to penalties for non completion of the implementation of the Project, establishment of Data Centre, recruitment of Manpower These SLA’s are included only in the RFP Service Level Agreements

Operations SLA S No. Service Metrics Parameters Baseline Lower Performance Breach Basis of Measurement Metric Credit Metric Credit Metric Debit 1 Availability of agreed services over Internet 99% 11 99.0-97.0% 6 < 97% - 5 Online analysis of event log through use of relevant tools 2 Average e-Procurement Portal page loading < 7 sec 6 8-15 sec 3 > 15 sec -2 <measured over a leased circuit or equivalent at 64kbps 3 Resolution of Critical faults in the e-Procurement system < 5 working hours 7 5-7 working hours 4 > 7 Working hours -2 Telephone and email logs maintained by Help Desk service

Lumpsum payment models Deferred payment models Milestone based payment Quarterly Guaranteed Revenue payment Service based payment Each type has its advantages and disadvantages and relevant for particular types of work Computerisation of Government Treasury – Deferred Payment Bangalore One - Payment per transaction, Advantage Incentive for the vendor to increase the number of transactions from the Bangalore One Centres, provide Good services Disadvantage Low transaction services that are in public interest may not be provided by the Vendor Payment Models

Transaction wise payment Per Driving license Per bill payment % age of Transaction , % age value of the tender in case of e-Procurement Paid by Citizen Government Even if paid by Citizen, ultimately every thing is paid by the Government Issue of Windfall gains Service based Payment

Responsibilities of the various stakeholders need to defined in great detail Government Vendor ( The Scope of Work would be the definition of the responsibilities of the Vendor) Responsibilities of other stake holders Both private and public involved in the project. Bangalore One Project promoted by the e-Governance department but dependencies on many other Government Departments Electricity Water Responsibilities

Project Management Office The task of the PMO is to manage the project post awarding of contract Should have a mix of Government Officers and Technical staff There may arise a need to undertake recruitment of technical Staff as such skills may not be readily available in Government Project Review Committee ( PRC) This committee would comprise of the Head of the Department, other members of the department, preferably independent technical experts The PRC should periodically review the progress of the Project The PRC should also function as a dispute resolution forum Supporting Infrastructure

Risk Factors should be articulated for each project Some Sample Risk factors for Bangalore One could be as following Bangalore One was the first e-Governance project being implemented by the newly formed e-Governance Department of Karnataka. Failure of the project would damage the credibility of the Department and hamper implementation of more such projects Risk Mitigation – The Department invested substantial efforts in design of Project , enlisted help of senior team that implemented the E-Seva Project. Developed Vendor Selection criteria that would enable competent vendors to be selected for the Project Bangalore One followed a hybrid technology approach of both online transaction and offline transaction updation, this model might not work Risk Mitigation – Detailed reports were developed to ensure that transaction would be updated in the central server of the utility. The Department also enlisted the help of competent technical consultants from Microsoft to work with the Software developer to ensure that the system would work Risk Factors

BESCOM, the electricity utility followed a distributed billing model with customer billing and payments maintained in the servers at the Sub divisions. Thus it may so happen that Customer payments made in Bangalore One may not be updated on the Sub Division records Risk Mitigation – The Department motivated BESCOM to invest in a Leased Line network that would enable transmission of data from the BESCOM Central Server to the sub divisions The various utility companies participating in the Project would not close their own billing counters leading to non viability of the Project Risk Mitigation – The Department felt that the superior customer service delivered by Bangalore One would lead to Customers preferring to pay bills at Bangalore One centres and not at the Department counters Risk Factors ( Contd..)

Lack of Internal Professional Capacity of the Department to implement the Project Risk Mitigation – Bolster Capacity through appointment of Consultants Huge Risk of Bankruptcy of the Organisation during the Project Period Risk Mitigation – Prescribe adequate financial parameters like Turnover, net worth that will mitigate the above Technology Obsolescence – X Department purchased a Unix variant O/S which does not have widespread OEM hardware support Risk Mitigation – At the risk of restricting competition prescribe widely used H/W and Software Software performance may degrade in 2-3 years time Risk Mitigation – Prescribe that Vendor would upgrade the software , hardware components Risk Factors ( Contd..)

Conscious decision needs to be taken Very short term contracts 1 year development , 1 year implementation + 2 year support and maintenance will lead to again going to market after 4 years Most probably Government staff will extend contract on same terms and conditions Long contracts 10 years, 15 years – Risk of technology obsolescence Duration of Contract

. Sample Implementation SLA Placement of required no. of HD1 counter operators as per specifications provided in the RFP S No. Item Details 1 Definition of Service or additional explanation Counter operators will have the required qualifications, experience, training and will have qualified the test set by Dir. EDCS 2 Certifying authority Chairman HD1 CMC 3 Penalty for breach Rs. 250/- per day for shortfall of every operator 4 Material Breach Placement of less than 75% of the required operator strength even after 60 days of the timeline 5 Stipulated period for mitigating material breach conditions 30 days 6 Enhanced Penalty during stipulated period Rs. 500/- per day per operator 7 Remedial performance required for mitigating material breach conditions for non termination before the end of the stipulated period Placement of atleast 90% of the operators within stipulated period

Timelines for Delivery with associated Penalties Milestone wise timelines with penalties for delay in each component example of Bangalore One Project Sl No Milestone Time for Completion Penalty for delay 1 Signing of PPP agreement with successful bidder T1 - 2 Handing over of site T1+8 weeks 3 Development of Application Software T1+14 weeks Rs X lakhs per every week of delay 4 Establishment of Centers, including Networking T1+14 Weeks Rs N lakhs per every week of delay 5 Testing & Certification of Software Solution T1+16 Weeks Rs M lakhs per every week of delay 6 Training T1+18 Weeks Rs Z lakh per every week of delay 7 System ready for launch (XX No. of Services at YYY No. Service Centers) T1+20 Weeks Rs Y lakhs per every week of delay

Key Considerations for Selection of Vendor Vendor should be technically capable – having prior experience, technical competence to execute the Project, Adequate skilled manpower Vendor should have Financial capability to execute the Project The risk of Vendor abandoning the project mid way due to variety of issues like attrition of key man power, financial issues should be reduced to extent possible Vendor should offer an optimum desirable ( as per Government requirement) of a technologically and financially superior solution Selection of Vendor

Financial capability Prior similar project experience Should have adequate justification why certain eligibility criteria is being proposed Should follow CVC guidelines Difficulty in formulating eligibility criteria when novel projects are being implemented Should evaluate Available Capacity of Vendor All e-Governance tenders determine eligibility based on Financial parameters like turnover, net worth , however a Vendor may secure multiple projects far beyond its execution capability Pre qualification or eligibility criteria

Guidelines were prescribed in this office OM of even number dated 17/12/2002, on the above-cited subject to ensure that the pre-qualification criteria specified in the tender document should neither be made very stringent nor very lax to restrict/facilitate the entry of bidders. It is clarified that the guidelines issued are illustrative and the organizations may suitably modify these guidelines for specialized jobs/works, if considered necessary. However, it should be ensured that the PQ criteria are exhaustive, yet specific and there is fair competition. It should also be ensured that the PQ criteria is clearly stipulated in unambiguous terms in the bid documents. Examples of Eligibility Criteria not meeting above guidelines MNC Brands for computers Turnover much higher than the required For giving International services, only private airlines with more than 5 years track record were considered – Thus only JET airways qualified CVC Guidelines

Analysis of Pre-qualification Criteria of an IT tender The Content Service Provider (CSP) should have an established office in the State. Needed because close cooperation is required with the Government Department, ideally Company should be provided the option of opening an office in the State The CSP should be a financially sound registered company/society in India having minimum annual turnover of Rs. 2 Crore during any two of the last three financial years Should be linked to project cost ideally the average turnover over the last three years should be 3 times the Project Cost The CSP should have minimum experience of 5 years in providing Content Development Services for websites/ portals /electronic publishing (CSP to provide documentary support). Restrictive as providing content for websites is an emerging field and many new companies have come up that can provide good service. However we do not want fly by night operators The CSP should have executed minimum two projects with entire scope of work as per clause 3. CSP to furnish detailed information on both the projects as per Annexure-V along with work orders. Required as we want experienced parties The CSP should have relevant experience and understanding of the information and services of Government Domain. Vague criteria, how do we evaluate experience in Government Domain CSP should have skilled/experienced Content Writers on its payroll (CSP to provide details as per Annexure III) How many Content writers, what skill level

Helpful to know number of parties interested in the project RFQ can help in shortlisting of firms Prospective bidders can know their competition and can give a serious bid Shortlisted Firms can be formally involved in Tender Preparation Shortlisted Firms can suggest Technology / Implementation alternatives Expression of Interest/ Request For Qualification

Required when diverse skills are needed Bangalore One Project Implementation of Citizen Centres Software Development Drawbacks of allowing Consortium Mostly ineligible firms team up with eligible firms. Work is executed by the smaller firm There exist Issues in management of Consortium Over long duration of project, partners may fall out Consortium partners may ask for replacement of one or more partners due to non performance Responsibility needs to be fixed on Prime Partner Consortium bidding

For Complex e-Governance project, Selection can be through a three stage process Stage 1 Checking compliance of bidders as per the pre-qualification criteria established for the Project Stage 2 Evaluation of Technical Capability of the Pre-Qualified bidders to execute the Work Technical capability of the bidder should be evaluated in a fair and objective manner Framework for evaluation of Technical Capability of the bidders should be provided upfront in the RFP Selection Process

Technical Evaluation should consist of the following Previous experience of the bidder that demonstrates its technical competence to undertake the project Specific competencies that the Bidder will deploy for successful outcome of the project Additional Manpower / Specific Quality methodologies Specific technical competency Approach of the bidder for successful execution of the Project Technical bid should form part of deliverables of the successful bidder Bidders scoring above a certain pre-determined marks should be qualified in the Technical Stage Stage 2 – Technical Evaluation

Stage 3 – Commercial bid evaluation Two methods of Vendor Selection Method 1 - L1 based selection Technical Qualified bidder that submits the best financial offer is awarded the work Method 2 – Joint Quality cum Cost basis Selection ( QCBS) Both Commercial and Technical Scores are given a certain weightage. Recommended in cases where Technical competence of Vendor will have an impact on the quality of Project Deliverables General Practice of giving 50% weightage to Technical Score and 50% weightage for Commercial Score However Projects requiring a high degree of technical competence like Security Audits, Technical marks may be given higher weightage of 75% In case of QCBS Selection, Technical Evaluation needs to be done in thorough and objective manner Stage 3 – Vendor Selection

Formal mechanism for interested parties to meet the department Put forth their suggestion, queries regarding the tender document Sufficient notice should be given for Pre-bid meetings Ask bidders to submit questions in advance Pre bid queries need to be answered atleast 15 days prior to last date of submission of bid Answers should be specific, detailed and comprehensive Pre bid Conference

Despite RFP being drafted comprehensively, there may be issues that are not covered in RFP Services based ( outcome oriented) Projects may have a more inclusive framework for accomodating changes, however still needed Bangalore One – Delivery of Passports through Bangalore One was far more complicated and effort intensive as compared to other services. Software Application projects, have a need for robust Change Control Framework Estimate of Cost of Change to Vendor is difficult Many times Vendors underbid but try and make up the price by submitting change requests Change Control Framework

MSA or contract with successful bidder Master Service Agreement contains general contract terms, though needs to be contextual to the Project for e.g. detailed terms and conditions related to Intellectual property may not be relevant in a Project where the task does not include development of application software but merely involves establishment and Operation and maintenance of desktops Most bidders don’t raise questions on MSA during pre bid but ask for changes once they win the contract. MSA in addition to generic contract should incorporate Scope of Work from RFP gets reproduced as Project Engagement Definition Document Technical bid of the successful bidder Service Level Agreements Master Service agreement

Ideally Project Monitoring Unit should monitor compliance of the Vendor to the RFP In absence of Internal Capacity a IIIrd party auditors may be appointed to review the deliverables of the Vendor Some Central Government Projects mandate appointment of a IIIrd party auditor IIIrd party vendor required for checking technical deliverables, Security audit Appears fair to the Vendor However at times IIIrd party auditors go completely as per the letter of the RFP and IIIrd party reports extremely rigid IIIrd Party Audit

RFP / Tender is a Project Implementation plan Needs to be prepared with care Will guide project implementation Extremely difficult to change RFP RFP clauses should be consistent with one another and should be coherent as a whole In case of change of Project Implementation Staff, RFP is the only document that will guide successors Summary

Delay in providing inputs to Vendor Delay in signoffs to SRS / FRS thereby delaying the Project Delay in certifying acceptance of Deliverable of Vendor thereby delaying payment to Vendor Roles and responsibilities of the Government are prepared in an idealistic manner Delays in deliverables of the responsibilities of the Government failure in providing sites Delay in making legislative changes Failure in securing cooperation from other Stakeholder departments No Penalties on Government Department for failure to execute its responsibilities Issues related to Project Execution

Lack of Continuity of Project Champion, Successor is not aware of the intricacies of the Project or does not share the same commitment to the Project Signoff's given by a Government Officer are not respected by the successor. During Project Execution many issues come up which may not have been covered in the RFP. Failure of the Government Officers in resolution of such issues Lack of ownership of Project implementation committee who are guided by the letter of the RFP and are not able to demonstrate flexibility during actual implementation Project Execution Issues ( Contd..)

E governance project conceptualisation to implementation

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to E governance project conceptualisation to implementation (20)

More from Anirban Mukerji (20)

E governance project conceptualisation to implementation