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 bidVendor

Evaluation Criteria

Roles and Responsibilities

Risk Factors

Technology Architecture

Legislative Changes

Tasks to be done by the Government

Contract Document / MSA

Commercial Bid

Change Managemen

t

DPR is an internal Government Document , it forms the base for the RFP, The RFP is finally circulated to the Vendor

Detailed project report

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

Bangalore One Architecture

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 types1) 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 DPR2) 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

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

Operations SLA

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

followingBangalore 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..)

Request for proposal

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

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

Placement of required no. of HD1 counter operators as per specifications provided in the RFP

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 manpowerVendor 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

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

Analysis of Pre-qualification Criteria of an IT tender

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..)

Thank you