Course: e-Governance Project Lifecycle

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

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

What is a Detailed Project Report or DPR?
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 – e-Governance/Reference documents section The Detailed Project Report is an essential building block for the project initiative. Preparation of DPR is a step in firming up a proposed initiative The DPR is to be prepared with sufficient details about the project to ensure appraisal, approval, and subsequent project implementation in a timely and efficient manner.

What is a DPR used for? 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 DPR involves a detailed study on various aspects of the project and should be prepared before the Selection of Vendors. Detailed project report is a comprehensive document that can be used as a basis for investment decision making, approval of plans and designs, project planning, implementation scheduling and budgeting for all types of projects.

e-Governance Project Lifecycle (eGLC)
When is a DPR prepared? 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.. This slide indicates the tentative period in the e-Governance Lifecycle where the DPR is prepared

e-Governance Project Lifecycle (eGLC)
When is a DPR prepared? 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.. 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 This slide indicates the tentative period in the e-Governance Lifecycle where the DPR is prepared

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. Feasibility study report is the primary report for formulation of the initiative. Investment decisions are taken based on the details incorporated in the study. The feasibility study report includes system identification and define overall objectives of the system proposed to be designed. Detailed project report is a complete document for investment decision-making, approval, planning whereas feasibility study report is a base document for investment decision-making. Detailed project report is prepared not only for the investment decision-making approval, but also execution of the project and also preparation of the plan.

Main Sections of a DPR* *Based on DIT guidelines- Jan 09
Section III : Project details including its implementation model Section II : Project overview Section I : Background of project and other basic information Once the scoping study has been undertaken, the unit would prepare a detailed project report (DPR) in the DPR template. This template has been divided into three sections, as follows: • Section I : Background of project and other basic information • Section II : Project overview • Section III : Project details including its implementation model The unit responsible for preparation of the project proposal is advised to refer to these guidelines while preparing the proposal. The Units should refer to the following documents for preparing the detailed project proposal: • Any standards/ guidelines brought out for implementation of NeGP projects. For the latest standards/ guidelines for NeGP, click on • Any other relevant guidelines issued by DIT with respect to Capacity Building, Project Implementation, Institutional Arrangement etc. *Based on DIT guidelines- Jan 09

Section I: Background of project and other basic information
Title of the Project Whether existing Mission Mode Project (MMP) Eligibility Tests- NeGP or Best Practice Alignment Whether Pilot or Roll out Project Initiator details Implementing Agency details Location of project implementation Section I : Background of project and other basic information SECTION I: BACKGROUND OF PROJECT AND OTHER BASIC INFORMATION This section requires provision of information regarding the name, its nature, the initiating and implementing bodies of the project. a) Title of the Project: For example: Detailed Project Report for Commercial Taxes Department, Tamilnadu; Detailed Project Report for e-District Project, Alwar District, Rajasthan, etc. b) Does the project fall under an existing Mission Mode Project (MMP)? If yes, indicate which? For example: Gram Panchayats, e-Districts etc. c) Eligibility Tests: whether the project clears the two broad eligibility tests proposed for NeGP project proposals. These tests probe the project alignment with (i) NeGP; (ii) Best practice. id) Pilot or Roll out: Is the project: A Pilot, A Roll out of the project subsequent to Pilot phase or Roll out Project without Pilot phase e) Project Initiator details Department/ Ministry initiating the project (Centre or State) Background of the department/ ministry iii) Name and Job Title of the key contact person (person responsible for initiation) iv) Contact details: f) Implementing Agency details i) Name of the Implementing Agency (in case it is not a Ministry or Department at the Centre or State level), ii) Date of Establishment (if applicable)-only in cases where the responsibility for implementation is totally outsourced to an external entity. Else, the proposed date of incorporation of the Project e-Mission Team should be provided here. iii) Name and Job Title of the key contact person (person responsible for implementation) iv) Contact details : g) Location of project implementation

Section II: Project overview
Identification of stakeholders Problem to be addressed by project Causes and effects of the problem Category of services: G2C, G2B or G2G Proposed Services Past experience and lessons learnt Key activities and timelines Project costs Source of funding From EGLC Phases: Vision & Strategy Development Current State Assessment To-be State Definition From EGLC Phases: Implementation Approach and Sourcing This section provides an overview of the project primarily in terms of: a) Identification of all stakeholders: Anybody who is affected by or can influence the programme/ project is called a stakeholder. The process of stakeholder identification/ interaction typically results in improved project effectiveness, efficiency, equity, sustainability, transparency and accountability. All the relevant stakeholders associated with the project should be identified. b) Introduce the problem/issue this project is designed to address The specific problem(s) or issue(s) faced by Citizens, Businesses or Governments that would be addressed by means of provision of improved services through the proposed project should be identified and mentioned in the form of a statement. c) Explain in brief the causes and effects of the problem/ issue The causes due to which the problem(s) has arisen and the effect(s) of the problem(s) should be discussed in brief. d) Identify the categories under which the services fall: Government to Citizen (G2C), Government to Business (G2B) or Government to Government (G2G). e) Highlight in concrete terms the improvements envisaged for each of these services (in terms of service levels). Service levels refer to the parameters that can be used in measuring the efficiency, transparency & reliability of the core services in terms of -Service quality, Service quantity, Service delivery time, Service cost f) Past Experience and lessons learnt: description of past experience of the concerned Project Implementation Agency/Department/State/Other States in carrying out similar projects and lessons learnt from there and incorporated in this project. g) Outline in broad terms project activities and timelines for Planning, Scoping Study, Process Re-engineering, Infrastructure (including technology) Adoption, Change Management (Legal Issues, Awareness creation, Capacity Building), Monitoring, Evaluation and Assessment, Human Resource Development, Other project specific activities h) Summary of total project cost: A formal cost estimate should be prepared with documented assumptions, using a consistent methodology, and historical data, if available. A summary of the total project cost estimated should be provided for the complete duration of the project. i) Sources of funding: The proposed sources of funding for the project should be indicated for entire period of the project.

Section III: Project details
Section III : Project details including its implementation model 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 Discussed in previous section Stakeholder Analysis 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 This section provides details of the Project including the goals, objectives, services and service levels, implementation strategy, key activities to be undertaken under the project, organisation structure, assumptions and risks, demand estimation, project costs, financing model, implementation arrangements and detailed work plan. Goal: The goal is a higher order objective/longer term outcome that the project will contribute to. The general practices of the project are guided by the goal. It is critical to set realistic and relevant goal(s) for the project For example: Ensure satisfied citizens and government by developing a hassle free and transparent tax filing process enabling increased levels of tax compliance. b) Objectives: Identify SMART objectives: Objectives are the specific and immediate outcomes of the project. S.M.A.R.T refers to the acronym that describes the key characteristics of meaningful objectives, which are Specific, Measurable, Achievable, Realistic and Time Bound. Example of how to convert an Objective into SMART Objective: Objective: Deliver services to the stakeholders in minimum turnaround time and minimal physical interaction with the Department. SMART Objective: “Increase efficiency and reduce turnaround time involved in filing of taxes, sales purchases reconciliation (Value Added Tax) and vehicle checking and monitoring at all check posts (Octroi) in order to benefit Citizens and Businesses through use of Information Technology tools”. c) Stakeholder Analysis d) Identification of services and service levels Service is defined as the core services that are delivered by the Ministry/ department/ Service levels refer to the parameters that can be used in measuring the efficiency, transparency & reliability of the core services in terms of- Service Quality, Service Quantity, Service delivery time, Cost of service- e.g. Online (Quality) dealer registration in 1 day (Time) along with provision of additional services such as registration renewal (Quantity) without any service charges (Cost) In case of the NeGP, services would be provided under the Mission Mode Projects (MMPs).

Section III: Project details (contd..)
Section III : Project details including its implementation 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 This section provides details of the Project including the goals, objectives, services and service levels, implementation strategy, key activities to be undertaken under the project, organisation structure, assumptions and risks, demand estimation, project costs, financing model, implementation arrangements and detailed work plan. Goal: The goal is a higher order objective/longer term outcome that the project will contribute to. The general practices of the project are guided by the goal. It is critical to set realistic and relevant goal(s) for the project For example: Ensure satisfied citizens and government by developing a hassle free and transparent tax filing process enabling increased levels of tax compliance. b) Objectives: Identify SMART objectives: Objectives are the specific and immediate outcomes of the project. S.M.A.R.T refers to the acronym that describes the key characteristics of meaningful objectives, which are Specific, Measurable, Achievable, Realistic and Time Bound. Example of how to convert an Objective into SMART Objective: Objective: Deliver services to the stakeholders in minimum turnaround time and minimal physical interaction with the Department. SMART Objective: “Increase efficiency and reduce turnaround time involved in filing of taxes, sales purchases reconciliation (Value Added Tax) and vehicle checking and monitoring at all check posts (Octroi) in order to benefit Citizens and Businesses through use of Information Technology tools”. c) Stakeholder Analysis d) Identification of services and service levels Service is defined as the core services that are delivered by the Ministry/ department/ Service levels refer to the parameters that can be used in measuring the efficiency, transparency & reliability of the core services in terms of- Service Quality, Service Quantity, Service delivery time, Cost of service- e.g. Online (Quality) dealer registration in 1 day (Time) along with provision of additional services such as registration renewal (Quantity) without any service charges (Cost) In case of the NeGP, services would be provided under the Mission Mode Projects (MMPs).

Section III : Project details including its implementation 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 This section provides details of the Project including the goals, objectives, services and service levels, implementation strategy, key activities to be undertaken under the project, organisation structure, assumptions and risks, demand estimation, project costs, financing model, implementation arrangements and detailed work plan. Goal: The goal is a higher order objective/longer term outcome that the project will contribute to. The general practices of the project are guided by the goal. It is critical to set realistic and relevant goal(s) for the project For example: Ensure satisfied citizens and government by developing a hassle free and transparent tax filing process enabling increased levels of tax compliance. b) Objectives: Identify SMART objectives: Objectives are the specific and immediate outcomes of the project. S.M.A.R.T refers to the acronym that describes the key characteristics of meaningful objectives, which are Specific, Measurable, Achievable, Realistic and Time Bound. Example of how to convert an Objective into SMART Objective: Objective: Deliver services to the stakeholders in minimum turnaround time and minimal physical interaction with the Department. SMART Objective: “Increase efficiency and reduce turnaround time involved in filing of taxes, sales purchases reconciliation (Value Added Tax) and vehicle checking and monitoring at all check posts (Octroi) in order to benefit Citizens and Businesses through use of Information Technology tools”. c) Stakeholder Analysis d) Identification of services and service levels Service is defined as the core services that are delivered by the Ministry/ department/ Service levels refer to the parameters that can be used in measuring the efficiency, transparency & reliability of the core services in terms of- Service Quality, Service Quantity, Service delivery time, Cost of service- e.g. Online (Quality) dealer registration in 1 day (Time) along with provision of additional services such as registration renewal (Quantity) without any service charges (Cost) In case of the NeGP, services would be provided under the Mission Mode Projects (MMPs).

Section III : Project details including its implementation 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 This section provides details of the Project including the goals, objectives, services and service levels, implementation strategy, key activities to be undertaken under the project, organisation structure, assumptions and risks, demand estimation, project costs, financing model, implementation arrangements and detailed work plan. Goal: The goal is a higher order objective/longer term outcome that the project will contribute to. The general practices of the project are guided by the goal. It is critical to set realistic and relevant goal(s) for the project For example: Ensure satisfied citizens and government by developing a hassle free and transparent tax filing process enabling increased levels of tax compliance. b) Objectives: Identify SMART objectives: Objectives are the specific and immediate outcomes of the project. S.M.A.R.T refers to the acronym that describes the key characteristics of meaningful objectives, which are Specific, Measurable, Achievable, Realistic and Time Bound. Example of how to convert an Objective into SMART Objective: Objective: Deliver services to the stakeholders in minimum turnaround time and minimal physical interaction with the Department. SMART Objective: “Increase efficiency and reduce turnaround time involved in filing of taxes, sales purchases reconciliation (Value Added Tax) and vehicle checking and monitoring at all check posts (Octroi) in order to benefit Citizens and Businesses through use of Information Technology tools”. c) Stakeholder Analysis d) Identification of services and service levels Service is defined as the core services that are delivered by the Ministry/ department/ Service levels refer to the parameters that can be used in measuring the efficiency, transparency & reliability of the core services in terms of- Service Quality, Service Quantity, Service delivery time, Cost of service- e.g. Online (Quality) dealer registration in 1 day (Time) along with provision of additional services such as registration renewal (Quantity) without any service charges (Cost) In case of the NeGP, services would be provided under the Mission Mode Projects (MMPs).

Section III : Project details including its implementation 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) This section provides details of the Project including the goals, objectives, services and service levels, implementation strategy, key activities to be undertaken under the project, organisation structure, assumptions and risks, demand estimation, project costs, financing model, implementation arrangements and detailed work plan. Goal: The goal is a higher order objective/longer term outcome that the project will contribute to. The general practices of the project are guided by the goal. It is critical to set realistic and relevant goal(s) for the project For example: Ensure satisfied citizens and government by developing a hassle free and transparent tax filing process enabling increased levels of tax compliance. b) Objectives: Identify SMART objectives: Objectives are the specific and immediate outcomes of the project. S.M.A.R.T refers to the acronym that describes the key characteristics of meaningful objectives, which are Specific, Measurable, Achievable, Realistic and Time Bound. Example of how to convert an Objective into SMART Objective: Objective: Deliver services to the stakeholders in minimum turnaround time and minimal physical interaction with the Department. SMART Objective: “Increase efficiency and reduce turnaround time involved in filing of taxes, sales purchases reconciliation (Value Added Tax) and vehicle checking and monitoring at all check posts (Octroi) in order to benefit Citizens and Businesses through use of Information Technology tools”. c) Stakeholder Analysis d) Identification of services and service levels Service is defined as the core services that are delivered by the Ministry/ department/ Service levels refer to the parameters that can be used in measuring the efficiency, transparency & reliability of the core services in terms of- Service Quality, Service Quantity, Service delivery time, Cost of service- e.g. Online (Quality) dealer registration in 1 day (Time) along with provision of additional services such as registration renewal (Quantity) without any service charges (Cost) In case of the NeGP, services would be provided under the Mission Mode Projects (MMPs).

Section III : Project details including its implementation 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 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 This section provides details of the Project including the goals, objectives, services and service levels, implementation strategy, key activities to be undertaken under the project, organisation structure, assumptions and risks, demand estimation, project costs, financing model, implementation arrangements and detailed work plan. Goal: The goal is a higher order objective/longer term outcome that the project will contribute to. The general practices of the project are guided by the goal. It is critical to set realistic and relevant goal(s) for the project For example: Ensure satisfied citizens and government by developing a hassle free and transparent tax filing process enabling increased levels of tax compliance. b) Objectives: Identify SMART objectives: Objectives are the specific and immediate outcomes of the project. S.M.A.R.T refers to the acronym that describes the key characteristics of meaningful objectives, which are Specific, Measurable, Achievable, Realistic and Time Bound. Example of how to convert an Objective into SMART Objective: Objective: Deliver services to the stakeholders in minimum turnaround time and minimal physical interaction with the Department. SMART Objective: “Increase efficiency and reduce turnaround time involved in filing of taxes, sales purchases reconciliation (Value Added Tax) and vehicle checking and monitoring at all check posts (Octroi) in order to benefit Citizens and Businesses through use of Information Technology tools”. c) Stakeholder Analysis d) Identification of services and service levels Service is defined as the core services that are delivered by the Ministry/ department/ Service levels refer to the parameters that can be used in measuring the efficiency, transparency & reliability of the core services in terms of- Service Quality, Service Quantity, Service delivery time, Cost of service- e.g. Online (Quality) dealer registration in 1 day (Time) along with provision of additional services such as registration renewal (Quantity) without any service charges (Cost) In case of the NeGP, services would be provided under the Mission Mode Projects (MMPs).

Service Level Management

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. Registration of companies Filing of returns Issuing passports Registration of birth and death Payment of taxes and duties…… Services provided by third parties Development of application software Implementation of IT infrastructure Maintenance of systems and infrastructure Establishment of call centre Establishment of service delivery centers etc…

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

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): Time for service completion Cost for service completion Accuracy of service delivered Completeness of service delivered Transparency in service delivery… Services provided by third parties: ‘Quality’ attributes of technical systems and services include: Completion of systems development in time, to the requirements, standards and cost… ‘Availability’ of services online ‘Performance’ of systems to deliver online services ‘Security’ of online services…..

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

Need for measuring the ‘Quality’ of services in e-Governance initiatives.. Government Services: ‘Quality’ attributes of government services need to be measured for: Understanding performance and perception of citizens To assess the outcomes and impact of initiatives undertaken for improving quality 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: To ensure compliance with defined performance levels – which in turn have impact on quality attributes of govt services Proactive identification and resolution of technical issues To ensure return on investment…. New trends in e-Governance includes leveraging third party service providers in delivering government services… 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

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

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 % (1 hr) SLA Are we listening to the customers??? User perception SLAs??? 99% system uptime with unsatisfied customers

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

Incentivizing performance Not only punitive measures Validity of SLAs through the project period Several SLAs become invalid during the contract period

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

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

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 Group Value Proposition (SLO) External: Customers, Suppliers, Financiers Efficiency, Convenience, Reliability, Responsiveness, Cost Effectiveness Internal: Employees, Management, Auditors Usability, Accountability, Traceability, Effectiveness Investment Area Value 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

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)

Sample SLA definition – G2B Service Delivery
Service Metrics Parameters Baseline Lower performance Breach Measurement method Metric Credit Service Related – Citizen Facing 1. Average wait-period at Service Centre (Peak dates , Peak hours) <15 min 15 15-25 min 10 >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 min 12 min 8 >20 min 3.Average wait-period at Service Centre (Non-Peak dates , Peak hours) < 5 min 9 5-10 min 6 >10 min 4.Average wait-period at Service Centre (Non-Peak dates , Non- Peak hours) No waiting 7 0 – 3 min 5

Sample SLA definition – G2B Service Delivery
Service Metrics Parameters Baseline Lower performance Breach Measurement method Metric Credit Service Related – Citizen Facing 1. Average wait-period at Service Centre (Peak dates , Peak hours) <15 min 15 15-25 min 10 >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 min 12 min 8 >20 min 3.Average wait-period at Service Centre (Non-Peak dates , Peak hours) < 5 min 9 5-10 min 6 >10 min 4.Average wait-period at Service Centre (Non-Peak dates , Non- Peak hours) No waiting 7 0 – 3 min 5 SLA Parameter SLA Metric SLA Enforcement SLA Measurement

Sample SLA definition – 2
Service Metrics Parameters Baseline Lower performance Breach Measurement method Metric Credit Technology – Performance Related Capacity of the Application Server 10000 service transactions per hour 6 No tolerance for lower performance. Zero credit will be given for performance below baseline <6000 -6 Measurements 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 hour 5 >3 hours -5

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

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 seconds (which does not adversely affect the SLO of user experience). Setting a portal load time of 2 seconds is unrealistic

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

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%

Deduction Method – Illustrative example
Sl. no: SLA Parameter Metric Baseline Lower Breach 1 Time taken for setting up Deployment Infrastructure Up to 15 days from Letter of Intent 15-30 days (Penalty of Rs 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)

Addition Method – Illustrative example
Service Metrics Parameters Baseline Lower performance Breach Metric Credit Service Related – Citizen Facing 1. Average wait-period at Service Centre (Peak dates , Peak hours) <15 min 12 15-25 min 6 >30 min 2.Average wait-period at Service Centre (Peak dates, Non-Peak hours) < 10 min 8 min 4 >20 min 3.Average wait-period at Service Centre (Non-Peak dates , Peak hours) < 5 min 5 5-10 min 2 >10 min 4.Average wait-period at Service Centre (Non-Peak dates , Non- Peak hours) No waiting 0 – 3 min > 3 min Total Credit 30 14

Service Metrics Parameters Baseline Lower performance Breach Metric Credit Service Related – Citizen Facing 1. Average wait-period at Service Centre (Peak dates , Peak hours) <15 min 12 15-25 min 6 >30 min 2.Average wait-period at Service Centre (Peak dates, Non-Peak hours) < 10 min 8 min 4 >20 min 3.Average wait-period at Service Centre (Non-Peak dates , Peak hours) < 5 min 5 5-10 min 2 >10 min 4.Average wait-period at Service Centre (Non-Peak dates , Non- Peak hours) No waiting 0 – 3 min > 3 min Total Credit 30 14 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.

Service Metrics Parameters Baseline Lower performance Breach Metric Credit Service Related – Citizen Facing 1. Average wait-period at Service Centre (Peak dates , Peak hours) <15 min 12 15-25 min 6 >30 min 2.Average wait-period at Service Centre (Peak dates, Non-Peak hours) < 10 min 8 min 4 >20 min 3.Average wait-period at Service Centre (Non-Peak dates , Peak hours) < 5 min 5 5-10 min 2 >10 min 4.Average wait-period at Service Centre (Non-Peak dates , Non- Peak hours) No waiting 0 – 3 min > 3 min Total Credit 30 14 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 = 21%. Hence 21%+70% (fixed part of payout) will be paid to the vendor

General perceptions of Government Procurement
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 (contd..)
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

Outcomes 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 Objectives not met, Investment loss, significant delays in projects - eventually leading to winding up projects and Creating negative trend/perceptions on IT/e-Governance

Procurement Approach determines project success
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
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…

RFP Development is here…..
Procurement Approach determines project success 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… RFP Development is here….. Before getting there, its important spend quality time and efforts in earlier phases of project….

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

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

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

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 Consider alliances with other agencies Finalize procurement method for each component Determine Business Model / type of vendor relationship Determine business and service levels Develop Tender Document Finalize Eligibility and Technical Evaluation Criteria Finalize approach to arrive at best value bid Develop Draft Contract

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

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

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)

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

Two Stage Process – EoI Stage
Expression of Interest Refinement 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

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

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

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

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

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 Illustrative To be discussed in detail in the later sessions

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

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 criteria Why is it important Relevant 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 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

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

Sample Technical Evaluation Matrix
No Parameter Max Score Min Cut Off 1 Proposed Technical Solution 40 30 1.1 Technologies & s/w platforms proposed 10 1.2 Solution design & approach 1.3 H/W and Infrastructure design 1.4 Security Architecture & Features 2 Approach & Methodology 20 15 2.1 Implementation Approach 2.2 Project Management 5 2.3 Quality Management 3 Past Credentials 25 19 3.1 Experience in implementing similar projects <to be defined> 3.2 Experience In large Government Sector Projects in India 3.3 Experience as a systems integrator 4 Proposed Personnel 11 4.1 Quality of manpower of the firm 4.2 Domain Exp. and Skill Sets of key personnel 7 4.3 Proposed team structure Total 100 75

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

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

Quality and Cost based Selection (QCBS)
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*wt +C*wf wt and wf are the technical and financial weightage 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%

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

Least Cost Selection Technical Evaluation
Short listing of bidders above cut-off score Selection of lowest technically qualified bidder 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.

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

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 Highest Technical Score N.A. Fixed Budget Proposals Within Budget Highest Technical Score within budget Least Cost Minimum Technical Score Lowest Price among qualified technical bids

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)

End of Session

Course: e-Governance Project Lifecycle

Similar presentations

Presentation on theme: "Course: e-Governance Project Lifecycle"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Course: e-Governance Project Lifecycle

Similar presentations

Presentation on theme: "Course: e-Governance Project Lifecycle"— Presentation transcript:

Similar presentations

About project

Feedback