the e-pragati authority, goape-pragati.in/download-files/epragati-rfp-for-rera.pdf · real estate...

1

REQUEST FOR PROPOSAL (RFP) FOR SELECTION OF

SYSTEM INTEGRATOR

TO

DESIGN, DEVELOP, INTEGRATE, MAINTAIN AND ENHANCE APPLICATION & SERVICES FOR

Real Estate Regulatory Authority (APRERA)

IN ANDHRA PRADESH STATE

June, 2018

Tendering Agency

The e-Pragati Authority, GoAP 3rd Floor, NTR Administrative Block

Pandit Nehru Bus Station, Vijayawada – 520 001

e-Pragati Authority - Develop, Maintain, Enhance and Application/Services for GoAP of 91

Proprietary & Confidential No part of this document can be reproduced in any form or by any means, disclosed or distributed to any person without the prior consent of the e-Pragati Authority (GoAP) except to the extent required for submitting a proposal and no more.


Request for Proposal (RFP) Structure This Request for Proposal (RFP) is meant to invite proposals from interested members of the empaneled system integrators (SI) panel capable of delivering the services described herein. The content of this RFP has been acknowledged in Single volume explained in following document:


OFFICE OF THE CHIEF EXECUTIVE OFFICER, THE E-PRAGATI AUTHORITY

NOTICE

THE E-PRAGATI AUTHORITY

Request for Proposal - Call Notice for “Design, Develop, Integrate, Maintain and Enhance Application & Services Proposed by Real Estate Regulatory Authority (APRERA) on e-Pragati Core

Platform, hosted by e-Pragati Authority for Government of Andhra Pradesh ”

Time schedule of various Proposal related events:

Release of Request for Proposal (RFP) Wednesday, June 20th, 2018 11:00 AM

Last date for submission of online questions by bidders

Friday, June 22nd, 2018 08:00 AM

Pre- Bid Conference Friday, June 22nd, 2018 12:00 PM

Date of Issue of Clarifications Monday, June 25th, 2018 11:00 AM

Last date for Submission of bids Thursday, June 28th, 2018 11:00 AM

Bid Opening Date Thursday, June 28th, 2018 03:00 PM

Letter of Award Friday, June 29th, 2018 02:00 PM

RFP Document Cost Rs. 10,000 (in words Ten Thousand only)

Contact points from e-Pragati authority Mr. Vikram Baheti, Consultant - +91-9823448250 Mr. Madhava Katru, HR & Admin Manager - +91-9959224312

Contact Details of POC [email protected], Mob. +91-9959224312

For further details please visit http://www.e-pragati.in/Proposals.aspx Chief Executive Officer, The e-Pragati Authority, GoAP 3rd Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 001, India Note: The document can be purchased by submitting the document fee in the form Demand Draft/ Banker’s cheque in favor of “CEO E-PRAGATI AUTHORITY AP, VIJAYAWADA” Payable at Vijayawada.

http://www.e-pragati.in/aptsTenders.aspx


Notice Inviting Proposal (NIP) Name of work – Selection of Empanelment System Integrator to Design, Develop, Integrate, Maintain and Enhance Application & Services for AP Real Estate Regulatory Authority (APRERA) Department as a part of Digital Transformation Drive of Government of Andhra Pradesh entrusted with Special Purpose Vehicle (SVP), e-Pragati Authority. On behalf of the Government of Andhra Pradesh (“GoAP”), the Chief Executive Officer (“CEO”), The e-Pragati Authority, Government of Andhra Pradesh, invites eligible and competent Proposers to submit their qualification, technical and commercial proposals for the selection to design, develop,, maintain and enhance software application/service, in accordance with conditions and manner prescribed in this Request for Proposal (RFP) and other Proposal Documents issued by the e-Pragati Authority, GoAP, which is available on its website ( http://www.e-pragati.in ). CEO, the e-Pragati Authority reserves the right to reject any or all proposals without assigning any reason.

Sd/- CEO, e-Pragati Authority

http://www.e-pragati.in/


Procedure to Submit proposal on AP e-Procurement Platform:

Procedure for Bid SubmissionThe Bidder shall submit their response through document submission

process on e-Procurement platform at www.apeprocurement.gov.in by following the procedure given

below:The Proposer would be required to register on the e-procurement platform www.apeprocurement.gov.in or https://tender.apeprocurement.gov.in and submit their proposals online. In case any Proposer is not able to upload the entire set of documents on e-procurement platform either due to space/size constraint or any other technical hitches, only in such cases, the relevant hard copies of the left over documents which could not be uploaded on e-procurement platform may be submitted in sealed covers in e-Pragati Authority office located at 3rd Floor, NTR Administrative Block, Pandit Nehru Bus Station, NH-65, Vijayawada, Andhra Pradesh, before the stipulated closure time of proposal submission. A self-certificate from the Proposer in this regard detailing the reasons for submitting the hard copies, if any, duly bringing out issues faced in uploading them on e-procurement platform, if any, shall also be submitted. The uploaded documents on the e-procurement platform and the hard copies submitted in sealed covers, if any, together will be treated as a single set of documents under a proposal and will be evaluated accordingly. The Proposers shall submit their necessary documents for empanelment proposal online in e-Procurement web site. The Proposers shall upload the scanned copies of all the relevant certificates, documents etc., in support of their Pre-Qualification and other certificates/documents with clear readability, in the e-Procurement web site. The Proposer should sign on all the statements, documents, certificates uploaded in the e-Procurement website, owning responsibility for their correctness/authenticity.

Registration with e-Procurement platform: For registration and online proposal submission Proposers may contact HELP DESK on

www.apeprocurement.gov.in or https://tender.apeprocurement.gov.in

Digital Certificate authentication: The Proposer shall authenticate the proposal with the agency’s Digital Certificate for submitting the proposal electronically on e-Procurement platform and the proposals not authenticated by digital certificate of the Proposer will not be accepted on the e-Procurement platform. For obtaining Digital Signature Certificate, you may contact:

http://www.apts.gov.in/digital.aspx Hard copies: All the Proposers shall submit the hardcopy of the DD towards the proposal processing fee in e-Pragati Authority office at Vijayawada before proposal due date. All the Proposers shall invariably upload the scanned copies of DD/BG in e-Procurement system and this will be the primary requirement to

consider the proposal responsive. 1 e-Pragati Authority shall carry out the technical evaluation solely based on the uploaded

certificates/documents, DD/BG towards EMD (if applicable) in the e-Procurement system and

open the price proposals of the responsive and technically qualified Proposers only.

http://www.apeprocurement.gov.in/


https://tender.apeprocurement.gov.in/

http://www.apts.gov.in/digital.aspx


2 e-Pragati Authority will notify the successful Proposer for submission of original hardcopies of all the uploaded documents and DD/BG towards EMD (if applicable) prior to entering into

agreement. 3 The successful Proposer shall invariably furnish the original DD/BG towards EMD (if

applicable); Certificates/Documents of the uploaded scanned copies to the RFP Inviting Authority before entering into agreement, either personally or through courier or post and the receipt of the same within the stipulated date shall be the responsibility of the successful Proposer. e-Pragati Authority will not take any responsibility for any delay in receipt/non-receipt of original DD/BG towards EMD (if applicable), Certificates/Documents from the

successful Proposer before the stipulated time.

4 On receipt of documents, e-Pragati Authority shall ensure the genuinity of the DD/BG towards EMD (if applicable) and all other certificates/documents uploaded by the Proposer in e-Procurement system in support of the qualification criteria before concluding the agreement.

Deactivation of Bidders Vide Ref GO Ms. No.174 – I&CAD dated 1-9-2008, if any successful Proposer fails to submit the original hard copies of uploaded certificates/documents within stipulated time or if any variation is noticed between the uploaded documents and the hardcopies submitted by the Proposer, the successful Proposer will be suspended from participating in the RFPs on e-Procurement platform for a period of 3 years. The e-Procurement system would deactivate the user ID of such defaulting Proposer based on the trigger/recommendation by the RFP Inviting Authority in the system. Besides this, e-Pragati Authority shall invoke all processes of law including criminal prosecution of such defaulting Proposer as an act of extreme deterrence to avoid delays in the RFP process for execution of the development schemes taken up by the government. Other conditions as per RFP document are applicable. The Proposer is requested to get a confirmed acknowledgement from the RFP Inviting Authority a proof of Hardcopies submission to avoid any discrepancy.

1 Payment of Transaction Fee: It is mandatory for all the participant Proposers from 1st January 2006 to electronically pay a prescribed non-refundable Transaction fee to M/s. APTS, the service provider through "Payment Gateway Service on E-Procurement platform". The Electronic Payment Gateway accepts all Master and Visa Credit Cards

Andhra Pradesh Technology Services Limited, Vijayawada www.apts.gov.in/ (OR)

You may please contact any Registration Authorities of Certifying Authorities in India. The list of CAs is available in the link provided below.

https://tender.apeprocurement.gov.in/DigitalCertificate/signature.html issued by any bank and Direct Debit facility/Net Banking to facilitate the transaction. This is in compliance as per G.O.Ms. 13 dated 07.05.2006.

2 Corpus Fund: As per GO MS No.4, user departments shall collect 0.04% of ECV (estimated project cost) with a cap of Rs.10,000 (Rupees ten thousand only) for all works with ECV up to Rs.50 Crores, and Rs.25,000/- (Rupees twenty-five thousand only) for works with ECV above Rs.50 Crores, from successful Proposers on e-Procurement platform before entering into agreement / issue of purchase orders, towards e-procurement fund in favor of Managing Director, APTS. There shall not be any charge towards e-Procurement fund in case of works, goods and services with ECV less than and up to Rs. 10 lakhs

https://tender.apeprocurement.gov.in/DigitalCertificate/signature.html


3 RFP Document:

The Proposer is requested to download the RFP document and read all the terms and conditions mentioned in the RFP Document and seek clarification if any from the RFP Inviting Authority. Any offline proposal submission clause in the RFP document could be neglected. The Proposer has to keep track of any changes by viewing the Addendum/Corrigenda issued by the RFP Inviting Authority from time-to-time in the e-Procurement platform. The Department calling for RFPs shall not be responsible for any claims/issues arising out of this.

4 Bid Submission Acknowledgement: The Proposer shall complete all the processes and steps required for Bid submission. The system will generate an acknowledgement with a unique proposal submission number after completing all the prescribed steps and processes by the Proposer. Users may also note that the proposals for which an acknowledgement is not generated by the e-procurement system are treated as invalid or not saved in the system. Such invalid proposals are not made available to the RFP Inviting Authority for processing the proposals. The Government of AP is not responsible for incomplete proposal submission by users.

4.1 The Proposers may contact the Admin and HR Manager, e-Pragati Authority

Vijayawada for any further information / clarifications on e-procurement. 4.2 The Proposers need to register on the electronic procurement market place of

Government of Andhra Pradesh i.e., www.apeprocurement.gov.in . On registration in the e-procurement market place they will be provided with a user ID and password

by the system using which they can submit their proposals on line. 4.3 While registering on the e-procurement market place, the Proposers need to scan and

upload the required documents as per the RFP requirements on to their profile. The e-procurement market place provides an online self-service registration facility to all such Contractors who are already registered with respective participating departments for supply of specified goods and services.

4.4 All the Proposers shall invariably upload the scanned copies of DD/BG in e-Procurement system and this will be the primary requirement to consider the proposal as responsive. The Department shall carry out the Technical proposal evaluation solely based on the uploaded certificates/documents, DD/BG towards EMD (if applicable) in the e-procurement system and open the price proposal of the eligible and responsive Proposers. The Department will notify the successful Proposer for submission of original hard copies of all uploaded documents and DD/BG towards

EMD (if applicable) prior to entering into agreement. 4.5 The Proposers shall furnish a declaration in online stating that the soft copies

uploaded by them are genuine. Any incorrectness/deviation noticed will be viewed seriously and apart from cancelling the work duly forfeiting the EMD (if applicable), criminal action will be initiated including suspension of business.

Process for empanelment of Pega registered partner with e-Pragati: Refer: Tender ID – 171294 on www.apeprocurement.gov.in




PROPRIETARY & CONFIDENTIAL .................................................................................................................. 2

REQUEST FOR PROPOSAL (RFP) STRUCTURE ................................................................................................ 3

NOTICE ...................................................................................................................................................... 4

NOTICE INVITING PROPOSAL (NIP) .............................................................................................................. 5

PROCEDURE TO SUBMIT PROPOSAL ON AP E-PROCUREMENT PLATFORM: ................................................... 6 REGISTRATION WITH E-PROCUREMENT PLATFORM: .........................................................................................................6 DIGITAL CERTIFICATE AUTHENTICATION: .......................................................................................................................6

PROCESS FOR EMPANELMENT OF PEGA REGISTERED PARTNER WITH E-PRAGATI: ........................................ 8

DEFINITIONS ............................................................................................................................................ 11

DISCLAIMER ............................................................................................................................................. 14

PREAMBLE ............................................................................................................................................... 16

1 PURPOSE OF THE RFP ...................................................................................................................... 17

2 SCHEDULE OF EVENTS...................................................................................................................... 18 2.1 TENTATIVE CALENDAR OF EVENTS .............................................................................................................. 18

3 INTRODUCTION TO E-PRAGATI AUTHORITY ...................................................................................... 19 3.1 CORE PLATFORM .................................................................................................................................... 19 3.2 DATALYTICS ........................................................................................................................................... 22 3.3 LEGACY APPLICATIONS OF THE DEPARTMENTS .............................................................................................. 22 3.4 LOCALIZATION ........................................................................................................................................ 22 3.5 CORE DASHBOARD .................................................................................................................................. 22 3.6 LINE DEPARTMENT APPLICATIONS: ............................................................................................................. 23 3.7 HIERARCHY OF THE STAKE HOLDERS ........................................................................................................... 25 3.8 SI PANEL SYSTEM AND RESOLUTION OF CONFLICTS ....................................................................................... 27

4 INTRODUCTION TO DEPARTMENT .................................................................................................... 29

5 FUNCTIONAL SCOPE OF THE RFP ...................................................................................................... 30 5.1 OVERVIEW ............................................................................................................................................. 30 5.2 REQUIREMENT GATHERING STANDARDS: ..................................................................................................... 36 5.3 DESIGN STANDARDS: ............................................................................................................................... 36 5.4 DEVELOPMENT STRATEGY: ........................................................................................................................ 37 5.5 CHANGE REQUEST ................................................................................................................................... 37 5.6 TESTING: ............................................................................................................................................... 38 5.7 GO LIVE REQUIREMENTS .......................................................................................................................... 39 5.8 OPERATIONS AND MAINTENANCE REQUIREMENTS ........................................................................................ 39

6 PROJECT METHODOLOGIES .............................................................................................................. 41 6.1 DELIVERY METHODOLOGY: ....................................................................................................................... 41 6.2 USER STORIES ........................................................................................................................................ 41 6.3 SPRINT DELIVERABLES: ............................................................................................................................. 42 6.4 OWNERSHIP OF DELIVERABLES .................................................................................................................. 43

7 PAYMENT TERMS ............................................................................................................................ 44 7.1 METHOD OF PAYMENT ............................................................................................................................ 44 7.2 PAYMENT CYCLE ..................................................................................................................................... 44 7.3 INCOME TAX RULE COMPLIANCE ................................................................................................................ 44 7.4 LIQUIDATED DAMAGES ............................................................................................................................ 44 7.5 PAYMENT SCHEDULES AND MILESTONES ..................................................................................................... 45 7.6 ASSUMPTIONS FOR COUNTING OF DAYS FOR ALL THE SLA AND TIMELINES ......................................................... 45

8 MILESTONES AND DELIVERABLES ..................................................................................................... 46 8.1 DELIVERABLES AND MILESTONES IN COMPLIANCE WITH SPRINT CYCLE .............................................................. 46

9 ACCEPTANCE CRITERIA .................................................................................................................... 49


9.1 ACCEPTANCE CRITERIA DEFINITION ............................................................................................................ 49 9.2 ACCEPTANCE CRITERIA TEMPLATE .............................................................................................................. 49 9.3 ACCEPTANCE CRITERIA FOR SI: .................................................................................................................. 49 9.4 GO LIVE REQUIREMENTS .......................................................................................................................... 51 9.5 CODE REVIEW CHECKLIST TEMPLATE FOR SPRINT REVIEW .............................................................................. 51

10 PROPOSED SPRINT TEAM COMPOSITION ......................................................................................... 53 10.1 PROPOSED O&M TEAM COMPOSITION ...................................................................................................... 53

11 SERVICE LEVEL AGREEMENT ............................................................................................................. 54 11.1 SERVICE LEVEL AGREEMENTS..................................................................................................................... 54 11.2 TIMELY IMPLEMENTATION OF SOFTWARE MODULES...................................................................................... 55

12 TERMS AND CONDITIONS ................................................................................................................ 62 12.1 CONTRACT TERMS ................................................................................................................................... 62 12.2 PRE-BID CONFERENCE ............................................................................................................................. 62 12.3 BIDDER INQUIRIES AND E-PRAGATI RESPONSES ............................................................................................. 63 12.4 SUPPLEMENTARY INFORMATION / CORRIGENDUM / AMENDMENT TO THE RFP.................................................. 63 12.5 PROPOSAL PREPARATION COSTS: ............................................................................................................... 64 12.6 RIGHT TO TERMINATE THE PROCESS OF RFP BY E-PRAGATI AUTHORITY ............................................................. 64 12.7 ACCEPTANCE OF PART / WHOLE BID / MODIFICATION – RIGHTS THEREOF: .......................................................... 64 12.8 AUTHENTICATION OF BIDS ........................................................................................................................ 64 12.9 INTERLINEATIONS IN BIDS ......................................................................................................................... 64 12.10 CONSORTIUM BIDS .................................................................................................................................. 65 12.11 VENUE & DEADLINE FOR SUBMISSION OF PROPOSALS .................................................................................... 65 12.12 LATE BIDS .............................................................................................................................................. 65 12.13 CONDITIONS UNDER WHICH THIS RFP IS ISSUED ............................................................................................ 65 12.14 RIGHTS TO THE CONTENT OF THE PROPOSAL: ............................................................................................... 65 12.15 MODIFICATION AND WITHDRAWAL OF PROPOSALS: ...................................................................................... 66 12.16 NON-CONFORMING PROPOSALS: ............................................................................................................... 66 12.17 ACKNOWLEDGEMENT OF UNDERSTANDING OF TERMS: .................................................................................. 66 12.18 OFFER VALIDITY PERIOD ........................................................................................................................... 66 12.19 LANGUAGE OF PROPOSALS........................................................................................................................ 66 12.20 NON-DISCLOSURE OF CONFIDENTIAL INFORMATION ...................................................................................... 66 12.21 CRITERIA FOR ELIGIBILITY OF SYSTEM INTEGRATOR FOR CONCURRENT PROJECT .................................................. 69

13 MASTER SERVICE AGREEMENT (MSA) .............................................................................................. 70

14 EVALUATION PROCESS .................................................................................................................... 76 14.1 PREQUALIFICATION CRITERIA ..................................................................................................................... 76 14.2 COMMERCIAL EVALUATION ....................................................................................................................... 76

15 ANNEXURE ...................................................................................................................................... 81 15.1 FORM P1: LETTER OF EMPANELMENT ......................................................................................................... 81 15.2 FORM P2: PENDING LITIGATION ................................................................................................................ 82 15.3 FORM P3: FORMAT FOR SELF-DECLARATION ON BLACKLISTING ....................................................................... 83 15.4 FORM P4: SELF-DECLARATION/ SELF- CERTIFICATION (COI) ........................................................................... 84 15.5 FORM P5: FORMAT OF THE LETTER OF UNDERSTANDING AND COMMITMENT .................................................... 85 15.6 FORM P6: PROJECT PLAN ......................................................................................................................... 86 15.7 FORM P7: RESUME FORMAT .................................................................................................................... 87 15.8 FORM P8: STATUS OF ENGAGEMENT OF SI FOR CONCURRENT PROJECTS WITH E-PRAGATI ................................... 89 15.9 FORM C1: COMMERCIALS ........................................................................................................................ 90


Definitions

Acronym Expansion

AE Assistant Engineer

AEE Assistant Executive Engineer

APTS Andhra Pradesh Technology Service AS Administrative Sanction

B2G Business to Government

BPR Business Process Re-engineering

C2G Customer to Government CE Chief Engineer

CFMS Centralized Funds Management System

CMS Content Management System COTS Commercially of The Shelf products

CRM Customer Relationship Management

CRUD Create/Read/Update/Delete

CSP / DCO Cloud Service Provider / Data Center Operator D-Code Departmental Codes

DAO Divisional Accounts Officer

DC Data Center DEE Deputy Executive Engineer

Dept. Department

DPR Detailed Project Report DR Disaster Recovery

DSS Decision Support Systems

EE Executive Engineer

EMD Earnest Money Deposit EMI Equated Monthly Instalment

ENC Engineer –in – Chief

EOL End of Life ePI e-Performance Indicator

ePRS e-Pragati Requirements Specifications

EQI Equated Quarterly Instalment

ERP Enterprise Resource Planning

ESI Empaneled System Integrator

ETL Extract, Transform and Load

FAQ Frequently Asked Questions FR Functional Requirements

G2B Government to Business

G2C Government to Customer

G2G Government to Government GIS Geographical Information System

GO Government Order

GoAP Government of Andhra Pradesh GoI Government to India

Govt. Government

GPS Global Positioning System

HA High Availability HLD High Level Design


IaaS Infrastructure as a Service IAM Identity Access Management

IOPS Input/output operations per second

IoT Internet of Things

ISMS Information Security Management System ISO International Organization for Standardization

ITE&C Information Technology, Electronics & Communication

ITIL Information Technology Infrastructure Library IVR Interactive Voice Response

JMS Java Message Service

KPI Key Performance Indicator

LAO Letter of Agreement LLD Low Level Design

Line Department Concerned Department for this RFP

LOC Line of Credit MB / M Book Measurement Book

MDDS Metadata and Data Standards

MFT Managed File Transfer

MIS Management information System MLA Member of Legislative Assembly

MOM Minutes of Meeting

MRR Maintenance of Rural Roads

MSB Maintenance of School Buildings

MSP Managed Service Provider

NAC Network Access Control NOC No-Objection Certificate

O&M Operations & Maintenance

OEM Original Equipment Manufacturer

ORM Object-Relational Mapping OTP One Time Password

PaaS Platform as a Service

PAO Pay and Accounts Office PBG Performance Bank Guarantee

PCI DSS Payment Card Industry Data Security Standard

PIU Project Implementation Unit

PM Performance Management Package PMU Project Monitoring Unit

PoC Proof of Concept

PSR Project Status Report QA Quality Assurance

QC Quality Control

RFID Radio-Frequency Identification

RFP Request for Proposal RPO Recovery Point Objective

RTM Reverse Traceability Matrix

RTO Recovery Time objective

SAN Storage Area Network

SAS Serial Attached SCSI

SATA Serial Advanced Technology Attachment

SCSI Small Computer System Interface


SDC State Data Center SE Superintendent Engineer

SI Systems Integrator

SLA Service Level Agreement

SMAC Social Media Analytics Cloud SME Subject Matter Expert

SMS Short Message Service

SNS Simple Notification Service SOA Service Oriented Architecture

SOAP Simple Object Access Protocol

SOP Standard Operating Procedures

SQC Software Quality Control SRS Software Requirement Specification

SSD Solid State Drive

SSO Single Sign-On TS Technical Sanction

UAT User Acceptance Testing

UI User Interface

UML Unified Modelling Language USSD Unstructured Supplementary Service Data

VLAN Virtual Local Area Network

VLB Virtual Load Balancer

VM Virtual Machines

VPC Virtual Private Cloud

VPN Virtual Private Network w.r.t with respect to

WBS work breakdown structure

WCAG Web Content Accessibility Guidelines

WSDL Web Services Definition Language WSR Work Status Report

Xn Number of User stories proposed & mutually agreed between e-Pragati & SI for specific Sprint

XSD XML Schema Definition


Disclaimer The information contained in this Request for Proposal (the “RFP”) or subsequently provided to Proposers (as defined hereinafter), whether verbally or in documentary or any other form by or on behalf of the CEO, e-Pragati Authority (as defined hereinafter) or any of its employees or advisors, is provided to Proposers (as defined hereinafter) on the terms and conditions set out in this RFP and such other terms and conditions subject to which such information is provided. The nature of this RFP Tender is Closed Tender and limited to Empaneled System Integrators with e-Pragati Authority. Proposer for this RFP are limited to 5 System Integrators who have completed set process, are as below:

1. Areteans Tech 2. JK Technosoft Ltd 3. Ruletronics Systems Pvt. Ltd. 4. Tech Mahindra 5. Yash Technologies

This RFP is not an agreement and is neither an offer nor invitation by the e-Pragati Authority to the prospective Proposers or any other person. The purpose of this RFP is to provide interested parties with information that may be useful to them in preparing and submitting their Proposals (as defined hereinafter). This RFP includes statements, which reflect various assumptions and assessments arrived at by the e-Pragati Authority in relation to the Project. Such assumptions, assessments and statements do not purport to contain all the information that each Proposer may require. This RFP may not be appropriate for all persons, and it is not possible for the e-Pragati Authority, their respective employees or advisors to consider the investment objectives, financial situation and needs of each person who reads or uses this RFP. The assumptions, assessments, statements and information provided in this RFP Documents (as defined hereinafter) may not be complete, accurate, adequate or correct. Each Proposer should, therefore, conduct its own investigations and analysis and should check the accuracy, adequacy, correctness, reliability and completeness of the assumptions, assessments, statements and information contained in this RFP and obtain independent advice from appropriate sources. Information provided in and pursuant to this RFP to Proposer is on a wide range of matters, some of which may depend upon the interpretation of the law. The information given is not intended to be an exhaustive account of statutory requirements and should not be regarded as a complete or authoritative statement of law. The e-Pragati Authority and GoAP accepts no responsibility for the accuracy or otherwise of any interpretation or opinion of law expressed herein. The e-Pragati Authority and GoAP, their respective employees and advisors make no representation or warranty and shall have no liability to any person, including any Proposer under any law, statute, rules or regulations or tort, principles of restitution or unjust enrichment or otherwise for any loss, damages, cost or expense which may arise from or be incurred or suffered on account of anything contained in this RFP or otherwise, including the accuracy, adequacy, correctness, completeness or reliability of the RFP Documents and/or any assessment, assumption, statement or information contained in or deemed to form part of this RFP Documents or arising in any way in connection with participation in the Proposal Submission process in respect of the Project. The e-Pragati Authority and GoAP accepts no liability of any nature whether resulting from negligence or otherwise howsoever caused arising from the reliance of any Proposer upon the statements contained in this RFP Documents.


The e-Pragati Authority may in its absolute discretion, but without being under any obligation to do so, update, amend or supplement the information, assessment or assumptions contained in this RFP Documents. The issue of this RFP Documents does not imply that the e-Pragati Authority is bound to evaluate a Proposer or to appoint the Successful Proposer for the Project and e-Pragati Authority reserves the right to reject all or any of the Proposers or Proposals without assigning any reason whatsoever. The Proposer shall bear all costs associated with or relating to the preparation and submission of its Proposal including but not limited to preparation, copying, postage, delivery fees, expenses associated with any demonstrations or presentations which may be required by the e-Pragati Authority or any other costs incurred in connection with or relating to its Proposal. All such costs and expenses will be to the account of the Proposer, and the e-Pragati Authority shall not be liable in any manner whatsoever for the same or for any other costs or other expenses incurred by a Proposer in connection with preparation or submission of the Proposal, regardless of the conduct or outcome of the Proposal Submission process.


Preamble The e-Pragati is a long-term sustained endeavor. As aware, the Government of Andhra Pradesh, under the aegis of the Hon’ble Chief Minister, Sri N Chandrababu Naidu Garu, has declared that e-Pragati will be the flagship program of Government of Andhra Pradesh that will help the government make a smooth transition from real-time government to real-time governance. Under the e-Pragati Platform, around 24 Unique in nature IT projects across all departments that can cater to more than 200 plus Citizen Centric services are planned to be implemented and rolled out. To make this program a success the following objectives must be achieved.

a. Understand Departments Businesses and its processes.

b. Transform it through Business Process Re-engineering.

c. Shift this re-engineered Business Process from being Government Centric to Citizen Centric.

d. Digitize the reengineered citizen-centric business process.

The government aims to deliver all its citizen related services through a single portal and experience “ONE” Government through an integrated application, data and services architecture as designed by Sri J. Satyanarayana Garu, (Retd.) IAS, IT Advisor to CM, Government of Andhra Pradesh.


1 Purpose of the RFP The purpose of this RFP is to enable e-Pragati to select a System Integrators from the pool of Empaneled System Integrators with e-Pragati Authority to Design, Develop, Integrate, Maintain and Enhance Application & Services for AP Real Estate Regulatory Authority (APRERA) Department, based on requirement document and inputs provided by Line Departments of Andhra Pradesh. The requirements mentioned in these documents may change during the execution period, based on the interaction among e-Pragati Authority, Line Departments and System Integrator, and all these changes have to be recorded and submitted to “Project Awarding Committee” for approval, System Integrator will be responsible for gathering and documenting these changes. The concerned department in case of this RFP is Line Department of Andhra Pradesh. The RFP is not an offer by e-Pragati but an invitation to receive proposals from eligible and interested bidders in respect of the above-mentioned project and limited to Empaneled System Integrators with e-Pragati Authority. The RFP does not commit e-Pragati to enter into a binding agreement in respect of the project with the potential bidders. Potential bidders who are already registered with e-Pragati Authority and possess an authorized Letter of Empanelment (LoE), are henceforth referred to as “Bidders” in this document. List of Empaneled System Integrators as on Tuesday, 22nd May 2018.

1. Areteans Tech 2. JK Technosoft Ltd 3. Ruletronics Systems Pvt. Ltd. 4. Tech Mahindra 5. Yash Technologies


2 Schedule of Events This RFP is issued by e-Pragati to the bidders and is intended to procure cloud services.

S. No. Item Description

1 Project Title Selection of ESI to Design, Develop, Integrate, Maintain and Enhance Application & Services

for AP Real Estate Regulatory Authority (APRERA) Department

2 Project Initiator / RFP Issuer Details The e-Pragati Authority, ITE&C, GoAP

3 Department Department of MA&UD, GoAP AP Real Estate Regulatory Authority (APRERA)

Department 4

Contact points from e-Pragati authority Mr. Vikram Baheti, Consultant Mr. Madhava Katru, HR & Admin Manager

5 Contact Details of POC

[email protected] Mob. +91-9959224312

6 Address for the purpose of Bid Submission

and all other communications

The e-Pragati Authority, GoAP 3rd Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 001

7 Correspondence CEO, e-Pragati Authority, GoAP

8 Website www.e-pragati.in

9 EMD Exempted 10 PBG The winning SI must submit the PBG of 10% of

proposed quote as a security at the time of signing a contract with the e-Pragati Authority or Line Department.

2.1 Tentative Calendar of Events The following table enlists important milestones and timelines for completion of bidding activities:

S. No. Description Date and Time

1 Release of Request for Proposal (RFP) Wednesday, June 20th, 2018 11:00 AM

2 Last date for submission of online questions by bidders Friday, June 22nd, 2018 08:00 AM 3 Pre- Bid Conference Friday, June 22nd, 2018 12:00 PM

4 Date of Issue of Clarifications Monday, June 25th, 2018 11:00 AM

5 Last date for Submission of bids Thursday, June 28th, 2018 11:00 AM

6 Opening of Bids Thursday, June 28th, 2018 03:00 PM

7 Letter of Award Friday, June 29th, 2018 02:00 PM

mailto:[email protected]

http://www.e-pragati.in/


3 Introduction to e-Pragati Authority 3.1 Core Platform The e-Pragati: An initiative of GoAP, aiming to deliver all its citizen-centric services through a single portal. Government envisioned to implement an integrated application, data and services architecture to bring around 72 IT projects on the same platform, including implementation and rollout of 24 unique IT projects and 800 citizen services in FY 2017-18; along with below objectives:

o Business Process Reengineering to shift process from Government-centric to Citizen-centric

o Digitize, implement workflow, automate and integrate re-engineered business process There have been numerous e-governance initiatives undertaken in various states one of them is also single window implementation for G2C, G2B, G2G etc. services, however, these initiatives faced major challenges during implementation. The major setback was due to the absence of government departments on boarding on the portal; all the services offered by the department were not added to the portal. The other was the time-consuming development of service delivery channel/ platform/ application, causing an overall delay in the project development. There were other crucial challenges that led to the failure of the state data portals. The main challenges faced by citizens and government departments are identified as below along with the probable outcomes which can be achieved after implementing the Core Application.

FIGURE 1: MAIN CHALLENGES FACED BY CITIZENS AND GOVERNMENT DEPARTMENTS

To realize the vision of GoAP, it is imperative to provide integrated services to citizens through the free flow of information, integrated services through common state e-Pragati portal. Further, GoAP envisions having e-Pragati Core Platform to enable GoAP to develop a flexible business application with fewer resources and as faster pace along with analytical capabilities while protecting the existing assets of GoAP. The envisaged e-Pragati core platform is intended to be established as a foundational layer for Government of AP users and the broader eco-system covering partners, distributors, suppliers and dealers. The common platform would enable rapid deployment and support model-driven architectures, Domain users or the government officials would be able to collaborate closely with the technology team and enable rapid agile deployments using a zero-coding, visual interfaces which would support run-time code development and deployment. The customers would be able to leverage the benefits of one Government interface based on the common platforms, the technology teams


would be able to save time and efforts through multi-channel developments and code base management. These components would be supported through the following key functionalities:

o Multi-user and multi-layer technology compatible channels

o Zero/ low code platforms

o Data and management layers

o Integration Layer

FIGURE 2: CORE PLATFORM TECHNICAL STACK

The core solution components include:

o The presentation layer would cover the delivery channels through which services would be consumed by the users. It would cover a broad range of current and future-ready interoperable and compatible mediums enabling a truly connected eco-system within the ambit of e-Pragati.

o The core platform will include business intelligence, service development and creation platform and integration layer, it would promote and support zero/ low coding requirements to enable rapid application development through a package of libraries and ready, out-of-the-box service templates and support in developing a truly connected government in AP.

o Data layer and management would have the functionality to enable the seamless exchange of data from the existing and planned data hubs, databases, data warehouses and data lakes.

o Security would be also a critical part covering ACL, encryption, SSO and roles-based access controls.

The core platform will be built up on top of the core products like Pega, MuleSoft, WSO2, PostgreSQL, Cassandra and Greenplum. The high-level technology layer has been presented below in continuation to the solution architecture where the different solution capabilities have been mapped to the underlying technology components, the technology components have been carefully reviewed against the competing products available in the leading industry market leaders and selected considering the overall vision and requirements under e-Pragati.


FIGURE 3: BOM FOR TECHNICAL STACK

The technology components are mapped to the overall solution components as follows:

o The identity and security services would leverage from WSO2 identity server which supports the key requirements of e-Pragati core platform as well as leading security standards which have been described below in subsequent sections.

o Pega Omni-channel support in provisioning multi-compatible services and device independent services and web apps with native capabilities

o Pega Process Designer solution helps department users in developing solutions with zero coding through its model-driven architectures, smart shapes and drag-drop interfaces.

o The integration layer will be managed through Mulesoft and Pega BIX solution to establish an interoperable and connected environment within e-Pragati eco-system

o PostgreSQL along with Cassandra would support the data management layer

o Hortonworks will be used for data lakes

3.1.1 The e-Pragati Core Architecture (Logical)

Figure 4: e-Pragati Core Architecture (Logical)

e-P

raga

tiC

ore

Arc

hit

ect

ure

(Lo

gica

l)

Delivery LayerAPP Store e-Pragati Portal

People First

Mee Seva

1100RTGS

1

Core Data LayerGIS Hub PSS

Master Data Hub

Land Hub

IoT HubEntity Hub

2

Ch

ann

els

Inte

rfac

es

Citizen

Business

Employee

Depts

Infrastructure LayerAP FibreNet State Data Centre

e-Highway

APCSOC

IAMGateways

3

Pega Dev Platform LocalizationCLGS

Common Function LayerHRMS CFMS (e-Nidhi)

India Stack

DataLytics

e-Procuremente-Office

4

Attendance


More than 90% of the requirements are being directly met through Pega platform and the other solutions proposed like Mulesoft, PostgreSQL and Cassandra are out of the box configured with Pega platform to deliver the

envisaged functionalities.

3.2 DataLytics DataLytics application is an integrated Business Intelligence and Data Analytics system which includes conventional and Big Data. The system is proposed to be a state-wide Analytical Engine which takes in data from various government department databases, internet, sensors, machine logs and other sources, transforms them, and presents them in an analyzable format. Also, DataLytics provides tools for performing analysis on the data, and gain insights, make data-based predictions, and identify best course of action for improving operational efficiency and governance.

3.3 Legacy Applications of the Departments Government of Andhra Pradesh has been pioneering in the fields of Information Technology in Public Sector. A legacy of two decades of thriving for citizen service delivery model has resulted in multiple legacy systems in various departments of the Government of Andhra Pradesh. These systems are sufficing the current needs of the department and can be used in future.

3.4 Localization Under the National e-Governance plan project several Mission Mode Projects are initiated for providing services to the common man. Currently there are 31 Mission Mode projects encompassing Central and State and integrated ones. Several portals / sites are being designed, developed and deployed under each of the Mission Mode Projects. In order that the fruits of e-Governance reach the masses the services thus offered needs to be in ones’ mother tongue. India being a Multicultural, Multilingual country with 22 scheduled languages it becomes utmost crucial to provide the citizen services in the locality and in regional language. In order to deliver these services in multiple languages, it is crucial to follow Internationalization / localization standards. Standards adherence is crucial for interoperability of information and seamless access with various access devices. The proposed system should be able to host these applications facilitating the localization support on the go.

3.5 Core Dashboard CORE (CM Office Real-time Executive) Dashboard an initiative of Government of Andhra Pradesh is a visual display of the department’s information which need to achieve one or more objectives; consolidated and arranged in a single frame so that the information can be monitored effectively by Honorable Chief Minister at a glance. 33 State Government Departments are integrated in the CORE Dashboard. Various key statistics of concerned departments are published in the CORE Dashboard, which may provide key insights of Department activities.

3.5.1 Purpose of CORE Dashboard CORE Dashboards is designed and developed to address wide range of objectives & monitoring the strategy of Government of Andhra Pradesh which can check on department's activities in order to achieve service-level targets.


3.5.2 Characteristics of Core Dashboard

o All the visualizations pertaining to all departments fit in a single screen.

o It displays the department’s key performance indicators that can be monitored.

o Indicators such as filtering and drill-down can be used in dashboard; department’s key performance indicators actions which also include lag & lead performances district wise etc.

o The Core Dashboard can be accessed by the Departmental HODs/Officials to monitor effectively & take necessary actions if needed.

o The data gets automatically updated without any assistance from the user. The frequency of the data updating will vary with the departments. Dashboard data gets updated on a daily basis.

3.6 Line Department Applications:

FIGURE 5: E-PRAGATI APPLICATION ARCHITECTURE

3.6.1 App Store The vision of APP store is to: “Provide e-Governance services to citizens, Departments and business through digitally infrastructure (Mobile Applications) on a single platform for seamless Integration of all state and central government Departments and business, making transactions electronic and cashless. A unique platform with reusable components, Integration components for Developers to contribute and develop app useful for citizens”. Key Features of APP Store APP Store involves the development of an ecosystem that promotes the development of applications useful to the community and proliferation of the usage of those applications. The Key Features of APP Store are given below, to appreciate the nature of work involved in its creation.

o APP Store is a combination of the following platforms and components:

o Platform(s) for hosting of applications - existing and new applications

o Directory of Mobile services

o Repository of APIs relating various Government of AP applications

o Portal that manages the entire ecosystem of Applications, through their lifecycle

o The initial set of Applications for the APP Store shall be sourced through a rigid selection process from among the applications already prevalent in the public sector in AP. A targeted

e-P

raga

tiA

pp

licat

ion

Arc

hit

ect

ure

Primary Sector

Education Sector

Welfare Sector

PR & RWS

Rural Development

Urban Development

Revenue GroupPerformance Management

Public Safety Industries

Healthcare & Nutrition

Stand-alone Projects

Temples Mgt

Energy

Excise

Transportation

Disaster Management

CARD ++

Water Resources

e-PDS

e-Assembly

Logical Core

Inte

gra

tion

Arc

hit

ectu

re

Integ

ration

Arch

itecture


list of new Applications will be developed as a part of the e-Pragati Program through its Pega platform.

o All the Applications old and new shall conform to the standards and interfaces defined by the APP Store.

o The SIs of the brownfield projects of e-Pragati (already in position) and of the Greenfield projects (being selected currently), will be required to Publish a set of APIs relating to the domain for which they have/ would have developed applications. As a rule, all possible APIs would be required to be Published, excepting those which cannot be so Published for valid reasons to be recorded by the concerned line Department/ nodal Department.

o Developers, registering themselves on the Developer Portal, will be allowed to proceed with development of Applications on their platform, which would eventually be taken through a rigorous evaluation process before being accepted and hosted for public usage.

o An appropriate revenue-sharing formula would ensure that the Developers will have incentive to develop and maintain applications of high quality with a solid value proposition to the citizens and businesses.

3.6.2 One Portal The Government of Andhra Pradesh (GoAP) has a vision to facilitate the citizens, visitors, other service seekers and departments with a single point of access and service delivery to all government services and its offerings. They also intend to include citizens as a part of governance machinery wherein they provide feedbacks and inputs to the working model of government. The government wants to usher an era of good governance in the state with efficient and transparent service delivery. With this endeavor, they want to revamp the existing portal of Andhra Pradesh, which is mostly providing informative services to the citizens. The new portal would act as a single window of information dissemination and service delivery in a citizen centric manner through a common portal, known as One Portal. Vision of One Portal: “to be the single access point for all e-Services provided by the Government to the citizens, businesses and government for sustained development.” The objectives of One Portal:

o Making government services accessible while holding minimum interactions with the government

o One stop destination for information dissemination and service delivery

o Enhance efficiency and convenience of citizens and business while dealing with government machinery

o Impose transparency and accountability on the government officers while rendering the services

o availability of citizen charter and time bound SLA's for service delivery

o 24/7 availability of government services – web and/ or mobile

o Provide single sign-on for all citizens and businesses while seeking services from the portal

o Integrated with all third-party applications, department applications, and workflows etc.

o Provisioning MIS and dashboards for monitoring and performance management

o Access to the portal and its services, content etc. with minimal click

o 360-degree view of government to the citizen

o Enhanced user experience

3.6.3 CLGS The Certificate-less Governance System (CLGS) component of Core Platform is intended to lead to the abolition of most of the certificates and establish a Certificate less society across


State of AP. It aims to minimize the usage of physical documents (no scan/photocopies, no physical papers) or electronic formats across the stakeholders. It is also intended to eliminate the circulation of fake documents (no fake government/degree certificates, no fake usage of someone else’s certificate) via a mechanism to verify “authenticity” of government issued documents online. The CLGS System is to be integrated with NAD (National Academic Depository) for the Board and Universities certificates to ensure the authenticity.

3.7 Hierarchy of the Stake Holders

FIGURE 6: HIERARCHY OF STAKEHOLDERS

3.7.1 Line Departments or the e-Pragati Authority (Owners of the Project) The Line Department or the e-Pragati Authority is the sole owners of the projects. The line department shall identify the process to be automated/ digitised or problem statement for the purpose of the digitization. The e-Pragati Authority will complete the due process necessary for on-boarding the winning SI integrator from the Empaneled SI Panel and initiate a handshake between empaneled SI and line departments or e-Pragati Authority. Once, the member of Empaneled SI panel is on-boarded, there will be a mutual responsibility of the Line Department and the e-Pragati Authority to initiate the process for business process re-engineering from improvement and smart digitization perspective. This will include a final definition of the problem statement, requirements and minimum acceptable criteria etc. Line departments or e-Pragati authority are solely responsible for provision of funds and payments based on rate cards listed above towards the services incurred from empaneled SI based against the manhours utilizations. Line Department or the e-Pragati Authority will extend necessary support for the implementation of the project. This will include access to the platform, development, deployment, integration and UAT of the project. Commercial aspect will be executed based on the terms of the engagement established in the tender document of subsequent projects.

3.7.2 Master SI EY (India) has been identified as Master SI. Master SI will host all required IT infrastructure for the deployed resources and responsible for their maintenance & management including

Principal Secretary, ITE&C, GoAP

CEO, e-Pragati Authority

Empanelment Committee

Project Awarding Committee

The Master SI, COE and APTS

Members of SI Panel


insurance of manpower and equipment. Master SI will host all required IT infrastructure for the deployed resources and responsible for their maintenance & management including insurance of manpower and equipment. To participate in Empanelment Process, Master SI shall also submit his proposal in response to this invitation. The responsibility of Master SI: a) To ensure that global best practices are followed for infrastructure management,

architecture governance, research support, development of PoC (Proof of Concept),

common utility applications design/ development/ test/ maintain, overall e-Pragati

program delivery responsibility, Program/ project management,

design/development/Quality Assurance and training in connection with implementation

of the Platform and development of applications.

b) The Master SI is responsible for overall e-Pragati Infrastructure Managed services and

delivery.

c) The Master SI is responsible for completion of the assignment assigned by e-Pragati

Authority and line department and e-Pragati program coordination.

d) To provide architecture governance support, guidance and handholding for continuously

improvement, fine-tuning and advancement of the architecture.

e) Master SI will be responsible for Operations and Maintenance (O&M) of the e-Pragati

Core Platform (ePCP) for 5 years of duration.

f) Master SI will establish a Helpdesk and will be available for stakeholders to register issues

observed in applications/services developed by SI and as part O&M, SI has to resolve these

issues as and when registered.

3.7.3 Centre of Excellence (CoE) The Master SI will provide the resources for Centre of Excellence (CoE). The Centre of Excellence (CoE) will be stationed at the e-Pragati Authority head office. The e-Pragati Authority will be governing and monitoring body for the CoE. The CoE Team will operate from a fully functional office with the adequate number of resources as agreed in the terms of the engagement with Master SI. The COE will be responsible for end-2-end support, maintenance and related activities associated with the ePCP.

a) The Master SI will establish (provide technical Manpower) Centre of Excellence (“CoE”) and

develop a robust body of knowledge for executing government enterprise architecture and

technology planning, government process re-engineering, and application development for

delivery of citizen-centric services by all the departments of GoAP. These techniques,

methodologies, and processes developed over the period and benchmarked complying with

globally established practices shall be recognized as best practices of the e-Pragati Authority.

These practices and guidelines are directly applicable to the members of the SI Panel.

b) The e-Pragati Authority envisages a unique approach that separates architecture

(engineering) from implementation through setting up of Centre of Excellence. The objective

of CoE is to build Government of Andhra Pradesh Enterprise Architecture as flexible,

changeable, and reusable and capable of meeting current and future e-governance needs.

These services will be extended with and exploited from the successful winner members of

subsequent members of the SI Panel.

c) Overall responsibility of e-Pragati Enterprise Architecture Governance, monitoring, Advisory

support designing, development and management of e-Pragati Core Platform, design,

development, testing of e-Pragati Portal, CLGS, LMS, portal services listing integration,

database, data migration support and all other services associated with these facilities to

ensure service levels, performance and availability requirements as prescribed in the Proposal

Submission Documents. All the members of the SI panel, on the successful delivery of the

product or service, must ensure that they have secured a Quality Checks and Sustenance


Certificate from the e-Pragati Authority. Within the e-Pragati Premises, COE will be

responsible for conducting all these activities.

d) CoE shall be required to diagnose faults quicker and more reliably on site. SLAs are in place

for the resolution timelines for the SI Concerns and Issues.

e) The CoE has already established e-Pragati Platform with readily available instances for

Development, Testing and Production. The CoE will provide access to Development platform

for development, Configuration and Deployment purpose to winning the SI.

f) Responsibilities: COE serves five basic needs:

i. Support: CoE offers support to the business lines for strategic and operational inputs. This is

through services needed or providing by subject matter experts.

ii. Guidance: Standards, methodologies, tools and knowledge repositories are typical

approaches to filling this need.

iii. Shared Learning: Training and certifications, skill assessments, team building, and

formalized roles are all other ways to encourage shared learning.

iv. Measurements: CoE has already demonstrated that they can deliver the valued results that

justified their creation using output metrics. These matrices will be applicable to the

members of the SI.

v. Governance: Allocating limited resources (budgets, people etc.) across all their possible use

is an important function of CoE. They should ensure organizations invest in the most valuable

automation projects & create economies of scale for their service offerings. In addition,

coordination across other corporate interests must enable COE to deliver value.

3.7.4 Project Awarding Committee For each Project to be initiated, it has to be approved by e-Pragati Project Awarding Committee. The Project Awarding Committee is also empowered with all the decision related to project during the execution Phase. Members of the Project Awarding Committee:

a) CEO, e-Pragati Authority - Chief Technology Owner/Chairman

b) Head of the concerned (Project Owner) - Chief Business Owner/Member

Department

c) CEO, Innovation Society - Digital Transformation Strategist/Member

d) Director, MeeSeva (ESD) - Digital Transformation Strategist/Member

e) Additional Director (Police Communications) - Digital Transformation Strategist/Member

f) Representative of the concerned - Digital Transformation Strategist/Member

(Project Owner) Department

g) Representative of ITE&C Department - Member

h) Representative of Finance Department - Member

i) Representative of APTS - Member

j) Pega Systems Solution Expert, e-Pragati - Digital Transformation Strategist/Member

Nominated

k) GPR Expert, e-Pragati Nominated - Digital Transformation Strategist/Member

l) Manager(Admin & HR) e-Pragati Authority - Member/Convener

3.8 SI Panel System and Resolution of Conflicts In case of Conflicts of any nature following matrix will be used for resolution:

Sl. No Nature of Conflict Level SPOC (Single Point of Contact) 1 Project Related Concerns First Level Head of the Line Department


Second Level SPOC, the e-Pragati Authority Final CEO, the e-Pragati Authority

2 Platform Related or Common Services

First Level CoE, the e-Pragati Authority

Second Level SPOC from the e-Pragati Authority

Final CEO, the e-Pragati Authority

3 The e-Pragati Authority Related

First Level SPOC, the e-Pragati Authority

Second Level CEO of the e-Pragati Authority

Final Principal Secretary, ITE&C, GoAP

4 Policy Related

First Level Head of the Line Department

Second Level SPOC, the e-Pragati Authority

Third CEO, the e-Pragati Authority

Final Principal Secretary, ITE&C, GoAP

TABLE 1: CONFLICT RESOLUTION MATRIX


4 Introduction to Department

Department: Andhra Pradesh Real Estate Regulatory Authority (APRERA) has been formed as a regulatory body towards achieving an objective to have holistic approach towards promoting the interests of the consumers as well as builders and boost investments into real estate in an environment of trust and confidence in line with the Andhra Pradesh Real Estate (Regulation & Development) Rules, 2017 which was approved by Government of Andhra Pradesh and notified on March 27, 2017 under “The Real Estate (Regulation & Development) Act, 2016” by Government of India. Its primary objective is to reform the real estate sector in Andhra Pradesh, encouraging greater transparency, citizen centricity, accountability and financial discipline as more & more people are investing in Real Estate. Primary Objective of The Department

➢ Ensuring Transparency & Efficiency in real estate sector in regard to sale of plot, apartment, building or real estate project

➢ Protecting the interest of consumers in real estate sector

➢ Establishing adjudicating mechanism for speedy dispute redressal

➢ Establishing Appellate Tribunal to hear appeals from the decisions, directions or orders of the Real Estate Regulatory Authority


5 Functional Scope of the RFP 5.1 Overview As part of the e-Pragati initiative, all the APRERA Departmental service offerings (modules) would be accessible from the One Portal with an objective to offer a digital platform envisioned to provide a Single Source of Truth for all users thereby eliminating multiple Touchpoints with focus on fetching data from other Departments. Following are the modules that are currently in scope. However, in future, new modules might be added to the below list as the Department is exploring newer & innovative aspects in regard to improved digital services to citizen, promoter, agents, departmental users etc. Modules • Grievance Redressal • Amicable Conciliation Forum • Complaint Redressal • Project Registration • Agent Registration • Visitor Management System • Online Appellate Tribunal • Asset Management System • Social Engagement • Public Service Delivery Guarantee Act


Individual Module Scope

Module: Grievance Redressal

• Build a portal to address grievances raised by internal department employees and external users for Andhra Pradesh Real Estate Regulatory Authority (APRERA) department

Functional

• Baselined PGP Bundle Use Cases:

• Authentication Check • Gather Grievance Details • Resolution by Department • Manager Review • Send email/SMS to Grievance raiser for closure

Integration Touchpoints

• One Portal User Groups

• Citizen • Department users

Module: Amicable Conciliation Forum

• Providing resolution for the complaints raised by citizens or promoters using a digital platform • Providing some informal alternative ways to litigation

Functional


• Complaint Raised by Complainant • Approval by Respondent • Panel Head to Decide Hearing Process • Chairman approval post Hearing process • Send email/SMS to complainant for closure with feedback


• One Portal • Project & Agent Registration

User Groups

• Promoter • Allottee • Department Users


Module: Complaint Redressal

• Addressing complaints post payment of nominal fee raised by Allottee, Promoter and agents using a digital platform

Functional


• Complaint Raised by Complainant • Payment completion by complainant • Traverse various APRERA departments for approval • JD, DP and Chairman approval • Hearing process and closure of the case


• One Portal • Project & Agent Registration • Payment Gateway

User Groups

• Promoter • Allottee • Agent • Department Users

Module: Asset Management System

• An application to record the systematic process of developing, operating, maintaining, upgrading, and disposing of assets digitally.

Functional


• Asset Registration • Asset allocation/Deallocation to Department user/employee • Tracking of asset • Notification of Asset theft/Stolen/Loss


• One Portal • Payment Gateway

User Groups

• Asset Team • Department Employee


Module: Project and Agent Registration

• Develop a customized application to manage Project and Agent registration requests, approval workflows and represent required information to department users through reports, dashboard etc.

Functional


• Gathering Promoter/Agent details • Approval by various APRERA departments • Approval by JD, DP, Chairman • Final Registration certificate generation

Integration Touchpoints (Tentative)

• One Portal • Payment Gateway • Registration Department • Revenue Department • Courts • ICAI • COA • ISE • GST • PAN • Digital signature • Development Permission Management system • Director of town and country planning

User Groups

• Promoter • Agent • Department Users


Module: Visitor Management System

• Creating a digital platform to gather visitor details who visit department for various purposes, so that security related issues can be handled, department will be able to regulate the visits of the visitors.

• Department employee’s engagement time with the visitors can be tracked on a real-time basis. Functional


• Appointment request raised by visitor • Approval of appointee (Department Employee) • Closure of request by Receptionist post visit completion



• Citizen • Department Employee

Module: Online Appellate Tribunal

• Build a portal where any person aggrieved by any direction or decision or order made by the authority or by an adjudicating officer under this act may prefer an appeal before the Appellate Tribunal having jurisdiction over the matter.

Functional

• Baselined PGP Bundle Use Cases

• Complaint information gathering • Payment • Hearing Process with Appellate Tribunal


• One Portal • Payment Gateway

User Groups

• Promoter • Allottee • Agent • AT panel members


Social Engagement

• Addressing grievances/complaints/queries raised by citizen through social media platform and providing next best response using AI

Functional


• Gathering Feedback

• Responding Based on Emotion

• Providing Feedback for existing cases

• Creatine new Grievance/complaint cases

• Sending email/SMS notification to citizen User Groups

• Promoter • Allottee • Agent

Public Service Delivery Guarantee Act

• An application to provide delivery of transparent, efficient and timely public services related to APRERA to the eligible citizens of Andhra Pradesh and for matters connected therewith

Functional


• Gathering information of Defaulters

• Chairman to initiate warning process

• Sending notification to defaulters

• BOT to collect clarifications from defaulters

• Chairman to initiate Loss of Pay for defaulters Integration Touchpoints


• Department Employee

• Chairman


5.2 Requirement Gathering Standards: The System Integrator is responsible for gathering detailed requirements from the Line Department or e-Pragati, the proposed team has two (2) Pega Sr. Business Analyst which should be utilized for this work and adhere to following guidelines.

o Define and agree on the scope of the project.

o Make sure requirements are specific, measurable, agreed upon, realistic and time-based.

o Always ask what the customer wants without assumptions.

o Involve the users from the start.

o Create a clear, concise and thorough requirements document and share it with the customer.

o Avoid talking technology or solutions until the requirements are fully understood.

o Get the requirements agreed with the stakeholders before the project starts.

o Create a prototype, if necessary, to confirm or refine the customer's requirements.

5.3 Design Standards: Design of applications should be in compliance of e-Pragati defined standards as stated below

o Well-structured code, consistent in style and format.

o Areas of the code with excessive complexity to be restructured or split.

o Enforce naming conventions.

o All fields to be properly initialized.

o Ensure that most common logic statements are always tested first with proper exit for every loop.

o Consider errors and manage exceptions cleanly

o Connectors, Data, Functional rules to be constructed under the correct class and ruleset.

o Use out-of-the-box rules and functions. Avoid custom HTML.

o Design intent-driven processes with limited hand-coded java in activities.

o Ensure to have not more than 5 connector flow actions for each assignment.

o Create easy-to-read flows - there should be no more than 15 shapes on a page.

o Calculate and edit declaratively, not procedurally.

Across All Modules

❑ REPORTING ▪ For most of the modules, Reporting should be there. Department Managers or Management officials

can customize and can create/download real time reports. Reports should be generated daily, weekly or monthly basis

❑ ADMIN PORTAL ▪ A Generic admin portal should be created for APRERA Department where an admin should be able to

log in and provide workbasket access to department users across modules and complete admin works

❑ SLA Every individual module should be governed by proper SLA (Goal and Deadline)


5.4 Development Strategy: o Selected SI needs to work along with e-Pragati BA to capture specific and detailed

requirements from Departments.

o This requires various iterations to departments to gather requirements/ Data/ Demos/ Sign offs.

o Once requirements are finalized, BRD needs to be documented/generated from DCO component of Pega.

o SI team develops the system as per department signoff requirements following e-Pragati/Pega best practices during all phases of system development.

o SI team shall reuse various frameworks available under e-Pragati core platform.

o Development of the Project should follow Project Methodology as mentioned in below Section 6.

o SI has to support for integration of developed services on APP Store, One Portal, Core Dashboard, CLGS, LMS and wherever e-Pragati Authority or Line Department finds it appropriate for Operational Purpose.

o If System Integrator has developed any of the APIs during the project development phase, it has to ensure that these APIs are exposed to e-Highway and wherever e-Pragati Authority or Line Department finds it appropriate for Operational Purpose.

5.5 Change Request Note: e-Pragati provides a scope for 30 percent of original contingency plan to accommodate the proposed changes which are approved and marked under contingency plan by “Project Awarding Committee”, during the execution of the project. This Contingency Plan is not binding for the e-Pragati Authority. Change request management process at e-Pragati will typically consist of following steps:

o Request for change review: The selected SI and Product Owner from e-Pragati will initiate a request for Change in existing scope and the same change request must be thoroughly documented.

o Following Components must be part of Change Request:

▪ Incidents that necessitate the change ▪ Description of how the change would be implemented ▪ Impact that the change would have on all associated systems ▪ A risk assessment ▪ Contact information for everyone involved in the change ▪ An outline of who will need to approve the request ▪ A backup plan to follow in case the change is not successful

o Change planning: Once the change request has been initiated and submitted, it will be reviewed by Project Management Office of e-Pragati Authority and Scrum specialists employ this process to prepare the implementation plans for changes based on available bandwidth and priorities.

o Change approval: The proposed change request and planning document will be submitted to Project Awarding Committee, based on merit of the change request, Committee will approve or reject the Change Request.

o Change implementation: Once the change request is approved by the Project Awarding Committee, Selected System Integrator will proceed with the change based on number


of Sprints approved and required to complete the Change Request. This additional work will be out of scope of exiting RFP and appropriate adjustments in the approved scope of the work (SoW) will be made to accommodate these Change Requests and timelines will be revised.

o Change closure: The PMU, Product Owner (e-Pragati Business Analyst) and Scrum Master (Project Manager) will follow this procedure when they perform production tests after changes have been implemented, and Product Owner (e-Pragati Business Analyst) engage with it when they close out changes.

5.6 Testing:

o Design of test cases and test plan strategy should be completed in parallel to requirements finalization.

o SI team to ensure that the SIT/UAT test cases and test strategy documents to be reviewed and approved by e-Pragati Authority.

o Testing will be performed for the sprint backlog and the bugs identified during testing iterations of the sprint are to be fixed within the sprint cycle only.

o Following Pega Standard testing best practices to be ensured across all phases of testing.

▪ Unit test cases executed against Test Plan/Scripts ▪ Profile to identify performance problems ▪ Verify that Logs have no errors or alerts ▪ Clipboard pages are managed

Scope of application testing shall include (but not limited to):

o Unit and regression testing – this includes functional testing of all individual modules developed under the AP RERA Application. This testing will be performed by the SI.

o System Integration Testing (SIT) – After the entire development cycle is over, all the components shall be tested end to end. Here SI has to demonstrate the system in a controlled production environment. The SI will carry out the Integration testing to ensure the integration of all the modules of AP RERA Application.

o Performance and Load Testing – The application software along with the associated infrastructure should successfully meet the criteria for response time for a given user load defined as a minimum concurrency of 20% of the total users of AP RERA Application. Number of Users may vary case to case scenario and SI has to adhere to these numbers.

o User Acceptance testing (UAT) – 100% of all Critical defects identified as part of the UAT shall be fixed and retested before go-live. For high-priority defects, at least 90% of the defects shall be fixed before go-live. Remaining 10% will need to be fixed within 1 month of the go-live. For medium-priority defects, 80% of these should be fixed before go-live and for low-priority defects, 60% shall be fixed before go-live. All pending medium and low priority defects shall be fixed within 2 months of go-live.

▪ Critical Priority: A defect that completely hampers or blocks testing of the product/ feature is a Critical Priority defect. An example but not limited to this, would be in the case of UI testing where after going through a wizard, the UI just hangs at one pane or doesn’t go further to trigger the function. Or in some other cases, when the feature developed itself is missing from the build.

▪ High Priority: A High Priority occurs when the functionality is functioning grossly away from the expectations or not doing what it should be doing. An example but not limited to this could be: the feature is expected to display a particular error to the user with


respect to its return code. In this case, functionally the code will throw an error, but the message will need to be more relevant to the return code generated.

▪ Medium Priority: A Medium Priority defect occurs when the product or application doesn't meet certain criteria or still exhibits some unnatural behavior, however, the functionality as a whole is not impacted. For example, but not limited to this example, a particular functionality can be used only on a later version of the platform, so in order to verify this – the tester actually downgrades his system and performs the test and observes a serious functionality issue which is valid, as normally end users will be expected to have support for a higher version of platform.

▪ Low Priority: A minor bug occurs when there is almost no impact to the functionality, but it is still a valid defect that should be corrected. Examples of this could include spelling mistakes in error messages printed to user or defects to enhance the look and feel of a feature.

5.7 Go Live Requirements For completion of Go-Live formalities, System Integrator (SI) must submit:

o Final UAT and Compliance Certificates from e-Pragati Authority.

o Letter for completion of Appropriate Training to Line Department Officials on delivered product.

o All the necessary software documentation for Delivered Product.

o User Manual for Line Department

o Catalogue for Help Desk Team to resolve Line Department issues or raise Flags/ Tickets.

5.8 Operations and Maintenance Requirements The vendor shall be required to provide operational and maintenance services for all applications including, all the connected software and integrated components. This section discusses the Operations & Maintenance services to be provided by vendor with respect to Application Software. Operations & Maintenance (O&M) phase of the project is by default scheduled for a period of 3 years from the date of “Go–Live” of the application. During these 3 years, the SI is required to undertake the following key activities:

o Maintain the implemented software as per prescribed service levels agreement terms laid down in this RFP.

o Integrate the application developed for this RFP, with software applications developed and deployed with e-Pragati Core Platform as per requirement.

o Implement changes to software as per terms and conditions of the RFP

o Actively monitor and manage e-Pragati Core Platform, limited to the scope of this RFP.

o Maintain systems required for automated generation of compliance of service level requirements laid down in this RFP.

System Integrator has to deploy the following mandatory team for O&M.

a) Pega Senior System Architect (SSA) (Per Project) - 1 Nos

b) Pega System Architect (SA) (Per Project) - 2 Nos

Cost of these resources will be added to final Proposal as mentioned in the Section 14.2.7 Extension of O&M contract will be at the discretion of e-Pragati Authority and e-Pragati Authority may continue or award the O&M post mandatory services from this RFP to other System


Integrators. The SI is required to conduct a parallel run for one month with any new SI identified. The Resources proposed in O&M are dedicated resources for O&M and will not be utilized or billed against any other project/sprint/assignment.


6 Project Methodologies 6.1 Delivery Methodology:

The e-Pragati Authority accord agile/scrum methodology for Project development. This enables to plan and track project deliverables more effectively with higher quality and faster delivery.

6.1.1 Agile Definition Agile involves iterative development in the product cycle including planning, designing, building, testing, reviewing.

6.1.2 Agile Team

o Product Owner — Represents end user (Subject Matter Expert assigned by e-Pragati Authority to reflect Citizen point of view, BA from e-Pragati or representative of Line Department, depending on the requirement of the Sprint) . Defines what is valuable and prioritizes the backlog.

o Scrum Master — facilitates team meetings, removes team impediments, liaises with product owner to ensure the team remains on track.

o Delivery Team — people in charge of execution or that are part of the project’s team (i.e., developer, tester)

6.2 User Stories The User Stories are broadly categorized in following segments and appropriate weightage has been assigned to these categories:

o Complex (Weightage 3): Stories/tasks which require a major addition/change in the architecture of the project. Architects involvement is required to understand existing flow and implementation of the project.

o Medium (Weightage 2): Stories/tasks which require a minor change to the existing architecture of the project. Limited involvement of the architect is required to progress the development of the project.

o Simple (Weightage 1): Stories/ task which are straight forward in terms of implementation and does not require major design requirement implementation or change. The tasks can be handled without the help of architects.

The System integrator has to ensure that the combination used for counting deliverables weigh Xn (where Xn is number of User stories proposed and mutually agreed between e-Pragati and System Integrators for specific Sprint) User stories based on above weightages.


e.g. If System Integrator proposes Xn = 38, 40 and 42 for Sprint A, Sprint B and Sprint C respectively.

Sl. No. Sprint Cycle Complex (Wt. 3) Medium (Wt. 2) Simple (Wt. 1) Total Count 1 Sprint A 2 (3*3 = 6) 2 (2*2 = 4) 28 (28*1 = 28) 6 + 4 + 28 = 38

2 Sprint B 5 (5*3 = 15) 6 (6*2 = 12) 13 (13*1 = 13) 15 + 12 + 13 = 40

3 Sprint C 6 (6*3 = 18) 5 (5*2 = 10) 14 (14*1 = 14) 18 + 10 + 14 = 42

6.2.1 Agile Principles Working software is delivered frequently (every 2 weeks) Simplicity is building only what is really essential, no fluff

o Sprint Planning — Team defines user stories. Main team members involved include scrum master and delivery team.

o Daily Stand-ups — 15min daily meeting to discuss what they did, what they are doing, and any problems they have.

o Sprint Review — Team presents what they delivered over a sprint to the product owner.

o Retrospectives — Meetings done after sprints to review and revise.

o Burn Down Chart — Chart showing remaining work to be done, progress overtime, and the team’s velocity

6.3 Sprint Deliverables: Includes development, testing, deployment and “Done”.

o Implementation of User stories with Unit Testing.

o Test Automation for QA testing (SIT / UAT / Regression / bug Fixes).

o Re-use Master SI core platform frameworks for building Applications.

o Re-use Master SI continuous Integration and DevOps for code deployment and Testing between environments.

o Best practices as per CoE to be followed during all phases of Sprint.


6.4 Ownership of Deliverables

Figure 7: Ownership of Deliverables


7 Payment Terms 7.1 Method of Payment Comprehensive Financial Management System (CFMS) is an enterprise level application, being designed, developed and implemented by Andhra Pradesh Centre for Financial Systems and Services (APCFSS) on behalf of the Finance Department, on the SAP S4 HANA platform. The broad outcomes envisaged from the implementation of the CFMS project include a ‘Single Source of Truth’ across the Enterprise (i.e. the State) accessible by all the stakeholders of the system, real time information availability, facilitate agility in decision making, speed and certainty of service delivery, convenience to all the Stakeholders, minimal reconciliations and improved financial discipline in the State. All the payments for vendors/service providers working for the Government of Andhra Pradesh, must be registered on this portal, as payment will be processed on CFMS portal. To Register on CFMS, Vendor/ System Integrator must provide following details:

o Name of the Beneficiary as mentioned on Bank Account

o Contact Number

o Complete Billing Address

o City, Postal Code

o State and Country

o e-mail Address

o Aadhaar Number (if Applicable)

o PAN Number

o GST Number (if Applicable)

o Bank Details

o Account Number

o Name of Account Holder (Registered name for bank A/c)

o IFSC Code

7.2 Payment Cycle The invoicing may be raised on monthly basis and payments may be made in next billing cycle or within 30 days or on quarterly from the invoice submission date, based on the actual deliverables/milestones achieved in the specified timeframe against the timesheet and attendance registered by deployed resources in Aadhar Based Biometric Attendance System available in e-Pragati Authority. SI has to ensure that all the resources deployed for the e-Pragati Assignment must have attendance more than 80% for any specific month. In case of emergencies and necessities for longer absence for any resource, SI must provide and replacement for the resource with appropriate qualification.

7.3 Income Tax Rule Compliance Payments shall be subject to deductions of any amount for which the Bidder is liable under the empanelment or RFP conditions. Further, all payments shall be made subject to deduction of TDS (Tax deduction at Source) as per the Income-Tax Act Section 194C and / or any other statutory provisions.

7.4 Liquidated Damages In the event of the Bidder's failure to submit the Guarantees and Documents and provision of the necessary deliverables as per schedule specified in this RFP, e-Pragati may at its discretion withhold any payment until the completion of the contract. e-Pragati may also deduct from the payment due to the Bidder as agreed, liquidated damages to the sum of agreed terms as specified in the SLA, subject to the maximum value of the Liquidated Damages being not more


than 10% of the value of corresponding milestone payment of the delayed/undelivered services/monthly instalment. This right to claim any liquidated damages shall be without prejudice to other rights and remedies available to e-Pragati under the contract and law. Liquidated damages shall not be imposed for the period of delay solely attributable to e-Pragati or Line Department of Andhra Pradesh.

7.5 Payment Schedules and Milestones All the payments will be done to the selected Bidder by the e-Pragati after the delivery of services or milestones. Following payment milestones shall be applicable for the Bidder:

Phase Milestone Payment

Monthly Invoice* (The first monthly payment will be due on completion of next billing cycle or one month (30 days) or 1st quarter from the Effective Date of Contract)

At the end of each month after satisfactory delivery of the services and acceptance of the submitted invoice to e-Pragati

Payment will be based on the actual usage measured as per allocation of resources in that particular Sprint to deliver the services/ and as per the “Unit Costs” under Pricing Summary Sheet. If the billing period less than one month, then amount will be calculated on pro-rata basis and for this purpose the following factors are considered.

• Billing Cycle is last week of every month

• 1 month is equal to One Calendar Month

• 1 quarter consists of Three Calendar Month

7.5.1 Terms and conditions

1. Next billing Cycle or Monthly or Quarterly Payment will be based on the actual utilization of resources to deliver the services/milestones/applications/user stories and as per the attendance of each resources under Rate Card

2. Total Monthly Payment is linked to the compliance with the SLA metrics and the actual payment is the payment due to the Service Provider after any SLA related deductions.

3. The payments shall be carried out on Pro-rata basis computed usage in minutes for the respective month.

7.6 Assumptions for Counting of days for all the SLA and Timelines The e-Pragati Authority assumes all the calendar days for the counting of SLA and timelines for deliverables. Due dates for SLA and Timelines, falling on non-working days will be extended to next working day. This extension will not result in change in project plans.


8 Milestones and Deliverables The following deliverables are expected from this project at high level. The detailed plan during execution can refine the following further during execution:

• Fully working User stories/Functions

• Updated input documents with changes during the project

• Any relevant document deemed necessary

• For every Sprint the below activities would need to be updated

Sprint Activity Description

Scrum Team Information & Stakeholder Register

A list of the Scrum team members and stakeholders.

User story Backlog

Prioritized List of user stories (requirements/Functions) team committed to do in the sprint(s). It shows tasks, assignments, and the status of work maintained throughout the project

Burn chart A graphical representation of the work completed (burnup) and the work left to do (burndown). It is updated daily by the Scrum Master following the Daily Scrum

Retrospective/Impediments /Parking log

Scrum Master uses this template to track the results of the lessons learned at the end of each sprint/ issues and roadblocks that are impacting team progress/ items that need to be revisited at another time.

Velocity A chart and graphical representation maintained by the Scrum Master that shows the story points committed and completed for each sprint

8.1 Deliverables and Milestones in compliance with Sprint Cycle T = Letter of Award/ Notification of Award

8.1.1 Project Timelines

S.no. Activity Timeline

1. Issue of Letter of Award T

2. Submit PBG (10% of the cost of the Project) before deadline T + 10 days

3. Signing of Master Service Agreement (MSA) T + 25 days

4. Deployment of Account Manager and Sprint Team at ePA T + 30 days

5. Beginning of Sprint 0

6. Assessment/ Assistance/Field Visits/ BRD/ Hand Shake with CoE, LD,

ePA, Legacy SI etc

T + 30 days

7. End of Sprint 0 T + 45 Days

8. Execution Plan submission Sprint Wise T + 45 Days

9. Beginning of Sprint 1 (Publish Backlog list with priorities for Sprint 1) T + 46 Days


S.no. Activity Timeline

10. Ends of Sprint 1 T + 60 Days

11. Review of Sprint 1 T + 61 Days


13. User Acceptance Testing (UAT) of Sprint 1 T + 63 Days

14. Third Party Audit (TPA) for Sprint 1 T + 66 Days

15. Raise Invoice for 1st Month Payment for completed Sprints between

T+31 to T+60

T + 60 Days







22. Raise Invoice for 1st Month Payment for completed Sprints between

T+61 to T+90

T + 90 Days




26. Continue with this Cycle to complete Proposed Subsequent Sprints… As proposed…

27. Go Live T + 210 days

28. Beginning of O&M Holiday Period and Monthly Payment for O&M

Resources

T + 211 days

29. End of O&M SLA Holiday Period and Beginning of O&M T + 300 days

30. Beginning of Exit Management and O&M Handover Period (if

required, SI has to work in parallel with selected replacement for

current SI for O&M)

T + 300 days + 3

Years - 90 days

31. Exit T + 300 days + 3

Years

8.1.2 Sprint Timelines The indicative timelines for sprint deliverables measured during any Sprint:


S. No. Deliverables Timelines

1

• Prepare Sprint Plan and Goals

• Prepare Sprint Backlog: Finalize User Stories

• Conduct daily Scrum meetings to review status and identify issues and roadblocks.

Sprint Day 1

2 Build and test the Sprint 1 finalized User Stories. Sprint Day 2

3 Releasable MVP with Definition of Done Criteria or working Sprint Day 12

4 Sprint Review & Retrospectives Logs Sprint Day 14 (or at the end of each Sprint)

5 Assign User Stories to next Sprint. Sprint Day 14 (or at the end of each Sprint)

6 Sprint Velocity Chart Sprint Day 15 Days (or at the end of each Sprint)

7 Impediments Log During Sprint

8 Parking Lot During Sprint

9 Submit Project Status Reports(Weekly/Sprint) Sprint Day 15


9 Acceptance Criteria 9.1 Acceptance Criteria Definition Acceptance Criteria defines how a particular feature could be used from an end user’s perspective. It focuses on business value, establishes the boundary of the feature’s scope and guides development. These are unique to a user story and form the basis of user story acceptance testing which establishes the conditions for the success of the feature. Acceptance criteria could establish a boundary that helps team members to understand what’s included and what’s excluded from the scope of the user story. The criterion of user story acceptance not only informs the product behavior in happy path scenarios, it also guides the user experience when things don’t work as intended. It describes what would be verified by the acceptance tests. When the product owner verifies particular user story acceptance criteria and the developed feature passes it, the development of the user story is considered a success.

9.2 Acceptance Criteria Template Acceptance criteria describe the intent of the e-Pragati Authority, i.e. his/her idea of what the user story should be like. It is up to the team to develop the solution to the user story. To make it simple, they can divide the document into a three-part scenario: Given, When, then – each describing an item of the criteria, like what the product is used for, what should be there and what shouldn’t be. In the format of acceptance test criteria examples:

Scenario This is the title of the condition to be acted upon.

Given (an initial condition)

The user places an item into their shopping cart.

When (something happens)

This is where the process in which the user's initial order is verified or whether it fulfils the system requirements to process the task. If it does, then the system can proceed to work on the order. However, if the user order does not match to the system requirements, the system will deny the task.

Then (this is the result)

Once the system is done verifying the user order, the order is then processed to produce the results which would be: the final result, input to the next task or a lead-on for the user to the next task.

9.3 Acceptance Criteria for SI: 1. The SI shall study the requirements of the project and existing systems and shall design,

develop, test, and provide maintenance support in accordance with the e-Pragati core

platform guidelines.

2. Final acceptance of Deliverables comprising functionalities and specifications identified in

the RFP and successful completion of all Sprints set forth in one or more Statements of


Work, i.e. outcomes of the Agile methodology is expressly conditioned upon completion of

all applicable inspection and testing procedures to satisfy the mutual definition of “done” as

prescribed in the Agile Scrum methodology.

3. Payments shall be made upon satisfaction of the criteria of “done” set forth in each Sprint.

The SI shall acknowledge and agree that Sprints and Deliverables may be iterative, and that

each Sprint shall incorporate agreed criteria for “done” together with a resolution process

for disagreement. The SI shall provide best estimate of the value of each Sprint.

4. The SI shall diligently engage with customer in review of all Deliverables presented and all

outcomes in accordance with each Sprint. In the event Customer’s review of the final

Deliverables, outcomes or other work contracted identifies errors, defects, faults,

noncompliance with the required Deliverables and specifications of the RFP as set forth in

any Sprint, the SI shall provide Customer with a revised Deliverable and/or a mutually

agreed upon detailed schedule, e.g. corrective action plan, for completion of a revised

Deliverable, for any objections that SI and Customer mutually determine fall within the

intended scope of the Deliverable or Sprint. If the customer objections are not within the

scope of the Agreement, the SI may initiate a Change Order and payment for the Sprint shall

be due, excepting the objections.

5. Final acceptance at the conclusion of the project will be complete when the Agile SCRUM

processes meet the definition of “done” and there are no objections pending. Final

acceptance shall result in release of any retainage amounts and the final Sprint payment.

6. The SI shall adhere to Pega implementation Best practices and standards. Some of the best

practices are included below for reference:

a. Leverage Directly Capture Objectives (DCO) as a core part of the delivery

process, starting with Inception and continuing through the entire project

lifecycle to improve project quality.

b. The SI shall monitor and report team in compliance with Pega Guardrail’s and

Alerts.

c. The SI shall share the teams monitor compliance scores with management on a

regular basis throughout the project. The SI should achieve the Guardrails

compliance score >95 throughout the project. Suggest Guardrails compliance

scores are mentioned below

Guardrails compliance Score Action to be taken

>95 A score of 95 or greater indicates that application is in good standing. As a best practice, verify and maintain the compliance score of 97 or greater before deploying it to production system.

80 – 94.99 A score of 80 to 94.99 indicates that application needs review for improvement

Below 80 A score below 80 indicates that immediate action is required

d. The SI has to ensure that Guardrail Score is above 95 before releasing the package

to final UAT and other compliance requirements for each Sprint. 7. The SI shall monitor and review the Alert logs via the Pega Autonomic Event Service

framework or Pega Predictive Diagnostic Cloud daily and provide remediation for the alerts

generated.


8. The following parameters would be reviewed during acceptance criteria

a. Number of working user stories/ functions signed off

b. Quality of deliverable including code, proof of internal review

c. Best practices followed on deliverables including code

The SI should establish a process to review all Guardrails violations and Alerts and document the rare situations when a violation is justified. Compliance with the Guardrails and Alerts will result in more maintainable, performant, scalable and upgradable applications with significantly fewer defects than non-compliant applications.

9.4 Go Live Requirements For Final UAT and Compliance Certificates from e-Pragati Authority, must submit:

o Letter for completion of Appropriate Training to Line Department Officials on delivered product.

o All the necessary software documentation for Delivered Product.

o User Manual for Line Department

o Catalogue for Help Desk Team to resolve Line Department issues or raise Flags/ Tickets.

Note: “Go Live” sign off document which will be jointly approved by the e-Pragati Authority, Head of the Department (HoD / Chief Business Owner nominated by the department in “Project Awarding Committee”) of the concerned department and System Integrator selected through this RFP.

9.5 Code Review Checklist Template for Sprint Review

Review Details (all fields mandatory)

Story Name(s) Reviewed

Author Name(s)

Reviewer Name(s) Review Date 5/18/2018 MM/DD/YYYY

Required Attachments: 1. Rule List with all rules created or changed 2. Data Instance List with all data instances created or

changed 3. DDL that is required to support the story 4. Preflight with warnings with justifications 5. PAL Report

Review Fundamentals

Does the code completely and correctly implement the Business Requirements?

Does the code completely and correctly implement the Solution Design?

Does the code completely and correctly implement the System Requirements?

Does the code completely and correctly implement the Technical Requirements?

Review Guidelines

Code Design Is the code well-structured, consistent in style, and consistently formatted?

Are any areas of the code excessively complex, and should as a result, be restructured or split?

Enforce naming conventions.

Are all fields properly initialized?


Are the most common logic statements always tested first, and does every loop have an exit?

Consider errors and manage exceptions cleanly

Connectors, Data, Functional rules have been constructed under the correct class and ruleset.

Use out-of-the-box rules and functions. Avoid custom HTML.

Limit hand-coded Java in activities

Design intent-driven processes

Do not have more than 5 connector flow actions for each assignment Create easy-to-read flows - there should be no more than 15 shapes on a page Calculate and edit declaratively, not procedurally

Rule Management & Reuse

All rule availability set appropriately

All rule changes checked in

All rules in appropriate class

All rules are appropriate ruleset Where possible, rules use parameters to make them flexible and re-usable.

All rules names follow naming conventions

Use cases associated to rules as applicable

Rules marked as extension points as applicable

No extraneous "save as" rules from different rulesets

No flows still in draft mode Create activities that implement a single function - to maximize re-use

Documentation

Is the code documented with an easy-to-maintain and consistent commenting style?

All activity steps have descriptions

History tab populated with usage and description information for all rules

All rules have meaningful, natural language short descriptions No commented-out steps in any activities

Testing & Performance

Unit test executed against Test Plan/Scripts

Profile to identify performance problems

Verify that Logs have no errors or alerts

Clipboard pages are managed

Review Findings

Description Remediation

Required Due Date Completed?

Stories/ Issues/ Code changes are reviewed by Representative of SI and e-Pragati Product Owner. Mentioned comments as Justification need to be <<Any issue observed in review>>

☐

5/17/2018

☐

MM/DD/YYYY

Secondary permits corresponding code changes are code as standards. ☐

5/17/2018 ☒

MM/DD/YYYY

Comments (if Any)


10 Proposed Sprint Team Composition

To ensure that, the Primary SI does not compromise with the quality of work, the e-Pragati Authority enforces minimum team composition of a Sprint Team for every subsequent project implemented under the purview of the e-Pragati Authority or Primary SI selected from this RFP, has to ensure that the proposed team comprises of minimum resources from following composition:

a) Pega Lead System Architect (LSA) (Per Project) - 1 Nos

b) Pega Senior System Architect (SSA) (Per Project) - 5 Nos

c) Pega System Architect (SA) (Per Project) - 3 Nos

d) Pega Sr Business Analyst (Per Project) - 2 Nos

e) Quality Experts (Per Project) - 2 Nos

f) Data Migration Expert (Per Project) - 1 Nos

g) Project Manager (Per SI) - 1 Nos

h) Delivery Manager (Per SI) - 1 Nos

i) UI Developer (Per Project) - 1 Nos

j) UX Designer (Per SI) - 1 Nos

10.1 Proposed O&M Team Composition System Integrator has to deploy the following mandatory team for O&M from the date of Go-live.




11 Service Level Agreement Definition of “T” for this section is Date of Project Awarding and Letter of Issuance for the same.

11.1 Service Level Agreements The service levels SI is required to comply with are detailed in this section. Also, penalties for non-compliances associated with the different service level requirements are defined herein. The service level requirements are broadly categorized under three headings:

o Service Level Requirements until “Go-live” of the Project: The charges to be levied on the SI for non-compliance to SLR until “Go-live” are referred to as Liquidated damages.

o Service Level Requirements during the O & M Phase: The charges to be levied on the SI for non-compliance to SLR during the O & M phase are referred to as penalties.

o Load and Performance SLR: There are no penalties attached to this SLA, but the service levels mentioned in this are to be maintained.

11.1.1 Service Level Requirements in Development Phase The charges levied on the SI on account of Liquidated Damages shall be capped at 10% of the total of Software Development and Implementation costs quoted by the bidder. If the liquidated damages breach the cap of 15% of the total SDI cost, e-Pragati Authority serves the right to terminate the contract.

11.1.2 Timely Deployment of Resources Requirement:

i. Deployment of Project manager on-site in e-Pragati Authority premises within T + 30 days ii. Deployment of Sprint Team on-site in e-Pragati Authority premises within T + 30 days

Type Metric Penalty

Baseline (i) Deployment of Project manager on-site in e-Pragati Authority premises within T + 30 days

(ii) Deployment of one functional lead on-site in e-Pragati Authority premises within T + 30 days

None

Lower performance

Each day of delay after the first 30 days up to 37th of delay

Rs. 5000 per day per resource

Breach Each day of delay from the 38th day of delay Rs. 10000 per day per resource

11.1.3 Timely registration with CoE e-Pragati Authority for obtaining necessary credentials of the ePCP Requirement:

i. Registration of all resources within T + 30 days + 4 hours (First half of the day) is mandatory with e-Pragati Biometric Attendance System for all the resources deployed for e-Pragati Projects. These resources must sign all the necessary documents to obtain the access to the e-Pragati Core Platform and other sensitive/restricted systems.


ii. Registration of all resources within T + 30 days + 16 working hours (end of second day) is mandatory with e-Pragati Center of Excellence (CoE) for all the resources deployed for e-Pragati Projects.

iii. Without completion of above two steps, the invoicing for resource will not be accounted.

11.2 Timely Implementation of Software Modules Requirement:

System Integrator has to ensure that it has achieved 95% score in Guardrails compliance Score for completion of the Sprint and anything below this will imply that Sprint is not complete, will not be considered for invoicing and necessary SLA will be applicable as mentioned in following table.

Type Metric Penalty

Baseline Guardrails compliance Score > 95%

None

Lower performance

Guardrails compliance Score 80 – 94.99%

e-Pragati will provide a margin of 3 days to comply with Guardrail compliance Score and beyond that Rs. 10000 per day penalty will be levied.

Breach Guardrails compliance Score Below 80%

Score below 80% is not acceptable and e-Pragati will not provide any margin to comply with Guardrail compliance Score and penalty of Rs. 50000 will be levied and for every subsequent delay in compliance will result in Rs. 10000 per day penalty.

The indicative timelines for execution measured from start date(T):

Xn = # User stories proposed & mutually agreed between e-Pragati & SI for specific Sprint)

S. No. Deliverables Timelines

1 • Project Assessment Phase Technical Assessment (Understand the application deployment scenario)

• Identify the tools/services/applications that can be reused and the tools/services/applications that need to be built

• Create a deployment plan and measure success with a set of agreed lists of deliverables/ documents for each sprint.

T+40 Days, (Only once per project)

2 Review Deployment plan with CoE or Product Owner (BA from e-Pragati) assigned by e-Pragati

T+40 Days, (Only once per project)

3 The System Integrator is expected complete on an average Xn User Stories in Sprint Cycle.

2 Weeks, from completion of Point 2 (for each sprint)

4 User Acceptance Testing (UAT): UAT for previous cycle will be completed at the beginning of the next Sprint, and during this time, System Integrator continue with the next Sprint Cycle. The System Integrators may have to change the Backlog List based on results of UAT.

3 Days, from completion of Point 3 (for each sprint)

5 Center of Excellence (CoE) Compliance Audit (Simultaneous to previous Sprint) Third (3rd) Party Compliance Audit

2 Days, from completion of


Technical Completion Certificate The System Integrators may have to change the Backlog List based on results of these audits and Sprint will be considered only on the basis of clearance from UAT and other compliance requirements.

Point 3 (for each sprint)

6 Invoicing and Billing 2 Sprints in one billing cycle.

Sprint 0: T + 45 Days

Note: SI can deploy their resources before T + 30 days to prepare a better understanding of Scope.

o Project Assessment Phase Technical Assessment (Understand the application deployment scenario)

o Identify the tools/services/applications that can be reused and the tools/services/applications that need to be built

o Create a deployment plan and measure success with a set of agreed lists of deliverables/ documents for each sprint.

o Review and approval from CoE for deployment plan. between T + 30 and T + 45 days

Sprint 0: At the end of Sprint 0, SI should be ready with Project and Resource Plan

Sprint 1: At least X1 stories launched between T + 46 and T + 60 days,

Sprint 2: At least X2 stories launched between T + 61 and T + 75 days



Sprint 5: At least X5 stories launched between T + 106 and T + 130 days Sprint 6:…..

Note: All the sprint completion will be evaluated by the line department and UAT team of e-Pragati Authority within 3 days of launching, for compliance with e-Pragati standards and guidelines, CoE will submit the compliance report in 2 days from UAT Testing. Post Compliance report from CoE, SI can raise an invoice for 2 sprints in one billing cycle (monthly billing).

Type Metric Penalty

Baseline Sprint 0: At the end of Sprint 0, SI should be ready with Project and Resource Plan

Sprint 1: At least X1 stories launched between T + 46 and T + 60 days,




Sprint 5: At least X5 stories launched between T + 106 and T + 130 days Sprint 6:…..

None

Lower performance

A First 2, Sprints will be cooling down period.

Note: SI has to ensure that, it completes all the User Stories for first 3 Sprints before the competition of 3rd Sprint.

No Penalty for 1st Two Sprints.


B SI did not meet at most 1 Sprint 1% of Software Development & implementation costs for each missed sprint for First week and subsequent weeks will add additional 1% to penalty i.e. Week 2 onwards Penalty will be 2%, Week 3 Penalty would be 3%

C SI delayed launch of all the modules within T + quoted time

In addition to 1% mentioned in the Section B, additional 0.25% of Software Development & implementation costs for 30 days for First week and subsequent weeks will add additional 0.25% to penalty i.e. Week 2 onwards Penalty will be 0.5%, Week 3 Penalty would be 0.75% (beyond T + quoted time)

Breach A SI did not meet consecutively more than one sprint (e.g. Sprint 1 is missed, and Sprint 2 is also missed)

2% of Software Development & implementation costs for each consecutive target (i.e. more than 1 target in a sequence) missed

B SI delayed launch of all the modules within T + quoted time.

0.5% of Software Development & implementation costs for each day from the date of Go-Live.

Notes:

1) Delays attributed to e-Pragati Authority will be accounted in definition of time period. For example, if e-Pragati Authority had delayed providing feedback on the first 2 modules by 20 days, the time period 1 definition will be suitably extended to T + 20 days and all other time periods will be accordingly extended

2) This SLA is drafted such that SI is NOT penalized for cascading / accumulated delays. Instead, SI will be penalized for delay which happened during a snapshot of time. If all the modules did not get launched as required in the RFP at end of the envisaged project implementation period, SI will be penalized for such delay as defined above. Thus, e-Pragati Authority’s interest is taken care of as well.

a) In a certain time period (i.e. missed target in one time period) – Example: SI launched M User Stories less than X1 stories (i.e. X1 - M). within T + 60 days (time period 1) but launched (X2 + M) user stories between T + 61 and T + 75 (time period 2). In this scenario, SI will be


penalized only for the delay which happened in time period 1 only (i.e. 1% of the Software Development & Implementation Costs for the missed target)

b) Continuous bad performance (i.e. missed targets in two consecutive time periods). For example, SI launched less than X1 stories within T + 60 days (time period 1), launched less than X2 stories between T + 61 days and T + 75 days (time period 2), launched less than X3 stories between T + 76 days and T + 90 days (time period 3) and launched all the backlogged user stories in addition to X4 stories for this sprint, between T + 91 days and T + 105 days (time period 4). In this scenario, SI will be penalized for the delays as explained below:

i) 1% of the software development & implementation costs for the missed target during time period 1

ii) 2% of the software development & implementation costs for the two consecutive targets missed during time period 2

iii) 2% of the software development & implementation costs for the two consecutive targets missed during time period 3

iv) No penalty as all the stories went live in Time period 4

3) SI shall not be penalized if it had accumulatively met the targets as defined below, even when certain time period specific periods were not met:

a) Accumulated targets:

i) Time period 1: Launched X1 user stories

ii) Time period 2: Launched X2 user stories

iii) Time period 3: Launched X3 user stories

iv) Time period 4: Launched X4 user stories

v) Time period 5: Launched X5 user stories

b) Example:

i) Time period 1: Launched 15 more than X1 user stories i.e. (X1 + 15), so accumulated number of launched user stories are X1 + 15 – No penalty

ii) Time period 2: Launched 15 User stories less than X2 user stories i.e. (X2 – 15); accumulated number of launched user stories are i.e. (X1 + X2) – As accumulated targets are met by the SI, there will be no penalty

4) Liquidated damages as per charges defined above will be deducted in the next payment due to the SI subsequent to applicability of the damages

Note: The Issue/Ticket Management System and Helpdesk will be managed by CoE and all the necessary issues will be forwarded to the O&M Team for resolution and timelines will be activated from time of assignment of issue/ticket.

11.2.1 Service Level Requirements in O & M Phase During O&M phase, penalties which can be levied on SI each year will be capped at 15% of the Total QGR Cost per year.

If cap on the penalties exceeds 15% of the total QGR cost per year, then e-Pragati Authority reserves the right to initiate termination action on SI. (For the purpose of calculation of penalties, a YEAR starts from the day the Operations and Maintenance phase starts and ends after 12 months from the start of O&M phase).


Requirement for resource deployment during O&M:

i. Deployment of suitably qualified Pegasystems certified resource on-site in e-Pragati Authority premises within 15 days of notification from e-Pragati Authority

ii. Deployment of suitably qualified hand holding resource on-site in e-Pragati Authority premises within 15 days of notification from e-Pragati Authority

Type Metric Penalty

Baseline (i) Deployment of suitably qualified Pegasystems Certified resource on-site in e-Pragati Authority premises within 15 days of notification from e-Pragati Authority

(ii) Deployment of suitably qualified hand holding resource on-site in e-Pragati Authority premises within 15 days of notification from e-Pragati Authority

None

Lower performance

Each day of delay for the first 15th days of delay Rs. 5000 per day per resource

Breach Each day of delay from the 16th day of delay Rs. 10000 per day per resource

11.2.2 Resolution of Critical Faults during O&M Requirement:

i. Fault resolution time = SI shall resolve a critical fault reported within 6 hours of receipt of the request

ii. Any new Software feature implemented through the change control procedure shall enjoy an SLA Holiday of 3 months with regards to the Fault resolution SLA from the date of deployment of the feature into production.

Type Metric Penalty

Baseline A critical fault is resolved within 6 working hours of receipt of the request

None

Lower performance A critical fault is resolved between 6 – 8 working hours of receipt of the request

Rs. 1000

Breach A critical fault is resolved in more than 8 and up to 24 Hours working hours of receipt of the request

Rs. 2000

For each hour more than 24 Hours Rs. 200 per Hours

Note

1) Working hours taken for this SLA computation is 0930 hours – 1800 hours on all working days of e-Pragati Authority. For example, when e-Pragati Authority registers a complaint on Saturday at 1730 hours, the SI as per the baseline metric is required to fix the complaint by 1430 hours on the subsequent Monday.


2) SI is deemed to have been notified about an issue (i.e. received a request for issue resolution) when the issue is reported in a designated email address. Only issues reported in the designated email address and the timestamp as recorded in the email shall be considered as input for implementation of this SLA.

3) The SI shall reply to the original email wherein issue was reported and confirm resolution of the issue. A copy of this mail shall be marked to e-Pragati Authority for information and tracking purposes. An issue is deemed to have been resolved if the user who raised the complaint does not dispute resolution of the issue. The time taken for issue resolution (TTIR) will be calculated from the difference between the issue resolution and issue reporting time (i.e. both as recorded in email).

4) If a user contests resolution of an issue as recorded in email, SI shall reopen the issue, mark the issue as unresolved and then once again report resolution of the issue. In such a scenario, the additional time taken for resolution of the issue will be added to the initial TTIR as defined in 3.

5) A fault is considered as critical when at least 50% of all registered users in the system could potentially be impacted by the fault. To operationalize this SLA, e-Pragati Authority and SI shall agree on the number of users for each of the 10 functional modules during SLA operationalization.

6) A fault which had occurred in the system can be reported by one or many users. If root cause of issues reported by many users at a point in time remains the same, such will be considered as single fault for SLA computation purposes.

7) TTIR will be computed for each of the faults resolved in the system and TTIR will be the basis on which penalty computations will be done.

8) SI is required to give a monthly report on all the issues and their resolution time. 9) Penalties will be calculated on a per fault basis. Hence, SI can be penalized for bad performance

for more than one critical fault in a quarter.

11.2.3 Resolution of Non-Critical Faults during O&M Requirement:

i. Fault resolution time = SI shall resolve a non-critical fault reported within 2 working days of receipt of the request

ii. Any new Software feature implemented through the change control procedure shall enjoy an SLA Holiday of 3 months with regards to the Fault resolution SLA from the date of deployment of the feature into production.

Type Metric Penalty

Baseline A non-critical fault is resolved within 2 working days of receipt of the request

None

Lower performance A non-critical fault is resolved between 3-4 working days of receipt of the request

Rs. 500

Breach A non-critical fault is resolved in more than 4 working days of receipt of the request

Rs. 1000

For each day of delay more than 6 days Rs. 500 Per day

Note

1) This SLA will be implemented as per e-Pragati Authority working days


2) The day in which a non-critical issue is reported will be excluded while computing the number of days it took to resolve a non-critical fault

3) SI is deemed to have been notified about an issue (i.e. received a request for issue resolution) when the issue is reported in a designated email address. Only issues reported in the designated email address and the timestamp as recorded in the email shall be considered as input for implementation of this SLA.

4) The SI shall reply to the original email wherein issue was reported and confirm resolution of the issue. A copy of this mail shall be marked to e-Pragati Authority for information and tracking purposes. An issue is deemed to have been resolved if the user who raised the complaint does not dispute resolution of the issue. The time taken for issue resolution (TTIR) will be calculated from the difference between the issue resolution and issue reporting time (i.e. both as recorded in email).

5) If a user contests resolution of an issue as recorded in email, SI shall reopen the issue, mark the issue as unresolved and then once again report resolution of the issue. In such a scenario, the additional time taken for resolution of the issue will be added to the initial TTIR as defined in 4.

6) A fault is considered as non-critical when less than 50% of all registered users in the system could potentially impacted by the fault. Further, the fault should have resulted from an error in software functionality already implemented or from deployment of the software. New feature requirements or requirement for modification of existing features shall not be considered as non-critical fault.

7) A fault which had occurred in the system can be reported by one or many users. If root cause of issues reported by many users at a point in time remains the same, such will be considered as single fault for SLA computation purposes.

8) TTIR will be computed for each of the faults resolved in the system and TTIR will be the basis on which penalty computations will be done.

9) SI is required to give a monthly report on all the issues and their resolution time. 10) Penalties will be calculated on a per fault basis. Hence, SI can be penalized for bad performance

for more than one non-critical fault in a quarter. 11) “Quarterly pay-outs” refers to total of the following payments made to the SI in a Quarter

during the Operations & Maintenance phase (i.e.) subsequent to the Go-live: Quarterly Guaranteed Revenue, Data center / disaster recovery rental charges and Man-month charges for provision of hand-holding resources, data digitization, training and help desk. The following payments shall be excluded from the Quarterly pay-outs: man-month charges for provision of on-site software development resources for implementation of software change control.


12 Terms and conditions 12.1 Contract Terms 12.1.1 Eligible Bidders

Only System Integrators who has been empaneled for designing, developing, enhancing and maintaining applications/services on e-Pragati core platform will be eligible for submitting their bids for this Tender.

12.1.2 Availability of the RFP Documents: The RFP can be downloaded from the website / given under Section 4. The bidders are expected to examine all instructions, forms, terms, project requirements and other information in the RFP documents. Failure to furnish all information required as mentioned in the RFP documents or submission of a proposal not substantially responsive to the RFP documents in every respect will be at the bidder's risk and may result in rejection of the proposal and forfeiture of the bid security.

12.2 Pre-Bid Conference The e-Pragati will host a Pre-Bid Conference, tentatively scheduled as per the schedule given in Section 2 above. The representatives of the interested organizations may attend the pre-bid conference at their own cost. The purpose of the pre-bid conference is to provide bidders with information regarding the RFP and the proposed requirements in reference to the particular RFP. It will also provide each bidder with an opportunity to seek clarifications regarding any aspect of the RFP and the project.

1. Clarify and discuss issues with respect to the Project and the RFP, the e-Pragati Authority may hold Pre-Proposal meeting(s). The e-Pragati Authority will endeavor to hold the Pre-Proposal meeting as per bidding schedule specified in Clause 2 above.

2. The date, time and venue of the Pre-Proposal Meeting (pre-bid meeting) shall be: Date : Friday, June 22nd, 2018 Time : 12:00 PM Venue :

Mini Conference Room, O/o The e-Pragati Authority, GoAP 3rd Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 001

3. Prior to the Pre-Proposal meeting(s), the Bidders may submit a list of queries and propose deviations, if any, to the Project requirements and/or the Services Agreement. Bidders must formulate their queries and forward the same to the e-Pragati Authority as per the time schedule set out in Clause 2 above. The e-Pragati Authority may, in its sole discretion or based on inputs provided by Bidders that it considers acceptable, amend the RFP.

4. Bidders may note that the e-Pragati Authority will not entertain any deviations to the RFP at the time of submission of the Proposal or thereafter. The Proposal to be submitted by the Bidders would have to be unconditional and unqualified and the Bidders would be deemed to have accepted the terms and conditions of the Bidding Documents with all its contents including the draft Services Agreement. Any conditional Proposal shall be regarded as nonresponsive and would be liable for rejection.

5. Attendance of the Bidders at the Pre-Proposal meeting is not mandatory. 6. All correspondence / enquiries are to be submitted to the officer mentioned below, in

writing by facsimile/registered post/courier or by email: Kind Attention : CEO, The e-Pragati Authority

Address : The e-Pragati Authority, GoAP 3rd Floor, NTR Administrative Block


Pandit Nehru Bus Station, Vijayawada – 520 001 Email : [email protected]

7. The e-Pragati Authority shall make available its responses, including a description of the enquiry, but without identifying its source, on the e-procurement website and/or its website. In addition, the e-Pragati Authority may choose to send to all Bidders, written copies of such responses to all the Bidders. No interpretation, revision, or other communication from the e-Pragati Authority regarding this solicitation is valid unless it is in writing and is signed by a person not less than the rank of the CEO, e-Pragati Authority.

8. The period of contract is 5 years from the date of signing of agreement with the successful bidder.

12.3 Bidder Inquiries and e-Pragati responses 1. All enquiries from the prospective bidders relating to this RFP must be submitted in writing

exclusively to the contact person notified by e-Pragati as above in the format specified in Format 6.3.1 Request for Clarification Format. A copy of the bidder enquiries should also be emailed to the bid issuer’s email address provided in the Section 4. The mode of delivering written questions would be through post or email. It can also be presented in writing by the authorized representative of the prospective bidders during pre-bid conference. In no event will e-Pragati be responsible for ensuring that bidders’ inquiries have been received by them. Telephone calls or any other mode of communication other than prescribed herein will not be accepted for the queries.

2. After the RFP is issued to the bidder, e-Pragati shall accept written questions/inquiries from the bidders. e-Pragati will endeavor to provide a complete, accurate, and timely response to all questions to all the bidders. However, e-Pragati makes no representation or warranty as to the completeness or accuracy of any response, nor does e-Pragati undertake to answer all the queries that have been posed by the bidders. All responses given by e-Pragati will be published on the website given under Section 4. All responses given by e-Pragati will be available to all the bidders. Any email communications sent by bidders to e-Pragati must be sent to the email address provided in Section 4.

3. The e-Pragati will not be bound to clarify any query after the pre-bid meeting. 4. The queries should be submitted in following format:

Sr. No.

Bidder Name

Section Name

Clause No

Page No.

Clause/Statement Query e-Pragati Response

12.4 Supplementary Information / Corrigendum / Amendment to the RFP 1. If e-Pragati deems it appropriate to revise any part of this RFP or to issue additional data to

clarify an interpretation of the provisions of this RFP, it may issue supplements to this RFP. Such supplemental information, including but not limited to, any additional conditions, clarifications, minutes of meeting, and official communication over email/post will be communicated to all the bidders by publishing on the website given under Section 4. Any such supplement shall be deemed to be incorporated by this reference into this RFP.

2. The letters seeking clarifications sent either to all the bidders or to specific bidder as the case may be pertaining to pre-bid conference shall also be deemed to be incorporated by this reference in this RFP, as the case may be.

3. At any time prior to the deadline (or as extended by e-Pragati) for submission of bids, e-Pragati, for any reason, whether at its own initiative or in response to clarifications requested by prospective bidder, may modify the RFP document by issuing amendment(s).



All such amendments will be published on the website given under Section 4. All such amendment(s) will be binding on all the bidders.

4. In order to allow bidders a reasonable time to take the amendment(s) into account in preparing their bids, e-Pragati, at its discretion, may extend the deadline for the submission of bids.

12.5 Proposal Preparation Costs: The bidder is responsible for all costs incurred in connection with participation in this process, including, but not limited to, costs incurred in conduct of informative and other diligence activities, participation in meetings/discussions/presentations, preparation of proposal in providing any additional information required by e-Pragati to facilitate the evaluation process, and in negotiating a definitive Service Agreement and all such activities related to the bid process. This RFP does not commit e-Pragati to award a contract or to engage in negotiations. Further, no reimbursable cost may be incurred in anticipation of award of the contract for implementation of the project.

12.6 Right to terminate the Process of RFP by e-Pragati Authority 1. e-Pragati may terminate the RFP process at any time without assigning any reason. e-

Pragati makes no commitments, explicit or implicit, that this process will result in a business transaction with anyone.

2. This RFP does not constitute an offer by e-Pragati. The bidder’s participation in this process may result in e-Pragati selecting the bidder to engage in further discussions and negotiations towards execution of a contract. The commencement of such negotiations does not, however, signify a commitment by e-Pragati to execute a contract or to continue negotiations.

3. e-Pragati has the right to terminate this discussions and negotiations process without assigning any reason and no costs will be reimbursed to the participating bidders.

12.7 Acceptance of part / whole bid / modification – Rights thereof: e-Pragati reserves the right to modify the specifications / quantities / requirements / tenure mentioned in this RFP including addition / deletion of any of the item or part thereof after pre-bid and the right to accept or reject wholly or partly bid offer, or, without assigning any reason whatsoever. No correspondence in this regard shall be entertained. e-Pragati also reserves the unconditional right to place order on wholly or partly bid quantity to successful bidder.

12.8 Authentication of Bids The original and all copies of the bid shall be typed or written in indelible ink and signed by the Bidder or a person duly authorized to bind the Bidder to the Contract. A certified true copy of the corporate sanctions/approvals/board resolution authorizing its authorized representative to sign/act/execute documents forming part of this proposal including various RFP documents and binding contract shall accompany the bid. All pages of the bid, except for un-amended printed literature, shall be initialed and stamped by the person or persons signing the bid.

12.9 Interlineations in Bids The bid shall contain no interlineations, erasures or overwriting except as necessary to correct errors made by the Bidder, in which case such corrections shall be initialed by the person or persons signing the bid.


12.10 Consortium Bids No Consortium is allowed.

12.11 Venue & Deadline for submission of proposals 1. Proposals, in its complete form in all respects as specified in the RFP, must be submitted

online at address specified in Section 1 Clause 1. 2. Last Date & Time of submission: Before the date and time stipulated in schedule given in

Section 1 Clause 2. 3. e-Pragati may, in exceptional circumstances and at its discretion, extend the deadline for

submission of proposals by issuing an addendum. All such addendums will be published on the website given under Section 1 Clause 1. In such a case of extension, all rights and obligations of e-Pragati and the bidders previously subject to the original deadline will thereafter be subject to the deadline as extended.

12.12 Late Bids Bids received after the due date and the specified time (including the extended period if any) for any reason whatsoever, shall not be entertained and shall be returned unopened.

12.13 Conditions under which this RFP is issued 1. This RFP is not an offer and is issued with no commitment. e-Pragati reserves the right to

withdraw the RFP and change or vary any part thereof at any stage. e-Pragati also reserves the right to disqualify any bidder, should it be so necessary at any stage for any reason whatsoever.

2. Timing and sequence of events resulting from this RFP shall ultimately be determined by e-Pragati.

3. No oral conversations or agreements with any official, agent, or employee of e-Pragati shall affect or modify any terms of this RFP and any alleged oral agreement or arrangement made by a bidder with any department, agency, official or employee of e-Pragati shall be superseded by the definitive agreement that results from this RFP process. Oral communications by e-Pragati to bidders shall not be considered binding on e-Pragati, nor shall any written materials have provided by any person other than e-Pragati.

4. Neither the bidder nor any of the bidder’s representatives shall have any claims whatsoever against e-Pragati or any of their respective officials, agents, or employees arising out of, or relating to this RFP or these procedures (other than those arising under a definitive service agreement with the bidder in accordance with the terms thereof).

5. The information contained in this document is only disclosed for the purposes of enabling bidders to submit a proposal to e-Pragati. No part of this document including the Annexures can be reproduced in any form or by any means, disclosed or distributed to any party not involved in the bid process without the prior consent of e-Pragati except to the extent required for submitting bid. This document should not therefore be used for any other purpose.

12.14 Rights to the Content of the Proposal: All the bids and accompanying documentation submitted as bids against this RFP will become the property of e-Pragati and will not be returned after opening of the proposals. e-Pragati is not restricted in its rights to use or disclose any or all of the information contained in the proposal and can do so without compensation to the bidders. e-Pragati shall not be bound by any language in the proposal indicating the confidentiality of the proposal or any other restriction on its use or disclosure. e-Pragati has the right to use the services of external experts to evaluate the proposal by the bidders and share the content of the proposal either partially


or completely with the experts for evaluation with adequate protection of the confidentiality information of the bidder.

12.15 Modification and Withdrawal of Proposals: 1. No Bid shall be modified, substituted or withdrawn by the Bidder on or after the Bid Due

Date. Entire bid security shall be forfeited if any of the bidders modify or withdraw their bid during the bid validity period.

2. Any alteration/ modification in the Bid or additional information supplied subsequent to the Bid Due Date, unless the same has been expressly sought for by the e-Pragati, shall be disregarded.

3. The RFP/ bid submission process is according to the e-Procurement process. The procedure for modification, substitution and withdrawal of bids shall be as specified in the e-Procurement website mentioned in the Section 4 of this RFP. Hence, bidders are advised to go through such procedures stated in the online procurement portal of e-Pragati.

4. The Bidder may modify, substitute or withdraw its Bid after submission, provided the same is done before the last date of bid submission or that written notice of the modification, substitution or withdrawal is received by the e-Pragati prior to the last date and time for submission of Bid. However, after the last date of bid submission modification, substitution or withdrawal of bid will not be permitted and such modified/ substituted bid will not be considered for evaluation.

12.16 Non-Conforming Proposals: A proposal may be construed as a non-conforming proposal and ineligible for consideration:

1. If it does not comply with the requirements of this RFP. 2. If a proposal appears to be “canned” presentations of promotional materials that do not

follow the format requested in this RFP or do not appear to address the particular requirements of the proposed solution, and any such bidders may also be disqualified.

12.17 Acknowledgement of Understanding of Terms: By submitting a proposal, each bidder shall be deemed to acknowledge that it has carefully read all sections of this RFP, including all forms, schedules and annexure hereto, and has fully informed itself as to all existing conditions and limitations.

12.18 Offer Validity period The offer should remain valid for a period of 180 days from the date of the submission of offer. A proposal valid for a shorter period may be rejected as nonresponsive. On completion of the validity period, unless the bidder withdraws his proposal in writing, it will be deemed to be valid until such time that the bidder formally (in writing) withdraws his proposal. In exceptional circumstances, at its discretion, e-Pragati Authority may solicit the bidder's consent for an extension of the validity period. The request and the responses thereto shall be made in writing or by fax or email.

12.19 Language of Proposals The proposal and all correspondence and documents shall be written in English.

12.20 Non-Disclosure of Confidential Information The Bidder shall maintain the security, nondisclosure and confidentiality of all information in accordance with the following clauses in performance of its activities under the Contract. Bidder shall


ensure that its personnel, agents, officers and other resources, if any, are fully aware of the obligations arising under this Exhibit and shall take all commercially reasonable steps to ensure compliance. The Contract may be terminated by the e-Pragati Authority for cause for a material breach of this Exhibit.

12.20.1 Security Procedures: Bidder warrants, covenants and represents that it shall comply fully with all security procedures and policies of the e-Pragati Authority, which procedures and policies are communicated to the Bidder by the e-Pragati Authority during the performance of the Contract. Bidder shall hold the e-Pragati Authority harmless from any loss or damage to the e-Pragati Authority resulting from the violation of such security procedures or policies by the Bidder, its officers, agents, employees, and other resources. The Bidder shall comply with the following specific security procedures:

o Data Access – The Bidder must ensure that all data related to this project is stored in a controlled access environment to ensure data security and integrity. All facilities proposed for use must have adequate security systems in place to protect against the unauthorized access to the facilities and data stored therein. Adequate security systems must be in place to control access into the facilities. Access into and within the facilities must be restricted through an access control system that requires positive identification of authorized individuals as well as maintains a log of all accesses (e.g., date, time, who). The Bidder shall have a formal procedure in place for granting computer system access to the data and to track access by its own employees. Access for projects outside of those approved by the e-Pragati Authority is strictly prohibited.

o Location of Data – Unless otherwise noted in the contract, all the e-Pragati Authority data exchanged with the Bidder must be stored, housed, processed, backed-up, archived and otherwise retained on systems physically located in India or designated online systems provided by the e-Pragati Authority. This requirement extends to any human resources deployed by the Bidder to handle data storage service.

o Data Exchange – Except as otherwise stipulated in the contract, Bidder shall make arrangements to receive or exchange all the e-Pragati Authority supplied or designated electronic information via the e-Pragati Authority's systems of record. The e-Pragati Authority information in other formats must be exchanged via an official contact identified in the contract.

o Physical Transport of Data – The Bidder shall use reputable means to transport data. Deliveries must be made either via hand delivery by an employee of the Bidder or by restricted delivery via courier (e.g., FedEx, India Post, DHL, Blue dart) with shipment tracking and receipt confirmation. This applies to transport between the Bidder’s offices, to and from other government departments of AP and to the e-Pragati Authority.

o Electronic Transport of Data – The Bidder shall use reliable means of electronically transferring data between the e-Pragati Authority and Bidder’s devices, offices and facilities. Such means must assure the confidentiality and integrity of the data while in transit.

o Data Protection – The Bidder shall use appropriate means to preserve and protect the e-Pragati Authority data. This includes, but is not limited to, use of stable storage media, regular data backups and archiving, password protection of volumes, and data encryption. The Bidder shall encrypt data identified by the e-Pragati Authority, as requiring encryption and it shall use encryption methods that have Federal Information Processing Standard (FIPS) 140 validation.


o Data Destruction – At the end of this contract, the Bidder shall employ the technical measures necessary to assure the secure, irreversible erasure or destruction of all data storage formats to eliminate any and all data collected or generated by the Bidder and/or provided by the e-Pragati Authority unless explicit provisions for the retention of some data sets have been stipulated in the contract. The destruction process must receive written approval by the e-Pragati Authority.

o Return of Data – Upon written request of the e-Pragati Authority, at any time during the term and upon expiration or termination of the contract, the Bidder shall promptly return to the e-Pragati Authority, in the format and on the media requested by the e-Pragati Authority, all or any part of the e-Pragati Authority data collected during the term of the contract.

o Data Breach Notification –below, Bidder agrees that it shall immediately report to the e-Pragati Authority the discovery of any unauthorized use or unauthorized disclosure of such Confidential Information [See Section B: Nondisclosure and Confidentiality] directly to the e-Pragati Authority.

The terms of this section shall apply equally to Bidder, its agents and other human resources, if any. Bidder agrees that all resources, if any, and agents shall be made aware of and shall be made contractually bound to the terms of this section. Upon request by the e-Pragati Authority, Bidder may be asked to provide a recent independent audit report on security controls. The e-Pragati Authority shall have the right to send its officers and employees into the offices of the Bidder for inspection of the facilities and operations used in the performance of any work under the Contract. On the basis of such inspection, specific measures may be required in cases where the Bidder is found to be non-compliant with Contract safeguards.

12.20.2 Nondisclosure and Confidentiality Except as may be required by applicable law or a court of competent jurisdiction, the Bidder, its officers, agents, employees, and other human resources, if any, shall maintain strict confidence with respect to any Confidential Information to which the Bidder, its officers, agents, employees, and other human resources, if any, have access. This representation shall survive termination of the Contract. For purposes of the Contract, all the e-Pragati Authority information of which Bidder, its officers, agents, employees, and other human resources, if any, becomes aware during the course of performing Services for the e-Pragati Authority shall be deemed to be Confidential Information (oral, visual or written, in paper, electronic or any other format). Notwithstanding the foregoing, information that falls into any of the following categories shall not be considered Confidential Information:

o Information that is previously rightfully known to the receiving party without restriction on disclosure;

o Information that becomes, from no act or failure to act on the part of the receiving party, generally known in the relevant industry or is in the public domain; and

o Information that is independently developed by Bidder without use of Confidential Information of the e-Pragati Authority.

Bidder shall hold the e-Pragati Authority harmless, without limitation, from any loss or damage to the e-Pragati Authority resulting from the disclosure by the Bidder, its officers, agents, employees, and resources of such Confidential Information.


12.20.3 Central or State Requirements In the event that it becomes necessary for Bidder to receive Confidential Information, which Central or State statute or regulation prohibits from disclosure, Bidder hereby agrees to return or destroy all such Confidential Information that has been received from the e-Pragati Authority when the purpose that necessitated its receipt by Bidder has been completed. In addition, Bidder agrees not to retain any Confidential Information which Central or State statute or regulation prohibits from disclosure after termination of the Contract. Notwithstanding the foregoing, if the return or destruction of the Confidential Information is not feasible, Bidder agrees to extend the protections of the Contract for as long as necessary to protect the Confidential Information and to limit any further use of disclosure of that Confidential Information. If Bidder elects to destroy Confidential Information, it shall use reasonable efforts to achieve the same and notify the e-Pragati Authority accordingly. Bidder agrees that it will use all appropriate safeguards to prevent any unauthorized use or unauthorized disclosure of Confidential Information, which Central or State statute or regulation prohibits from disclosure. Bidder agrees that it shall immediately report to the e-Pragati Authority the discovery of any unauthorized use or unauthorized disclosure of such Confidential Information directly to the e-Pragati Authority. The terms of this section shall apply equally to Bidder, its agents and resources, if any. Bidder agrees that all resources, if any, and agents shall be made aware of and shall be bound contractually to the terms of this section.

12.21 Criteria for Eligibility of System Integrator for Concurrent Project To ensure that adequate resources are available and deployed for the e-Pragati Projects, the concurrent number of projects for any Empaneled System Integrator will be based on following table:

Sl. No. # of Pega Certified Resources Available with Empaneled SI in India # Concurrent Projects

1 More than 50 but less than 150 Pega Certified Resources Up to 2

2 More than 150 but less than 300 Pega Certified Resources Up to 5

3 More than 300 Pega Certified Resources Up to 8

RESOURCE-PROJECT RELATION TABLE The SI has to ensure that they are working on number of projects according to this table and in compliance with number of resources present in the list submitted during the Empanelment Process. (Submit Form P8). In case of System Integrator whose current project will be completed before the closing date for a new RFP, they can seek a special permission by sending an email to [email protected] . Once this approval received from procurement team based on actual timeline of previous project. They can submit the proposal for this RFP, attaching email printout to Form P8.



13 Master Service Agreement (MSA) Master Service Agreement- Template

This Master Service Agreement (“Agreement”) is made on this day ___________ 2018 (“Execution

Date”):

1. The e-Pragati Authority, a society duly incorporated under the provisions of the Andhra Pradesh Societies Registration Act, 2001 and having its registered office at 3rd Floor, NTR Administrative block, Andhra Pradesh – 522503, represented herein by its chief executive officer, Mr. N Bala Subramanyam, IPS, (hereinafter referred to as the “ Contracting Authority” which expression shall unless repugnant to the subject or context thereof, mean and include the said society, its executors, assigns and successors-in-interest) of the One Part

And

2. ___ a company registered under the Companies Act, 1956 and its subsequent amendments having its registered office at __ ____ and place of business at ____ represented through its ____, who is duly authorized by the Service Provider through the Board resolution of the Service Provider. (hereinafter referred to as "Service Provider / Selected System Integrator" from Panel of Empaneled System Integrators, which expression, unless excluded or the context otherwise required hereof includes its successors, administrators and assigns) of the Second Part;

WHEREAS

A. The Contracting Authority intends to engage a service provider for undertaking the (i) supply of e-Pragati Core Platform (e-PCP), (ii) Setting up of e-Pragati Core Platform on the Hosting Platform , (iii) configuration of e-Pragati Core Platform, (iv) submission of a manpower rate card for the design, configuration (develop) & maintenance of business applications on Configured e-Pragati Core Platform (, (v) setting up applications for provision of Specific Service, (vi) administration, support, Operations &Maintenance of the Configured e-Pragati Core Platform, (vii) provision of annual technical support & updates, (viii) provision of center of excellence (“CoE”) team, and (ix) provision of capacity building services of a whole system across all the locations of Andhra Pradesh as identified by the Contracting Authority on a turnkey basis for the Configured e-Pragati Core Platform and to accomplish the ultimate objective of providing a platform for all modules under e-Pragati related services to the citizens in an efficient, convenient and transparent manner (the “Project”).

B. In pursuance to the RFP for the Project upon evaluation Ernst and Young was selected as the Master System Integrator for the Project and an MSA was executed on 27th November, 2018 in this regard between the Contracting Authority and the Ernst & Young.

C. Additionally, for the purpose of the Project, it has been envisaged that more layers of group

are to be designed as a common, group and department specific applications, in increasing degrees of freedom of choice of technical, designs and functionalities, which shall be implemented and developed by various System Integrators empaneled by the Contracting Authority. Upon receiving requests from line-department along with the basic functionality, which will be studied by the e-Pragati authority and e-Pragati Authority shall prepare a


detailed Scope of Work (SoW) with required BPR to Design, Develop, Integrate and Maintain the desired services and applications in consultation with line department and shall issue Request for Proposal in respect of the same. It is being clarified that the SoW shall be granted to one of the empaneled System Integrators subject to being selected as successful bidder in pursuance of the RFP.

D. In view of the above e-Pragati Authority, ITE&C Department, Government of Andhra Pradesh

issued an Empanelment Process (“EP”) dated ________ in respect of Empanelment of System Integrators (SI) to Design, Develop, Integrate and Maintain Applications and Services on ePCP and to participate in the e-Pragati program by being eligible to submit proposals in respect of such services. In pursuance of the Empanelment Process, upon fulfilment of the eligibility criterion and all the conditions mentioned therein the EP, the Service Provider being a certified Pega Partner was issued an empanelment letter appointing it as one of the Selected System Integrators.

E. The Contracting Authority and the Selected System Integrator wish to agree upon certain

broad specific terms and conditions which will govern their relationship if and when they agree upon specific services to be performed. Further, it is agreed that upon specific SOW being awarded to the Selected System Integrator by the Contracting Authority a detailed Agreement shall be executed between the Parties;

The Contracting Party and Service Provider are hereinafter individually referred to as a “Party” and

collectively as “Parties”.)

NOW THEREFORE, in consideration of the mutual obligations herein, the parties hereto, intending to be legally bound, hereby agree as follows: Section 1 Scope of Services 1.1 During the term of this Agreement, the Selected Service Provider shall be entitled to

participate in the process to provide services related to Design, Develop, Integrate and Maintain Applications and Services on ePCP (hereinafter “Services”) and if the SOW is awarded to it upon being selected as a successful bidder in pursuance of the Request for Proposal issued by the Contracting Authority, it shall provide the services in strict accordance of such SOW and the RFP.

1.2 Upon being selected as successful bidder in pursuance of the RFP in respect of specific services the Selected Service provider shall execute a detailed Master Service Agreement providing for detailed roles and responsibilities of the Selected system Integrator and terms and conditions including the Service Level Agreement.

1.3 The Selected System Integrator understands and acknowledges that this Agreement or the Empanelment Letter by itself does not constitute an offer by the e-Pragati Authority in respect of the SoW. The Service provider’s participation in this process may result in the e-Pragati Authority selecting it to engage in further discussions towards execution of an Agreement in the respect of the SOW. The commencement of such discussions does not, however, signify a commitment by the e-Pragati Authority to grant SoW.

Section 2


Fees and Payment Terms 2.1 The Selected System Integrator shall be paid fees in accordance with the terms of the RFP

inclusive of all taxes which may be more explained more elaborately in the Final Master Services Agreement to be executed between the Contracting Authority and the Selected System Integrator.

Section 3 Term and Termination 3.1 Unless the Agreement is terminated earlier, the term of this Agreement shall be until Friday,

December 21st, 2018 i.e. 180 days from the Project Awarding Date (Friday, June 25th, 2018 6:00PM)

3.2 This Agreement may be terminated by either party at any time during the term of this

Agreement, provided that at least thirty (30) days prior written notice is given to the other party.

3.3 This Agreement may be terminated upon fifteen (15) days prior written notice by the non-defaulting party if the other party has materially breached the provisions of this Agreement and has not cured such breach within such notice period. In such case, the non-defaulting Party shall be entitled to all such rights under the applicable law.

3.4 The System Integrator acknowledges that the empanelment is based on the details and

information/documents submitted by it in respect of which the Contracting Authority reserves the right to verify the credentials submitted by it. If at any stage, any information submitted by it is found to be incorrect/false or have some discrepancy which disqualifies the applicant bidder, then the Contracting Authority reserves the right to terminate this Agreement immediately causing the cancellation of the empanelment of the System Integrator immediately and may initiate any other appropriate action against the Empaneled System Integrator including blacklisting.

Section 4 Representation and Warranties

The Selected System Integrator represents and warrants to the Contracting Authority as follows: 4.1 That they have full capacity, power and authority and has obtained all requisite consents and

approvals to, enter into and to observe and perform this Agreement and to consummate the transactions contemplated hereunder. Persons executing this Agreement on behalf of the Selected System Integrator have full capacity and authority to sign and execute this Agreement.

4.2 The execution, delivery and consummation of, and the performance by it, of this Agreement shall not conflict with, violate, result in or constitute a breach of or a default under, (a) any contract by which it, are bound or affected, and/ or (b) its constitutional documents; 4.3 This Agreement constitute its legal, valid and binding obligations, enforceable against it, in accordance with their terms under Applicable Laws Section 5 Confidential Information


Except as expressly authorized herein, the Receiving Party will hold in confidence and not use or disclose any Confidential Information. The Receiving Party’s nondisclosure obligation shall not apply to information which the Receiving Party can document: (I) was rightfully in its possession or known to it prior to receipt of the Confidential Information; (ii) is or has become public knowledge through no fault of the Receiving Party; (iii) is rightfully obtained by the Receiving Party from a third party without breach of any confidentiality obligation; (iv) is independently developed by employees of the Receiving Party who had no access to such information; or (v) is required to be disclosed pursuant to a regulation, law or court order (but only to the minimum extent required to comply with such regulation or order and with advance written notice to the Disclosing Party). Each party will only disclose Confidential Information to its employees, agents, representatives and authorized contractors (collectively “Representatives”) having a need to know for the purposes of this Agreement. Each party will notify and inform such Representatives of each party's limitations, duties, and obligations regarding use, access to, and nondisclosure of Confidential Information and will obtain or have obtained its Representatives' agreements to comply with such limitations, duties, and obligations with regard to such Confidential Information no less restrictive than those contained herein. Each party is liable for all acts and omissions of the Representatives related to the other party’s Confidential Information. Each party agrees to give notice to the other party immediately after learning of or having reason to suspect a breach of any of the proprietary restrictions set forth in this Section. The Receiving Party acknowledges that disclosure of Confidential Information would cause substantial harm for which damages alone would not be a sufficient remedy, and therefore that upon any such disclosure by the Receiving Party the Disclosing Party shall be entitled to appropriate equitable relief in addition to whatever other remedies it might have at law. Confidential Information shall not include information that (I) is or becomes generally known to the public through no breach of any confidentiality obligation; (ii) is rightfully known to Licensee at the time of disclosure by Licensor without violation of any confidentiality restriction and without any restriction on Licensee's further use or disclosure; or (iii) is independently developed by Licensee without any use of or reference to Licensor's Confidential Information Section 6 Miscellaneous 6.1 The Selected System Integrator shall indemnify and hold harmless the Contracting Authority and its affiliates and their respective directors, officers, employees, agents and representatives from and against any and all direct losses, damages, costs and expenses (including, without limitation, reasonable attorneys’ fees and expenses) caused by or arising out of any finally determined breach of this Agreement or any breach for it is responsibility hereunder, and any and all actions, suits, proceedings, claims, demands or judgments incident thereto. 6.2 The Selected System Integrator hereby agrees that its failure to perform any obligation or duty which it has agreed to perform under this Agreement may cause irreparable harm to the Contracting Authority which harm cannot be adequately compensated for by money damages. It is further agreed by both Parties that an order of specific performance or for injunctive relief against the Selected System Integrator in the event of a breach or default under the terms of this Agreement would be an equitable remedy. Accordingly, in the event of a breach or default by the Selected System Integrator hereunder, the Contracting Authority, in addition to whatever other remedies are or might be available at law or in equity, shall have the right either to compel specific performance by, or to obtain injunctive relief against, the Selected System Integrator with respect to any obligation or duty herein or breach thereof.


6.3 The Parties hereby agree that unless and until a final definitive agreement in the form of detailed Master Service Agreement between the Parties has been executed and delivered, neither the Contracting Authority nor the Selected System Integrator will be under any legal obligation of any kind whatsoever with respect to the Project by virtue of this Agreement except for the matters specifically agreed to herein. 6.4 The Contracting Authority has not granted to the Selected System Integrator any licenses, by implication or otherwise, under any patent, copyright, trademark, trade secret or other rights by disclosing the Confidential Information to the Selected System Integrator under this Agreement. The Contracting Authority shall retain all proprietary and intellectual Property Rights in respect of the disclosed confidential information and it is clarified that the use of the disclosed Confidential Information shall be in strict accordance with the terms of the Agreement. 6.5 All disputes, differences or claims arising out of or in connection with this Agreement including, any question regarding its existence, validity, construction, performance, termination or alleged violation shall be resolved through binding arbitration in accordance with the provisions of the Arbitration and Conciliation Act, 1996 by a sole arbitrator mutually agreed upon by the Parties. The place of arbitration shall be Vijayawada, India. The language of the arbitral proceedings shall be English. 6.6 If any term or provision in this Agreement is held to be either illegal or unenforceable, in whole or in part, under any enactment or rule of law, such term or provision or part shall to that extent be deemed not to form part of this Agreement, but the validity and enforceability of the remainder of this Agreement shall not be affected. 6.7 This Agreement constitutes the entire agreement between the Parties with respect to the subject matter hereof and supersedes all prior agreements and understandings related to such subject matter. No change, variation or modification of any of the terms and conditions set forth herein shall be valid unless incorporated as an amendment to this Agreement and is signed by the Parties. 6.8 This Agreement shall be binding upon, and inure to the benefit of, and be enforceable by, the Parties hereto and their respective successors and assigns, however, neither Party shall have the right to assign or otherwise transfer its rights or obligations under this Agreement without the prior written consent of the other Party. 6.9 All communications are to be addressed to the address of a Party as provided hereinabove and proof of sending the communication shall be sufficient proof of service. In case of a change of address, such Party shall inform the other in writing and only on receipt of a written confirmation from the concerned Party shall such new address be accepted as the agreed address for communication. 6.10 This Agreement shall be governed by and construed in accordance with the laws of India and in any dispute arising out of or relating to this agreement, the Parties submit to the exclusive jurisdiction of the Courts situated at Vijayawada. 6.11 No failure or delay by the Contracting Authority in exercising any right, power or privilege hereunder shall operate as a waiver thereof, nor shall any single or partial exercise thereof preclude any other or further exercise thereof or the exercise of any right, power or privilege hereunder.


6.13 This Agreement may be executed in any number of counterparts, each of which shall be deemed an original, but all of which taken together shall constitute one and the same instrument. The Parties set forth their signatures below in acceptance of the terms contained herein. Contracting Authority Selected System Integrator Sign: Sign: Name: Name: Designation: Designation: Date: Date: Note: Disclaimer – Final MSA may differ from this MSA and will be based on mutual agreement between contracting parties.


14 Evaluation Process 14.1 Prequalification Criteria Bidder must be an Empaneled System Integrator (ESI) with e-Pragati Authority on submission date with a valid and authorized Letter of Empanelment (LoE) issued by CEO, e-Pragati Authority. Note: Approximately two sprints are treated as equal to one-man month for base line purpose.

14.2 Commercial Evaluation 14.2.1 The timespan for competition of the task in this RFP The SI has to complete the commencement of the project within 210 days from date of Project awarding.

14.2.2 Mandatory Team Composition for the Project Awarding (Sprint Team) To ensure that, e-Pragati does not want to compromise with the quality of work, the e-Pragati Authority enforce minimum team composition for every subsequent project implemented under the purview of this RFP and ensure that the proposed team comprises of minimum resources from following mandatory composition: Dedicated Resources for each Sprint Team

a) Pega Lead System Architect (LSA) (Per Project) - 1 Nos





f) UI Developer (Per Project) - 1 Nos

Shared Resources for each System Integrator

a) UX Designer (Per SI) - 1 Nos

b) Project Manager (Per SI) - 1 Nos

c) Delivery Manager (Per SI) - 1 Nos

d) Data Migration Expert (Per Project) - 1 Nos

Note: The shared resources will be billed for 50% of the rate card, in case of Single Project or Sprint

Team is in execution mode with e-Pragati Authority. For optimized utilization of shared

resources working on more than 2 Projects with Single Sprint Team or Single Project with more

than 2 Sprint Teams, System Integrator can initiate an invoice for full cost from card for shared

resources i.e. maximum billing for shared resources will be only once.

Cost of a team deployed for these 18 resources:

Dedicated Resources for Sprint Team:


Shared Resources in Case of only 1 Sprint is in execution:

Shared Resources in Case of more than 2 Sprints are in execution:

Depending on Number of Sprints in progress,

B = B1 or B2 Note: SI has to ensure that proposed number of resources are adequate to form Sprint Teams in complete i.e. all the proposed members are present during the sprint from Section 14.2.2.

14.2.3 Details of the Sprint Teams working parallelly in a Month To complete the work in 180 days, SI can propose multiple Sprint Teams to work in parallel. The Number of Sprint Teams which are working for this project in parallel must be mentioned in following table.

Sl. No. Name of the Sprint Time Utilization (in Particular Months)

1 Sprint Team 1 2 Sprint Team 2

3 Sprint Team 3

4 Sprint Team…

Total count of Sprints (C)


14.2.4 Number of Resources The following rates are binding to us for proposed resources for this project and in addition to above resources, SI perceives that additional resources are required to be deployed for smooth execution of the project, we request you to consider these resources for as Cost Units for quoted proposal.

Sl. No. RateTime Frame

(in Month)

Sprint wise

CountTotal Count Total Cost

1 7,31,040

2 3,93,573

3 3,93,573

4 3,01,101

5 2,50,000

6 2,54,054

7 2,47,167

8 2,21,600

9 2,21,600

10 4,29,563

11 2,54,054

12 2,25,000

13 2,46,719

14 2,25,000

15 2,25,000

16 2,98,300

17 2,98,300

18 2,54,054

19 2,25,000

20 2,79,017

21 2,23,300

Data Quality Expert/ Data

Migration Expert

Designated Role/Title

Chief Enterprise Architects

Solution Architects/ Pega

Lead Business Architect

Delivery Manager/ Head

Program Manager

UI Developer

Sr. Business Analyst / Pega

Solutions Consultant

Senior Business Architects

Senior System Architects

Data Architects/ Tester

Engagement Leader

/Project Manager

Product Owner/ Pega Lead

System Architect

Database Administrator

Big Data Administrator

Functional Tester/ Quality

Experts

Performance/Stress/Load

Tester

UX Designer

Total Cost (D) for Specific Month Invoice

Sr. Developer /

Programmer/ Integration

Experts/Pega Sr. System

Architect

Jr. Developer /

Programmer/ Integration

Experts/Pega System

Architect

Proposed Product Trainer

Technical Document Writer

14.2.5 Cost of Invoice for Specific Month

Invoice Amount = A * C + B + D


Where,

A = Cost of Dedicated Resources per Sprint Team B = Cost of Shared Resources per Sprint Team C = No. Sprint Team Proposed as a response to RFP D = Cost of Additional Resources proposed from Rate Card.

14.2.6 Cost of Operations and Maintenance

Resource Name Sharing of Resources

Count Duration for Deployment

Price from Rate Card

Pega Senior System Architect (SSA) Per Project 1 36 Months 2,54,054 Pega System Architect (SA) Per Project 2 36 Months 2,25,000

Total O&M for team of 3 (Per Month to execute O&M) (E)

These rates are aligned with rate Card Proposed in this RFP and since this a fixed team, can be excluded from Commercial Proposal.

14.2.7 Total Cost of the Project The e-Pragati Authority is of view that System Integrator has accounted number of resources mentioned in Sprint Team from Section 14.2.2 and are adequate to deliver approximately Xn user stories in 2 weeks span. Based on this proposal, System Integrator has proposed following timelines and quotation for completion of work assigned through this RFP.

Sl. No. Name of

the Module Date for Delivery

Proposed User

Stories

# Sprints required

Proposed Parallel Sprints

# User Stories/ Sprint

Commercial Quote

1

Sprint Team 1

Sprint Team 2

Sprint Team …

2

Sprint Team 1

Sprint Team 2

Sprint Team …

3

Sprint Team 1

Sprint Team 2

Sprint Team …

4

Sprint Team 1

Sprint Team 2

Sprint Team …

…. …. …. …. …. …. ….

Cost of Operations and Maintenance for 180 days till Go Live (X)


Sl. No. Name of

the Module Date for Delivery

Proposed User

Stories

# Sprints required



Commercial Quote

Cost of Operations and Maintenance for 36 Months from Go Live (Y)

<<Cost of proposed Resources for 36 Months>>

Gran Total (X+Y)

Final Quote for deciding L1

14.2.8 Resolution of Equal Quotes

o In case of situation where, two or more bidders have submitted the same quotes, the bidder with minimum proposed timelines for completion will be awarded the project.

o In case of situation where, two or more bidders have submitted the same quotes and timelines, the “Lottery System” will be used for resolution of tie in presence of representatives of concerned Sis based on approval from Project Awarding Committee and the selected bidder will be awarded the project.

14.2.9 Cost of Commute incurred during the Project This is to convey to SIs that, cost of the necessary commute or any other expenses incurred during the project execution for requirement gathering, UAT and any other work, will be sole responsibility of the System Integrator and should be accounted while submitting a quote for this proposal.


15 Annexure

15.1 Form P1: Letter of Empanelment

(On the Letterhead of the Bidder)

Date: [●]

To,

The CEO, The e-Pragati Authority, GoAP 3rd Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 001

Re: Design, Develop, Integrate, Maintain and Enhance Application & Services for AP Real Estate Regulatory Authority (APRERA) Department on e-Pragati Authority Core Platform (ePCP) of e-Pragati Authority. Sir, This is to confirm that, we are an Empaneled System Integrators (ESI) with a valid Letter of Empanelment (LoE) issue by CEO, e-Pragati. Please find the attached copy of LoE. Thanking you, Sincerely, [Bidder's name with seal] [Authorized Signature (in full and initials) Name and Title of Signatory Address, Location and Date

Enclosed: Copy of Letter of Empanelment (LoE) issued by CEO, e-Pragati


15.2 Form P2: Pending Litigation

(EACH APPLICANT MUST FILL IN THIS)

Date: ................................... Name................................................................. In the capacity of................................................................. Signed................................................................. Duly authorized to sign the Application for and on behalf of.................................................... Stamp / Seal……………………………………………………….

Applicant Partner Legal Name.................................................................

No pending litigation Pending litigation is indicated below Year

Matter in Dispute

Value of Pending Claim in INR Equivalent

Value of Pending Claim as a % of Net Worth


15.3 Form P3: Format for Self-Declaration on Blacklisting

(Company Letterhead) Date

To, CEO,

The e-Pragati Authority, GoAP 3rd Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 001 Andhra Pradesh, India

Sir, In response to the EP No.___________________________________________ dated___________ for quoting against the EP as an Director of M/s << Proposer>> , I / We hereby declare that our Company / Firm ___________________is having unblemished past record and was not declared blacklisted or ineligible to participate for Proposal Submission as on date of submission of the Proposal by any State/Central Govt. or PSU due to, breach of general or specific instructions, corrupt /fraudulent , Non Performance or any other unethical business practices. Yours faithfully, Authorized Signatory_______________ Name_______________________ Designation____________________ Company name___________________


15.4 Form P4: Self-Declaration/ Self- Certification (CoI)

(Company Letterhead)

Date To,

CEO, The e-Pragati Authority, GoAP 3rd Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 001 Andhra Pradesh, India

Sub: Undertaking on Conflict of Interest Sir, I/We as Primary SI (SI) do hereby undertake that there is absence of, actual or potential conflict of interest on the part of the SI or any prospective OEM due to prior, current, or proposed contracts, engagements, or affiliations with the Contracting Authority. I/We also confirm that there are no potential elements (time frame for service delivery, resource, financial or other) that would adversely impact the ability of the SI to complete the requirements as given in the RFP. We undertake and agree to indemnify and hold the Contracting Authority harmless against all claims, losses, damages, costs, expenses, proceeding fees of legal advisors (on a reimbursement basis) and fees of other professionals incurred (in the case of legal fees & fee of professionals, reasonably) by the Contracting Authority and/or its representatives, if any such conflict arises later. Yours faithfully, Authorized Signatory Designation


15.5 Form P5: Format of the Letter of Understanding and Commitment

Format of the Letter of Commitment

(On the Letterhead of the Bidder)

Date: [●]

To,


Re: Design, Develop, Integrate, Maintain and Enhance Application & Services for AP Real Estate Regulatory Authority (APRERA) Department on e-Pragati Authority Core Platform (ePCP) of e-Pragati Authority. Sir, This has reference to the Proposal being submitted by______________ (name of the bidder) in respect project_________________. We hereby acknowledge and confirm the following: We, ______________ (name of the bidder), have examined in detail and have understood and satisfied ourselves regarding the requirements of the Project, including in respect of the following:

o The Request for Proposal issued by the e-Pragati Authority; and

o All subsequent written communications issued by the e-Pragati Authority to the Bidders. I declare that all the provisions of this RFP/Tender Document are acceptable to my company and we agree to work in compliance with e-Pragati and Pegasystems guidelines wherever they are binding and applicable. I further certify that I am an authorized signatory of my company and I am, therefore, competent to make this declaration. Thanking you, Sincerely, [Bidder's name with seal] [Authorized Signature (in full and initials) Name and Title of Signatory Address, Location and Date


15.6 Form P6: Project Plan

[On the letterhead of the Bidder] Letter of Technical Proposal

Date: [●] To,


Subject: Submission of the Project Plan for the functional scope specified in the RFP dated [ ] Dear Sir, We, the undersigned, offer to provide the following services in accordance with the RFP/Bidding. Documents for RFP to Design, Develop, Integrate, Maintain and Enhance Application & Services for AP Real Estate Regulatory Authority (APRERA) Department on e-Pragati Authority Core Platform (ePCP) of e-Pragati Authority. We are hereby submitting our Project Plan in this regard. Project Plan Covers:

1. High level understanding of functional requirement in this RFP. 2. Gantt Chart for Deliverables and Milestones 3. Resource Management.

Thanking you, Sincerely, [Bidder's name with seal] [Authorized Signature (in full and initials) Name and Title of Signatory Address, Location and Date Enclosed: Project Plan Note


15.7 Form P7: Resume Format (Please fill the details for each of the proposed team members)

Resume Format for Resources proposed in this RFP:

S. No Article Description

1. Name: 2. Date of Birth:

Nationality:

3. Contact details:

4. Education: Name of Institution Degree obtained (Subject) Date of obtainment

5. Professional Training:

6. Professional Certifications: 7. Platform based Certifications:

8. Countries of Work Experience:

9. Languages: Speaking Reading Writing

English Hindi

Telugu

… 10. Employment Record:

a. From: To: Till Date

Employer:

Positions held:

b. From: To: Till Date

Employer:

Positions held:

c.

11. Detailed Tasks Assigned:

12. Work Undertaken that Best Illustrates Capability to Handle the Tasks Assigned i. Name of the Project:

Year: Duration: Client: Main project Features: Position Held: Activities Performed:

ii. Name of the Project: Year: Duration: Client: Main project Features: Position Held:


S. No Article Description Activities Performed:

13. Certification:

I, the undersigned, certify that to the best of my knowledge and belief, this CV correctly describes me, my qualifications, and my experience. I understand that any willful misstatement described herein may lead to my disqualification or dismissal, if engaged. Date: Authorized signatory:


15.8 Form P8: Status of engagement of SI for Concurrent Projects with e-Pragati

(Company Letterhead) Date

To, CEO, The e-Pragati Authority, GoAP 3rd Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 001 Andhra Pradesh, India

Sub: Undertaking for current status of engagement of SI for Concurrent Projects with e-Pragati. Sir, I/We as Primary SI (SI) do hereby undertake that we are currently working as a System Integrator on following Concurrent Projects which are either in Design, Develop or Enhancement phase. List of Project:

Sl No Project ID Name of Project Owner of the Project Start Date Go-Live Date # Resources

List of Resource for individual Project with Project ID:

S.No Project ID Name (as Per Payroll Records) Designation Pega Certification Certification Email id

We declare that completely understand the scope and requirements of the e-Pragati Program, assure that we are in compliance towards Section 12.21 (Criteria for Eligibility of System Integrator for Concurrent Project). Yours faithfully, Authorized Signatory Designation


15.9 Form C1: Commercials (On the Letterhead of the Bidder)

Date To,

The CEO, The e-Pragati Authority, GoAP 3rd Floor, NTR Administrative Block Pandit Nehru Bus Station, Vijayawada – 520 001 Andhra Pradesh, India

Dear Sir, We, the undersigned, offer to provide the System Integration Services for development and implementation of applications and services on e-Pragati Core Platform of the e-Pragati program in Andhra Pradesh in accordance with your Request for Proposal dated <<Date>>>. Our attached Financial Proposal agrees to the rate cards approved by the e-Pragati Authority and time frame for the empanelment of the SI. We commit to provide following minimum resources per sprint Team:

Dedicated Resources for each Sprint Team a) Pega Lead System Architect (LSA) (Per Project) - 1 Nos





f) UI Developer (Per Project) - 1 Nos

Shared Resources for each System Integrator

a) UX Designer (Per SI) - 1 Nos

b) Project Manager (Per SI) - 1 Nos

c) Delivery Manager (Per SI) - 1 Nos

d) Data Migration Expert (Per Project) - 1 Nos

We understand that, the shared resources will be billed for 50% of the rate card, in case of Single

Project or Sprint Team is in execution mode with e-Pragati Authority. For optimized utilization of

shared resources working on more than 2 Projects with Single Sprint Team or Single Project with more

than 2 Sprint Teams, System Integrator can initiate an invoice for full cost from card for shared

resources i.e. maximum billing for shared resources will be only once.

We have ensured that proposed number of resources are adequate to form Sprint Teams in complete. To complete the work in 180 days, we propose multiple Sprint Teams to work in parallel. We propose,

Based on understanding and proposed number of resources mentioned in Sprint Team from Section B are adequate to deliver approximately Xn user stories per Sprint. Based on this proposal, we propose following timelines and quotation for completion of work assigned through this RFP.

We also commit to provide O&M Team for following composition:


System Integrator has to deploy the following minimum mandatory team for O&M.



(The Proposer may Suggest a change of composition for O&M.)

Sl. No. Name of the

Module Date for Delivery

Proposed User Stories

# Sprints required



Commercial Quote

1

Sprint Team 1

Sprint Team 2

Sprint Team …

2

Sprint Team 1

Sprint Team 2

Sprint Team …

3

Sprint Team 1

Sprint Team 2

Sprint Team …

4

Sprint Team 1

Sprint Team 2

Sprint Team …

…. …. …. …. …. …. ….

Cost of Operations and Maintenance for 180 days till Go Live (X)

Cost of Operations and Maintenance for 36 Months from Go Live (Y) <<Cost of proposed Resources for 36 Months>>

Gran Total (X+Y)

Final Quote for deciding L1

Commercial Quote mentioned for the respective module/Sprint is inclusive of minimum team composition and additional resources, if required for that specific module and sprint. We clearly understand that the only component for identifying the L1 bidder for this RFP will be based on final quote submitted by us in Section D of this form. Our Financial Proposal shall be binding upon us until the expiration of the validity period of the Proposal. We understand you are not bound to accept any Proposal you receive. We remain, Yours sincerely, [Bidder's name with seal] [Authorized Signature (in full and initials) Name and Title of Signatory Address, Location and Date