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