Presentation is loading. Please wait.

Presentation is loading. Please wait.

Slide 1 Course: e-Governance Project Lifecycle Day 3 Session 4 DPR & RFP Preparation.

Similar presentations


Presentation on theme: "Slide 1 Course: e-Governance Project Lifecycle Day 3 Session 4 DPR & RFP Preparation."— Presentation transcript:

1 Slide 1 Course: e-Governance Project Lifecycle Day 3 Session 4 DPR & RFP Preparation

2 Slide 2 Agenda  Objectives for preparation of DPR  DIT guidelines for preparation of DPR  Key elements of DPR  Need for KPIs and Service Levels in e-Governance Projects  Service Level Management  Approach for procurement of goods and services in for e-Governance  Key elements of RFP  Implementation Partner/agency evaluation and selection methods

3 Slide 3 What is a Detailed Project Report or DPR? 3 The Detailed Project Report is an essential building block for firming up a proposed project initiative The DPR contains details about the proposed project to enable appraisal, approval, and subsequently implementation Usually prepared according to funding agencies’ templates and guidelines e.g. DIT guidelines for NeGP projects, World Bank guidelines… Refer www.mit.gov.in – e-Governance/Reference documents section

4 Slide 4 What is a DPR used for? 4 DPR involves a detailed study on various aspects of the project and should be prepared before the Selection of Vendors. It is a comprehensive proposal prepared for all types of projects and used as a basis for: Investment decision making Approval of plans and designs Project planning Implementation scheduling and budgeting

5 Slide 5 e-Governance Project Lifecycle (eGLC) Vision & Strategy Development Current State Assessment Future State Definition Implementation approach and sourcing Develop and implement T system Operate and sustain Stakeholder Needs Assessment Define clear vision & objectives Prioritization of services and projects Incorporate domestic and global learnings Identify institutional structures & capacities for implementation Define funding requirements Define monitoring and evaluation approach. Critical assessment of current business processes and pain areas Best practices in similar environments Assess legal framework and current limitations Assess current ICT systems and their ability to support future plans Assessment of current capacities at all levels and their preparedness for e- governance. Process reengineering and to –be process definition Identity IT enablement opportunities and requirements Define changes to the legal and regulatory environment Develop People change and capacity building plan Develop project awareness and communication requirements… Define implementation approach and phasing plan (functional and geographic) Assess detailed funding requirements and business model Prepare DPR Develop vendor evaluation and selection criteria Develop KPIs and performance levels for services and systems Develop RFP Bid evaluation and vendor selection Definition of detailed functional and technical requirements System design and development Software quality assurance, acceptance testing and auditing Training and capacity building Change management and project communications Project documentation Project go-live System operations and maintenance Software change management Rollout services and systems (functionality and geography) Objectives and benefits evaluation and reinforcement Sustained change, capacity building and communications.. When is a DPR prepared?

6 Slide 6 e-Governance Project Lifecycle (eGLC) Vision & Strategy Development Current State Assessment Future State Definition Implementation approach and sourcing Develop and implement T system Operate and sustain Stakeholder Needs Assessment Define clear vision & objectives Prioritization of services and projects Incorporate domestic and global learnings Identify institutional structures & capacities for implementation Define funding requirements Define monitoring and evaluation approach. Critical assessment of current business processes and pain areas Best practices in similar environments Assess legal framework and current limitations Assess current ICT systems and their ability to support future plans Assessment of current capacities at all levels and their preparedness for e- governance. Process reengineering and to –be process definition Identity IT enablement opportunities and requirements Define changes to the legal and regulatory environment Develop People change and capacity building plan Develop project awareness and communication requirements… Define implementation approach and phasing plan (functional and geographic) Assess detailed funding requirements and business model Prepare DPR Develop vendor evaluation and selection criteria Develop KPIs and performance levels for services and systems Develop RFP Bid evaluation and vendor selection Definition of detailed functional and technical requirements System design and development Software quality assurance, acceptance testing and auditing Training and capacity building Change management and project communications Project documentation Project go-live System operations and maintenance Software change management Rollout services and systems (functionality and geography) Objectives and benefits evaluation and reinforcement Sustained change, capacity building and communications.. When is a DPR prepared? The highlighted activities in the eGLC provide inputs to the DPR However, the DPR may make provisions of detailed study or implementation in some of these areas e.g. Legal reforms may be a separate project

7 Slide 7 How is DPR different from feasibility report? While Feasibility study report Defines overall objectives of the proposed system Is a primary report for formulation of the initiative Is a base document for investment decision-making DPR is a project proposal that is used not only for the investment decision-making, but also for preparation of the project plan and execution of the project.

8 Slide 8 Main Sections of a DPR* *Based on DIT guidelines- Jan 09 Section I : Background of project and other basic information Section II : Project overview Section III : Project details including its implementati on model

9 Slide 9 Section I: Background of project and other basic information Title of the ProjectWhether existing Mission Mode Project (MMP)Eligibility Tests- NeGP or Best Practice AlignmentWhether Pilot or Roll outProject Initiator detailsImplementing Agency detailsLocation of project implementation Section I : Background of project and other basic information

10 Slide 10 Section II: Project overview Identification of stakeholdersProblem to be addressed by projectCauses and effects of the problemCategory of services: G2C, G2B or G2GProposed ServicesPast experience and lessons learntKey activities and timelinesProject costsSource of funding Section II : Project overview From EGLC Phases: A.Vision & Strategy Development B.Current State Assessment C.To-be State Definition From EGLC Phases: A.Implementation Approach and Sourcing

11 Slide 11 Section III: Project details As a result of Vision & Strategy Development in EGLC Objectives should be S.M.A.R.T (Specific, Measurable, Achievable, Realistic and Time Bound) Goal and Objectives As a result of Vision & Strategy Development in EGLC Discussed in previous section Stakeholder Analysis As a result of Vision & Strategy Development in EGLC Service is the core services delivered by the Agency Service levels are parameters for measuring efficiency, transparency & reliability of services Service Levels defined in terms of- Quality, Quantity, Delivery time & Cost Services and Service levels Section III : Project details including its implementati on model

12 Slide 12 Section III: Project details (contd..) Section III : Project details including its implementati on model As a result of Implementation approach and sourcing in EGLC Horizontal or vertical functionality implementation Prioritization criteria of implementation Delivery channel strategy Implementation Strategy Description and Recommendations for each sub-activity Discussed in previous section Scoping Study As a result of Future State Definition in EGLC Scope and purpose of intended process change Mapping of existing processes Identification of areas of inefficiency, duplication of efforts, redundancy etc Preparation of blue print for improving efficiencies Process Reengineering

13 Slide 13 Section III : Project details including its implementati on model As a result of Future State Definition in EGLC Capacity Building, Awareness Creation, Legal Issues Change Management As a result of Future State Definition and Current State Assessment in EGLC Back-end, Middle ware:, Front-end, Network Architecture/ Devices, Information Security As-Is, Option Analysis, To-Be Infrastructure As a result of Vision & Strategy Development in EGLC Impact/ Outcome Indicators, Output Indicators, Process Indicators Means of verification Monitoring, Evaluation and Assessment Section III: Project details (contd..)

14 Slide 14 Section III : Project details including its implementati on model Other Activities like civil works, etc As a result of Vision & Strategy Development in EGLC Existing and Proposed Organization Structure Staffing and deployment strategy Organization structure Assumptions Risk Assessment Measures for risk mitigation Assumptions and Risk Management In short, medium and long term Estimated demand and growth rate of proposed services Section III: Project details (contd..)

15 Slide 15 Section III : Project details including its implementati on model As a result of Vision & Strategy Development in EGLC Project Cost Investment Costs Recurring Costs Financing Year-wise breakup of source Amount of funds in form of assistance Project Costs, Procurement and Financing Financial Analysis Business Model Key Implementation Design Features Public Private Partnership (PPP) Section III: Project details (contd..)

16 Slide 16 Section III : Project details including its implementati on model Procedural, staffing, budgetary and contractual arrangements to ensure sustainability of project outcomes Sustainability Plans As a result of Future State Definition in EGLC Management arrangements Contracting arrangements Accounting and audit arrangements Implementation arrangements As a result of Future State Definition in EGLC Phasing of project activities Schedule of implementation for each phase Identify critical dependencies in the project and Expected timelines for completion of key milestones Detailed Work Plan Section III: Project details (contd..)

17 Slide 17 Service Level Management

18 Slide 18 Understanding Service Levels/KPIs in e-Governance ‘Services’ in an e-Government Project (differentiating government services and third party services) Government Services: Department Services identified for ‘e’ enablement.e.g. 1.Registration of companies 2.Filing of returns 3.Issuing passports 4.Registration of birth and death 5.Payment of taxes and duties…… Services provided by third parties 1.Development of application software 2.Implementation of IT infrastructure 3.Maintenance of systems and infrastructure 4.Establishment of call centre 5.Establishment of service delivery centers etc…

19 Slide 19 Understanding Service Levels/KPIs in e-Governance ‘Services’ in an e-Government Project (differentiating government services and third party services) Government Services: Department Services identified for ‘e’ enablement.e.g. 1.Registration of companies 2.Filing of returns 3.Issuing passports 4.Registration of birth and death 5.Payment of taxes and duties…… Services provided by third parties 1.Development of application software 2.Implementation of IT infrastructure 3.Maintenance of systems and infrastructure 4.Establishment of call centre 5.Establishment of service delivery centers etc… Government is responsible for ‘Quality’ of Government Services & Third party service provider is responsible for ‘Quality’ of Systems/Techni cal services

20 Slide 20 Understanding Service Levels/KPIs in e-Governance Service levels or Key Performance Indicators support in measuring ‘Quality’ of Services…. Government Services (Recap from GPR): ‘Quality’ attributes of government services include (illustrative list): 1.Time for service completion 2.Cost for service completion 3.Accuracy of service delivered 4.Completeness of service delivered 5.Transparency in service delivery… Services provided by third parties: ‘Quality’ attributes of technical systems and services include: 1.Completion of systems development in time, to the requirements, standards and cost… 2.‘Availability’ of services online 3.‘Performance’ of systems to deliver online services 4.‘Security’ of online services…..

21 Slide 21 Understanding Service Levels/KPIs in e-Governance Improving the ‘Quality’ of services in e-Governance initiatives.. Government Services: ‘Quality’ attributes of government services are improved through (illustrative): 1.Government Process Reengineering 2.Leveraging Information Technology 3.Privatisation/PPP (to leverage private sector strengths…)…. Services provided by third parties: High ‘Quality’ technical systems and services are delivered through: 1.Clear understanding of requirements 2.Adopting proven technology and standards 3.Employing skilled resources 4.Right project management approaches 5.Quality assurance processes…

22 Slide 22 Understanding Service Levels/KPIs in e-Governance Need for measuring the ‘Quality’ of services in e-Governance initiatives.. Government Services: ‘Quality’ attributes of government services need to be measured for: 1.Understanding performance and perception of citizens 2.To assess the outcomes and impact of initiatives undertaken for improving quality 3.To understand the progress towards the defined targets…. Services provided by third parties: ‘Quality’ attributes of technical systems and services need to be measures for: 1.To ensure compliance with defined performance levels – which in turn have impact on quality attributes of govt services 2.Proactive identification and resolution of technical issues 3.To ensure return on investment…. New trends in e-Governance includes leveraging third party service providers in delivering government services… 1.E.g. leveraging service providers for delivering government services (CSCs, eSeva, MCA21…) This requires measuring performance of service providers on both ‘process’ and ‘systems/technical’ measures

23 Slide 23 Service Level Agreements – Some Definitions Service: A Service is an outcome of an request and it provides an economic, social or personal benefit or right to the requestor or results in efficiency gains to an organization. Service Level: A Service Level defines the quality and quantity of service, in a measurable and objective way. Service Level Objective (SLO): is the set of purposes or objectives sought to be achieved through defining and prescribing the Service Levels for an initiative or organization. Service Level Agreement (SLA): is an agreement between the Service Provider and the Service Seeker that defines the Service Levels, the terms and conditions for enforcing the Service Levels and the remedies in case the Service Levels are not fulfilled. Service Level Management (SLM): is an institutional arrangement that ensures effective implementation of the Service Levels and enforcement of the SLA

24 Slide 24 Key Challenges in SLA Definition & Management Minimal Understanding & awareness on Service Level Management  Type of SLAs, Relevance to Project objectives, Measurement process etc… Non-alignment with business goals  Criticality of server uptime vs service uptime Non-alignment with project benefits  Is it a service delivery project or an IT Infrastructure project? Lack of impact assessment on business goals  Do we understand the business impact between 96% (12 hrs) and 99.99 % (1 hr) SLA Are we listening to the customers???  User perception SLAs???  99% system uptime with unsatisfied customers

25 Slide 25 Lack of measurability  99% of Application uptime?????  Ambiguity in measurement process Lack of understanding on the cost implications of SLA definition  Achieving 99% uptime requires significant redundancy in infrastructure & resources Redundancy in infrastructure & resources for SLA Management across projects (3 infrastructure projects, 10+ State MMPs....)  SLA Monitoring solution for monitoring & reporting SLAs  Resources for measuring and certifying SLAs.... Who does SLA Monitoring?  In several projects, SLA monitoring systems are implemented and managed by the same agency which provides services??? Key Challenges in SLA Definition & Management

26 Slide 26 Incentivizing performance  Not only punitive measures Validity of SLAs through the project period  Several SLAs become invalid during the contract period Key Challenges in SLA Definition & Management

27 Slide 27 Some Considerations for SLAs for e-Governance Projects The Service Levels/KPIs defined for the project should fulfill the following design criteria: Should be based on the business objectives and goals proposed to be addressed through the project Should be measurable and enforceable Clear accountability and responsibility for SLAs (based on the stakeholders and their allocated responsibilities) -IT service provider can not be responsible for ‘government services quality’ if his scope is only limited to IT systems design and development… Should be inline with the phase of project development (SLAs during project development are different than the SLAs post project implementation) SLA’s to be time bound….

28 Slide 28 SLA Life Cycle Defining Service Level Objectives Defining Service Levels Designing SLA Establishing SLM Defining Services Business Objectives SLA Life Cycle

29 Slide 29 Service Level Objectives Service Level Objective is the value that the management intends to give to various sets of stakeholders, and the value it intends to derive from the investment in Technology and Infrastructure Illustrative set of SLOs given in table below: Stakeholder GroupValue Proposition (SLO) External: Customers, Suppliers, Financiers Efficiency, Convenience, Reliability, Responsiveness, Cost Effectiveness Internal: Employees, Management, Auditors Usability, Accountability, Traceability, Effectiveness Investment AreaValue to be derived (SLO) Technology & Process: Standards, Architecture, BPR Interoperability, Cost Effectiveness, Transformation, Simplicity Infrastructure & People areas: Data Centre, DR Site, Change Management Performance, Security, Availability, Efficiency, Ownership

30 Slide 30 Defining Service Levels Service Levels need to be defined for services proposed to be covered under the e-governance project: Service Levels defined for those services to be delivered by the vendor forms the basis of the Service Level Agreements The components of the Service Level Definition are: - Service Level Parameters: measurable attributes of the service, which will provide a reliable and objective estimate of the quality and quantity of service - Service Level Metrics: A set of norms prescribed against each service level parameters to provide baseline performance expected from Vendor - Service Level Measurement Method: Precise, reliable and consistent method by which the service level parameter can be measured - Service Level Enforcement Method: Method by which the service level agreement can be enforced (deduction from payments, penalties etc)

31 Slide 31 Sample SLA definition – G2B Service Delivery Service Metrics Parameters Baseline Lower performanceBreach Measurement method MetricCreditMetricCreditMetric Service Related – Citizen Facing 1. Average wait-period at Service Centre (Peak dates, Peak hours) <15 min15 15-25 min10>30 min Time between issuance of the token to the customer at the kiosk on arrival and initiation of registration process in the system by the CSC executive (as measured by SLA Monitoring system) 2.Average wait-period at Service Centre (Peak dates, Non-Peak hours) < 10 min12 10 -15 min8>20 min 3.Average wait-period at Service Centre (Non-Peak dates, Peak hours) < 5 min9 5-10 min6 >10 min 4.Average wait-period at Service Centre (Non-Peak dates, Non- Peak hours) No waitin g7 0 – 3 min5

32 Slide 32 Sample SLA definition – G2B Service Delivery Service Metrics Parameters Baseline Lower performanceBreach Measurement method MetricCreditMetricCreditMetric Service Related – Citizen Facing 1. Average wait-period at Service Centre (Peak dates, Peak hours) <15 min15 15-25 min10>30 min Time between issuance of the token to the customer at the kiosk on arrival and initiation of registration process in the system by the CSC executive (as measured by SLA Monitoring system) 2.Average wait-period at Service Centre (Peak dates, Non-Peak hours) < 10 min12 10 -15 min8>20 min 3.Average wait-period at Service Centre (Non-Peak dates, Peak hours) < 5 min9 5-10 min6 >10 min 4.Average wait-period at Service Centre (Non-Peak dates, Non- Peak hours) No waitin g7 0 – 3 min5 SLA Parameter SLA Metric SLA MeasurementSLA Enforcement

33 Slide 33 Sample SLA definition – 2 Service Metrics Parameters Baseline Lower performanceBreach Measurement method MetricCreditMetric Credi tMetricCredit Technology – Performance Related Capacity of the Application Server 10000 service transact ions per hour 6 No tolerance for lower performance. Zero credit will be given for performance below baseline <6000-6 Measurement s from the Enterprise SLA Monitoring System at the State Data Centre Uptime of Servers> 95%12<96%-8 Uptime of Internet services >98%4>95%-4 Time to restore Data Centre from failure <1 hour5>3 hours -5

34 Slide 34 Indicative list of SLP categories SLPs may be defined to capture the quality of service delivery in any of the broad service categories: - Design and development of e-Government Projects - Speed of Delivery of Services - Waiting times of customers - Maintenance of IT assets created for a project - Maintenance of non-IT assets created for a project - User experience - User convenience - Responsiveness of systems - Responsiveness of service delivery agents - Adherence to security standards - Response to security incidents - Defect-free / error-free service

35 Slide 35 Definition of Service Level Metrics The following performance metrics (range of values) to be defined for each service level parameter: - Baseline: Acceptable level of service by the vendor - Lower: Degraded level of service, for which vendor may be penalized - Higher (optional): Higher level of service for which vendor may be incentivized - Breach: Highly degraded level of service / material breach, which may invite termination contract Service level metrics should be realistic without compromising on Service Level Objectives - E.g. Baseline metric for portal load time can be anywhere between 5-10 seconds (which does not adversely affect the SLO of user experience). Setting a portal load time of 2 seconds is unrealistic

36 Slide 36 Measurement of Service Levels “If you can’t measure it, you can’t manage it !” Tools designed for measuring SLA metric should be precise, reliable, accurate, consistent and trustworthy Automated measurement by SLA Management System should be used wherever possible The conditions under which measurement is taken should be defined precisely: - e.g. Measurement of portal page loading: measured over a broadband connection of 128 Kbps Some SLAs (e.g. user experience) may require periodic surveys and feedback from end users. The methodology for this should be precisely defined in the Contract so as to eliminate later ambiguities and disputes

37 Slide 37 Service Level Enforcement SLA can be most effectively enforced by linking the payments to the Service Provider to the degree of compliance with the SLA Deduction Method: - Vendor gets 100% payments (monthly / quarterly / milestone) for full compliance to the SLA - For lower performance from SLA, specified percentage is deducted. Higher performance may be incentivized by bonus payments Addition Method: - A percentage of the payment (e.g. 40%) to the SP is made dependant on the fulfillment of Service Level Matrix - All SLPs are assigned credits for baseline, lower, higher and breach metric. Credits will depend on the priority of the SLP - Scores prescribed for baseline performance will add up to 100%

38 Slide 38 Deduction Method – Illustrative example Sl. no: SLA Parameter Metric BaselineLowerBreach 1 Time taken for setting up Deployment Infrastructure Up to 15 days from Letter of Intent 15-30 days (Penalty of Rs. 2000 per day) Above 30 days (Termination of contract) 2 Delay in completion of milestone 1 week delay 1-2 week delay (Penalty of 5% of milestone payment for 1 week, additional 1% penalty for each additional day) Above 2 weeks (2% additional penalty of each additional day, termination of contract)

39 Slide 39 Addition Method – Illustrative example Service Metrics Parameters Baseline Lower performanceBreach MetricCreditMetricCreditMetricCredit Service Related – Citizen Facing 1. Average wait-period at Service Centre (Peak dates, Peak hours) <15 min12 15-25 min6>30 min 0 2.Average wait-period at Service Centre (Peak dates, Non-Peak hours) < 10 min8 10 -15 min4>20 min 0 3.Average wait-period at Service Centre (Non-Peak dates, Peak hours) < 5 min55-10 min2 >10 min0 4.Average wait-period at Service Centre (Non-Peak dates, Non- Peak hours) No waitin g5 0 – 3 min2 > 3 min0 Total Credit3014 0

40 Slide 40 Addition Method – Illustrative example Service Metrics Parameters Baseline Lower performanceBreach MetricCreditMetricCreditMetricCredit Service Related – Citizen Facing 1. Average wait-period at Service Centre (Peak dates, Peak hours) <15 min12 15-25 min6>30 min 0 2.Average wait-period at Service Centre (Peak dates, Non-Peak hours) < 10 min8 10 -15 min4>20 min 0 3.Average wait-period at Service Centre (Non-Peak dates, Peak hours) < 5 min55-10 min2 >10 min0 4.Average wait-period at Service Centre (Non-Peak dates, Non- Peak hours) No waitin g5 0 – 3 min2 > 3 min0 Total Credit3014 0 30% of the total payout (monthly/quarterly) is linked to vendor’s achievement of baseline SLA. In case of lower performance, lower credits will be given in that SLA parameter and payment will be reduced accordingly.

41 Slide 41 Addition Method – Illustrative example Service Metrics Parameters Baseline Lower performanceBreach MetricCreditMetricCreditMetricCredit Service Related – Citizen Facing 1. Average wait-period at Service Centre (Peak dates, Peak hours) <15 min12 15-25 min6>30 min 0 2.Average wait-period at Service Centre (Peak dates, Non-Peak hours) < 10 min8 10 -15 min4>20 min 0 3.Average wait-period at Service Centre (Non-Peak dates, Peak hours) < 5 min55-10 min2 >10 min0 4.Average wait-period at Service Centre (Non-Peak dates, Non- Peak hours) No waitin g5 0 – 3 min2 > 3 min0 Total Credit3014 0 30% of the total payout (monthly/quarterly) is linked to vendor’s achievement of baseline SLA. In case of lower performance, lower credits will be given in that SLA parameter and payment will be reduced accordingly. Sample calculation: If bidder meets baseline in SLP 1 & 3, lower in SLP 2 and breach in SLP 3, payout will be 12+4+5+0 = 21%. Hence 21%+70% (fixed part of payout) will be paid to the vendor

42 Slide 42 Long cycles for procurement - many a times it may take anywhere between 3-6 months for finalisation of vendor Unable to procure right product/right vendor Procured goods/services not inline with the business requirements Qualifications and evaluation criteria not inline with project objectives and requirements Lack of clarity in evaluation and selection criteria Open ended scope /ambiguous requirements - expected to be finalised post award of contract Unlimited liability of the implementation partners SLA's are not realistic and not inline with the business requirements Ambiguity in SLAs - not measurable Penalty clauses payment schedules not inline with the efforts and investments expected from vendors during project phases General perceptions of Government Procurement

43 Slide 43 Not guaranteeing timely payments (funding agencies provision payment of interest on fees if payment is delayed) detailed contractual obligations/terms and conditions not known at the time of bidding (RFP doesn't include draft contract) Short procurement cycles in some cases Lack of clarity on right solution (COTS or Bespoke???) Expected to deliver best value solution at least cost – commercially not feasible General perceptions of Government Procurement (contd..)

44 Slide 44 Ending up with wrong vendor Ambiguous requirements at RFP stage leading to conflict in understanding between government and vendor - leading to delays and terminations Long cycles for procurement - many a times it may take anywhere between 3-6 months for finalisation of vendor Procured goods/services not inline with the business requirements Efforts of vendor and project costs overshooting budgets Unable to measure SLAs leading to delays in payments Levying penalties leading to delays/terminations delayed payments and loss to the vendors - leading terminations Litigations/court cases by vendors or government Outcomes Objectives not met, Investment loss, significant delays in projects - eventually leading to winding up projects and Creating negative trend/perceptions on IT/e-Governance

45 Slide 45 It requires in clarity in getting what is needed Clarity in what is needed from solution – requirements Clarity in what is expected from vendor – scope of work Clarity in capabilities needed to deliver solution – qualification and evaluation criteria Clarity in what matters – cost or quality (L1 vs QCBS/QBS) Clarity in how to measure solution and serviced delivered by vendor – KPIs/SLAs Clarity in investments needed in project lifecycle - payment schedule & business model Clarity in efforts needed in delivering solution – project/implementation schedule……. Procurement Approach determines project success

46 Slide 46 Need to spend sufficient time and energies in getting the ‘clarity’ Should avoid hurrying up to get into RFP writing Like DPR, RFP is only a culmination of work performed in earlier stages of project development, but not an output on its own… Procurement Approach determines project success

47 Slide 47 Need to spend sufficient time and energies in getting the ‘clarity’ Should avoid hurrying up to get into RFP writing Like DPR, RFP is only a culmination of work performed in earlier stages of project development, but not an output on its own… Procurement Approach determines project success RFP Development is here….. Before getting there, its important spend quality time and efforts in earlier phases of project….

48 Slide 48 Regulatory Framework for Public Procurement Public Procurement operates on the backbone of a broad framework of National laws dealing with relevant aspects of procurement. - Indian Contract Act, 1872; Sale of Goods Act, 1930; Companies Act, 1956; Arbitration & Conciliation Act, 1996; Limitation Act, 1963; Right to Information Act, 2005 Public Procurement in India is a State subject, and thereby the Regulatory Framework governing Public Procurement varies from State to State ‘General Financial Rules’ (GFR), framed by the central financial ministry acts as the guideline for public procurement, but has only subordinate legislation status Various states have adopted their own Legal framework, based on the GFR and other best practices Procurement funded by external donors (World Bank, ADB etc) follows guidelines by the donor in this regard

49 Slide 49 Procurement in e-Governance Projects – Life cycle Assess Procurement Options Renegotiate existing contract/ Develop RFP / Bidding document Develop Draft Contract Publish RFP Selection of Vendor Finalise Contract Sign Contract Business Case for procurement Understand cost components Assess existing contracts / fresh procurement Set up Contract Governance Monitoring and Evaluation Exit Management Periodic Review Phase 4: Contract Management Phase 1: Business Case Phase 2: Decide Procurement Strategy Phase 3: Procurement

50 Slide 50 Business Case for undertaking the project The Business Case phase include the following activities, which usually results in a Feasibility Study Report and Detailed Project Report (DPR) - Defining Objectives, Vision and Mission for the initiative - Study of Best Practices from similar contexts - Stakeholder Consultations - Understand cost components for the project - Detailed analysis of business case - Business justification for the project (better service levels) - Cost Benefit Analysis - Analysis of risks and mitigation measures In case of transition from existing system / vendor, the analysis of benefits of continuing with the current arrangement vs. fresh procurement is carried out This is a very important but often ignored phase in any e-Governance initiative

51 Slide 51 Deciding on Procurement Strategy Identify & Segregate Project Components Assess Procurement Options for components Develop Procurement Plan Identify components of the project Segregate components that can be self managed and to be outsourced Identify opportunities to bundle components Develop Tender Document Finalize Eligibility and Technical Evaluation Criteria Finalize approach to arrive at best value bid Develop Draft Contract Consider alliances with other agencies Finalize procurement method for each component Determine Business Model / type of vendor relationship Determine business and service levels

52 Slide 52 Identifying Project Components ICT Strategy and Consultancy: ICT strategy, defining ICT architecture, ICT security, RFP preparation for ICT vendor and procurement, contract management, and training Applications development / Software implementation: Custom applications development, deployment of COTS products, Project Management Deployment IT Infrastructure: Hosting infrastructure and storage, distributed infrastructure and LAN servers (desktop, laptops, printers, software licenses, local servers) Operations and Maintenance: Operations management (operations administration, database management etc.), service delivery, helpdesk support, facilities management. Communications: Communications infrastructure (network connectivity, PABX, videoconferencing, etc.), voice (fixed and mobile), and data/ISP

53 Slide 53 Single vs. Multiple Vendors Single sourcing: Optimum option if all the components for external sourcing can be bundled into one group Suited for smaller agencies and agencies in which ICT is not highly strategic or customized Subcontracting and Consortium arrangements may be used to bring in diverse capabilities with one single entity taking overall responsibility More cost effective than managing multiple vendors Multiple Vendors Better suited for large agencies with highly specific and strategic ICT functions Provides greater control over vendor performance Requires higher capacities in the department and higher coordination risk Allows for best of the breed solutions in each component Identify opportunities for bundling outsourced components: One or Multiple outsourcing vendors

54 Slide 54 Planning the Procurement Based on the Procurement context, any of the following procurement modes may be employed: - Two stage competitive process: Expression of Interest, followed by Request for Proposal open to bidders qualified from EoI process - Single stage competitive process: Request for Proposal open to all bidders fulfilling the qualifying criteria - Request for Quotes: Used for standardized requirements, in which price is the only deciding factor - Procurement from Rate Contracts: For items with standard specification, for which Rates have already been negotiated in the form of a Rate Contract by a nodal agency and economies of scale can be obtained - Single sourcing / Nomination: In cases where the required Solution / Product is available from only one vendor and there are no suitable alternatives (strong justification required)

55 Slide 55 Single Stage vs. Two Stage Two Stage Process: Most appropriate for systems with one or more of the below factors: Complex Business Applications (e.g. Creation of Land Records using GPS based techniques) Systems in which finalization of requirements will need industry inputs Extensive Software development Complex technologies (e.g. photographic equipment such as for advanced cadastres, large scale data processing equipment etc) Single Stage Process Procurement of Standard Technical products / service specifications (e.g. packaged software like Accounting, HRMS etc) Requirements can be specified to great degree of accuracy and bidders have no major design discretion Market offerings are standardized and are comparable Comparison of offerings does not favour any particular technology / vendor

56 Slide 56 Two Stage Process – EoI Stage Expression of InterestRefinement of Requirements Client's high level understanding of the business requirement presented in the EoI document Solicits responses from bidders fulfilling certain eligibility criteria, detailing the following: Bidder’s capabilities relevant to the business need Bidder’s proposed solution Bidder’s suggestions to refine the requirements Attractiveness of the procurement opportunity to the vendors is gauged (market’s ability and desire to provide the requirements) Requirements are refined based on the valid suggestions from the EoI responses The refined RFP is published for final selection – open to bidders who responded to the EoI Second Stage of the Two Stage process is the RFP process

57 Slide 57 Request for Proposal A Request for Proposal (RFP) an invitation for suppliers, often through a bidding process, to submit a proposal on a specific commodity or service The RFP process brings structure to the procurement decision and allows the risks and benefits to be identified clearly upfront The RFP will have to specify in great detail, the following requirements of the Buyer: -Technical and Functional Requirements -Bid Process and Commercial Specifications -Contractual and Legal Specifications The RFP is usually structured in 3 Volumes with one Volume for each one of the above requirements

58 Slide 58 Overview of selection through RFP Preparation of RFP Preparation of Draft Contract Publishing of RFP Pre-bid Clarifications Corrigenda / Addenda Bid Preparation & Submission Prequalification & Technical Evaluation Commercial Evaluation Final Selection RFP Preparation and Publishing Bidding Process Bid Evaluation Process

59 Slide 59 RFP Volume I: Functional and Technical Specifications Contents of Volume I are: -Introduction & Detailed Background of the Project -Project Vision, Mission and Objectives -Services Definition -Detailed Scope of Work for the Vendor -Functional Architecture & Requirements -Technical Architecture & Requirements (including Security Requirements) -Other Requirements (e.g. Data Migration, Digitization etc) -Timelines for implementation of the Project -Project Deliverables Illustrative

60 Slide 60 RFP Volume II: Bid Process & Commercial Specifications Contents of Volume II are: -Bidding Terms and Conditions (Guidelines for preparing proposal) -Pre-qualification Criteria -Technical Evaluation Criteria -Bid Opening and Evaluation Process -Evaluation of Commercial Bids -Negotiations, Contract Finalization and Award -Formats for providing bid response Pre-qualification Technical and Commercial Illustrative

61 Slide 61 RFP Volume III: Contractual and Legal Specifications Contents of Volume III are: -Roles and Responsibilities of Stakeholders -Service Level Agreement -Master Service Agreement Scope of Services under the Contract Breach, Rectification and Termination Intellectual Property Rights Disputes & Amendments Change Control Schedule Exit Management Program Governance Structure & Schedule Payment Terms and Schedule Implementation Schedule To be discussed in detail in the later sessions Illustrative

62 Slide 62 General Statements on Scope and Requirements… This is only a high level scope of work and detailed scope of work shall be finalized during execution The requirements indicated below are illustrative…the specific requirements shall be determined during execution……. The vendor shall develop system to address any additional requirements as they come up during project development… System should do ……………… “etc” Vendor shall not charge any additional costs for new requirements identified during implementation stage…………. How to cost for services/requirements which are not known???? Is there a provision for scope change management? Is there provision for assessment of efforts for additional requirements and paying for such additional services????

63 Slide 63 Pre-Qualification Evaluation Pre-qualification stage is used to ensure bids from those bidders who have the necessary technical and financial capabilities are evaluated Pre-qualification criteriaWhy is it importantRelevant documentation Years in operation To ensure company is an established player Company Registration Certificate Company Turnover (last 3 yrs) from relevant operations (e.g. IT / ITES projects) Turnover should be around 5 times the estimated project cost Audited Financial Reports Company profit (last 3 yrs) To ensure the company is not loss making Audited Financial Reports Experience of relevant previous projects Capability to handle project of the same scale Citations / Work Orders Minimum professional strength To ensure the company has the requisite skills Undertaking from Authorised Signatory of company Relevant Certifications (e.g. CMMI Level 5) To ensure Software Standards Relevant Certificate copy

64 Slide 64 Technical Evaluation Technical bids of only those bidders who qualify the pre-qualification stage shall be opened The Technical Bid is evaluated against pre-defined criteria. The following criteria are used to evaluate technical bids: - Technical Solution proposed by the vendor - Proposed solution and its compliance to functional requirements - IT Infrastructure and Hardware Design - Security Architecture - Approach & Methodology - Project Management, Risk Management & Quality Management approach - Past Credentials - Specific experience of projects similar to the current project - Broad experience in related domains - Proposed Personnel - Quality of staff proposed for key roles - Quality of manpower available with the company

65 Slide 65 Sample Technical Evaluation Matrix NoParameterMax ScoreMin Cut Off 1Proposed Technical Solution4030 1.1Technologies & s/w platforms proposed10 1.2Solution design & approach10 1.3H/W and Infrastructure design10 1.4Security Architecture & Features10 2Approach & Methodology2015 2.1Implementation Approach10 2.2Project Management5 2.3Quality Management5 3Past Credentials2519 3.1Experience in implementing similar projects 15 3.2Experience In large Government Sector Projects in India5 3.3Experience as a systems integrator5 4Proposed Personnel1511 4.1Quality of manpower of the firm5 4.2Domain Exp. and Skill Sets of key personnel7 4.3Proposed team structure3 Total10075

66 Slide 66 Defining Technical Evaluation Criteria Break down each criteria into sub criteria and define objective parameters against each criteria Sl. No.CriteriaMarks awarded Max marks 3.1Experience in implementing Health Management Information Systems (HMIS) in India 10 Bidder to submit 2 citations (max 5 marks per citation): a.For each citation with the following criteria (3 marks) Web based solution with n-tier architecture > 200 concurrent users b.If the citation is for government client, 1 bonus mark to be given c.If the project involved service delivery through PPP, 1 bonus mark to be given

67 Slide 67 Selection Methods Once the Technical Bids are evaluated and Technical score of each bidder is finalized, the final selection can be done based on a number of selection methods Based on the requirement of the department, any of the following selection methods may be chosen - Quality and Cost Based Selection (QCBS) - Quality Based Selection (QBS) - Least-Cost Selection (L1) - Fixed Budget Selection (FBS) - Consultants’ Qualifications Selection

68 Slide 68 Quality and Cost based Selection (QCBS) QCBS takes into account both the quality of the technical proposal and the cost of the services to be provided QCBS allows for a reasonable tradeoff between quality and cost Technical proposals are given weightage of 60-90%, with minimum cut-off at 60-75% Technical Evaluation Commercial Evaluation Final Selection Evaluate Technical bid and provide technical evaluation score (T) Eliminate bidders who scored less than cutoff Evaluate Commercial bid Normalize commercial bids score to 100 (C). Lowest bidder will score 100. Other bidders will be scored proportionately The bidder with the lowest composite score will be selected S = T*w t +C*w f w t and w f are the technical and financial weightage

69 Slide 69 Quality Based Selection (QBS) Quality-based selection (QBS) is a method based on evaluating only the quality of the technical proposals and the subsequent negotiation of the financial proposal and the contract with the consultant who submitted the highest ranked technical proposal QBS is appropriate when: - assignments are complex or highly specialized making it difficult to define precise Terms of Reference and the requires input from the consultants - assignments where the downstream impact is so large that the quality of the services is of overriding importance for the outcome of the project - assignments that can be carried out in substantially different ways such that financial proposals maybe difficult to compare The Technical Proposals are evaluated in the same way as in QCBS, and negotiations are carried out with the highest ranked bidder for arriving at the cost of services

70 Slide 70 Least Cost Selection Least Cost Selection (LCS) is only appropriate for selecting consultants for very small assignments where well-established practices and standards exist Consist in setting a minimum quality mark and selection of the lowest financial proposal from the companies that are above the minimal financial score Technical proposals will be opened first and evaluated. Bidders securing less than the minimum qualifying mark will be rejected, and the financial proposals of the rest will be opened and compared The firm with the lowest price shall then be selected and invited to negotiate and finalize the contract. Technical Evaluation Short listing of bidders above cut- off score Selection of lowest technically qualified bidder

71 Slide 71 Selection under Fixed Budget (SFB) Selection under Fixed Budget (SFB) is based on disclosing the budget to the bidders and selection of the vendor with the highest technical score within the estimated budget Having the financial constraint, the bidders will adjust methodology and quality to the available budget Fixed budget selection (FBS) is appropriate when - the TOR are precisely defined, - the time and personnel inputs can be accurately assessed, - the budget is fixed and cannot be exceeded Technical Bids are evaluated and bidders are ranked based on the technical score. Financial bids of bidders with qualifying technical score are opened Bidder with the highest technical score within the fixed budget is awarded the contract

72 Slide 72 Summary of Selection methods SELECTION PROCEDURE TECHNICAL EVALUATION FINANCIAL EVALUATION COMBINED EVALUATION SELECTION OF THE WINNING FIRM QCBS Points and Scores Scores Weighted Scores (e.g. T- 80/P-20) Highest Combined Score QBS Points and Scores Highest Technical Score N.A. Highest Technical Score FIXED BUDGET Points and Scores Proposals Within Budget N.A. Highest Technical Score within budget LEAST COST Points and Scores Minimum Technical Score N.A. Lowest Price among qualified technical bids

73 Slide 73 Some considerations for defining Commercial Bid Formats All bidders should be on a level playing field – with knowledge of all cost components in the project In case of bought out mode of operation: - Overall commercial quote to be obtained under logical heads (Software development cost, Deployment hardware cost, AMC cost etc) - Component level cost to be obtained under each major head In case of PPP/ transaction fee based model: - Bidder to be provided with all possible cost components and their quantity required over the contract period - Bidder to be provided historical data and trends to project the expected transactions during contract period - Individual cost components to be sought, in case of items under re-imbursement (e.g. hardware, consumables etc)

74 Slide 74 End of Session


Download ppt "Slide 1 Course: e-Governance Project Lifecycle Day 3 Session 4 DPR & RFP Preparation."

Similar presentations


Ads by Google