RFP for Selection of System Integrator for the Design ...dot.gov.in/sites/default/files/2018_03_28...

2018

RFP Reference No.: 1-6/2004/LF II/Vol III RFP Issuing Date: 27/Mar/2018

Tender Issuing Authority: Director – Licensing Finance Assessment Department of Telecommunication Ministry of Communications Sanchar Bhawan, 20 Ashoka Road New Delhi- 110001 Phone: 011-233-72193 Mobile: +91 9868135825 E-Mail: [email protected]

RFP for Selection of System Integrator for the Design, Development, Implementation and Maintenance of Revenue Management System for Department of Telecommunications

Volume – I

Functional & Technical Requirements, Schedule of Services, SLA and Project

Schedule

mailto:[email protected]

RFP for Selection of System Integrator for the Design, Development, Implementation and Maintenance of Revenue Management System for DoT (Volume-I)

Page 1 of 182

Table of Contents

DISCLAIMER ............................................................................................................................................ 4

Abbreviations ......................................................................................................................................... 5

Invitation of e-Bids and Notice Inviting e-Bids (NIB) ............................................................... 8

1.0 Introduction ................................................................................................................................ 11 1.1 Overview ........................................................................................................................................ 11 1.2 Key functions of DoT .................................................................................................................. 11 1.3 Organizational Structure and DoT’s Regional Offices ................................................... 12 1.4 Overview of DoT’s Requirement ........................................................................................... 13 1.5 Key Process in RMS .................................................................................................................... 14

2.0 DoT Key Stakeholders ............................................................................................................... 16

3.0 Functional Requirement Specifications ................................................................................. 20 3.1 Introduction.................................................................................................................................. 20 3.2 Module Wise Detailed Functional Requirements of the Proposed System ............ 22 3.2.1 Setting-up of TSP ......................................................................................................................... 22 3.2.2 Setting-up of Master Table and Master Data ..................................................................... 29 3.2.3 Administration ............................................................................................................................ 44 3.2.4 Bank Guarantee Module ........................................................................................................... 51 3.2.5 Spectrum Usage Charges (SUC) Assessment ..................................................................... 58 3.2.6 License Fee Assessment ........................................................................................................... 74 3.2.6.1 AGR based License Assessment Process .................................................................................... 77 3.2.6.2 Terminal based License Assessment Process ............................................................................ 90 3.2.7 Deduction Verification Report (DVR) Module .................................................................. 98 3.2.8 Court Case Module .................................................................................................................... 111 3.2.9 MIS .................................................................................................................................................. 115 3.2.10 Dashboard (Department/User wise) ................................................................................. 121 3.2.11 Knowledge Bank Module ....................................................................................................... 124 3.2.12 Discussion Board Module ...................................................................................................... 128 3.2.13 Grievance Module ..................................................................................................................... 133 3.2.14 Customer Acquisition Form/ Electromagnetic Field Radiation (CAF/EMR) ....... 138 3.2.15 Budget ........................................................................................................................................... 143

4.0 Technical Requirement Specifications ................................................................................ 145 4.1 Development and Deployment ............................................................................................ 145 4.2 System Architecture ................................................................................................................ 145 4.3 Installation/ Upgrade/ Enhancement ............................................................................... 146 4.4 Import/ Export Facility ........................................................................................................... 147 4.5 Integration .................................................................................................................................. 147 4.6 Workflow Integration Approach ......................................................................................... 147 4.7 Internet Enabled ....................................................................................................................... 148 4.8 Scalability .................................................................................................................................... 149 4.9 Security ......................................................................................................................................... 149 4.10 System Control and Audit ...................................................................................................... 150


Page 2 of 182

4.11 Data Backup/ Data Archival/ Restore ............................................................................... 150 4.12 Data Migration ........................................................................................................................... 151 4.13 User Interface ............................................................................................................................. 151 4.14 Enterprise Management System ......................................................................................... 152 4.15 Operations ................................................................................................................................... 153

5.0 Schedule of Services ............................................................................................................... 154 5.1 Business Process Analysis ..................................................................................................... 154 5.2 System Requirement Study and Preparation of SRS & SDS ....................................... 154 5.3 Design and Development of RMS (Application Software) .......................................... 155 5.4 Integration of RMS .................................................................................................................... 157 5.5 Data Migration ........................................................................................................................... 158 5.6 Testing of RMS............................................................................................................................ 158 5.7 User Acceptance Testing (UAT) ........................................................................................... 158 5.8 Commissioning of RMS and Warranty ............................................................................... 159 5.8.1 Hosting Requirements: ........................................................................................................... 160 5.8.2 Warranty ...................................................................................................................................... 161 5.9 Go-live of RMS ............................................................................................................................ 161 5.10 Annual Maintenance Contract (AMC) of RMS ................................................................. 162 5.10.1 Maintenance and Technical Support: ................................................................................ 162 5.10.2 Helpdesk Support ..................................................................................................................... 164 5.10.3 Change Request ......................................................................................................................... 165 5.10.4 Man Days Bundle and Flexi Packages ................................................................................ 165 5.11 Documentation .......................................................................................................................... 166 5.12 Training and Capacity Building ........................................................................................... 166 5.13 Project Management ................................................................................................................ 168 5.14 Project Monitoring and Reporting ..................................................................................... 168 5.15 Business Continuity Planning .............................................................................................. 169 5.16 Supply of Software/ Application/ RDBMS/ Other related Software/ Licenses .. 169 5.17 Authorization, Security and Access .................................................................................... 169 5.18 DR Drill ......................................................................................................................................... 169 5.19 Disaster Recovery and Back-up Policy .............................................................................. 170 5.20 General Scope ............................................................................................................................. 170 5.21 Deliverables ................................................................................................................................ 171

6.0 Service Level Agreement ....................................................................................................... 174 6.1 Purpose of this Agreement .................................................................................................... 174 6.2 Escalation Mechanism ............................................................................................................. 174 6.3 Availability Management ....................................................................................................... 175 6.4 Service Windows & Severity Levels ................................................................................... 175 6.5 Service Levels ............................................................................................................................. 177 6.6 Penalties in case of Failure to meet Service Levels ...................................................... 178 6.7 SLA Supervision ......................................................................................................................... 178 6.8 SLA Change Control .................................................................................................................. 179 6.9 SLA Change Process.................................................................................................................. 179 6.10 Version Control.......................................................................................................................... 180 6.11 Issue Management Process ................................................................................................... 180 6.12 Issue Escalation Process......................................................................................................... 180


Page 3 of 182

6.13 Risk and Cost Factor ................................................................................................................ 181 6.14 Breach of SLA .............................................................................................................................. 181 6.15 Exclusions .................................................................................................................................... 181

7.0 Project Schedule ..................................................................................................................... 182


Page 4 of 182

DISCLAIMER

This RFP is not an offer by Department of Telecommunications, Government of India (DoT), but an

invitation to receive electronic proposals/ e-bids from interested eligible bidders for selection of System

Integrator for the design, development and maintenance of Revenue Management System for DoT.

No contractual obligation whatsoever shall arise from the RFP process unless and until a formal contract

is signed and executed between DoT and the successful bidder.

This RFP is being issued with no financial commitment and DoT reserves the right to withdraw the RFP

and change or vary any part thereof or foreclose the same at any stage.


Page 5 of 182

Abbreviations

Table 1: Abbreviations

# Abbreviation Explanation

1. AGR Adjusted Gross Revenue

2. BG Bank Guarantee

3. BoM Bill of Material

4. CA Chartered Accountant

5. CAF Customer Acquisition Form

6. CCA Controller of Communication Accounts

7. CMMi Capability Maturity Model Integration

8. CV Curriculum Vitae

9. Day “Day” means calendar day

10. DoT Department of Telecommunication, Government of India

11. DR Disaster Recovery

12. DR Drill Disaster Recovery Drill

13. DR Site Disaster Recovery Site

14. DVR Deduction Verification Report

15. EA Enterprise Architecture

16. EMD Earnest Money Deposit

17. EMR Electromagnetic Field Radiation

18. eSAFE eGovernance Security Assurance Framework

19. FAQ Frequently Asked Question

20. FAT Final Acceptance Testing

21. FBG Financial Bank Guarantee

22. GIGW Guidelines for Indian Government Websites

23. GoI Government of India

24. GR Gross Revenue

25. GST Goods and Services Tax

26. GUI Graphical User Interface

27. HQ Headquarter


Page 6 of 182

28. ICT Information and Communication Technology

29. IEEE Institute of Electrical and Electronics Engineers

30. INR Indian National Rupee

31. ISO International Organisation for Standardisation

32. ISP Internet Service Provider

33. IT Information Technology

34. ITeS Information Technology enabled Services

35. LD Liquidated Damages

36. LF License Fee

37. LFA License Finance Assessment

38. LFP License Finance Policy

39. LoA Letter of Acceptance

40. LoI Letter of Intent

41. MCLR Marginal Cost of Funds Based Lending Rate

42. MeitY Ministry of Electronics and Information Technology, Government of India.

43. MIS Management Information System

44. MWA Microwave Access

45. MWB Microwave Backbone

46. OEM Original Equipment Manufacturer

47. OGPL Open Government Platform

48. O&M Operations and Maintenance

49. OWASP Open Web Application Security Project

50. PBG Performance Bank Guarantee

51. PLR Prime Lending Rate

52. PoA Power of Attorney

53. Pr. CCA Principal Controller of Communication Accounts

54. PSU Public Sector Undertaking

55. QCBS Quality cum Cost Based Selection

56. REST Representational State Transfer


Page 7 of 182

57. RFP Request for Proposal

58. RMS Revenue Management System

59. RPO Recovery Point Objective

60. RTO Recovery Time Objective

61. SDLC Software Development Life Cycle

62. SDS Software Design Specifications

63. SI System Integrator

64. SLA Service Level Agreement

65. SOAP Simple Object Access Protocol

66. SRS Software Requirement Specifications

67. SSL Secure Socket Layer

68. SUC Spectrum Usage Charge

69. TLS Transport Layer Security

70. TSP Telecom Service Provider

71. UAT User Acceptance Testing

72. WPF Wireless Planning Finance

73. XINS XML Interface for Network Services


Page 8 of 182

Invitation of e-Bids and Notice Inviting e-Bids (NIB)

1. Department of Telecommunications, Government of India invites electronic bid (e-Bid)

proposals from reputed, competent and professional Information Technology (IT) Firms, who

meet the minimum eligibility criteria and successfully qualifies on technical evaluation

parameters as specified in this RFP document, for the Design, Development, Implementation

and Maintenance of Revenue Management System.

2. A “single stage - two envelope” procedure shall be adopted for the selection of a SI. A bidder

would be selected on the basis of QCBS method wherein a bidder with highest composite

score would be selected for the implementation of the project.

3. Bidder (authorised signatory) shall submit their proposal/ bid online in electronic formats

both for technical and financial proposal. However, Demand Draft (DD) for RFP document

fees and Earnest Money Deposit (EMD) should be submitted physically at the office of RFP

Issuing Authority as prescribed in this NIB and scanned copy of same should also be uploaded

along with the technical bid.

4. DoT will not be responsible for delay in online submission due to any reason. For this, bidders

are requested to upload the complete bid well in advance so as to avoid 11th hour issues like

slow speed; choking of web site due to heavy load or any other unforeseen problems.

5. Please note that a Pre-Bid meeting of the prospective bidders, who have purchased the

tender/ bidding document, is scheduled as per the details specified in this NIB. The objective

of this meeting is to address the queries of the prospective bidders related to the Project and/

or tender/ bidding document.

6. No contractual obligation whatsoever shall arise from the RFP/ bidding process unless and

until a formal contract is signed and executed between the DoT and the SI.

7. Bidders who wish to participate in this bidding process must register on DoT’s e-tender portal

i.e. https://eprocure.gov.in.

https://eprocure.gov.in./


Page 9 of 182

Notice Inviting e-Bids (NIB)

RFP Reference No.: 1-6/2004/LF II/Vol III Date: 27 March 2018 Department of Telecommunications, Government of India invites electronic bids (e-bids)/ proposals from eligible bidders for Selection of System Integrator for Design, Development, Implementation and Maintenance of Revenue Management System.

Department of Telecommunications Ministry of Communications, Government of India Sanchar Bhawan, 20 Ashoka Road, New Delhi – 110001 Phone No.: 011-23372193 Mob. No.: +91 9868135825

e-Mail: [email protected]

Request for Proposal for Selection of Systems Integrator (SI) for the Design, Development, Implementation and Maintenance of Revenue Management System for Department of

Telecommunications

RFP Document Fee INR 10,000/- (INR Ten Thousand Only) payable through Demand Draft

Earnest Money Deposit (EMD)* INR 20 Lakhs (Rupees Twenty Lakh Only) payable through Demand Draft/ Bank Guarantee

Date of Publishing the NIB 27/Mar/2018

Last date of submission of Pre-Bid queries

09/Apr/2018, 14:00 Hrs (Email to [email protected] and [email protected] )

Date, Time and Venue of Pre-bid Meeting

11/Apr/2018, 15:00 Hrs Venue: Department of Telecommunications

e-Bid Submission Start Date and Time 17/Apr/2018, 09:00 Hrs

e-Bid Submission End Date and Time 02/May/2018, 15:00 Hrs

Date, Time and Address for Submission of RFP Document Fee and EMD

From 17/Apr/2018, 09:00 Hrs to 02/May/2018, 15:00 Hrs Address: Department of Telecommunications

Technical Bid Opening Date and Time 03/May/2018, 15:00 Hrs

Financial bid Opening Date and Time To be communicated to the technically qualified bidders at the later stage.

Websites for downloading the RFP Document, Corrigendum’s, Addendums etc.

Interested SI may download the RFP Document from: https://eprocure.gov.in and http://dot.gov.in However in this case, the DD needs to be submitted along with the e-bid, failing which the e-bid would be summarily rejected.



https://eprocure.gov.in/

http://dot.gov.in/


Page 10 of 182

Or may collect from: Ankit Anand Director – Licensing Finance Assessment Department of Telecom Sanchar Bhawan, 20 Ashoka Road, New Delhi – 110001 By paying RFP Document Fee of INR 10,000/- payable through Demand Draft.

Contact person name and contact details

Name: Ankit Anand Address: Room No.: 708 Sanchar Bhawan, 20 Ashoka Road, New Delhi – 110001 e-Mail Id: [email protected] Phone No.: 011-23372193 Mobile: +91 9868135825

Bid Validity 180 Days from the bid submission end date

* In case, a bidder fails to physically submit the Demand Draft for RFP Document Fee and EMD up to 02/May/2018, 15:00 Hrs, the Bid of the bidder shall be rejected. The Demand Draft should be drawn in favour of ”Pay and Accounts Officer, DoT (HQ)” payable at “New Delhi” from the Scheduled Bank.


Page 11 of 182

1.0 Introduction

1.1 Overview

The telecom services have been recognized the world-over as an important tool for socio

economic development for a nation and hence telecom infrastructure is treated as a crucial factor

to realize the socio-economic objectives in India. Accordingly, the Department of Telecom has

been formulating developmental policies for the accelerated growth of the telecommunication

services. The Department is also responsible for grant of licenses for various telecom services like

Unified Access Service Internet and VSAT service. The Department is also responsible for

frequency management in the field of radio communication in close coordination with the

international bodies. It also enforces wireless regulatory measures by monitoring wireless

transmission of all users in the country.

1.2 Key functions of DoT

1. Policy, Licensing and Coordination matters relating to telegraphs, telephones, wireless, data,

facsimile and telematics services and other like forms of communications.

2. International cooperation in matters connected with telecommunications including matters

relating to all international bodies dealing with telecommunications such as International

Telecommunication Union (ITU), its Radio Regulation Board (RRB), Radio Communication

Sector (ITU-R), Telecommunication Standardization Sector (ITU-T), Development Sector (ITU-

D), International Telecommunication Satellite Organization (INTELSAT), International Mobile

Satellite Organization (INMARSAT), Asia Pacific Telecommunication (APT).

3. Promotion of standardization, research and development in telecommunications.

4. Promotion of private investment in Telecommunications.

5. Financial assistance for the furtherance of research and study in telecommunications

technology and for building up adequately trained manpower for telecom program, including:

a. Assistance to institutions, assistance to scientific institutions and to universities for

advanced scientific study and research; and

b. Grant of scholarships to students in educational institutions and other forms of

financial aid to individuals including those going abroad for studies in the field of

telecommunications.


Page 12 of 182

6. Procurement of stores and equipment required by the Department of Telecommunications.

7. Telecom Commission.

8. Telecom Regulatory Authority of India.

9. Telecom Disputes Settlement and Appellate Tribunal.

10. Administration of laws with respect to any of the matters specified in this list, namely:-

a. The Indian Telegraph Act, 1885 (13 of 1885);

b. The Indian Wireless Telegraphy Act, 1933 (17 of 1933); and

c. The Telecom Regulatory Authority of India Act, 1997 (24 of 1997).

11. Indian Telephone Industries Limited.

12. Post disinvestment matters relating to M/s Hindustan Teleprinters Limited.

13. Bharat Sanchar Nigam Limited.

14. Mahanagar Telephone Nigam Limited.

15. Videsh Sanchar Nigam Limited and Telecommunications Consultants (India) Limited.

16. All matters relating to Centre for Development of Telematics (C-DOT).

17. Residual work relating to the erstwhile Department of Telecom Services and Department of

Telecom Operations, including matters relating to-

a. Cadre control functions of Group 'A' and other categories of personnel till their

absorption in Bharat Sanchar Nigam Limited;

b. Administration and payment of terminal benefits.

18. Execution of works, purchase and acquisition of land debitable to the capital Budget

pertaining to telecommunications.

1.3 Organizational Structure and DoT’s Regional Offices

The department has 26 offices spread across the country from where the assessments and other

important activities are carried out. Each and every activity including assessment follows a well-

established processes. The organizational structure of DoT is as following:


Page 13 of 182

1.4 Overview of DoT’s Requirement

DoT has envisaged an IT platform as a tool to address the identified gaps in service delivery,

information dissemination, communication and coordination with various stakeholders and

enhance overall operational efficiency of the department. Department plans to implement the

RMS as a centralized application to be accessed by all the DoT users (bureaucrats, officials, staff)

including various circles and TSPs across the country. The DoT through proposed RMS aims to

implement a system that receives inputs; computes, shares and stores data; and automatically

generates required information along with various MIS reports in the prescribed formats for the

use of various users.

The department currently has an application which is use by the departmental users to perform

their day to day functions. But the existing application has limited features to cater the current

requirements of DoT. Therefore, DoT is now looking forward to build a new system which would


Page 14 of 182

replace the existing one to enhance the IT & ITeS capabilities of the department. The upcoming

centralized Revenue Management System will be more robust, secure, easy to use and easily

scalable/ configurable to meet the new or changing requirements of the department.

Department intends to bring in complete computerization and automation of all the functions

across the life-cycle of revenue management from assessment–to-grievances with the objective

of standardizing processes, improving customer service for TSP, ISP & others and enhancing

compliance across the processes. Through this exercise the department also intends to enhance

delivery efficiency of the division resulting in the increase in overall revenue collection for the

Government and improved user experience (UX) for the Telecom operators. At the same time

the division is also looking forward to bring in complete transparency and governance across all

the processes and branches across the country.

1.5 Key Process in RMS

Revenue Management System will be used by DoT for handling Collection, Recovery and

Assessment of License Fees administering Bank Guarantees and other relevant financial

conditions of all the Licenses and Spectrum issued by DoT to the Telecom Service Providers (TSP).

The end-users of the existing system can have Read only, Read Insert, Read Delete, Read Update

or Full access to these modules depending upon the access rights given to the user/user group.

The existing system has following modules:

1. Login and Change Password

2. Toolbar

3. General Directory Information (GDI)

4. License Information (LI)

5. AGR Statement (AS)

6. Bank Guarantee Administration (BG)

7. Assessment And Interest Calculation (AS)

8. Payment Collection (PC)

9. User Administration (UA)

10. Reports

11. BHARATKOSH

12. CAF/EMR Penalty

The upcoming system will computerize all the processes and facilitate the users to enter and

manage data online. DoT has envisages the futuristic Revenue Management System into 15


Page 15 of 182

modules including several sub-modules. The envisaged modules in the Application System are as

follows:

1. Setting-up of TSP

2. Setting-up of Master Table and Data

3. Administration

4. Bank Guarantee Submission

5. Spectrum Usage Charge Assessment

6. License Fee Assessment

7. Deduction Verification Report Preparation

8. Court Case

9. MIS

10. Dashboard

11. Knowledge Bank

12. Discussion Board

13. Grievance

14. Customer Acquisition Form/ Electromagnetic Field Radiation

15. Budget

Detailed use cases for each module are mentioned in subsequent chapters of this volume of the

RFP.


Page 16 of 182

2.0 DoT Key Stakeholders

Sr. No. Stakeholder Short Description

1. 1 LFP • Policy related matters of Unified License, Unified Access Service

License, INSAT MSS-R Licenses, ISP "A","B" and "C" category

Licenses, Radio-paging. VSAT (captive as well a commercial),

NLD, ILD and IP-ii services.

• Policy matters on Tripartite Agreements (TPA).

• Scrutiny of application for grant of Access services, carrier

services, and data services licenses.

• Approval for grant of access services licenses, carrier services

licenses, data services licenses.

• Policy matter on Merger & Acquisition, CAF and EMF

verification, Financial Bank Guarantees and Performance Bank

Guarantees.

• Handling of court cases on Revenue Matters in TDSAT, Hon'ble

Supreme court and in different High Courts.

• Reply on Joint Parliamentary Committee, Public Account

committee matters and audit coordination related to Policy

Wing.

• TC Memo and arbitration cases.

• VIP references and parliamentary question.

• Monitoring of decentralized licenses which includes Monitoring

of Assessment and Monitoring of bank Guarantees.

• Discharging the duty of Appellate Authority for assessment

done by CCA's.

2. 2 LFA • Review if DVR reports.

• Annual Assessment of License Fees paid by the Telecom Operators

based on the Audited AGRs including watch on receipt of DV reports.

• Review of payments and outstanding.

• Calculation of penal interest on delayed payments & recovery of the

same.

• Refund/ adjustment of license fee excess paid.

• Speaking order on Representation by Licensees on Annual

Assessment.


Page 17 of 182

• Clarifications/ guidelines on verification reports of deduction claims.

• Checking of affidavit etc. at the time of recovery of quarterly revenue

share/ License Fees.

• Annual Financial settlement of revenue share/ L.F.

• Safe custody of Performance Bank Guarantee.

• Review of Performance Bank Guarantees, issue of letters of extension

of BGs before the expiry of its validity period and invocation in case

of non-extension and enhancement of BG amount. Disposal of

Appeal/ Representation received from TSPs regarding BGs.

• Issue of instructions/ guidelines in connection with Financial Bank

Guarantees.

• Data compilation, preparation and submission of Telecom

Commission Memo.

• Reconciliation of LF collections.

• Monitoring of LF Collections, GR/ AGR figures and trend analysis

under clause 19.1 and 19.2 of LA.

• Providing inputs for quarterly Return of Financial Advisor's (FA)

report for Department of Expenditure, Ministry of Finance.

• Furnishing Report on Standing Committee on Finance matters/ other

Parliament Committees.

• Furnishing Data for Finance Commission.

• Review of receipts from various penalties levied by other wings of

DoT/ Field Units.

• Correspondence regarding various penalties imposed by other wings

of DoT/ Field Units.

• Vetting of calculation of penalty in respect of Roll out obligations.

• Vetting of Assessment of License Fee/ calculation of interest details

etc. received from AS Section and from other Licensing Branch.

• Audit of the Telecom Licensees under clause 22.5 of the License

Agreement.

• Special audit of Telecom Licensees under Clause 22.6.

• Interaction with Banking Authorities/ RCA/ Income Tax/ Service Tax

authorities.

3. 3 WPF WPF user are looking after

1. Monitoring of SUC assessment and collection 2. Spectrum Auction 3. Bank Guarantees under NIA 4. Policies related to above


Page 18 of 182

This wing is presently performing several important functions, which can be broadly divided into two branches

i) Wireless Finance (WF) ii) Wireless Revenue (WR)

WF:

i) Financial scrutiny of various expenditure and budget proposals concerning the WPC and WMO, including the World Bank project.

ii) Spectrum Auction iii) Policies related to spectrum auction iv) Other miscellaneous function

WR

i) Monitoring and collection of Spectrum Charges of basic, cellular and UASL licensees in respect of their GSM, CDMA, 3G and BWA services.

ii) Policies related to above iii) Other miscellaneous function

4. 4 CCA There are 26 CCA offices across the country. As a field unit of DoT,

CCA offices are responsible for realization of License fee and

Spectrum usage charges. It also verifies the claim of deduction by

the service providers and AGR verifications for the decentralized

licenses.

Following are the Revenue Functions of CCA offices:

i. License Fee collection: The CCA office is responsible for

collection of license fee from all commercial licensees of

cellular, basic, Unified Access Service, NLD, ILD, Commercial

VSAT, PMRTS services, Internet Services Providers (without

telephony), Internet Service Providers (with telephony),

captive VSAT, CMRTS, Radio links, Microwave links and OFC

links. The license fee collected is a sizeable component of the

non-tax revenue for the government.

ii. Verification of Deductions: As per the license agreements,

licensees can claim deductions (on account of pass-thru

charges, roaming service charges, government taxes) from


Page 19 of 182

their gross revenues’ to arrive at ‘adjusted gross revenue’

before calculating the license fee payable. To ensure that the

deductions claimed by the licensees are correct and not

excess, the CCA has been assigned the task of verifying the

deductions on quarterly basis.

iii. Spectrum Charges: The work of collection of quarterly

Spectrum Charges from the Telecom Service Providers as

well the assessment of Spectrum charges is also being

carried out by the CCA offices.

iv. Bank Guarantee: Maintenance of performance and Financial

Bank Guarantees of and ensure encashment for nonrenewal

and non- fulfilment of terms and conditions of respective

License Agreement.

5. 5 Pr. CCA Pr. CCA office is headed by the Principal Controller of

Communications Accounts, with sanctioned strength of one or

multiple CCA(s), joint CCAs and/or Dy. CCA(s). Pr. CCA is the

monitoring authority for multiple CCA offices.

6. 6 TSP A Telecommunications Service Provider (TSP) is a type

of communications service provider that has traditionally

provided telephone and similar services. This category

includes incumbent local exchange carriers, competitive local

exchange carriers, and mobile wireless communication companies,

Internet Service Providers, Satellite Services Provider, Radio

Trunking Service Providers etc.

https://en.wikipedia.org/wiki/Communications_service_provider

https://en.wikipedia.org/wiki/Telephone

https://en.wikipedia.org/wiki/Competitive_local_exchange_carrier

https://en.wikipedia.org/wiki/Competitive_local_exchange_carrier

https://en.wikipedia.org/wiki/Mobile_wireless_communication


Page 20 of 182

3.0 Functional Requirement Specifications

The functional requirement specifications stated below are the indicative features which RMS

should have. The SI shall develop the final detailed System Requirement Specifications (SRS) and

System Design Specifications (SDS) documents after a detailed study under which this FRS, TRS

along with all the departmental processes, procedures and existing templates/ designs should be

studied in detail by the SI. SI should independently design the solution which should be based on

its own independent study and as may be required to support the department’s operations. The

SI shall be required to coordinate with DoT and other stakeholders of the project for the detailed

system study and for the preparation of SRS and SDS documents. The SRS document may have

all or some of the features mentioned in this indicative FRS.

3.1 Introduction

The proposed Revenue Management system shall comprise of Application Home page (consist of

basic menu and features), 15 major modules which are further sub-divided into multiple sub-

modules. Functional requirements of the all 15 modules have been chalked out during the To-Be

study which covers the entire scope of the project, these functional requirements may further

amend during the SRS phase:


Page 21 of 182

Bank Guarantee

Performance Bank Guarantee (for LF only)

Financial Bank Guarantee

LF Assessment

LF Calculation from GR and DVR

Two stages of payment

One stage of demand notice

DVR

AO,AG,PP,IR forms submission

Provisional DVR

Final DVR

Court Case

Linking of Demand order with Court name and Case number

Setting up of TSP

Master data of TSP i.e. users, Licenses information, service area, bandwidth

Administration

Manage user User groups

Dashboard

Different type of Dashboards

MIS

Different type of reports

Setting up of Master Data

License information, rates of License fee, Service areas, Bandwidth & cap, SUC rates, CCAs, PLR/MCLR rates, Principle CCAs, Bank details, Spectrum bid amount

CAF/EMR

Notice of term cellPayment for TSPs

Grievance

Queries from TSPs Resolution by

DoT/CCA

Knowledge Bank

Public orders Private orders

Discussion Board

Public Discussion (including TSP)

Private discussion(Govt. users)

Transaction data

SUC

DVRDemand order

License fee

Process Map – Revenue Management System

Demand order

Transaction data flow

Master data flow

Final SUC from LF AGR

Two stages of payment

Two stage of demand notice

SUC Assessment Finalized AGR

Budget

LF SUC

MIS data

Figure 1: High level process map of proposed system


Page 22 of 182

3.2 Module Wise Detailed Functional Requirements of the Proposed System

3.2.1 Setting-up of TSP

One of the major stakeholder of the proposed revenue management system is Telecom Service Providers (TSPs). This module will be used to setup the TSP (Telecom Service Provider) in the system. A designated user within Department (DoT) will setup/create the TSP in the system with their authorization (License) details. The process shall involve creation of user credential for a TSP. TSP will then use these credentials for creating other users for each type of authorization. TSP shall create at least two user (who will perform the work as Maker and Checker user) for each type of authorization. TSP will also be able to use this module to view all the exceptions (time extensions) he had asked for along with the status of the same. The sub-modules under setting up of TSP modules are shown in the table below:

SUB MODULES IN SETTING OF TSP MODULE Module Sub-Module Sub Sub-Module Users

Setting up of TSP Setting up of TSP DoT User (LFP)

Manage TSP DoT User (LFP)

Creating TSP Users TSP

My Profile Manage Profile TSP

My Spectrum Holding TSP

Exception History TSP


Page 23 of 182

Figure 2: Process flow for Setting up of TSP

Setting up of TSPD

oT

Ma

ster

U

ser

AS/

CS/

DS

(Do

T)

TSP

Start

Collect the License Information

Create the TSP Company User

Share the TSP Company user

credential

User credential recieved

Create user credential for each license/authorization.

Minimum 2 user maker and checker

End

Manage My Profile


Page 24 of 182

Setting up of TSP

Module Setting up of TSP

Sub Module Setting up of TSP

Use Case No. 3.2.1.1

Introduction This will be used by DoT user (LFP) for setting up the TSP user in the system post issuing the Licenses to TSP.

Preconditions DoT user (LFP) should be registered in the system.

License has already been issued to the TSP.

Actor Involved DoT user (LFP)

Process Flow 1. User will login into the system with his/her login credentials upon login user will be landed at the dashboard page by default.

2. User (LFP) will now click on the Setting up of TSP module. 3. User (LFP) will fill the inputs boxes for TSP Name, CIN, Registered Address, email

I’d, Phone number, License Start date, License Expiry date, Authorization and Service Area, Bandwidth Allocation and order for allocation.

4. User (LFP) will click on “register TSP” with all the submitted information.

Data Fields Selection Criteria o TSP Name o CIN o Registered Address o Registered email I’d o Phone number o License Start date o License Expiry date o Authorization and Service Area o Allocation detail band wise, circle wise, year wise, bid price, deferred

payment detail o Spectrum Type o Spectrum Technology o Order upload o Assessing office(CCA)

Exceptions

References Document

Post Conditions Post registering the TSP, an email notification will be sent to the registered email address along with username and password.

An acknowledgement email for registering the TSP will be sent to DoT Admin User.

Manage TSP


Page 25 of 182


Sub Module Manage TSP


Introduction This will be used by DoT user (LFP) for managing the TSP user in the system for updating the existing information and to resetting the password.


TSP should already be registered in the system.



2. User (LFP) will now click on the Setting up of TSP->Manage TSP. 3. User (LFP) can modify the inputs boxes for TSP Name, Registered Address, email

I’d, Phone number, License Start date, License Expiry date, Authorization and Service Area.

4. User (LFP) can click on “Password Reset”, if asked by TSP 5. User (LFP) will click on “update TSP information” with all the submitted

information.

Data Fields Input Criteria o TSP Name o Registered Address o Registered email I’d o Phone number o License Start date o License Expiry date o Assessing office o Authorization and Service Area

Exceptions In case of any update in TSP detail, history will be available in the system to view.

References Document

Post Conditions Post updating TSP information, an email notification will be sent to the registered email address.

In case of password reset, new default password will also be sent to the TSPs registered e-mail.

An Acknowledgement email for registering the TSP will be sent to DoT Admin User.

Creating TSP Users


Sub Module Creating TSP Users



Page 26 of 182

Introduction This will be used by TSP user (Headquarter) to create TSP user (multiple users)

Preconditions TSP should already be registered in the system and having credentials for the system.

Actor Involved TSP User


2. User will now click on the Setting up of TSP->Creating TSP Users. 3. User will be able to create the users with inputs boxes for TSP User (user level),

User’s name, email I’d, Phone number, Service area, Authorization. 4. User will create the user against the license/authorization. 5. After filling these information TSP User can click on “create user”. 6. User can also click on “Password Reset”, if asked by TSP Maker user or TSP

Checker user.

Data Fields Selection Criteria o TSP Maker/Checker User

Data Fields o User’s name o email I’d o Phone number o Service area o Authorization

Exceptions

References Document

Post Conditions Post creating TSP user, an email notification will be sent to the email address.

In case of password reset, new default password will also be sent the email I’d.

An Acknowledgement email for registering the TSP user will be sent to the registered email of TSP.

My Profile o Manage Profile

Module My Profile

Sub Module Manage Profile


Introduction This will be used by TSP user for updating selected TSP information including “change password”.

Preconditions TSP should already be registered in the system.

TSP user should be registered in the system.

TSP user should be logged in to the system.

Actor Involved TSP user



Page 27 of 182

2. User will now click on the My Profile. 3. User can modify the inputs boxes for Name, email I’d, Phone number and

Password. 4. User will click on “update information” with all the updated information.

Data Fields Selection Criteria o Name o email I’d o Phone number o Password

Exceptions

References Document

Post Conditions Post updating TSP information, an email notification will be sent to the registered email address.

o My Spectrum Holding

Module My Profile

Sub Module My Spectrum Holding


Introduction This will be used by TSP (headquarter/license) user to view the Spectrum holding and making the deferred payment linked with Spectrum Allocation

Preconditions TSP user should be registered in the system.

TSP must hold the spectrum



2. User will now click on the My Spectrum Holding. 3. User will view the list of spectrum allocation with year, bandwidth, allocation,

Bid Amount, Minimum Bid Amount, Remaining Deferred payment (if any). 4. User can make the remaining deferred payment. User can edit the payment

amount. 5. Payment will done through Bharatkosh Payment Gateway. 6. After Successful payment Amount of remaining deferred payment will update.

Data Fields

Exceptions

References Document

Post Conditions Post Payment of deferred payment, Remaining amount will update.

o Exceptions History


Page 28 of 182

Module My Profile

Sub Module Exception History


Introduction This will be used by TSP user to view the Exception history.

Preconditions TSP user should be registered in the system. Exception has been raised by TSP

Actor Involved TSP


2. User will now click on the My Profile> Exception History. 3. On this page all the Exceptions till date will get displayed which are initiated

by TSP. 4. User can select any exception to view the detail and action performed.

Data Fields

Exceptions

References Document

Post Conditions


Page 29 of 182

3.2.2 Setting-up of Master Table and Master Data

The revenue management system will have data elements which will be used commonly across

multiple modules/sub-modules. DoT would like to maintain such data elements/fields in the form

of master data in the RMS. This module will have two major sub-modules – setting up of master

table and setting up of master data. Setting up of master table module will be used to create,

alter and delete a new or existing master tables, while setting up of master data module will be

use to add and manage (edit and deactivate) master table.

Access to this module shall be limited to DoT Admin user only. DoT admin user will use this

module to setup the Master table and master data in the system. Master data will be used by all

the modules to perform their respective activities. The list of master data identified to be

captured using this module shall include (but not limited to):

All license information

Service areas

Bandwidth and caps

SUC rate

PLR/MCLR rate

Principle CCA & CCA information

Bank details

Spectrum bid amounts

Master Data

Master Table

The sub-modules under setting up of Master Tables and Master Data are shown in the table below:

Module Sub-Module Sub Sub-Module Users

Setting up of Master data

Master Table Create Master Table DoT Admin User

Alter Master Table DoT Admin User

Drop Master Table DoT Admin User

Master Data Create Master Data DoT Admin User

Manage Master Data DoT Admin User

Manage Licenses Add License DoT Admin User

Manage License DoT Admin User

Manage License Fee rate

Add LF rate DoT Admin User

Manage LF rate DoT Admin User

Manage Service Area Add Service area DoT Admin User

Manager Service Area DoT Admin User

Manage Bandwidth and Cap

DoT Admin User


Page 30 of 182

Manage SUC rate Add SUC rate DoT Admin User

Manage SUC rate DoT Admin User

Manage CCA Add CCA DoT Admin User

Manage CCA DoT Admin User

Manage PLR/ MCLR rate

DoT Admin User

Manage Principle CCA Add Pr. CCA DoT Admin User

Manage Pr. CCA DoT Admin User

Manage Bank DoT Admin User

Manage Spectrum Bid Amount

DoT Admin User


Page 31 of 182

Master Data

DoT

Mas

ter

Use

r

Start Add Master data

Manage Master data

End

Create Master Table

Alter Master Table

Drop Master Table

Figure 3: Process flow for Setting-up of Master Data


Page 32 of 182

Manage Master Table o Create Master Table

Module Master Table

Sub Module Create Master Table


Introduction This sub module will be used by DoT admin user to Create Master Table.

Preconditions DoT admin user should be registered in the system.

Actor Involved DoT admin User

Process Flow 1. User will login into the system with his/her login credentials upon login the User will be directed on the dashboard page.

2. User will now click on the Master Table> Create Master Table sub module 3. User will be able to create master table in the system. 4. User will add the table name, columns and select data type of column

Data Fields Name

Column Name

Data type

Exceptions Data to be entered should be in the correct format for all the fields else pop-up message “Please enter the details in correct format” will be displayed.

References Document

Post Conditions Master table will be created in the database for further use.

o Alter Table

Module Master Table

Sub Module Alter Master Table


Introduction This sub module will be used by DoT Admin user to alter the created table.


Master table should be available (already created) in the system.

Actor Involved DoT Admin User


2. User will now click on the master Table> Alter Table sub module 3. Here list of all the master table with name will display. 4. User will be able to search the master table. 5. User will select master table to alter. 6. User will be able to update the datatype of any column if data is not

available in the column. 7. User will be able inactive any column. 8. User will be able to add new column in the table

Data Fields Name

Column Name


Page 33 of 182

Datatype

New Data type

Add new column

Exceptions Data to be entered should be in the correct format for all the fields else pop-up message “Please enter the details in correct format” will be displayed. System will not allow user to alter is the table is already in use.

References Document

Post Conditions User will be able to make necessary changes to the table structure/schema.

o Drop Table

Module Master Table

Sub Module Drop Table


Introduction This sub module will be used by DoT admin user to drop the master table.


Master table should be available (already created) in the system.



2. User will now click on the master Table> Drop Table sub module 3. Here list of all the master table with name will display. 4. User will be able to search the master table. 5. User will select master table to drop.

Data Fields Drop

Exceptions Master Table should not be in use by any functions. In case if it is in use the system must through exception.

References Document

Post Conditions Drop table will delete permanently from the database.

Manage Master Data o Create Master Data

Module Master Data

Sub Module Create Master Data


Introduction This sub module will be used by DoT admin user to create master data.


Master table should be available in the system.


Process Flow 1. User will login into the system with his/her login credentials upon login the user will be directed on the dashboard page.


Page 34 of 182

2. User will now click on the Master Data> Create Master Data sub module 3. Here list of all the master table with name will display. 4. User will be able to search the master table. 5. User will select master table to create master data. 6. User will be able to add the master data in the table.

Data Fields Table Name

Form Fields


References Document

Post Conditions Master data will get populated in the master tables for further usage.

o Edit Master Data

Module Master Data

Sub Module Edit/Append Master data


Introduction This sub module will be used by DoT Admin User to edit the data present in the master tables.


Master table and data should be available in the system.


Process Flow 1. Admin User will login into the system with his/her login credentials upon login the user will be directed on the dashboard page.

2. User will now click on the Master Data> Edit Master Data sub module 3. Here list of all the master table with name will display. 4. User will be able to select the master table whose data the user want to

edit. 5. User will select master table. 6. User will be able to view the data present in the system. 7. User will click/select on the data which the user want to edit. Upon clicking

the data will be available in edit mode. User will make necessary changes and save the data.

8. User will be able to activate inactive data also using this feature.

Data Fields Table Name

Form Fields

Data


References Document

Post Conditions Master data present inside the master table will get updated and will be available for further use.


Page 35 of 182

License o Add license

Module License

Sub Module Add License


Introduction This sub module will be used by DoT Admin User to add new License.

Preconditions DoT Admin User should be registered in the system.



2. User will now click on the License> Add License sub module 3. User will be able to add new license in the system. 4. User fill the values in the textboxes provided in the form 5. User submit the data and license is available for further usage.

Data Fields License ID (Auto generated)

License Name

License Start date

Category (like UL or UL VNO)

Order (upload function)


References Document

Post Conditions Submitted license is available for further usage.

o Manage License

Module License

Sub Module Manage License


Introduction This sub module will be used by DoT Admin User to manage the master data of Licenses.




2. User will now click on the License> Manage License sub module 3. Here list of all the license will display. 4. User will be able to search any license 5. User will be able to edit the information of any license. 6. User can mark any license as inactive with inactive date and order. 7. User cannot delete any license.

Data Fields License ID (Auto generated)


Page 36 of 182

License Name

License Start date

Category (like UL or UL VNO)



References Document

Post Conditions Submitted license is available for further usage.

License Fee Rate o Add LF rate

Module License Fee Rate

Sub Module Add License Fee Rate


Introduction This sub module will be used by DoT Admin User to Add License Fee rate.




2. User will now click on the License Fee Rate> Add LF Rate sub module 3. User will be able to add license fee in the system for each year. 4. User select the year, circle, service and enter the license fee rate.

Data Fields Year

Circle

Service

Rate



References Document

Post Conditions Submitted license fee rate is available for further usage.

o Manage LF Rate

Module License Fee Rate

Sub Module Manage License Fee Rate


Introduction This sub module will be used by DoT Admin User to Manage License Fee rate.




Page 37 of 182


2. User will now click on the License Fee Rate> Manage LF Rate sub module 3. Here list of all the LF rate with year, circle and service will display. 4. User will be able to search the data based on year/circle/service. 5. User will be able to edit the LF rate for any circle/year/service.

Data Fields Year

Circle

Service

Rate



References Document

Post Conditions Submitted license fee rate is available for further usage.

Manage Service Area o Add Service Area

Module Service Area

Sub Module Add Service Area


Introduction This sub module will be used by DoT Admin User to Manage Service Area.




2. User will now click on the Service Area > Add Service Area sub module. 3. User will be able to add Service Area in the system with name, effective date

and order.

Data Fields Service Area name

Effective date



References Document

Post Conditions Added service area is available for further usage.

o Manage Service Area

Module Service Area

Sub Module Manage Service Area


Page 38 of 182


Introduction This sub module will be used by DoT Admin User to manage the master data of Service Area.




2. User will now click on the Service Area> Manage service Area sub module 3. Here list of all the service area will display. 4. User will be able to edit the service area detail. 5. User cannot delete service area.

Data Fields Service Area name

Effective date



References Document

Post Conditions Edited Service Area Name is available for further usage.

Manage Bandwidth and cap

Module Manage Bandwidth and cap

Sub Module


Introduction This sub module will be used by DoT Admin User to Manage bandwidth and cap for each bandwidth.




2. User will now click on the Manage Bandwidth and cap module 3. User will be able to add bandwidth in the system with cap, effective date and

order.

Data Fields Bandwidth

Cap

Effective date



References Document

Post Conditions Added bandwidth and cap is available for further usage.


Page 39 of 182

Manage SUC Rate o Add SUC Rate

Module SUC Rate

Sub Module Add SUC Rate


Introduction This sub module will be used by DoT Admin User to Add SUC Rate.




2. User will now click on the SUC Rate> Add SUC Rate sub module 3. User will be able to add SUC rate in the system. 4. User add the SUC rate with bandwidth, slab and year


Year

Slab

Rate

Service

Service Area

Order (Upload Function)


References Document

Post Conditions Added SUC rate is available for further usage.

o Manage SUC Rate

Module SUC Rate

Sub Module Manage SUC Rate


Introduction This sub module will be used by DoT Admin Use to manage the SUC rate.




2. User will now click on the SUC Rate> Manage SUC Rate sub module 3. Here list of all the SUC rate with year, circle, slab and service will display. 4. User will be able to search the data based on year/circle/service. 5. User will be able to edit the SUC rate for any circle/year/service/slab.


Year

Slab


Page 40 of 182

Rate

Service

Service Area

Order (Upload Function)


References Document

Post Conditions Edited SUC rate is available for further usage.

Manage CCA o Add CCA

Module CCA

Sub Module Add CCA


Introduction This sub module will be used by DoT Admin User to Add CCA detail in the system.

Preconditions DoT Admin Use should be registered in the system.



2. User will now click on the CCA> Add CCA sub module 3. User will be able to add CCA in the system with name, email, effective date

and order.

Data Fields CCA name

Email

Effective date



References Document

Post Conditions Added CCA is available for further usage.

o Manage CCA

Module CCA

Sub Module Manage CCA


Introduction This sub module will be used by DoT Admin User to manage the master data of CCA.




Page 41 of 182


2. User will now click on the CCA> Manage CCA sub module 3. Here list of all the CCA will display. 4. User will be able to edit the CCA detail. 5. User cannot delete CCA. CCA can be inactive by the user with date and order.

Data Fields CCA name

Email

Effective date



References Document

Post Conditions Edited CCA is available for further usage.

Manage PLR/MCLR Rate

Module Manage PLR/MCLR Rate

Sub Module


Introduction This sub module will be used by DoT Admin User to Manage PLR/MCLR rate.




2. User will now click on the Manage PLR/MCLR rate 3. User need to enter PLR/MCLR for each year.

Data Fields PLR/MCLR rate

Year


References Document

Post Conditions Added PLR/MCLR rate is available for further usage

Manage Principle CCA o Add Pr. CCA

Module Principle CCA

Sub Module Add Pr. CCA


Introduction This sub module will be used by DoT Admin User to Add Pr. CCA detail in the system.


Page 42 of 182




2. User will now click on the Principle CCA> Add Pr. CCA sub module. 3. User will be able to add CCA in the system with Pr. CCA Name, Email, CCA

covered, effective date and order.

Data Fields Pr. CCA name

Email

CCA covered

Effective date



References Document

Post Conditions Added Pr. CCA is available for further usage.

o Manage Pr. CCA

Module Principle CCA

Sub Module Manage Pr. CCA


Introduction This sub module will be used by DoT Admin User to manage the principle CCA detail.




2. User will now click on the Principle CCA> Manage Pr. CCA sub module 3. Here list of all the Pr. CCA will display. 4. User will be able to edit the Pr. CCA detail. 5. User cannot delete Pr. CCA. 6. User can inactive the Pr. CCA with order and date.

Data Fields Pr. CCA name

Email

CCA covered

Effective date



References Document

Post Conditions Edited Pr. CCA is available for further usage.


Page 43 of 182

Manage Bank

Module Manage Bank

Sub Module


Introduction This sub module will be used by DoT Admin User to Manage Bank.




2. User will now click on the Manage bank 3. User enter the Bank name in the system.

Data Fields Bank Name


References Document

Post Conditions Added Bank Name is available for further usage.

Manage Spectrum Bid Amount

Module Manage Bid

Sub Module


Introduction This sub module will be used by DoT Admin User to Manage Spectrum Bid Amount.




2. User will now click on the Manage Spectrum bid amount 3. User enter the bid amount of each auction in the system.

Data Fields Year

Circle

Bid Amount

Band


References Document

Post Conditions Added Bid amount detail is available for further usage.


Page 44 of 182

3.2.3 Administration

This module can be accessed only by the DoT admin user. In this module DoT Admin user will

create application users and user groups. Application users are DoT official who shall be accessing

the RMS application, while user groups are different types of roles with selective/controlled

access to each module as identified in the system. Each application user shall be tagged to one

or multiple user group(s). While creating the User groups DoT Admin user will define the access

rights of the User group and associated Users. DoT admin user can update the user group detail

and access rights/control at any time. DoT/CCA user will also be able to view the exception

requests (for time extension) submitted by TSPs for accepting/rejecting and will also be able to

view the exception history.

The sub-modules under administration module are shown in the table below:


Administration Manage user group Add user group DoT Admin User

Manage user group DoT Admin User

Manage user Add user DoT Admin User

Manage user DoT Admin User

My Profile Manage Profile DoT/CCA

Exceptions DoT/CCA

Exception History DoT/CCA


Page 45 of 182

Administration

DoT

Adm

in U

ser

Add User

Start

Add User Group

Manage User

Manage User Group

End

Exceptions

My Profile

Figure 4: process flow for Administration


Page 46 of 182

Manage user group o Add User Group

Module User Group

Sub Module Add Group


Introduction This will be used by DoT Admin to create the user group in the system.

Preconditions DoT Admin user should be registered in the system.

Actor Involved DoT Admin user


2. User will now click on the User Group>Add user group. 3. User will add the new user group in the system with the permission for that

group.

Data Fields User group name

Access rights (selection)


References Document

Post Conditions Added user group is added in the system for further usage.

o Manage user group

Module User Group

Sub Module Manage Group


Introduction This will be used by DoT Admin to manage the user group in the system.




2. User will now click on the User Group>Manage user group. 3. On this page all the user group will display, user can select any user group to

edit the information of user group. 4. User can edit the permission of user group. 5. User can inactive user group. Inactive user group is not available for further

usage.

Data Fields User group name

Access rights (selection) Exceptions Data to be entered should be in the correct format for all the fields else pop-up

message “Please enter the details in correct format” will be displayed.


Page 47 of 182

References Document

Post Conditions Edited user group is added in the system for further usage.

Manage user o Add User

Module User

Sub Module Add User


Introduction This will be used by DoT Admin to create the user in the system.




2. User will now click on the User >Add user. 3. User will add new user in the system with the user detail. 4. User will submit all the details to create the user.

Data Fields First Name

Last Name

Office

Phone

Email

User group (only one)

Exceptions Data to be entered should be in the correct format for all the fields’ else pop-up message “Please enter the details in correct format” will be displayed.

References Document

Post Conditions Added user is available in the system for further usage. An email sent to registered email ID of that user with their username and password.

o Manage user

Module User

Sub Module Manage User


Introduction This will be used by DoT Admin to manage the user in the system.




2. User will now click on the User >Manage user.


Page 48 of 182

3. On this page all the users will display, user can select any user to edit the information of user.

4. User can reset the password of registered user. Reset password button will be there to reset the password. Reset password again sent to registered email ID.

5. User can edit the information of registered user. 6. User can inactive user. Inactive user is not available for further usage.


Last Name

Office

Phone

Email



References Document

Post Conditions Updated user detail is added in the system for further usage.

My Profile o Manage Profile

Module My Profile

Sub Module Manage Profile


Introduction This will be used by DoT/CCA user to manage the profile.

Preconditions DoT/CCA user should be registered in the system.

Actor Involved DoT/CCA


2. User will now click on the User >Add user. 3. User will add new user in the system with the user detail. 4. User will submit all the details to create the user.


Last Name

Office

Phone

Email




Page 49 of 182

References Document

Post Conditions Updated user detail is added in the system.

o Exceptions

Module My Profile

Sub Module Exceptions


Introduction This will be used by DoT/CCA user to manage the exceptions.




2. User will now click on the My Profile> Exception. 3. On this page all the Exceptions will display. User can filter the exception based

on category like time extension request. 4. User can take the action against the exception. Once action has been taken

exception will move to exception history sub module. 5. User can approve/reject the time extension request. 6. Once user approve the time extension request, User need to enter the date

till the time extension has been granted.

Data Fields

Exceptions Other than time extension request, there may be additional exceptions.

References Document

Post Conditions Requested exception will process as per status/action of user.

o Exceptions History

Module My Profile

Sub Module Exception History


Introduction This will be used by DoT/CCA user to view the exceptions.




2. User will now click on the My Profile> Exception History.


Page 50 of 182

3. On this page all the Exceptions till date will display. This list will contain all the exceptions which are already acted upon.

4. User can select any exception to view the detail and action performed.

Data Fields

Exceptions

References Document

Post Conditions


Page 51 of 182

3.2.4 Bank Guarantee Module

This module will keep the record of all types of Bank Guarantees (BG) associated against each of

the authorization for each of the TSP. DoT user can directly put in the details of Bank Guarantees

in the system and upload the scanned copy of the BG in case of first BG received after this all the

renewal and additional BG details will be updated by TSP. CCA will review the information

provided by TSP on the RMS application and shall online update the status of the bank guarantee.

This module will also automatically review the value of Bank Guarantee twice in a year and shall

communicate deviation (if any) observed w.r.t to value of the BG to the respective CCA. CCA will

then send the information/ alert to TSP through the system only in case any action is required

from TSP. Similarly system will also assess the validity of bank guarantee based on the renewal

timeframe. In such cases system will send email alert to CCA as well as display the same on TSP

& CCA user dashboards prior to 2 months from the date of expiry/renewal of bank guarantee.

CCA shall be able to send the renewal reminders to TSPs as and when required in the last 2

months of the validity.

The sub-modules under Bank Guarantee module are shown in the table below:

Module Sub-Module Users

Bank Guarantee Add BG DoT

Manage BG TSP

Approve/Validate BG CCA

Invoke BG CCA, DoT


Page 52 of 182

Bank Guarantee

Do

T/C

CA

Do

TTS

PC

CA

StartAdd Bank

Guarantee

Manage Bank Guarantee

End

Invoke Bank Guarantee

Approve/Validate BG

Figure 5: Process flow for Bank Guarantee Module


Page 53 of 182

Add BG o DoT User

Module Bank Guarantee

Sub Module Add BG


Introduction This module is used by DoT user to fill the BG details.

Preconditions DoT user should be registered in the system

The License allotted to the licensee should also be registered in the system.

Actor Involved DoT User

Process Flow 1. User will login into the system with his/her login credentials and upon login

the User will be directed on the dashboard page.

2. User will now click on the Bank Guarantee->Add BG.

3. User will fill the required data fields.

4. User will submit the form.

Data Fields Selection Criteria:

o First time FBG or Renew (Checkbox) o Authorization o BG Category o BG Type o BG Status (selection criteria)

1. Received from TSP 2. Sent by DoT to CCA 3. Received from DoT 4. Sent for verification (to Bank) 5. Verified from bank 6. Invocation notice sent 7. Invoked

Data Fields:

o Submission Date o Expiry Date o BG Amount o Additional BG o BG Number o BG Validity (Auto calculate) o BG Bank Detail o BG certificate

Business Rule In case of SUC and LF, Financial Bank Guarantee is fixed for 1st year and from

2nd year it is calculated as [(average of last 4 quarters LF/SUC payable on self-

assessment basis * 2) + 10%]

Additional BG is required in case there is a 25 % jump in quarterly LF/SUC


Page 54 of 182

Performance bank guarantee is fixed for life of license/authorization

Exceptions Data to be entered in the correct format for all the fields else Pop-up display

“Please enter the details in correct format”

References Document

Post Conditions All the Submitted BGs will be available in Manage BG section for further

actions.

Manage BG o TSP User


Sub Module Manage BG


Introduction This is used by TSP (headquarter/license) user to update the details for

renewed and additional BGs.

Preconditions TSP user should be registered in the system

BG should be available in the system


Process Flow 1. User will login into the system with his/her login credentials upon login the

User will be directed on the dashboard page.

2. User will now click on the Bank Guarantee->Manage BG.

3. On this page all the BGs of that TSP will display. User will select any BG to view

and update the detail of BG.

4. User will be able to filter the BG list to view the BGs as per license, BG type,

BG category and action required

5. User will be able to add the updated details.

6. In case of additional BG required, user will be able to add the additional BG

detail in the system with that BG.

Data Fields Selection Fields:

o Authorization o BG Category o BG Type

Data Fields:

o Submission Date o Expiry Date o BG Amount


Page 55 of 182

o Additional BG o BG Number o BG Validity (Auto calculate) o BG Bank Detail o BG certificate






Adequacy of FBG is reviewed in Six months (system review)

Exceptions Data to be entered in the correct format for all the fields else Pop-up display

“Please enter the details in correct format”

User will be able to filter the BGs as per requirement

References Document


actions.

o Approve/Validate BG - CCA User


Sub Module Approve/Validate BG


Introduction This is used by CCA user to update the status for all BGs.

Preconditions CCA user should be registered in the system

BG should be available in the system

Actor Involved CCA User



2. User will now click on the Bank Guarantee->Approve/Validate BG.

3. On this page all the BGs of that TSP will display. User will select any BG to view

and update the status of BG.

4. User will be able to filter the BG list to view the BGs as per license, BG type,

BG category and action required.

5. User will be able to update the status of details.

6. User will also be able to send the renewal notice through esign.

Data Fields BG Status (selection criteria) o Received from TSP


Page 56 of 182

o Sent by DoT o Received from DoT o Sent for verification (to Bank) o Verified from bank o Invocation sent o Invoked






Renewal notice to be sent by CCA to licensee 2 months prior to expiry of FBG

All the status update action will kept in the “BG history” section with all the

details

Exceptions System will notify the user to send the auto generated renewal notice.

Only Verified BGs will be available in the MIS reports. However, there will be

an option to see BG under verification as well. Colour coding preferable.

References Document


actions.

Invoke BG DoT/CCA User


Sub Module Invoke BG


Introduction This is used by DoT/CCA user to send the invocation notice the full/partial BG.


Valid BG should be available in the system

Actor Involved DoT/CCA User



2. User will now click on the Bank Guarantee->Manage BG.

3. On this page user will select the TSP and License.

4. Once details has been selected all the BG with details will get displayed.

5. User can select BGs for invocation and will enter the amount for invocation.

6. Two options “Send invocation notice to TSP” and “Send invocation notice to

bank” will be available to select.


Page 57 of 182

7. In case of “Send invocation notice to TSP”, invocation notice will get

generated by the system in predefined format and sent to TSP using esign.

8. In case of “Send invocation notice to bank”, invocation notice will get

generated by the system in predefined format and will be available for

download.

Data Fields BG Status (selection criteria) o Received from TSP o Sent by DoT to CCA o Received from DoT o Sent for verification (to Bank) o Verified from bank o Invocation

1. Invocation notice sent to TSP 2. Invocation notice sent to Bank 3. Partial Invoked (with updated amount and remark) 4. Invoked (with remark) 5. Not Invoked (with updated amount and remark)

Business Rule Once invocation notice is sent to bank, the status will be displayed as

Invocation notice sent. If DD of said amount is received, then this will be

update by making entry by DoT/CCA user and BG amount will be get reflected.

In case BG is not invoked, it will be entered into system with reason and BG

amount will get reflected accordingly undoing the effect of BG invocation.

Exceptions

References Document

Post Conditions As per selection of user status of BG will update in the system.


Page 58 of 182

3.2.5 Spectrum Usage Charges (SUC) Assessment

This module will be used for carrying out both the self-assessment by the TSP users and for final

assessment by the CCA officials. In this module, TSP will be able to submit the Adjusted Gross

Revenue (AGR) and make the SUC payment. The module will also allow TSP user to submit the

quarterly AGR related documents and make online quarterly payment against each quarter. At

the end of financial year, the module also provides TSP user an option to make the shortfall

payments (if any). TSP user will also view online the demand order sent by CCA using this module.

In this module CCA user can view the quarterly AGR and payment made by the TSP. CCA can

review and send the Demand notice generated by system based on status of quarterly payment

received in the system. CCA can also review and send the annual demand notices to TSP based

on assessment of audited document and Final AGR assessment. Demand notices will be

generated by system however, it will sent online to TSP post confirmation by CCA. All notices sent

by CCA will be e-signed. A revised Demand order will nullify all the previous Demand orders and

will reflect all the pending demands along with the current demand.

An Assessment will be re-initiated in case of any outcome from Special Audit, C&AG audit and

Court order. A new Demand orders will be generated and reflect the changes as per new

Assessment. Older Assessments and Demand orders will get saved and will be available for View.

SUC rate will also calculate for MWA and MWB spectrum allocation.

SUC will be calculated for each technology as per their service revenue.

The sub-modules under Spectrum Usage Charges Assessment are shown in the table below:


SUC Assessment Quarterly Payments TSP Maker user, TSP Checker user, CCA Level I user

Annual Payments Audited Documents TSP Maker user, TSP Checker user

Shortfall Payment TSP Maker user, TSP Checker user

Quarterly Review CCA (Level 1)

Assessment Audited Assessment CCA (Level 1)

Finalized AGR CCA (Level 1, Level 2)

Notice Show Cause Notice TSP/CCA/DoT

Demand Notice TSP/CCA/DoT


Page 59 of 182

Spectrum Usage Charge

CC

A(l

evel

1)

LFA

(DoT

)TS

P(C

heck

er)

TSP

(Mak

er)

CC

A (

Leve

l 2)

Start

Verify the data through esign

Payment Gateway

Deposit Payment/Shortfall Payment

Submission of Audited AGR

Finalized AGR

Calculate SUC based on AGR

Review SUC paid

Calculate SUC based on AGR

View Demand notice generated by

systemOutstanding SUC

Outstanding SUC

Notice Received

Show Cause Notice issue

Demand Note issue

Willing to Pay or representation or

GrievanceGrievance

End

Submit Estimated AGR for Advance

Payment

Submit Actual AGR for Adjustment

Payment

Payment


Calculate SUC with Penalty, interest and interest over

penalty

Grievance

Figure 6: Process flow for SUC Assessment


Page 60 of 182

SUC Advance Payment (Quarterly) o TSP Maker user

Module SUC Assessment

Sub Module Quarterly Payment


Introduction This will be used by TSP Maker user to fill the estimated statement of revenue

data for making quarterly advance payment and send the entries to TSP Checker

user for verification and making the quarterly advance payment.

Only current quarter’s fields will be enabled to fill the data.

Preconditions TSP Maker user should be registered in the system.

The Spectrum allotted to TSP should be captured in the system.

Actor Involved TSP Maker user

Process Flow 1. User will login into the system with his/her login credentials upon login user will

be landed at the dashboard page by default.

2. User will now click on the SUC->Quarterly Payment sub module.

3. User will select financial year and quarter.

4. As per the selection, Statement of revenue form will be opened (only enabled

for current quarter). TSP Maker user fill the form with Estimated STATEMENT

OF REVENUE.

5. Total AGR, AGR for SUC calculation component wise, SUC Rate and SUC will get

calculated and displayed by the system. Also TSP can view the SUC rate and SUC

calculation sheet by clicking “View calculation report”.

6. User can save the form and “forward” for verification by TSP Checker user.

Data Fields Selection Criteria

o Financial Year

o Quarter

Exceptions Data to be entered should be in the correct format for all the fields else pop-up

message “Please enter the details in correct format” will be displayed.

TSP can fill the AGR figure in Advance AGR column till end of quarter.

TSP can request for extending the timeline by 15 days from the system itself. It

will go to respective CCA Dashboard/Exception with a message alert to CCA.

TSP will be allowed to fill the AGR for advance payment till the end of quarter.

System will display SUC for each technology i.e. CDMA Access, MWA of CDMA,

MWB of CDMA, GSM Access, MWA of GSM & MWB of GSM with consolidated

SUC

References Document

Post Conditions Control will flow to TSP Checker user for Verification and Making SUC Payment.

o TSP Checker user


Page 61 of 182




Introduction This will be used by TSP Checker user for verification of the entries made by TSP Maker user and making the Advance Quarterly Payment for SUC.

Preconditions TSP Checker user should be registered in the system.

TSP Maker user has filled the STATEMENT OF REVENUE data for the current

quarter and “forwarded” the same for verification.

Actor Involved TSP Checker user

Process Flow 1. User will login into the system with his/her login credentials upon login user

will be landed at the dashboard page by default.

2. TSP Checker user will now click on the SUC->Quarterly Payment sub module.


4. User will see the STATEMENT OF REVENUE entries for the current quarter

filled by TSP Maker user.

5. User can modify the entries or he can send that back to TSP maker user again

to modify the entries.

6. If user finds all the entries are correct, user can verify the entries through e-

Sign.

7. Total AGR, AGR for SUC calculation, SUC Rate and SUC will get calculated and

displayed by the system. Also TSP can view the SUC rate and SUC calculation

sheet by clicking “View calculation report”.

8. System will display SUC for each technology i.e. CDMA Access, MWA of

CDMA, MWB of CDMA, GSM Access, MWA of GSM & MWB of GSM with

consolidated SUC. User will be able to edit the SUC amount of any

technology/component to make the payment. Consolidated amount will

update as per user action

9. User can click on “Make SUC Payment” and make the quarterly advance

payment (he can also edit the amount payable).

10. Post clicking he will be directed to Bharatkosh and can make the payment.


o Financial Year

o Quarter

Exceptions Data to be entered should be in the correct format for all the fields else pop-

up message “Please enter the details in correct format” will be displayed.

TSP will be able fill the AGR figure in Advance AGR column till end of quarter.

A show cause notice will be generated and sent by CCA to TSP after 15 days

of end of quarter. Show cause notice will generate in case of Document not

submitted or Payment not done or Less Payment made based on self-

assessment or both.

TSP will be able to make the payment without AGR figures.


Page 62 of 182

References Document

Post Conditions Data entered and SUC payment will be captured in the system for MIS and Reporting purposes.

SUC – Actual Payment (Quarterly) o TSP Maker user




Introduction This will be used by TSP Maker user to fill the Actual Statement of revenue

data for making quarterly adjusted payment and send the entries to TSP

Checker user for verification and making the quarterly adjusted payment.

Only Past quarter’s data fields will be enabled to fill the data.


The Spectrum allotted to TSP should be captured in the system.






4. As per the selection Statement of revenue form will open (only enabled for

previous quarter(s)). TSP Maker user fill the form with Actual STATEMENT OF

REVENUE.

5. Total AGR, AGR for SUC calculation, SUC Rate, SUC paid, Actual SUC and

shortfall SUC will get calculated and displayed by the system. Also TSP can

view the SUC rate and SUC calculation sheet by clicking “View calculation

report”.

6. User save the form and “forward” for verification by TSP Checker user.


o Financial Year

o Quarter



References Document

Post Conditions Control will flow to TSP Checker user for Verification and Making SUC Payment.

o TSP Checker user


Page 63 of 182




Introduction This will be used by TSP Checker user for verification of the entries made by TSP Maker user and making the Adjusted Quarterly Payment for SUC.


TSP Maker user has filled the STATEMENT OF REVENUE data for the previous

quarter and “forwarded” the same for verification.






4. User will see the STATEMENT OF REVENUE entries for the previous quarter


5. User can modify the entries or he can send that back to TSP Maker user again


6. If User finds all the entries are correct, user can verify the entries through e-

Sign.




report”.



consolidated SUC. User will be able to edit the SUC amount of any

technology/component to make the payment. Consolidated amount will

update as per user action

9. User can click on “Make SUC Payment” and make the quarterly adjusted

payment (he can also edit the amount payable).

10. Post clicking he will be directed to Bharatkosh and can make the payment.


o Financial Year

o Quarter



A show cause notice will be generated and sent by CCA to TSP after 15 days

of end of quarter. Show cause notice will generate in case of Document not

submitted or Payment not done or Less Payment made based on self-

assessment or both.

TSP will be able to make the payment at any point of time. Payment is not

linked with AGR form.

TSP can make the multiple payment in a quarter.


Page 64 of 182

References Document

Post Conditions Data entered and SUC payment will be captured in the system for MIS and Reporting purposes.

o Quarterly Review - CCA Level 1


Sub Module Quarterly Review

Sub Sub Module Show Cause Notice


Introduction This will be used by CCA (Level 1, Level 2) user for review & issuance of show cause notice, generated by the system based on the unaudited (actual) statement of revenue entries.

Preconditions CCA (Level 1, Level2) user should be registered in the system.

TSP has made the unaudited (Actual) Statement of revenue entries.

SUC payment is due for that quarter.

Actor Involved CCA (Level 1,Level2) user



2. On dashboard user can view the number of Show cause notice pending for

issuance. User click on the same to review and issue the same.

3. On Show cause notice page AGR entries done by the TSP will be visible along

with calculation of SUC rate and SUC.

4. On Show cause notice CCA can view the AGR figure, SUC rate calculation

sheet, SUC rate figure, Total SUC, SUC paid, SUC due.

5. User can issue the show cause notice to TSP for payment or CCA can stop/hold

the show cause notice with remark. CCA need to e-sign to send the show

cause notice to TSP.

Data Fields

Exceptions

References Document

Post Conditions In case of issue of show cause notice, show cause notice will generate and

send to TSP along with AGR, SUC rate calculation sheet and SUC.

In case hold/stop of show cause notice, show cause notice will hold or stop at

CCA level.

o View Assessment - CCA


Sub Module View Assessment & Payment details



Page 65 of 182

Introduction This will be used by CCA/DoT user for view the assessments (Payments and AGR) done by TSPs.

Preconditions CCA user should be registered in the system.

Self-assessment (Payment or AGR) done by TSPs.

Actor Involved CCA/DoT user



2. User will now click on the SUC-> View Assessment & Payment details sub

module.

3. On this page all the assessments done by the TSP’s will display here. User will

select any assessment to view all the AGR entries and Payments (Quarterly

and Shortfall). The payment will be displayed technology wise in six separate

column along with consolidated Amount.

4. User will be able to filter the assessments based on TSP, license and year.

Data Fields

Exceptions

References Document

Post Conditions User will be able to view the AGR entries (Quarterly, Annually & Revised, if

any) and all the payments made by the TSP with payment details

SUC – Audited (Annual) o TSP Maker user


Sub Module Annual Payment

Sub Sub-Module Audited Document


Introduction This will be used by TSP Maker user to fill the Audited Statement of revenue data and send the same for verification to TSP Checker user.





2. User will now click on the SUC->Annual Payment->Audited Payment sub

module.

3. User will select financial year.

4. As per the selection Audited Statement of revenue form will open. TSP Maker

user fill the form with Audited Statement of revenue data.

OR Audited Statement of revenue data will be Auto-Populated from LF Statement of revenue.


Page 66 of 182

5. Total AGR, AGR for SUC calculation, SUC Rate, SUC as per Audited AGR, SUC

paid and shortfall SUC will get calculated and displayed by the system. Also

TSP can view the SUC rate and SUC calculation sheet by clicking “View

calculation report”.

6. User save the form and “forward” for verification by TSP Checker user.


o Financial Year

Exceptions Data to be entered should be in the correct format for all the fields’ else pop-


In case Audited Statement of revenue data gets Auto-Populated, TSP Maker

user can edit the Actual Statement of revenue Data only if TSP Checker user

hasn’t verified the same.

TSP can request for extending the timeline by 15 days from the system itself.

It will go to respective CCA Dashboard/Exception with a message alert to CCA.

References Document

Post Conditions Control will flow to TSP Checker user for Verification and Making SUC

Payment.

If TSP Checker user not exists, Data entered and will be captured in the system

for MIS and Reporting purposes.

o TSP Checker user





Introduction This will be used by TSP Checker user for verification of the entries made by TSP Maker user and making the Adjusted Quarterly Payment for SUC.


TSP Maker user has filled the audited STATEMENT OF REVENUE data for the

assessment year and “forwarded” the same for verification.




2. User will now click on the SUC->Annual Payment>Audited Document sub

module.


4. User will see the STATEMENT OF REVENUE entries for the assessment year


5. User can modify the entries or he can send that back to TSP Maker user again



Page 67 of 182

6. If User finds all the entries are correct, user can verify the entries through e-

Sign.




report”.



consolidated SUC.


o Financial Year


References Document

Post Conditions Data entered will be captured in the system for MIS and Reporting purposes.

SUC Shortfall Payment o TSP Checker user



Sub Sub-Module Shortfall Payment


Introduction This will be used by TSP Checker user for making SUC Shortfall payment Annually.

Preconditions TSP Checker user be registered in the system.

The Spectrum allotted to TSP should also be registered in the system.




2. User will now click on the SUC->Annual Payment> Shortfall Payment sub

module.


4. SUC Rate, SUC paid, Actual SUC will get calculated and displayed by the

system. Also TSP can view the SUC rate and SUC calculation sheet by clicking

“View calculation report”.

5. User will fill the amount to be paid for SUC Shortfall.

6. User will click the “make payment” button and after clicking TSP will be

directed to the Bharatkosh payment gateway.


o Financial Year


Page 68 of 182


References Document

Post Conditions SUC payment will be captured in the system for MIS and Reporting purposes.

o Audited Assessment - CCA (Level 1, Level2)


Sub Module Assessment

Sub Sub-Module Audited Assessment


Introduction This will be used by CCA (Level 1, Level2) user for review & issuance of demand order generated by the system based on the Audited (Annual) Statement of revenue entries.

Preconditions CCA (Level 1, Level2) user should be registered in the system.

TSP has made the Audited (Annual) Statement of revenue entries.

SUC payment is due for that year.

Actor Involved CCA Level 1 user



2. On dashboard user can view the number of Demand order pending for

issuance. User click on the same to review and issue the same.

3. On demand order page statement of revenue entries done by the TSP will be

visible along with calculation of SUC and interest.

4. On demand order page CCA can view the final AGR calculation sheet with

Final AGR figure, SUC rate calculation sheet, SUC rate figure, SUC paid, Total

SUC, SUC due, Interest and final remaining payment including due SUC and

interest.

5. User can issue the demand order to TSP for payment or CCA can stop/hold

the demand order with remark.

Data Fields

Exceptions

References Document

Post Conditions In case of issue of demand order, Demand order will get generated and will

be sent to TSP along with AGR calculation sheet, SUC rate calculation sheet,

SUC and interest.

In case hold/stop of demand order, Demand order will be holed or stopped

at CCA level.

SUC – Finalized o CCA Level 1


Page 69 of 182



Sub Sub-Module Finalized LF


Introduction This will be used by CCA Level 1 user to calculate Finalized SUC Payment from TSPs as per the Finalized Statement of revenue provided by LFA.

Preconditions CCA Level 1 user should be registered in the system.

LFA should have updated Finalized Statement of revenue in the system.




2. User will now click on the SUC->Assessment>Finalized LF sub module.


4. User will press the “Calculate” button to auto calculate SUC rate, SUC and

shortfall as per the finalized Statement of revenue provided by LFA (Auto-

Populated in the system).

5. User will “Forward” the Shortfall amount information to CCA Level 2 user.


o Financial Year

o Quarter

Exceptions

References Document

Post Conditions Control will be flowed to CCA Level 2 for verification of information and issuance of Demand Notice.

o CCA Level 2



Sub Sub-module Finalized LF


Introduction This will be used by CCA Level 2 user for verification of information forwarded by CCA Level 1 user and issuance of Demand Notice.

Preconditions CCA Level 2 user should be registered in the system.

CCA Level 1 user has already calculated and forwarded the Finalized SUC rate,

SUC and Shortfall amount, Penalty and Interest over penalty (if any).




2. User will now click on the SUC->Assessment>Finalized LF sub module.


Page 70 of 182

3. User will select financial year. All the pending assessment will display on the

page. CCA level 2 user can select any pending assessment for completion.

4. On assessment page, CCA Level 2 user can click on “Calculate Penalty”,

“Calculate Interest” and “Calculate interest over Penalty” button to calculate

complete SUC till date.

5. User then clicks on “Generate Demand Notice” and the same is forwarded to

the TSP

6. Demand order will generate using e-sign.


o Financial Year

Exceptions

References Document

Post Conditions After generation of Demand Notice, an Intimation and Physical copy of Demand Notice to be sent to TSP.

Show Cause Notice - TSP

Module SUC

Sub Module Notice

Sub Sub-Module Show Cause Notice


Introduction This sub module will be used by TSP user to view the show cause notice issued by CCA.

Preconditions TSP should be registered in the system

Show cause notice should be issued to TSP by CCA/DoT.

Actor Involved TSP



2. User will now click on the SUC>Notice>Show Cause Notice sub module

3. User will select financial year, LSA, Authorization/License. However user will

be able to see all the show cause notices issued by the CCA/DoT without any

selection. Selection will work as filter.

4. User will select any show cause notice to view the detail.

Data Fields

Exceptions

References Document

Post Conditions

Demand Notice - TSP


Page 71 of 182

Module SUC

Sub Module Notice

Sub Sub-Module Demand Notice


Introduction This sub module will be used by TSP user to view the demand notice issued by CCA/DoT.

User will be able to respond over demand notice


Demand notice should be issued to TSP by CCA/DoT.

Actor Involved TSP



2. User will now click on the SUC>Notice>Demand Notice sub module


be able to see all the demand notices issued by the CCA/DoT without any


4. User will select any Demand notice to view the detail of demand notice.

5. On demand notice page user will be able to take the action against demand

notice like, user can make the whole payment or partial payment or

representation or mark it as under litigation.

6. In case of complete payment, user will be able to make the payment using

bharatkosh gateway

7. In case of partial payment, user will be able to make partial payment using

bharatkosh payment gateway

8. In case of representation, user will be able to upload the supporting

documents and enter the remarks against the demand notice

9. In case of litigation, user will be able to mark the demand notice as under

litigation and will add the court name, case name, case number and remark

in the system.

10. In case of response over representation from DoT/CCA, user can respond

over the same.

Data Fields

Exceptions

References Document

Post Conditions Status of demand notice will update as per action taken by the TSP.

Show Cause Notice – CCA/DoT


Sub Module Notice



Introduction This sub module will be used by CCA/DoT to view the show cause notice’s issued by CCA/DoT.


Page 72 of 182

Preconditions CCA/DoT should be registered in the system

For representation response – Representation must be submitted by TSP against the Demand notice.

Actor Involved CCA/DoT



2. User will now click on the SUC>Notice>Show cause Notice sub module

3. User will select financial year, TSP, LSA, Authorization/License. However user

will be able to see all the demand notices issued by the CCA without any


4. User will select any Show cause notice to view the detail.

Data Fields

Exceptions

References Document

Post Conditions

Demand Notice – CCA/DoT


Sub Module Notice



Introduction This sub module will be used by CCA/DoT to view the status of demand notice issued by CCA/DoT.

User can view and respond over the representation submitted by TSP






2. User will now click on the SUC>Notice>Demand Notice sub module




4. User will select any Demand notice to view the status or representation

submitted by the TSP.

5. User can view the detail of Demand notice. On this page status of demand

notice will also display

6. In case of representation received, User will respond over the representation with documents and remarks

7. In case of Partial Payment, User will regenerate and send the fresh demand notice for that assessment


Page 73 of 182

8. In case of under litigation, User will update the case detail in court case module

9. In case of No response, User will be able to regenerate and send the fresh

demand notice OR start the BG invocation process

Data Fields Status

o Completed (Payment Received)

o Under Litigation (Court Case)

o Partial Payment

o No Response

o Representation

Exceptions

References Document

Post Conditions Status of demand notice will update as per action taken by the DoT

Note:

There are 6 types of assessment processes for SUC assessment, out of which only 1 types of assessment process for Access Licenses is explained here which have major contribution in revenue generation and volume. The remaining assessment processes are relatively less complex in nature.

Surplus adjustment of fund may be allowed between inter-year and inter-circle


Page 74 of 182

3.2.6 License Fee Assessment

License Fee Assessment module will provide platform to both TSP and CCA users to carry out

the self-assessment as well as final assessment against each of the authorization (license)

issued to a TSP. In this module, TSP will be able to submit the AGR related documents and

make the License Fee payment online on quarterly basis. Module will also allow the TSP to

make the shortfall payment (in any) at the end of the financial year. TSP will also be able to

view online the demand order sent by CCA/DoT.

In this module CCA/DoT will be able to view the quarterly AGR and the records of the online

payments made by the TSPs. CCA/DoT will review and send the notice generated by system

based on quarterly payments. CCA/DoT will also review and send the annual demand notices

to TSP using this system, based on the assessment of Audited documents. Demand notices

will be generated by the system; however, it will sent online to the TSP post confirmation by

CCA/DoT users. All such system generated demand letters will be e-signed. A revised Demand

order will nullify all the previous Demand orders and will reflect all the pending demands

along with the current demand.

An Assessment will be re-initiated in case of any outcome from Special Audit, C&AG audit and

Court order. A new Demand orders will be generated and reflect the changes as per new

Assessment. Older Assessments and Demand orders will get saved and will be available for

View.

Following are the sub modules for AGR Based Assessment licenses:

Module Sub Module Sub Sub-Module User

License Fee Assessment

Quarterly Statement & Payment

Quarterly AGR & Payment

TSP users (Maker & Checker)

Shortfall Payment TSP users (Maker & Checker)

Audited AGR TSP users (Maker & Checker)

Audited Document CCA/DoT

Audited Assessment Reconciliation Sheet CCA/DoT

Final LF CCA/DoT

Notice Demand Notice TSP/DoT/CCA

Show Cause Notice TSP/DoT/CCA

View Assessment & Payment details

CCA/DoT

Following are the sub modules for Terminal Based Assessment licenses:

Module Sub Module Sub Sub-Module User

License Fee Assessment

Quarterly Statement & Payment

Quarterly Payment TSP users (Maker & Checker)


Page 75 of 182

Shortfall Payment TSP users (Maker & Checker)

Audited Document TSP users (Maker & Checker)

Audited Document CCA/DoT

Audited Assessment Final LF CCA/DoT

View Assessment & Payment details

CCA/DoT

Note: Surplus adjustment of fund may be allowed between inter-year and inter-circle


Page 76 of 182

LF Assessment

TSP

(Ch

eck

er)

CC

AD

oT

(LFA

)/C

CA

le

vel

1T

SP (

Mak

er)

Do

T(L

FA)/

CC

A

leve

l 4

Do

T(L

FA)/

CC

A

leve

l 3

Do

T(L

FA)/

CC

A

leve

l 2

No

DVR

Verify the data submitted the TSP

Prepare the Reconciliation Sheet

Prepare the GR Calculation of AGRCalculation of LF

and outstanding LF

Calculation of LF with interest,

penalty and interest over penalty

Demand Note issue through esign

Receive Demand Notice

Willing to pay or representation or

Grievance Grievance

Submit Unaudited Quarterly AGR

Deposit Payment/Shortfall Payment

Start

End

Payment Gateway

Payment

Outstanding LF Yes

No

Data Correct

Yes

No

Submit audited AGR/ Reconciliation

sheet/ Balance Sheet

Verify the Data through esign


Grievance

Figure 7: Process Flow for LF Assessment


Page 77 of 182

3.2.6.1 AGR based License Assessment Process

Self-Assessment o Quarterly Statement of Revenue by TSP Maker user

Module License Fee Assessment


Use Case No. 3.2.6.1.1

Introduction This sub module will be used by TSP Maker user for submitting the quarterly GR figure and forwarding to TSP Checker. The TSP Checker user will verify the information and make the quarterly payment.


The License allotted to TSP should also be registered in the system.


Process Flow 1. User will login into the system with his/her login credentials upon login

user will be landed at the dashboard page by default.

2. User will now click on the LF>Quarterly Payment sub module.

3. User will select financial year, license type/authorization, quarter.

4. According to selection Statement of Revenue form will open. TSP

Maker user fill the figure in form. If Statement of Revenue of that

quarter is already filled in SUC (Quarterly Payment) then system will

automatically fetch those details.

5. According to Statement of Revenue, license fee for that quarter is

display.

6. User save the form and forward for verification by TSP Checker user.


o Financial Year

o License Type

o Service Area

o Quarter

Data field of Statement of Revenue


User can edit the fetched data only in case if it hasn’t approved by TSP checker user. Once approve it cannot edit the fetched data.

User can edit the data only in case if it hasn’t approved by TSP checker user. Once approve it cannot edit the data.

TSP can request for extending the timeline from the system itself. It will go to respective CCA Dashboard/Exception with a message alert to CCA.


Page 78 of 182

TSP will be allowed to fill the AGR for advance payment till the end of quarter.

References Document

Statement of Revenue

Post Conditions Control will flow to TSP Checker user for Verification and Making LF Payment.

o Quarterly GR verification and LF Payment by TSP Checker user




Introduction This sub module will be used by TSP Checker user to verify the Statement of Revenue figure shared by TSP Maker user then make the payment of quarterly License Fee.


Statement of Revenue is filled by TSP Maker user for that quarter.




2. User will now click on the LF>Quarterly Payment sub module


4. According to selection Statement of Revenue will display. This Statement of

Revenue figure was submitted by TSP Maker user.

5. User verify the figure and in case of discrepancy TSP checker user can update

the figure.

6. User will upload the Affidavit.

7. User submit the Statement of Revenue for LF calculation.

8. User can see the License Fee calculated by the system based on the figure

verified by the TSP checker user.

9. User can pay the License Fee as displayed by the system however it can pay

less or more than the LF calculated by the system. There will be a text box

where TSP Checker user can enter the amount which he wants to pay.

10. Before Payment a popup will display for e-sign to confirm the payment and

Revenue detail. Once the e-sign is successfully verified user can proceed for

payment.

11. Payment will made through Bharatkosh as integrated payment gateway.

12. After Successful payment “success” message will display.

13. User can pay another round of payment for the same license type/year and

quarter. TSP checker user can enter the additional amount in the same text

box to pay.


o Financial Year


Page 79 of 182

o License Type

o Service Area

o Quarter


Exceptions Data to be entered should be in the correct format for all the fields else

pop-up message “Please enter the details in correct format” will be

displayed.

User will be able to make the payment without Revenue detail.

TSP will be able to make the payment at any point of time.

TSP can make the multiple payment in a quarter.

A show cause notice will be generated and sent by CCA to TSP after 15

days of end of quarter. Show cause notice will generate in case of

Document not submitted or Payment not done or Less Payment made

based on self-assessment or both.

References Document


Affidavit

Post Conditions License Fee Payment done for the quarter with GR submission.

LF Final Assessment o Shortfall Payment





Introduction This sub module will be used by TSP Maker user for Paying the shortfall amount.



Actor Involved TSP Checker User



2. User will now click on the LF>Annual Payment> Shortfall Payment sub module

3. User will select financial year, license type/authorization.

4. According to selection, payment detail will display. Detail of payments made

for each quarter with date and consolidated amount.

5. On the form there will be textbox to pay shortfall amount according to TSP.

6. User can enter the amount in the textbox to pay and upload the affidavit for

payment

7. User can make the payment online.


Page 80 of 182


9. After Successful payment success message will display.


o Financial Year

o License Type

Data field to enter shortfall amount


References Document

Post Conditions Shortfall amount paid is tagged against the license/financial year.

Audited Statement of Revenue by TSP Maker User





Introduction This sub module will be used by TSP Maker user for submitting the Audited Statement of Revenue, Affidavit.






2. User will now click on the LF>Annual Payment> Audited Document sub

module.


4. According to selection Statement of Revenue form will open.

5. User fill the Audited figure of Statement of Revenue for each quarter.

6. User save the form for verification by TSP checker user.


o Financial Year

o License Type



TSP can request for extending the timeline by 15 days from the system itself. It will go to respective CCA Dashboard/Exception with a message alert to CCA.


Page 81 of 182

TSP will be able to save the entries as a draft (applicable for each use case wherever applicable)

References Document


Affidavit

Post Conditions Submitted Audited Statement of Revenue figure forwarded to TSP checker user for verification.

Audited Statement of Revenue by TSP Checker User





Introduction This sub module will be used by TSP Checker user to verify the Audited figure of Statement of Revenue figure shared by TSP Maker user.



Audited figure of Statement of Revenue is filled by TSP Maker user for that financial year.





3. According to selection Statement of Revenue will display. This Statement of

Revenue figure was submitted by TSP Maker user.

4. User verify the figure and in case of discrepancy TSP checker user can update

the figure.


6. User submit the Document for Assessment.

7. While submission a popup will display for e-sign the GR. Once the e-sign is

successfully verified, data will be saved.


o Financial Year

o License Type




A show cause notice will be generated and sent by CCA to TSP after 7th

October next financial year (Date may change). Show cause notice will


Page 82 of 182

generate in case of Document not submitted or Payment not done or Less

Payment made based on self-assessment or both.

References Document


Affidavit

Post Conditions Submitted data goes to CCA/DoT for Final Assessment process.

Audited Profit and Loss Statement, Reconciliation statement by TSP (headquarter) User





Introduction This sub module will be used by TSP (Headquarter) or TSP LSA user for submitting the Audited Reconciliation statement and Profit & Loss statement.

Preconditions TSP should be registered in the system.




2. User will now click on the License Fee >Annual Payment> Audited Document

sub module.


4. After selection user need to upload the Audited P&L statement and

Reconciliation statement (consolidated in case of consolidated Reconciliation

statement or license/authorization wise reconciliation).

5. User save the documents for initiation of Final Assessment process.


o Financial Year

Exceptions P&L statement is applicable as per company act.

Reconciliation statement is not mandatory to submit.

User will also be able to enter the details of Reconciliation statement in the

system

Reconciliation statement in XML/CSV/Excel format so that system can fetch

the reconciliation detail and TSP can verify and edit the same or in PDF format

References Document

Profit & Loss statement

Reconciliation statement (LSA wise or consolidated)

Post Conditions Added documents forwarded to CCA/DoT for final assessment process.


Page 83 of 182

Demand Notice


Sub Module Notice



Introduction This sub module will be used by TSP user to view the demand notice issued by CCA.



Demand notice should be issued to TSP by CCA.

Actor Involved TSP



2. User will now click on the LF>Notice>Demand Notice sub module


be able to see all the demand notices issued by the CCA without any selection.

Selection will work as filter.

4. User will select any Demand notice to view the detail of demand notice.

5. On demand notice page user will be able to take the action against demand

notice like, user can make the whole payment or partial payment or

representation or go to court.

6. In case of complete payment, user will be able to make the payment using bharatkosh gateway

7. In case of partial payment, user will be able to make partial payment using bharatkosh payment gateway

8. In case of representation, user will be able to upload the supporting documents and enter the remarks against the demand notice

9. In case of litigation, user will be able to mark the demand notice as under

litigation and will add the court name, case name, case number and remark

in the system.

Data Fields

Exceptions

References Document

Post Conditions Status of demand notice will update as per action taken by the TSP.

Audited Statement of Revenue & License Fee verification by CCA/DoT level 1 user


Page 84 of 182


Sub Module Audited Document Verification


Introduction This sub module will be used by CCA/DoT Level 1 to view the Audited Statement of Revenue figure and Quarterly license fee payment received from TSPs based on estimated Statement of Revenue.

Preconditions LEVEL 1 CCA/DoT user should be registered in the system.

Physical copies of all the documents is submitted by the TSP at CCA/DoT.

Actor Involved CCA/DoT LEVEL 1



2. User will now click on the License Fee >Audited document sub module.

3. User will select financial year, LSA, TSP, license type/authorization.

4. According to selection Statement of Revenue figure will display for all the

quarter.

5. User will check and verify the information entered in the statement of

revenue from the hard copy submitted by TSP is correct or not. If data entered

by TSP found wrong, it will be marked as “wrong entered”.

6. User need to provide the comment on Data flagged as “Wrong entered”.

7. If data entered by TSP found correct, it will marked as “Verified”.

8. User will also check & verify payment detail and status of payment made by

TSP.

9. The GR data and flag selected by Level 1 is sent to next level of user i.e. Level

2 for 2 level authentication.


o Financial Year

o TSP

o TSP License Type

o Service Area (only for DoT)

Exceptions

References Document

Post Conditions Status of Level 1 forwarded to 2nd level user for verification.

Verification of User 1 status and assigning the Assessment process by CCA level 2 user



Sub Sub-Module


Page 85 of 182


Introduction This sub module will be used by CCA/DoT level 2 user to view the Statement of Revenue figure & Quarterly license fee payment received from TSP based on verification done by CCA Level 1 user.

Preconditions Level 2 should be registered in the system.

AGR Document verification done by level 1 user.

Actor Involved CCA Level 2



2. User will click on the License Fee> Audited Document sub module.

3. User will select financial year, LSA, TSP, license type/authorization.

4. According to selection Audited Statement of Revenue figure will display for

all quarters. Also the status selected by LEVEL 1 is also get displayed.

5. If status of LEVEL 1 is “wrong entered” then entered GR will again be verified

by CCA/DoT level 2 user and it will return back to TSP for re-entry for correct

data with intimation to TSP.

6. If status of CCA/DoT Level 1 user is “Verified” for Audited Statement of

Revenue figure then license fee assessment process will initiate by CCA/DoT

Level 2 user.

7. User can assign any user (CCA/DoT level 3 user) to work on the assessment

process through dropdown. Dropdown will contain the list of users in the

CCA/DoT.


o Financial Year

o License Type

o Service Area

o User

Exceptions

References Document

Audited Statement of Revenue

Post Conditions

Initiation of Assessment Process by CCA/DoT level 3 user


Sub Module Audited Assessment

Sub Sub-module Reconciliation Sheet

Use Case No. 3.2.6.1.10

Introduction This sub module will be used by CCA/DoT level 3 user to start the assessment process.

Preconditions CCA/DoT level 3 user should be registered in the system.


Page 86 of 182

Deduction Allowance (DVR) has been finalized by all the CCA’s for that TSP, Financial Year, and Authorization/License.

Assessment has assigned by level 2 user.

Actor Involved CCA/DoT Level 3



2. User will click on the LF>Audited Assessment>Reconciliation Sheet sub

module

3. User will select financial year, TSP.

4. User will also view the reconciliation sheet to fill by the level 3 user after

verification

5. In reconciliation sheet statement of revenue detail for each LSA/authorization

will display (auto fetched by the system)

6. Disallowance figure will also be auto fetched by the system for each

LSA/authorization.

7. User enter the add-back figure in the sheet either in consolidated figure or

LSA/authorization wise.

8. According to detail enter by level 3 user, Final AGR, LF, LF Paid, LF outstanding

will be displayed.

9. User submit the reconciliation sheet to calculate the Final LF with Penalty,

interest and interest over penalty.

10. All the details forwarded to Level 4 user after submission.


o Financial Year

o TSP

Data fields

o Reconciliation sheet

Exceptions It is not mandatory to get all the DVRs from all CCAs to initiate the Assessment

process

Final LF will be calculated for LSAs only if DVR has been received. However,

GR will be calculated for all LSAs and AGR will be calculated once DVR has

been finalized.

AGR will get updated in case of any updates in DVR

References Document

P&L Statement

Reconciliation Sheet

Post Conditions Submitted details forwarded to Level 4 user.

Final LF Calculation & Issuance of Demand order by DoT/CCA (4th level user)


Page 87 of 182



Sub Sub-Module Final LF

Use Case No. 3.2.6.1.11

Introduction This sub module will be used by CCA/DoT (4th level user) to view & verify the final LF with all the applicable charges.

CCA/DoT (4th level user) also issue the demand notice (if applicable)

Preconditions CCA/DoT (4th level user) should be registered in the system

Reconciliation sheet is submitted by level 3 user for that financial year and TSP

Actor Involved CCA/DoT (4th level user)



2. User will now click on the LF>Audited Assessment>Final LF sub module

3. User will select financial year, TSP, LSA, Authorization/License.

4. According to selection Final LF calculation sheet will display with Gross GR,

Deduction, and License Fee for each quarter and License Fee paid detail with

date, interest for each quarter, penalty and interest on penalty.

5. User can view final LF with all charges as on date. Or user can manually add

the date to view the total LF till that date.

6. In case of outstanding due, User will be able to issue the demand order to TSP

linked with final LF calculation.


o Financial Year

o License Type

o LSA

Exceptions

References Document

Post Conditions Final LF calculation

Issuance of Demand order

Demand Notice


Sub Module Notice


Use Case No. 3.2.6.1.12

Introduction This sub module will be used by CCA/DoT to view the status of demand notice issued by CCA.

User can view and response over the representation submitted by TSP


Page 88 of 182






2. User will now click on the LF>Notice>Demand Notice sub module




4. User will select any Demand notice to view the status or representation

submitted by the TSP.

5. User will view the detail of Demand notice. On this page status of demand

notice will also display

Data Fields Status

o Completed (Payment Received)

o Under Litigation (Court Case)

o Partial Payment

o No Response

o Representation

Exceptions

References Document

Post Conditions In case of representation received, User will respond over the representation with documents and remarks

In case of Partial Payment, User will regenerate and send the fresh demand notice for that assessment

In case of under litigation, User will update the case detail in court case module

In case of No response, User will be able to regenerate and send the fresh demand notice OR start the BG invocation process

o View Assessment - CCA



Use Case No. 3.2.6.1.13


Preconditions CCA/DoT user should be registered in the system.


Page 89 of 182





2. User will now click on the LF-> View Assessment & Payment details sub

module.



and Shortfall).

4. User will be able to filter the assessments based on license, year.

Data Fields

Exceptions

References Document



Show Cause Notice - TSP

Module LF Assessment

Sub Module Notice


Use Case No. 3.2.6.1.14

Introduction This sub module will be used by TSP user to view the show cause notice issued by CCA.



Show cause notice should be issued to TSP by CCA/DoT.

Actor Involved TSP



2. User will now click on the LF Assessment>Notice>Show Cause Notice sub

module


be able to see all the show cause notices issued by the CCA/DoT without any


4. User will select any show cause notice to view the detail of notice.

Data Fields

Exceptions


Page 90 of 182

References Document

Post Conditions

Show Cause Notice – CCA/DoT

Module LF Assessment

Sub Module Notice


Use Case No. 3.2.6.1.15

Introduction This sub module will be used by CCA/DoT to view the show cause notice’s issued by CCA/DoT.





2. User will now click on the LF Assessment>Notice>Show cause Notice sub

module


will be able to see all the Show cause notices issued by the CCA without any


4. User will select any Show cause notice to view the detail.

Data Fields

Exceptions

References Document

Post Conditions

3.2.6.2 Terminal based License Assessment Process

Quarterly Statement & Payment o Quarterly Terminal & Hub detail by TSP Maker user


Sub Module Quarterly Statement & Payment

Sub Sub Module Quarterly Payment


Introduction This sub module will be used by TSP Maker user for submitting the quarterly license Fee, TSP maker user submit the terminal and hub detail in the system and send the same to TSP checker user to verify the information and make the quarterly payment.



Page 91 of 182





2. User will now click on the LF>Quarterly Payment sub module.


4. According to selection Terminal and hub detail form will open. User will enter

the detail in the form.

5. According to detail filled by user, license fee for that quarter will display.

6. User will save the form and forward for verification by TSP Checker user.


o Financial Year

o License Type

o Service Area

o Quarter

Data field of Terminal and hub


User will be able to edit the data only in case if it hasn’t approved by TSP checker user. Once approve it cannot edit the data.

TSP will be able to request for extending the timeline by 15 days from the system itself. It will go to respective CCA Dashboard/Exception with a message alert to CCA.

References Document

Terminal and Hub detail

Post Conditions Control will flow to TSP Checker user for Verification and Making LF Payment.

o Quarterly Terminal & Hub detail verification and LF Payment by TSP Checker user



Sub Sub Module Quarterly Payment


Introduction This sub module will be used by TSP Checker user to verify the Terminal and Hub figure shared by TSP Maker user then make the payment of quarterly License Fee.


Terminal and Hub detail is filled by TSP Maker user for that quarter.





Page 92 of 182

2. User will now click on the LF>Quarterly Payment sub module


4. According to selection Terminal and Hub detail will display which was

submitted by TSP Maker user.

5. User will verify the detail and in case of discrepancy TSP checker user will

update the figure.


7. User submit the detail for LF calculation.

8. User will see the License Fee calculated by the system

9. User will pay the License Fee as displayed by the system however it can pay

less or more than the LF calculated by the system. (There will be a text box

where TSP Checker user can enter the amount which he wants to pay).

10. During payment a popup will display for e-sign. Once the e-sign is successfully

verified user can proceed for payment.



13. User can pay another round of payment for the same license type, year and

quarter. TSP checker user can enter the additional amount in the same text

box to pay.


o Financial Year

o License Type

o Quarter

Data field of Terminal and Hub


References Document

Post Conditions License Fee Payment done for the quarter with Terminal and Hub detail submission.

LF Final Assessment o Shortfall Payment





Introduction This sub module will be used by TSP Maker user for Paying the shortfall amount.



Page 93 of 182





2. User will now click on the LF> Quarterly Statement & Payment > Shortfall

Payment sub module


4. According to selection, payment detail will display. Detail of payments made

for each quarter with date and consolidated amount.

5. On the form there will be textbox to pay shortfall amount according to TSP.

6. User can enter the amount in the textbox to pay and upload the affidavit for

payment

7. User can make the payment online.




o Financial Year

o License Type

Data field to enter shortfall amount


References Document

Post Conditions Shortfall amount paid is tagged against the license/financial year.

o Audited Documents – TSP User


Sub Module Audited Documents


Introduction This sub module will be used by TSP user for Adding the Audited Documents.






2. User will now click on the LF>Audited Documents sub module


4. According to selection, document upload form will open.

5. User will upload the audited documents.


Page 94 of 182


o Financial Year

o License Type

Data field to upload the documents


References Document

Post Conditions Audited documents is tagged against the license/financial year.

Terminal detail & License Fee verification by CCA/DoT level 1 user




Introduction This sub module will be used by CCA/DoT Level 1 to view the Terminal and hub detail and Quarterly license fee payment received from TSPs based on estimated Statement of Revenue.

Preconditions LEVEL 1 CCA/DoT user should be registered in the system.

Audited figure of Terminal and Hub has been submitted by TSP in the system

Actor Involved CCA/DoT LEVEL 1



2. User will now click on the License Fee >Audited document sub module.

3. User will select financial year, TSP, license type/authorization.

4. According to selection submitted Audited figure of Terminal and Hub will

display for all the quarter.

5. User will check and verify the information entered in the statement of

revenue from the copy uploaded by TSP is correct or not. If data entered by

TSP found wrong, it mark as “wrong entered”.

6. User need to provide the comment on Data flagged as “Wrong entered”.

7. If data entered by TSP found correct, it will marked as “Verified”.

8. User will also check & verify payment detail and status of payment made by

TSP.

9. The flag selected by Level 1 is sent to next level of user i.e. Level 2 for 2nd level

authentication.


o Financial Year

o TSP


Page 95 of 182

o TSP License Type


Exceptions

References Document

Post Conditions Status of Level 1 forwarded to 2nd level user for verification.

Verification of User 1 status and assigning the Assessment process by CCA level 2 user




Introduction This sub module will be used by CCA/DoT level 2 user to view the Terminal and Hub detail & Quarterly license fee payment received from TSP based on verification done by CCA Level 1 user.

Preconditions Level 2 should be registered in the system.

AGR Document verification done by level 1 user.

Actor Involved CCA Level 2



2. User will click on the License Fee> Audited Document sub module.

3. User will select financial year, TSP, license type/authorization.

4. According to selection figure of Terminal and Hub will display for all quarter.

Also the status selected by LEVEL 1 is also display.

5. If status of LEVEL 1 is “wrong entered” then entered figure will again verify by

CCA/DoT level 2 user and it will return back to TSP for re-entry for correct

data with intimation to TSP.

6. If status of CCA/DoT Level 1 user is “Verified” for Audited figure of Terminal

and Hub then license fee assessment process will initiate by CCA/DoT Level 2

user.

7. User can assign any user (CCA/DoT level 3 user) to work on the assessment

process through dropdown. Dropdown will contain the list of users in the

CCA/DoT.


o Financial Year

o License Type


o User

Exceptions


Page 96 of 182

References Document

Audited Terminal and Hub Detail Document

Post Conditions

Final LF Calculation & Issuance of Demand order by DoT/CCA (3rd level user)



Sub Sub-Module Final LF


Introduction This sub module will be used by CCA/DoT (3rd level user) to view & verify the final LF with all the applicable charges.

CCA/DoT (3rd level user) also issue the demand notice (if applicable)

Preconditions CCA/DoT (3rd level user) should be registered in the system

Reconciliation sheet is submitted by level 3 user for that financial year and TSP

Actor Involved CCA/DoT (3rd level user)



2. User will now click on the LF>Audited Assessment>Final LF sub module

3. User will select financial year, TSP, LSA, Authorization/License.

4. According to selection Final LF calculation sheet will display with penalty and

interest on penalty.

5. User can view final LF with all charges as on date. Or user can manually add

the date to view the total LF till that date.

6. User can issue the demand order to TSP with final LF amount. User can issue

the demand order through e-sign.


o Financial Year

o License Type

o LSA

Exceptions

References Document

Post Conditions Final LF calculation

Issuance of Demand order

o View Assessment – CCA/DoT



Page 97 of 182









2. User will now click on the LF-> View Assessment & Payment details sub

module.



and Shortfall).

4. User will be able to filter the assessments based on license, year.

Data Fields

Exceptions

References Document



Note:

There are 6 types of assessment processes for LF assessment, out of which 2 types of assessment process for AGR based and Terminal based are explained here which have major contribution in revenue generation and volume. The remaining assessment processes like project cost based, royalty based, etc are relatively less complex in nature.

Surplus adjustment of fund may be allowed between inter-year and inter-circle


Page 98 of 182

3.2.7 Deduction Verification Report (DVR) Module

Deduction Verification Report (DVR) Module will enable the TSPs to online file the deduction

verification claim online, and subsequently enable the CCA users/officials to online verify and

approve the DVR claims in the RMS application. The system also provides an option to generate

and review DVR reports against each TSPs.

In this module, TSP user will submit the Deduction claim to the respective CCA office online as

per the AG/AO/PP/IR forms/format for the purpose of deduction claim verification. The process

of submission of DVR claims is a time bound process and system will allow the TSP to submit the

form along with the supporting documents to CCA within 75 days from the quarter end. Then

CCA will verify the claim submitted by TSP and approve the claim for deduction. As per the

verification and approval, objection sheet will be prepared and shared with TSP for response. TSP

will be responding over objection sheet along with supporting documents using RMS.

Once the verification will be completed by the CCA, deduction verification report will be prepared

by the system which will be used to calculate the AGR.

The system should have the capability to handle the exceptions like Departmental order, Special

Audit, C&AG audit and Court order. Deduction Claim and Verification Process which may lead to

re-initiation/revision/re-examination of the DVR process. System should be able to handle this as

a part of system workflow. In such cases and older Deduction Claim and Verification will get saved

and will be available for View. This process will also trigger the re-initiation of LF assessment and

SUC assessment. All the older assessment affected by the re-initiation of DVR will get saved and

available for view.

The sub-modules under DVR Module are shown in the table below:

Module Sub-Module User

DVR Module Quarterly Claim Deduction TSP

Annual Audited Claim TSP

Objection Sheet TSP

Revision TSP

Quarterly Review - Deduction Claim

CCA

Quarterly/Provisional DVR CCA

Annual Review - Deduction Claim

CCA

Re-initiation CCA

View DVR DoT, CCA


Page 99 of 182

Figure 8: Process Flow for DVR

Deduction Verification Report

TSP

CC

A

StartSubmit AO/AG/PP/IR within 75 days of

end of quarter

Submit Supporting

documents of AO/AG/PP/IR

Extension granted

No

Yes

Verify the document, status

update. 15 days extension

for document submission

Objectionable sheet prepare and sent to

TSP

Objectionable sheet Recieved

Submit Document in support of

objectionable sheet

Verify the document and update the status

of AO/AG/PP/IR

DVR Prepared

End

Audited Documents submission


Page 100 of 182

TSP o Claim DVR by TSP

Module Deduction Verification Report Module

Sub Module Claim Deduction


Introduction This will be used by TSP user to claim Deduction.




2. User will now click on the DVR>Claim Deduction. 3. User will be able to fill the AO form in AO form section, AG form in AG form

section, PP form in PP form section and IR form in IR form section. These forms are available for all types of deduction as per license type.

4. Rows of each form, work like excel rows. User can merge rows/column of form. User can also filter the columns as per need like in excel.

5. User fill the AO, AG, IR and PP form for each quarter and license/authorization type.

6. User will upload the relevant documents against the deduction claim in each row of AO, AG, IR and PP form.

7. User will fill the Tax claim detail for GST/Service Tax and Local tax (exact name need to use).

8. User will fill the data in each form within 75 days of end of quarter. Beyond 75 days TSP can’t fill the form.

9. User can final submit the form and authorize it with e-sign. However, TSP can save the form as draft for modification at later stage.

Data Fields Selection criteria o Quarter o License/authorization

Data fields of each form

Exceptions Data to be entered should be in the correct format for all the fields’ else pop-up message “Please enter the details in correct format” will be displayed.

User have the facility to upload the file using file based utility for AO/AG/PP/IR and supporting proof/invoice/balance sheet will upload against each row.

Timeline to upload/add the deduction claim in 75 days from the end of quarter.

TSP to submit the request for extending the timeline from the system itself. It will go to respective CCA Dashboard/Exception with a message alert to CCA. (Wherever applicable)

References Document

Post Conditions Submitted AO, AG, IR and PP form sent to CCA for claim verification.


Page 101 of 182

TSP

o Objection sheet by TSP


Sub Module View Objection Sheet


Introduction This will be used by TSP user to view the objection sheet prepared by CCA.


Review done by CCA.



2. On dashboard user can click on objection sheet number or user can click on the DVR > Objection Sheet.

3. User select year, quarter and license/authorization type to view the objection sheet.

4. Here objection item list of each form will display which include form name, invoice number, amount and remark.

5. TSP can upload the supporting proof against the each row of objection sheet. 6. TSP cannot add new claim also it cannot edit the previous entered claim and

document.

Data Fields

Exceptions TSP will have 15 days’ time to respond on objection sheet along with

supporting proof.

Also, it will be able to request for an extension to upload the supporting

proof which will go as an exception in CCA/DoT Dashboard.

Once CCA approves the extension request, TSP can upload the proof

against each row of objection sheet.

References Document

Post Conditions Submitted data/proof will go to CCA for verification.

o Revision by TSP


Sub Module Revision



Page 102 of 182

Introduction This will be used by TSP user to make the revision in the existing Deduction claim.




2. On dashboard user can click on objection sheet number or user can click on the DVR > Revision.

3. User will request to revise the DVR. 4. User will be able to add the new documents against each row which was

claimed previously. 5. User will be able to claim new deduction, user will enter the new claim in the

sheet. New claim will be highlighted with different color/categorization. 6. User will upload the supporting proof against the new claim.

Data Fields

Exceptions

References Document

Post Conditions Revision request sent to CCA as an exception. Once CCA allow to enter the

deduction claim, TSP can enter the new claim or upload the documents for

previously added claims.

Once TSP submit the new claim or documents for previous claim it will send

to CCA to reinitiate the DVR process, It will also trigger to reinitiate the

process of LF and SUC assessment

CCA o Quarterly Review - CCA – level 1


Sub Module Quarterly Review - deduction claim


Introduction This will be used by CCA user to review the deduction claim by TSP.


Deduction claim must be submitted by TSP.

Actor Involved CCA level 1 user


2. User will now click on the DVR> Review deduction claim. 3. User will select the quarter and license/authorization type to view the AO,

AG, IR and PP form submitted by TSP. 4. User will give their comments for each/selected row of each form. 5. User can filter any column according to criteria like excel.


Page 103 of 182

6. User also select the status for each/selected row like Admissible, partial admissible, provisional admissible or inadmissible. User enter amount in case of partial admissible status along with reasons for disallowance in all cases of disallowance from a check list (15-20 options).

7. Claim/approve amount of each row is reflect and added in “Manage DVR” section to prepare DVR.

8. User submit the form for next level reviews.

Data Fields Selection Criteria 1. Admissible

2. Inadmissible

3. Partial Admissible

4. Provisional Admissible

Exceptions Rows will highlight with specify color, with the selection of status.

There will be separate column for CCA level 1 for status and amount, and will not be able to edit the status of any other user.

Last status in a row will be the final status of that row, whether it will be CCA level 1, 2 or 3.

Multi Select option will be available for action.

References Document

Post Conditions Submitted comment of CCA level 1 user sent to CCA level 2 user for review.

o Quarterly Review - CCA - level 2






Review done by CCA level 1 user




AG, IR and PP form submitted by TSP. 4. User will give their comments for each/selected row of each form. 5. User can filter any column according to criteria like excel. 6. User also select the status for each/selected row like Admissible, partial

admissible, provisional admissible or inadmissible. User enter amount in case of partial admissible status along with reasons for disallowance in all cases of disallowance from a check list. (15-20 options).


Page 104 of 182

7. Claim/approve amount of each row is reflect and added in “Manage DVR” section to prepare DVR.

8. User can also change the status of CCA level 1 user. 9. User submit the form for next level reviews.


2. Inadmissible






References Document

Post Conditions Submitted comment of CCA level 2 user sent to CCA level 3 user for review

o Quarterly Review - CCA – level 3






Review done by CCA level 2 user.





admissible, provisional admissible or inadmissible. User enter amount in case of partial admissible status along with reasons for disallowance in all cases of disallowance from a check list. (15-20 options).

7. Claim/approve amount of each row is reflected and added in “Manage DVR” section to prepare DVR.

8. User can also change the status of CCA level 1 user and CCA level 2 user. 9. User submit the form.


Page 105 of 182


2. Inadmissible






References Document

Post Conditions According to Quarterly review status of CCA, Objection Sheet is prepared and

display on dashboard, CCA user can view and send to TSP for response.

Objection sheet will have only inadmissible and partial inadmissible items.

o Objection sheet by CCA


Sub Module View Objection Sheet


Introduction This will be used by CCA user to view the objection sheet prepared by CCA.


Review done by CCA.

Actor Involved CCA user


2. On dashboard user can click on Objection sheet number or user can click on the DVR > Objection Sheet.

3. User select year, quarter and license/authorization type to view the Objection sheet. After search all the Objection sheet listing will display. CCA can select any objection sheet to view the sheet.

4. Here objection item list of each form will display which include form name, invoice number, amount and remark.

5. User can click on send to TSP button to forward the sheet to TSP, user need to e-sign the objection sheet before sending to TSP.

Data Fields

Exceptions

References Document

Post e-sign objection sheet send to TSP for response.


Page 106 of 182

Post Conditions TSP will have 15 days’ time to respond on objection sheet along with supporting proof. Also, it will be able to request for an extension of another 15 days.

o Quarterly/Provisional DVR - View


Sub Module Quarterly/provisional DVR


Introduction This will be used by CCA user to view the DVR prepared by CCA.


Review done by CCA.

Actor Involved DoT user


2. User will now click on the DVR > View Provisional DVR. 3. User select year, quarter and license/authorization type. 4. Here DVR consolidated figure will display.

Data Fields

Exceptions

References Document

Post Conditions

o Annual Review – CCA – Level 1


Sub Module Annual Review - deduction claim




Quarterly Review done by CCA level.

Annual Audited Deduction Document submitted by TSP to CCA.




AG, IR and PP form submitted by TSP. 4. User will give their comments for each/selected row of each form. 5. User can filter any column according to criteria like excel.


Page 107 of 182

6. User also select the status for each/selected row like Admissible, partial admissible or inadmissible. User enter amount in case of partial admissible status along with reasons for disallowance in all cases of disallowance from a check list. (15-20 options).

7. Claim/approve amount of each row is reflected and added in “Annual DVR” section to prepare DVR.

8. User submit the form for next level of review.


2. Inadmissible


Exceptions Timeline for review will be 9 month from the end of Financial Year.


Last status in a row will the final status of that row whether it will be CCA level 1, 2 or 3.

Provisional DVRs completed will be available for further modification

References Document








Annual Audited Document Review done by CCA level 1 user.





admissible or inadmissible. User enter amount in case of partial admissible status along with reasons for disallowance in all cases of disallowance from a check list (15-20 options).


Page 108 of 182

7. Claim/approve amount of each row is reflect and added in “Annual DVR” section to prepare DVR.



2. Inadmissible





Disallowance reason may be increased at later stage

References Document








Annual Audited Document Review done by CCA level 2 user.





admissible or inadmissible. User enter amount in case of partial admissible status along with reasons for disallowance in all cases of disallowance from a check list. (15-20 options).

7. Claim/approve amount of each row is reflect and added in “Annual DVR” section to prepare DVR.




Page 109 of 182

2. Inadmissible





References Document

Post Conditions According to final status of CCA, Final DVR will prepare and available to view at

CCA and DoT level.

o Re-initiation by CCA


Sub Module Re-initiation


Introduction This will be used by CCA user to make the reinitiate in the existing Deduction claim.


DVR has been processed by the CCA



2. On dashboard user can click on the DVR > Re-initiation. 3. On this page all the completed DVR will display, user can select any DVR to

reinitiate the Deduction verification process. CCA will enter the reason to reinitiate the Deduction verification process.

4. User can filter the completed DVR by year, TSP, License/Authorization.

Data Fields

Exceptions

References Document

Post Conditions CCA will reinitiate the DVR process and it will trigger the re-initiation of LF and

SUC assessment. However existing DVR will remain in the system for view.

DoT/CCA o View DVR



Page 110 of 182

Sub Module View DVR


Introduction This will be used by DoT/CCA user to view the DVR prepared by CCA.


Review done by CCA.

Actor Involved DoT/CCA user


2. User will now click on the DVR> View DVR. 3. User select year, quarter and license/authorization type. 4. Here DVR consolidated figure will display for each component.

Data Fields

Exceptions DVR will be the lowest of CCA claim verification OR Audited

deduction claimed by TSP for each quarter

References Document

Post Conditions DVR report will be available for view to the user


Page 111 of 182

3.2.8 Court Case Module

The court case module provide the Department users with an option to online manage all the

information pertaining to various ongoing Court Cases or arbitration across DoT including the

CCA offices.

Using this module the DoT users can add and manage any new court case. Each case will be linked

with the demand order along with information like court name, case number and status of the

case. User can also update the status (can be multiple) of the case with remarks and date at any

time.

Scope of work under this module should also provision for integration of Court case module with

LIMBS application.

The sub-modules under Court case module are shown in the table below:

Module Sub Module User

Court Case Add Case CCA, DoT

Court Case Manage Case CCA, DoT


Page 112 of 182

Court case

DoT

TSP Demand Notice

Start

Link demand order with court name,

case number, case status

Update Case status End

Approach to court against

Demand Notice

Figure 9: Process flow for Court Case Module


Page 113 of 182

CCA/DoT – Add Case

Module Court Case

Sub Module Add Case


Introduction This will be used by CCA/DoT user to add the court case and link it with Demand order.


Demand order is generated by the system and not paid by the TSP.

Actor Involved CCA/DoT User



2. User will now click on the Court Case>Add case sub module.

3. User can create new court case using selection of Year, Circle, TSP, and

Authorization.

4. User need to add the Court name, Case Name, Court Number, Court case

number, next hearing date, Court case status, court case detail and reason of

case.

5. If Court case is linked with any Demand order, it will display the amount of

demand order and amount till date with all penalty & interest.


o Financial Year

o Authorization

o TSP

o Demand order

o Circle

Reason of case

o SUC Demand Order

o LF Demand order

o OTSC

o LF Rate

o SUC Rate

o Any other with remark



Court case may not necessary be only for Demand Order, this is applicable for

any other issue as well which includes OTSC, LF Rate, SUC Rate, Any other.

References Document

Post Conditions Court case added in the system for further MIS reporting.


Page 114 of 182

Court case will link with demand order generated by the system.

CCA/DoT- Manage Case

Module Court Case

Sub Module Manage Case


Introduction This will be used by CCA/DoT user to manage the court case.


Court Case must be available in the system.

Actor Involved CCA/DoT User



2. User will now click on the Court Case>Manage case sub module.

3. On manage case page all the court case will list.

4. User can select any court case to manage the status, hearing date of case.

5. User can add the status of case with remark and date. User can add multiple

status.


o Close

o Hold

o Stay


References Document

Post Conditions Court case status added in the system for further MIS reporting.


Page 115 of 182

3.2.9 MIS

DoT/CCA would like to access various information pertaining to assessment or various historical

data present in the system. This module will help the user to gain access to such information on

regular/periodic or need basis in the form of MIS report. The system should provide the option

to DoT user to modify the search and generate run time customize MIS reports on need basis

also. Most of the report are available for internal department users only, only few report will be

available for public (DoT/CCA users and TSP users only).

User Administration (Use Case No. 3.2.9.1):

Category * Dropdown Office Dropdown

S.No.

Category (Official/TSP)

Name

Designation

Username

Office (CCA/DoT)

Location

Department

Phone

Role

Email

Address

License Information (Public report) (Use Case No. 3.2.9.2):

License Type * Dropdown (All/Terminated/Surrender)

LSA Dropdown Assessing Area (CCA) Dropdown

S.No. License Type License Name

Licensee Name

License Number

Effective Date

Expiry Date

Spectrum Information (Public report) (Use Case No. 3.2.9.3):

Circle* Dropdown


Page 116 of 182

Band Dropdown Operator Dropdown

Technology

Dropdown (GSM/CDMA/BWA/MWA/MWB)

Year of Allotment Dropdown

Spectrum Status

Dropdown (Hold/Surrendered)

Start Date Date Selection End Date Date Selection

Spectrum Type

Dropdown (Original/ Shared)

S.No.

Circle

Band

Allotment

Year

Operator

SUC Rate

Spectrum Status

Liberalize status

Shared Start Date*

Technology

Spectrum Type

AGR Statement (Use Case No. 3.2.9.4):

Service Area* Dropdown

Operator Dropdown License Dropdown Year* Dropdown Quarter Dropdown

AGR Type

Dropdown (Audited/Unaudited)

S.No.

Category

Licens

e

Service

Area

Operato

r

AGR <Year> Cumulative Audited AGR

Status <Year>

GR

Deduction Claimed

Deduction

Allowed

AGR

GR

Deduction

Claimed

Deduction

Allowed

AGR


Page 117 of 182

Bank Guarantee Administration (Use Case No. 3.2.9.5): o List of Bank Guarantees

Circle* Dropdown

License Dropdown

BG Category Dropdown (LF/SUC/NIA)

BG Type Dropdown

Status Dropdown From Date Date Selection

To Date Date Selection

S.No.

Circle Licen

se Operat

or

BG Detail

BG Number

Bank Name

Submission date

Expiry date

Amount

Status

Report on dues outstanding against each license & Availability of FBG/PBG (Use Case No. 3.2.9.6)

Circle*

Dropdown

Year Dropdown


Page 118 of 182

Operator Dropdown

LF/SUC Dropdown (LF/SUC/All)

S.No.

Circle

License

Operator

Year

LF/SUC/All

Total LF/SUC/All

Principle

Interest

Penalty

Interest over

Penalty

Paid

Shortfall

PBG Amount

and validity

FBG Amount

and validity

Document detail (Use Case No. 3.2.9.7)

Circle* Dropdown License Dropdown TSP Dropdown Assessment Year Dropdown

S.No. Circle Year

Operator

License Type

Document Received (Y/N)

Q1 AGR

Q2 AGR

Q3 AGR

Q4 AGR

Audited AGR

P & L Statement

Reconciliation Sheet


Page 119 of 182

DVR and Assessment Module (Use Case No. 3.2.9.8):

Circle* Dropdown License Dropdown payment Type Dropdown Year Dropdown LF/SUC Dropdown

S.No.

Circle

Year

Operator

License Type

LF/SUC

Document status

Deduction verification status

Assessment status

Demand Notice Status

Demand Notice Amount

Demand Notice date

Trend Analysis (YoY, QoQ, TSP wise) (Use Case No. 3.2.9.9): o Trend analysis report of LF collection based on last 5 year.

o Trend analysis report of different components of deductions.

o Trend analysis report of SUC collection based on last 5 year data.

o Trend analysis of GR, AGR and different components of AGR.

Pending Activities (Use Case No. 3.2.9.10) o This will display the pop up alert for all the pending Activities once the user log-in

in the system.

Revenue collection Report (Use Case No. 3.2.9.11)

Circle Dropdown


Page 120 of 182

Year Dropdown Quarter Dropdown Operator Dropdown LF/SUC Dropdown

S.No. Circle License Operator Year Quarter Revenue

Collection

Outstanding demand report (Use Case No. 3.2.9.12)

Circle Dropdown Year Dropdown Quarter Dropdown Operator Dropdown LF/SUC Dropdown

S.No. Circle License Operator Year Quarter Outstanding

Demand

*Above mentioned MIS reports are indicative only. The final list of MIS reports will be finalized during requirement gathering (SRS) phase. * SI will provide the MIS reports on demand as and when required by DoT


Page 121 of 182

3.2.10 Dashboard (Department/User wise)

This module provides user a quick navigation to critical functions or information which are

required by them (system users) for carrying out their assessment related work. In this module

most of the critical information as well as pending task/activity (like Demand Notices, LF, SUC,

Grievances, etc.) will be made available on user dashboard. The dashboard should provide the

user an option to highlight and all the information is available only for current financial year.

However user can view the required information/report through MIS section or by search which

is available in each module. All the Dashboard will be user group based and each dashboard item

will redirect user to the respective section.

The User Dashboard view along with the information is provided below:

TSP (headquarter) Dashboard o User will be able to see Demand Orders received from CCA/DoT against each

License and Service area. This dashboard link will redirect the user to take their

internal actions.

o User will be able to see LF due against each License and Service area to take their

internal actions.

o User will be able to see SUC due against each License and Service area to take their

internal actions.

o User will be able to see Bank Guarantee pending for renew against each License

and Service area to take their internal actions.

o User will be able to see Open Grievances for issues raised by TSP for status, replies

and further actions.

o User will be able to see Open Representation raised by TSP for replies and further

actions

o User will be able to see CAF/EMR Notices against each License and Service area

to take their internal actions.

TSP (Service/Authorization) o User will be able to see Demand Orders received from CCA/DoT. This dashboard

link will redirect the user to Demand order page to make payments or user can

take other actions like Representation, Court Cases etc. from respective section.

o User will be able to see LF due against each License to take further actions

including Payment, Document submission etc.

o User will be able to see SUC due against for Spectrum to take further actions

including Payment, Document submission etc.


Page 122 of 182

o User will be able to see Bank Guarantee pending for renew to take further

actions.

o User will be able to see Open Representation raised by TSP for replies and further

actions



o User will be able to see CAF/EMR Notices against each License to take further

actions.

o User will be able to see Exceptions requests granted in his dashboard to take

further action (Document submission etc.)

CCA o User will be able to see Demand Orders sent to TSPs. This dashboard link will

redirect the user to take further action like Demand Order regeneration or BG

invocation.

o User will be able to see LF due against TSP for each License to take further actions

including Demand Order or BG Invocation.

o User will be able to see SUC due against TSP for Spectrum to take further actions


o User will be able to see Bank Guarantee pending for renew to take further actions

like sending renewal notice sent to TSPs.




actions including Demand Order or BG Invocation.

o User will be able to see Exceptions requests received from TSPs in his dashboard

to take further action (Grant/Reject)

o User will be able to see Representation received from TSPs in his dashboard to

take further action

o User will be able to see the number of Demand Orders needs to send to TSPs. This

dashboard link will redirect the user to take further action.

o User will be able to see the number of DVR pending for review at user level

o User will be able to see the number of court case whose hearing is pending in

next 10 days to take further action.

LFP o User will be able to see Open Grievances for issues raised by TSP for status, replies



Page 123 of 182

LFA o User will be able to see Demand Orders sent to TSPs. This dashboard link will

redirect the user to take further action like Demand Order regeneration or BG

invocation.

o User will be able to see LF due against TSP for each License to take further actions


o User will be able to see DVR received from CCAs.

o User will be able to see Bank Guarantee pending for renew to take further actions

like sending renewal notice sent to TSPs.




actions including Demand Order or BG Invocation.

o User will be able to see the number of court case whose hearing is pending in

next 10 days to take further action.

o User will be able to see Representation received from TSPs in his dashboard to

take further action

o User will be able to see Exceptions requests received from TSPs in his dashboard

to take further action (Grant/Reject)

The Statistical Dashboard will showcase the following information, this information will be showcased as per the filter selected by the users. Filter criteria could be TSP, quarter, assessment year, licenses, service area etc.

o LF (pending vs received)

o SUC (pending vs received)

o Demand order sent (amount)

o BGs pending for renew

o Grievances (open vs closed)

o DVR (pending vs received)

* Above mentioned dashboard items are indicative and consolidated for all stakeholders, however dashboard items will be specific for each user groups. Dashboard items as per the User Groups will be finalized during SRS phase.


Page 124 of 182

3.2.11 Knowledge Bank Module

The knowledge bank module will help DoT to build a repository of all critical orders, information

and other important document which needs to be shared with the internal users. Using this

module DoT user can share the knowledge/orders internally with other user. While uploading

the order DoT Admin User can select the category of the document like SUC or LF or General.

General orders are visible to all users. However SUC or LF related orders is only visible to CCA and

DoT user. The module allows users to upload the file in pdf format or they can post the link of

order (may be external site path) along with order name and category.

The sub-modules under Knowledge Bank modules are shown in the table below:


Knowledge Bank DoT, CCA, TSP


Page 125 of 182

Knowledge BankTS

PD

oT/C

CA

Start

Upload order with name, category and

user type to view the order

Can view the order which is marked as

For TSP

EndCan view the order

with name and category

Figure 10: Process Flow for Knowledge Bank Module


Page 126 of 182

DoT Admin User

Module Knowledge Bank


Introduction This will be used by DoT Admin User to upload all published orders (either in PDF format or to update the link in case order is already uploaded on DoT webpage).




2. User will now click on the Knowledge Bank Module. 3. User will check/uncheck the checkbox “for TSP”, if that order is to be

available/not available for TSP as well. A. By default this checkbox is “unchecked”. B. Post checking the checkbox “for TSP” a pop-up will be shown “This order

will be visible to TSP users as well”->”Confirm”. 4. User will select the category of the order and enter the name of order (SUC,

LF or General etc.). 5. User will browse for the order and click on “upload” the published orders. OR

User will update the link and order title of orders which are already uploaded on DoT webpage.

Data Fields Selection Criteria o Order Categories

Exceptions

References Document

Post Conditions All the uploaded orders will be visible to intended participants (DoT, CCA and TSP)

DoT/CCA/TSP User

Module Knowledge Bank


Introduction This will be used by DoT/CCA/TSP user to access the published orders uploaded.

Preconditions DoT/CCA/TSP user should be registered in the system.

Actor Involved DoT/CCA/TSP user


2. User will now click on the Knowledge Bank Module. 3. User will select the categories of orders. OR

By default, orders will be visible sorted from latest released. 4. User will see all the orders and he/she can click on the link to open/download

the order as per the access given by DoT Admin User.



Page 127 of 182

o Order Category

Exceptions

References Document

Post Conditions DoT/CCA/TSP will be able to view/download the published orders.

Each order will have a button “initiate discussion” on right side. By clicking this DoT/CCA/TSP user will be redirected to the “Discussion Board” module and initiate the discussion with reference.


Page 128 of 182

3.2.12 Discussion Board Module

DoT is looking forward to provide a chat based collaborative tool to its internal as well as external

stakeholders. Using this module, users of the application can collaborate online with each other.

The module allows any user to initiate the discussion, user needs to select the category of the

discussion as well as participant for the topic. Participant on these discussion board can be

internal stakeholders i.e. DoT or CCA users or they can also all including external stakeholders i.e.

TSPs. Based on the participants of the discussion, discussion topic shall be made visible to the

users under the module. Each user can view and comment on the topic. In case if the topic is

created by CCA or DoT user, they can select the participants for the topic. However in case topic

is created by TSP user then by default all types of user will become participant (TSP cannot select

the participant for the topic).

The sub-modules under Discussion Board Modules are shown in the table below:


Discussion Board DoT/CCA Creator User DoT, CCA

DoT/CCA Responder User DoT, CCA

TSP Creator User TSP

TSP Responder User TSP


Page 129 of 182

Figure

11:

Process Flow for Discussion Board Module

Discussion Board

DoT

CCA

TSP

Start

Start Discussion and select participant type Internal or Including TSP

Start Discussion and select participant type Internal or Including TSP

Start Discussion, this discussion will open for all type of

user

Search discussion/ Reply on discussion



End


Page 130 of 182

DoT/CCA Creator User

Module Discussion Board


Introduction This will be used by DoT/CCA user to initiate the discussion based on the category selected OR redirected from “initiate discussion” button in Knowledge Bank module.

Preconditions DoT/CCA User should be registered in the system.



2. User will now click on the Discussion Board Module. 3. User will select the discussion topic category (in case category is not listed he

will select other and specify the category in a text box). OR

In case User is redirected from Knowledge Bank module, Discussion category and reference will be auto populated from the same.

4. User will input the discussion/clarification/information inputs in a text box. 5. User can choose the discussion participants by clicking the radio buttons from

“Internal” or “all including TSP”. 6. User will click on “submit” the discussion points.

Data Fields Selection Criteria o Discussion Categories

Exceptions By default this discussion created by DoT/CCA creator user will only be “Internal” (for Government users only).

References Document

Post Conditions All published discussion threads will be visible to DoT/CCA Responder user.

DoT/CCA Responder User



Introduction This will be used by DoT/CCA users to respond to the discussion threads based on the category selected.

Preconditions DoT/CCA User should be registered in the system.



2. User will now click on the Discussion Board Module. 3. User will select the discussion topic category currently available (having the

discussion threads). 4. By default discussion threads will be sorted from latest created date. 5. User will input the discussion/clarification/information inputs/comments in

“comment” text box.


Page 131 of 182

6. User will click on “submit” the discussion reply.


Exceptions

References Document

Post Conditions All replies on discussion threads will be visible to DoT/CCA Responder and DoT/CCA Creator user.

TSP Creator User



Introduction This will be used by TSP user to initiate the discussion based on the category selected OR redirected from “initiate discussion” button in Knowledge Bank module.

Preconditions TSP User should be registered in the system.



2. User will now click on the Discussion Board Module. 3. User will select the discussion topic category (in case category is not listed he

will select other and specify the category in a text box). OR

In case User is redirected from Knowledge Bank module, Discussion category and reference will be auto populated from the same.

4. User will input the discussion/clarification/information inputs in a text box. 5. User will click on “submit” the discussion points.


Exceptions By default this discussion created by TSP creator user will be visible to all the users (DoT/CCA users and all other TSPs as well) with contribute access.

References Document

Post Conditions All published discussion threads will be visible to DoT/CCA Responder and TSP Responder users.

TSP Responder User



Introduction This will be used by TSP users to respond to the discussion threads based on the category selected.



Page 132 of 182



2. User will now click on the Discussion Board Module. 3. User will select the discussion topic category currently available (having the

discussion threads). 4. By default discussion threads will be sorted from latest created date. 5. User will input the discussion/clarification/information inputs/comments in

“comment” text box. 6. User will click on “submit” the discussion reply.


Exceptions

References Document

Post Conditions All replies on discussion threads will be visible to all users.


Page 133 of 182

3.2.13 Grievance Module

Grievance modules provides an online facility to the TSP to raise and follow the status of the

grievances/complaints in the system. Using this module, grievance can be submitted by the TSP

user. While creating the grievance user needs to select the “For Action” and “For Information”

user for that grievance. Grievance will be visible in both type of user, however user who has

selected as “for Action” can only respond on grievance with status and remark and forward the

same to respective owner with “for information” and “for action”. Complete trail of grievance

will forward at the time of forwarding of grievance.

The sub-modules under Grievance modules are shown in the table below:


Grievance DoT, CCA, TSP


Page 134 of 182

Figure 12: Process Flow for Grievance Module

GrievanceTS

PD

oT/C

CA

Start

Submit Grievance with category and select For

Action and For Information

Display For Action and For Information

Grievance

Respond on For Action Grievance with remark and

status

Forward the grievance to respective

owner

End


Page 135 of 182

TSP User

Module Grievances


Introduction This module will be used by TSP user to lodge the Grievances against SUC rate, LF Calculation, Demand Notice, Show Cause Notice or any general/miscellaneous issue.




2. User will now click on the Grievances Module. 3. User will select the intended responder (CCA or DoT). 4. User will select the Grievance category (in case category is not listed he will

select General/Miscellaneous and specify the same in a text box). 5. User will input the Grievance details in a text box. 6. User can upload the Grievance document in pdf format. 7. User will click on “submit” the Grievance.

Data Fields Selection Criteria o SUC rate o LF Calculation o Policy Related o Presumptive AGR o Minimum AGR o Bid Amount o Demand Notice o Show Cause Notice/Objection Sheet o General/Miscellaneous

Exceptions

References Document

Post Conditions Post submitting the Grievance this will go the in intended participant’s dashboard.

By default each Grievance will go to DoT as an FYI in dashboard.

CCA User

Module Grievances


Introduction This module will be used by CCA user to reply on the Grievances raised by TSPs for SUC rate, LF Calculation, Demand Notice, Show Cause Notice or any general/miscellaneous issue.

Preconditions CCA User should be registered in the system.

Grievance should already be raised by the TSP user or forwarded by DoT or any other CCA.


Page 136 of 182

Actor Involved CCA User


2. User will now click on the Grievances Module or Dashboard. 3. User will see all the Grievances, documents and act accordingly (Reply,

Comment and status update as Open or Closed). Or

User can also “forward” the Grievance to DoT/respective CCA for further action.

Data Fields Selection Criteria o SUC rate o LF Calculation o Demand Notice o Show Cause Notice o General/Miscellaneous

Exceptions

References Document

Post Conditions Post replying the Grievance and Alert will go to the TSP and comment will be visible to all users (CCA/DoT/TSP).

If CCA is forwarding the Grievance to DoT or respective CCA, this will go to their respective Dashboard and a notification will be sent to the TSP, respective CCA and DoT for the same.

DoT User

Module Grievances


Introduction This module will be used by DoT user to reply on the Grievances raised by TSPs for SUC rate, LF Calculation, Demand Notice, Show Cause Notice or any general/miscellaneous issue.

Preconditions DoT User should be registered in the system.

Grievance should already be raised by the TSP user or forwarded by CCA.

Actor Involved DoT User


2. User will now click on the Grievances Module or Dashboard. 3. User will see all the Grievances, documents and act accordingly (Reply,

Comment and status update as Open or Closed). Or

User can also “forward” the Grievance to respective CCA for further action.

Data Fields Selection Criteria o SUC rate o LF Calculation


Page 137 of 182

o Demand Notice o Show Cause Notice o General/Miscellaneous

Exceptions

References Document

Post Conditions Post replying the Grievance and notification will go to the TSP and comment and status will be visible to all users (CCA/DoT/TSP).

If DoT is forwarding the Grievance to respective CCA, this will go to their respective Dashboard and a notification will be sent to the TSP and respective CCA for the same.


Page 138 of 182

3.2.14 Customer Acquisition Form/ Electromagnetic Field Radiation (CAF/EMR)

Customer Acquisition Form/ Electromagnetic Field Radiation module provide the DoT/CCA user

to add the CAF/EMR penalty notice issued by term cell. DoT user will add the notice in “Add

notice” of “CAF/EMR” section. Once added in the system the TSP can view the notice and can

make payment against the penalty amount imposed on them using online payment gateway on

RMS. System will provide and option to TSP to make part payment (in the form of instalment) of

the penalty imposed on them. As per TSP action carried out by TSP the status of Notice will get

changed from pending for payment, paid or partially paid. TSP/DoT/CCA can view all the notices

with their status.

The sub-modules under Customer Application Form/ Electromagnetic Field Radiation module are

shown in the table below:

Module Sub-Module User

CAF/EMR Add Notice DoT

Manage Notice DoT, CCA

My Notice TSP


Page 139 of 182

CAF/EMR

DoT

/CC

ATS

P

StartCAF/EMR Notice

ReceivedSend CAF/EMR Notice to TSP

CAF/EMR Notice Received

Make Payment End

Payment Gateway

Payment Acknoweldge

ment

Term Cell CAF/EMR Notice

Figure 13: Process Flow for CAF/EMR Module


Page 140 of 182

DoT users o Add Notice

Module CAF/EMR

Sub Module Add Notice


Introduction This will be used by DoT/CCA user to add the CAF/EMR notice in the system.


CAF/EMR notice must be issued by Term cell to operator.



2. User will now click on the CAF/EMR>Add Notice. 3. User will be able to feed the detail of CAF/EMR notice. 4. User select and enters the circle, notice letter no, notice date, name of

operator, license number, category of penalty, Amount demanded, due date and remarks. User can preview and edit the Notice before uploading it. Scanned copy of notice may be uploaded as well.

5. User can preview and edit the Notice before sending to operator.

Data Fields Selection criteria o Category o Date o Due Date o Operator o Circle



There will be a provision of revision of an earlier notice by a future notice

which will be result in the reduction/increase of amount demanded.

References Document

Post Conditions Submitted Notice will be sent to the operator for Action and respective CCA for Information, Notice will visible in CAF/EMR section.

o Manage Notices

Module CAF/EMR

Sub Module Manage Notices


Introduction This will be used by DoT user to View the CAF/EMR Notices.

Preconditions DoT user should be registered in the system.

CAF/EMR notice must be issued, to access this sections.



2. User will now click on the CAF/EMR>Manage Notices.


Page 141 of 182

3. On this page all the issued notices will display, user can select any notice to view the status of notice like paid or partially paid with amount or pending with notice description.

Data Fields

Exceptions User will be able to edit the amount of demand notice.

References Document

Post Conditions User can view details of the Notice issued

TSP users o My Notice

Module CAF/EMR

Sub Module My Notices


Introduction This will be used by TSP user to view the CAF/EMR notice and submit the penalty as per notice.

Preconditions TSP user should be registered in the system

CAF/EMR notice must be issued by DoT for the TSP



2. User will now click on the CAF/EMR >My Notices. 3. On this page all the notices will list with status like need to respond, partially

paid and fully paid. 4. User can open any notice to view and user can pay the amount directly from

notice detail page. 5. User can have the facility to edit the payment amount. So that user can pay

the notice amount in installments. 6. Payment will be made through Bharatkosh as integrated payment gateway.

Data Fields


References Document

Post Conditions Status against the Notice shall get update in system.

CCA users o Notice

Module CAF/EMR

Sub Module Notices


Introduction This will be used by CCA user to view the CAF/EMR Notices.


CAF/EMR notice must be issued, to access this sections.



Page 142 of 182


2. User will now click on the CAF/EMR> Notices. 3. On this page all the issued notices will be display, user can select any notice

to view the status of notice like paid or partially paid with amount or pending with notice description.

Data Fields

Exceptions

References Document

Post Conditions CCA User can view the status of the notice


Page 143 of 182

3.2.15 Budget

This module will be used to feed in the budgetary revenue estimates (BE) for next financial

year and revised revenue estimates (RE) for current financial year. LFA and WPF wings will

feed the BE & RE for License Fee and Spectrum usage charges respectively. This data will be

used for MIS and Dashboard to see if LFA/WPF progress in terms of achieving the revenue

targets.

The sub-modules under Budget module are shown in the table below:

SUB MODULES IN BUDGET MODULE Module Sub-Module Sub Sub-Module Users

Budget LF DoT User (LFA)

SUC DoT User (WPF)

Budget for LF

Module Budget

Sub Module LF


Introduction This will be used by DoT user (LFA) feed in the BE & RE in the system.




2. User (LFP) will now click on the Budget module. 3. User (LFP) will now select the applicable Financial year separately for BE and RE. 4. User (LFP) will fill the inputs boxes for Budgetary revenue estimates (for next

Financial year) and Revised revenue estimates (for current Financial year) 5. User (LFP) will click on “Submit” with all the submitted information.

Data Fields Input fields o BE o RE

Selection Criteria o Applicable Financial year

Exceptions

References Document

Post Conditions BE & RE data will be used for MIS and Dashboard to see if LFA progress in terms of achieving the revenue targets.

Budget for SUC

Module Budget

Sub Module SUC


Introduction This will be used by DoT user (WPF) feed in the BE & RE in the system.


Page 144 of 182

Preconditions DoT user (WPF) should be registered in the system.

Actor Involved DoT user (WPF)


2. User (WPF) will now click on the Budget module. 3. User (WPF) will now select the applicable Financial year separately for BE and

RE. 4. User (WPF) will fill the inputs boxes for Budgetary revenue estimates (for next

Financial year) and Revised revenue estimates (for current Financial year) 5. User (LFP) will click on “Submit” with all the submitted information.

Data Fields Input fields o BE o RE

Selection Criteria o Applicable Financial year

Exceptions

References Document

Post Conditions BE & RE data will be used for MIS and Dashboard to see if WPF progress in terms of achieving the revenue targets.


Page 145 of 182

4.0 Technical Requirement Specifications

Technical specifications provided here are the set of requirements that the proposed RMS

must meet. This document provides information to the SI on business requirements, various

standards & guidelines, and the best practices, and is an essential guide for defining a

proposed system and ensuring mutual understanding among key stakeholders.

All the technical specifications provided in this section are minimum and have been provided

for immediate reference only.

All the software (if any) along with proposed RMS shall initially be supplied with a 5 (five)

years comprehensive on-site OEM warranty/ support. Also, if the contract period is extended,

then bidder must ensure that all the supplied software OEM warranty, service and support,

subscription is also extended for the same period.

4.1 Development and Deployment

a) Development of RMS shall be based on the approved Software Requirement

Specifications (SRS) and Software Design Specifications (SDS).

b) Agile standard development methodology should be adopted for the development of

RMS.

c) The RMS shall support all popular/ common web browsers i.e. Chrome, Mozilla, Internet

Explorer, Apple Safari.

d) The RMS shall comply with the guidelines issued by the Govt. of India for the development

of the government websites/ portal/ web application i.e. GIGW

4.2 System Architecture

a) All the modules/ components of the proposed RMS should be deployed in centralized

manner/ platform.

b) The system architecture needs to be designed in a manner that will based on loosely

coupled components making it easy to extend.

c) The system should allow addition of more features/ sub-modules or more users in any

module as and when required, without affecting the performance of other functioning

modules; which should seamlessly integrate into the core system.

d) The system should support customization to meet the project requirements. In case need

for customization arises, the same should be done in the form of add-ons and routines/

patches that can be plugged/ unplugged from the base software package as the situation

arises.


Page 146 of 182

e) The system should provide facility for 'single point data entry at source' and fully

integrated, unified and interfaced so that there are no redundancies.

f) The system should have real-time data update among modules. It should have the ability

to have an update occur in one module and be immediately available to all other modules

of the system even among geographically dispersed sites.

g) The system should support clustering and high availability.

h) The integration methodology should be based on REST/ SOAP/ XINS and Web enabled

services technologies.

SMS Service

Provider

Payment

Gateway

Service

Provider

E-Sign

Service

Provider

User s

eMail

Account

Internet

Firewall

Web Server

App Server

Database

Sever

Web Server

App Server

Database

Server

Server

Database

Server

Internet

Router Load Balancer

Payment Gateway

E-Sign APISMS Gateway

User s Mobile

Confirmation/

Communication

On Mobile

eMail Server

Integration

With

eMail

Gateway

eMail Server

Figure 1: System Architecture

4.3 Installation/ Upgrade/ Enhancement

a) The RMS should facilitate seamless upgrades (deployment of patches/ new version)

without any adverse impact on the system and its components.

b) The SI should provide notification and patches for system enhancements and fixes to RMS

after implementation on a proactive basis.

c) The system should have facility to maintain versions with changes/ modifications made in

each release.


Page 147 of 182

4.4 Import/ Export Facility

a) The system should support the upload and download of the Adobe acrobat files, MS Excel

files, and MS Word files into/ from the system.

b) Any other file-format as required by DoT in due course of time.

4.5 Integration

a) The system should be fully integrated across modules and functional areas.

b) The system should be fully compatible for data exchange/ enable data migration with

existing/ legacy system(s) being used by DoT. The exchanged/ migrated data should be

available permanently in the RMS for daily use of the users.

c) The RMS should be integrated with:

a. SMS gateway, e-Mail server for sending SMS/ e-Mail alerts/ reminders/

notifications etc.

b. Bharatkosh/ PFMS/ Payment Gateway for facilitating the online payments

c. e-Sign platform (Aadhaar based) to facilitate user to digitally sign the document

d. And any other platform/ facility/ system identified by DoT during the course of

implementation or by SI during requirement study.

d) SI shall be responsible for assisting the DoT in:

a. Identification and integration of e-Sign, Payment Gateway, PFMS, Bharatkosh,

Email Gateway, SMS Service Provider(s) and any other service providers identified

by DoT.

b. Signing of contract with the service provider(s)

c. Resolving any issue/problem arises in the project, pertaining to the services

provided by the service provider(s).

e) DoT will bear the setup and running/operational cost of e-Sign, payment gateway and

SMS gateway services.

4.6 Workflow Integration Approach

a) The RMS should be able to support/ configure complete workflow required for successful

coverage of various business processes of DoT. It should allow designing of workflow with

the ability to map with the DoT’s business rules and process flows, and should also enable

to set alerts and triggers without programming.


Page 148 of 182

b) The RMS should support creation of secondary workflows as well which should be fully

integrated with the primary workflows.

c) RMS should automatically raise alerts, messaging, notifications, emails etc. across

functional areas/ modules and concerned stakeholders based on the various deadlines/

timelines assigned for particular task or if an attempt is made to amend the entries already

entered in the system.

d) Workflow management/ control must be an integrated part of the application. The RMS

should allow authorized user to configure the workflow as per the guidelines of the

Department for handling the processes successfully.

e) The workflow management/ control should provide consistent method of defining

business rules, process flows for all DoT/ CCA offices and concerned stakeholders.

f) Mandatory approval should be uploaded in the RMS prior to making any changes in the

workflow. Audit trail of the modifications should be maintained in the system.

g) The RMS shall periodically and automatically save the data entered by the user into the

system during a live session and shall make the data available to the user as intermediate

save even after expiry of the session.

h) RMS should allow devising of simple or complex rules to suite the DoT’s business

requirements and also the requirements specific to certain stakeholder(s). The rules

should be stored in a central repository and the same must be shared across all business

processes.

i) No programming/ coding should be required by the authorized user of DoT when

configuring the workflow or making any change in the workflow. If there is any change in

the personnel or approving authorities, delegation of power/ authority or a change in DoT

policies, the workflow should be updated without any programming and should be

applied on live transactions.

4.7 Internet Enabled

a) The RMS should support access over internet with secured connectivity.

b) The system should have feature of storing and maintaining the information in local

system’s caches to minimize the information transferred over the internet.

c) The system should be scalable and flexible enough to provide access and information to

all the users from the different functions/ departments/ offices of DoT and other key

stakeholders.

d) The system should support all TCP/ IP/ SMTP or any other related protocols.


Page 149 of 182

4.8 Scalability

a) The system should be scalable to handle an average of 200 concurrent users of different

access type i.e. DoT and other key stakeholders, and should support high volume of data

upload, without compromising response time or efficiency of the system. System should

also be capable of handling peak load.

b) The system data must be kept on storage media with high tolerance of failure/ accident/

natural calamity.

c) Auto-switching of failover to other available/ backup server should be supported in case

of server failure.

d) A load balancer should be deployed to optimize resource use, maximize throughput,

minimize response time, and avoid overload of any single resource.

4.9 Security

a) The system must have proper security and maintenance facility with access control

features for controlling the access rights over the system and over the various functions/

features available for different types of users.

b) Unauthorized access should be restricted and only authorized users with valid login-id and

password to should be allowed to access the legitimate features i.e. access to data file,

module, screen, data table, record, field, etc. If required, two levels of authentication may

be provided for accessing certain features/ screens/ transactions.

c) To maintain information security during transaction the developed system should support

both HTTP and HTTPS, all internal data communication shall be done through encrypted

mode using latest version of TLS (Transport Layer Security)/ SSL (Secure Socket Layer).

d) SI shall follow the eSAFE (eGovernance Security Assurance Framework) Guidelines for

Implementation of Security Controls issued by the Ministry of Electronics and Information

Technology (MeitY), Government of India.

e) Solution shall apply security measures like ‘captcha’ at the time of login by user to

determine whether the user is human or not, and to avoid unauthorized access by Other

Software i.e. Bots, DDoS etc.

f) The system should have a capability to assign activities to roles, and map roles to users

and provide role based access to users.

g) The system should notify security/ system administrator regarding unauthorized access

or attempt to access and record in a log with reporting mechanism.

h) The system should have session management features which should automatic log-off the

user if there is no activity for specified time period.


Page 150 of 182

i) The system should have the ability to assign validation on specific fields based on entries

in the data validation reference file.

4.10 System Control and Audit

a) The system should maintain audit trails, audit logs and transaction logs (what, when, who

has changed).

b) The application shall log all the actions done by individual users with user name, date and

time and the administrator shall be able to generate detailed audit logs and history of the

process instance.

c) It should enable availability of user wise online audit trails/ logs which should be archived

based on user, date, time etc. as part of audit records keeping.

d) All the edited and deleted (if any) records should be traceable and copy of all records

should be kept in the system and which should be available with MIS reporting of the

same.

4.11 Data Backup/ Data Archival/ Restore

a) The system should be able to archive data, based on user specified parameters (i.e. data

range) and restore archival data for online use whenever required.

b) Backup and recovery of all the system software, application software, database, etc. as

per GoI policy (Guidelines for Government Departments for Adoption/ Procurement of

Cloud Services).

c) The system should provide features to schedule backup/ restore operations. The SI should

ensure that activity such as proper Data Backup, Data Restoration, and Data

Synchronization at Disaster Recovery site are tested and implemented properly as per the

standard norms.

d) In case required, the system should have the ability to run multiple backup tasks in

parallel.

e) The system should produce a report for each backup/ restore activity.

f) The system should support direct backup of data from one machine to another/ from

server to back tapes/ CDs/ Storage Area Network etc.

g) The system should have provision to keep data on storage media with high tolerance of

failure.


Page 151 of 182

h) The system should allow recovery of data in case of hardware/ software failure and data

corruption. It should be able to perform recovery to a point of time, to known backup

database.

i) The SI shall ensure that the CSP carryout mock disaster recovery and data restoration drills

and should submit the report to DoT as explained in detail at clause 5.18.

4.12 Data Migration

a) SI is expected to carryout independent exercise for assessment of data source, data

format, and data fields and number of records before data migration.

b) The SI should develop a migration strategy for migration of existing data into the database

of new system.

c) SI should ensure proper validations, tracking and reporting and correction procedures for

migration of data from the existing database/ any other format shared by the DoT.

d) Ensuring correct migration of data shall be the responsibility of SI.

e) Indicative list of master and transaction records which need to be migrated is as under:

Sr. No. Detail Nos.

1 Total tables 140

2 Master tables 40

3 Transaction tables 100

4.13 User Interface

a) The system should have a user friendly, interactive and responsive graphical user interface

(GUI).

b) The online form should have mandatory fields marked out clearly. The system should not

allow submission of the form without completing the mandatory fields.

c) RMS must support uploading of scanned supporting documents. There must be a check

for ensuring upload of all mandatory documents. System should checking for file type and

size of files also.

d) The GUI should be browser based and user friendly. There should be sufficient validation

checks in the system for validating the data formats etc. It should provide safeguards to

prevent damage to data from user errors, simultaneous updates, module unavailability or

system failures.


Page 152 of 182

e) It should have provision for warning and alert messages in case of validation failure,

incomplete data etc.

f) It should have facility to display confirmation/ warning windows for deletes, changes etc.

g) The system should provide consistent screen layouts and access methods across all

modules so that they look and behave the same.

h) The system should provide various reports/ MIS in graphical and tabular views along with

facility to drill down to navigate to the next levels of details and so on.

i) The user interface shall give flexibility to toggle between graphical and tabular views, and

tile different views in the same interface.

j) User specific/ customized dashboard should allow authorized user to take action on

pending activities in a secured manner in a system seamlessly integrated with other

modules of the application. Submission of every activity in the system should suitably

update database on real-time basis.

4.14 Enterprise Management System

a) In addition to the hardware and software requirements of this implementation, SI shall

also implement and maintain an Enterprise Management System (EMS). The EMS should

be able to support the proposed hardware and software components at Cloud Platform

and DRC over the tenure of the contract. The EMS should be capable of providing early

warning signals to the DoT/ SI on the solution performance issues, and future

infrastructure capacity augmentation.

b) SI is required to supply, customize, implement, rollout, test, train, and maintain the EMS

application and hardware at the Cloud Platform and DRC as per the requirements of this

RFP. Bidder is expected to provide and implement an EMS encompassing the following

functions:

i. Configuration Management

ii. Fault Management

iii. Incident, Problem and Change Management

iv. Asset Management

v. Remote Control

vi. SLA management & monitoring

vii. Performance management

viii. Monitoring Backup and Management


Page 153 of 182

ix. Event Management

x. Server, storage and other infrastructure management

xi. Monitor network components of the LAN & WAN

xii. Network Link Monitoring

xiii. Other modules as required by SI to meet the requirements of the RFP

xiv. Also the EMS solution should be extended to any new device which will be added

by in future to fulfil the project requirements.

c) SI shall be required to submit EMS generated SLA compliance report on monthly and

quarterly basis as part of monthly and quarterly compliance report to DoT

4.15 Operations

a) The system should be able to generate user friendly Graphical Reports, Trends,

Dashboards, etc. in customised and standard form.

b) The system should provide error logging facility. The system should have ability to redo/

rollback a transaction after recovery from software/ hardware failure to ensure data

integrity.

c) The system should restrict users from deleting data directly unless authorized to do so. In

case of authorized users also, only soft delete facility would be available.

d) The system should allow multiple users to access the same module simultaneously.

e) The system should display data according to user profile/ access rights.

f) The system should provide functionality to users in generating reports on their own

without having knowledge about technical programming.

g) Any document or report should be previewed before printing.

h) The system should notify users automatically after report is generated.

i) The system should have a mechanism for resetting and emailing the new password to the

users registered email ID, in case one forgets his password

j) The system should provide facility to block or unblock any user access


Page 154 of 182

5.0 Schedule of Services

This schedule of services sets out precise list of services that the SI will be providing as part of

this project for meeting the project goals. The schedule of services also contains various

deliverables, schedule, reports and end product details that are to be provided by the SI as

part of this project.

SI will be required to provide quality and timely services to DoT for the successful design,

development and implementation of RMS. All the activities performed by the SI during

different phases of the project shall be closely monitored by DoT. The SI is strongly advised

to carefully read the Schedule of Services and quote accordingly.

The broad schedule of services for the SI during the contract period would include (but not

limited to):

a) Performing a system requirement study and prepare SRS & SDS

b) Design and Development of RMS (application software)

c) Migration of data from existing (old) RMS to the proposed (new) RMS

d) Application Testing i.e. unit testing, integration testing, system testing, load testing

e) User Acceptance Testing (UAT)

f) Commissioning of RMS and Warranty

g) Go-Live of RMS

h) Training & Capacity Building

i) Maintenance of RMS

5.1 Business Process Analysis

SI shall assess the existing business processes of DoT to supplement the understanding

gathered from the high level business processes included in the FRS of this RFP document.

The selected bidder’s objective shall be to develop comprehensive solution to support all the

business needs of DoT in detailed manner along with other functional requirements as stated

in the RFP document.

5.2 System Requirement Study and Preparation of SRS & SDS

a) Although an indicative, FRS, TRS and Schedule of Service have been provided in the RFP

document, the SI shall carryout an independent and detailed assessment study of

functional, technical and operational requirements of DoT.


Page 155 of 182

b) The SI is responsible to carry out an independent system study at DoT Head Office and at

least 4 Field Offices of DoT i.e. CCA offices, to thoroughly understand the function and

operational process of department by:

i. Interacting with concerned department’s officials and understanding the entire

setup, process flows and business logics involved

ii. Reviewing the existing systems, process, and existing application software

iii. Detailing various use cases scenario

iv. Understanding/ assessment of data migration requirement and strategy

v. Understanding/ assessment of data inputs and outputs requirements by

collecting all input forms, registers and report formats of DoT

vi. Understanding/ assessment of existing applications from perspective of

integration with proposed application

c) Based on the above study, preparing the System Requirement Specifications (SRS) as per

the latest version of the IEEE Standard for drafting the SRS, and obtaining Sign-off of SRS

from DoT.

d) Based on the approved SRS, preparing the Software Design Specification (SDS), based on

the principles of Enterprise Architecture (EA).

e) Preparation and submission of Project Implementation Plan in compliance to the project

schedule provided in the RFP document.

5.3 Design and Development of RMS (Application Software)

a) Development of the departmental RMS application based on the approved SRS and SDS.

b) Agile standard development methodology should be adopted for Software Development,

covering the entire SDLC (Software Development Life Cycle).

c) The SI shall be responsible for development a feature rich system which shall comply with

the guidelines issued by the Govt. of India for the development of the government

websites/portal i.e. GIGW and egovstandards.gov.in.

d) The development should be based upon automated workflow system & open standards.

e) SI may use any workflow management software for building all the required Workflow

features in the application software. All the applicable licenses (if any and as applicable

time-to-time), shall be provided by SI.

f) Identify and Integrate with all internal and external systems and services as per the

requirement of the proposed system.

g) The RMS must have integrated security/ monitoring features with the following:

i. Definition of Roles/user group/user type and Users

http://egovstandards.gov.in/


Page 156 of 182

ii. Define Role-wise add/ edit/ view/ delete rights for each Entry Form/ Report in all

modules

iii. Digital Time and User Stamping of each transaction

iv. Online monitoring of the User activities using user activity logs

h) The information and forms collected from various sources and the development of the

application software will have to be converted into appropriate electronic open standard

format(s) as mentioned in “Interoperability Framework for E-Governance in India-Draft

v1.0 issued by Ministry of Electronics & Information Technology (MeitY), Government of

India.

i) The RMS must facilitate the department, from the day one, to send SMSs and emails to

the concerned stakeholders/ users.

j) Access to specific elements of the application. The audit trail should provide a facility to

trace the path of changes in application software.

k) The SI will also be responsible for hosting the system on cloud platform (PaaS model) as

explained in detail at clause 5.8 of this section.

l) The SI would also ensure that the hosting services should be portable to another vendor

without any changes to hosting environment.

m) Configuring the specific system modules and third party applications.

n) Carryout testing of the RMS including unit testing, integration testing, system testing, etc.

along with User/ Final Acceptance Testing and share test reports.

o) Conducting various testing including Load Testing, Performance Testing etc. and making

necessary changes to the proposed IT system based on such test results. SI shall share

such test reports.

p) All tools required for load testing and performance testing should be standard. In case any

third Party tools are required, the same are to be arranged by the SI for this project on its

own cost.

q) Any other work required to complete the proposed IT system as per requirement of DoT.

r) The SI is required to provide detailed profile of the team proposed for application

development phase in the technical bid. A format for submitting the profiles of the

proposed team is provided at Annexure-V of Volume-II.


Page 157 of 182

Figure 2: Web Application Architecture

5.4 Integration of RMS

a) The SI will be responsible for integration of RMS with e-Sign platform (Aadhaar based) to

facilitate an e-Sign user to digitally sign a document. The recurring transaction charges, if

any, shall be borne by DoT.

b) The SI will be responsible for integration of RMS with the Bharatkosh/ PFMS/ Payment

Gateway for enabling online payments. The recurring transaction charges, if any, shall be

borne by DoT.

c) The SI will be responsible for integrating the RMS with the GoI provided SMS Gateway

(MSDG)/ or the SMS gateways/ email gateway prescribed by the DoT. The RMS must

facilitate, from the day one, in automatically sending the required details/ information

through SMS & email to the designated officers of the department and other

stakeholders. The recurring SMS and email charges, if any, shall be borne by DoT.

d) Identify the data/ services which is to be exchanged between the RMS and the other

internal/ external systems and DoT website.


Page 158 of 182

e) Identify integration touch points for ensuring seamless integration with these internal/

external systems and DoT website.

5.5 Data Migration

a) The SI shall be responsible to carryout Data collection, data preparation, data validation,

data cleansing/ correction and data migration of all kinds of master data and transaction

data required for successful implementation and operationalization of the proposed

system.

b) Carryout data migration from the legacy systems and other data presently available with

DoT in electronic format so as to ensure for successful implementation and

operationalization of the proposed system.

c) The SI shall develop an effective data migration strategy for migration of data from the

existing/ legacy application software and from other available sources to the database so

as to ensure for successful implementation and operationalization of the proposed

system.

d) SI shall ensure correct migration of data.

5.6 Testing of RMS

a) Preparation and submission of detailed testing plan and strategy.

b) Prepare and share various use cases and scenarios.

c) Performing unit testing, integration testing, system testing, load testing and security

testing. Security testing (safe to host audit) shall be carried out by CERT-In empaneled

agencies.

d) Conducting testing of various components/ modules of the RMS, as per the latest version

of the IEEE 730 standards. The bidder shall be required to share the testing documents

and standards with the designated software testing team, wherever applicable/ required.

e) Taking corrective steps based on the testing reports i.e. rectifying the software issues/

bugs reported during the testing.

f) The test results along with details/ report of action taken shall be submitted to DoT.

g) All the testing and related activities will be carried out by the SI at its own expense and at

no additional cost to DoT.

5.7 User Acceptance Testing (UAT)

a) Preparation and submission of detailed UAT plans.


Page 159 of 182

b) Submit System Test Cases with results with DoT for review and verification at the time of

UAT.

c) Prepare and submit various use cases, scenarios along with results with DoT for carrying

out UAT.

d) The SI shall conduct orientation workshop(s) for the users before handing over the

application to DoT for UAT.

e) The orientation workshop shall be conducted at the location(s) prescribed by DoT.

f) UAT shall be done jointly by DoT, SI and PMU (appointed by DoT). SI shall assist DoT and

PMU in carrying out UAT of RMS.

g) Rectifying the application software (RMS) issues/ bugs reported during the testing upto

the satisfaction level of DoT.

h) DoT may reject any module/ system or any part thereof that fails to pass any test or do

not conform to the specifications/ DoT requirements. The SI shall rectify such rejected

item/ module or parts thereof or make alterations necessary to meet the specifications

and shall again perform the testing, all these activities shall be performed at no additional

cost to DoT.

i) The SI will conduct User Acceptance Tests (UATs) to ascertain whether the proposed IT

system or any sub-system(s) is capable of meeting the functional and technical

requirement as per the RFP and Performance requirements.

j) DoT will provide full co-operation to the SI in conducting the UAT which shall be carried

out on the development server.

k) Final approval/ user acceptance of the application software shall be given by DoT after

successful implementation and testing. This is the responsibility of the SI to obtain the

UAT approval from the DoT.

l) All the costs towards testing and commissioning to be borne by the SI.

5.8 Commissioning of RMS and Warranty

a) Only after the successful completion of UAT and Security Testing from the CERT-In

empaneled agencies, the application software shall be deployed on the production

environment.

b) The SI shall be responsible for installation, integration, testing and commissioning of the

hosting environment on the cloud platform, along with all the allied equipment, software,

updates, patches etc. at the production environment as and when needed.


Page 160 of 182

c) Only after successful deployment of RMS on production environment, RMS would be

deemed to have been commissioned.

5.8.1 Hosting Requirements:

i. SI shall be responsible for hosting the RMS on the cloud platform on Platform as

a Service (PaaS) model. The hosting of the application should be carried out in

atleast Tier III data centre within India. SI shall be required to submit all necessary

data centre related certifications like tier certificate, ISO 27001 certificate etc.,

along with its technical proposal.

ii. SI will be responsible for installation of all the software required for the successful

hosting of the RMS.

iii. In case there is any requirement of application specific server at any point of time,

the SI shall be required to provide the same also without any additional cost to

DoT.

iv. Cloud platforms should provide sufficient capacity in terms of data processing,

data storage and network bandwidth to handle the overall load and traffic coming

to the RMS without compromising the overall performance of the system. The

cloud service should provide dedicated IP, dedicated SSL/ TLS certificate.

v. It will be the responsibility of SI to prepare the specification for cloud platform i.e.

CPUs, RAM, storage, required software, other equipment and the network

requirements for running the RMS efficiently. Whatever infrastructure is needed

shall be clearly accounted in the bid document.

vi. The SI should have solutions to route Internet users seamlessly from Cloud

Platform to DR site (if required).

vii. Appropriate redundancies shall be built in IT infrastructure as per standard

industry practices. The SI shall inform DoT about the cost of hosting of RMS on

cloud platform and share the appropriate documentary proof. The cost should

also include the application hosting cost at Disaster Recovery (DR) site as well.

viii. The SI shall formulate an effective Back-up Strategy and Disaster Recovery Plan

and shall be responsible for implementing the same at the time of commissioning

of RMS.

ix. The SI shall also ensure that the hosting services should be portable to another

vendor without any changes to hosting environment.

x. It is mandated that the SI shall either host the RMS on its own cloud hosting

platform (at least Tier III) or go for the MeitY empaneled CSPs. In no case, SI shall


Page 161 of 182

host the application on cloud platform of any company which has a history of data

loss and security breaches.

xi. SI shall be configuring the DoT provided domain name on its servers.

5.8.2 Warranty

i. After the successful commissioning of the project, the one month warranty period

shall start.

ii. During warranty period the SI shall be responsible for

A. Update, modify, re-build, replace any module, feature of the application,

at SI’s sole cost, to keep the system free from any defect or deficiency in

any aspect that prevent the RMS and/or any of its sub-systems(s) from

fulfilling the functional or technical requirements.

B. During warranty period DoT may request SI, to make necessary changes in

the layout, colour schema, MIS reports format, input forms layout etc.

However, these changes shall be suggested keeping in view that it should

not transform in database schema. The selected bidder shall be

responsible to make these changes at no extra cost to DoT.

C. If the RMS or any of its sub-system cannot be used by user of such reasons,

the warranty period for the Project shall be extended by a period equal to

the period during which the RMS or any of its sub-system could not be used

by the Users because of such defect and/or making good of such default,

defect or deficiency.

5.9 Go-live of RMS

a) After the commissioning of RMS and successful completion of the warranty period, the

RMS would be declared as Go-Live and enter into AMC phase, and the SI would be issued

a Go-live certificate by DoT.

b) SI shall share all the passwords/ access rights/ addresses along with all relevant details of

the application/ server/ database/ hardware (if any) with DoT from the day of Go-live.

c) SI shall also handover complete, fully tested/ audited, bug free, final version of RMS

source code (in softcopy format) along with the signed hash of the final source code

printed on the SI letter head and complete details of technology and software (with

versions) used for the development of RMS.


Page 162 of 182

5.10 Annual Maintenance Contract (AMC) of RMS

a) The SI shall provide post implementation support for entire AMC period of five (5) years

that includes maintenance support, technical support, helpdesk support and

implementation and deployment of Change Request raised by DoT.

b) If any OEM is involved in the process, the SI shall arrange the support from OEM also for

the same period.

c) During the AMC phase the SI shall deploy sufficient manpower to ensure seamless

operation of the RMS system.

d) SI shall transfer the ownership of the RMS along with the latest version of source code i.e.

all software developed/ customized/ configured/ procured etc. and all the procured

licenses and support related documents in the name of Department of

Telecommunications, Government of India.

e) Post completion of the 5 years of maintenance period, DoT in its own discretion, may

extend the maintenance contract for, one year at a time, on mutually agreed basis.

f) During AMC phase, DoT may request SI, to make necessary changes in the layout, colour

schema, content, MIS reports format, input forms layout etc. However, these changes

shall be suggested keeping in view that it should not impact the database schema. The

selected bidder shall be responsible to make these changes at no extra cost to DoT.

g) The SI shall be responsible to maintain version control and archives of source code,

content and database.

h) During entire AMC phase, the SI shall submit the detailed monthly compliance report

including system generated report from EMS and HMS in hard and softcopy format to DoT

within first calendar week of the next month, and on need basis as and when required by

the DoT. The final format of the report shall be finalized by the SI in due consultation with

DoT before start of warranty period.

5.10.1 Maintenance and Technical Support:

i. SI shall deploy a minimum of two (2) technical resources on fulltime basis at DoT for

the entire AMC period apart from other resources deployed during the AMC phase.

ii. These technical resources shall be responsible for providing maintenance and

technical support to DoT which includes carrying out small changes wherein the

total development effort requirement is upto 15 man-days apart from the routine

maintenance operations or bug fixing. The profiles of the technical resources shall

as following:

S. No. Resource Type Profile


Page 163 of 182

1. Software Developer Minimum 3 - 5 years of experience

2. GUI Developer / Software

Developer

Minimum 3 - 5 years of experience

iii. The SI is required to provide detailed profile of the team proposed for AMC in

technical bid.

iv. The SI shall make available and implement all upgrades of proposed RMS and related

tools during the AMC period including warranty period.

v. The SI shall be responsible for deploying additional manpower for smooth

functioning of the project and at no extra cost to DoT.

vi. The SI shall be responsible for (including following, but not limited to):

A. During the entire AMC period SI shall be responsible for handling all the issues/

problems faced by the users.

B. Installation of new versions/ software/ releases (including next generation

release) upgrades, bug fixes, functionality enhancements, patches to cater to

changes (including tax, legal, statutory and policy requirements), any

modification or enhancement to existing business processes, changes to

configurations, customizations, database administration, data back-up and

archiving, security and other technical assistance.

C. Overall administration, operations, monitoring, and maintenance, definitions/

patches/ updates/ service packs, backup, recovery, etc. of the deployed IT

Hardware and Software infrastructure at the cloud platform and to ensure the

desired uptime.

D. Overall monitoring of the deployed network bandwidth/ links so as to ensure

the desired uptime. In case of downtime/ link failure, reporting immediately

the same to the Broadband Service Provider (BSP) and tracking until the link is

restored and services are operational as required.

E. In the event of onsite deployed resource(s) leaving the project/ employment,

the same shall be immediately replaced with another resource of equivalent

minimum qualifications and experience. All such events should be notified to

the DoT well within time.

F. At no time, the provided manpower should be on leave or absent from the

duty without prior permission from the designated nodal officer of DoT. In case

of long term absence due to sickness, leave etc. the SI shall ensure

replacements and manning of all manpower posts by without any additional


Page 164 of 182

liabilities to DoT. Substitute will have to be provided by the SI against the staff

proceeding on leave/ or remaining absent and should be of equal or higher

qualifications/ experience.

5.10.2 Helpdesk Support

i. The SI shall setup an helpdesk at DoT headquarter with two (2) fulltime executive

for an initial period of at least 6 months from the day of go-live of RMS. The helpdesk

duration may be extended by the DoT on the need basis.

ii. SI shall be required to deploy helpdesk management system for the helpdesk call

management, logging and SLA reporting purpose. The SI shall submit the helpdesk

generated call log reports to designated nodal officer at the end of each month and,

as and when required by the DoT.

iii. The helpdesk system shall allow the users to create tickets for any problem/ issue

faced by them and same should be closed only by the user after the resolution of

the problem.

iv. Helpdesk staff shall escalate the problem to the Project Manager and maintain the

log/ status of the complaint in the online call log register.

v. The DoT will be providing a dedicated telephone line at the Helpdesk. The helpdesk

desk shall also have a dedicated email account, so that the end users could send

their queries and issues via email as well.

vi. The helpdesk shall be accessible with in DoT as well as Outside DoT via telephone

and e-mails.

vii. The helpdesk will be responsible for following:

A. Understanding the issues/ challenges faced by users.

B. If possible, guide user/ help user in taking corrective action/ helpdesk team to

take corrective action by visiting the site or by accessing the system remotely.

C. If problem is persisting/ helpdesk unable to take corrective action collect

required information and communicate the same to the technical team.

D. Follow-up with the technical team for resolution within prescribed time limit.

E. Inform user about the resolution of problem/ issue.

viii. The helpdesk should generally be accessible during prime working hrs. (9:00 AM to

6:00 PM) from Monday to Saturday (except Sundays and national holidays).

However, in special circumstances, DoT may request for the availability of helpdesk

at any point of time, and the SI shall ensure the availability of support persons as per

the requirement of DoT.


Page 165 of 182

ix. The SI shall be required to submit HMS generated compliance report on monthly

and quarterly basis as part of monthly and quarterly compliance report to DoT.

x. DoT will provide all necessary infrastructure to SI for setting up the helpdesk at DoT

headquarter.

5.10.3 Change Request

i. DoT may at any time, by a written order given to the SI, make changes in scope of

the work or schedule of services as specified in the RFP document.

ii. All changes outside the scope of work or Schedule of Services having financial

implications in terms of the overall cost/ time of the project, shall be undertaken by

the SI, only after securing the express consent of the DoT.

iii. While approving any change request, if required, DoT may ask the SI to deploy the

required resources on-site.

iv. The change request/ management procedure will follow the following steps:

A. Identification and documentation of the need for the change: The information

related to initiator, initiation date and details of change required and priority

of the change will be documented by DoT.

B. Analysis and evaluation of the Change Request: Impact of the change in terms

of the estimated effort, changed schedule, cost and the items impacted will be

analyzed and documented by the SI.

C. Approval or disapproval of the change request: DoT will approve or disapprove

the change requested including the additional payments (as per the quoted

man-month rate), after discussion with SI on the impact of the change on

schedule. Any change request where the total man-month effort requirement

is upto the 15 man-days shall not be considered as change request.

D. Implementation of the change: The change will be implemented in accordance

to the agreed cost, effort, and schedule by the SI.

E. Verification of the change: The change will be verified and tested by the DoT

on completion of implementation of change request prior to deployment on

the production server.

v. Any change request shall be dealt with in accordance with the Change Control

Schedule set out in Schedule II of Vol III of this RFP.

5.10.4 Man Days Bundle and Flexi Packages

I. In order to ensure a more flexible development and to avoid approval from senior

management each time, DoT is requesting bidders to provide an innovative cost offering


Page 166 of 182

to address the changes and updates to the system without the need for lengthy change

request and approval process considering the following principles:

A. Man days bundle/flexible package are considered only for additional

Services that are NOT provided as part of the original scope of this RFP.

B. Man days bundle/Flexible package payments occurs when specifically

agreed scope for man days bundle/ flexible package is deployed to

production and signed off. Payment amount for each scope is calculated

based on the effort agreed by DoT and SI.

C. The selected SI should consider that development of additional Services

includes the following, but not limited to Requirement gathering, Technical

development, testing and deployment.

D. The SI should provide consolidated man day rates for a bundle of 600 Man

days which may or may not be used by DoT during the contract period.

5.11 Documentation

a) Preparation of the documents like but not limited to, Software Requirement Specification

(SRS), screen layouts, Software Design Specifications (SDS), Change Management Plan,

Training Plan, Test Cases, Scenarios & Results, Software Code (softcopy), User Manuals,

Training manuals, Operations & Maintenance Manual, Administrator Manual, Security

Policy, etc. as per acceptable standards.

b) Updating all above mentioned documents time to time, specially whenever there is any

change, update in the RMS. Submit all the updated documents to DoT

c) Obtaining sign-off for all the documents from DoT.

d) Provide OEM documentation with every unit of the equipment supplied. The language of

the documentation should be in English. The technical documentation should include

illustrated catalogues/ reference manuals/ technical manuals and operation manuals.

5.12 Training and Capacity Building

Training of key stakeholders is essential for ensuring that the software developed is actually

put to use. Hence, the SI shall ensure a proper training to the designated end-users on the

ERP system so as to make them well conversant with the functionalities, features and

processes built in the proposed system.

a) Training Plan: The selected bidder shall provide comprehensive and detailed training plan

describing the proposed approach & methodology, calendar/ timelines, course contents,

course duration, training materials, training tools, training logistics, etc.


Page 167 of 182

b) The content of the training plan and schedule shall be prepared by the SI in consultation

with DoT at an appropriate time period. The SI shall submit the final document for

approval of DoT before initiating the training activity.

c) Training Overview: The training overview shall be provided to DoT’s Steering Committee

and PMU members (if proposed) before beginning of each training phase. SI shall

incorporate the changes suggested/ inputs provided by the DoT during the training

overview. The overview sessions will not be counted in total number of training sessions.

d) The selected bidder shall arrange separate training sessions for different categories of

participants in batches (Approx. Batch size: 25+ participants).

e) Training could have multiple sessions as per the need and requirement of the project/

application. Hence, the SI shall conduct Training Needs Analysis of all the concerned staff

and chalk out a systematic training plan. There should be sufficient number of trainers in

every training session for conducting the training program.

f) Re-training of the above staffs whenever significant changes are made in the RMS and/ or

personnel.

g) Assessment of Training Effectiveness: Evaluate effectiveness of training programs and

workshops by obtaining formal feedback from each participant after completion of each

training program/ workshop. The SI will be responsible for re-conducting the training of

the whole batch in case the average score is less than 70% and the additional cost of such

re-training sessions shall be borne by the SI.

h) The requisite training infrastructure like space, seats, projector with screen etc. shall be

provided by DoT in consultation of SI.

i) The training shall be organized by the SI wherein specialised logistics and supportive

facilities (if any), apart from the above mentioned facilities, should be arranged by the SI

only, and all associated cost shall be borne by the SI.

j) SI shall conduct training at the location(s) prescribed by DoT and each training session

shall be of 8 hours that shall include minimum 6 hrs of training.

k) The SI shall provide training material like handouts, user manual (role base), the language

of training manual shall be in English.

l) The training content and mode of delivery must be approved by DoT. Training material

should be provided in hard and soft copies both. The SI shall ensure that all the training

documentation in Hardcopy and Softcopy is in place (user training, operation procedures,

visual help-kit etc.) before beginning the each training session.


Page 168 of 182

m) The cost incurred on carrying out the training at prescribed location(s) shall be borne by

the SI which includes trainer’s and other support team member’s fees/ salary along with

all incidental expenses like travelling, lodging-boarding, local conveyance etc.

n) DoT will bear its own expenses related to travel and lodging of its personnel.

o) SI should also provide online help corner for the users and upload user manuals, self-

running demos, save and maintain FAQs online so that users can obtain system specific

technical/ functional help online as and when required. The system should also maintain

module-wise online user Feedback database.

p) SI shall need to provide the minimum of 40 desktop based training sessions across 4 zones.

5.13 Project Management

a) Co-ordinate all activities with the Program Management Unit (PMU)/ Steering committee

set-up by DoT.

b) Ensure timely delivery of all the deliverables related to proposed IT system.

c) Supervise and ensuring delivery, installation and commissioning of IT infrastructure as per

BOM supplied with the technical bid.

d) Co-ordinate among various stakeholders and other vendors.

e) Ensure that day to day issues related to the proposed IT system are handled and solved

immediately.

f) Monitor risk management related aspects and project delays;

5.14 Project Monitoring and Reporting

a) The Bidder shall describe the proposed project monitoring and reporting methodology in

the bid.

b) SI to submit a written progress report every fortnight to DoT for review. The frequency of

report submission can be modified mutually during critical phases of the Project.

c) Report exceptions and issues that require immediate attention of DoT on a regular basis.

d) The SI’s Project Management team will be responsible for updating the Program

Management Unit (PMU)/ Steering committee of DoT in progress review meetings to be

held at periodic intervals.


Page 169 of 182

5.15 Business Continuity Planning

The selected bidder shall prepare and implement the Business Continuity Plan for DoT. The

strategy should include details of infrastructure, location, operations, management and

policies based on Business Impact Analysis carried out in consultation with the DoT officials.

5.16 Supply of Software/ Application/ RDBMS/ Other related Software/ Licenses

a) SI shall supply all the software with adequate number of licenses, required for the

proposed IT system.

b) The software provided should have the OEM/ vendor support for a period of not less than

5 years from the date of go live.

c) Tools, software for implementation, Data Migration, Testing etc. shall be part of the

offered solution and shall be arranged by the SI without any additional cost to DoT.

d) All support services including updates, upgrades and patches for all software modules

shall be provided by the SI till the end of the warranty and AMC period.

5.17 Authorization, Security and Access

a) The SI shall assist DoT in formulating appropriate security/ authorization, control policy to

prevent unauthorized access to the RMS components e.g. programs, data, screens and

outputs.

b) The SI shall build adequate access rights and control mechanisms into the proposed IT

system to prevent any unauthorized access to the RMS or any of its part/ data/

information.

5.18 DR Drill

The DR drill will happen at the time of start of warranty period, and successful DR drill will

be an acceptance criterion. Post that a DR drill will happen once every six month. DR drill

shall ensure that in case of a disaster a smooth and proper transition happens from Cloud

Platform to DR within RTO/ RPO timeliness. Following parameters should be looked into &

maintained during a DR Drill:

a) The transition time between Cloud Platform to DR shift is maintained as per the RTO.

b) The low compute is scaled to full compute within the RTO timelines.

c) The network connectivity and traffic re-routing is taken care with in the RTO timelines.

d) The data loss is within the define RPO.

e) The period of the DR drill will be one week.


Page 170 of 182

5.19 Disaster Recovery and Back-up Policy

f) The SI shall formulate an effective Back up strategy and Disaster Recovery Plan and will

be responsible for implementing the same during the contract period.

g) The SI shall revise/ update the backup policy keeping pace with the technological

advancement.

h) The SI shall test the effectiveness of the Back-up Strategy.

i) The SI shall submit the DR drill report to DoT.

5.20 General Scope

a) The SI must provide comprehensive on-site warranty/ on-site maintenance duly backed-

up by authentic OEM support for the entire IT infrastructure supplied and installed under

the project and thereafter during maintenance phase for the entire period of contract as

per the agreed SLA.

b) If required, preventive maintenance services to be carried out at least once in a quarter

(3 months).

c) Corrective maintenance services to be carried out as and when required.

d) Asset management services i.e. creation of a database of all the IT hardware (if any) and

software assets, record installation and removal of any asset and inform DoT even if it is

temporary, register all the licensed software with the respective OEMs and maintain the

registration details.

e) Configuration management services i.e. maintaining the record of all the hardware and

software configurations, to ensure that no unwarranted changes are carried out, version

management of the configurations, accessibility of the configurations only to the admin

and designated officials.

f) Vendor management services i.e. coordination with external vendors/ OEMs/ CSP/ BSP

etc., maintaining the database of all the vendors with their contact details.

g) Server management services i.e. administration, performance tuning, patch

management, usage statistics, access details, logs, security etc.

h) Backup and recovery of all the system software, application software, database, etc. as

per the Standard/ CSP policy.

i) SI should ensure that all the software, hardware, peripherals, accessories, sub-

components required for the functionality and completeness of the solution should also

be provisioned according to the requirements of the solution. Also, any additional

components, sub-components, assemblies, sub-assemblies that would be required to


Page 171 of 182

meet the desired performance requirements (as per SLA) will have to be provisioned by

the SI at no additional cost to DoT.

j) To ensure that the application design and implementation takes care of necessary security

aspects such as data safety, access controls, integrity, backup measures.

k) Bidder should ensure that none of the quoted components and sub-components is

declared end-of-sale, end-of-life, and end-of-support by the respective OEM at the time

of bid submission. If, the OEM declares any of the products/ solutions end-of-sale

subsequently, bidder should ensure that the same is supported by the respective OEM

from its date of deployment till the end of the contract period.

l) SI will be responsible for the generation and submission of necessary documentation

required during the entire project by DoT.

m) The SI will be responsible for maintaining the required performance levels as per the

agreed SLA failing which the penalty, as applicable and as define in the subsequent

sections of this RFP document, shall be imposed on the SI.

5.21 Deliverables

The SI shall have to submit certain key deliverables during implementation and AMC phase

which are mentioned hereunder. However, in addition to the deliverables as indicated below,

the SI shall prepare and submit all other required information related to the project in

desirable format as notified by the DoT, whenever required. Acceptance criteria of

deliverables will be mutually agreed and decided between the DoT and SI, during project kick-

off meeting.

S. No. Deliverable

Number

Deliverables from SI

1. D1 SRS document as per IEEE Standards

Screen Layouts/ Wireframes

Requirement Traceability Matrix (RTM)

Project Implementation Plan

Resource deployment Plan

Work Breakdown Structure

2. D2 SDS document including

o Application architecture

o System architecture

o Class diagram

o ER diagram

o Data-flow diagram


Page 172 of 182

3. D3 UAT report on commissioning of Cloud Platform (DC and DR Site)

consists of:

o Screenshots of the communication between DC and DR Site

o Access to User Interface to view server utilization on real-time

basis etc.

Backup, Recovery and Replication Policy and Plan

Data Migration Report

o Data Migration Assessment

o Migration and Transition Approach

o Detailed Data Migration Plan

o Scripts required for data migration

4. D4 Test plan, cases and scenarios, System Test, Integration Test, Load

Test and Performance Test.

The test results along with details.

User Acceptance Test plan, cases and scenarios

Live application showing data entry screens, workflows and MIS

report

5. D5 UAT Report

Security Audit Results

OEMs and Third Party Licenses, Agreements, User Manuals and

any other supporting document

6. D6 Data Migration Completion Report

o Details of actual data that has been migrated

o Certificate from DoT officials confirming successful completion

of data migration

Training Plan

7. D7 User Manual & Handouts

Training Manual

Operations & Maintenance Manual

Administrator Manual

Self-running demos

8. D8 Details of patches/ upgrades/ changes of all components

Details of Issue/ Problem/ Bugs/ Defect (tracker) and solution

Fully tested, bug free, final version of RMS source code

9. D9 Monthly and quarterly compliance reports covering the following:

o Performance Monitoring reports for system

o SLA Compliance Reports

o Details of Patches/ Upgrades of all components


Page 173 of 182

o Details Incremental updates to solution

o Details of Change Requests Managed

o Details of Issue/ Problem/ Bugs/ Defect (tracker) and solution

o On-Going Project Updates and updated documents

o Fully tested, bug free, final/latest version of RMS source code

along with signed hash on SI letter head

o Audit/ Standard Compliance Reports


Page 174 of 182

6.0 Service Level Agreement

Service Level Agreement (SLAs) define the quality and timelines of service delivery during the

Operations and Maintenance (O&M) phase of a project. SLA helps the DoT sustain the

planned business outcomes from the solution deployed on a continued basis over a sustained

period of time.

6.1 Purpose of this Agreement

a) The purpose of this SLA is to clearly define the service level standards in terms of quality

and timelines to be provided by SI and further enforce it on SI. SLA in this project shall

be in effect for the entire contract period (5 years from the day of Go-live and any

extension thereof).

b) The SLA is designed to:

i. Define unambiguously the service level standards expected from the SI and also

ensure that the desired/ agreed level of services are rendered by the SI to DoT.

ii. Motivate SI to ensure the service standards are up to the mark.

iii. Draw the urgent attention of SI in case there is any issues in the service levels or

service level falls below the agreed/ desired level.

iv. Provide a tool to DoT to control and ensure the service levels provided by SI.

v. Avoid imposing penalty on SI without valid reason.

6.2 Escalation Mechanism

The SLA provides the Levels of support to be provided by the selected bidder along with other

important information like criticality of reported incident, incident escalations, responsible

office(s) and expected time to resolve the incident. The following characteristics are used to

identify the severity of an incident.

a) Business and financial exposure

b) Work outage

c) Number of end-users affected

d) Workaround

e) Acceptable resolution time

A given problem must be judged against each of the characteristics to make an overall

assessment of which severity level best describes the incident. The designated officer and

selected bidder’s helpdesk staff may jointly determine the initial severity rating for the report.


Page 175 of 182

Table 2: Escalation Matrix

Escalation Level Severity Codes Responsible Officer

Level 1 Critical

High

Medium

Low

1) SI’s service desk executive/ SPOC for RMS project

2) Designated nodal officer of DoT

Level 2 Critical

High

Medium

Low

1) Project Manager of RMS project

2) Designated nodal officer of DoT

Level 3 Critical

High

Medium

Low

1) Project Director for RMS project

2) DDG at DoT

6.3 Availability Management

a) Availability of IT system - High Availability is a key requirement of DoT as the RMS will

enable the DoT officials to deliver the key activity related to the Revenue Generation.

The expected availability of IT system should be 99% between 8:00 AM and 8:00 PM,

and 95% between 8:00 PM and 8:00 AM. The project must also be able to rebound or

recover from any planned or unplanned system downtime, ensuring a minimal impact

on the operations. The selected implementation vendor should provide a single point

of contact on a 24×7 basis.

b) Availability will be measured on quarterly basis. Planned downtime will not be classified

as unavailability. Planned downtime where both main as well redundant systems are

not available for providing service will be limited to maximum of 48 Hours in a quarter.

The selected bidder should endeavour to take such downtimes only during weekends

or holidays preferably after end of day (EoD). However duration of the maximum

allowable planned downtime time will be reviewed on yearly basis.

c) In case of any breach in the SLA a penalty amounting to 10% of the Quarterly AMC

charges shall be levied on the selected bidder.

6.4 Service Windows & Severity Levels

Table 3: Types of Business Days

Sr. No. Business Day Type Duration of Business Hour Type

1 Prime Business Days (PBD) 1) First 20 days of each quarter


Page 176 of 182

2) Last 20 days of each financial year

2 Business Days (BD) Days except PBD, Sundays and national holidays

3 Non-Prime Business Days

(NPBD)

Sundays and national holidays

Table 4: Types of Business Hours

Sr. No. Business Hour Type Duration of Business Hour Type

1 Prime Business Hours (PBH) 1) 08:00 AM to 08:00 PM, 12 Hours (Monday to Saturday)

2 Non-Prime Business Hours

(NPBH)

1) 08:00 PM to 08:00 AM, 12 Hours (all days)

2) Whole Sundays and national holidays

Table 5: Business Day and Business Hour (BDBH) wise Severity Matrix

Sr. No. Business Day Type Business Hours Type Severity Level

1 Prime Business Day (PBD) Prime Business Hours (PBH) Critical

2 Prime Business Day (PBD) Non-Prime Business Hours (NPBH) High

3 Business Days (BD) Prime Business Hours (PBH) High

4 Business Days (BD) Non-Prime Business Hours (NPBH) Medium


(NPBD)

Prime Business Hours (PBH) Medium


(NPBD)

Non-Prime Business Hours (NPBH) Low

Table 6: Application Module/ Functionality wise Severity Matrix

Sr. No. Application Module/ Functionality Severity Level

1. SUC Assessment Workflow Critical

2. LF Assessment Workflow Critical

3. DVR Preparation Workflow Critical

4. MIS Reports Critical

5. Dashboard High

6. CAF/ EMR Module High

7. Setting-up of TSP Medium

8. Bank Guarantee Submission Workflow Medium

9. Knowledge Bank Medium

10. Discussion Board Medium

11. Grievance Module Medium


Page 177 of 182

12. Setting-up of Master Data Low

13. Administration Functionalities Low

14. Court Case Module Low

15. Budget Module Low

6.5 Service Levels

Following service levels will be applicable on the SI during the entire maintenance period:

Table 7: Service Levels

Sr.

No

.

Severity Level as per

Application Module/

functionality

Severity Level

as per BDBH

Matrix

Response Time/

Acknowledgement of

Problem

Resolution Time

1. Critical Critical Within 15 mins of

reporting

Within 2 hr of

acknowledgement

2. Critical High Within 30 mins of

reporting

Within 6 hr of

acknowledgement

3. Critical Medium Within 1 hr of

reporting

Within 12 hr of

acknowledgement

4. Critical Low Within 2 hr of

reporting

Within 24 hr of

acknowledgement

5. High Critical Within 30 mins of

reporting

Within 6 hr of

acknowledgement

6. High High Within 1 hr of

reporting

Within 12 hr of

acknowledgement

7. High Medium Within 2 hr of

reporting

Within 24 hr of

acknowledgement

8. High Low Within 3 hr of

reporting

Within 36 hr of

acknowledgement

9. Medium Critical Within 1 hr of

reporting

Within 12 hr of

acknowledgement

10. Medium High Within 2 hr of

reporting

Within 24 hr of

acknowledgement

11. Medium Medium Within 3 hr of

reporting

Within 36 hr of

acknowledgement

12. Medium Low Within 4 hr of

reporting

Within 2 day of

acknowledgement

13. Low Critical Within 1 hr of

reporting

Within 24 hr of

acknowledgement

14. Low High Within 2 hr of

reporting

Within 36 hr of

acknowledgement

15. Low Medium Within 3 hr of

reporting

Within 48 hr of

acknowledgement


Page 178 of 182

16. Low Low Within 1 working day

of reporting

Within 3 days of

acknowledgement

6.6 Penalties in case of Failure to meet Service Levels

Following penalty shall be applicable on SI in case of non-compliance to service levels (as

provided in table above):

Table 8: Penalties in case of Non-compliance

Sr. No. % of Non-Compliance Applicable Penalty

(% of the quarterly payable amount)

1. <= 1% No Penalty

2. > 1 % but <= 2% 1%

3. > 2 % but <= 3% 2%

4. > 3 % but <= 4% 3%

5. > 4 % but <= 5% 4%

6. > 5 % but <= 10% 10%

7. a) After 10% of non-compliance, 10% of additional penalty will be applicable for next

10% slab of non-compliance.

b) Maximum penalty applicable on SI would be 20% of the Quarterly AMC instalment.

Post which DoT may decide to terminate the contract and the PBG submitted by SI,

will be encashed.

6.7 SLA Supervision

a) Performance Reporting Procedures: The SI shall prepare the SLA performance reports

of each quarter in an agreed upon format by the 10th calendar day of subsequent

quarter. The reports will include details of each and every incident reported to SI i.e.

date and time of receiving email/ call, date and time of response/ acknowledgement

email, date and time of resolution provided for the reported problem, name of the

module/ functionality which not working upto the mark, severity level of the module/

functionality, severity level as per the Business Day and Business Hour (BDBH) matrix,

complied to the service level or not, total number of incident reported, total number

and % of compliance to the service levels, total number and % of non-compliance to the

service level etc. Performance reports along with all the documentary proofs i.e.

printouts of all the incident reporting emails/ photocopies of incident log register,

acknowledgement email, resolution email, resolution confirmation emails etc. and will

be submitted to DoT in hardcopy as well as softcopy format (ms-excel or open office


Page 179 of 182

format). However actual performance reporting mechanism, format and list of

supporting documents will be discussed and finalized by the SI with DoT before entering

into project maintenance phase.

b) Monitoring and Auditing: Nodal officer of the DoT or its authorized representative

(consultant appointed by DoT) will be responsible for monitoring the performance of SI

against the SLA parameters each quarter, or at any periodicity defined in the contract

document/ mutually decided by both the parties. The review/ audit report prepared

based on the performance report, will form basis for any action relating to imposing

penalty or breach of contract. Any such review/ audit can be scheduled as and when

required. The results will be shared with the SI as soon as possible. DoT reserves the

right to ask SI to provide performance report anytime during the contract period and to

appoint a third-party auditor to validate the SLA.

6.8 SLA Change Control

a) The present SLA has been worked out on the basis of current business needs of DoT.

However, as the system evolves over the time, the DoT’s business needs also evolve

over the course of the contract period. In view of this requirement of changing the SLA

may also arise.

b) Any request for change in the service levels provided during the term of this agreement

shall be documented and negotiated in good faith by both parties. Either party can

request for a change. Changes will be documented as an addendum to SLA and

consequently the contract.

c) Any changes in the SLA shall be dealt with in accordance with the Change Control


d) If in case there is any confusion or conflict between Final RFP document and the

Contract, the Contract and subsequent amendments, if any, shall prevail.

6.9 SLA Change Process

a) Both the parties may amend this SLA by mutual agreement in accordance.

b) Changes can be proposed by either party.

c) Normally the forum for negotiating SLA changes will be DoT’s review meetings.

d) Any changes in the SLA shall be dealt with in accordance with the Change Control



Page 180 of 182

6.10 Version Control

All negotiated SLA changes will require changing the version control number. As appropriate,

minor changes may be accumulated for periodic release (e.g. every quarter) or for release

when a critical threshold of change has occurred.

6.11 Issue Management Process

This process provides an appropriate management structure for the orderly consideration

and resolution of business and operational issues in the event that quick consensus is not

reached between DoT and SI. It is expected that this pre-defined process will only be used on

an exception basis if issues are not resolved at lower management levels.

a) Either DoT or SI may raise an issue by documenting the business or technical problem,

which presents a reasonably objective summary of both points of view and identifies

specific points of disagreement with possible solutions.

b) DoT will determine which committee or executive level should logically be involved in

resolution.

c) A meeting or conference call may be conducted to resolve the issue in a timely manner.

The documented issues will be distributed to the participants at least 24 hours prior to

the discussion if the issue is not an emergency requiring immediate attention.

d) Management of DoT and SI will develop a temporary, if needed, and the permanent

solution for the problem at hand. The SI will then communicate the resolution to all

interested parties.

e) In the event a significant business issue is still unresolved, the arbitration procedures

described in Vol III of this RFP.

6.12 Issue Escalation Process

a) All issues would be raised to the project management team, which is completely

responsible for the day to day aspects of the implementation. The project management

team shall classify the issues based on their severity level and resolve them within

appropriate timelines.

b) If project management team is unable to resolve an issue, the issue would be escalated

to the top management with options/ risks detailed for decision. Top management will

make decisions based on the options/ risks presented by the IT team.

c) In case one or both the parties are unsatisfied with the decision of the top management

of DoT, the dispute will be resolved as specified in the volume-III of this RFP.


Page 181 of 182

6.13 Risk and Cost Factor

In the event of termination of contract on the basis of non-performance by the SI as per SLA,

SI will be solely responsible for risk and cost factor thereon. In such an event, the performance

Bank Guarantee furnished by the SI will be encashed and will stand forfeited.

6.14 Breach of SLA

In case the SI does not meet the service levels mentioned in this RFP and percent of non-

compliance exceeds 20% as specified in the clause 6.6 above, DoT will treat it as a case of

breach of Service Level Agreement. The following steps will be taken in such a case:-

a) DoT issues a show cause notice to the SI.

b) SI should reply to the notice within three working days.

c) If DoT authorities are not satisfied with the reply, DoT will initiate termination process

as per the contract.

6.15 Exclusions

The SI will be exempted from any non-compliance/ delays/ slippages on SLA parameters

arising out of following reasons:

a) Delay in execution due to delay (in approval, review etc.) from DoT’s side. Any such

delays will be notified in written to the DoT

b) Force Majeure

c) The network links will be provided by a third party and the SI will monitor and report

any problems on behalf of third party. If SI notifies and DoT approves that the delay or

fault was due to the third party link services then such loss will not be considered for

tracking SI’s SLA parameters (Also reduced from total service time).


Page 182 of 182

7.0 Project Schedule

The project schedules for the design, development and implementation of DoT Portal are as

follows:

S.

No.

Activities Time for

Completion1

Deliverables

from SI*

1. Signing of Contract with successful bidder Date of Start (T) –

2. Preparation and submission of the SRS

document,

T + 6 Weeks D1

3. Preparation and submission of Software Design

Specifications, including solution architecture

and design of the Revenue Management System

T + 12 weeks D2

4. Commissioning of cloud platform and disaster

recovery center along with supporting tools/

software

T + 16 Weeks -

5. Acceptance testing of cloud platform and

disaster recovery center, and preparation of the

data migration strategy

T + 20 Weeks D3

6. Development of Revenue Management System T + 24 Weeks -

7. Testing of RMS T + 28 Weeks D4

8. User Acceptance Testing T + 32Weeks D5

9. Data Migration T + 33 Weeks D6

10. Training to key staffs/ users T + 34 Weeks D7

11. Warranty exit for Revenue Management System

and Go-Live date

T + 36 Weeks D8

12. Annual Maintenance Support 5 years from

Date of Go-Live

D9

* Please refer clause 5.21 (Deliverables) for the details of aforementioned deliverables.

1 Any timelines related changes amongst activities may be discussed with the SI, but the overall duration of the project (36 weeks) will remain unchanged.

2018

RFP Reference No.:1-6/2004/LF II/Vol III RFP Issuing Date: 27/Mar/2018

Tender Issuing Authority: Director – Licensing Finance Assessment Department of Telecommunication Ministry of Communications Sanchar Bhawan, 20 Ashoka Road New Delhi- 110001 Phone: 011-233-72193 Mobile: +91 9868135825 E-Mail: [email protected]

RFP for Selection of System Integrator

for the Design, Development,

Implementation and Maintenance of

Revenue Management System for

Department of Telecommunications

Volume – II

General and Financial Specifications


RFP for Selection of System Integrator for the Design, Development, Implementation and Maintenance of Revenue Management System for DoT (Volume-II)

Page 2 of 80

Table of Contents

Abbreviations and Definitions .......................................................................................................................... 5

1. The RFP Process ............................................................................................................................................ 7

1.1 Content of the RFP Document ................................................................................................... 7 1.2 Key Activities and Dates .............................................................................................................. 7 1.3 Clarifications on RFP Documents ............................................................................................. 8 1.4 Pre-Bid Meeting .............................................................................................................................. 8 1.5 Proposal Preparation Cost ......................................................................................................... 9 1.6 DoT’s Right to Terminate ............................................................................................................ 9

2. Instructions to Bidders ............................................................................................................................ 10

2.1 Availability of RFP Document ................................................................................................. 10 2.2 RFP Document Fee ...................................................................................................................... 10 2.3 Eligible Bidders ........................................................................................................................... 10 2.4 Debarment .................................................................................................................................... 11 2.5 Preparation and submission of Bid ...................................................................................... 11 2.6 Late Bid ........................................................................................................................................... 15 2.7 Withdrawal and resubmission of e-Bid .............................................................................. 15 2.8 DoT's Right to accept any e-Bid and to reject any or all e-Bids. ................................. 16 2.9 Period of validity of e-Bid ........................................................................................................ 16 2.10 Correspondence with the Bidder .......................................................................................... 17 2.11 Earnest Money Deposit/ Bid Security ................................................................................. 17 2.12 Amendments in RFP Document ............................................................................................. 18 2.13 Compliance with Mandatory Requirements ..................................................................... 18 2.14 Technical Proposal ..................................................................................................................... 19 2.15 Financial Proposal ...................................................................................................................... 20 2.16 Terms & Conditions of Bidders .............................................................................................. 21 2.17 Deviations in Terms and Conditions of RFP ...................................................................... 21 2.18 Right to Publish ........................................................................................................................... 22 2.19 Clarifications from Bidders ..................................................................................................... 22 2.20 Due-diligence by Bidders ......................................................................................................... 23 2.21 Collusive Proposal ...................................................................................................................... 23 2.22 Fraud and Corrupt Practices .................................................................................................. 23 2.23 Conflict of Interest ...................................................................................................................... 25 2.24 Integrity Pact ................................................................................................................................ 25 2.25 Opening of e-Bids ........................................................................................................................ 26 2.26 Confidentiality ............................................................................................................................. 27 2.27 Taxes & Duties ............................................................................................................................. 28 2.28 Return of Information to DoT ................................................................................................ 28 2.29 False or Misleading Claims ...................................................................................................... 28 2.30 Assignment/ Sub Contract ....................................................................................................... 29 2.31 Intellectual Property Rights (IPR) Indemnity .................................................................. 29 2.32 Criminal Charges and Conviction .......................................................................................... 30

3 Evaluation of Bids/Proposals ................................................................................................................ 31

3.1 Opening of Bids ............................................................................................................................ 31 3.2 Initial Determination of Compliance with RFP Requirements................................... 31


Page 3 of 80

3.3 Correction of Errors ................................................................................................................... 31 3.4 Bid Evaluation Procedure ........................................................................................................ 31 3.5 Site Visit by DoT .......................................................................................................................... 34 3.6 Best Value Determination and Final Evaluation ............................................................. 34

4 Award of Contract ...................................................................................................................................... 35

4.1 DoT’s Right to Accept or Reject Any or All Proposals .................................................... 35 4.2 Notification of Award ................................................................................................................ 35 4.3 Signing of Contract ..................................................................................................................... 36 4.4 Contract Period ........................................................................................................................... 36 4.5 Performance Bank Guarantee ................................................................................................ 36 4.6 Annulment of Award.................................................................................................................. 37 4.7 Appointment Tenure ................................................................................................................. 37 4.8 Exit/ Suspension/ Termination of Contract with Selected Bidder ........................... 37

5 Other General Terms and Conditions ................................................................................................. 39

5.1 Relationship between the Parties ......................................................................................... 39 5.2 Standards of Performance ....................................................................................................... 39 5.3 Delivery and Documents .......................................................................................................... 39 5.4 Governing Language for Assignment ................................................................................... 40 5.5 Suspension .................................................................................................................................... 40 5.6 Notice .............................................................................................................................................. 40 5.7 Progress of the Project .............................................................................................................. 40 5.8 Forfeiture of Performance Bank Guarantee ..................................................................... 40 5.9 Probity & Publicity ..................................................................................................................... 41 5.10 Reservation of Rights ................................................................................................................ 41 5.11 Extension of Contract ................................................................................................................ 42 5.12 Breach of Statutes ....................................................................................................................... 42 5.13 Waiver ............................................................................................................................................. 42 5.14 Project Timelines ........................................................................................................................ 42 5.15 Miscellaneous ............................................................................................................................... 42

6 Payment Schedule ..................................................................................................................................... 43

Annexure-I: Cover Letter ................................................................................................................................. 44

Annexure-II: Particulars of Bidder ............................................................................................................... 46

Annexure-III: Format for Request for Clarifications ............................................................................. 47

Annexure-IV: Format for Submitting BOM ................................................................................................ 48

Annexure-V: Summary of Profile of Key Personnel ............................................................................... 49

Annexure-VI: Format for Submitting Profiles of key resources ........................................................ 50

Annexure-VII: Format for providing details of past projects of the bidder................................... 51

Annexure-VIII: Pre-Qualification Criteria ................................................................................................. 52

Annexure-IX: Technical Evaluation Parameters ..................................................................................... 54

Annexure-X: Financial Proposal Format .................................................................................................... 59

Annexure-XI: Cost for Additional Services ................................................................................................ 61

Annexure-XII: Format for Earnest Money Deposit (EMD) ................................................................... 63

Annexure-XIII: Format for Performance Bank Guarantee (PBG) ..................................................... 65


Page 4 of 80

Annexure-XIV: Format for Self-Declarations ............................................................................................ 67

Annexure-XV: Integrity Pact ........................................................................................................................... 70

Annexure-XVI: Financial Capability Statement ....................................................................................... 78

Annexure-XVII: Format for Providing Past Project Summary of Bidder ........................................ 79

Annexure-XVIII (Format for Submission of Deviations) ...................................................................... 80


Page 5 of 80

Abbreviations and Definitions Table 1: Abbreviations and Definitions

# Abbreviation Explanation

1. BG Bank Guarantee

2. BoM Bill of Material

3. CA Chartered Accountant

4. CCA Controller of Communication Accounts

5. CMMi Capability Maturity Model Integration

6. CV Curriculum Vitae

7. DoT Department of Telecommunication, Government of India

8. EMD Earnest Money Deposit

9. GoI Government of India

10. GR Gross Revenue

11. GST Goods and Services Tax

12. HQ Headquarter

13. ICT Information and Communication Technology

14. INR Indian National Rupee

15. ISO International Organization for Standardization

16. IT Information Technology

17. ITeS Information Technology enabled Services

18. LD Liquidated Damages

19. LF License Fee

20. LFA License Finance Assessment

21. LFP License Finance Policy

22. LLP Limited Liability Partnership

23. LoA Letter of Acceptance

24. LoI Letter of Intent


Page 6 of 80

25. MCLR Marginal Cost of Funds Based Lending Rate

26. OEM Original Equipment Manufacturer

27. O&M Operations and Maintenance

28. PBG Performance Bank Guarantee

29. PLR Prime Lending Rate

30. PoA Power of Attorney

31. Pr. CCA Principal Controller of Communication Accounts

32. PSU Public Sector Undertaking

33. QCBS Quality cum Cost Based Selection

34. RFP Request for Proposal

35. RMS Revenue Management System

36. SI System Integrator

37. SLA Service Level Agreement

38. SUC Spectrum Usage Charge

39. TSP Telecom Service Provider

40. UAT User Acceptance Testing

41. WPF Wireless Planning Finance


Page 7 of 80

1. The RFP Process

1.1 Content of the RFP Document

a) The RFP documents are those stated below and should be read in conjunction with any

Addenda issued in accordance with clause 2.12 (Amendment in RFP Documents) of this

Volume and proceedings of Pre-bid Meeting issued in accordance with clause 1.4 (Pre-Bid

Meeting):

RFP Volume I : Functional & Technical Specifications

RFP Volume II : General & Financial Specifications

RFP Volume III : Master Service Agreement

b) The bidder is expected to examine all instructions, forms, terms, DoT’s requirements and

other information in the RFP documents. Failure to furnish all information required by the

RFP documents or submission of a proposal not substantially responsive to the RFP

documents in every aspect would be at the bidder’s risk and may result in rejection of the

proposal.

1.2 Key Activities and Dates

The schedule of key activities for the purpose of this RFP is outlined below:

S. No. Key Activities Date

1. Issuance of Request For Proposal (RFP) 27/Mar/2018

2. Last date of receiving queries from bidders 09/Apr/2018, 14:00 hrs

3. Pre-bid meeting date 11/Apr/2018, 15:00 Hrs

4. Last date and time for submission of e-bids 02/May/2018, 15:00 Hrs

5. Opening of the e-bid -Technical Proposal 03/May/2018, 15:00 Hrs

6. Technical Presentation cum Demo To be communicated to the bidders at the later stage.

7. Opening of the e-bid - Financial Proposal To be communicated to the bidders at the later stage.

8. Contract Finalization and Award To be communicated to the bidders at the later stage.

Important: It must be noted that DoT reserves the right to change any date/time mentioned in

the schedule above at any point of time. The bidders would, however be intimated of the changes


Page 8 of 80

as and when they happen and the same shall be updated on the DoT website- dot.gov.in and e-

tender websites https://eprocure.gov.in.

1.3 Clarifications on RFP Documents

a) A prospective bidder requiring any clarification on the RFP documents shall notify DoT in

writing at the address of correspondence/email given in Volume-II of this RFP. All queries and

clarifications should reach DoT by 09/Apr/2018, 14:00 Hrs.

b) DoT would try to give clarifications to the bidders in the pre–bid meeting. However, the final

responses to clarifications will be published by the DoT on DoT and e-procurement/ e-tender

websites. This may be noted that, DoT at its sole discretion may decide not to respond to

some or any of the queries submitted by the bidders.

c) The queries, suggestions and other observations will be examined by DoT and any

amendments to the RFP, if required, shall be done at the sole discretion of DoT.

d) Except for responses to request for any clarifications on the bid, the bidder shall not contact

DoT by any means for any matter related to this bid from the time of submission of the bid

until the issuance of LOI to the successful bidder. Such actions may lead to disqualification as

well as blacklisting of the bidder.

1.4 Pre-Bid Meeting

a) The bidder’s authorized representatives are invited to attend the Pre-bid meeting at their

own cost which would take place at the venue mentioned below and time as stipulated above

in the clause 1.2.

Venue: Ministry of Communications Department of Telecommunications Sanchar Bhawan, 20 Ashoka Road New Delhi- 110001 Email: [email protected]

b) The purpose of the meeting would be to clarify queries on any matter related to the RFP and

the project.

c) The bidders are requested to submit their queries in writing/email to DoT on or before the

date indicated above in clause 1.2. Any queries received after the indicated date and time will

not be entertained.

d) The bidders shall submit their queries in the specified format as mentioned in this RFP

(Annexure-III).

dot.gov.in



Page 9 of 80

e) Bidders may submit the queries at above mentioned email ID within the stipulated timelines

as indicated above in clause 1.2. Queries received later than the date and time mentioned

above in clause 1.2 shall not be entertained.

f) Only authorized representatives (maximum two persons) of the bidders will be allowed to

participate in the pre-bid meeting.

g) Not attending the pre-bid meeting will not be a cause for disqualification.

1.5 Proposal Preparation Cost

The bidders shall bear all costs associated with the preparation and submission of their bids,

contract negotiation, signing and/or any activity related to this RFP like participation in the

bidding process/ meetings, conduct the study, analysis and diligence activities in order to prepare

respond, presentation(s). DoT in no case will be responsible or liable for these costs. Through this

RFP, DoT neither commits to award a contract nor to engage in any negotiations regardless of

the conduct or outcome of the bidding process.

1.6 DoT’s Right to Terminate

a) DoT may terminate the RFP process at any time and without assigning any reason. The DoT

makes no commitment, express or implied, that this process will result in a business

transaction with anyone.

b) This RFP does not constitute an offer by the DoT. The bidder's participation in this process

may result in DoT selecting the bidder to engage in further discussions and negotiations

toward execution of a contract. The commencement of such negotiations does not, however,

signify a commitment by DoT to execute a contract or to continue negotiations. The DoT may

terminate negotiations at any time without assigning any reason.


Page 10 of 80

2. Instructions to Bidders

2.1 Availability of RFP Document

This RFP document is available on the web site https://eprocure.gov.in and on DoT website

http://www.dot.gov.in/ to enable the Bidders to view, download the RFP document and to

submit e-Bids online up to the last date and time mentioned in RFP document. The Bidder’s shall

have to pay RFP Document Fee in the form of Demand Draft of a Nationalized Bank of India drawn

in favor of the ”Pay and Accounts Officer, DoT (HQ)” and payable at New Delhi. The Bidder shall

also furnish, as part of its bid, an Earnest Money Deposit (EMD)/ bid Security of INR 20,00,000/-

(INR Twenty Lakhs only) by means of a Demand Draft/ Bank Guarantee, from a scheduled bank,

drawn in favour of ”Pay and Accounts Officer, DoT (HQ)” valid for 180 days from the bid

submission end date, payable at New Delhi.

2.2 RFP Document Fee

2.2.1 RFP Document Fee of INR 10,000/- (INR Ten Thousand only) in the form of a Demand Draft

drawn in favour of ”Pay and Accounts Officer, DoT (HQ)” and payable at New Delhi must

be submitted along with the Proposal.

2.2.2 Proposals not accompanied by RFP Document Fee shall be rejected as non- responsive.

2.3 Eligible Bidders

2.3.1 A bidder may be a legal private entity or a legal government-owned entity with the intent

to enter into contract to deliver the engagement.

2.3.2 The bidder should be eligible to operate in conformity with the provisions of the laws in

India and shall have a registered office within India.

2.3.3 Bidder should not have any conflict of interest with any parties included in the bidding

process.

2.3.4 No consortium or Joint Venture is allowed to participate in the bidding Process.

2.3.5 A bidder can submit only one bid in this bidding process. Submission of more than one

bid by the bidder will result in the disqualification of all the bids submitted by the bidder.

2.3.6 The bidder must produce documentary evidence of any claim made in the RFP document

regarding their eligibility and ability for fulfilling the requirements specified within this

RFP. The evaluation committee may decide the type and format of such documentary

evidence.


http://www.dot.gov.in/


Page 11 of 80

2.3.7 The Evaluation committee can make such investigations, if need be felt, as necessary to

determine the eligibility and ability of the bidder to fulfil the requirements specified

within this RFP.

2.4 Debarment

The bidder should not be debarred for fraudulent and corrupt practices by any Government

entity in India as on the date of bidding.

2.5 Preparation and submission of Bid

2.5.1 Language of Bid

The bid document prepared by the Bidder, as well as all correspondence and documents relating

to the e-Bid exchanged by the Bidder and DoT shall be written in English. The correspondence

and documents in Hindi must be accompanied by embedded/separate Hindi font files. Only

English numerals shall be used in the e-Bid.

2.5.2 Documents constituting the e-Bid

The e-Bid prepared by the Bidder shall comprise the following components:

a) Technical Bid – Technical Electronic Bid shall comprise of :

i) Fee Details – Scanned copy of RFP Document Fee demand draft.

ii) Bid Security Details – Scanned copy/softcopy of EMD bank guarantee/DD.

iii) Eligibility Details - Includes copies of required documents in PDF format justifying

that the Bidder is qualified to perform the contract if his/her bid is accepted and

the Bidder has financial & technical capability necessary to perform the contract

and meets the criteria outlined in the Pre-Qualification and fulfill all the conditions

of the contract.

iv) Technical Evaluation: Include copies of required documents in PDF format along

with required information as outlined in Technical Evaluation Parameters in this

RFP (Annexures-I to IX and XII to XVII) and fulfills all the technical conditions of the

contract.

b) Financial Bid – The Financial Electronic Bid shall include following:

i) Cover letter: Financial Proposal Format (Annexure-X) along with Cost for Additional Services

(Annexure-XI) in PDF format (include Annexure-XI as annexure of Annexure-X at the time of

upload at https://eprocure.gov.in).



Page 12 of 80

ii) Financial Quote: in the prescribed BoQ (Annexure X, in xls/xlsx/pdf file format) available for

download on https://eprocure.gov.in.

2.5.3 Documents establishing Bidder's Qualification

a) The Bidder shall furnish, as part of its technical e-Bid, documents establishing the

Bidder's qualification to perform the contract if its e-Bid is accepted. The documentary

evidence should be submitted by the Bidder electronically in the PDF format.

b) The documentary evidence of Bidder's qualification to perform the contract if its e-Bid

is accepted shall be as per qualification requirements specified in e-Bid document.

c) All the documents submitted by the bidder shall be signed by authorized signatory and

shall also put company’s/authorized signatory’s seal.

2.5.4 e-Bid Currency

The prices quoted in the proposal shall be in Indian Rupees only. Proposal in any currency

other than Indian Rupee (INR) shall be treated as non-responsive and hence shall be

rejected.

2.5.5 Formats and Signing of e-Bid.

a) The Bidder shall prepare one electronic copy each of the technical bid and financial bid

separately.

b) The e-Bid document shall be digitally signed, at the time of uploading, by the Bidder or

a person or persons duly authorized to bind the Bidder to the contract. The bidder’s

authorization shall be supported by attaching a scanned copy of valid proof of

authorization like Power of Attorney/Board Resolution etc.

2.5.6 Deadline for submission of e-Bid

E-Bid (Technical and Financial) must be submitted by the Bidder at e-tender website:

https://eprocure.gov.in not later than the time specified on the prescribed date (as the

server time displayed in the e-procurement website). The Department may, at its

discretion, extend this deadline for submission of e-Bid by issuing and publishing a

corrigendum on DoT and e-tender website; in such case all rights and obligations of the

Department and the Bidders previously subject to the deadline will thereafter be subject

to the deadline as extended.

2.5.7 Submission of e-Bid




Page 13 of 80

a) The bid submission module of e-tender website: https://eprocure.gov.in enables

the Bidders to submit the e-Bid online in response to the RFP published by the

Department.

b) Bid submission can be done only from the bid submission start date and time till the

bid submission end date and time given in the RFP. Bidders should start the bid

submission process well in advance so that they can submit their e-Bids in time.

c) The Bidder should submit their e-Bid considering the server time displayed in the e-

tender website. This server time is the time by which the e-Bid submission activity will

be allowed till the permissible time on the last/end date of submission indicated in the

e-Bid schedule.

d) Once the e-Bid submission date and time is over, the Bidders cannot submit their e-

Bid. For delay in submission of e-Bid due to any reasons, the Bidders shall only be held

responsible.

e) The Bidders have to follow the following instructions for submission of their e-Bid:

i) For participating in e-Bid through the e-Bidding system it is necessary for the

Bidders to be the registered users of the e-tender website: https://eprocure.gov.in.

The Bidders must obtain a user login ID and password by registering themselves

with Department of Telecommunications, Government of India if they have not

done so previously for registration.

ii) In addition to the normal registration, the Bidder has to register with his/her

digital signature certificate (DSC) in the e-Bidding system and subsequently

he/she will be allowed to carry out his/her e-Bid submission activities.

Registering the digital signature certificate (DSC) is a one-time activity. Before

proceeding to register his/her DSC, the Bidder should first log on to the e-Bidding

system using the user login option on the home page with the login Id and

password with which he/she has registered.

iii) For successful registration of DSC on e-tender website: https://eprocure.gov.in the

Bidder must ensure that he/she should possess class-2/class-3 DSC issued by any

certifying authorities approved by controller of certifying authorities, Government

of India, as the e-tender website: https://eprocure.gov.in is presently accepting

DSC issued by these authorities only. The Bidder can obtain user login ID and

perform DSC registration exercise given above even before the e-Bid submission

date starts. The Department shall not be held responsible if the Bidder tries to






Page 14 of 80

submit his/her e-Bid at the moment before end date of submission but could not

submit due to DSC registration problem.

iv) The Bidder can search for active Bids through "search active tenders" link, select

a Bid in which he/she is interested in and then move it to 'My Tenders' folder

using the options available in the e-Bid submission menu. After selecting the Bid,

for which the Bidder intends to e-Bid, from "My tenders" folder, the Bidder can

place his/her e-Bid by clicking "pay offline" option available at the end of the view

Bid details form. The Bidder should keep all the documents ready as per the

requirements of e-Bid document in the PDF as per formats given in the RFP

document.

v) After clicking the 'pay offline' option, the Bidder will be redirected to terms and

conditions page. The Bidder should read the terms & conditions before

proceeding to fill in the RFP document fee and EMD offline payment details. After

entering and saving the Bid fee and EMD details form so that "bid document

preparation and submission" window appears to upload the documents as per

technical and financial schedules/packets given in the Bid details.

vi) Next the Bidder should upload the technical e-Bid documents for fee details (e-

Bid fee and EMD), Qualification details. Before uploading, the Bidder has to select

the relevant digital signature certificate. He may be prompted to enter the digital

signature certificate password, if necessary. For uploading, the Bidder should

click "browse" button against each document label in technical and financial

schedules/packets and then upload the relevant PDF files already prepared and

stored in the Bidder's computer. The required documents for each document

label of technical and financial schedules can be clubbed together to make single

different files for each label.

vii) The Bidder should click "Encrypt" next for successfully encrypting and uploading

of required documents. during the above process, the e-Bid document are

digitally signed using the DSC of the Bidder and then the documents are

encrypted/locked electronically with the DSC's of the bid openers to ensure that

the e-Bid documents are protected, stored and opened by concerned bid

openers only.

viii) After successful submission of e-Bid document, a page giving the summary of e-

Bid submission will be displayed confirming end of e-Bid submission process. The

Bidder can take a printout of the bid summary using the "print" option available

in the window as an acknowledgement for future reference.


Page 15 of 80

2.6 Late Bid

2.6.1 The server time indicated in the bid management window on the e-tender website:

https://eprocure.gov.in will be the time by which the e-Bid submission activity will be

allowed till the permissible date and time scheduled in the e-Bid.

2.6.2 Once the e-Bid submission date and time is over, the Bidder cannot submit his/her e-Bid.

Bidder has to start the bid submission well in advance so that the submission process

passes off smoothly. The Bidder will only be held responsible if his/her e-Bid is not

submitted in time due to any of his/her problems/faults, for whatsoever reason, during

e-Bid submission process.

2.7 Withdrawal and resubmission of e-Bid

2.7.1 At any point of time, a Bidder can withdraw his/her e-Bid submitted online before the bid

submission end date and time. For withdrawing the Bidder should first log in using his/her

login ID and password, then subsequently by using his/her digital signature certificate on

the e-tender website: https://eprocure.gov.in. The Bidder should then select "My bids"

option in the bid submission menu. The page listing all the bids submitted by the Bidder

will be displayed. Click "View" to see the details of the bid to be withdrawn. After selecting

the "bid withdrawal" option the Bidder has to click "Yes" to the message "Do you want to

withdraw this bid?" displayed in the bid information window for the selected bid. The

Bidder also has to enter the bid withdrawing reasons and upload the letter giving the

reasons for withdrawing before clicking the "Submit" button. The Bidder has to confirm

again by pressing "OK" button before finally withdrawing his/her selected e-Bid.

2.7.2 No e-Bid may be withdrawn in the interval between the deadline for submission of e-Bids

and the expiration of period of e- bid validity. Withdrawal of an e-Bid during this interval

may result in the forfeiting of Bidder's e-Bid security.

2.7.3 The Bidder can re-submit his/her e-Bid as when required till the e-Bid submission end

date and time. The e-Bid submitted earlier will be replaced by the new one. The payment

made by the Bidder earlier will be used for revised e-Bid and the new e-Bid submission

summary generated after the successful submission of the revised e-Bid will considered

for evaluation purposes. For resubmission, the Bidder should first log in using his/her login

ID and password and subsequently by his/her digital signature certificate on the e-tender

website: https://eprocure.gov.in. The Bidder should then select "My bids" option in the

bid submission menu. The page listing all the bids submitted by the Bidder will be

displayed. Click "View" to see the detail of the e-Bid to be resubmitted. After selecting the





Page 16 of 80

"bid resubmission" option, click "Encrypt & upload" to upload the revised e-Bids

documents.

2.7.4 The Bidder can submit their revised e-Bids as many times as possible by uploading their

e-Bid documents within the scheduled date & time for submission of e-Bids.

2.7.5 No e-Bid can be resubmitted subsequently after the deadline of submission of e-Bids.

2.8 DoT's Right to accept any e-Bid and to reject any or all e-Bids.

2.8.1 Notwithstanding anything contained in this e-Bid, DoT reserves the right to accept or

reject any Bid and to annul the Selection Process and reject all Bids, at any time without

any liability or any obligation for such acceptance, rejection or annulment, and without

assigning any reasons thereof.

2.8.2 The Department reserves the right to reject any Bid if:

At any time, any misrepresentation is made or uncovered, or

The Bidder does not provide, within the time specified by DoT, the supplemental

information sought by DoT for evaluation of the e-Bid.

2.8.3 Such misrepresentation/ improper response may lead to the disqualification of the

Bidder. If such disqualification/ rejection occurs after the e-Bid has been opened and the

highest ranking Bidder gets disqualified/ rejected, then the department reserves the right

to consider the next best Bidder, or take any other measure as may be deemed fit in the

sole discretion of the DoT, including annulment of the Selection Process.

2.9 Period of validity of e-Bid

2.9.1 e-Bid shall remain valid for 180 days (one hundred and eighty days) from the bid

submission due date/end date as prescribed by the DoT. An e-Bid valid for a shorter

period shall be rejected by the DoT as non-responsive.

2.9.2 In exceptional circumstances, DoT may solicit the Bidder's consent to an extension of the

period of e-Bid validity. The request and the response thereto shall be made in writing. A

Bidder may refuse the request without forfeiting its e-Bid security. A Bidder granting the

request will not be required nor permitted to modify its e-Bid.

2.9.3 During the bid validity period, the bidder is expected to keep available the personnel

proposed for the assignment.


Page 17 of 80

2.9.4 DoT will make its best effort to evaluate the bids and sign the contract within this period.

If DoT wishes to extend the validity period of the proposals, the bidders who do not agree,

have the right not to extend the validity of their proposals.

2.10 Correspondence with the Bidder

2.10.1 No Bidders or its Technical Partners shall contact DoT on any matter relating to his e-Bid

from the time of Bid opening to the time contract is awarded.

2.10.2 Any effort by the Bidder or by its Technical Partners to influence DoT in the Bid evaluation,

Bid comparison or contract award decisions, may result in the rejection of his Bid.

2.11 Earnest Money Deposit/ Bid Security

2.11.1 The bidder shall furnish, as part of its bid, an Earnest Money Deposit (EMD)/ bid Security

of INR. 20,00,000/- (INR Twenty Lakhs only) by means of a Demand Draft/Bank Guarantee,

from a scheduled bank, drawn in favour of “Pay and Accounts Officer, DoT (HQ)”, valid

for 180 days from the bid submission end date, payable at New Delhi. No bidder is

exempted from furnishing the said EMD. The currency of the EMD shall be Indian Rupees

(INR) only.

2.11.2 Bids received without the EMD shall be rejected outright as non-responsive. No further

communication from the bidder, in this regard, shall be entertained by DoT.

2.11.3 No interest shall be payable by DoT for the sum deposited as EMD.

2.11.4 The EMD shall be forfeited in the following cases:

a) Any information submitted by the bidder is found to be incorrect/forged.

b) If bid is withdrawn during the validity period or any extension agreed by DoT and

bidder thereof.

c) If the bid is modified in a manner not acceptable to DoT after opening of the bid.

d) If the bidder tries to influence the evaluation process.

e) If the successful bidder fails to sign the contract in accordance with clause 4.2

“Notification of award”.

2.11.5 In case of unsuccessful bidder, earnest money/bid security will be released on request

from the bidder on a date subsequent to the signing of contract with the successful

bidder.


Page 18 of 80

2.11.6 The bid security of the successful bidder will be returned after the bidder has signed the

Contract Agreement pursuant to clause 4.2 (Notification of award of Contract) and has

furnished the required Performance Bank Guarantee pursuant to clause 4.5.

2.11.7 DoT reserves the right to forfeit the earnest money or part thereof, in circumstances

which according to it indicate that the bidder is not earnest in accepting/executing any

order placed under specification.

2.12 Amendments in RFP Document

2.12.1 DoT may, in its absolute discretion, but without being under any obligation to do so,

update, amend or supplement the information in this RFP document.

2.12.2 At any time prior to the deadline for submission of the bids, DoT may amend the RFP

document by issuing addendum/corrigendum without notifying any bidder or without

giving any reason. Any addendum issued shall be part of the bidding document and shall

be communicated by the DoT on DoT and e-procurement/ e-tender websites. In case of

issuing addendum/ corrigendum, the last date of bid submission may be extended by DoT,

if felt necessary by DoT.

2.12.3 Prospective bidders shall promptly acknowledge such addendum/ corrigendum thereof,

in writing via email or fax. DoT will bear no responsibility or liability arising out of non-

receipt of the same in time or otherwise by the bidder.

2.12.4 The bidders are requested to refrain from requesting extension of time on any grounds

since the same will not be entertained by DoT.

2.12.5 No clarification obtained through verbal communication by the bidder with any employee

of DoT will be deemed as addendum/corrigendum to this RFP document. The bidder

acting on such a verbal communication will do so at his own risk and DoT shall bear no

responsibility for any outcome arising out of this.

2.13 Compliance with Mandatory Requirements

All proposals will be reviewed for compliance with the mandatory requirements as contained

within the RFP. Proposals deemed non-responsive will be eliminated from further consideration.


Page 19 of 80

2.14 Technical Proposal

2.14.1 For preparing the Technical Proposal, the bidders are advised to thoroughly examine this

RFP in detail. Any deficiencies in providing the information requested may result in

rejection of the Proposal/e-bid.

2.14.2 While preparing the Technical Proposal, the bidder must give particular attention to the

following:

Understanding of scope of work

Features of the proposed IT system

Architecture envisaged for the solution including Information security measures

Approach and Methodology for implementation and roll-out

Project plan

Training plan

Number and suitability of personnel planned to be deployed for this project. It is

desirable that these personnel be permanent employees of the firm or have an

extended and stable working relation with it.

Maintenance and Support.

2.14.3 The Technical Proposal shall not include any financial information. Bid which encloses

financial bid information/ part of financial bid in the technical bid shall be rejected

outright by DoT as being non-responsive.

2.14.4 The bidder shall submit the following documents with its technical proposal:

a) A forwarding letter on company letterhead of the bidder indicating the submission

of the bid signed by an authorised person holding the power of attorney (as per

Annexure-I).

b) Copy of demand draft of RFP Document Fee.

c) Copy of Bank guarantee/ demand draft of Earnest Money Deposit (EMD) (as per

the format provided at Annexure – XII).

d) Particulars of bidder as per Annexure-II.

e) Bill of Material (BoM) (if any) as per Annexure – IV that should include tentative

hardware, software, networking requirements for the project, required for the

bidder’s proposed solution. This should include details of quantity and


Page 20 of 80

configuration of servers, storage, switches, firewalls, internet connectivity

bandwidth etc. for all the tiers of deployment.

f) Summary of Profile of Key Personnel as per Annexure-V.

g) CVs of the personnel planned to be deployed for this project as per Annexure-VI

(Format for Submitting Profiles of key resources).

h) Details of past projects implemented by the bidder as per Annexure-VII (Details of

Past Projects Implemented by bidder).

i) Response to the Pre-Qualification Criteria given in the Annexure-VIII (Pre-

Qualification Criteria for bidders) along with supporting documents.

j) Response to the Technical Evaluation Parameter given in the Annexure-IX

(Technical Evaluation Criteria for bidders) along with supporting documents.

k) Undertaking and Self-Declaration by the bidder (as per the formats provided at

Annexure – XIV (a), (b) & (c)).

l) Signing of Integrity Pact (as per the format provided at Annexure – XV).

m) Financial capability statement (as per the format provided at Annexure – XVI).

n) Format for providing past project summary of bidders (as per the format provided

at Annexure – XVII).

o) Project Approach & Methodology

p) High level description of the proposed system

q) Project Implementation Plan

r) Training Schedule – including resources required for conducting the training

s) Operations and Maintenance Plan

t) Any other relevant form(s) and document(s) in compliance to the RFP

requirements.

2.15 Financial Proposal

2.15.1 Financial e-bid shall include the following document:

Sr. No. Document Type Document Format

1. Cover Letter - Financial Proposal Format

(Annexure-X) in PDF format.

On bidder’s letter head duly signed by

authorized signatory


Page 21 of 80

Note: Include Annexure-XI as annexure of

Annexure-X at the time of upload at e-

tender portal.

2. Financial Quote In the prescribed BoQ (Annexure X,

xls/xlsx/pdf file) provided at e-tender

portal

2.15.2 The bidder as part of its financial bid should account for all out of pocket and other

expenses including all permits, approvals, travel cost and licenses etc. that may be

required for completion of all items as mentioned in the scope of work of this RFP

document.

2.15.3 The Financial Proposal should include all the taxes, duties, cess, etc. apart from

GST/Service Tax which will be payable extra as applicable at the time of billing.

2.15.4 The prices/rates quoted by the bidder shall remain firm (fixed) during the entire Contract

Period and shall not be subject to any variation on any account. A bid submitted with

variable price quotation will be treated as non-responsive and hence shall be liable to be

rejected.

2.16 Terms & Conditions of Bidders

2.16.1 Any terms and conditions of the bidder will not be acceptable at any stage of bidding

process.

2.16.2 Any terms and conditions of the bidders mentioned in the bid will not be considered as a

part of their bids and/or contract.

2.17 Deviations in Terms and Conditions of RFP

2.17.1 No deviations in the terms and conditions as laid out in the RFP will be accepted.

2.17.2 The evaluation committee overseeing the RFP reserves the right to waive minor

irregularities. The evaluation committee also reserves the right to waive mandatory

requirements provided that all of the otherwise responsive bids fail to meet the same

mandatory requirements and/or doing so does not otherwise materially affect the

procurement. This right is at the sole discretion of the evaluation committee.

2.17.3 Bidders are advised to exercise adequate care in quoting the prices. No

modification/correction in the bids will be entertained after the bid submission date.

2.17.4 Provided that a Technical Proposal is substantially responsive, DoT may waive any non-

conformity or omission in the bid that does not constitute a material deviation. Further


Page 22 of 80

all non-material deviations included in the bid shall also be submitted in the format

prescribed in Annexure XVIII, no other non-material deviation apart from those

mentioned in Annexure XVIII shall be a part of this bid.

2.17.5 Provided that a Technical Proposal is substantially responsive, DoT may, at its discretion,

request the bidder to submit the necessary information or documentation, within a

reasonable period of time, to rectify nonmaterial nonconformities or omissions in the

Technical Proposal related to documentation requirements. Such omission shall not be

related to any aspect of the Financial Proposal of the bid. Failure of the bidder to comply

with the request may result in the rejection of its bid.

2.17.6 Provided that the Financial Proposal is substantially responsive, DoT will correct

arithmetical errors during evaluation of Financial Proposals on the following basis:

a) If there is a discrepancy between the unit price and the total price that is obtained

by multiplying the unit price and quantity, the unit price shall prevail and the total

price shall be corrected, unless in the opinion of DoT there is an obvious

misplacement of the decimal point in the unit price, in which case the total price

as quoted shall govern and the unit price shall be corrected; or

b) If there is an error in a total corresponding to the addition or subtraction of

subtotals, the subtotals shall prevail and the total shall be corrected; and

c) If there is a discrepancy between words and figures, the amount in words shall

prevail, unless the amount expressed in words is related to an arithmetic error, in

which case the amount in figures shall prevail subject to (a) and (b) above.

2.17.7 If the bidder does not accept the correction of errors, its bid shall be disqualified and its

bid security may be forfeited, or its bid securing declaration shall be executed.

2.18 Right to Publish

Throughout the duration of this bidding process and contract term, bidders must secure from

DoT, written approval prior to the release of any information that pertains to the potential work

or activities covered by this procurement or the subsequent contract. Failure to adhere to this

requirement may result in disqualification of the bid or termination of the contract.

2.19 Clarifications from Bidders

2.19.1 DoT may at its sole discretion contact the bidder for clarification of the response.


Page 23 of 80

2.19.2 DoT reserves the right to verify the credentials (including documents, declarations, self-

certifications) provided by the bidders by its own means and methods. In case DoT

receives feedback contrary to the responses of the bidder or is not satisfied with

compatibility of the experience with the required standards/expectations, DoT reserves

the right to form its own opinion and even reject the bids and forfeit the EMD.

2.19.3 DoT/ Evaluation Committee may use other sources of information in proposal evaluation

as required.

2.20 Due-diligence by Bidders

2.20.1 Each bidder should conduct its own study and analysis in order to respond to this RFP

document.

2.20.2 DoT makes no representation or warranty and shall incur no liability under any law,

statute, rules or regulations on any claim the potential bidder may make in case of failure

to understand the requirement and respond to the RFP document.

2.21 Collusive Proposal

2.21.1 Bidders and their employees, agents, advisors and any other person associated with the

bidder, must not engage in any collusive proposal, anti-competitive conduct or any other

similar conduct with any other bidder or any other person in relation to the preparation

or submission of bid.

2.21.2 In addition to any other remedies available under any law or any contract, DoT reserves

the right, in its sole and absolute discretion, to reject any submission lodged by a bidder

that engaged in any collusive proposal, anti-competitive conduct or any other similar

conduct with any other bidder or any other person in relation to the preparation or

lodgement of proposals, and further the EMD/PBG may be invoked.

2.22 Fraud and Corrupt Practices

2.22.1 The bidders and their respective officers, employees, agents and advisers shall observe

the highest standard of ethics during the bidding Process. Notwithstanding anything to

the contrary contained herein, DoT may reject any submitted bid without being liable in

any manner whatsoever to the bidder if it determines that the bidder has, directly or

indirectly or through an agent, engaged in corrupt practice, fraudulent practice, coercive

practice, undesirable practice or restrictive practice in the bidding Process.


Page 24 of 80

2.22.2 DoT may also initiate appropriate legal action under relevant Indian laws against the

bidder found indulging in fraud and corrupt practices.

2.22.3 Without prejudice to the rights of DoT hereinabove, if an bidder is found by DoT to have

directly or indirectly or through an agent, engaged or indulged in any corrupt practice,

fraudulent practice, coercive practice, undesirable practice or restrictive practice during

the bidding process, such bidder shall not be eligible to participate in any tender/RFP

issued by DoT for a period of 2 (two) years from the date such bidder is found by DoT to

have directly or indirectly or through an agent, engaged or indulged in any corrupt

practice, fraudulent practice, coercive practice, undesirable practice or restrictive

practice, as the case may be.

2.22.4 Misrepresentation and/or improper response by any bidder may be lead to

disqualification of the bidder. If any such disqualification are detected at any stage of

bidding process/implementation, such bidders are liable to be blacklisted.

2.22.5 Bids, which in the opinion of DoT, have been completed with the improper assistance of

employees of DoT and ex-employees of DoT, or with the utilization of information

unlawfully obtained from DoT, will be excluded from further consideration and shall be

rejected.

2.22.6 For the purposes of this section, the following terms shall have the meaning hereinafter

respectively assigned to them:

a) “Corrupt practice” means the offering, giving, receiving, or soliciting, directly or

indirectly, of anything of value to influence the actions of any person connected

with the bidding Process

b) “Fraudulent practice” means a misrepresentation or omission of facts or

suppression of facts or disclosure of incomplete facts, in order to influence the

bidding Process;

c) “Coercive practice” means impairing or harming or threatening to impair or harm,

directly or indirectly, any person or property to influence any person’s participation

or action in the bidding Process

d) “undesirable practice” means establishing contact with any person connected with

or employed or engaged by DoT with the objective of canvassing, lobbying or in

any manner influencing or attempting to influence the bidding Process;

e) “Restrictive practice” means forming a cartel or arriving at any understanding or

arrangement among Applicants with the objective of restricting or manipulating a

full and fair competition in the bidding Process.


Page 25 of 80

2.23 Conflict of Interest

2.23.1 DoT requires the bidders to provide professional, objective, and impartial advice and at

all times hold DoT's interests paramount

2.23.2 The bidders should strictly avoid conflicts with other assignment or their own corporate

interests and act without any consideration for future work.

2.23.3 Neither the selected bidder nor any of its personnel shall engage in any personal, business

or professional activity which conflicts or could conflict with any of their obligations in

relation to this Project.

2.23.4 A bidder may be considered to be in a conflict of interest with one or more parties in this

bidding process if, including but not limited to:

a) have controlling shareholders in common; or

b) receive or have received any direct or indirect subsidy from any of them; or

c) have the same legal representative for purposes of this bid; or

d) have a relationship with each other, directly or through common third parties, that

puts them in a position to have access to information about or influence on the bid

of another bidder, or influence the decisions of DoT regarding this bidding process;

or

e) A bidder participates in more than one bid in this bidding process. Participation by

a bidder in more than one bid will result in the disqualification of all bids in which

it is involved.

f) A bidder or any of its affiliates participated as a consultant in the preparation of

the design or technical specifications of the goods and services that are the subject

of the bid.

2.24 Integrity Pact

The pact essentially envisages an agreement between the prospective vendors/ bidders and the

buyer, committing the persons/ officials of both sides, not to resort to any corrupt practices in

an aspect/ stage of the contract. Only those vendors/ bidders, who commit themselves to such a

Pact with the buyer, would be considered competent to participate in the bidding process. In

other words, entering into this Pact would be a preliminary qualification. The essential

ingredients of the Pact include:


Page 26 of 80

a) Promise on the part of the DoT not to seek or accept any benefit, which is not legally

available;

b) DoT to treat all bidders with equity and reason;

c) Promise on the part of bidders not to offer any benefit to the employees of the DoT

not available legally;

d) Bidders not to enter into any undisclosed agreement or understanding with other

bidders with respect to prices, specifications, certifications, subsidiary contracts, etc.

e) Bidders not to pass any information provided by DoT as part of business relationship

to others and not to commit any offence under PC/ IPC Act,

f) Foreign bidders to disclose the name and address of agents and representatives in

India and lndian Bidders to disclose their foreign principals or associates;

g) Bidders to disclose the payments to be made by them to agents/ brokers or any other

intermediary,

h) Bidders to disclose any transgressions with any other company that may impinge on

the anti-corruption principle.

2.25 Opening of e-Bids

2.25.1 Opening of technical e-Bid

i) The DoT will open all technical e-Bids, in the presence of Bidder`s representatives who

choose to attend the bid opening process on the prescribed date and time of opening

at the prescribed venue as mentioned in RFP clause 1.2.

j) The Bidder's representatives who are present shall sign a register evidencing their

attendance. In the event of the specified date of e-Bid opening being declared a

holiday for DoT, the e –bids shall be opened at the appointed time and place on the

next working day.

2.25.2 Opening of financial e-Bid

a) After evaluation of technical e-Bid, through the evaluation committee the DoT shall

notify those Bidders whose technical e-Bids were considered non-responsive to the

conditions of the contract and not meeting the technical specifications and

qualification requirements indicating that their financial e-Bids will not be opened.


Page 27 of 80

b) DoT will simultaneously notify the Bidders, whose technical e-Bids were considered

acceptable to the Department. The notification may sent by e-mail provided by

Bidder.

c) The financial e-Bids of technically qualified Bidders shall be opened in the presence of

Bidders who choose to attend. The date and time for opening of financial bids will be

communicated to the technically qualified Bidders subsequently after completion of

technical bids evaluation through e-mail provided by the Bidder. The name of Bidders,

percentage price quoted for various items etc. will be announced at the meeting.

2.25.3 Correction of Errors

a) Financial Bids determined to be responsive will be checked by the DoT for any

arithmetic errors. Where there is a discrepancy between the rate quoted in the

Financial Bid, in figures and in words, the amount in words will prevail over the

amounts in figures, to the extent of such discrepancy.

b) The amount stated in the Financial Bid will be adjusted by the DoT in accordance with

the above procedure for the correction of errors and shall be considered as binding

upon the Bidder. If the Bidder does not accept the corrected quoted rate of e-Bid, his

e-Bid will be rejected, and his Bid Security shall be liable for forfeiture in accordance

with the RFP conditions.

2.25.4 Conditions of eligibility of Bidder

a) Bidders must carefully examine the eligibility criteria as provided in Annexure-VIII:

Pre-Qualification Criteria. The Bidder has to meet all the eligibility criteria set out to

be eligible for technical & financial evaluation.

2.26 Confidentiality

2.26.1 After the opening of bids, information relating to the examination, clarification,

evaluation and comparison of bids, and recommendations concerning the award of

contract shall not be disclosed to bidders or other persons not officially concerned with

such process.

2.26.2 Any effort by a bidder to influence DoT or others connected in the process of examination,

clarification, evaluation and comparison of bids, and in decisions concerning the award of

Contract, may result in the rejection of his bid.

2.26.3 No bidder shall contact DoT on any matter relating to its bid, from the time of the opening

of bids to the time the contract is awarded. Any effort of the bidder to influence DoT in


Page 28 of 80

its decision in respect of bid evaluation, bid comparison or award of the contract shall

result in the rejection of the bid and forfeiture of the bid security. During the bid

preparation process, bidders will focus their inquiries and communications, if any, to only

the authorized nodal officer of DoT.

2.26.4 Canvassing in connection with “Request for Proposal” is strictly prohibited. The submitted

bid of the applicant who resorts to canvassing is liable to be rejected. Bid containing

uncalled remarks or any additional conditions are liable to be rejected.

2.27 Taxes & Duties

2.27.1 All Custom Duties, Excise Duties and any other Taxes, Duties, Cess and Levies payable by

the bidder in respect of any transaction for procuring any services, components, sub-

assemblies, raw-materials and equipment shall be included in the bid price and no

separate claim on this behalf will be entertained by DoT.

2.27.2 As regards the Income Tax, surcharge on Income Tax and other taxes including tax

deduction at source, the bidder shall be responsible for such payment to the concerned

authorities within the prescribed period.

2.27.3 Statutory variation in GST/Service Tax in India during the contractual period shall be to

DOT’s account.

2.28 Return of Information to DoT

DoT reserves the right, in its sole and absolute discretion, to demand that at any stage all written

information provided by DoT (whether confidential or otherwise and without regard to the type

of media on which such information was provided to any bidder, including all copies of such

information) be:

a) Returned to DoT, in which case the bidder must promptly return all such information

to the address identified by DoT; or

b) Destroyed by the bidder, in which case the bidder must promptly destroy all such

information and provide DoT with written certification that it has been destroyed.

2.29 False or Misleading Claims

DoT may in its absolute discretion exclude or reject any proposal that in the opinion of DoT

contains any false or misleading claims or statements. DoT has no liability to any person or agency

for excluding or rejecting any such proposal.


Page 29 of 80

2.30 Assignment/ Sub Contract

Successful bidder shall not assign the project to any other agency, in whole or in part other than

cloud infrastructure services, to perform its obligation under the contract, without DoT’s prior

written consent. Any sub-contracting request shall be addressed to DoT for prior permission.

2.31 Intellectual Property Rights (IPR) Indemnity

2.31.1 The bidder shall, indemnify and hold harmless the DoT and its employees and officers

from and against any and all suits, actions or administrative proceedings, claims,

demands, losses, damages, costs, and expenses of any nature, including attorney’s fees

and expenses, which the DoT may suffer as a result of any infringement or alleged

infringement of any patent, utility model, registered design, trademark, copyright, or

other IPR registered or otherwise existing at the date of the contract by reason of:

a) The installation of the Products/Services by the Bidder or the use of the

Products/Services in the country where the Site is located; and

b) The sale in any country of the products produced by using the Products/ materials

purchased under the contract.

2.31.2 Such indemnity shall not cover any use of the Products/Services or any part thereof other

than for the purpose indicated by or to be reasonably inferred from the Contract, neither

any infringement resulting from the use of the Products/Services or any part thereof, or

any Products/Services produced thereby in association or combination with any other

equipment, plant, or materials not supplied by the Bidder, pursuant to the Contract.

2.31.3 If any proceedings are brought or any claim is made against the DoT out of the matters

referred to above, the DoT shall promptly give the Bidder a notice thereof, and the bidder

shall at its own expense and in the DoT’s name conduct such proceedings or claim and

any negotiations for the settlement of any such proceedings or claim.

2.31.4 If the Bidder fails to notify the DoT within fifteen (15) days after receipt of such notice

that it intends to conduct any such proceedings or claim, then the DoT shall be free to

conduct the same to the cost of Bidder.

2.31.5 The DoT shall, at the Bidder’s request, afford all available assistance to the Bidder in

conducting such proceedings or claim, and shall be reimbursed by the Bidder for all

reasonable expenses incurred in so doing.


Page 30 of 80

2.32 Criminal Charges and Conviction

The Bidder warrants that it has disclosed and will continue to disclose during the term of this

Contract full details of all criminal convictions and all pending criminal charges against it or any

of its personnel and associates that would reasonably be expected to adversely affect the Bidder

and the company who owns the patent of the technology being offered or the Bidder’s capacity

to fulfil its obligations under this contract.


Page 31 of 80

3 Evaluation of Bids/Proposals

Bids/Proposals will be reviewed by a Committee constituted by the DoT or its designated

representative(s). The DoT, or such other authority designated by the DoT, as the case may be, is

also referred to herein as the Evaluation Committee (or “Committee”).

3.1 Opening of Bids

DoT would open the proposal as specified in section 2 and subsequently examine and evaluate

the bids in accordance with the provisions set out in clause 3.4.

3.2 Initial Determination of Compliance with RFP Requirements

3.2.1 The Committee will perform an initial review of all proposals that are submitted on time.

After initial review, the Committee may recommend discontinuing the evaluation of any

proposal which it considers unacceptable prima facie for any reason such as:

a) The proposal is not a reasonable effort to respond to the requirements of the RFP; or

b) The proposal contains technical deficiencies, such as not all the requirements of the

solution are addressed and proposed solution is not in accordance with the

requirements of the DoT.

c) The bidder shall provide all supporting documents for all the information submitted

as a part of this RFPs response. Any claim without the required supporting document

would not be considered for the purpose of scoring. The supporting documents

submitted must be valid as on the date of submission of the bids.

3.3 Correction of Errors

3.3.1 Bidders are advised to exercise adequate care in quoting the prices. No

modification/correction in quotations will be entertained once the bids/proposals are

submitted. Even before submission of the proposal, care should be taken to ensure that

any corrections/overwriting in the proposal are initialed by the person signing the

proposal form.

3.3.2 In case of discrepancy between the amounts mentioned in figures and in words, the

amount in words shall be considered final.

3.4 Bid Evaluation Procedure

3.4.1 To establish the bidder’s competency and capabilities, it is proposed that the evaluation

of the bids will be done in two stages as mentioned below:


Page 32 of 80

Stage-1:

Evaluation of Pre-Qualification Proposal to establish the Eligibility Claim.

Evaluation of Technical Proposal

Stage-2:

Evaluation of Financial Proposal

On each of these parameters, the bidders would be required to meet the qualification/

evaluation criteria as detailed in subsequent sections.

All those bids meeting the Pre-Qualification Criteria would progress to the next level

of evaluation i.e. Technical Bid Evaluation.

Post technical evaluations, only the technically qualified bids would progress to next

level of evaluation i.e. Financial Bid Evaluation.

3.4.1.1 Stage-1 of Evaluation of Technical Proposal

At this stage, only Pre-Qualification and Technical proposal would be considered.

Financial bids/proposals would not be opened at this stage.

Evaluation of Pre-qualification Proposal:

An “Evaluation Committee” would perform an initial review of the pre-qualification

proposals and they shall be scrutinized for the responsiveness as set in the pre-

qualification criteria, and for the completeness of required supporting documents as

required to establish the Eligibility Claim.

The pre-qualification criteria is listed out in Annexure-VIII.

Evaluation of Technical Proposal:

Technical Evaluation of only eligible bidders would be carried out in the following manner:

a) The bidder’s technical solutions proposed in the bid document will be evaluated as

per the requirements specified in the RFP and bidder is required to provide details on

the proposed solution adopting the evaluation framework given in Annexure-IX.

b) Proposal Presentations: The Committee if required, may invite each bidder to make

a presentation to the DoT at a date, time and locations determined by the DoT. The

purpose of such presentations would be to allow the bidders to present their

proposed solution to the committee as per serial 4 and 5 of Annexure IX.


Page 33 of 80

c) The Evaluation Committee may undertake written clarifications from the bidders. The

primary function of clarification in the evaluation process is to clarify ambiguities and

uncertainties, if any, arising out of the evaluation of the bid documents.

d) Upon technical evaluation of each bid inline with a, b and c mentioned above and

Annexure IX a “Technical marks” out of a maximum of 100 marks will be assigned to

every bid.

e) The bidders who score 70 or more marks in technical bid, will qualify for the

evaluation of the financial bid.

f) The bidder with the highest marks in technical bid will be awarded 100 “Technical

Score” and subsequently others bidders will also be awarded “Technical Score”

relative to the highest technical marks for the final composite score calculation

purpose e.g. if the highest technical marks is 90 then “Technical Score” is (90/90) ×

100 = 100, hence the bidder with highest technical marks will score 100 “Technical

Score”. Similarly another bidder who scored 80 marks, will get (80/90) x 100 = 88.88

“Technical Score”. Following formula will be used for the “Technical Score” (TS)

calculation:

𝑇𝑒𝑐ℎ𝑛𝑖𝑐𝑎𝑙 𝑆𝑐𝑜𝑟𝑒 (𝑇𝑆) =(𝐵𝑖𝑑𝑑𝑒𝑟′𝑠 𝑇𝑒𝑐ℎ𝑛𝑖𝑐𝑎𝑙 𝑀𝑎𝑟𝑘𝑠 (𝐵𝑇𝑀))

(𝐻𝑖𝑔ℎ𝑒𝑠𝑡 𝑇𝑒𝑐ℎ𝑛𝑖𝑐𝑎𝑙 𝑀𝑎𝑟𝑘𝑠 (𝐻𝑇𝑀))× 100

g) The details of technical evaluation parameters are provided at Annexure-IX.

3.4.1.2 Stage-2 Evaluation of Financial Proposal

The evaluation will be carried out if financial bids are complete and computationally

correct. The lowest financial bid will be awarded “Financial Score” of 100. The “Financial

Score” of other bidder(s) will be computed by measuring the financial bids against the

lowest financial bid. Following formula will be used for calculating “Financial Score”:

𝐹𝑖𝑛𝑎𝑛𝑐𝑖𝑎𝑙 𝑆𝑐𝑜𝑟𝑒 (𝐹𝑆) =(𝐿𝑜𝑤𝑒𝑠𝑡 𝐹𝑖𝑛𝑎𝑛𝑐𝑖𝑎𝑙 𝐵𝑖𝑑 (𝐿𝐹𝐵))

(𝐵𝑖𝑑𝑑𝑒𝑟′𝑠 𝐹𝑖𝑛𝑎𝑛𝑐𝑖𝑎𝑙 𝐵𝑖𝑑 (𝐵𝐹𝐵))× 100


Page 34 of 80

3.4.1.3 Stage-3 Computation of Composite Bid Score

The “Composite Bid Score” is a weighted average of the Technical and Financial Scores.

The ratio of Technical and Financial Scores is 80:20 respectively. The Composite Bid Score

will be derived using the following formula:

Composite Bid Score = ((TS × 0.80) + (FS × 0.20))

The responsive bidder(s) will be ranked in descending order according to the Composite

Bid Score, which is calculated based on the above formula. The highest-ranking bidder as

per the Composite Bid Score will be selected for award of contract.

3.5 Site Visit by DoT

As part of the evaluation process, DoT and/or any agency selected by DoT shall be allowed to visit

and examine/verify the bidder’s system capabilities as defined in the Technical Proposal. The

bidder, if asked by DoT, shall arrange and facilitate such visit. The cost of such visits to the Sites

shall be at DoT’s expense.

3.6 Best Value Determination and Final Evaluation

3.6.1 Only those bidders who qualify the Stage-I evaluation shall be considered for Stage-II

evaluation. Financial Proposals will be opened for the bidders who cleared Stage-I

evaluation. Minimum Marks required for any bidder to be qualified for opening of

financial bid is 70.

3.6.2 Financial bid evaluation will be done on total prices excluding GST/Service Tax as quoted

in Annexure X.

3.6.3 Proposals will be evaluated on the basis of Quality cum Cost based Selection-(QCBS)

method.

3.6.4 The bid having the highest composite bid score (as per 3.1.4.3) will be selected for the

project.


Page 35 of 80

4 Award of Contract

DoT shall reserve the right to negotiate with the bidder whose proposal has been ranked first by

the committee on the basis of highest CBS. Following finalization of selected bid, the contract

shall be signed in accordance with Master Service Agreement (Volume III of the RFP document).

DoT reserves the right to present a contract to the bidder selected for negotiations. A contract

will be awarded to the responsible, responsive bidder whose proposal conforms to the RFP and

is, in the opinion of DoT, the most advantageous and represents the best value to the project,

price and other factors considered. Evaluations will be based on the proposals and any additional

information requested by the DoT.

The final contract must stipulate that the overall solution will satisfy the requirements as stated

in the RFP document. On acceptance of proposal for awarding the contract, DoT will notify the

successful bidder in writing or by fax or email that their proposal has been accepted. After signing

of the Contract Agreement, no variation in or modification of the term of the contract shall be

made except by written amendment signed by both parties.

DoT reserves the right to award the contract, based on initial offers received or otherwise,

without discussion and without conducting any further negotiations. Further, the selected bidder

may not re-assign any award made as the result of this RFP, without prior written consent from

DoT.

4.1 DoT’s Right to Accept or Reject Any or All Proposals

DoT reserves the right to accept or reject any proposal, and to annul the RFP process and reject

all proposals at any time prior to award of contract, without incurring any liability to the affected

bidder or bidders or any obligation to inform the affected bidder or bidders of the grounds for

DoT’s action.

4.2 Notification of Award

The successful bidder who will score highest composite bid score shall be notified by the DoT in

writing or by fax or email, that its proposal has been accepted (hereinafter the “Letter of Intent”),

prior to the expiration of the period of validity of the proposals. The receipt of this letter shall be

acknowledged by the successful bidder in writing and shall send its acceptance letter (hereinafter

the “Letter of Acceptance”) along with the required Performance Bank Guarantee to enter into

the Contract within fifteen (15) days from the receipt of the Letter of Intent. Upon the successful

furnishing of performance bank guarantee by the successful bidder, contract signing process will

take place. In case the successful bidder is unable to furnish the performance bank guarantee,

DoT may invite the bidder second in order of composite marks.


Page 36 of 80

4.3 Signing of Contract

Once the DoT notifies the successful bidder that its proposal has been accepted, pursuant to the

bidder for acknowledging the Letter of Intent (LoI), the successful bidder and DoT shall promptly

sign the Contract. This shall be subject to the furnishing of the Performance Bank Guarantee

(PBG) as stated in clause above. DoT shall have the right and authority to negotiate certain terms

with the successful bidder before signing of the Contract. The signing of the Contract shall

amount to award of the Contract and the successful bidder shall initiate the execution of the

work as specified in the Contract.

4.4 Contract Period

The contract period shall be 5 years from the date of Go-Live. After the end of the contract

period, DoT reserves the right to either continue with the existing bidder with either same or

revised terms and conditions as mutually agreed by both parties or sign a contract with other

agency.

4.5 Performance Bank Guarantee

4.5.1 The successful bidder shall at its own expense deposit with DoT, within fifteen (15)

working days of the date of receipt of Letter of Intent of the contract or prior to signing

of the contract whichever is earlier, an unconditional and irrevocable Performance Bank

Guarantee (PBG) from a scheduled bank acceptable to DoT, payable on demand, for the

due performance and fulfillment of the contract by the bidder.

The Performance Bank Guarantee will be as follows:

Schedule to Provide PBG Performance Bank Guarantee

At the award of contract as described in clause 4.2 and 4.5 of Volume-II of this RFP

10% of the Total Price (serial 3 of Annexure X)

4.5.2 All incidental charges whatsoever such as premium, commission etc. with respect to the

Performance Bank Guarantee shall be borne by the bidder. The successful bidder shall

ensure that the Performance Guarantee is valid at all times during the Term of the

contract (including any renewal) and for a period of 180 days beyond all the contractual

obligations/ completion of contract period/ tenure of the appointment.

4.5.3 In the event of the bidder being unable to service the contract for whatever reason, DoT

will encash the PBG. Notwithstanding and without prejudice to any rights whatsoever of

DoT under the contract in the matter, the proceeds of the PBG shall be payable to DoT

as compensation for the bidder’s failure to perform/comply with its obligations under


Page 37 of 80

the contract. DoT shall notify the bidder in writing of the exercise of its right to receive

such compensation within 14 days.

4.5.4 Before encashing the PBG, the vendor will be given an opportunity to represent before

DoT. The decision of DoT on the representation given by the vendor shall be final and

binding. If circumstances so warrant, the matter may be referred to an arbitrator(s) as

appointed under section on Arbitration and Legal Jurisdiction in Volume III of this RFP.

4.5.5 The PBG is required to protect DoT against the risk of selected bidder's conduct, which

would warrant the PBGs forfeiture.

4.6 Annulment of Award

Failure of the successful bidder to comply with pre-qualification criteria, evaluation criteria and

other terms and conditions set out in the RFP document shall constitute sufficient ground for the

annulment of the award of contract, in which event DoT may make the award to the bidder who

scored second highest composite marks or may call for new bids.

4.7 Appointment Tenure

4.7.1 The tenure of appointment shall be valid for a term of 5 years post Go-live of RMS.

4.7.2 The tenure of appointment of the selected bidder will end if:-

a) Bidder contravenes the conditions/clauses as specified in the contract with DoT; or

b) At the end of the tenure as specified in the Letter of Appointment.

4.8 Exit/ Suspension/ Termination of Contract with Selected Bidder

No order of suspension or termination of contract with the selected bidder would be issued by

DoT, except after conducting an enquiry by a designated officer of DoT, authorized in this regard.

The grounds for suspension/ termination of the selected bidder may include inter alia

4.8.1 Contravention of the conditions/ clauses as would be specified in the Contract/ Letter

of Appointment/Work Order.

4.8.2 Inability to perform the duties and requirements as would be specified in the contract.

4.9 Transfer of assets in case of Expiry/ Suspension/ Termination of Contract

4.9.1 In case of expiry or suspension or termination of contract, the selected bidder may be

directed by DoT to continue all services and also to maintain all project assets including


Page 38 of 80

application software, databases, system software, hardware and networking, including

documents or any other relevant material that may be in its custody or control, relating

to its activities as Selected Bidder as per the terms and condition mentioned in clause 14

and 15 of Vol III of this RFP.

4.9.2 Termination of the selected bidder shall be with immediate effect and would be subjected

to the directions of DoT. In such a situation, DoT may direct selected bidder to continue

discharging its role and responsibilities in the transition phase, and/or appoint an

administrator to take over the project assets and the management of selected bidder

functions and/or appoint any agency to take over the project assets and the management

of the selected bidder functions, and/or appoint a successor selected bidder and:

a) Transfer all or part of the project assets and the management of the selected bidder

functions to the new selected bidder, and/or

b) Determine the residual value of the project assets based on guidelines or fair value

as determined by DoT, or

c) Ensure smooth transfer of project assets both tangible and intangible to the new

Selected Bidder.


Page 39 of 80

5 Other General Terms and Conditions

5.1 Relationship between the Parties

Nothing mentioned herein shall be constructed as relationship of master and servant or of

principal and agent as between ‘DoT’ and the ‘Bidder’. The bidder, subject to this contract will

have complete charge of its personnel (and third parties, if any), performing the services under

this project from time to time. The bidder shall be fully responsible for the services performed by

them or on their behalf hereunder.

5.2 Standards of Performance

The bidder shall perform the services and carry out their obligations under the contract with due

diligence, efficiency and economy in accordance with generally accepted professional standards

and practices. The bidder shall always act in respect of any matter relating to this contract as

faithful advisor to DoT. The bidder shall always support and safeguard the legitimate interests of

DoT, in any dealings with the third party. The bidder shall abide by all the provisions/ Acts/ Rules

etc. of Information Technology prevalent in the country and conform to the standards laid down

in this RFP document, in totality.

5.3 Delivery and Documents

5.3.1 The applicant shall submit all the deliverables on due date as per the delivery schedule.

The bidder shall not without DoT’s prior written consent disclose the contract, drawings,

specifications, plans, patterns, samples to any person/ agency other than an entity

employed by DoT for the performance of the contract. In case of termination of the

contract, the entire document(s) used by applicant in the execution of project shall

become property of DoT.

5.3.2 The bidder shall also provide all necessary documentation like user manuals, license

certificates, brochures etc. as mentioned in section 5.21 of Vol. I of this RFP as part of the

deliverables.

5.3.3 The bidder shall provide all necessary support whenever requested by DoT during the

period of pilot implementation.


Page 40 of 80

5.4 Governing Language for Assignment

The contract shall be written in ‘English Language’. English version of the contract shall govern

its interpretation. All correspondences and other documents pertaining to the contract, which

are exchanged between the parties, shall be written in the English Language.

5.5 Suspension

DoT may, by written notice to bidder, suspend all payments under dispute to the bidder

hereunder if the bidder fails to perform any of its obligations under this contract including the

carrying out of the services, provided that such notice of suspension-

a) Shall specify the nature of failure.

b) Shall request the bidder to remedy such failure within a period not exceeding thirty (30) days

after receipt by the bidder of such notice of failure.

5.6 Notice

Any notice, request or consent required or permitted to be given or made pursuant to this

contract shall be in writing. Any such notice, request or consent shall be deemed to have been

given or made when delivered in person to an authorized representative of the party to whom

the communication is addressed, or when sent to such party at the address mentioned in the

Contract Agreement.

5.7 Progress of the Project

The bidder would be required to intimate the progress of the project to DoT in a frequency and

manner as may be prescribed post mutual consultation and agreement with the bidder after the

award of contract.

5.8 Forfeiture of Performance Bank Guarantee

5.8.1 In case of a successful bidder, the PBG submitted by the bidder shall be forfeited under

the following conditions:

a) If the bidder violates any such important conditions of this RFP.

b) If the bidder indulges any such activities as would jeopardize the interest of DoT in

timely finalization of this RFP document.


Page 41 of 80

5.8.2 The decision of DoT regarding forfeiture of PBG shall be final and in case of dispute this

will be governed by the section on Arbitration and Legal Jurisdiction in Volume-III of

this RFP.

5.9 Probity & Publicity

5.9.1 DoT shall require all the bidders to:

a) Declare any actual or potential conflict of interest.

b) Not collude with any other bidder or any other contractor who is a potential bidder.

c) Comply with all laws in force in India applicable to the bidding procedure.

d) Not attempt to influence the outcome of the bidding procedure by offering any

employment, payment or any other incentive to or in any way seek to improperly

influence any person employed/ engaged by DoT.

e) Not make any press releases or responses to media enquiries and questions pertaining

to this process or the subsequent selection process without DoT‘s written approval.

5.9.2 If the bidders act contrary to these requirements, DoT reserves the right to:

a) Terminate negotiations

b) Terminate consideration of the bid and

c) Terminate any contract that may have been executed by DoT with such bidder

without any obligation on DoT to make any payments to the bidder.

5.10 Reservation of Rights

DoT reserves the right to:

5.10.1 Extend the Closing Date for submission of the bids.

5.10.2 Amend the bid requirements at any time prior to the closing date, provided that the

amendment is notified to prospective bidders.

5.10.3 Seek information from or negotiate with one or more of the bidders on any issue at

any time and to continue to negotiate with one or more of the bidders.

5.10.4 Discontinue negotiations at any time with any bidder.

5.10.5 Terminate or abandon this procedure or the entire project before or after the receipt

of bids.

5.10.6 Seek the advice of external consultants to assist DoT in the evaluation or review of bids.


Page 42 of 80

5.10.7 Make enquiries of any person, company or organization to ascertain information

regarding the bidder and their bid.

5.10.8 Reproduce for the purpose of this procedure the whole or any portion of the RFP

document despite any copyright or other intellectual property right that may subsist

in the RFP document.

5.11 Extension of Contract

DoT reserves the right to extend the contract with the Terms & Conditions mutually agreed by

both the parties. The extension of the contract will be based on the performance of the bidder

during the contract period which will be reviewed by DoT on yearly basis.

5.12 Breach of Statutes

The successful bidder shall indemnify DoT against all penalties and liabilities of every kind of

breach of any Statutes, Ordinance, Rules and Regulations or By-laws as may be applicable for and

in the execution of the contract.

5.13 Waiver

5.13.1 Any waiver by DoT of any breach of the terms or conditions of the contract shall not

constitute waiver of any subsequent breach of the same.

5.14 Project Timelines

5.14.1 Please refer Volume-I of this RFP document for the DoT envisaged timelines for the

execution of this project. Bidders are required to submit a detailed Work Plan

indicating phase wise activities and timelines to complete each activity as listed.

Bidders should also indicate any dependencies in any of these activities which may

result in any considerable delays/ deviations from the work plan.

5.15 Miscellaneous

5.15.1 The end product of the work assignment carried out by the bidder, in any form, will be

the sole property of DoT.

5.15.2 In the event the applicant’s/ bidder’s company or the concerned division of the

company is taken over/ bought over by another company, all the obligations under the

agreement with DoT, should be passed on the compliance by the new company/ new

division in the negotiation for their transfer.


Page 43 of 80

6 Payment Schedule

The payment schedules for the implementation of Revenue Management System and Operations

& Maintenance phase are as follows:

50% of Total Cost of Design, Development, Implementation and Maintenance of Revenue

Management System for DoT (as quoted at serial no. 1 of Annexure X of Vol II) would have been

paid out to SI the time of Go-Live, and balance payment of 50% will be paid out in equal parts

over the rest of the 5 (five) years based on the achievements of milestones/ quality of services

provided by selected bidder.

S. No. Payments % of Cost (as quoted at serial no. 1 of

Annexure X of Vol II)

Payment not Before

A. Implementation Phase

1. SRS sign-off 10% T+6

2. Setting up of cloud platform for application hosting

15% T+20

3. Revenue Management System Go-Live 25% T+36

B. Maintenance Phase

1. Twenty quarterly instalments over Five years from the “Go-Live” date, each instalment being a maximum of 2.5% of total contract value depending upon the quarterly performance level assessed on the basis of SLAs defined in this RFP.

50% Quarterly


Page 44 of 80

Annexure-I: Cover Letter

[To be submitted on Bidder Company’s Letterhead]

Date: To: Director – Licensing Finance Assessment Department of Telecommunication Sanchar Bhawan, 20 Ashoka Road New Delhi – 110001 Sub: Proposal for Selection of System Integrator for the Design, Development, Implementation and

Maintenance of Revenue Management System for DoT

Dear Sir,

With reference to your RFP document dated 27/Mar/2018, we, having examined the

Bidding Documents and understood their contents, hereby submit our Proposal for the aforesaid

Project. The Proposal is unconditional and unqualified.

1 All information provided in the Proposal and in the Appendices to it is true and correct and

the documents accompanying such Proposal are in original or true copies of their respective

originals, as the case may be.

2 This statement is made for the express purpose of qualifying as a Selected Bidder for System

Implementation and its Maintenance and Operation thereof for 5 years for DoT.

3 We shall make available to DoT any additional information it may find necessary or require

to supplement or authenticate the Proposal.

4 We acknowledge the right of DoT to reject our Proposal without assigning any reason or

otherwise and hereby waive our right to challenge the same on any account whatsoever.

5 We declare that, we have examined and have no reservations to the RFP Documents,

including any Addendum issued by DoT.

6 We understand that you may cancel the Bidding Process at any time and that you are neither

bound to accept any Proposal that you may receive nor to invite the Bidders to submit a

Proposal for the Project, without incurring any liability to the Bidders.

7 We believe that we satisfy the eligibility criteria and meet(s) the requirements as specified in

the RFP document.

8 We hereby irrevocably waive any right which we may have at any stage at law or howsoever

otherwise arising to challenge or question any decision taken by DoT in connection with the


Page 45 of 80

selection of the Bidder, or in connection with the Bidding Process itself, in respect of the

above mentioned Project and the terms and implementation thereof.

9 We agree to keep this offer valid for 180 days (one hundred eighty days) from the Proposal

Due Date specified in the RFP.

10 We agree and undertake to abide by all the terms and conditions of the RFP document.

We submit this Proposal under and in accordance with the terms of the RFP document.

Yours faithfully,

Date:

(Signature of the Authorized signatory)

Place: (Name and designation of the of the Authorized signatory)

(Name and rubber seal of the Bidder)

CERTIFICATE AS TO AUTHORIZED SIGNATORIES

Hereby it is certified that I Mr./Ms. ……………………………………. Company Secretary of the

firm/corporation ………………………….…………………………………, and that Mr./Ms.

………………………………. who has signed the above bid are authorized to bind the firm/corporation

by authorities of its governing body.

(Company Secretary)

Date & Place:


Page 46 of 80

Annexure-I I: Particulars of Bidder

Sr. No. Heads Particulars

1. Registered Name of the Firm

2. Type of Firm

(Proprietary/ Partnerships/ Private/Public) Please enclose self-certified copy of certificate of incorporation

3. Complete Address of Registered Office

4. Date and Country of Incorporation

5. Number of years of operations in India

6. Number and locations of offices in India

7. Contact person details (Name, Designation, Mobile Number, Email)

8. Telephone Number (with ISD & STD Code)

9. Fax Number (with ISD & STD Code)

10. Brief description of the Firm including details of

its main lines of business along with the brief

profile of the organization

11. Annual turnover from IT and ITeS operations for

FY 14-15, FY 15-16 and FY 16-17 (Enclose

Certificates duly signed by Chartered Accountant

along with seal which should also clearly show

the CA’s membership number]

12. CMMi assessment level and date of assessment

13. Validity period of the CMMi assessment

14. Please attach copy of PAN Card/ GST Registration

15. Any other relevant information

Signature of Authorised Signatory

Name of Designation of Authorised Signatory

Telephone & Mobile Number (with ISD & STD Code)

Fax Number (with ISD & STD Code)

E-Mail Address

Official seal of the Company


Page 47 of 80

Annexure-I II : Format for Request for Clarif ications

Bidder’s Request For Clarification

Name of Organization

submitting request:

Name & position of person

submitting request

Address of organization

including phone, fax, email

points of contact

<Name of bidding

company>

<Name of primary contact

person>

Address:

Tel:

Fax:

E-mail:

# Bidding Document

Reference (Volume/

Section/ Page No.)

Content as in RFP requiring

clarification

Query/ points of clarification

required

1

2

3

4


Page 48 of 80

Annexure-IV: Format for Submitting BOM

# Item Quantity Specifications Specific to DoT (Y/N and clarifications)

Software Components (including COTS, Bespoke, Third party software etc.)

1.

2.

3.

Cloud Platform Components 1.

2.

3.

Any Other Components 1.

2.

3.

Note:

1. Bidder is required to mention all the components that it proposes to be used for this

assignment. However, the successful bidder would be required to provide the actual BOM to

DoT after starting the UAT (User Acceptance Testing).

2. Bidder needs to specifically mention all components proposed to be used/procured specific

to DoT’s application and also clarify the extent of the component’s use for the same.


Page 49 of 80

Annexure-V: Summary of Profile of Key Personnel

# Role Qualification Years of

Experience

Profile Summary

1. Program Manager

2. Project Manager

3. Solution Architect

4. Business Analyst

5. Application Lead

6. Database Administrator

7. Others (Please specify)


Page 50 of 80

Annexure-VI: Format for Submitting Profi les of key resources

# Items Guidelines

1. Name of the personnel: <Name of the personnel>

2. Designation <Designation in bidding firm>

3. Proposed position for the project: <Responsibility Area in the project >

4. Qualification:

<Degree-1> o Academic institution graduated from o Year of graduation o Specialization (if any)

<Degree-2> o Academic institution graduated from o Year of graduation o Specialization (if any)

5. Professional Certifications: <No. of years>

6. Total years of experience <No. of years>

7. Years of experience in present company

<No. of years>

8. Experience of working on Government Projects

<Yes/No>

<No. of years>

<Project Reference – Names Only>

9. Experience of working on Turnkey System implementation Projects

<Yes/No>

<No. of years>

<Project Reference – Names Only>

10. Project wise IT professional experience details:

(Only relevant projects)

<Name of the project & client>

Key project features in brief

Relevance to DoT project in brief


Page 51 of 80

Annexure-VII: Format for providing details of past projects of the bidder

# Items Guidelines

1. Name of the project <Project Name>

2. Client Details <Client Name & Complete Address>

<Contact Person’s Name>

<Contact Number>

<Email ID>

3. Scope of the project <Provide short narrative description and details of the overall project scope>

4. Scope of the work done <Provide details of scope of work under contract>; <highlight key result areas expected and achieved>

5. Duration of the project <No. of Years/ Months>

<From: mmm/ yyyy> <To: mmm/ yyyy>

6. Relevant work area/domain <Specify the relevance of area of work/ domain relevant to the requirements of this RFP>

7. Location of the project <Specify the location of the project implementation>

8. No. of locations <Specify the no. of locations for implementation>

9. Contract Value <Provide particulars on contract value assigned to each major phase and milestone>


Page 52 of 80

Annexure-VIII : Pre-Qualif ication Criteria

Bidders should include this compliance checklist duly completed with their Pre-Qualification

Proposal:

# Basic Requirement Specific Requirements Documents Required

1 Legal Entity Should be Company registered under

Companies Act, 1956/2013

Or

a partnership firm registered under LLP

Act, 2008

Should have been operating in the area of

software development, implementation,

IT consulting for last five years before

date of submission of bid.

Certificates of

Incorporation/

Registration as

applicable

Relevant extracts of

Annual Report i.e.

Income Statement,

Balance Sheet, Cash-

flow Statement of

previous 5 years

2 Sales Turnover in

IT/ITES Operations

The Bidder should have average annual

turnover of INR 100 Crores from IT/ ITeS

and other IT related services (excluding

sale of hardware) in the last three

financial years (i.e. 2014‐2015, 2015‐2016

& 2016-2017)

Financial Capability

Statement in prescribed

format (Annexure – XVI)

3 Power of

Attorney

A board resolution OR power of attorney

in the name of the person executing the

bid, authorizing the signatory to commit

the Bidder.

Board Resolution

Or

Power of Attorney with

appropriate

supporting documents

4 Net Worth The bidder should have positive net-

worth at the time of bidding.

Financial Capability

Statement in prescribed

format (Annexure – XVI)

5 Technical

Capability

Bidder must have successfully completed

software project(s) of similar nature

involving complex business process, rule

engines and work flows or should have

executed software project(s) for Central

Board of Direct Taxes or GST (or

Commercial Taxes) or Central Board of

Annexure – XVII & VII

along with

Completion certificates

from the client;

OR


Page 53 of 80

Excise and Customs within India or should

have executed software project(s) for

non-tax revenue generating

department(s) or telecom sector

involving assessment processes within or

outside India.

Note:

Engagement(s) of value specified herein:

- One project with project value not less

than INR 8 Crores;

OR

- Two projects with each project value not

less than INR 4 Crores;

OR

- Three projects with each project value

not less than INR 3 Crores

Work order + Self

certificate of

completion (Certified

by the Authorised

Signatory/ Chartered

Accountant);

Note: The documents

supplied should clearly

mentioning the project

scope, project duration

(phase wise if any),

project value, project

start date etc.

6 Certifications The bidder should have valid CMMi level

3 Certification or higher at the time of

bidding

Copy of valid

certificates

7 Debarment The bidder should not be debarred for

fraudulent and corrupt practices by any

Government entity in India as on date of

bidding.

Undertaking of the


(Annexure – XIV (C))

8 Manpower

Strength

The bidder should have at least 300 plus

full time manpower resources on their

payroll.

Self-certification by the


9 Pre-contract

Integrity Pact

Integrity pact in the prescribed format Integrity pact in the

format prescribed

(Annexure – XV)

Note: all the submitted documents and annexures should have authorized signatory’s sign and

seal.


Page 54 of 80

Annexure-IX: Technical Evaluat ion Parameters

The technical proposal submitted by the implementation agency shall be evaluated as per the

technical evaluation parameters listed below. The bidder shall be required to make a technical

presentation of the proposed solution, project implementation plan and project maintenance

plan in front of the DoT officials. The date and time of the presentation will be communicated to

the bidders by DoT in due course of time.

Following table outlines the Technical Evaluation Parameters and Scoring Methodology based

on which evaluation of technical proposals of the bidders shall be carried out by DOT:

SN Criterion Max.

Marks

Supporting

Document

1 Relevant experience of executing software project(s)

(assessment study and implementation) involving complex

business processes, rule engine & work flows or have

worked for application development projects for Central

Board of Direct Taxes/ GST (or Commercial Taxes)/ Central

Board of Excise and Customs within India or on assessment

software in telecom sector within or outside India.

Note: Preference shall be given to the projects carried out

in Government/ Public sector domain and are substantially

completed i.e. completed or 70% completed. For 70%

completion please attach client certificate or payment

receipt confirmation.

The work order should have been issued within the last 5

years as on date of submission of bid:

a. Experience of executing 1 Projects – 4 Marks

b. Experience of executing 2 Projects – 8 Marks

c. Experience of executing 3 Projects – 12 Marks

d. Experience of executing 4 Projects – 16 Marks

e. Experience of executing 5 or more Projects – 20

Marks

20 Completion

certificates from

the client;

OR

Work order + Self

certificate of

completion

(Certified by the

Authorised

Signatory/

Chartered

Accountant);

OR

Work order +

Phase completion

certificate from

the client

Along with

Annexure VII &

XVII


Page 55 of 80

2 Relevant experience of software development &

maintenance services on turnkey basis, to be

demonstrated in a maximum of 5 nos. with each

engagement value of more than INR 3 crore with

Government Clients within India.

Note: Projects should be substantially completed i.e.

completed or 70% completed. For 70% completion please

attach client certificate or payment receipt confirmation.

The work order should have been issued within the last 5

years as on date of submission of bid:



c. Experience of executing 3 Projects – 9 Marks

d. Experience of executing 4 Projects – 12 Marks

e. Experience of executing 5 or more Projects – 15

Marks

15 Completion

certificates from

the client;

OR

Work order + Self

certificate of

completion

(Certified by the

Authorised

Signatory/

Chartered

Accountant);

OR

Work order +

Phase completion

certificate from

the client

Along with

Annexure VII &

XVII

3. Relevant experience of application hosting and

maintenance on cloud platform or providing Data Centre

Infrastructure support.

Note: project should have gone live and should be in O&M

phase



c. Experience of executing 3 or more Projects – 4

Marks

d. Additional 1 marks to be provided in case of

Government projects

5 Completion

certificates from

the client;

OR

Work order + Self

certificate of

completion

(Certified by the

Authorised

Signatory/

Chartered

Accountant);

OR


Page 56 of 80

Work order +

Phase completion

certificate from

the client

Along with

Annexure VII &

XVII

4. Proposed Solution: Bidders must demonstrate their

understanding of the DoT’s requirements by providing:

a. Bidders understanding of Revenue Assessment

Software of DoT and scope of work as per this RFP – 5

marks

b. Solution proposed and its components – 5 marks

c. Proposed Technical Architecture

It should cover: ( 5 marks)

Application Architecture, Technology and Software

platform proposed

Cloud Infrastructure design covering aspects

related to Scalability, redundancy, performance,

capacity planning etc.

Security Architecture and features - Proposed

Application level security, network & server level

security, user activity monitoring plan, incident

response plan.

Disaster Recovery Plan

d. Quality and Risk Management Methodology – 5 marks

e. Proposed application maintenance and exit

management plan – 5 marks

25 Please note apart

from the technical

proposal the

bidder shall be

required to present

the above

understanding

separately also in

the form of a

technical

presentation.

5. Qualitative Assessment of Project Management and

Detailed Work Plan:

a. Overall project management approach adopted by

the bidder to implement the project shall be

assessed – 2 marks

5 Required information in relevant format


Page 57 of 80

b. The detailed project plan including detailed work

breakdown structure, timelines, assignment of

resource, dependencies and milestones/

deliverables – 3 marks

6. Financial Capability:

Average turnover of the firm from System Integration/ ICT

Systems Development and Implementation Work in last 3

financial years (i.e. 2014‐2015, 2015‐2016 & 2016-2017):

(Turnover in INR)

a. Average Turnover ≥ 500 crore: 5 marks b. 400 ≤ Average Turnover < 500 crore : 4 marks c. 300 ≤ Average Turnover < 400 crore : 3 marks d. 200 ≤ Average Turnover < 300 crore : 2 marks e. 100 ≤ Average Turnover < 200 crore : 1 mark

5 Financial Capability Statement in prescribed format (Annexure – XVI)

7. Key Manpower & Deployment Plan:

a. Project team structure and Deployment plan

b. Profiles of each of the proposed resource for the

assignment

i. Experience in relevant assignments

ii. Years of experience

iii. Technology specific number of certifications.

Note: Please refer next table in this annexure for proposed

team evaluation criteria

18 Summary of key profiles (Annexure-V)

and

CVs of the team members (Annexure-VI)

8. a. Bidder Certification – Bidder must be a CMMi Level 3 or above certified company

i. CMMi Level 3 (1 mark)

ii. CMMi Level 4 (3 marks)

iii. CMMi Level 5 (5 marks)

b. Bidder Certification – Bidder must be ISO 20000 certified (2 marks)

7 Copy of valid

certificate

Total 100

Note: all the submitted documents and annexures should have authorized signatory’s sign and

seal.


Page 58 of 80

Evaluation Criteria for Proposed Team

# Role Desired Experience and Qualification Max.

Marks

1 Program

Manager

Experience > 15 Years – 1 mark

Minimum 5 years of Experience of Leading Projects in

Government Sector – 1 mark

B. Tech/ BE/ MCA – 1 mark

3

2 Project

Manager

Experience > 12 Years with minimum 5 years of Experience

working on Government Sector projects – 1 mark


PMP/ Prince 2/ Scrum/ Agile Certification – 1 mark

3

3 Solution

Architect

Experience > 12 Years in designing solution for Enterprise

Architecture – 1 mark


TOGAF Certification – 1 mark

3

4 Business

Analyst

Minimum 10 Years’ experience in Business Analysis and

Requirement Gathering with 5 years in Government Sector –

1 mark

Experience of working on application development involving

Complex Assessment process – 1 mark

B. Tech/ BE/ MCA/ MBA – 1 mark

3

5 Application

Lead

Minimum 09 Years’ experience – 1 mark

Experience of working on complex web application

development projects – 1 mark


3

6 Database

Administrator

Experience > 7 Years as DBA – 1 marks

Experience of working on projects involving Data Migration –

1 mark


3

Total 18


Page 59 of 80

Annexure-X: Financial Proposal Format

[To be submitted on Bidder Company’s Letterhead] To: Director – License Fee Assessment Department of Telecommunication Sanchar Bhawan, 20 Ashoka Road New Delhi – 110001

Sub: Financial Proposal for Selection of System Integrator for the Design, Development, Implementation and Maintenance of Revenue Management System for DoT (RFP Ref No.: _________________ Dated: ___________).

Dear Sir,

We are pleased to submit our Financial Proposal for the Design, Development, Implementation and Maintenance of Revenue Management System for DoT for a period of five years from the date of go-live.

1. We hereby declare that our Financial Proposal is unqualified and unconditional in all respects.

2. The Financial Bid has been quoted without seeking any minimum guarantee support from DoT.

3. Our attached Financial Proposal is as follows:

S.No. Particulars Total Price in INR (in Figure)

Total Price in INR

(in Words)

1. Total Cost of Design, Development, Implementation and Maintenance of Revenue Management System for DoT for a period of five years from the date of Go-live (including Out of Pocket Expenses)

2. Man Days Bundle for 600 Man days of effort**

3. Total Price (1+2)

**DoT may consider utilizing the services of bidder to implement/accommodate any change request that are not part of the scope of this RFP on the man day utilization concept.

4. The price quoted above by the bidder is exclusive of GST/Service Tax and includes all other applicable taxes.


Page 60 of 80

Yours faithfully,

Date:


Place:

(Name and Designation of the of the Authorized signatory)

(Rubber seal of the Bidder)


Page 61 of 80

Annexure-XI: Cost for Additional Services

Man Month Rates for Change Request

DoT may consider utilizing the services of bidder to implement additional Services that are not

part of the scope of this RFP on man month rate basis. Bidders are requested to provide man

month rate option. It may be noted that DoT will invoke these rates for any further Change

Requests once the efforts under man days as quoted in Man days bundle at serial 2 of Annexure

X of Vol II have been exhausted. Resource categorization is as described below

S. No Manpower Type Man Month Rate

1 Technical Consultant (TA, DBA, BA, Leads)

2 Developer (Software, GUI, Tester)

Training Cost (in Per Session):

(The cost provided in this table may be used by the DoT for making the payment of additional

training sessions conducted by SI on request of DoT (if any), required after consuming all the 40

training sessions mentioned in this RFP document)

S. No Particular Cost per session

1 Training Cost (as per clause 5.12 of Volume-I)

Note: Training cost shall include cost of trainer, training material, travel cost and all other

incidental charges as applicable in conducting training sessions at the location prescribed by the

DoT.

Helpdesk Cost (in Per Month):

(The cost provided in the table below will be used by the DoT for making payment to SI for the

extended period of helpdesk support (beyond 6 months of the helpdesk duration, as mentioned in

this RFP) on the request of DoT (if any))

S. No Particular Cost per month

1 Helpdesk Cost (as per clause _____ of Volume-I)

Note: The price quoted above by the bidder is exclusive of GST/Service Tax and includes all other applicable taxes. Date:


Place:


Page 62 of 80

(Name and Designation of the of the Authorized signatory) (Rubber seal of the Bidder)


Page 63 of 80

Annexure-XII: Format for Earnest Money Deposit (EMD)

<Location, Date>

To,

Director

Licensing Finance Assessment

Department of Telecommunication

Sanchar Bhawan, 20 Ashoka Road, New Delhi – 110001

Phone Nos.:011-23372193, +91 9868135825

Email id: [email protected]

Whereas <<name of the bidder>> (hereinafter called 'the Bidder') has submitted the bid for

Submission of RFP # <<RFP Number>> dated <<insert date>> for RFP for Selection of System

Integrator for the Design, Development, Implementation and Maintenance of Revenue

Management System for DoT (hereinafter called "the Bid") to Department of

Telecommunications.

Know all Men by these presents that we <<name of the bank>> having our office at <<Address>>

(hereinafter called "the Bank") are bound unto the Department of Telecommunications

(hereinafter called "the Purchaser") in the sum of Rs. 20,00,000 (Rupees Twenty Lakh Only) for

which payment well and truly to be made to the said Purchaser, the Bank binds itself, its

successors and assigns by these presents. Sealed with the Common Seal of the said Bank this

<<insert date>>.

The conditions of this obligation are:

1. If the Bidder having its bid withdrawn during the period of bid validity specified by the Bidder

on the Bid Form; or

2. If the Bidder, having been notified of the acceptance of its bid by the Purchaser during the

period of validity of bid

(a) Withdraws his participation from the bid during the period of validity of bid document; or

(b) Fails or refuses to participate or failure to respond in the subsequent Tender process after

having been short listed;

We undertake to pay to the Purchaser up to the above amount upon receipt of its first written

demand, without the Purchaser having to substantiate its demand, provided that in its demand

the Purchaser will note that the amount claimed by it is due to it owing to the occurrence of one

or both of the two conditions, specifying the occurred condition or conditions.


Page 64 of 80

This guarantee will remain in force up to <<insert date>> and including <<extra time over and

above mandated in the RFP>> from the last date of submission and any demand in respect

thereof should reach the Bank not later than the above date.

NOTHWITHSTANDING ANYTHING CONTAINED HEREIN:

I. Our liability under this Bank Guarantee shall not exceed Rs. 20,00,000/- (Rupees Twenty Lakh

only).

II. This Bank Guarantee shall be valid upto <<insert date>>).

III. It is condition of our liability for payment of the guaranteed amount or any part thereof arising

under this Bank Guarantee that we receive a valid written claim or demand for payment under

this Bank Guarantee on or before <<insert date>>) failing which our liability under the guarantee

will automatically cease.

(Authorized Signatory of the Bank)

Seal:

Date:


Page 65 of 80

Annexure-XII I: Format for Performance Bank Guarantee (PBG)

(PERFORMA OF BANK GUARANTEE)

THIS DEED OF GUARANTEE executed on this the ___________day of ________________ at

_________________________ by _________________________________ (Name of the Bank)

having its Head/Registered office at _________________________________________________

hereinafter referred to as “the Guarantor” which expression shall unless it be repugnant to the

subject or context thereof include successors and assigns;

In favour of

Department of Telecommunication, (hereinafter referred to as “DoT”, which expression shall,

unless repugnant to the context or meaning thereof include its administrators, successors or

assigns.

WHEREAS

A. By the Agreement (“AGREEMENT”) being entered into between DoT and

_________________, a company incorporated under the provisions of the Companies Act,

1956, having its registered office___________________, Selected Bidder, System

Implementation for DoT (hereinafter referred to as “The Project”).

B. As per terms of RFP, the Selected Bidder is required to furnish to DoT, an unconditional and

irrevocable bank guarantee for an amount of INR ________________ only as security for due

and punctual performance/discharge of its obligations under the Agreement relating to

design, development and operate the system.

C. At the request of the Selected Bidder, the Guarantor has agreed to provide bank guarantee,

being these presents guaranteeing the due and punctual performance/ discharge by the

Selected Bidder of its obligations relating to the Project;

NOW THEREFORE THIS DEED WITNESSETH AS FOLLOWS:

1. Capitalized terms used herein but not defined shall have the meaning assigned to them

respectively in the Agreement.

2. The Guarantor hereby irrevocably guarantees the due and punctual performance by

________________ (hereinafter called “the Selected Bidder”) of all its obligations relating to

the Project and in connection with design, development and operation of system by the

Selected Bidder, in accordance with the Agreement.

3. The Guarantor shall, without demur, pay to DoT sums not exceeding in aggregate INR

___________, within five (5) calendar days of receipt of a written demand therefor from DoT

stating that the Company has failed to meet its obligations under the Agreement. The

Guarantor shall not go into the veracity of any breach or failure on the part of the Selected

Bidder or validity of demand so made by DoT and shall pay the amount specified in the

demand, notwithstanding any direction to the contrary given or any dispute whatsoever


Page 66 of 80

raised by the Selected Bidder or any other Person. The Guarantor’s obligations hereunder

shall subsist until all such demands are duly met and discharged in accordance with the

provisions hereof.

4. In order to give effect to this Guarantee, DoT shall be entitled to treat the Guarantor as the

principal debtor. The obligations of the Guarantor shall not be affected by any variations in

the terms and conditions of the Agreement or other documents or by the extension of time

for performance granted to the Selected Bidder or postponement/non exercise/delayed

exercise of any of its rights by DoT or any indulgence shown by DoT to the Selected Bidder

and the Guarantor shall not be relieved from its obligations under this Guarantee on account

of any such variation, extension, postponement, non-exercise, delayed exercise of any of its

rights by DoT or any indulgence shown by DoT, provided nothing contained herein shall

enlarge the Guarantor’s obligation hereunder.

5. This Guarantee shall be irrevocable and shall remain in full force and effect until __________

(180 days after completion of tenure of appointment) unless discharged/ released earlier by

DoT in accordance with the provisions of the Agreement. The Guarantor’s liability in

aggregate be limited to a sum of INR.

6. This Guarantee shall not be affected by any change in the constitution or winding up of the

Selected Bidder/the Guarantor or any absorption, merger or amalgamation of the

Concessionaire/the Guarantor with any other Person.

7. The Guarantor has power to issue this guarantee and discharge the obligations contemplated

herein, and the undersigned is duly authorized to execute this Guarantee pursuant to the

power granted under ______________.

IN WITNESS WHEREOF THE GUARANTOR HAS SET ITS HANDS HEREUNTO ON THE DAY, MONTH

AND YEAR FIRST HEREINABOVE WRITTEN.

SIGNED AND DELIVERED

by ____________________________________ Bank, by the hand of Mr./Ms.

______________________ its __________________and authorized official.


Page 67 of 80

Annexure-XIV: Format for Self -Declarations

A) Undertaking for availability of Sufficient and Competent Manpower to support the

requirements in RFP


Date:

To:

Director – Licensing Finance Assessment Department of Telecommunication

Sanchar Bhawan, 20 Ashoka Road New Delhi – 110001 Sub: Undertaking for Sufficient IT Manpower Dear Sir,

In accordance with eligibility requirements of this tender process, we _________<Name of the

bidding firm>__________________ wish to declare that, we have more than _______<number

of employees> full time employees on our own payroll, competent to support DoT’s Project to

execute and deliver the services as per the envisaged scope of work.

Yours faithfully,

Date:


Place:

(Name and designation of the of the Authorized signatory)



Page 68 of 80

B) Format for self-declaration on “No Conflict of Interest” [To be submitted on Bidder Company’s Letterhead] Date: To:

Director – Licensing Finance Assessment Department of Telecommunication Sanchar Bhawan, 20 Ashoka Road New Delhi – 110001 Sub: Undertaking for No Conflict of Interest Dear Sir, In accordance with clause 2.23 of the Volume-II of this RFP document, we _________<Name of the firm>__________________ wish to declare that we do not have any conflict of interest that may affect the current Bidding Process.

1 Yours faithfully,

Date:





Page 69 of 80

C) Format for Undertaking on Clean Track Record – No Corrupt/Fraudulent Practices [To be submitted on Bidder Company’s Letterhead] Date: To:

Director – Licensing Finance Assessment Department of Telecommunication Sanchar Bhawan, 20 Ashoka Road New Delhi – 110001 Sub: Undertaking of Clean Track Record Dear Sir, With reference to the above subject, we hereby wish to inform that, <Name of the Firm> isn’t debarred by any Central/ State Government Department/ Institution as on the date of submission of the bid and there has been no litigation with any Department/ PSU/ Corporation in Central/ State Government which may have any material impact on our ability to deliver the project (if awarded) or under a declaration of ineligibility for corrupt or fraudulent practices as on date_________. We hope that this undertaking provided hereinabove shall suffice the purpose. In case you need and further clarification, we would be glad to provide the same.

2 Yours faithfully, Date:





Page 70 of 80

Annexure-XV: Integrity Pact

(INTEGRITY PACT)

This pre-contract agreement (hereinafter called the “Integrity Pact” or “Pact”) is made on <<day>> of <<month, year>>, between, on one hand, the President of India acting through Director – Licensing Finance Assessment, Department of Telecommunications, Government of India (hereinafter called the “BUYER”, which expression shall mean and include, unless the context otherwise requires, his successors in office and assigns) of the First Part.

AND

M/s <<bidder’s legal entity >> represented by <<name and designation>> (hereinafter called the

“BIDDER/Seller”, which expression shall mean and include, unless the context otherwise

requires, his successors and permitted assigns) of the Second Part.

WHEREAS the BUYER proposes to engage the Managed Service Provider (MSP) for

implementation and operations management of the Project and the BIDDER is willing to offer/

has offered the services and

WHEREAS the BIDDER is a private company/ public company/ Government undertaking/

partnership/ registered export agency, constituted in accordance with the relevant law in the

matter and the BUYER is a Ministry/ Department of the Government of India performing its

functions on behalf of the President of India.

NOW, THEREFORE,

To avoid all forms of corruption by following a system that is fair, transparent and free from any

influence/ prejudiced dealings prior to, during and subsequent to the currency of the contract to

be entered into with a view to:-

Enabling the BUYER to obtain the desired services at a competitive price in conformity with the

defined specification by avoiding the high cost and the distortionary impact of corruption on

public procurement, and Enabling BIDDERs to abstain from bribing or indulging in any corrupt

practice in order to secure the contract by providing assurance to them that their competitors

will also abstain from bribing and other corrupt practices and the BUYER will commit to prevent

corruption, in any form, by its officials by following transparent procedures.

The parties hereto hereby agree to enter into this Integrity Pact and agree as follows:

Commitments of the BUYER

1.1. The BUYER undertakes that no official of the BUYER, connected directly or indirectly

with the contract, will demand, take a promise for or accept, directly or through

intermediaries, any bribe, consideration, gift, reward, favour or any material or

immaterial benefit or any other advantage from the BIDDER, either for themselves or

for any person, organisation or third party related to the contract in exchange for an


Page 71 of 80

advantage in the bidding process, bid evaluation, contracting or implementation

process related to the contract.

1.2. The BUYER will, during the pre-contract stage, treat all the BIDDERs alike, and will

provide to all BIDDERs the same information and will not provide any such information

to any particular BIDDER which could afford an advantage to that particular BIDDER in

comparison to other BIDDERs.

1.3. All the officials of the BUYER will report to the appropriate Government office any

attempted or completed breaches of the above commitments as well as any

substantial suspicion of such a breach.

2 In case any such preceding misconduct on the part of such official(s) is reported by the

BIDDER to the BUYER with full and verifiable facts and the same is prima facie found to be

correct by the BUYER, necessary disciplinary proceedings, or any other action as deemed

fit, including criminal proceedings may be initiated by the BUYER and such a person shall be

debarred from further dealings related to the contract process. In such a case while an

enquiry is being conducted by the BUYER the proceedings under the contract would not be

stalled.

Commitments of the Bidder

3 The BIDDER commits itself to take all the measures necessary to prevent corrupt practices,

unfair means and illegal activities during any stage of its bid or during any pre-contract or

post-contract stage in order to secure the contract or in furtherance to secure it and in

particular commit itself to the following:-

3.1 The BIDDER will not offer, directly or through intermediaries, any bribe, gift,

consideration, reward, favour or any material or immaterial benefit or other

advantage, commission, fees, brokerage or inducement to any official of the BUYER,

connected directly or indirectly with the bidding process, or to any person,

organization or third party related to the contract in exchange for any advantage in the

bidding, evaluation, contracting and implementation of the contract.

3.2 The BIDDER further undertakes that it has not given, offered or promised to give,

directly or indirectly any bribe, gift, consideration, reward, favour, any material or

immaterial benefit or other advantage, commission, fees, brokerage or inducement to

any official of the BUYER or otherwise in procuring the Contract or forbearing to do or

having done any act in relation to the obtaining or execution of the contract or any

other contract with the Government for showing or forbearing to show favour or dis-

favour to any person in relation to the contract or any other contract with the

Government.

3.3 BIDDER shall disclose the payments to be made by them to agents/brokers or any other

intermediary, in connection with this bid/contract.


Page 72 of 80

3.4 The BIDDER further confirms and declares to the BUYER that the BIDDER has not

engaged any individual or firm or company whether Indian or foreign to intercede,

facilitate or in any way to recommend to the BUYER or any of its functionaries, whether

officially or unofficially to the award of the contract to the BIDDER, nor has any amount

been paid, promised or intended to be paid to any such individual, firm or company in

respect of any such intercession, facilitation or recommendation.

3.5 The BIDDER, either while presenting the bid or during pre-contract negotiations or

before signing the contract, shall disclose any payments he has made, is committed to

or intends to make to officials of the BUYER or their family members, agents, brokers

or any other intermediaries in connection with the contract and the details of services

agreed upon for such payments.

3.6 The BIDDER will not collude with other parties interested in the contract to impair the

transparency, fairness and progress of the bidding process, bid evaluation, contracting

and implementation of the contract.

3.7 The BIDDER will not accept any advantage in exchange for any corrupt practice, unfair

means and illegal activities.

3.8 The BIDDER shall not use improperly, for purposes of competition or personal gain, or

pass on to others, any information provided by the BUYER as part of the business

relationship, regarding plans, technical proposals and business details, including

information contained in any electronic data carrier. The BIDDER also undertakes to

exercise due and adequate care lest any such information is divulged.

3.9 The BIDDER commits to refrain from giving any complaint directly or through any other

manner without supporting it with full and verifiable facts.

3.10 The BIDDER shall not instigate or cause to instigate any third person to commit any of

the actions mentioned above.

3.11 If the BIDDER who is involved in the bid process or any employee of such BIDDER or

any person acting on behalf of such BIDDER, either directly or indirectly, is a relative of

any of the officers of the BUYER, or alternatively, if any relative of an officer of BUYER

who is involved in the bid process has financial interest/stake in the BIDDER’s firm, the

same shall be disclosed by the BIDDER at the time of filing of tender.

3.12 The BIDDER shall not lend to or borrow any money from or enter into any monetary

dealings or transactions, directly or indirectly, with any employee of the BUYER.

For the purposes of clauses 3.11 & 3.12, the listed words shall have the ascribed meanings as

follows:


Page 73 of 80

i) “employee of such BIDDER or any person acting on behalf of such BIDDER” means only

those persons acting on behalf of such Bidder who are involved in the bid process/

Project.

ii) “officers/employee of the BUYER”, means only those persons who are involved in the

bid process/ Project.

iii) “financial interest/stake in the BIDDER’s firm” excludes investment in securities of

listed companies”.

4 Previous Transgression

4.1 BIDDER declares that no previous transgression occurred in the last three years

immediately before signing of this Integrity Pact, with any other company in any

country in respect of any corrupt practices envisaged hereunder or with any Public

Sector Enterprise in India or any Government Department in India that could justify

BIDDER’s exclusion from the tender process. .

4.2 The BIDDER agrees that if it makes incorrect statement on this subject, BIDDER can be

disqualified from the tender process or the contract, if already awarded, can be

terminated for such reason.

5 Earnest Money (EMD)

5.1 The Bidder’s EMD of INR 20,00,000/- deposited along with the bid shall remain valid

till the submission of performance guarantee by the BIDDER.

5.2 In case of the successful BIDDER, a clause would also be incorporated in the

Performance Bank Guarantee that the provisions of Sanctions for Violation shall be

applicable for forfeiture of Performance Bond in case of a decision by the BUYER to

forfeit the same without assigning any reason for imposing sanction for violation of

this Pact.

5.3 Within 15 days of the receipt of notification of award from the employer, the

successful Bidder shall furnish the performance security equal to 10 per cent of the

value of contract from a commercial bank in accordance with the conditions of the

Agreement, in the proforma prescribed at Volume – III of this RFP.

5.4 Performance security should remain valid from date of execution of Contract to the

expiry of 180 days after the date of completion of all contractual obligations including

warranty obligations.

5.5 No interest shall be payable by the BUYER to the BIDDER on Earnest

Money/Performance Security for the period of its currency.

6 Sanctions for Violations


Page 74 of 80

6.1 Any breach of the aforesaid provisions by the BIDDER or any one employed by it or

acting on its behalf (whether with or without the knowledge of the BIDDER) shall

entitle the BUYER to take all or any one of the following actions, wherever required:

6.1.1 To immediately call off the pre contract negotiations without assigning any

reason or giving any compensation to the BIDDER. However, the proceedings

with the other BIDDER(s) would continue.

6.1.2 The Earnest Money Deposit (in pre-contract stage) and/or Performance Security

(after the contract is signed) shall stand forfeited either fully or partially, as

decided by the BUYER and the BUYER shall not be require to assign any reason

therefore.

6.1.3 To immediately cancel the contract, if already signed, without giving any

compensation to the BIDDER.

6.1.4 To recover all sums already paid by the BUYER, and in case of an Indian BIDDER

with interest thereon at 2% higher than the prevailing prime lending rate of State

Bank of India, while in case of a BIDDER from a country other than India with

interest thereon at 2% higher than the LIBOR. If any outstanding payment is due

to the BIDDER from the BUYER in connection with any other contract for any

other stores, such outstanding payment could also be utilised to recover the

aforesaid sum and interest.

6.1.5 To encash the advance bank guarantee and performance bond/warranty bond,

if furnished by the BIDDER, in order to recover the payments, already made by

the BUYER, along with interest.

6.1.6 To cancel all or any other Contracts with the BIDDER. The BIDDER shall be liable

to pay compensation for any loss or damage to the BUYER resulting from such

cancellation/rescission and the BUYER shall be entitled to deduct the amount so

payable from the money(s) due to the BIDDER

6.1.7 To debar the BIDDER from participating in future bidding processes of the

Government of India for a minimum period of five years, which may be further

extended at the discretion of the BUYER

6.1.8 To recover all sums paid in violation of this Pact by BIDDER(s) to any middleman

or agent or broker with a view to securing the contract.

6.1.9 In cases where irrevocable Letters of Credit have been received in respect of any

contract signed by the BUYER with the BIDDER, the same shall not be opened.

6.1.10 Forfeiture of Performance Bond in case of a decision by the BUYER to forfeit the

same without assigning any reason for imposing sanction for violation of this

Pact.


Page 75 of 80

6.2 The BUYER will be entitled to take all or any of the actions mentioned at para 6.1.1 to

6.1.10 of this Pact also on the Commission by the BIDDER or any one employed by it or

acting on its behalf (whether with or without the knowledge of the BIDDER), of an

offence as defined in Chapter IX of the Indian Penal code, 1860 or Prevention of

Corruption Act, 1988 or any other statute enacted for prevention of corruption.

6.3 The decision of the BUYER to the effect that a breach of the provisions of this Pact has

been committed by the BIDDER shall be final and conclusive on the BIDDER. However,

the BIDDER can approach the Independent Monitor(s) appointed for the purposes of

this Pact.

7 Fall Clause

The BIDDER undertakes that under similar buying conditions, it has not supplied/is not

supplying similar product/systems or subsystems at a price lower than that offered in the

present bid in respect of any other Ministry/Department of the Government of India or PSU

and if it is found at any stage that similar product/systems or subsystems was so supplied

by the BIDDER to any other Ministry/Department of the Government of India or a PSU at a

lower price, then that very price, with due allowance for elapsed time, will be applicable to

the present case and the difference in the cost would be refunded by the BIDDER to the

BUYER, if the contract has already been concluded.

8 Independent Monitors

8.1 The task of the independent external monitor (hereinafter referred to as Monitor) for

overseeing and implementation of the Pre-Contract Integrity Pact for procurement of

services in the <Purchaser’s entity, shall be to review independently and objectively,

whether and to what extent the parties comply with the obligations under this Pact.

8.2 The Monitors shall not be subject to instructions by the representatives of the parties

and perform their functions neutrally and independently.

8.3 Both the parties accept that the Monitors have the right to access all the documents

relating to the project/procurement, including minutes of meetings.

8.4 As soon as the Monitor notices, or has reason to believe, a violation of this Pact, he will

so inform the Authority designated by the BUYER.

8.5 The BIDDER(s) accepts that the Monitor has the right to access without restriction to

all Project documentation of the BUYER including that provided by the BIDDER. The

BIDDER will also grant the Monitor, upon his request and demonstration of a valid

interest, unrestricted and unconditional access to his project documentation. The

same is applicable to Subcontractors. The Monitor shall be under contractual

obligation to treat the information and documents of the BIDDER/Subcontractor(s)

with confidentiality.


Page 76 of 80

8.6 The BUYER will provide to the Monitor sufficient information about all meetings among

the parties related to the Project provided such meetings could have an impact on the

contractual relations between the parties. The parties will offer to the Monitor the

option to participate in such meetings.

8.7 The Monitor will submit a written report to the designated Authority of BUYER/

Secretary in the Department/ within 8 to 10 weeks from the date of reference or

intimation to him by the BUYER/ BIDDER and, should the occasion arise, submit

proposals for correcting problematic situations.

9 Facilitation of Investigation

In case of any allegation of violation of any provisions of this Pact or payment of

commission, the BUYER or its agencies shall be entitled to examine all the documents

including the Books of Accounts of the BIDDER and the BIDDER shall provide necessary

information and documents in English and shall extend all possible help for the purpose of

such examination.

10 Law and Place of Jurisdiction

This Pact is subject to Indian Law. The place of performance and jurisdiction is New Delhi.

11 Other Legal Actions

The actions stipulated in this Integrity Pact are without prejudice to any other legal action

that may follow in accordance with the provisions of the extant law in force relating to any

civil or criminal proceedings.

12 Validity

12.1 The validity of this Integrity Pact shall be from date of its signing and extend upto the

complete execution of the contract to the satisfaction of both the BUYER and the

BIDDER, including warranty period, whichever is later. In case Bidder is unsuccessful,

this Integrity Pact shall expire after six months from the date of signing of the contract.

12.2 Should one or several provisions of this Pact turn out to be invalid, the remainder of

this Pact shall remain valid. In this case, the parties will strive to come to an agreement

to their original intentions.

13 The parties hereby sign this Integrity Pact at _____________ on ________________.

Buyer Bidder

Name of Officer Chief Executive Officer/ Authorized

Representative of Bidder


Page 77 of 80

Designation

Dept./Ministry/PSU

WITNESS WITNESS

1. 1.

2. 2.

* Provisions of these clauses would need to be amended/deleted in line with the policy of the

BUYER in regard to involvement of Indian agents for foreign suppliers.


Page 78 of 80

Annexure-XVI: Financial Capability Statement

[To be submitted separately on Statutory Auditor’s letterhead for the bidder firm]

I hereby declare that I have scrutinized and audited the financial statements of

M/s________________. Turnover* of the bidder (name of the Bidder) as on 31st March, 2017 as

per audited statement is as follows:

Financial year Turnover (INR Crore) Net Worth (INR Crore)

2016-17

2015-16

2014-15

*To be provided from latest available Audited statement

The organization is a profit making company with positive net worth for each of the last three

financial years (FY-14-15, FY-15-16, FY-16-17) as on 31st March 2017

__________________

(Signed and Sealed by the statutory auditor)


Page 79 of 80

Annexure-XVII: Format for Providing Past Project Summary of Bidder

# Technical

Evaluation

Criteria No.

Project

Name

Client

Name

Project

Value

Project

Duration

Start &

End Date

Project

Location

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.


Page 80 of 80

Annexure-XVII I (Format for Submission of Deviations)


Date:

To:

Director – Licensing Finance Assessment Department of Telecommunication Sanchar Bhawan, 20 Ashoka Road New Delhi – 110001

Sub: Undertaking for Submission of Deviations

Dear Sir,

In accordance with the RFP document, we <Name of the firm> wish to submit our deviations

along with the proposal and declare that:

a) Deviations don’t have any material impact on the project.

b) We have not submitted any deviation(s) anywhere else in this proposal.

c) The submission of deviations doesn’t mean acceptance of deviation by DoT.

d) Even if deviations are not accepted by DoT and we are selected under the RFP as SI then we

shall abide by all the terms and conditions of this RFP document.

# RFP (Volume / Section / Page No.)

RFP Requirement Deviation Page no. in Technical Proposal

1

2

3

Yours faithfully,

Date:



(Name and seal of the Bidder)

2018

RFP Reference No.:1-6/2004/LF II/Vol III RFP Issuing Date: 27/Mar/2018

Tender Issuing Authority:

Director – Licensing Finance

Assessment

Department of Telecommunication

Ministry of Communications

Sanchar Bhawan, 20 Ashoka Road

New Delhi- 110001

Phone: 011-23372193

Mobile: +91 9868135825

E-Mail: [email protected]

RFP for Selection of System Integrator

for the Design, Development,

Implementation and Maintenance of

Revenue Management System for

Department of Telecommunications

Volume – III

Master Service Agreement

RFP for Selection of System Integrator for the Design, Development, Implementation and Maintenance of

Revenue Management System for DoT (Volume-III)

Page 2 of 44

Table of Contents Master Service Agreement ....................................................................................................................................5

1 Definitions and Interpretation ....................................................................................................................6

1.1 Definitions ..................................................................................................................................................6

1.2 Interpretation ...........................................................................................................................................9

1.3 Measurements and Arithmetic Conventions ................................................................................ 10

1.4 Ambiguities within Agreement ......................................................................................................... 10

1.5 Priority of Documents ......................................................................................................................... 10

2 Basic understanding .................................................................................................................................... 10

3 Scope of the Project ...................................................................................................................................... 11

4 Term and Duration of the Agreement ................................................................................................... 11

5 Conditions Precedent and Effective Date ............................................................................................. 12

5.1 Provisions to take effect upon fulfilment of Conditions Precedent ................................... 12

5.2 Conditions Precedent ......................................................................................................................... 12

5.2.1 Conditions Precedent of the Implementing Partner ............................................................. 12

5.2.2 Conditions Precedent of the DoT ................................................................................................. 12

5.3 Extension of time for fulfilment of Conditions Precedent ..................................................... 12

5.4 Non-fulfilment of the System Integrator’s Conditions Precedent ....................................... 12

6 Change of Control ......................................................................................................................................... 13

7 Representations and Warranties ............................................................................................................ 13

7.1 Representations and warranties of the System Integrator ................................................... 13

7.2 Representations and warranties of the DoT................................................................................ 14

8 Obligations of DoT ........................................................................................................................................ 16

9 Obligations of the System Integrator ..................................................................................................... 16

10 Approvals and Required Consents ..................................................................................................... 16

11 Use of Assets by the System Integrator ............................................................................................ 17

12 Access to DoT Locations ......................................................................................................................... 17

13 Financial Matters ...................................................................................................................................... 18

13.1 Terms of Payment and Service Credits and Debits .................................................................. 18

13.2 Invoicing and Settlement .................................................................................................................. 18

13.3 Tax ............................................................................................................................................................. 19

14 Termination ............................................................................................................................................... 20

14.1 Right to Terminate .............................................................................................................................. 20

14.2 Effects of Termination ........................................................................................................................ 20



Page 3 of 44

14.3 Consequences of termination .......................................................................................................... 21

15 Exit Management ...................................................................................................................................... 22

15.1 Exit Management Plan........................................................................................................................ 22

15.2 Training, hand-holding and knowledge transfer ..................................................................... 24

16 Indemnification and Limitation of Liability .................................................................................... 24

16.1 Indemnification .................................................................................................................................... 24

16.2 Limitation of Liability ......................................................................................................................... 26

17 Force Majeure ............................................................................................................................................ 26

17.1 Definition of Force Majeure ............................................................................................................. 26

17.2 Force Majeure events .......................................................................................................................... 26

17.3 Notification procedure for Force Majeure .................................................................................. 28

17.4 Allocation of Costs Arising Out of Force Majeure ..................................................................... 28

17.5 Consultation and Duty to Mitigate ................................................................................................... 29

18 Confidentiality ........................................................................................................................................... 29

19 Intellectual Property Rights ................................................................................................................. 30

20 Warranty ..................................................................................................................................................... 31

21 Liquidated Damages ................................................................................................................................ 32

22 Governing Laws / Jurisdiction Arbitration ..................................................................................... 32

23 Arbitration and Legal Jurisdiction ..................................................................................................... 32

24 Miscellaneous ............................................................................................................................................ 33

24.1 Personnel ................................................................................................................................................ 33

24.2 Assignment ............................................................................................................................................. 33

24.3 Trademarks, Publicity ........................................................................................................................ 34

24.4 Notices ..................................................................................................................................................... 34

24.5 Variations and Further Assurance ................................................................................................. 34

24.6 Severability and Waiver .................................................................................................................... 35

24.7 Compliance with Applicable Law ................................................................................................... 35

24.8 Professional Fees ................................................................................................................................. 35

24.9 Ethics ........................................................................................................................................................ 35

24.10 Entire Agreement ............................................................................................................................ 36

24.11 Amendment ....................................................................................................................................... 36

SCHEDULES .............................................................................................................................................................. 37

SCHEDULE – I: RFP Document ....................................................................................................................... 37

SCHEDULE – II: Change Control Schedule ................................................................................................... 38

SCHEDULE – III: Implementation Timelines ............................................................................................ 41



Page 4 of 44

SCHEDULE – IV: Payments Schedule ............................................................................................................. 43

ANNEXURE – A: Bid Response of the System Integrator ......................................................................... 44



Page 5 of 44

Master Service Agreement

THIS MASTER SERVICE AGREEMENT (“Agreement”) is made on this the <<Date>> day of <<Month>> <<Year>> at <<Place>>, India.

BETWEEN

The President of India acting through <<Name of the Officer>> <<Designation>>, Department of Telecommunications having its office at Sanchar Bhawan, 20 Ashoka Road, New Delhi-110001, India hereinafter referred to as ‘DoT’, which expression shall, unless the context otherwise requires, include its permitted successors and assigns);

AND

<<Company Name>>, a Company incorporated under the Companies Act, 1956/2013, having its registered office at <<Company Address>> (hereinafter referred to as ‘System Integrator’ which expression shall, unless the context otherwise requires, include its permitted successors and assigns).

Each of the parties mentioned above are collectively referred to as the ‘Parties’ and individually as a ‘Party’.

WHEREAS:

1. DoT is desirous to implement the project of “Design, Development, Implementation and Maintenance of Revenue Management System.”

2. In furtherance of the same, DoT undertook the selection of a suitable System Integrator through an open competitive e-bidding process for implementing the Project and in this behalf issued Request for Proposal (RFP) dated <<dd/mmm/yyyy>>.

3. The successful bidder has been selected as the System Integrator on the basis of the e-bid response set out as Annexure-A of this Agreement, to undertake the Project of the design, development and implementation of the Revenue Management System, its roll out and sustained operations.

NOW THEREFORE, in consideration of the mutual covenants, promises, assurances, representations and provisions set forth herein, the Parties hereto agree as follows:



Page 6 of 44

1 Definitions and Interpretation

1.1 Definitions

1.1.1 Adverse Effect: means material adverse effect on

i) The ability of the System Integrator to exercise any of its rights or perform/discharge any of its duties/obligations under and in accordance with the provisions of this Agreement and/or

ii) The legal validity, binding nature or enforceability of this Agreement;

1.1.2 Agreement: means this Agreement together with all Articles, Annexures, Schedules and the contents and specifications of the RFP;

1.1.3 Applicable Law(s): means any statute, law, ordinance, notification, rule, regulation, judgment, order, decree, bye-law, approval, directive, guideline, policy, requirement or other governmental restriction or any similar form of decision applicable to the relevant party and as may be in effect on the date of the execution of this Agreement and during the subsistence thereof, applicable to the Project;

1.1.4 Application: means the Revenue Management System developed as a part of scope of work set out in this agreement.

1.1.5 Application Downtime: means the time for which user/s is not able to access the application. However, in calculating downtime, scheduled downtime (for example, backup time, batch processing time, routine maintenance time) would not be considered;

1.1.6 Assets: means entire hardware and software, network or any other information technology infrastructure components used for the Project and other facilities leased / owned / operated by the System Integrator exclusively in terms of ensuring their usability for the delivery of the Services as per this Agreement.

1.1.7 Bespoke Software shall mean the Revenue Management software designed, developed, tested and deployed by SI for the purposes of rendering the services and includes the source code along with associated documentation, which is the work product of the development efforts involved in the Project and the improvements effected to such software during the tenure of appointment, but does not include the third party software products (except for the customization components on such products), proprietary software components and tools deployed by SI.

1.1.8 Business Hours shall mean the working time for DoT users which is 9:00 AM to 6:00 PM. Again for Web Server and other components which enable successful usage of Revenue Management System of DoT the working time should be considered as 24 hours for all the days of the week. It is desired that IT maintenance, other batch processes (like backup) etc. should be planned so that such backend activities have minimum effect on the performance;

1.1.9 Confidential Information: means all information including DoT Data (whether in



Page 7 of 44

written, oral, electronic or other format) which relates to the technical, financial and business affairs, dealers, suppliers, products, developments, operations, processes, data, trade secrets, design rights, know-how, plans, budgets and personnel of each Party and its affiliates which is disclosed to or otherwise learned by the other Party in the course of or in connection with this Agreement (including without limitation such information received during negotiations, location visits and meetings in connection with this Agreement);

1.1.10 Control: means, in relation to any business entity, the power of a person to secure

i) by means of the holding of shares or the possession of voting power in or in relation to that or any other business entity, or

ii) by virtue of any powers conferred by the articles of association or other document regulating that or any other business entity, that the affairs of the first mentioned business entity are conducted in accordance with that person’s wishes and in relation to a partnership, means the right to a share of more than one half of the assets, or of more than one half of the income, of the partnership;

1.1.11 Deliverables: means the products, infrastructure and services agreed to be delivered by the System Integrator in pursuance of the agreement as defined more elaborately in the RFP, Implementation and the Maintenance phases and includes all documents related to the user manual, technical manual, design, process and operating manuals, service mechanisms, policies and guidelines (such as security related, data migration related), inter alia payment and/or process related etc., source code and all its modifications;

1.1.12 DoT Data: means all proprietary data of the department or its nominated agencies generated out of operations and transactions, and related information including but not restricted to user data which the System Integrator obtains, possesses or processes in the context of providing the Services to the users pursuant to this Agreement;

1.1.13 Effective Date shall mean the <<date>>

1.1.14 Final Acceptance Test shall be conducted on completion of the following:

i) Setting up and operationalization on Cloud Infrastructure at DoT approved Data Centre by System Integrator,

ii) Design, Deployment, Customization and UAT of the overall Revenue Management System.

iii) Setting up of master data in the Revenue Management System

1.1.15 Force Majeure means any event which is unforeseeable, beyond the control of the affected party and materially affects its capacity to perform this Agreement. Such events may include: war, civil war, insurrection, riots, revolutions, fire, floods, epidemics, quarantine, strikes and earthquakes

1.1.16 GoI shall means the Government of India;



Page 8 of 44

1.1.17 Intellectual Property Rights shall mean and include all rights in the application, Bespoke Software, its improvements, upgradations, enhancements, modified versions that may be made from time to time, source code and object code of the software and include all rights relating to designs, copyrights, trademarks, patents, trade secrets and other rights therein.

1.1.18 Material Breach: means a breach by either Party (DoT or System Integrator) of any of its obligations under this Agreement which has or is likely to have an Adverse Effect on the Project which such Party shall have failed to cure;

1.1.19 Parties: means DoT and System Integrator for the purposes of this Agreement and “Party” shall be interpreted accordingly;

1.1.20 Performance Bank Guarantee shall mean the guarantee provided by SI from a scheduled bank in favor of DoT for the performance of its obligations under this Agreement

1.1.21 Planned Application Downtime: means the unavailability of the application services due to maintenance activities such as configuration changes, up gradation or changes to any supporting infrastructure wherein prior intimation (at least two working days in advance) of such planned outage shall be given and approval sought from the DoT as applicable;

1.1.22 Project: means Pilot, Project Implementation (roll out) and Maintenance in terms of the Agreement;

1.1.23 Project Implementation shall mean Project Implementation as per the testing standards and acceptance criteria stated in Schedule I hereto

1.1.24 Project Implementation Phase shall be from the Effective Date of the Agreement/Contract Signing to the Date of Go Live.

1.1.25 Project Timelines shall have the same meaning ascribed to in Schedule-III;

1.1.26 Replacement System Integrator: means any third party that DoT appoint to replace System Integrator upon expiry of the Term or in the event of termination of this Agreement to undertake the Services or part thereof;

1.1.27 Required Consents: means the consents, waivers, clearances and licenses to use DoT's Intellectual Property Rights, rights and other authorizations as may be required to be obtained for the System and other items that DoT or their nominated agencies are required to make available to System Integrator pursuant to this Agreement;

1.1.28 Services: means the services delivered to the Stakeholders of DoT, employees of DoT, and to professionals, using the tangible and intangible assets created, procured, installed, managed and operated by the System Integrator including the tools of information and communications technology;

1.1.29 Service Level: means the level of service and other performance criteria which will apply to the Services delivered by the System Integrator;

1.1.30 SLA: means the Performance and Maintenance Service Level Agreement executed



Page 9 of 44

as part of this Master Service Agreement;

1.1.31 System: means the System designed, developed / customized, tested and deployed by the System Integrator for the purposes of the Project and includes the source code along with associated documentation, which is the work product of the development efforts involved in the Project and the improvements and enhancements effected during the term of the Project, but does not include the related third party System products, proprietary System components and tools deployed by the System Integrator;

1.1.32 Third Party Systems shall mean Systems (or any part thereof) in which the Intellectual Property Rights are owned by a third party and to which SI has been granted a license to use and which are used in providing the services under this Agreement.

1.1.33 Unplanned Application Downtime: means the total time for all the instances where the application is not available for more than 5 consecutive minutes;

1.2 Interpretation

In this Agreement, unless otherwise specified:

1.2.1 references to Clauses, Sub-Clauses, Paragraphs, Schedules and Annexures are to clauses, sub-clauses, paragraphs, schedules and annexures to this Agreement;

1.2.2 use of any gender includes the other genders;

1.2.3 references to a ‘company’ shall be construed so as to include any company, corporation or other body corporate, wherever and however incorporated or established;

1.2.4 references to a ‘person’ shall be construed so as to include any individual, firm, company, government, state or agency of a state, local or municipal authority or government body or any joint venture, association or partnership (whether or not having separate legal personality);

1.2.5 a reference to any statute or statutory provision shall be construed as a reference to the same as it may have been, or may from time to time be, amended, modified or re- enacted;

1.2.6 any reference to a ‘day’ (including within the phrase ‘business day’) shall mean a period of 24 hours running from midnight to midnight;

1.2.7 references to a ‘business day’ shall be construed as a reference to a day (other than a Sunday) on which the offices of DoT are generally open for business;

1.2.8 references to times are to Indian Standard Time;

1.2.9 a reference to any other document referred to in this Agreement is a reference to that other document as amended, varied, notated or supplemented at any time; and

1.2.10 All headings and titles are inserted for convenience only. They are to be ignored in the interpretation of this Agreement.



Page 10 of 44

1.2.11 System Integrator (SI) or Implementing Agency (IA) has been used for the same entity i.e. bidder selected for the project.

1.3 Measurements and Arithmetic Conventions

All measurements and calculations shall be in the metric system and calculations done to 2 (two) decimal places, with the third digit of 5 (five) or above being rounded up and below 5 (five) being rounded down except in money calculations where such amounts shall be rounded off to the nearest INR.

1.4 Ambiguities within Agreement

In case of ambiguities or discrepancies within this Agreement, the following principles shall apply:

1.4.1 as between two Clauses of this Agreement, the provisions of a specific Clause relevant to the issue under consideration shall prevail over those in a general Clause;

1.4.2 as between the provisions of this Agreement and the Schedules/Annexures, the Agreement shall prevail, save and except as expressly provided otherwise in the Agreement or the Schedules/Annexures; and

1.4.3 as between any value written in numerals and that in words, the value in words shall prevail.

1.5 Priority of Documents

This Agreement, including its Schedules and Annexures, represents the entire agreement between the Parties as noted in this Clause. If in the event of a dispute as to the interpretation or meaning of this Agreement it should be necessary for the Parties to refer to documents forming part of the bidding process leading to this Agreement, then such documents shall be relied upon and interpreted in the following descending order of priority:

1.5.1 This Agreement along with the Schedules;

1.5.2 Request for Proposal and Addendum / Corrigendum to the Request for Proposal (if any).

For the avoidance of doubt, it is expressly clarified that in the event of a conflict between this Agreement and Annexures / Schedules or the contents of the RFP, the terms of this Agreement shall prevail over the Annexures / Schedules and Annexures / Schedules shall prevail over the contents and specifications of the RFP.

2 Basic understanding

SI hereby confirms that:

(i) It has understood the functions which it has to perform and the obligations it has

to discharge as SI detailed in this Agreement.



Page 11 of 44

(ii) It has the required skills, technical knowledge, qualified personnel and expertise

to carry out it’s functions and obligations and to provide the services under this

Agreement and will build the necessary infrastructure for the purpose.

(iii) SI possesses the consents of appropriate authorities, licenses, permits and

approvals as are necessary for carrying out its functions and obligations under this

Agreement.

The parties hereby agree that the above is the basic understanding and based on which DoT has

entered into this Agreement

3 Scope of the Project

DoT has decided to roll out a Revenue Management System for the computerization and automation of the revenue management related processes/ functions of DoT. In this regard an RFP was floated by DoT for the Selection of the System Integrator who shall be responsible for Design, Develop, Rollout and Operations & Maintenance of the Revenue Management System (RMS) for a period of 5 years from the date of Go–Live including providing necessary infrastructure required for hosting of the solution on cloud based platform including the Disaster Recovery services for the project.

The broad scope of work of the System Integrator shall be to:

a) Design, Develop and Implement Revenue Management System for DoT

b) Provide necessary software, infrastructure and hosting services on cloud based infrastructure on “Platform as a Service” (PaaS) model.

c) Provide operations and maintenance support including technical support to the solution for a period of Five (5) years from the date of Go-Live (as mentioned in Volume-I of the RFP). Set-up support desk at DoT for initial 6 months of the maintenance phase to ensure successful rollout and acceptance of the system among stakeholders.

Detailed scope of work for the SYSTEM INTEGRATOR is outlined in Volume-I of the RFP document titled “RFP for Selection of Solution Integrator for the Design, Development, Implementation and Maintenance of Revenue Management System for DoT”, RFP No. 1-6/2004/LF II/Vol III, Dated 27/Mar/2018.

4 Term and Duration of the Agreement

This Agreement shall come into effect on <<dd/mmm/yyyy>> (hereinafter the ‘Effective Date’) and unless terminated earlier, this agreement shall be in force and effect for a period of five (5) years from the date of go-live of the Revenue Management System. After the end of the contract period, DoT reserves the right to either continue with the existing bidder with either same or revised terms and conditions as mutually agreed by both parties or sign a contract with other agency.



Page 12 of 44

5 Conditions Precedent and Effective Date

5.1 Provisions to take effect upon fulfilment of Conditions Precedent

Subject to express terms to the contrary, the rights and obligations under this Agreement shall take effect only upon fulfillment of all the Conditions Precedent set out below. However, DoT may at any time at its sole discretion waive fully or partially any of the Conditions Precedent for the System Integrator.

5.2 Conditions Precedent

5.2.1 Conditions Precedent of the Implementing Partner

The System Integrator shall be required to fulfill the Conditions Precedent which is as follows:

i) to comply with all the conditions stated in Schedule I, as per the timelines defined in it

ii) to provide a Performance Security/Guarantee and other guarantees/ payments as and when required to the DoT; and

iii) to provide the DoT certified true copies of its constitutional documents and board resolutions authorizing the execution, delivery and performance of this Agreement by the System Integrator

5.2.2 Conditions Precedent of the DoT

The DoT shall be required to fulfill the Conditions Precedent in which is as follows:

i) Access to required offices and site

ii) Necessary clearances

iii) Approval of the Project by a Competent Authority, etc.

For the avoidance of doubt, it is expressly clarified that the obligations of the Parties except the financial obligations of DoT under this Agreement shall commence from the fulfillment of the Conditions Precedent as set forth above.

5.3 Extension of time for fulfilment of Conditions Precedent

The Parties may, by mutual agreement extend the time for fulfilling the Conditions Precedent and the Term of this Agreement.

For the avoidance of doubt, it is expressly clarified that any such extension of time shall be subject to imposition of penalties on the System Integrator linked to the delay in fulfilling the Conditions Precedent.

5.4 Non-fulfilment of the System Integrator’s Conditions Precedent

5.4.1 In the event that any of the Conditions Precedent of the System Integrator have not been fulfilled within 15 days of signing of this Agreement and the same have not been waived fully or partially by DoT, this Agreement shall cease to exist;

5.4.2 In the event that the Agreement fails to come into effect on account of non-fulfillment of the System Integrator’s Conditions Precedent, the DoT shall not be liable in any manner whatsoever to the System Integrator and the DoT shall forthwith



Page 13 of 44

forfeit the Performance Bank Guarantee.

5.4.3 In the event that possession of any of the DoT facilities has been delivered to the System Integrator prior to the fulfillment of the Conditions Precedent, upon the termination of this Agreement such shall immediately revert to DoT, free and clear from any encumbrances or claims.

6 Change of Control

6.1 In the event of a change of control of the System Integrator during the Term, the System Integrator shall promptly notify DoT of the same with in a period of 15 days.

6.2 In the event that if the net worth of the surviving entity is less than that of System Integrator prior to the change of control, the DoT may within 30 days of becoming aware of such change in control, require a replacement of existing Performance Bank Guarantee furnished by the System Integrator from a guarantor acceptable to the DoT (which shall not be System Integrator or any of its associated entities).

6.3 If such a guarantee is not furnished within 30 days of the DoT requiring the replacement, the DoT may exercise its right to terminate this Agreement within a further 30 days by written notice, to become effective as specified in such notice.

6.4 Pursuant to termination, the consequences of termination as set out in Clause 14.3 of this Agreement shall follow.

6.5 For the avoidance of doubt, it is expressly clarified that the internal reorganization of the System Integrator shall not be deemed an event of a change of control for purposes of this Clause unless the surviving entity is of less net worth than the predecessor entity.

7 Representations and Warranties

7.1 Representations and warranties of the System Integrator

The System Integrator represents and warrants to the DoT that:

7.1.1 it is duly organized and validly existing under the laws of India, and has full power and authority to execute and perform its obligations under this Agreement and other agreements and to carry out the transactions contemplated hereby;

7.1.2 it is a competent provider of a variety of information technology and business process management services;

7.1.3 it has taken all necessary corporate and other actions under laws applicable to its business to authorize the execution and delivery of this Agreement and to validly exercise its rights and perform its obligations under this Agreement;

7.1.4 from the Effective Date, it will have the financial standing and capacity to undertake the Project in accordance with the terms of this Agreement;

7.1.5 in providing the Services, it shall use reasonable endeavors not to cause any unnecessary disruption to DoT's normal business operations



Page 14 of 44

7.1.6 this Agreement has been duly executed by it and constitutes a legal, valid and binding obligation, enforceable against it in accordance with the terms hereof, and its obligations under this Agreement shall be legally valid, binding and enforceable against it in accordance with the terms hereof;

7.1.7 the information furnished in the tender documents and as updated on or before the date of this Agreement is to the best of its knowledge and belief, true and accurate in all material respects as at the date of this Agreement;

7.1.8 the execution, delivery and performance of this Agreement shall not conflict with, result in the breach of, constitute a default by any of the terms of its Memorandum and Articles of Association or any Applicable Laws or any covenant, contract, agreement, arrangement, understanding, decree or order to which it is a party or by which it or any of its properties or assets is bound or affected;

7.1.9 there are no material actions, suits, proceedings, or investigations pending or, to its knowledge, threatened against it at law or in equity before any court or before any other judicial, quasi-judicial or other authority, the outcome of which may result in the breach of this Agreement or which individually or in the aggregate may result in any material impairment of its ability to perform any of its material obligations under this Agreement;

7.1.10 it has no knowledge of any violation or default with respect to any order, writ, injunction or decree of any court or any legally binding order of any Government Instrumentality which may result in any Adverse Effect on its ability to perform its obligations under this Agreement and no fact or circumstance exists which may give rise to such proceedings that would adversely affect the performance of its obligations under this Agreement;

7.1.11 it has complied with Applicable Laws in all material respects and has not been subject to any fines, penalties, injunctive relief or any other civil or criminal liabilities which in the aggregate have or may have an Adverse Effect on its ability to perform its obligations under this Agreement;

7.1.12 no representation or warranty by it contained herein or in any other document furnished by it to DoT in relation to the Required Consents contains or shall contain any untrue or misleading statement of material fact or omits or shall omit to state a material fact necessary to make such representation or warranty not misleading; and

7.1.13 no sums, in cash or kind, have been paid or shall be paid, by it or on its behalf, to any person by way of fees, commission or otherwise for entering into this Agreement or for influencing or attempting to influence any officer or employee of DoT in connection therewith.

7.2 Representations and warranties of the DoT

DoT represent and warrant to the System Integrator that:

7.2.1 it has full power and authority to execute, deliver and perform its obligations under this Agreement and to carry out the transactions contemplated herein and



Page 15 of 44

that it has taken all actions necessary to execute this Agreement, exercise its rights and perform its obligations, under this Agreement and carry out the transactions contemplated hereby;

7.2.2 it has taken all necessary actions under Applicable Laws to authorize the execution, delivery and performance of this Agreement and to validly exercise its rights and perform its obligations under this Agreement;

7.2.3 it has the financial standing and capacity to perform its obligations under the Agreement;

7.2.4 it is subject to the laws of India, and hereby expressly and irrevocably waives any immunity in any jurisdiction in respect of this Agreement or matters arising thereunder including any obligation, liability or responsibility hereunder;

7.2.5 this Agreement has been duly executed by it and constitutes a legal, valid and binding obligation enforceable against it in accordance with the terms hereof and its obligations under this Agreement shall be legally valid, binding and enforceable against it in accordance with the terms thereof;

7.2.6 the execution, delivery and performance of this Agreement shall not conflict with, result in the breach of, constitute a default under, or accelerate performance required by any of the Applicable Laws or any covenant, contract, agreement, arrangement, understanding, decree or order to which it is a party or by which it or any of its properties or assets is bound or affected;

7.2.7 there are no actions, suits or proceedings pending or, to its knowledge, threatened against it at law or in equity before any court or before any other judicial, quasi-judicial or other authority, the outcome of which may result in the default or breach of this Agreement or which individually or in the aggregate may result in any material impairment of its ability to perform its material (including any payment) obligations under this Agreement;

7.2.8 it has no knowledge of any violation or default with respect to any order, writ, injunction or any decree of any court or any legally binding order of any Government Instrumentality which may result in any Adverse Effect on the DoT ability to perform its obligations under this Agreement and no fact or circumstance exists which may give rise to such proceedings that would adversely affect the performance of its obligations under this Agreement;

7.2.9 it has complied with Applicable Laws in all material respects;

7.2.10 all information provided by it in the RFP in connection with the Project is, to the best of its knowledge and belief, true and accurate in all material respects; and

7.2.11 Upon the System Integrator performing the covenants herein, it shall not at any time during the term hereof, interfere with peaceful exercise of the rights and discharge of the obligations by the System Integrator, in accordance with this Agreement.



Page 16 of 44

8 Obligations of DoT

Without prejudice to any other undertakings or obligations of the DoT under this Agreement, the DoT shall perform the following:

8.1 To provide any support through personnel to test the system during the Term;

8.2 To provide any support through personnel and/or test data during development, rollout, steady state operation, as well as, for any changes/enhancements in the system whenever required due to scope change that may arise due to business, delivery or statutory/regulatory reasons;

8.3 DoT shall provide the data (including in electronic form wherever available) to be migrated.

8.4 To authorize the System Integrator to interact for implementation of the Project with external entities such as the Data Center/MeitY approved Cloud Service Providers, Payment/SMS/Email Gateway Service Providers etc.

9 Obligations of the System Integrator

9.1 It shall provide to the DoT, the Deliverables as set out in RFP document.

9.2 It shall perform the Services as set out in Clause 3 of this Agreement and in a good and workmanlike manner commensurate with industry and technical standards which are generally in effect for international projects and innovations pursuant thereon similar to those contemplated by this Agreement, and so as to comply with the applicable Service Levels set out with this Agreement.

9.3 It shall ensure that the Services are being provided as per the Project Timelines set out in Schedule-III to this Agreement.

10 Approvals and Required Consents

10.1 The Parties shall cooperate to procure, maintain and observe all relevant and regulatory and governmental licenses, clearances and applicable approvals (hereinafter the “Required Consents”) necessary for the System Integrator to provide the Services. The costs of such Approvals shall be borne by the Party normally responsible for such costs according to local custom and practice in the locations where the Services are to be provided.

10.2 The DoT shall use reasonable endeavors to assist System Integrator to obtain the Required Consents. In the event that any Required Consent is not obtained, the System Integrator and the DoT will co-operate with each other in achieving a reasonable alternative arrangement as soon as reasonably practicable for the DoT to continue to process its work with as minimal interruption to its business operations as is commercially reasonable until such Required Consent is obtained, provided that the System Integrator shall not be relieved of its obligations to provide the Services and to achieve the Service Levels until the Required Consents are obtained if and to the extent that the System Integrator’s obligations are not dependent upon such Required Consents.



Page 17 of 44

11 Use of Assets by the System Integrator

During the Term the System Integrator shall:

11.1 take all reasonable and proper care of the entire hardware and System, network or any other information technology infrastructure components used for the Project and other facilities leased / owned / operated by the System Integrator exclusively in terms of ensuring their usability for the delivery of the Services as per this Agreement (hereinafter the “Assets”) in proportion to their use and control of such Assets; and

11.2 Keep all the tangible Assets in as good and serviceable condition (reasonable wear and tear excepted) as at the date the System Integrator takes control of and/or first uses the Assets and during the entire Term of the Agreement.

11.3 ensure that any instructions or manuals supplied by the manufacturer of the Assets for use of the Assets and which are provided to the System Integrator will be followed by the System Integrator and any person who will be responsible for the use of the Assets;

11.4 take such steps as may be properly recommended by the manufacturer of the Assets and notified to the System Integrator or as may, in the reasonable opinion of the System Integrator, be necessary to use the Assets in a safe manner;

11.5 ensure that the Assets that are under the control of the System Integrator, are kept suitably housed and in conformity with Applicable Law;

11.6 procure permission from the DoT and any persons duly authorized by them to enter any land or premises on which the Assets are for the time being sited so as to inspect the same, subject to any reasonable third party requirements;

11.7 Unknowingly or negligently use or permit any of the Assets to be used in contravention of any statutory provisions or regulation or in any way contrary to Applicable Law.

12 Access to DoT Locations

12.1 For so long as the System Integrator provides services to the DoT location, as the case may be, on a non-permanent basis and to the extent necessary, the DoT as the case may be or its nominated agencies shall, subject to compliance by the System Integrator with any safety and security guidelines which may be provided by the DoT as the case may be or its nominated agencies and notified to the System Integrator in writing, provide the System Integrator with:

12.1.1 Reasonable access to the location, in the same manner granted to the DoT employees.

12.1.2 Reasonable work space, access to office equipment as mutually agreed and other related support services in such location and at such other the DoT as the case may be location, if any, as may be reasonably necessary for the System Integrator to perform its obligations hereunder and under the SLA.

12.2 Access to locations, office equipment and services shall be made available to the System



Page 18 of 44

Integrator on an “as is, where is” basis by the DoT as the case may be or its nominated agencies. The System Integrator agrees to ensure that its employees, agents and contractors shall not use the location, services and equipment referred to in RFP for the following purposes:

12.2.1 for the transmission of any material which is defamatory, offensive or abusive or of an obscene or menacing character; or

12.2.2 in a manner which constitutes a violation or infringement of the rights of any person, firm or company (including but not limited to rights of copyright or confidentiality).

13 Financial Matters

13.1 Terms of Payment and Service Credits and Debits

13.1.1 In consideration of the Services and subject to the provisions of this Agreement and of the SLA, the DoT shall pay the System Integrator for the Services rendered in pursuance of this agreement, in accordance with the Terms of Payment Schedule set out as Schedule-IV of this Agreement.

13.1.2 All payments shall be made to the System Integrator subject to the application of liquidated damages and/or SLA penalties as per Terms and Conditions defined in this RFP.

13.1.3 Save and except as otherwise provided for herein or as agreed between the Parties in writing, the DoT shall not be required to make any payments in respect of the Services (or, without limitation to the foregoing, in respect of the System Integrator performance of any obligations under this Agreement or the SLA) other than those covered in Schedule-IV of this Agreement. For the avoidance of doubt, it is expressly clarified that the payments shall be deemed to include all ancillary and incidental costs and charges arising in the course of delivery of the Services including consultancy charges, infrastructure costs, project costs, implementation and management charges and all other related costs including GST/Service Tax which are addressed in this Clause.

13.2 Invoicing and Settlement

13.2.1 Subject to the specific terms of the SLA, the System Integrator shall submit its invoices in accordance with the following principles:

13.2.1.1 The DoT shall be invoiced by the System Integrator for the Services. Generally and unless otherwise agreed in writing between the Parties or expressly set out in the SLA, the System Integrator shall raise an invoice as per Schedule-IV of this Agreement; and

13.2.1.2 Any invoice presented in accordance with this Article shall be in a form agreed with the DoT.

13.2.1.3 The System Integrator alone shall invoice all payments after receiving due approval from the competent authority. Such invoices shall be accurate and



Page 19 of 44

all adjustments to or changes in the terms of payment as stated in Schedule-IV of this Agreement.

13.2.2 Payment shall be made within 30 working days of the receipt of invoice along with supporting documents by the DoT subject to penalties. The penalties may be imposed on the vendor as per the SLA/LD criteria specified in the RFP.

13.2.3 The DoT shall be entitled to delay or withhold payment of any invoice or part of it delivered by the System Integrator under Schedule-IV of this Agreement. The withheld amount shall be limited to that which is in dispute. The disputed / withheld amount shall be settled post resolution of the dispute. Further, the System Integrator will not claim any interest on the arrear/payment due but not paid from DoT. Any exercise by the DoT under this Clause shall not entitle the System Integrator to delay or withhold provision of the Services.

13.2.4 The SI shall be solely responsible to make payment to its subcontractors.

13.3 Tax

13.3.1 The DoT shall be responsible for withholding taxes from the amounts due and payable to the System Integrator wherever applicable. The System Integrator shall pay for all other taxes in connection with this Agreement, SLA, scope of work and any other engagement required to be undertaken as a part of this Agreement, including, but not limited to, property, sales, use, excise, value-added, goods and services, consumption and other similar taxes or duties.

13.3.2 The DoT shall provide System Integrator with the original tax receipt of any withholding taxes paid by DoT on payments under this Agreement. The System Integrator agrees to reimburse and hold the DoT harmless from any deficiency including penalties and interest relating to taxes that are its responsibility under this paragraph. For purposes of this Agreement, taxes shall include taxes incurred on transactions between and among the DoT and the System Integrator.

13.3.3 If, after the date of submission of bid, there is any increase or decrease in the rate of GST/Service Tax, then all such change in the rate will be to the account of DoT.

13.3.4 The Parties shall cooperate to enable each Party to accurately determine its own tax liability and to minimize such liability to the extent legally permissible. In connection therewith, the Parties shall provide each other with the following:

i) any resale certificates;

ii) any relevant information regarding out-of-state or use of materials, equipment or services; and

iii) any direct pay permits, exemption certificates or information reasonably requested by the other Party.



Page 20 of 44

14 Termination

14.1 Right to Terminate

14.1.1 DoT has the right to terminate this Agreement upon giving 30 days written notice in that behalf being given by it to SI at any time after the happening of any of the following events:-

14.1.1.1 Any default or breach of any provision hereof and in case SI fails or neglects to cure any such default or breach within 15 days of being called upon in writing to do so by DoT.

14.1.1.2 Any order has been passed by a competent court for winding up of SI.

14.1.1.3 Any order has been passed by a Competent Authority attaching the assets or appointing a receiver to the property of SI which is used for providing services under this Agreement.

14.1.1.4 SI ceases or threatens to cease to carry on its business or, without the prior written approval of DoT disposes off the whole or substantially the whole of its undertaking or (except in the ordinary course of business) of its assets.

14.1.1.5 Execution of any decree upon or against any part of the property of SI which is used for providing services under this Agreement and the same is not discharged within fourteen days from the date of such execution.

14.1.1.6 Any change in control of SI, of which DoT is not informed within 15 days of such change.

14.1.2 Any omission or failure to act, by DoT subsequent to the happening of any of the above events shall not be deemed a waiver or a compromise of the right hereby conferred on DoT.

14.1.3 Prior to issue of the notice, DoT shall give SI a reasonable opportunity of hearing to enable it to make its submissions.

14.2 Effects of Termination

14.2.1 In the event that DoT terminates this Agreement pursuant to failure on the part of the System Integrator to comply with the conditions as contained in this clause and depending on the event of default, Performance Bank Guarantee furnished by System Integrator may be forfeited.

14.2.2 Upon termination of this Agreement, the Parties will comply with the Exit Management clause as specified in this Agreement.

14.2.3 In the event that DoT or the System Integrator terminates this Agreement, the compensation will be decided in accordance with the Terms of Payment Schedule set out as Schedule-IV of this Agreement.

14.2.4 DoT agrees to pay System Integrator for

14.2.4.1 all charges for the services System Integrator provides and any Deliverables and/or system (or part thereof) System Integrator delivers



Page 21 of 44

through termination, and

14.2.4.2 Reimbursable expenses that the System Integrator incurs through termination. If DoT terminates without cause, then DoT also agrees to pay any applicable adjustment expenses System Integrator incurs as a result of such termination (which System Integrator will take reasonable steps to mitigate).

14.2.4.3 If the termination is initiated before go-live, the financial settlement for the system integrator will be calculated on the basis of approved / signed off deliverables.

14.2.4.4 If the exit management is initiated post go-live, the financial settlement for the system integrator will be calculated on the basis of service provided during the operations and maintenance phase and schedule IV.

14.3 Consequences of termination

14.3.1 On expiry or termination of this Agreement: -

14.3.1.1 DoT, pending the appointment of another SI, may require SI to continue to provide all the services in scope and maintain all the assets (including database, system software, documents, cloud infrastructure and all other relevant materials relating to provision of services) that may be in its custody or control for a period of six months from the date of expiry/termination of contract, while adhering to terms and conditions of this Agreement. In case if DoT is not able to select replacement SI in the first three months from the date of termination of the agreement, in such a scenario the existing SI will have to continue providing all the services in scope and maintain all the assets (including database, system software, documents, cloud infrastructure and all other relevant materials relating to provision of services) for 9 months from the date of expiry/termination of the contract. This period is further extendable for another 3 months i.e. a total of 12 months from the date of expiry/termination of the agreement.

14.3.1.2 DoT, pending the appointment of another SI, may appoint an Administrator to take over the project assets of SI used in providing services to all the stakeholders and SI shall provide all assistance as may be required by the Administrator in taking over such assets including assets created exclusively for the purpose of continuity in operations and relevant data, application, cloud infrastructure, networks and all other facilities excluding physical infrastructure (building, air conditioners, power supply infrastructure, furniture and the like).

14.3.2 Furnishing Information

14.3.2.1 SI shall provide to DoT, all relevant information relating to the services provided, stakeholders, and performance data in relation to the services and also the following:

I. Documentation relating to Project's Intellectual Property Rights;



Page 22 of 44

II. All current and updated project data and documentation as is reasonably required for purposes of project for transitioning the services to its Replacement SI/Administrator;

III. All other information (including but not limited to documents, records and Agreements) relating to the services reasonably necessary to carry out due diligence in order to effect transition of services.

15 Exit Management

15.1 Exit Management Plan

15.1.1 The System Integrator shall submit a structured & detailed Exit Management plan along with the technical proposal. The System Integrator needs to update the Transition and Exit management on half yearly basis or earlier in case of major changes during the entire contract duration. This plan needs to be discussed and approved by the DoT.

15.1.2 The exit Management plan shall deal with at least the following aspects of exit management in relation to the SLA as a whole and in relation to the Project Implementation, the Operation and Management SLA and Scope of work definition:

15.1.2.1 A detailed program of the transfer process that could be used in conjunction with a Replacement Vendor including details of the means to be used to ensure continuing provision of the services throughout the transfer process or until the cessation of the services and of the management structure to be used during the transfer;

15.1.2.2 Plans for the communication with such of the System Integrator, staff, suppliers, customers and any related third party as are necessary to avoid any material detrimental impact on Project’s operations as a result of undertaking the transfer;

15.1.2.3 Plans for provision of contingent support to the Project and Replacement Vendor for a reasonable period (minimum one month) after transfer.

15.1.2.4 Plans for training of the Replacement System Integrator/DoT staff to run the operations of the project. This training plan along with the training delivery schedule should be approved by DoT. The delivery of training along with handholding support and getting the sign off on the same would be the responsibility of System Integrator.

15.1.3 At the end of the contract period or during the contract period, if any other agency is identified or selected for providing services related to the System Integrator scope of work, the System Integrator shall ensure that a proper and satisfactory handover is made to the other sgency.

15.1.4 All risk during transition stage shall be properly documented by the System Integrator and mitigation measures shall be planned in advance so as to ensure a smooth transition without any service disruption. The System Integrator must ensure that no end of support products (software/ hardware) exist at time of transition.



Page 23 of 44

15.1.5 The transition & exit management period will start three (3) months before the expiration of the contract. The System Integrator will provide shadow support for at least forty-five (45) days and secondary support for an additional forty-five (45) days before the end of the O&M period or expiry of the contract, as applicable at no additional cost to DoT.

15.1.6 In case of termination, the exit management period will start from effective date of termination or such other date as may be decided by DoT and communicated to the SI.

15.1.7 System Integrator must ensure closing off all critical open issues as on date of exit. All other open issues as on date of Exit shall be listed and provided to DoT.

15.1.8 The System Integrator shall provide necessary knowledge transfer and transition support. The deliverables are indicated below:

15.1.8.1 Updated transition plan on periodic basis

15.1.8.2 Complete documentation for the entire system handed over to the DoT/replacement System Integrator/identified agency.

15.1.8.3 Handover of all AMC support related documents, credentials etc. for all OEM products supplied/maintained in the system. Handover MOUs signed for taking services taken from third parties such as digital signature agencies, etc.

15.1.8.4 Handover of the list of complete inventory of all assets created for the project.

15.1.8.5 Assisting the new System Integrator/DoT with the complete audit of the system including licenses and physical assets.

15.1.8.6 Detailed walk-throughs and demos for the solution.

15.1.8.7 Hand-over of the all project deliverables, entire software including source code, program files, configuration files, setup files, project documentation, user IDs, passwords, security policies, scripts etc.

15.1.8.8 Hand-over of the user IDs, passwords, security policies, scripts etc. to replacement System Integrator.

15.1.9 Knowledge transfer of the system to the incoming System Integrator to the satisfaction of the DoT.

15.1.10 The System Integrator shall be released from the project once successful transition is completed by meeting the parameters defined for successful transition

15.1.11 The System Integrator shall ensure that the DoT data, assets, images in the cloud must be preserved for a period of 6 months from the end of contract. This shall not be deleted / destroyed without the prior consent of DoT.

15.1.12 During the exit management period, the System Integrator shall use its best efforts to deliver the services.

15.1.13 Payments during the Exit Management period shall be made in accordance with the Terms of Payment Plan.



Page 24 of 44

15.2 Training, hand-holding and knowledge transfer

15.2.1 The System Integrator shall hold technical knowledge transfer sessions with designated technical team of Department and/or any designated agency in the last three (3) months of the project duration.

15.2.2 The System Integrator shall hold operational hand-holding sessions on the RMS Application with the designated officers/ staff members, so that department can continue with the RMS application even after System Integrator exits the project.

16 Indemnification and Limitation of Liability

16.1 Indemnification

16.1.1 Subject to Clause 16.1.5 below, System Integrator (the "Indemnifying Party") undertakes to indemnify DoT (the "Indemnified Party") from and against all losses on account of bodily injury, death or damage to tangible personal property arising in favor of any person, corporation or other entity (including the Indemnified Party) attributable to the Indemnifying Party's negligence or willful default in performance or non-performance under this Agreement.

16.1.2 If the Indemnified Party promptly notifies Indemnifying Party in writing of a third party claim against Indemnified Party that any Service provided by the Indemnifying Party infringes a copyright, trade secret or patents incorporated in India of any third party, Indemnifying Party will defend such claim at its expense and will pay any costs or damages that may be finally awarded against Indemnified Party.

16.1.3 Indemnifying Party will not indemnify the Indemnified Party, however, if the claim of infringement is caused by

16.1.3.1 Indemnified Party’s misuse or modification of the Service;

16.1.3.2 Indemnified Party’s failure to use corrections or enhancements made available by the Indemnifying Party;

16.1.3.3 Indemnified Party’s use of the Service in combination with any product or information not owned or developed by Indemnifying Party;

16.1.3.4 Indemnified Party’s distribution, marketing or use for the benefit of third parties of the Service; or

16.1.3.5 Information, direction, specification or materials provided by Indemnified Party or any third party contracted to it.

16.1.4 If any Service is or likely to be held to be infringing, Indemnifying Party shall at its expense and option either

16.1.4.1 Procure the right for Indemnified Party to continue using it,

16.1.4.2 Replace it with a non-infringing equivalent,

16.1.4.3 Modify it to make it non-infringing.

16.1.4.4 The foregoing remedies constitute Indemnified Party’s sole and exclusive remedies and Indemnifying Party’s entire liability with respect to



Page 25 of 44

infringement.

16.1.5 The indemnities set out in Clause 16.1 shall be subject to the following conditions:

16.1.5.1 the Indemnified Party as promptly as practicable informs the Indemnifying Party in writing of the claim or proceedings and provides all relevant evidence, documentary or otherwise;

16.1.5.2 the Indemnified Party shall, at the cost of the Indemnifying Party, give the Indemnifying Party all reasonable assistance in the Defense of such claim including reasonable access to all relevant information, documentation and personnel provided that the Indemnified Party may, at its sole cost and expense, reasonably participate, through its attorneys or otherwise, in such Defense;

16.1.5.3 if the Indemnifying Party does not assume full control over the Defense of a claim as provided in this Article, the Indemnifying Party may participate in such Defense at its sole cost and expense, and the Indemnified Party will have the right to defend the claim in such manner as it may deem appropriate, and the cost and expense of the Indemnified Party will be included in Losses;

16.1.5.4 the Indemnified Party shall not prejudice, pay or accept any proceedings or claim, or compromise any proceedings or claim, without the written consent of the Indemnifying Party;

16.1.5.5 All settlements of claims subject to indemnification under this Clause will

16.1.5.5.1 be entered into only with the consent of the Indemnified Party, which consent will not be unreasonably withheld and include an unconditional release to the Indemnified Party from the claimant or plaintiff for all liability in respect of such claim and

16.1.5.5.2 include any appropriate confidentiality agreement prohibiting disclosure of the terms of such settlement;

16.1.5.6 the Indemnified Party shall account to the Indemnifying Party for all awards, settlements, damages and costs (if any) finally awarded in favor of the Indemnified Party which are to be paid to it in connection with any such claim or proceedings;

16.1.5.7 the Indemnified Party shall take steps that the Indemnifying Party may reasonably require to mitigate or reduce its loss as a result of such a claim or proceedings;

16.1.5.8 in the event that the Indemnifying Party is obligated to indemnify an Indemnified Party pursuant to this Article, the Indemnifying Party will, upon payment of such indemnity in full, be subrogated to all rights and defenses of the Indemnified Party with respect to the claims to which such indemnification relates; and

16.1.5.9 if a Party makes a claim under the indemnity in respect of any particular Loss or Losses, then that Party shall not be entitled to make any further claim in



Page 26 of 44

respect of that Loss or Losses (including any claim for damages).

16.2 Limitation of Liability

16.2.1 The aggregate liability of System Integrator (whether in contract, tort, negligence, strict liability in tort, by statute or otherwise) for any claim in any manner related to this Agreement, including the work, deliverables or Services covered by this Agreement, shall be the payment of direct damages only which shall in no event exceed one time the total contract value payable under this Agreement. The liability cap given under this Clause shall not be applicable to the indemnification obligations set out in Clause 16 and breach of Clause 18.

16.2.2 In no event shall either party be liable for any consequential, incidental, indirect, special or punitive damage, loss or expenses (including but not limited to business interruption, lost business, lost profits, or lost savings) nor for any third party claims (other than those set-forth in Clause 16.1) even if it has been advised of their possible existence.

16.2.3 The allocations of liability in this Clause 16 represent the agreed and bargained for understanding of the parties and compensation for the Services reflects such allocations. Each Party has a duty to mitigate the damages and any amounts payable under an indemnity that would otherwise be recoverable from the other Party pursuant to this Agreement by taking appropriate and commercially reasonable actions to reduce or limit the amount of such damages or amounts.

17 Force Majeure

17.1 Definition of Force Majeure

The System Integrator or the DoT as the case may be, shall be entitled to suspend or excuse performance of its respective obligations under this Agreement to the extent that such performance is impeded by an event of force majeure (‘Force Majeure’).

17.2 Force Majeure events

A Force Majeure event means any event or circumstance or a combination of events and circumstances referred to in this Clause, which:

17.2.1 is beyond the reasonable control of the affected Party;

17.2.2 such Party could not have prevented or reasonably overcome with the exercise of reasonable skill and care;

17.2.3 does not result from the negligence of such Party or the failure of such Party to perform its obligations under this Agreement;

17.2.4 is of an incapacitating nature and prevents or causes a delay or impediment in performance; and

17.2.5 may be classified as all or any of the following events:



Page 27 of 44

17.2.5.1 Non-Political Events

a. act of God, including earthquake, flood, inundation, landslide, exceptionally adverse weather conditions, storm, tempest, hurricane, cyclone, lightning, thunder, volcanic eruption, fire or other extreme atmospheric conditions;

b. radioactive contamination or ionizing radiation or biological contamination except as may be attributable to the System Integrator’s use of radiation or radio- activity or biologically contaminating material;

c. strikes, lockouts, boycotts, labour disruptions or any other industrial disturbances as the case may be not arising on account of the acts or omissions of the System Integrator and which affect the timely implementation and continued operation of the Project; or

d. any event or circumstances of a nature analogous to any of the foregoing.

17.2.5.2 Political Events

a. Change in Law, other than any Change in Law for which relief is provided under this Agreement;

b. expropriation or compulsory acquisition by the DoT agencies of any material assets or rights of the Implementing Partner;

c. unlawful or unauthorized revocation of, or refusal by DoT or any of their nominated agencies, GoI or any of its agencies to renew or grant any clearance or Required Consents required by the System Integrator to perform its obligations without valid cause, provided that such delay, modification, denial, refusal or revocation did not result from the System Integrator’s inability or failure to comply with any condition relating to grant, maintenance or renewal of such Required Consents applied on a non-discriminatory basis;

d. any judgment or order of any court of competent jurisdiction or statutory authority in India made against the System Integrator in any proceedings for reasons other than failure of the System Integrator to comply with Applicable Laws or Required Consents or on account of breach thereof, or of any contract, or enforcement of this Agreement or exercise of any of its rights under this Agreement;

e. expropriation or compulsory acquisition by the DoT or any of their nominated agencies of any material assets or rights of the System Integrator;

f. unlawful or unauthorized revocation of, or refusal by any authority other than the DoT or any of their nominated agencies to renew or grant any Required Consents required by the System Integrator to perform its obligations without valid cause, provided that such delay, modification, denial, refusal or revocation did not result from the System Integrator’s inability or failure to comply with any condition relating to grant, maintenance or renewal of such Required Consents applied on a non-discriminatory basis;

g. any requisition of the Project by any other authority; or



Page 28 of 44

h. any requisition of the Project by the DoT or any of their nominated agencies.

i. For the avoidance of doubt, suspension of the Project in accordance with the provisions of this Agreement shall not be considered a requisition for the purposes of Force Majeure event.

17.2.5.3 Other Events

a. an act of war (whether declared or undeclared), hostilities, invasion, armed conflict or act of foreign enemy, blockade, embargo, prolonged riot, insurrection, terrorist or military action, civil commotion or politically motivated sabotage, for a continuous period exceeding seven (7) days.

17.2.6 For the avoidance of doubt, it is expressly clarified that the failure on the part of the System Integrator under this Agreement or the SLA to implement any disaster contingency planning and back-up and other data safeguards in accordance with the terms of this Agreement or the SLA against natural disaster, fire, sabotage or other similar occurrence shall not be deemed to be a Force Majeure event.

17.2.7 For the avoidance of doubt, it is further clarified that any negligence in performance of Services which directly causes any breach of security like hacking aren’t the forces of nature and hence wouldn’t be qualified under the definition of “Force Majeure”. In so far as applicable to the performance of Services, Service Provider will be solely responsible to complete the risk assessment and ensure implementation of adequate security hygiene, best practices, processes and technology to prevent any breach of security and any resulting liability therefrom (wherever applicable).

17.3 Notification procedure for Force Majeure

17.3.1 The affected Party shall notify the other Party of a Force Majeure event within seven (7) days of occurrence of such event. If the other Party disputes the claim for relief under Force Majeure it shall give the claiming Party written notice of such dispute within thirty (30) days of such notice. Such dispute shall be dealt with in accordance with the dispute resolution mechanism in accordance with Clause 23.

17.3.2 Upon cessation of the situation which led the Party claiming Force Majeure, the claiming Party shall within seven (7) days hereof notify the other Party in writing of the cessation and the Parties shall as soon as practicable thereafter continue performance of all obligations under this Agreement.

17.4 Allocation of Costs Arising Out of Force Majeure

17.4.1 Upon the occurrence of any Force Majeure Event prior to the Effective Date, the Parties shall bear their respective costs and no Party shall be required to pay to the other Party any costs thereof.

17.4.2 Upon occurrence of a Force Majeure Event after the Effective Date, the costs incurred and attributable to such event and directly relating to the Project (‘Force Majeure Costs’) shall be allocated and paid as follows:

17.4.2.1 upon occurrence of a Non-Political Event, the Parties shall bear their respective Force Majeure Costs and neither Party shall be required to pay to



Page 29 of 44

the other Party any costs thereof.

17.4.2.2 upon occurrence of any Other Event of Force Majeure, all Force Majeure Costs attributable to such Other Event, and not exceeding the Insurance Cover for such Other Event, shall be borne by the Implementing Partner and to the extent Force Majeure costs exceed such Insurance Cover, one half of such excess amount shall be reimbursed by DoT to the Implementing Partner.

17.4.2.3 upon occurrence of a Political Event, all Force Majeure Costs attributable to such Political Event shall be reimbursed by DoT to the Implementing Partner.

17.4.2.4 For the avoidance of doubt, Force Majeure Costs may include interest payments on debt, operation and maintenance expenses, any increase in the cost of the Services on account of inflation and all other costs directly attributable to the Force Majeure Event.

17.4.2.5 Save and except as expressly provided in this Clause, neither Party shall be liable in any manner whatsoever to the other Party in respect of any loss, damage, costs, expense, claims, demands and proceedings relating to or arising out of occurrence or existence of any Force Majeure Event or exercise of any right pursuant hereof.

17.5 Consultation and Duty to Mitigate

Except as otherwise provided in this Clause, the affected Party shall, at its own cost, take all steps reasonably required to remedy and mitigate the effects of the Force Majeure event and restore its ability to perform its obligations under this Agreement as soon as reasonably practicable. The Parties shall consult with each other to determine the reasonable measures to be implemented to minimize the losses of each Party resulting from the Force Majeure event. The affected Party shall keep the other Parties informed of its efforts to remedy the effect of the Force Majeure event and shall make reasonable efforts to mitigate such event on a continuous basis and shall provide written notice of the resumption of performance hereunder.

18 Confidentiality

In the course of performing its functions and obligations under this Agreement, System Integrator shall maintain strict secrecy, confidentiality and privacy in respect of the confidential records and information that has come to its possession or knowledge.

18.1 System Integrator shall keep confidentiality of the details and information with regard to the Project, including systems, facilities, operations, management and maintenance of the systems.

18.2 It is agreed between DoT and System Integrator that DoT has a right to prevent or prohibit System Integrator at any time from disclosing any information and records to any person and System Integrator shall abide by such decision except as required by any Statutory bodies or by due process of law.

18.3 System Integrator agrees that it shall ensure that all its employees, agents, service providers and any another related stakeholder are bound by nondisclosure



Page 30 of 44

agreements, and shall provide copies of such agreements to DoT whenever required.

18.4 All Proprietary Information, documentation and correspondence exchanged between DoT and System Integrator in relation to the Project and the performance of tasks by System Integrator shall be treated as confidential and privileged by the parties and disclosed only to their respective officers, agents, representatives, professional advisors and members of Official Committees (if any, formed for the purpose) on a need to know basis.

18.5 System Integrator shall treat information and records provided to it or obtained otherwise by it in connection with the Project or its implementation as confidential and not use the same wholly or partially for any purpose other than for discharging the obligations under this Agreement, without the prior written approval of DoT except as required by any Statutory bodies or by due process of law.

18.6 Information that is in the public domain shall not be considered as confidential information under this Agreement.

19 Intellectual Property Rights

19.1 Products and fixes: All products and related solutions and fixes provided pursuant to this work order shall be licensed according to the terms of the license agreement packaged with or otherwise applicable to such product. System Integrator would be responsible for arranging any licenses associated with products. “Product” means any computer code, web-based services, or materials comprising commercially released, pre-release or beta products (whether licensed for a fee or no charge) and any derivatives of the foregoing which are made available to DoT for license which is published by product owner or its affiliates, or a third party. “Fixes” means product fixes that are either released generally (such as commercial product service packs) or that are provided to you when performing services (such as workarounds, patches, bug fixes, beta fixes and beta builds) and any derivatives of the foregoing.

19.2 Bespoke development: Subject to the provisions of Clause 19.3 and 19.4 below, upon payment, the IPR rights for any bespoke development done during the implementation of the project will lie with DoT. System Integrator shall be entitled to a broad license back in the bespoke development for its internal usage and other e-governance projects.

19.3 Pre-existing work: All IPR including the source code and materials developed or otherwise obtained independently of the efforts of a party under this Agreement (“pre-existing work”) including any enhancement or modification thereto shall remain the sole property of that party. During the performance of the services for this agreement, each party grants to the other party (and their subcontractors as necessary) a non-exclusive license to use, reproduce and modify any of its pre-existing work provided to the other party solely for the performance of such services for duration of the Term of this Agreement. Except as may be otherwise explicitly agreed to in a statement of services, upon payment in full, the System Integrator should grant DoT a non-exclusive, perpetual, fully paid-up license to use the pre-existing work in



Page 31 of 44

the form delivered to DoT as part of the service or deliverables only for its internal business operations. Under such license, either of parties will have no right to sell the pre-existing work of the other party to a Third Party. DoT’s license to pre-existing work is conditioned upon its compliance with the terms of this Agreement and the perpetual license applies solely to the pre-existing work that bidder leaves with DoT at the conclusion of performance of the services.

19.4 Residuals: In no event shall System Integrator be precluded from independently developing for itself, or for others, anything, whether in tangible or non-tangible form, which is competitive with, or similar to, the deliverables set-out in this Agreement or Annexure. In addition, subject to the confidentiality obligations, System Integrator shall be free to use its general knowledge, skills and experience, and any ideas, concepts, know-how, and techniques that are acquired or used in the course of providing the Services.

20 Warranty

20.1 Standard: The System Integrator warrants that the Project, including all the system(s) and other Services provided, shall be free from any defect or deficiency in the material, design, engineering, and performance/ workmanship that prevent the Project and/or any of its systems(s) from fulfilling the functional or technical requirements or that limit in a material fashion the performance, reliability, or extensibility of the Project and/or any of its system(s) as per warranty period defined in the RFP. The warranty period for the project shall be 1 month from the date of successful completion of User Acceptance Testing / Final Acceptance Testing of the Revenue Management System for DoT. If during the warranty period any defect or deficiency is found in the material, design and performance/workmanship of the Project and other Services provided by the System Integrator, the System Integrator shall promptly, in consultation and agreement with DoT, and at the System Integrator’s sole cost repair, replace, or otherwise make good (as the System Integrator shall, at its discretion, determine) such default, defect or deficiency as well as any damage to the Project caused by such default, defect or deficiency. Any defective system that has been replaced by the System Integrator shall remain the property of the System Integrator. If the Project or any of its System cannot be used by reason of such default, defect or deficiency and/or making good of such default, defect or deficiency, the warranty period for the Project shall be extended by a period equal to the period during which the Project or any of its system could not be used by the DoT because of such defect and/or making good of such default, defect or deficiency.

20.2 Implied Warranty: The warranties provided herein are in lieu of all other warranties, both express and implied, and all other warranties, including without limitation that of merchantability or fitness for intended purpose is specifically disclaimed.

20.3 The System Integrator shall have no liability in the case of breach of this warranty due to

20.3.1 use of the deliverables on any environment (hardware or System) other than the environment recommended or approved by the System Integrator,



Page 32 of 44

20.3.2 the combination, operation, or use of some or all of the deliverables with information, System, specifications, instructions, data, or materials not approved by the System Integrator;

20.3.3 the deliverables having been tampered with, altered or modified by DoT without the written permission of the System Integrator, or (iv) use of the deliverables otherwise than in terms of the relevant documentation.

21 Liquidated Damages

Time is the essence of the Agreement and the delivery dates are binding on the System Integrator. In the event of the System Integrator’s default in adhering to the agreed time frame/ scheduled set of activities as laid down in the contract or any negligence, for causes attributable to the System Integrator, System Integrator shall be liable to pay liquidated damage @ 0.5% of the milestone value per week of delay subject to a maximum of 10% of the milestone value. Further, across all the milestones liquidated damage will be capped at 10% of the total contract value. DoT has the final authority to adjudicate.

22 Governing Laws / Jurisdiction Arbitration

Any matter relating to the appointing of System Integrator or the procedure for the appointment of the System Integrator shall be governed by the Laws of Union of India.

23 Arbitration and Legal Jurisdiction

23.1 In the event of any question, dispute or difference arising under the agreement in connection therewith (except as to matters, the decision to which is specifically provided under this agreement) the same shall be referred to sole arbitration of the Secretary, DOT (hereinafter referred to as the said officer) and if the Secretary, DOT is unable or unwilling to act as such, than to the sole arbitration of some other person appointed by the Secretary, DOT. The agreement to appoint an arbitrator will be in accordance with the Arbitration and Conciliation Act, 1996. The adjudication of such Arbitrator shall be governed by the provisions of the Arbitration and Conciliation Act, 1996 or any statutory modification or re-enactment thereof or any rules made thereof.

23.2 The arbitrator may from time to time with the consent of both the parties enlarge the time frame for making and publishing the award. Subject to aforesaid Arbitration and Conciliation Act, 1996 and the rules made there under, any modification thereof for the time being in force shall be deemed to apply to the arbitration proceeding under this clause.

23.3 The venue of the arbitration proceeding shall be the office of Secretary, DOT or such other place as the arbitrator may decide.

23.4 However, disputes which remain unresolved further shall be subject to the jurisdiction of Delhi only.

23.5 Upon any and every reference as aforesaid, the assessment of costs and incidental expenses in the proceedings for the award shall be at the discretion of the Arbitrator.



Page 33 of 44

24 Miscellaneous

24.1 Personnel

24.1.1 The personnel assigned by System Integrator to perform the Services shall be employees of System Integrator, and under no circumstances shall such personnel be considered employees of DoT. The System Integrator shall have the sole responsibility for the supervision and control of the personnel deployed in the Project and for payment of such personnel’s compensation, including salary, withholding of income taxes and social security taxes, worker’s compensation, employee and disability benefits and the like and shall be responsible for all obligations of an employer subject to Applicable Law.

24.1.2 The System Integrator shall use its best efforts to ensure that sufficient System Integrator personnel are assigned to perform the Services and that such personnel have appropriate qualifications to perform the Services. After discussion with System Integrator, DoT shall have the right to require the removal or replacement of any System Integrator personnel performing work under this Agreement based on bonafide reasons. In the event that DoT requests that any System Integrator personnel be replaced, the substitution of such personnel shall be accomplished pursuant to a mutually agreed upon schedule.

24.1.3 In the event that the DoT and System Integrator identify any personnel of System Integrator as “Key Personnel”, then the System Integrator shall not remove such personnel from the Project without the prior written consent of DoT unless such removal is the result of an unavoidable circumstance including but not limited to resignation, termination, medical leave, etc.

24.1.4 Each Party shall be responsible for the performance of all its obligations under this Agreement or the SLA as the case may be and shall be liable for the acts and omissions of its employees and agents in connection therewith.

24.1.5 Neither Party will solicit for employment or knowingly hire an employee of the other Party with whom such Party has contact pursuant to project engagements under this Agreement. This restriction shall not apply to employees of either Party responding to advertisements in job fairs or news media circulated to the general public.

24.2 Assignment

24.2.1 All terms and provisions of this Agreement shall be binding on and shall inure to the benefit of the DoT and their respective successors and permitted assigns.

24.2.2 Subject to Clause 6, the selected System Integrator may assign/ sub contract its rights and obligations under this Agreement to a third party according to their solution proposed to DoT for providing Data Centre and Disaster Recovery Centre services. The System Integrator shall provide details of all such assignments including the contact details of such third parties/ sub-contractors in their



Page 34 of 44

technical proposal. In case of any change of subcontracting arrangement prior return approval of DoT has to be taken. However, the Revenue Management System implementation and roll out services cannot be assigned/ sub contract to any third party under this contract.

24.3 Trademarks, Publicity

Neither Party may use the trademarks of the other Party without the prior written consent of the other Party except that System Integrator may, upon completion, use the Project as a reference for credential purpose. Except as required by law or the rules and regulations of each stock exchange upon which the securities of one of the Parties is listed, neither Party shall publish or permit to be published either alone or in conjunction with any other person any press release, information, article, photograph, illustration or any other material of whatever kind relating to this Agreement, the SLA or the business of the Parties without prior reference to and approval in writing from the other Party, such approval not to be unreasonably withheld or delayed provided however that System Integrator may include DoT or its client lists for reference to third parties subject to the prior written consent of DoT not to be unreasonably withheld or delayed. Such approval shall apply to each specific case and relate only to that case.

24.4 Notices

24.4.1 Any notice or other document which may be given by either Party under this Agreement shall be given in writing in person or by pre-paid recorded delivery post or email.

24.4.2 In relation to a notice given under this Agreement, any such notice or other document shall be addressed to the other Party’s principal or registered office address with a copy to System Integrator. In relation to a notice given under the agreement, a Party shall specify the Parties’ address for service of notices, any such notice to be copied to the Parties at the addresses set out in this Clause.

24.4.3 Any such notice or other document shall be deemed to have been given to the other Party (or, if relevant, its relevant associated company) when delivered (if delivered in person) if delivered between the hours of 9.00 am and 5.00 pm at the address of the other Party set forth above or if sent by fax, provided the copy fax is accompanied by a confirmation of transmission, or on the next working day thereafter if delivered outside such hours, and 7 days from the date of posting (if by letter).

24.4.4 Either Party to this Agreement may change its address, telephone number and nominated contact for notification purposes by giving the other reasonable prior written notice of the new information and its effective date.

24.5 Variations and Further Assurance

24.5.1 No amendment, variation or other change to this Agreement shall be valid unless authorized in accordance with the change control procedure as set out in the Change Control Schedule set out in Schedule-II of this Agreement. Such amendment shall be made in writing and signed by the duly authorized



Page 35 of 44

representatives of the Parties to this Agreement.

24.5.2 Each Party to this Agreement agrees to enter into or execute, without limitation, whatever other agreement, document, consent and waiver and to do all other things which shall or may be reasonably required to complete and deliver the obligations set out in this Agreement.

24.6 Severability and Waiver

24.6.1 If any provision of this Agreement, or any part thereof, shall be found by any court or administrative body of competent jurisdiction to be illegal, invalid or unenforceable the illegality, invalidity or unenforceability of such provision or part provision shall not affect the other provisions of this Agreement or the remainder of the provisions in question which shall remain in full force and effect. The relevant Parties shall negotiate in good faith in order to agree to substitute for any illegal, invalid or unenforceable provision a valid and enforceable provision which achieves to the greatest extent possible the economic, legal and commercial objectives of the illegal, invalid or unenforceable provision or part provision.

24.6.2 No failure to exercise or enforce and no delay in exercising or enforcing on the part of either Party to this Agreement of any right, remedy or provision of this Agreement shall operate as a waiver of such right, remedy or provision in any future application nor shall any single or partial exercise or enforcement of any right, remedy or provision preclude any other or further exercise or enforcement of such right, remedy or provision or the exercise or enforcement of any other right, remedy or provision.

24.7 Compliance with Applicable Law

Each Party to this Agreement accepts that its individual conduct shall (to the extent applicable to its business like the System Integrator as an information technology service provider) at all times comply with all laws, rules and regulations of government and other bodies having jurisdiction over the area in which the Services are undertaken provided that changes in such laws, rules and regulation which result in a change to the Services shall be dealt with in accordance with the Change Control Schedule set out in Schedule-II of this Agreement.

24.8 Professional Fees

All expenses incurred by or on behalf of each Party to this Agreement and the SLA, including all fees of agents, legal advisors, accountants and actuaries employed by either of the Parties connection with the negotiation, preparation in and execution of this Agreement or the SLA shall be borne solely by the Party which incurred them.

24.9 Ethics

The System Integrator represents, warrants and covenants that it has given no commitments, payments, gifts, kickbacks, lavish or expensive entertainment, or other things of value to any employee or agent of DoT in connection with this agreement and acknowledges that the giving of any such payment, gifts, entertainment, or other things of value is strictly in violation of DoT standard policies and may result in cancellation of this Agreement.



Page 36 of 44

24.10 Entire Agreement

This Agreement with all schedules appended thereto and the contents and specifications of the RFP constitute the entire agreement between the Parties with respect to their subject matter, and as to all other representations, understandings or agreements which are not fully expressed herein, provided that nothing in this Clause shall be interpreted so as to exclude any liability in respect of fraudulent misrepresentation.

24.11 Amendment

Any amendment to this Agreement shall be made in accordance with the Change Control Schedule set out in Schedule- I I of this Agreement by mutual written consent of all the Parties.

This Agreement shall be with effect from <<dd/mmm/yyyy>>.

In WITNESS WHEREOF the parties hereto have executed this Agreement as of the day and year herein above written.

SIGNED for and on behalf of SIGNED for and on behalf of

Department of Telecommunications, (DoT) System Integrator (SI)

By Sh. By Sh.

Signature __________ Signature ____________

Witness____________ Witness ____________

Name: Name:

Place: Place:

Date: Date



Page 37 of 44

SCHEDULES

SCHEDULE – I: RFP Document

RFP for “Selection of System Integrator for the Design, Development, Implementation and Maintenance of Revenue Management System for DoT” (Volume-I & II)

<< The Published RFP copy will be placed here for reference>>



Page 38 of 44

SCHEDULE – II: Change Control Schedule

CHANGE CONTROL PROCEDURE

System Integrator recognizes that frequent change is an inevitable part of delivering services. DoT recognizes that this change may require modification in the systems and re-organizing processes and therefore may have a financial impact. DoT will work with System Integrator to ensure that all changes are discussed and managed in a constructive manner.

This section describes the procedure to be followed in the event of any proposed changes to the Master Service Agreement (MSA), the Project Implementation, the operation, the SLA or Scope of work and Functional Requirement specifications. Such change shall include, but not be limited to, changes in the scope of services provided by System Integrator, addition of new SLAs and changes to the terms of payment as stated in the Terms of Payment.

Change Control Note (“CCN”)

a. Change requests in respect of the MSA, the Project Implementation, the operation, the SLA or Scope of work and Functional Requirement specifications will emanate from the Parties' respective Project Management Unit (PMU), who will be responsible for obtaining approval for the change and will complete part A of CCN provided in this schedule

b. Parties, while evaluating and finalizing CCN, shall consider the change in the context of the following parameter, namely whether the change is beyond the scope of Services including ancillary and concomitant services required and as detailed in RFP documents.

c. Change requests and CCNs will be reported monthly to DoT who will prioritize and review progress. System Integrator shall be obliged to implement any proposed changes once approval in accordance of Part B: CCN (Evaluation and Finalization) provided in this schedule with effect from the date agreed for implementation.

d. On evaluation of the financial impact, the charges for such a change will be decided between the DoT and System Integrator and will be a part of the Change Control Notice (Evaluation and Finalization).The payment for such changes will be as per the Terms of Payment to be decided by DoT and System Integrator.

Part a: Change Control Notice (Initiation)

Change Control Note CCN Number: Request Date:

Title of the request for change

Party Requesting change

Party Expected to Implement the change



Page 39 of 44

Details of Proposed Change

(To include reason for change and appropriate details/specifications)

Signature of the Party Proposing the change

Part B: Change Control Notice (Evaluation and Finalization)

Reference CCN Number: Date on which change request initiated: Party Proposed : Title: Date:

Brief Description of Solution/Procedure for implementation of change)

Impact: a) Operational Impact b) Systems Impact

Deliverables: ( to be provided by the party implementing the change)

Charges for the proposed change a) One-Time Cost b) Recurring Cost

Implementation Schedule along with roles and responsibilities: ( to be agreed mutually by parties initiating and implementing the change)



Page 40 of 44

Other Relevant Information: (including acceptance criteria, if any during/after implementation)

Signature of System Integrator ( as an acceptance of the change initiator/Implementer)

Signature of DoT ( as an acceptance of the change initiator/Implementer)



Page 41 of 44

SCHEDULE – III: Implementation Timelines

The project schedules for the implementation of Revenue Management System development are as follows:

S.

No.

Activities Time for

Completion1

Deliverables

from SI*

1. Signing of Contract with successful bidder Date of Start (T) –

2. Preparation and submission of the SRS document, T + 6 Weeks D1

3. Preparation and submission of Software Design

Specifications, including solution architecture and

design of the Revenue Management System

T + 12 weeks D2

4. Commissioning of cloud platform and disaster

recovery center along with supporting tools/

software

T + 16 Weeks D3

5. Acceptance testing of cloud platform and disaster

recovery center, and preparation of the data

migration strategy

T + 20 Weeks D4

6. Development of Revenue Management System T + 24 Weeks D5

7. Testing of RMS T + 28 Weeks D6

8. User Acceptance Testing T + 32Weeks D7

9. Data Migration T + 33 Weeks D8

10. Training to key staffs/ users T + 34 Weeks D9

11. Warranty exit for Revenue Management System and

Go-Live date

T + 36 Weeks D10

12. Annual Maintenance Support 5 years from Date

of Go-Live

D11

* Please refer clause 5.21 (deliverables) of Volume – I for details of deliverables.

1 Any timelines related changes amongst activities may be discussed with the SI, but the overall duration of the project

(36 weeks) will remain unchanged.



Page 42 of 44

If there are any changes to the signed off To-Be Processes, the implementation schedule may have to be revised. Also data migration strategy as well as procedure will have to be signed off by DoT before starting the data migration.

The aforesaid schedule can be accomplished, subject to the following also being completed as per

the defined schedule

1. SRS document Sign off by DoT

2. Availability of required resources for Data migration study

3. UAT testing and System Acceptance by DoT

4. Availability of relevant key staff from DoT, Producers/Agents for training



Page 43 of 44

SCHEDULE – IV: Payments Schedule

The payment schedules for the implementation of IT application development and revamping of the website are as follows:

50% of Total Cost of Design, Development, Implementation and Maintenance of Revenue Management System for DoT (as quoted at serial no. 1 of Annexure X of Vol II) would have been paid out to SI the time of Go-Live, based on the milestones achieved and balance payment of 50% will be paid out in equal parts over the rest of the 5(five) years based on the achievements of milestones/ quality of services provided by System Integrator.

S. No. Payments % of Total Fee Payment Not Before

A. Implementation Phase

1. SRS Document sign-off 10% T+6

2. Setting up of cloud platform for application hosting 15% T+20

3. Revenue Management System Go-Live 25% T+36

B. Operations & Maintenance Phase

1. Twenty quarterly instalments over Five years from the “Go-Live” date, each instalment being a maximum of 2.5% of total contract value depending upon the quarterly performance level assessed on the basis of SLAs defined in this RFP.

50% Quarterly

However, the above framework is indicative and would be finalized mutually between DoT and the successful bidder.



Page 44 of 44

ANNEXURE – A: Bid Response of the System Integrator

Date post:	14-Mar-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times