Request for Proposal

For Selection of an IT Solution Provider for

Web Based Application for
MG NREGS Module Based Process Automation through
end-to-end Web Solution
RFP Identification No. RDP/04/C.Cell-2013
Last Date of Bid Submission: 6th February 2013

(Tendering through e-Procurement Portal of Government of

Karnataka)

Abbreviations and Terminology Used

Abbreviation

Description

GoK
MG NREGS, RDPR Dept

Government of Karnataka
Mahatma Gandhi National Rural
Employment Guarantee Scheme,
Department of Rural Development &
Panchayat Raj, Govt of Karnataka
Finance Department, Government of
Karnataka
National Rural Employment Guarantee
National Informatics Centre
Human Resource Management System
E-Procurement Portal of Government of
Karnataka
Request for Proposal

FD
NREG
NIC
HRMS
E-Procurement
RFP

Section 1: Preface
1.1 Executive Summary
The purpose of this Request for Proposal (RFP) is to select an IT Solution Provider for MG NREGS
Module Based Process Automation through end-to-end Web Solution:

A well functional end-to-end Web based Software Solution will achieve

(a) Household & wage seeker friendly registration for Job Card Anywhere, anytime On-line
application (in addition to regular application method)
(b) Monitoring of Planning, follow up, tracking and ensuring that planning process gets completed in a
time-bound manner.
(c) Work selection as per Guidelines, better execution, monitoring & transparency
(d) The work estimation would be automated and standardized. This one aspect itself will reduce a lot of
bottlenecks and wrong implementations in the field.
(e) The estimate preparation as well as the measurement of executed works will be automated through
GPS enabled devices. This will lead to date&time as well as geo-stamped measurements for each work.
The duplication and false measurements will reduce substantially.
(f) The manual measurements will be replaced by e-MB (electronic Measurement Book) and the same
will be linked with the estimates of the work. The billing and accounts will also be linked to this e-MB.
So not only the need for manual calculations be obviated, a lot of time and drudgery will be saved
(g) Prompt payment for works in transparent fashion would happen and fraudulent payments will come
down substantially due to billing automation as stated above (e-FMS is independently being rolled out
which will deliver payments electronically into accounts of Job Card holders)
(h) HRMS computerization will enable proper management of manpower as well as increased
accountability, performance review/monitoring etc.
(i) All work site time&date plus geo-stamped photos will be part of bill preparation itself.
(j) The accounts, billing and finances will be computerized. A transparent system of accounting will
emerge, and, audit, reconciliation, and utilization will be available on-line.
(k) Reporting, Analysis, Dynamic Queries, Analytics for evaluation, monitoring and corrective action.

S.No.
Milestone
Date
1.
Publication of RFP document 7-01-2013
Bidders are advised to study this document carefully. SubMG NREGS, RDPR Dept of RFP shall be
or Tender Publication
deemed to have been done after careful study and examination of this document with full understanding
2.
Last date of submission of 19-01-2013
of its implications. The RFP document must be read in it its entirety including annexures.
queries
1.2
Schedule
for
Bid
Process
Management21-01-2013
3.
Pre-Bid Conference
The
will follow
in the table below, however the
4. MG NREGS, RDPR Dept Last
date to the
bid bid schedule given
06-02-2013
department
reserves
the
right
to
change
the
schedule
at
any
moment.
The changes in schedule will be
5.
Opening of Technical Bids 08-02-2013
notified
through
e-Procurement
Portal
of
Government
of
Karnataka.
6.
Pre-qualification and
11-02-2013 (10AM onwards)
Technical Evaluation of Bids
6.
Opening of Financial Bids 15-02-2013
(for technically qualified
Contact Address for Communication
Regarding Bid
bidders only)
7.
Award of Contract
As per finalization
Any queries/doubts/questions regarding the bid shall be addressed to

MG NREGS, RDPR Dept Department of Rural Development and

Panchayat Raj, 2nd Floor, 3rd Gate, M S Building Bangalore - 560001
1.3
About
Karnataka
Email:
nregs-ka@nic.in
Phone: 080-22342162
Karnataka is a state in south west India. It is bordered by the Arabian Sea to the west, Goa to the
northwest, Maharashtra to the north, Andhra Pradesh to the east, Tamil Nadu to the southeast, and
Kerala to the southwest. The state covers an area of 191,976 square kilometres (74,122 sq mi), or 5.83%
of the total geographical area of India. It is the eighth largest Indian state by area, the ninth largest by
population and comprises of 30 districts. More information about Karnataka can be found at
http://en.wikipedia.org/wiki/Karnataka
Information about Government of Karnataka can be found at
http://www.karunadu.gov.in/Pages/Default.aspx

1.4 MG NREGS:
Introduction:
Mahatma Gandhi National Rural Employment Guarantee Scheme (MG NREGS) is implemented as a
Centrally sponsored scheme under the aegis of Ministry of Rural Development (MoRD), Govt of India,
for operationalization of the mandate of National Rural Employment Guarantee Act, 2005 an act
which guarantees minimum 100 days of unskilled wage employment to rural households across the
country.
Salient Features of the Scheme:

MG NREGS has the following salient features

1. Each Rural Household which registers with a local gram panchayat is issued a Job Card within a
period of 15 days of filing of an application seeking such a Job Card the only thing verified is that
the household seeking the Job Card are ordinarily resident in the said Gram Panchayat and are adult
memebers.
2. Based on the issued Job Card the concerned household becomes entitled to guaranteed unskilled wage
employment for at least 100 days in a year. This guarantee for 100 days is for each household with all
the members of the said household taken together. For better tracking of employment availed by each
Job Card holding family the unskilled wage employment is given against a written demand and
accounts are kept of the employment availed against each Job Card.
3. Accordingly, each Job Card is uniquely numbered and details of all the members of the family to
which the card is issued are captured in the Job Card together with photographs.
4. In case unskilled employment is sought by any member of a family holding a Job Card, and, the same
is not made available to the seeker of employment within a period of 15days from date of application;
such a seeker of employment becomes entitled to Unemployment Allowance which shall be paid to
him by Programme Officer of MG NREGS.
5. The aim of the scheme is to give sustainable employment with asset generation accordingly, a
minimum 60% of funds must be spent on unskilled wage payment portion. The unit to calculate whether
minimum 60% funds have been spent on unskilled wage payment is Gram Panchayat, Taluk level and
District level depending on the operational area of an Implementing Agency.
6. There are no financial targets nor specific budget in MG NREGS, however, labour demand is used to
assess the requirement of funds for a specific Gram Panchayat, Taluk and District. The same is summed
up to assess the likely labour demand for the whole State.
The labour demand is assessed using the formula = [No of Job Cards] X 100. This forms the upper limit
of labour demand for an area, and, then depending upon the practical demand actually generated
previous year a more practical assessment is arrived at for a given area. The same is summed up for all
Gram Panchayats, and, a practical demand for whole district is worked out. The same is used to arrive at
a practical figure for labour demand for the whole State.
7. Central Government gives 90% of the funds while State Government gives rest of 10% funds as State
share.
8. As giving gainful unskilled employment is central to MG NREGS, therefore, MoRD, GoI, has
prescribed 16 broad category of works which can be executed/taken up under MG NREGS. The works
not covered by these 16 category of works cannot be taken up under MG NREGS.
9. The Central Govt has issued detailed guidelines for implementation of the Scheme, and, the same is
termed as MG NREGS. The States have been asked to evolve their own detailed Schemes within the
broad parameters of MG NREGS.
10. MG NREGS prescribes that not more than 6% of the scheme funds could be utilized for meeting
administrative expenses related with implementation of the scheme.

Implementation Details of MG NREGS:

While full details are in the Guidelines of MG NREGS; broadly, there are following processes
1. Registration for Job Card & Labour Demand
a. The start point of MG NREGS process is with a Rural Household apply for registration to Gram
Panchayat
b. A family and it adult members who are ordinarily resident of a Gram Panchayat (at the time of
registration) can register themselves in the said Gram Panchayat as a Household
c. Gram Panchayat upon verification (within 15 days) of (i) local residence (ii) family (iii) Adult
(>18years age), will be registered with a unique registration number.
d. GP will issue Job Card to each such registered Household.
e. As each Job Card is entitled to 100 days of unskilled employment; therefore, the number of Job Cards
are the upper limit on Labour Demand in a Gram Panchayat. The actual Labour Demand projections for
a Gram Panchayat will be based on previous years experience, and, other conditions in labour market
(including wage rate, drought conditions etc).
2. Planning
a. MG NREGS implementation process starts with the planning process wherein starting from the
grassroots level of village/grama sabhas people sit down in Grama Sabha, and, themselves identify the
works they wish to be taken up in their area. The works list is prepared and approved by this Grama
Sabha which is essentially comprises of all adults of a village/panchayat.
b. The works shall belong to the 16 permitted categories of works.
c. The work-lists prepared by Grama Sabha are perused and prioritized by Gram Panchayat. However,
Gram Panchayat cannot delete the works from the list of Grama Sabha even in case of ineligible
project it can only suggest for inclusion of an alternate work.
d. The work lists prioritized by Gram Panchayats are, then, examined and, approved by Taluk Panchayat
Samitis. The TPS can add such works to the list of these works which run across multiple Gram
Panchayats or are inter-Gram Panchayat
e. Similarly, after approval by Taluk Pachayat Samitis, the Zilla Panchayat approves the work list. The
idea is that works are examined from admissibility point of view (16 category of works and maintenance
of 60:40 ratio) however, even inadmissible works can also be only sought to replaced by another
admissible work. Zilla Panchayat can include inter-Taluk works as well as works of Line Department
which are inter-taluk works. However, the approval of Grama Sabha for all works is mandatory.
f. Once approved by Zilla Panchayat the prioritized work list becomes Annual Action Plan for the
district. It is to be noted that Annual Action Plan contains prioritized list of works which would be taken
up in the next financial year. The Grama Sabhas would have suggested long list of works, and, the same
is expected to exceed the practical Labour Demand of an area, therefore, prioritized list of proposed
work enable picking the top priority works such that the Annual Action Plan conforms with practical
Labour

Demand of an area (Gram Panchayat). Therefore, the prioritization role of Gram Panchayat, Taluk
Panchayat and Zilla Panchayat plays critical role in creating the Annual Action Plan.
g. The works which do not find mention in the Annual Action Plan (limited due to practical Labour
Demand) but were part of list prepared by Gram Sabha will become part of Shelf of Projects. The
works will be picked from Shelf of Projects in case Labour Demand of an area goes beyond the
originally conceived Annual Action Plan.
h. The planning process for a given Financial Year starts on 15 th August of the preceding year, and, the
district Annual Action Plan and the district Shelf of Projects for a Financial Year shall be in place before
1st December of preceding year
i. The district Annual Action Plans shall be consolidated at the State level and sent to MoRD, GoI, as
Annual Action Plan for whole State based on which the funds are ear-marked for each State. The same
are covered in Budget of the Central Government.
3. Estimate Preparation for Works
As soon as the Grama Panchayat prioritizes the works as proposed by Grama Sabhas, the relevant
technical personnel shall make detailed technical estimates of the works as per priority of the Gram
Panchayat. In this regard technical estimates shall be prepared for at least such number of works (as per
prioritized list prepared by Gram Panchayat) which will meet the Labour Demand of Gram Panchayat.
The prepared technical estimates shall be technically approved by relevant technical authorities.
By 31st December when Annual Action Plan of the district is ready, the full and duly approved technical
estimates shall also be ready. In fact, this should be completed by 31 st October itself in order to
facilitate correct Annual Action Plan preparation at both Taluk and district levels.
In any case, Annual Action Plan a given financial year for a district (along with the technical estimates
of the works that are included in the said plan) shall be ready and finalized by 31 st December of the
preceding year. The details in this regard are as stated in the Planning process stated above.
4. Works Management, Execution & Payment
a. There is category of permissible works and also of impermissible works. Annual Action Plan and
Shelf of Projects shall consist of only the permissible works.
b. Unskilled Wage & Material cost ratio of 60:40 shall be maintained at GP level as a unit (for line
department this could be at Taluk or District level as a Unit)
c. In case at least 10 Job Card holders approach a GP for assigning works, and, no work is on-going to
which they can be assigned; then GP shall initiate a fresh work from among list of works in Shelf of
Projects (Annual Action Plan of GP).
d. e-Muster Roll shall be issued under signatures of Programme Officer (EO TPS) for the labourers and
the e-NMR has a specific number and validity for 15 days.

e. Executed works in field shall be measured by Technical Personnel each week and wages shall be paid
and bills paid as well.
f. Payments are being issued to the labourers through account payee cheques, and through e-FMS Pay
Order (electronic fund transfer) in 7 districts in the state. The whole State will migrate to e-FMS
payment mode in next two to three months.
5. Social Audit, Civil Society, Quality Monitoring, 3 rd Party Inspections
A gamut of agencies and activities are envisaged which both concurrently, and, post facto do evaluation
and independent monitoring of execution of works under MGNREGS. The aim is also to bring
transparency, accountability and peoples participation in management of MG NREGS.
6. Ombudsman System & Complaints Management
MG NREGS has built-up and is further strengthening the system of enquiries into specific allegations,
complaints. This is a complementary system to point no 5, and, specific powers are now conferred on
Ombudsmen (who are senior, experienced, well-meaning citizens with relevant background) to impose
penalties and also order recoveries and initiate disciplinary action for lapses.
7. Human Resource Management & Administrative Expenses
Each year about Rs70-90Crores are spent for administrative expenses out of which about Rs30Crores
are for payment to personnel alone. This cost is going to increase with substantial addition of manpower
as is envisaged at present. A proper planning and monitoring of this is necessary.
8. MIS (Management Information System)
An elaborate MIS has been developed for reporting on MG NREGS by NIC. It is a web based
application which is hosted in New Delhi on a central Server. A lot of static information on MG NREGS
is available on MIS which is regularly updated from the field (nrega.nic.in/MISreport.htm). This site
caters to need of the whole country.
The above points are major processes/aspects of MG NREGS. A more detailed write-up in the form of
Operational Guidelines, 2012 is attached herewith for further understanding in Annexure-B.
MGNREGS, RDPR Dept, is also setting up a call center to
a. Guide citizens about the MG NREGS. For example details of scheme, programs, entitlements,
benefits etc.
b. Guide citizens about the various touch points of the MG NREGS, RDPR Dept to avail a service
including modalities or procedures for accessing such entitlements/benefits

c. Registration for Job Card

i. The request from Citizens for issuance of new Job Card or inclusion of name in an existing Job Card
will be accepted over phone. The details captured in the appropriate software provided by MG NREGS,
and, sent to appropriate quarters through this Software.
ii. The MG NREGS provided software or the appropriate software solution will hand-hold the Call
Centre personnel in doing this.
iii. Guide the citizens to apply for Job Card on-line through web.
d. Demand for Unskilled Employment (Labour Demand)
i. Any family with a Job Card can demand unskilled employment from a local Gram Panchayat by
submitting application in Form-6
ii. The Call Centre shall accept the applications over phone demanding unskilled employment from Job
Card Holders. The demand shall be logged into MG NREGS software solution or appropriate software
solution, and, escalated to proper office through the software.
iii. The MG NREGS software or the appropriate software solution will hand-hold the Call Centre
personnel in doing this.
iv. Guide the citizens to apply for unskilled employment on-line through web.

e. Complaints & Grievances

i. Any MG NREGS, RDPR DEPT related complaint filing and follow-up through Call Centre
ii. The MG NREGS software or the appropriate software solution will hand-hold the Call Centre
personnel in doing this.
iii. Guide the citizens to register complaints/grievances on-line through web.
iv. Any other MG NREGS Activity
v. General Enquiries
vi. Enable self-help IVR to read out the status of the application.
vii. Daily/weekly/monthly MIS, as and when required in prescribed format

Section 2: Instruction to Bidders

2.1 Introduction
At present there is an IT system / MIS solution has been developed by National Informatics Centre
[NIC] (NREGASoft) for MG NREGS, RDPR Dept and is available at www.nrega.nic.in. Any webbased solution developed for MG NREGS shall fully integrate with the existing solution/solutions based
on laid down standards of Ministry of Information Technology, Dept of Information Technologys egovernance standards. The Software Solution being developed in this RFP shall be in complete
complimentarity with NregaSoft of NIC, New Delhi.

2.2 Corrupt Practices

MG NREGS, RDPR DEPT requires bidders to observe the highest standard of ethics during the
procurement and execution of such contracts.
a) The following definitions apply:
Corrupt practice means the offering, giving receiving, or soliciting, directly or indirectly, of any
thing of value to influence the action of any party in the procurement process or the execution of a
contract;
Fraudulent practice means a misrepresentation or mission of facts in order to influence a
procurement process or the execution of a contract;
collusive practices means a scheme or arrangement between two or more bidders, with or without
the knowledge of the Department, designed to influence the action of any party in a procurement process
or the execution of contract
coercive practices means harming or threatening to harm, directly or indirectly, persons, or their
property to influence their participation in a procurement process, or affect the execution of a contract;
b) Department will reject a proposal for the award of Contract if it determines that the bidder
recommended for award has, directly or through an agent, engaged in corrupt, fraudulent, collusive, or
coercive practices in competing for the Contract

Any communication between the bidder and the MG NREGS, RDPR DEPT related to matters of
alleged fraud or corruption must be made in writing.
By signing the contract, the bidder shall represent that it is either the owner of the Intellectual Property
Rights (IPR) in the hardware, software or materials offered, or that it has proper authorization and/or
license to offer them from the owner of such rights. For the purpose of this clause, IPR shall be defined
in the Section 8 of this bid document. Wilful misrepresentation of these facts shall be considered a
fraudulent practice

2.3 Eligible Bidders

2.3.1 Pre-Qualification Criteria (minimum technical requirements) (see Annexure-L)
1. The bidder shall be in IT business and worked for a Government Department or a Govt Public Sector
Undertaking in the last three years (as on 01.01.2013) [LoI/Work order/Completion Certificates]
2. The bidder must have implemented in last the six years at least three web-based software solutions
either for Government of Karnataka/Government of India/other state governments or for Govt
Boards/Govt PSUs/Govt Corporations as on 01.01.2013
3. The bidder shall have executed or executing to the satisfaction of government department or
PSU/Board one IT works of value not less than 10 Crore rupees
Or
Shall have executed/executing to the satisfaction of department two IT works of not less than 5 Crores
Rupees each
Or
Shall have executed/executing to the satisfaction of department three IT works of not less than 3 Crore
Ruppees each
4. The bidder shall not have been blacklisted by Government of Karnataka/Government of India/other
state governments and their PSUs/Boards/Corporations.
Note: Consortium bidding is NOT permitted, and, subject to eligibility criteria stated above, more than
one legal entity cannot together or jointly bid for this tender.
Eligibility will be as per the qualification criteria defined above.
Bidder shall not have a conflict of interest with objectives of this Bid and this RFP. Participation by
Bidder(s) having a conflict of interest will result in the disqualification of all the Bids. MG NREGS,
RDPR DEPT considers a conflict of interest to be a situation in which a party has interests that have a
potential or are likely to adversely influence that partys performance of assigned duties or
responsibilities, contractual obligations, or compliance with applicable laws and regulations, and that
such conflict of interest may contribute to or constitute a prohibited corrupt practice. A Bidder may be
considered to be having a conflict of interest in this bidding process if, including but not limited to, the
bidder:
(a) acts directly or indirectly in collusion with any of other bidders or parties; or
(b) have the same legal representative for purposes of this Bid; or
(c) have a relationship with each other and uses it to have access to information about or influence on the
Bid of another Bidder, or influence the decisions of the Department regarding this bidding process
(d) a Bidder bids more than one bid in this tender (here a bidder means a single legal entity).
Participation by a Bidder in more than one Bid will result in the disqualification of all Bids in which it is
involved. However, this does not limit the inclusion of the same product (commercially available
hardware, software or network product manufactured or produced by the firm), as well as purely
incidental services such as installation, configuration, routine training and ongoing maintenance/support,
in more than one bid; or

(e) a Bidder or any of its sub-contractors participated as a consultant in the preparation of the design or
technical specifications of the Bid and services that are the subject of the bid.

2.4 Eligible Goods and Related Services

For the purpose of this Clause, the term Goods includes hardware, software, networking equipments
and cables; and Related services includes services such as insurance, transportation, associated
documentation, installation, customization, integration, field survey, testing and comMG NREGS,
RDPR Depting, training, technical support, maintenance, repair and other necessary services to be
provided by the selected bidder and necessary for successful implementation of the project as specified
in the contract.

2.5 Language of Bid

The Bid, as well as all correspondence and documents relating to the Bid exchanged by the Bidder and
MG NREGS, RDPR DEPT, shall be written in the English. Supporting documents and printed literature
that are part of the Bid may be in another language provided they are accompanied by an accurate
translation of the relevant passages in English.

2.6 Cost of Bidding

All costs and expenses incurred by the Bidder in any way associated with this Bid will be borne entirely
and exclusively by the Bidder regardless of the conduct or outcome of Bid.

Bid Prices
1. The Bidder shall indicate price in the prescribed format (Annexure-I) for all items it proposes to provide
under the Contract. Prices should be shown separately for each item as detailed in Tender Documents. The
price components furnished by the Bidder in accordance with format below will be solely for the purpose of
facilitating the comparison of bids by MG NREGS, RDPR Dept and will not in any way limit the MG NREGS,
RDPR Depts right to contract on any of the terms offered.
2. Prices quoted in the bid must be firm and final and shall not be subject to any upward modifications, on
any account whatsoever. However, the MG NREGS, RDPR Dept reserves the right to negotiate the prices
quoted in the bid to effect downward modification.
3. The Contract price shall be the only payment, payable by MG NREGS, RDPR Dept, to the successful
bidder for completion of the contractual obligations by the successful bidder under the Contract, subject to
the terms of payment specified in the contract. The price would be inclusive of all applicable taxes, duties,
charges and levies, unless specified otherwise.
4. The prices, once offered, must remain fixed and must not be subject to escalation for any reason
whatsoever within the period of contract. A proposal submitted with an adjustable price quotation or
conditional proposal may be rejected as non-responsive.
5. Prices in any form or by any reason before opening the Commercial Bid should not be revealed by the
bidder or their representatives, failing which the offer shall be liable to be rejected.

2.7 Currency of Bid

The currency of bid will be Indian Rupees.

2.8 Amendments to RFP

At any time prior to the deadline for mission of the Bids , MG NREGS, RDPR DEPT can amend the bid
by issuing a corrigendum. Such corrigendum will be available on the e-Procurement site of the
Government of Karnataka.
MG NREGS, RDPR DEPT, at its discretion for any reason whether at its own initiative may add, modify
or remove any element of the Goods (including hardware, software etc) or any component of Related
Service entirely or any part thereof from the bid document till the time of award of contract.

2.9 Right to reject any bid or all bids

MG NREGS, RDPR DEPT reserves the right to accept or reject any Bid, and to annul the bidding
process and reject all Bids at any time prior to Contract award, without thereby incurring any liability to
the Bidders

2.10 Information in RFP

The RFP contains statements derived from information that is believed to be true and but does not
purport to provide all information that may be necessary or desirable, to enable an intending contracting
party to determine, whether or not to enter into a contract with respect of this RFP.

2.11 Local Conditions

It will be imperative on each bidder to fully inform himself of all local conditions and factors which may
have any effect on the execution of the works. MG NREGS, RDPR DEPT will not entertain any request
for clarifications from the bidders, regarding such local conditions. It must be understood and agreed
that such factors have properly been investigated and considered while submitting the proposals. No
kind of financial or any adjustments will be made once the bids are submitted.

2.12 Sections of Bidding Document

The Instruction to Bidders issued by the Department is a part of the Bidding Document. All the sections
mentioned in Section : Preface are part of bidding document.

2.13 Period of Validity of Bids

Bids shall remain valid for the period of 120 days after the bid submission date. This can be extended by
mutual acceptance for a period of 60 days after intial period of 120 days

2.14 Bid Security

The Bidder shall furnish a Bid Security in the amount and currency specified in the bid document.

2.15 Submission Process and Deadlines

The Bidding Process will be conducted through E-procurement Portal of Government of Karnataka
(eproc.karnataka.gov.in). Entire process including Tender Fee, EMD Payment, Technical and Financial
Bid Submission are handled by the e-Procurement Portal of Government of Karnataka. All
communications regarding Pre-Bid, dates and timing will be done through e-Procurement Portal of GoK.
The details about participation process through Government of Karnataka e-Procurement Portal can be
found on eproc.karnataka.gov.in

2.16 EARNEST MONEY DEPOSIT (BID GUARANTEE)

The bidders shall furnish EMD for an amount of Rs. 400,000/- ( Rs. Four Lakhs Only) through any of
the four e-payment modes mentioned in the e-procurement Portal.
The bid guarantee may be forfeited:
a. If a Bidder withdraws / modifies its bid during the period of bid validity specified by the Bidder on
the Bid Form; or
b. In case of a successful Bidder, if the Bidder fails to sign the Contract; or

c. In case of a successful Bidder, if the Bidder fails to furnish the Security Deposit/Performance
Guarantee.
2.16.1 E-payment modes for Tender Processing Fee & Earnest Money Deposit.
The supplier/contractor shall pay the Earnest Money Deposit (EMD) & Tender Fee in the eProcurement portal using any of the following payment modes:
Credit Card
Direct Debit
National Electronic Fund Transfer (NEFT)
Over the Counter (OTC)
i. CREDIT CARD PAYMENT METHOD:
To pay the registration fee through your credit card, click on the Credit Card (Online
Payment) option. If you choose to pay the fees later click on Close button. Click Pay after
verifying details on the screen that appears.
Click on Pay button to proceed with payment process. Click Back if you wish to
Choose a different payment method. Click on OK button on the payment method
Confirmation window that is displayed. You will choose your card type (VISA, master Card).
You enter your credit card details.
Card Details completely filled.

 The screen will look like it is shown above when you have completely filled the card details.
Click on PAY NOW button to effect the payment. Your card details are verified by the
payment gateway service and you will receive confirmation of payment debited to your card
account if the card is valid. If the card is not valid you will receive alert about it and system will
wait for you to correct any errors in the card details provided by you.
A successful transaction message is displayed.
ii. DIRECT DEBIT METHOD:
Click on Direct Debit Using Internet Banking (Online Payment) option to pay from your bank
account through Internet Banking facility.
Click on Pay to proceed or Back to change the payment method on the Payment details
screen.
Click on OK on the confirmation window to effect the payment. Click on Cancel and then on
Back to change the payment method. You will get information on your screen about successful
completion of payment process.
iii. OTC PAYMENT PROCEDURE:
If a contractor/supplier chooses to make payment of EMD/tender processing fees Over The
Counter (OTC) in any of the designated Axis Bank branches listed in the e-Procurement web-site
(https://www.eproc.karnataka.gov.in) the contractor/supplier will need to log into e-Procurement
system, access the tender for which bid is being created and then select the OTC option under the
payment section and print the Challan shown in that section. The printed challan will have the
unique bid reference number and the amount to be remitted. Along with the challan, contractor
can choose to make the payment either in the form of cash or

in the form of Demand Draft. Cheque payments will not be accepted. The contractor is requested
to specifically inform the bank officer to input the unique bid reference number printed in the
challan in the banking software. Upon successful receipt of the payment, the bank will provide a
16-digit reference number acknowledging the receipt of payment. This 16-digit reference number
has to be inputted by contractor in the payment section of its bid as payment confirmation before
the bid is submitted (i.e.) as a pre-requisite for bid subMG NREGS, RDPR Dept.
iv. NEFT PAYMENT PROCEDURE:
If a contractor/supplier chooses to make payment of EMD/tender processing fees using Reserve
Bank of India's (RBI) National Electronic Fund Transfer (NEFT) system, the contractor/supplier
will need to log into e-Procurement system, access the tender for which bid is being created and
then select the NEFT option under the payment section and print the Challan shown in that
section. The printed challan will have the unique bid reference number, account details of
Government of Karnataka and the amount to be remitted. The contractor has to submit the
printed challan to its bank-branch (NEFT-enabled) and request for an account-to-account
transfer, wherein the money will get transferred from the contractors' bank account to GoK's
bank account. The contractor shall ensure that NEFT transfer instructions are executed and the
funds are wired to the Government of Karnataka's principal account before the last date for bid
subMG NREGS, RDPR Dept and preferably 24 hours before the last date for bid subMG NREGS,
RDPR Dept. If the contractor's bank transfers/wires the money after the last date for bid subMG
NREGS, RDPR Dept, the contractor's bid will be liable for rejection. Upon executing the transfer,
the contractor's bank will provide a reference number generated by NEFT software as
confirmation of transfer, which has to be inputted by contractor in the payment section of its bid
as payment confirmation before the bid is submitted (i.e.) as a pre-requisite for bid subMG
NREGS, RDPR Dept. Also, the account number from which the funds were transferred have to be
inputted in the e-Procurement system as part of its bid.
The supplier/contractors bid will be evaluated only on confirmation of receipt of the payment
(EMD) in the Government of Karnataka central pooling a/c held at Axis Bank.
For details on e-Payment services refer to e-procurement portal for more details on the process.

Note: In e-Procurement Portal Contractor has the option of withdrawing the Bid by digitally signing
to withdraw/cancel bid before the bid subMG NREGS, RDPR Dept time /Date.
Earnest Money Deposit paid by the unsuccessful Bidders will be returned as soon as possible after the
tender has been finalised.
Earnest Money Deposit of the successful Bidder will be refunded after fulfilment of the security Deposit
and Performance Guarantee Clause.
The deposit towards EMD shall not carry any interest.

2.17 Bidder Queries and MG NREGS, RDPR DEPT Responses

All enquiries from the bidders relating to this RFP must be submitted through e-procurement portal of
Government of Karnataka.
The answers to the enquiries will be posted on the E-Procurement portal of Government of Karnataka.
Pre-Bid queries will be accepted up to two business days prior of Pre-Bid date.

2.18 Errors and OMG NREGS, RDPR Depts

Bidders shall notify the department of any error, fault, oMG NREGS, RDPR Dept, or discrepancy found
in this RFP document but not later than three business days prior to the bid SubMG NREGS, RDPR
Dept due date.

2.19 Pre-Bid Conference

The Department will host a Pre-Bid Conference, at date, time and venue mentioned in the EProcurement Portal of Government of Karnataka. Any change in the date, time and venue of the Pre-Bid
will be intimated through e-Procurement Portal of Government of Karnataka. (eproc.karnataka.gov.in)

2.20 Bid Proposal

Bid Proposals must be direct, concise, and complete. The Tender Scrutiny Committee will evaluate the
bidders proposal based on its clarity and the directness of its response to the requirements of the project
as outlined in this RFP

2.21 Technical Proposal (See Annexure-L and fill up)

The technical proposal shall contain a detailed description of how the bidder will provide the required
services outlined in this RFP. It shall articulate in detail, as to how the bidders Technical Solution meets
the requirements specified in the RFP. Technical proposal shall clearly show the preparedness of the
bidder to meet the quality as well as timely delivery requirements. In case bidder wants to submit
additional information, they shall mark it as supplemental and write on top beyond the scope of work.
Technical proposal shall be structured as per the scope of work mentioned in this bidding document and
technical evaluation criteria mentioned in Annexure D and shall address following at the minimum.
2.21.1 Previous Experience

 Experience in development/deployment of of various IT and eGovernance Solutions to various

government departments/organizations/PSUs.
Experience in providing a Bidder role covering hardware, Software, data centre etc.
(The documentary proof of above as scanned copy document must be submitted along with bid).
2.21.2 Technical solution as per requirements of RFP
(please, see Section 4 Scope of Work)
The Data Centre requirements and Deployment Architecture, Server Application and Hardware
proposed by the bidder. (Application will be hosted at State Data Centre and Disaster Recovery Centre
will be provided by e-Governance Department in due course)
The Application Software proposed by the bidder (Reporting Engine, Dashboards, Drill Downs,
Analytics, Grievance Management System etc).
Hardware Infrastructure for data centre hosting proposed by the bidder. MG NREGS, RDPR DEPT
will provide the data centre of e-governance department of Government of Karnataka
System Software proposed by the bidder.
Security Architecture proposed by the bidder
Proof of Concept Demonstration Proof of Concept demonstration shall be as per the Functional
Requirements Specifications (FRS) attached in the scope of work and as explained in Annexure-J. The
basic aim of proof of concept demonstration is to evaluate the bidder understanding of the work and his
ability to execute the work under given timelimits.
2.21.3 Project Management Methodology
Approach & Methodology planned for adoption for successful execution of the project.
Project Plan. (Shall cover Customization/Development)
Risk Management Plan
Training Plan.
The selection of the technical proposal during technical evaluation would under no circumstances imply
the acceptance of the technical proposal. Acceptance of the technical proposal would be subject to its
complete adherence to the technical requirements as specified in the RFP including load and
performance testing requirements.

2.22 Financial Proposal (Annexure-I)

Prices in bid shall be quoted only in Indian Rupees. Financial bids must be submitted in the format
Annexure-I and uploaded in e-procurement portal.
The bidders shall mandatorily quote for all the items for IT Implementation, including any items
which are not identified in the formats provided for the successful implementation of the project and
subsequent operations & maintenance inline with SLA.
Cost quoted for software solution shall be total and inclusive of all the cost (see Annexure-I)
components including the maintenance and project management for 1 year after go live.

 Annual Maintenance and Project Management for 2 nd and 3rd year shall be quoted separately.
Cost quoted for hardware shall include the cost of installation, configuration and maintenance for 3
years.

2.23 Deviation
The bidder shall provide deviations and exclusions in the Format for Deviation Statement Annexure F.
Bids having deviation or exclusions unacceptable to Department will be rejected irrespective of outcome
of technical evaluation.

2.24 Total Responsibility

Bidder shall take total responsibility of the defect free operation of eGovernance Solution for MG
NREGS, RDPR DEPT for three years after GO-LIVE without any conditions. An undertaking to this
effect shall be submitted as part of this bid.

2.25 Bid Submission

Bids submissions shall be as per the e-Procurement portal of Government of Karnataka.

2.26 Late Bids

Bids received after due date and time will be rejected

2.27 Opening of Bids

MG NREGS, RDPR DEPT will open the Technical Proposals in the presence of Bidders representatives
who choose to attend, at the address, date and time specified in the e-Procurement Portal of Government
of Karnataka.
After the evaluation of the Technical Proposals which will include Technical Presentation and Proof of
Concept Demonstration, MG NREGS, RDPR DEPT will invite bidders who have submitted
substantially responsive Technical Proposals to attend the opening of the Price Proposals. The date, time,
and location of the opening of Price Proposals will be advised by MG NREGS, RDPR DEPT through eProcurement Portal of Government of Karnataka.

2.28 Interpretation of Bid in case of Arithmetic Errors

In case of discrepancy between the amounts mentioned in figures and in words, the amount in words
will prevail.

2.29 Withdrawal of Proposals

No proposals can be withdrawn from the date of submission of bid until bid validity period.

2.30 Evaluation of Bid

The bids of bidders will be evaluated in two steps
1. Technical Evaluation (see Annexure D & L)
2. Financial Evaluation (see Annexure-I)

2.30.1 Technical Evaluation (Annexures D & L)

The technical evaluation will consist of

2.30.1.1 Proposal Evaluation

Proposal evaluation as per Technical evaluation criteria (Section 2.21 read with Annexure D read with
Annexure J).
The First Stage of Technical Evaluation is checking of the meeting of Pre-Qualification Conditions as
per Section 2.3

2.30.1.2 Proposal Presentations and Proof of Concept Demonstration

The Tender Scrutiny Committee-cum-Technical Expert Committee shall technically evaluate each of
the bidders at time, date and venue as determined by MG NREGS, RDPR DEPT as per sub-section 1.2
of Section 1 of this RFP. The technical presentation and other detailed technical evaluations as per
Annexure-D is the fundamental step in the technical evaluation process.
Bidders shall present and demonstrate their technical solution to the committee.
Technical Presentations also include Proof of Concept demonstration (Annexure-J). The total
presentation time for each bidder will be as determined by the Tender Scrutiny Committee and may
extend to field demonstration of the PoC and spread over more than few days.
The proof of concept demonstration (see Annesure-J) shall be as per the Functional Requirements
Specifications mentioned in this bid document (Annexure-C) read with Annexures A, B, J and Section 4
Scope of Work. The PoC shall show how the solution will deliver the FRS/Scope of Work. The
bidder shall demonstrate his PoC as per explanation given in Annexure-J.
Depending on the evaluation criteria mentioned in this document (Annexure-D and Annexure-J),
each Technical Bid will be assigned a technical score out of a maximum of 100 points, including the
marks allocated for Proof of Concept (PoC) (65 Marks Total Marks of PoC are 850 and the scored
marks will be scaled down to reflect makrs out of 65 Marks. The formula to be used in this regard
shall be
Let marks scored in PoC be H;
then marks in PoC scaled down to 65 = 65 X [H/Total Marks of PoC]
2.30.2 Financial Evaluation (See Annexure-I)
The technical bids of only those bidders who meet the minimum prescribed PQR (see paragraph 2.3.1
above) and score at least 65marks in the Tehnical Evaluation (see 2.30.1) will be declared
substantially Technically Responsive and their financial bids, thereupon, be opened (the bids of other
bidders shall be declared Technically Unresponsive and rejected)
2.30.3 Final Evaluation of Bids
The financial bids of Technically Responsive Bidders as per clause 2.30.2 shall be opened,
and, the bidder with the lowest financial bid will be declared L1 (Annexure-I). In case of two or
more bidders having identical financial bids then

the following method shall be adopted to declare the L1

(i) bidder with higher technical evaluation marks (see 2.30.1) shall be L1.
(ii) However, in case two or more bidders have identical technical as well as the financial
marks; then the L1 shall be decided by draw of lots.
Note: In case the final L1 bidder does not come forward for entering into contract due to any
reason then the work shall be retendered.

2.31 Award of Contract

MG NREGS, RDPR DEPT will consider to award the work only to the bidder who has been declared L1
as per paragraph 2.30.3 among all the technically qualified bidders.

2.32 Signing of Contract

Immediately after the notification of award of contract, the successful bidder shall enter into an
agreement with MG NREGS, RDPR DEPT. The Ageement shall be on a stamp paper of suitable value
as decided by MG NREGS, RDPR DEPT and in the form as decided by MG NREGS, RDPR Dept,
basically, covering Scope of Work and this RFP.

2.33 Performance Bank Guarantee

The successful bidder shall deposit with MG NREGS, RDPR DEPT, within fifteen (15) working days of
the date of award of the work an unconditional and irrevocable Performance Bank Guarantee (PBG)
from a scheduled Nationalised bank, in the format in Annexure E: Performance Bank Guarantee
(PBG), payable on demand, for the due performance and fulfilment of the contract by the bidder. Failure
to submit the PBG within the specified period by the bidder may be construed as non-acceptance of the
contract and failure to comply with the terms and conditions of the RFP, leading to the forfeiture of the
entire EMD amount.
This Performance Bank Guarantee will be for an amount equal to 10% of total contract value, which
shall be intimated by the MG NREGS, RDPR DEPT upon signing the contract. PBG shall be invoked by
MG NREGS, RDPR DEPT in the event Implementation Agency
(i) fails to meet the milestones provided for in the Time Schedule for Implementation and Operations
contained or any changes agreed between parties.
(ii) Fails to perform the responsibilities and obligations.
(iii) Misrepresentations of facts/information submitted to the department.
(iv) Otherwise, fails to discharge responsibilities as prescribed in the Agreement
The bank guarantee shall be valid for {Entire project period from the date of award of work plus three
months beyond the last date of validity of the project} (project period is three years from date of GoLive). In case project implementation/go-live is delayed performance bank guarantee shall be extended
for that period of time plus three months.
MG NREGS, RDPR DEPT will notify the Bidder in writing thirty days (30) days in advance about the
exercise of its right to invoke performance bank guarantee

In case PBG is not extended, or, made available as required, by the bidder, the MG NREGS, RDPR Dept
reserves right to deduct the requisite amount from any money of the Bidder with the MG NREGS,
RDPR Dept MG NREGS, RDPR Dept or any amount of any bill or bills due for payment to the Bidder,
until the entire amount of PBG is deducted. The MG NREGS, RDPR Dept, at its discretion, in case of
default to extend the period of PBG, reserves the right to terminate the contract at full cost and risk of
the bidder. This default or termination shall be treated as failure to meet the requirements of the contract
and the bidder shall be liable for blacklisting from any future tenders/works for a period of two years
from date of order of such a blacklisting. This blacklisting shall be in addition to any other legal
remedies available to MG NREGS, RDPR Dept.

2.34 Warranty and Maintenance

Bidder will provide complete maintenance and project management support for all full solution
including hardware (if any) as per this RFP for a period of three years after GO-LIVE period. (GO LIVE
+ 36months).
During the warranty period (if applicable to specified Goods and Services see Section 4), the
bidder shall warrant that the goods supplied under the contract are new, unused, of the latest release
version/ models at the time of delivery and incorporate all recent improvements in design and materials,
unless provided otherwise in the contract. The bidder shall further give warranty that the goods supplied
under this contract shall have no defects arising from design, materials or workmanship.
MG NREGS, RDPR DEPT shall promptly notify the successful bidder in writing of any claims
arising under this warranty. Upon receipt of such notice, the bidder shall, within the warranty period and
with all reasonable speed, repair or replace the defective systems, without costs to the and within the
time specified and acceptable to the MG NREGS, RDPR DEPT .
If the successful bidder, having been notified, fails to remedy the defect(s) within the period specified
in the contract, Department may proceed to take such reasonable remedial action as may be necessary, at
the successful bidders risk and expense and without prejudice to any other rights, which Department
may have against the bidder under the contract.
During the comprehensive warranty period and Annual Maintenance and Project Management
Contract period (see Section 4 Scope of Work), the successful bidder will provide all product(s) and
documentation updates, patches/ fixes, and version upgrades within 15 days and shall carry out
installation and make operational the same at no additional cost to MG NREGS, RDPR DEPT.
The successful bidder hereby warrants Department that:
The proposed Solution represents a complete integrated solution meeting all the requirements as
outlined in the RFP and further amendments if any, and provides the functionality and performance, as
per the terms and conditions specified in the contract.
The successful bidder will be responsible for all components of products included in the systems.
This information supplements information in scope of work regarding warranties

2.35 Failure to Agree with Terms and Conditions of RFP

Failure of the successful bidder to agree with the Terms & Conditions of the RFP shall constitute
sufficient grounds for the annulment of the award, in which event Department may award the contract
to the next best value bidder or call for new bid.
The bidder may be blacklisted for participation in tenders of Government of Karnataka.

2.36 Disclaimer
Subject to any law to the contrary, and to the maximum extent permitted by law, the procurement Entity
the department and its director, officers, employees, contractors, representatives, agents,and advisers
disclaim all liability from any loss, claim, expense (including, without limitation, any legal fees, costs,
charges, demands, actions, liabilities, expenses or disbursements incurred therein or incidental thereto)
or damage, (whether foreseeable or not) (Losses) suffered by any person acting on, or refraining from
acting because of any presumptions or information (whether oral or written and whether express or
implied), including forecasts, statements, estimates, or projections contained in this RFP document or
conduct ancillary to it whether or not the losses arise in connection with any ignorance, negligence,
inattention, casualness, disregard, oMG NREGS, RDPR Dept, default, lack of care, immature
information, falsification or misrepresentation on the part of the Procurement Entity, department or its
director, officers, employees, contractors, representatives, agents, or advisers

Section 3: Project Governance and Strategic Control

For the successful implementation of the Project as outlined in the scope of work it is
necessary to identify and delineate the roles of Governance and Implementation and
also ensure clarity of strategic control through the project implementation and beyond.
This will get adequate buy in from all the stakeholders.
3. 1 Governance Structure: In order to ensure smooth implementation of the
project, a project steering committee will be constituted. The project streering
committee will meet at least once in two weeks (initially on a weekly basis) to take
stock of the progress. The project steering committee will be responsible for the overall
implementation strategy ensuring adequate collaboration among stakeholders.
3.2 Project Management Unit and Implementation Structure: Project would be
implemented adopting the best professional practices so as to ensure attainment of
the project goals in a timebound manner. In this context project would require special
skills in project management, change management, technology, domain, etc. In order
to ensure that these specialists work on the project in a dedicated manner, a PMU will
be to be set up in MG NREGS, RDPR DEPT.

The PMU will be responsible for monitoring application development, pilot

implementation, quality check, roll out, version control, implementation progress,
training etc.

3.3 Strategic Control over Application

Persons of MG NREGS, RDPR DEPT, Government of Karnataka will be associated during all the
phases of the application. Solution Provider must obtain the sign-off of MG NREGS, RDPR Dept,
Government of Karnataka on the design and acceptance testing document.
3.3.1 Audit of Software Solution
MG NREGS, RDPR DEPT may constitute a committee or commission a third party or ask the Bid
Winner to have the certification (Security and Performance) from among relevant vendors empaneled by
e-Governance Dept, Govt of Karnataka or relevant vendors empaneled/approved by Dept of Information
Technology, Govt of India for/after Go-Live (Module Wise and Overall). All the changes desired by the
certification process shall be

implemented by bidder free of cost and within a deadline provided by MG NREGS, RDPR DEPT. The
audit shall be done, as per the decision of MG NREGS, RDPR Dept, concurrently for each Software
Module separately or more than one Modules taken together.
The Application System and the Source Code has to deposited with the MG NREGS, RDPR DEPT after
rollout, for any subsequent changes made to the software during maintenance period
3.4 Enhancements/Changes to the Application
1. Any subsequent change in the source code after 3 rd party audit needs to be deposited with MG
NREGS, RDPR Dept, Government of Karnataka with appropriate log and documents maintained with
each change.
2. Any changes to the application, required to enhance the functionality, or to improve performance or to
address the security gaps, shall first be hosted in an application staging environment, tested for
consistency, integrity and performance by the Application Administrator of the Bidder. MG NREGS,
RDPR Dept shall review the proposed change and accord their approval or reject the request. These
changes must accompany impact analysis document.
3. MG NREGS, RDPR DEPT may entrust the responsibility to designated administrators, who can
exercise the privilege of approval or rejection of the proposed change request.
4. No change to the application shall be effected by the Bidder unless the process defined at 1, 2, 3
above is gone through.
MG NREGS, RDPR DEPT may undertake comprehensive application audits at regular intervals through
a 3rd party to ensure application functionality and integrity .
The application software, source codes, libraries as well as binaries shall be version controlled using a
source code control management software.

3.5 Strategic Control over Database

MG NREGS, RDPR Dept, Government of Karnataka will exercise the strategic control over database
through the database tools like database software, schema and data browsing tools supplied by the
Bidder.
The entire database, including the table structures, schemas and master data are deposited with the
MG NREGS, RDPR DEPT.
3.5.1 Enhancements/Changes to the Database Schema
1. Any subsequent change in the database schema, procedures, triggers or any source code, binary,
library associated with database after 3rd party audit post rollout needs to be deposited with MG
NREGS, RDPR DEPT with appropriate log and documents maintained with each changes.
2. Any changes to the database schema, procedures, triggers or any source code, binary, library
associated with database, required to enhance the functionality, or to improve performance or to address
the security gaps, shall first be hosted in an application staging environment, tested for consistency,
integrity and performance by the Application Administrator of the Bidder. MG NREGS,

RDPR DEPT shall review the proposed change and accord their approval or reject the request. These
changes must accompany impact analysis document.
3. MG NREGS, RDPR DEPT may entrust the responsibility to designated administrators, who can
exercise the privilege of approval or rejection of the proposed change request.
4. No change to the application shall be effected by the Bidder unless the process defined at 1, 2, 3
above is gone through.
MG NREGS, RDPR Dept, Government of Karnataka may undertake comprehensive application audits
at its own convenience at regular intervals through a 3rd party to ensure database integrity .
The application software, source codes, libraries as well as binaries shall be version controlled using a
source code control management software.
3.5.2 Database Administrator Actions
1. Database Administrator role shall be separate from application user or any kind of user.
2. All Database Administrator Actions shall be automatically logged by the database server/audit log
tools.
3. MG NREGS, RDPR DEPT may do a 3rd party comprehensive audit of Database Administrator
Actions.
4. MG NREGS, RDPR DEPT appointed database administrator may oversee the actions of Bidder
Database Administrator by their physical presence.
5. User Administration shall not be part of database administration.
3.5.3 Encryption of Data
Confidential data in the database must be encrypted by the application and the data which must not
be modified shall be hashed and digitally signed by the application at the time of original data
population itself. This feature must be designed as part of Application Security.
The need to encrypt data must be clearly spelt out in System Requirement Specifications document.
Names of encrypted tables must be separately submitted to MG NREGS, RDPR DEPT.
This shall be in conformity with the standards and protocols laid down by Dept of Information
Technology, Govt of India.

3.6 Strategic Control over Application Security.

1. The entire application must be developed as per the security requirements mentioned in this RFP
document & e-Governance Standards as laid down by Dept of IT, Govt of India.
2. The core activities relating to security administration like assigning roles and privileges, configuration
management in relation to all the security assets shall be carried out only after the prior approval of MG
NREGS, RDPR Dept, Government of Karnataka.
3. MG NREGS, RDPR DEPT or its designated agency will have full access to all the logs to supervise
and review the system activities.

4. The System shall provide the capability to centrally monitor the content of audit records generated by
individual components throughout the system.
5. System must automatically generate E-Mail and SMS alerts to pre-defined E-Mail and SMS accounts
regarding accounts management creation, deletion, change of rights.
6. Bidder must strictly comply with requirements of ISO 270001 while designing Risk Assessment,
Operational and Applicability plan and Security Policy.
7. MG NREGS, RDPR DEPT at its own cost may conduct a security audit by third party to ensure that
the Security Policy and the Operational Procedures are strictly implemented and practiced by all the
users of the system and that there is no breach or compromise of security. This audit can be undertaken
at any moment.
8. The Bidder shall comply with all the recommendations made by the third party auditor within the time
specified.
9. The system shall allow conducting post-implementation review and audit in select cases that have
resulted in a major change to check the completeness and correctness of the administrative tasks
performed and ensuring that all and only those necessary components have been installed on the system .

Section 4: Scope of Work

Scope of Work
Period of Engagement : Three years but the period for software licensing (if any) shall
be five years
Note: The first year maintenance and project management shall not be paid separately
and shall be covered in the cost of Software Solution itself.. The Annual Maintenance &
Project Management Contract (AM&PM C) for 2nd and 3rd year shall be done and
responsibilites in this regard shall be discharged as per this RFP and contract. The
Solution Provider shall ensure adequate resources and personnel are made available
as per this RFP requirements to deliver and discharge responsibilities cast upon him by
this RFP and the contract.
MG NREGS, RDPR DEPTs Module Based Process Automation through end-to-end Web Solution is
going to be developed at Bidder Site.
Note: The Scope of Work or this section shall have over-riding effect insofar as
anything else written in this RFP which may be inconsistent or interpreted to be
inconsistent or likely to be interpreted to abridge or dilute the requirements of this
section.

4.1 Functional & SLA Requirements

1. The software solution shall be built in complementarity with the existing
NregaSoft of NIC New Delhi (including full responsibilty of integration and
coordination with existing software solutions). For details on NregaSoft visit
www.nrega.nic.in.
2. The software solution shall be web-based. The solution architecture shall be based
on Centrally hosted n-Tier Web Based approach. A web portal for showcasing the MG
NREGS and its details and activities shall be developed. The software solution shall
integrate with other software solutions as per requirements of MG NREGS.
The software solution shall seamlessly support both on-line and off-line modes. This is
so as many a Gram Panchayats and other offices/locations which are likely to use the
software solution do not have a very reliable internet connectivity. Therefore, the
software solution shall be able to seamlessly toggle between on-line & off-line mode of
operation without the user getting to know any difference. The data/information
captured during the off-line mode shall be automatically synchronized once the
internet connectivity becomes alive/active. The ability to work off-line shall be
configurable in terms of number of hours/days beyond which the error/warning/ticket
message is generated seeking intervention of the Administrators. The software shall
allow data sychronization of PERMANENTLY offline mode systems with on-line system
strictly though Digital Signatures Certificate plus biometric based authentication.
Further, in case of automatic sychronization by the software (temporary offline
systems) the use of Transport Layer Security (TLS) and/or Secure Sockets Layer
(SSL) protocols shall be mandatory.
SMS, Mobile, Call Centre & IVR Support
All the aspects and facets of MG NREGS shall have SMS, Mobile, Call Centre Support
and Integrated Voice Recording System including Complaints, Labour Demand, any
other.

3. In case of permanently off-line GP locations, the software solution shall run in

off-line mode with regular data and other synchronization with a pre-determined
location (in terms of IP address). This synchronization shall be secure and
authenticated with the Digital Signatures and Biometrics of (i) PDO of the GP, and,
(ii) One Person authorized by EO TPS. Further, the use of Transport Layer Security
(TLS) and/or Secure Sockets Layer (SSL) protocols shall be mandatory.
4. The S0ftware Solution shall create a home page for each of 5627 GPs, 176 Taluks, 30
District ZP offices with the following staffing pattern (subject to change in final SRS)
a. ZP Office (i) One CEO ZP (ii) One Ombudsman (iii) Two Deputy Secretary ZP &
Project Director DRDA (iv) District MIS Cooridinator (v) Two Supervisors (vi) Five Case
Workers (vii) Five Data Entry Operators (viii) One Grievance/Complaint Case Worker
b. Taluk Pachanyat Samiti (i) One EO TPS (ii) One Assistant Director Taluk (iii) One
Taluk MIS Cooridinator (iv) Two Supervisors (v) Five Case Workers (vi) Three Data Entry
Operators (vii) One Grievance/Complaint Case Worker
c. GP (i) One Adhyaksha (ii) One PDO (iii) One GP Secretary (iv) Two Data Entry
Operators (v) One Grievance/Complaint Case Worker
d. The application must support role based access control for authorization purposes.
Each staff/personnel shall have a login ID with intuitive login name (such
<Deisgnation.OfficeName.Location> (PDO.GP.Kanakapura etc). The login id of a
government servant shall be linked with his (i) email id (ii) Mobile No; (just like
facebook allows this). In this, the first login could be as per based on Official ID, and,
once logged in, an employee shall be asked to give his email and mobile no
(compulsory), thereafter, the government servant can use (i) Regular Login ID (ii) His
email id (iii) Mobile number, to login. The email facility or PoP facility shall be created
for each of these personnel.
Each of the user as stated above shall have option to navigate and login as Virtual
User into all other logins albeit with read-only permissions.
The whole of the above adminsitrative hierarchy shall be built graphically and
a. The administrative tree is not merely a graphical representation of the
administrative hierarchy but the said hierarchy shall be built into the office creation. In
other words, each office which is created will know at which administrative level it is
situated and shall be linked to those above and below it in administrative hierarchy.
b. It is this administrative level which shall be reflected at the top of the HOME PAGE
when an officer/official logs in (see Annexure-Z for generic screen shot).

The radio button in each login main page of each employee shall lead to full Administrative Tree of all
departments wherein each name shall be a hyperlink drill-down. For example once the Full
Administrative Tree populates the screen, clicking EO TPS will open all EO TPS Offices of the State
(district wise). These, in turn, will also be hyperlink drilldowns and, clicking any of the EP TPS Office

will open full Login Main Page of the EO TPS as READ-ONLY. This idea is called Virtualizated Users.
Virtualized Users: As per above, once drill-down Administrative Tree is available on the screen, the
purpose is to enable each officer and official to navigate every other login environment as a Virtual
User. In this, for example, CEO ZP of a district will have ability to click and login as Virtual User in
any EO TPS or even PDOs login. This facility shall be available to each and every official user to
login as Virtual User albeit with READ-ONLY permissions. Moreover, in case a government servant
is going beyond his administrative jurisdiction, then the READ-ONLY provision will be limited even
further and shall not have ability to see individual persons. No virtual User shall have read permission to
read (i) Emails (ii) To-Do List (iii) Similar personalized information.
5. Login Main Page Functionalities: The functionalities of each button/table/chart
etc are explained below
a. Heading: The items are self explanatory Administrative Level is the level as per
Administrative Hierarchy Tree
b. Admin: Self explanatory one.
i. Employee Master = edit option for add/modify/delete office employees with login
creation
ii. Workflow Master = Edit/create service wise workflows and link to Employees or
link to other offices
iii. Authorized Representative = Allows configuring one or more authorized
representatives of Head of Office to act on behalf of the office
c. Performance Rank:
i. Depending upon at which level a particular office is in the Administrative Hierarchy,
its performance ranks are calculated (for example CEO Office will be ranked at (i)
Division Level (ii) State Level, whereas, GP Office will be ranked at (i) Taluk (ii) Subdivision (iii) District (iv) Division, and, (v) State level).
ii. Rank can be calculated using suitable measureable Parameters
Performance Rank = Weighted Average of Performance in Multiple
Criteria/Parameters
Clearly, a real number will be obtained using above formula (for each State, Division,
District etc level) which can be used to rank inter-se all offices of a given type (rank all
EO TPS Offices, CEO ZP offices etc). Rank in (a), (b), (e) will be as per real score of an
office in these parameters.
d. To-Do List: This is a Calendar Linked electronic PA/planner. Also, any important
instructions which a senior officer sends through Small Message button will come
and get tagged in this.
e. Email Pop: This button allows iPhone style collating and single or multiple inbox
support for at least three email service providers

6. The functionalities are broadly explained Module by Module below. The broad functional
requirements below shall be read together with (i) MG NREGS Operational Guidelines 2012, (ii)
National Rural Employment Guarantee Act, 2005, (iii) MG NREG Scheme of Karnataka, (iv)
Karnataka Unemployment Allowance Payment Rules, (v) Karnataka Employment Guarantee Council
Rules, (vi) Karnataka Employment Guarantee Fund Management Rules (vii) Write-Up on PoC
Annexure J
(i) General
The Modules and the Scope of Work shall be read along with other documents are stated above, and, the
Modules shall be created such that MG NREGS Guidelines are enabled, supported and enforced. FRS
and Write-Up on PoC are covered in detail in Annexure-C and Annexure-J, respectively, and, the same
shall be treated as part of this Scope of Work.
(ii) Registration & Planning Module
This software module will allow a citizen to apply & register as a Job Card Holder On-line as well as at
Gram Panchayat. Similarly, the registration through Common Service Centres (CSCs such as Nad
Katcheris/Nemmadi) shall be supported. This step will link the process of registration of a household to
Job Card generation and capturing the information in MIS or other software. This shall obviate need to
do manual entries substantially into the MIS. The registration of a household and issuance of Job Card
shall be as per the prescribed MG NREGS Guidelines in this regard.
In the Planning Process the conduct of Grama Sabha, the proceedings of thereof and recommended
works list of Grama Sabha will be computerized. Now, once the first list of recommended/approved
works by a Grama Sabha is entered into system, all subsequent processes of prioritization of works (GP,
TPS and ZP level) right upto creation of Shelf of Projects and Annual Action Plan will be automated and
shall not need any futher data entry. In fact, the list of approved works of Grama Sabha shall be entered
once. The subsequent prioritization, short-listing, Annual Action Plan preparation shall be based on this
entered list of works only. The entered list of works can be prioritized, shall be categorized as
permissible/impermissible; but not deleted. The Gram Panchayat, Taluk, District level authorities
shall have not have option to add any work which has not come as duly approved by Grama Sabha.
However, the GP/Taluk/District level authorities and Line Departments shall have option to recommend
works to the Grama Sabha by entering these works in Planning Module as Works Recommended to
Grama Sabha. No deviations from the MG NREGS Guidelines shall be permitted. The Annual Action
Plan shall be created for each district in a time bound manner the Planning Module shall ensure this as
per MG NREGS Guildelines/prescribed timelimits.
There are Permissible and Impermissible Category of works under MG NREGS Operational
Guidelines. This categorization shall be fully captured by the Planning Module. At present there are 16
broad category of permissible works. Each work which is approved in the Grama Sabha shall be first
categorized as Permissible or Impermissible. In case of

permissible works,
theTaluk/Block
same shall be
further categorized
into one of the 16 (at present this number
Step-by-Step
The
Planning
Executive
Process
Officer (Programme
may change in future)
permissible
cateogries.
Further,
each
permissible category of works shall
Officer) and TPS can only refer back of
to the
GP 16
such
be further divided into
sub-categories
based
on
theviolate
wage-material
ratio
Works
works
in
arethe
identified
worklist
or
which
selected
or chosen
MG NREGS
or associated with the work. The
wage-material ratio Guidelines.
shall be calculated
usingworks
the Estimation
Preparation
proposed
byThe
villagers,
other
GPs
orinLine
the Depts
approved
or list Module. The works under a
other
must
be
Agencies
approved
without
change
bycategorized
TPS
given category but with
similar
wage-material
ratio
shall be
together as a sub-category.
within
15
days
of
receipt
(EO
shall
place
the
The idea is that Software Solution shall ensure that overall 60:40::Wage:Material Ratio is maintained at
The (with
worklist
worklist
inminimum
TPS
is prepared
within
ten
asdays
per
above
receipt
proposals
of being spent on unskilled labour
a Gram Panchayat level
60%
funds
ofof
MG
NREGS
and
list).
consolidated
In
case
EO/TPS
GP
and
fail
to
Village-wise
approve
the
worklist
wages). In other words, the Annual Action Plan and Shelf of Projects created for a Gram Panchayat
sent
byofGP
then itare
shall
beon unskilled labour wages in a
shall be such that atas
least
60%
thewithin
funds 15-days,
of MG NREGS
spent
The worklist
deemed
to have
is placed
been for
approved
discussion
by TPS.
and The
financial year. The Finance, Accounting & Wage and Bill Payment Module shall keep a track of this
decision
TPS
can add
of the
certain
Grama
works
Sabha
which are admissible
and highlight at regular
(configurable)
intervals
any
and are of "inter-GP" nature deviation from this minimum requirement.
Grama Sabha delibrates the list and

It shall be possible to
track
all planning
processes
across
the
state
and take corrective actions in time to
approves/rejects/modifies
The
deemed
approved
or actually
the
worklist.
approved
A final
ensure adherence toworklist
prescribed
time-limits.
The
Planning
Module
shall automatically highlight
duly approved
reaches
worklist
CEO ZP,
is who
givenshall
by Grama
examine
Sabha
deviations from the from
prescribed
of MGofNREGS,
and, take
pointtime-limits
of admissibility
works from
MG suo-moto corrective action to the
TheofGS
NREGS
guidelines.
approved
Theemail
inadmissible
goes
toprinted
GP.
works
The
GP
shalletc.
extent possible by way
issuing
SMS worklist
and
alerts,
notices
prioritizes
be
sent back
thetolist
GPasfor
per
reconsideration.
GP's Labour Budget
The

(Labour
other
works
based
on expected
have
to approved.
Labour
The Job Card holders
shalladmissible
beBudget
able to is
apply
atshall
Gram
Panchayat
personally, or, On-line and even through
Demand
The
Zilla
in
Panchayat
a
GP).
There
shall
should
approve
be
the
attempt
to Labour Demand, and, the same
a Call Centre. The demand of work shall be, in turn, used to assess the
select
admissible
works
works
in
all/maximum
within
15-days
number
of
receipt
of
villages
shall then correlated with preparation of Action Plans (depending on the estimated cost of the works).
in the GP.
failing
which
GP the
cannot
worklist
delete
shall
anybework
deemed
(unless
to it
The labour demand of an area/GP shall be continuously kept a track of, and, in case the actual labour
violates
have
been
MGapproved.
NREGS Guidelines)
The ZP canand
addcan
certain
merely
demand and execution
of works
crosses
75% of the originally approved labour budget (in terms of
priotitise
works
which
the are
worklist.
admissble and are of "Interlabour demand); then
this
Module
shall
automatically
trigger as well as alert for enhancement (to an
Taluk" nature
extent that shall be configurable)
of
labour
budget
and
Annual Action Plan for the
The prioritized and GP approvedincrease
Worklistingoes
concerned area/GP from
among theworklist
Shelf ofas
Projects
or Grama
Sabhas Approved list of works. In
to Taluk/Block
The
approved
Panchayat
for
per approval.
Labour
Budget
EO TPS
case the said list of approved
works"Annual
of Grama
Sabha
is admissibility
inadequate
shall become
examine
the
worklist
Action
as Plan"
to
for the then
of the Module shall trigger and
works
asand,
per
enter
MG NREGS
into "Shelf
Guildelines.
of Projects".
The This
alert for conduct of district,
new Grama
Sabhas.
consolidated works
inadmissible
"Annual
shall
Action
be sent
Plan"back
as per
to GP
Labour
for
change
Budget
shall
by
EO
be
TPS
sent
by
CEO
ZP
to
State
level,
The Planning Process and Annual Action Plan shall be correlated with the number of Job Cards in a
which,
turn,Days
sends
Ministry
of Rural
Grama Panchayat such
that in
Person
in it
thetoAnnual
Action
Plan for a Grama Panchayat shall not
Development,
Govt
of
India
as
State
Plan.
All
exceed [100 X No Job Cards in the GP]. This upper-limit shall be enforced
subject to any changes in
the district annual action plans are
MG NREGS Guidelines in this regard.
consolidated, and, financial requirements of the
State are arrived at.

The planning process for creation of Annual Action Plan for a financial year starts from 15 th August of
the preceding year. The Grama Sabhas shall be conducted, the worklists prepared and approved in the
Grama Sabha shall have to be entered into the Planning Module. As per above details, the Planning
Process is as follows

(iii) Estimate Preparation Module & e-Measurements

Standard templates will be prepared for all the works that are taken up under MG NREGS. The said
templates will be loaded on mobile devices which have

capability to capture time&date and geo-stamping of locations. The device shall have to be taken to
actual spot of the proposed work and then dimensions/data fed into the template to generate the estimate
for the work. This will substantially reduce the scenario of preparation of work estimates without
visiting the worksites.
The estimate once prepared and approved will become finalized and frozen. Now, during the actual
execution the executed works will be measured using same mobile devices and the measurements of
executed work will be fed into the software to generate bills for payments.
These e-Measurement will be linked to automatic preparation of e-bills and also linked to e-MR of MIS
(both at the time of downloading as well as entry). This will trigger electronic payments for both wages
and material directly into the correct accounts.
The Bid Winner shall list out the compatible mobile devices wherein the device can serve the
purposes of (i) Mobile Phone (ii) GPS/GeoStamping (iii) Photography (iv) Estimate Making & eMB. These shall be, to the extent possible, regular mobile phones available in the market. The Bid
Winner shall clearly state the ability of mobile devices listed by him to capture GeoStamp in
absence of mobile networks as well as the likely resolution and error in capture of GeoStamp
shall also be mandatorily mentioned

(iv) Finance, Accounting & Wage and Bill Payment Module

A complete Finance, Accounting (including bill processing) Module shall be developed. This will
computerize full accounting system of MG NREGS. The existing e-FMS system will be used for bill as
well wage payments, however, the calculations and billing which trigger the e-FMS payments will be
computerized (bill preparation will be based on electronic input of mobile devices which act as e-MB).
This Module shall integrate fully with the MIS/NregaSoft of NIC, New Delhi particularly, for eFMS
payments.
The eFMS system of payment is used by GPs and other Implementing Agencies under MG NREGS. In
this system a single pooled central account at the state/district level is used for payment of bills of GP
and other Implementing Agencies. The GP and IAs trigger payments from this single pooled bank
account electronically through use of DSC/PKI. The accouting and cash book writing shall adequately
take care of this. The software solution shall also full integrate with this eFMS system of NICs
NregaSoft.
In future, UID/Aadhaar based payments will become the standard payment method of MG NREGS, and,
the software solution shall fully support and integrate with the same.
(v) Material Management & Asset Management
A complete module shall be developed for Material Purchases, Inventory, Storage and Management. The
process to procure material will also be computerized including e-procurement integration (if required).
This module

will be directly linked to e-Estimation Module, and, thus, ensure that material purchases are not in
excess of estimations. This module shall be directly linked to e-Estimation, e-MB, e-Billing, Finance &
Accounts Modules, and, thus, ensure that material purchases are not in excess of estimations. The
Module shall link each procurement to the works, and, at least, the following shall be the features
a. Based on the PD projection in the 1st quarter of the financial year, the upper limit
shall be put on material procurement. This Module shall not allow more procurement of
material than this limit.
b. Thereafter, as per the %age achievement of PD as against the projected PD in the
preceding months of the current financial year, the upper limit on material
procurement shall be affixed for material procurement from second quarter on-wards
(July onwards)
c. Each procurement shall be linked to specified works, and, their estimates shall serve
as the upper limit on the material procurement that can be done for a particular work.
The material procurement without linkages with work in the Annual Action Plan shall
not be permitted.
d. These limits subject to strict enforcement after December may be relaxed and
configurable at the discretion of CEO ZP or the concerned Line Department which is an
Implementing Agency.
e. Once, Action Plan linked work-wise procurement of material is done, the procedure
to do so shall be in conformity of KTPP Act, and, with proper tax, royalty and duty
payments. The software solution shall allow generation of tender notices, tender
documents etc.
f. The utilization of the material shall be as per progress of a work and connected
estimate of the work. The billing of a work in Billing, Finance & Accounts Module
will automatically lead to proper accounting and reconciliation of the material already
used/issued for a work. In this sense, the issuance of material for a work shall be based
on the estimate of the work and the Software Solution shall not allow more material to
be issued or utilized for a work than its approved estimate.
g. The asset creation shall be a direct by-product of completion of a work in MG
NREGS. No separate manual entries shall have to be made for Asset Register. Asset
Mapping etc. The work ID shall become/get linked to the Asset ID.
(vi) The asset creation will be a direct consequence of completion of a work in MG NREGS. No
separate manual entries shall have to be made for Asset Register. Asset Mapping etc.
(vii) GIS Module
A complete satellite image based GIS Module shall be developed for transparency and
monitoring. The following shall be ensured
(A) Each work shall be shown on the GIS the works could be at different stages
a. Proposals (under consideration, yet to be approved by Grama Sabha)
b. Approved list of Grama Sabha
c. Approved list of Gram Panchayat (Shelf of Project of GP)

d. Approved list of Taluk (Shelf of Projects in a Taluk = Sum of Shelf of Projects of all
GPs in a Taluk PLUS Line Dept Works in a Taluk)
e. Approved Annual Action Plan of a district
f. Works started in a given year
g. Works on-going at a given point of time
h. Works completed in a given year(s)
The works in category (e) to (h) must be captured and shown on the GIS. From among
works in the category (a) to (d), such of the works for which estimate has been
prepared in the Standard Estimation Template, shall also be shown on the GIS. In other
words, each work for which estimate has been prepared shall automatically get linked
to the GIS Module for display.
(B) The assets created in MG NREGS shall be displayed on the GIS Map on same lines
as works.
(C) There are 16 Permissible Categories of works. Then there are Sub-category. In
overall context of Point (A) above, there shall be option to view or display works and
assets on GIS
a. Category Wise
b. Sub-Category Wise
c.
District wise
d. Taluk Wise
e. GP wise
(D) All works and assets photographs (being time & geo-stamped) shall display all
relevant information about the work through a drill-down feature which will go right
upto the muster roll level entries about the MG NREGS wage seekers who executed the
said work (including photographs of actual works/assets). This way the GIS Module
shall be lined with the other Modules of the Software.
(E) The display on the GIS of the possible duplicate works shall be made available.
Briefly: A complete satellite image based GIS Module shall be developed for
transparency and monitoring. The created assets will be displayed on the GIS Map,
and, attempts will be made to correlate terrain and the works specifically suitable to
the terrain. All works and assets photographs (being stamped with time & geostamped) will display all relevant information about the work through a drill-down
feature which will go right upto the muster roll level enteries about the MG NREGS
wage seekers who executed the work (including photographs of actual works/assets).
(viii) Human Resource Management System

A complete HRMS system will be developed including leave management, payments, performance
evaluation etc. In context of more than Rs50Crores annual payment going-out for Manpower/contractual
staff, this Module will become THE TOOL to manage the workforce, evaluate them continuously, and,
do performance review based on which they will get payments, continuation or performance evaluation
shall be based on this Module.

Therefore, in absence of this module it will be practically impossible to monitor and supervise the
workforce and track their outputs and contributions to MG NREGS. All the workforce will be provided
email id and login id from the software solution. The notices, communications, etc through software
solution shall be treated at par with paper/formal communications, and, the same shall lead to efficient
management of manpower. The delegation of power with respect to personnel issues shall occur and get
enforced through the software solution.
(ix) Complaints/Grievance Management Module
This is a self explanatory Module. Idea is to have a complaint/grievance module which is interactive one
with the complainant, and, obtains his feedback on the closure/decision on his complaint. If he is
unsatisfied with the resolution/reply of a complaint then the said complaint is automatically escalated
to the next higher level/officer. This continues to happen until State Level. This way a complainant need
not run from pillar to post to have his voice heard. Full Call Centre & IVR support shall be given as
well.
(x) Ombudsman Module
All 30 districts will soon have Ombudsman who, in turn, is a formal authority to examine complaints on
and with respect to MG NREGA implementation. Ombudsman has authority to issue formal orders for
recovery, recommendations for disciplinary action etc. All these will be provided by the Module plus the
orders of Ombudsman will reach proper quarters both physically as well as electronically for follow up
action.
(xi) Digital Signatures Certificate Management
About 15000 Digital Signatures Certificate (DSCs) are soon going to be part and parcel
of MG NREGS implementation as all/majority of the payments under MG NREGS shall
be made using them (including, all payments to labourers/Job Card Holders). Apart
from this, the DSCs shall be used extensively for all MG NREGS management, HRMS,
and other communications. In view of large number of DSCs, the software solution
shall build a robust, intuitive, and intelligent DSC and Dongle management system to
ensure that (i) the DSCs do not expire without aprior and advance alerts for renewals
(ii) New DSCs requests are triggered without any delay (3-months in advance) (iii) the
usage of DSCs is logged and tracked, including, the IP addresses from where the DSCs
are used.
The web based solution shall fully support PKI and Digital Signatures Certificates of
both government servants as well as private individuals. The Software Solution will
also fully support web-based/online and offline biometric authentication. The
standards in this regard are as prescribed by Ministry of Information Technology, Govt
of India.
A full module for management of DSCs, including, but not limited to (i) Dongle
Management (ii) Timely and in-advance DSC Renewal Management (iii) New DSC
issuance (iv) All aspects of DSC Management.

(xii) Social Audit Module

The whole gamut of activities on social audit front will be captured through on-line reporting,
evaluation. The State of Social Audit will be able to use this

Module to track and follow up the social audit across the state. The Module will give facility to scan and
upload photographs, proceedings, and, other feedback and reports emerging in Social Audit from the
field.
(xiii) SMS, Mobile, Call Centre & IVR Support
All the aspects and facets of MG NREGS shall have SMS, Mobile, Call Centre Support and Integrated
Voice Recording System including Complaints, Labour Demand, any other
(xiv) Reporting, Dashboarding and Analytics Module
MG NREGS due to its massive data generation and multiple issues and points of
evaluation/monitoring/performance; needs a very dynamic, query based, and, intelligent reporting
system. It needs Analytics to predict demands for Gram Panchayats and Districts.
This Module shall automatically highlight deviations from the prescribed MG NREGS Guidelines, and,
take suo-moto corrective action to the extent possible by way of Calls through IVR, Call Centre, SMS
and email alerts, printed notices etc. This Module shall also be linked with other Modules to trigger
action for deviations from the MG NREGS Guidelines for example, action on violation of
60:40::Wage:Material Ratio; false bills (once this has been finalised by an appropriate authority) and the
recoveries from salaries, delayed payments to labourers/bills; etc.
As per availble data, the software solution should provide log and data for measurement, statistics,
analysis and analytics (office wise, officer wise, GP wise, Line Department, district, taluk and sub-taluk
wise) of
a. average payment time,
b. average Person Days,
c. on Muster Rolls,
d. on wages, material and other payments,
e. work and person days generation - spatially and area wise (patterns shall be discovered in this regard
for practical action)
f. Mean, Median, Standard Deviations & other Statistical features of transactions, works, person-days,
MG NREGS review points, above points shall be calculated and made available, and, also
automatically acted upon to the extent possible.
(xv) The software solution shall run from Go-Live. The solution over the web could
be accessed by upto 6000 (six thousand) concurrent online users at a given point
of time though the total logins and passwords will be more than that and expected
to touch 30,000 (thirty thousand). The meaning of concurrent users is explained
in Annexure-K.
(xvi) The web based solution shall fully support PKI and Digital Signatures
Certificates of both government servants as well as private individuals. The
Software Solution will also fully support web-based/online biometric
authentication. The standards in this regard are as prescribed by Ministry of
Information Technology, Govt of India.
A full module for management of DSCs, including, but not limited to (i) Dongle
Management (ii) Timely and in-advance DSC Renewal Management (iii) New DSC
issuance (iv) All aspects of DSC Management.

(xvii) The solution architecture shall be based on Centrally hosted n-Tier Web
Based approach. A web portal for showcasing the MG NREGS and its details and
activities shall be developed. The software solution shall integrate with other
software solutions as per requirements of MG NREGS. The integration shall be
achieved by the Solution Provider as per laid e-Governance Standards. The solution
is a high availability solution both in hardware and software terms.
(xviii) The Application shall support both English and Kannada for all the
reports/dashboards/Query Builder. The application shall be accessible using
popular web-browsers such as Internet Explore, Mozilla Firefox, Google Chrome etc.
(xix) Security Policies must be developed using global standards like ISO 27001.
Security Policy shall be implemented only after it is approved by third party audit
agency. The various laid standards, security and other protocols and mandatory
directions of Ministry of Information Technology, Department of
Information Technology, Govt of India, shall be complied.
(xx) The SMS & Mobile based reports shall be provisioned in the software solution.
The application shall provide to send SMSes. Application may use the SMS gateway
provided by the e-Governance department of Government of Karnataka or any
other SMS Gateway that MG NREGS, RDPR Dept may make available. The actual
cost with respect to these SMSs/Mobiles will be borne by MG NREGS, RDPR DEPT. It
is expected that about 1Lakh SMSes would be needed to be sent each day.
(xxi) The application must support role based access control for authorization
purposes.
(xxii) Web Solution shall provide email pop facility in each User Login Account
whereby the user can port all his emails (at least in gmail, hotmail, and yahoo
email accounts) to his User Login of this Web Solution.This email pop is akin in
functionality to standard facilities provided in Smart Phones or MS Outook in
this regard.
(xxiii) The software solution shall integrate (through XML data-interchange web
services) with the existing Software as well as the other existing department
software with respect to aims of MG NREGS so that the Scope of Work is
adequately delivered. The other software solution also have responsibility to fully
cooperate in the integration. In case of any issue in this regard the decision of the
MG NREGS, RDPR, Dept, shall be final and same will be reflected in the SRS
document. It is expected that standards and protocols prescribed by Ministry of
Information Technology, Department of Information Technology, Govt of India shall
be complied with. It shall be duty of the Solution Provider to integrate through XML
data-interchange web services in this Solution Provider shall support both push
and pull of data with real-time, or close to real-time database synchronization.
In this context it may be noted that the Software Solution and full Solution would consist of three
components namely,
o Web Portal
o Application Software
o Integration Component

The protocol for communication including data formats and exact mechanism of data
transfer with participating entities shall be morefully documented in the SRS document.
(xxiv) The training will be organised by the MG NREGS, RDPR Dept but actual
training at Bangalore & Mysore shall be imparted by the bid winner resource
persons. It is assessed that training of trainers will be the focus of training at
Bangalore and Mysore level and upto 1500 persons (Trainers) in total could be
trained at Bangalore & Mysore level over the period of nine-months. The training
will be done in batches upto size of 30. So it is expected 50 such batches will be
trained on the software. The bid winner shall have to provide the resource persons
for these training. The training is expected to be completed in 9 months time from
Go-Live.
(xxv) The Bid Winner shall ensure and post 8 dedicated personnel of prescibed
qualifications the throughout the contract period to deliver the requirements of this
RFP with MG NREGS at the location(s) of choice of MG NREGS.
(xxvi) Web User Interface should be clean HTML without having to install additional third party
applications or plug-ins
(xxvii) Statistics, Analysis and Analytics:

As per availble data, the software solution should provide log and data for measurement, statistics,
analysis and analytics (office wise, officer wise, GP wise, Line Department, district, taluk and sub-taluk
wise) of
a. average payment time,
b. average Person Days,
c. on Muster Rolls,
d. on wages, material and other payments,
e. work and person days generation - spatially and area wise (patterns shall be discovered in this regard
for practical action)
f. Mean, Median, Standard Deviations & other Statistical features of transactions, works, person-days,
MG NREGS review points, above points shall be calculated and made available.
(xxviii) A support to Petitions and Unemployment Allowance claims as per provisions of the MG
NREGS Guidelines on the works/NREGS shall be created. This shall become full on-line decision
support system for Authorities. This functionality is essential to correctly operationalise and decide the
Unemployment Allowance claims
(xxix) SLAs of performance of the software (at DataCentre level) [Note that
bandwidth and Datacentre is responsibility of MG NREGS, RDPR Dept] shall be (see
Annexure-H for details as the same be read as part and parcel of Scope of Work)
a. Concurrent on-line users 6000 (six thousand) (Annexure-K)
b. Portal page display time < 7seconds
c. Time required to generate reports
i. Report that does not give individual details < 10 seconds
ii. Report that gives individual details and individuals are less than 500, < 15
seconds and for reports displaying upto 10000 records/individual details < 60
seconds. An intelligent

reporting architecture must be built to display large data set in sets of smaller
batches with response time as prescribed in this section and SLAs.
iii. Other simple queries < 15 seconds
iv. Complex queries, charts/graphs and analytics < 30 seconds
d. Password and login management of upto 1Lakh users
21 Software
The customized software and the Software Solution developed shall be the property of MG
NREGS, RDPR Dept, Govt of Karnataka
All the system/software licenses (if any) shall be procured by the Solution Provider. The
system/software licenses mentioned in the Bill of Materials shall be genuine, perpetual, full use and
should provide patches, fixes, security updates directly from the OEM at no additional cost to MG
NREGS, RDPR Dept for the entire period of 5 years.
Solution Provider shall be responsible for providing the perpetual licenses for the commercial
software so as to maintain the IPR and source code (customised / extension) with MG NREGS,
RDPR Dept, Govt of Karnataka.
The bidder shall provide with a full use database license
All the licenses and support should be in the name of MG NREGS, RDPR Dept, Govt of
Karnataka
22. Time shall be the essence of the contract and of this work as MG NREGS, RDPR
Dept has to meet very tight time and delivery deadlines, therefore, timely delivery
and adherence to delivery schedule is essential part of the requirement of
successful implementation. Non successful adherence to time limits of delivery as
stated in this bid document, and; in particular, in Section 5, shall result in declaring
the work unsuccessful and closure of the contract for breach of contract condition
without any financial or cost liability to MG NREGS, RDPR Dept.

4.2 Responsibilities of the State Data Centre (SDC)

The application and the supporting artefacts will be co-hosted at the State Data Centre. The following are the
roles and the responsibilities of the SDC:
a. Ensuring the uptime of IT infrastructure set up at the SDC
b. Storage of Data related to the this project
c. Provide secure database services for the this project via the internet
d. Ensure compliance with the requirements of the SLA between the MG NREGS, RDPR Dept and the SDC

4.3 Hardware Configuration for the New Application

The Solution Provider is required to assess and state and provide as per need the IT infrastructure
requirements for hosting the Software Solution. The IT infrastructure assessment should cover servers,
security, storage, networking etc as required for ensuring performance, security and availability of the
application software as a part of the proposal. This infrastructure requirement provided by the selected bidder
shall be validated by MG NREGS, RDPR Dept and a Technical Expert Team. After award of contract, this
cost provided by the selected vendor would be compared to the preferential hardware cost that CeG, eGovernance is being offered by various vendors of the same. If the cost specified by the bidder is lower than
this, then the hardware could be procured by the selected bidder. If higher, then MG NREGS, RDPR Dept
has the option of procuring the same

according to the Bill of Materials provided in the proposal. This decision would be taken by MG NREGS,
RDPR Dept soon after the successful vendor has been identified. In this actual procurement will be as per
requirement assessed. The solution including the hardware shall be hosted in the Karnataka State Data
Centre (SDC). However it is the responsibility of the SOLUTION PROVIDER to ensure performance, security
and availability of the application. The IT infrastructure requirements signed-off between the SOLUTION
PROVIDER and MG NREGS, RDPR Dept shall be provided by the SDC or it may be procured by the MG
NREGS, RDPR Dept. The security and network infrastructure such as firewall, antivirus, LAN and internet
connectivity shall be provided by the SDC.
The SOLUTION PROVIDER shall provide the configuration, specifications and rates for the complete bill
of materials of the hardware (Servers, Storage, etc) infrastructure components, OS and Database licenses
(which shall also include OEM support for the period of the contract) to fulfil the requirements of RFP as per
the SLA. The detailed Bill of Materials shall be provided by the vendor meeting the specifications and Service
level criteria identified.
Procurement of IT infrastructure components for the data centre and the DR site as per design, sizing and
configuration of the SOLUTION PROVIDER, along with required support for period of contract would be
carried out by either the SOLUTION PROVIDER at quoted rate or MG NREGS, RDPR Dept itself. MG
NREGS, RDPR Dept will have sole discretion to procure the same from the SOLUTION PROVIDER at
quoted rates or from alternate sources. If asked by MG NREGS, RDPR Dept to supply part or all of these
components, the SOLUTION PROVIDER will be committed to procure and supply the requested items at
quoted rate and configuration. The price quoted shall be valid for entire contract period.
All the hardware shall comply with the specifications as submitted in the Proposal by the SOLUTION
PROVIDER and shall be certified by the OEM.
The SOLUTION PROVIDER should ensure that all the required hardware and system software at the Data
Centre is in place before the new application software is placed for deployment and subsequent UAT.
The SOLUTION PROVIDER should also ensure that all hardware and network hardening is performed in
collaboration with SDC and KSWAN so as to ensure full security of the project infrastructure. This activity
should be completed before the application software and the database is sent for deployment. The 3rd party
auditor will be responsible for providing, to the SOLUTION PROVIDER, the policies to be followed for
ensuring network and hardware hardening.
MG NREGS, RDPR Dept shall perform the load testing, as part of third party acceptance testing, to verify
the compliance of IT infrastructure & software provided by SOLUTION PROVIDER with the performance
indicators defined for the project in the SLA document. Any gaps identified in the system performance review
shall be addressed by the SOLUTION PROVIDER to the complete satisfaction of the MG NREGS, RDPR
Dept at no additional cost.
If the performance of the system is affected on account of the installed hardware limitations, due to the
rapid growth in the transaction volumes on the platform, the SOLUTION PROVIDER is required to augment
the infrastructure (For e.g. Additional servers, storage space and the corresponding s/w etc) free of cost.
In case, after go-live, there is a change in functionality, which may lead to performance degradation
beyond the service levels specified in this RFP, then the MG NREGS, RDPR Dept and SOLUTION
PROVIDER can mutually discuss and decide the level of upgradation required over the hardware
configuration already deployed at DC. Based upon the conclusion of the agreement the MG NREGS, RDPR
Dept may procure additional hardware at the rate specified in the financial proposal. Here it should be noted
that the payments due against the hardware and software procured by the MG NREGS, RDPR

Dept would be identified after depreciating the cost quoted for the item in the commercial proposal by 5 %
multiplied by the number of year spent from the date of issuance of purchase order, e.g. if cost quoted for a
particular brand of server is A and the same server has to be procured in the 3rd year of the contract then the
rate of depreciation would be 5 % x 2= 10%.
The configuration and installation of the hardware at the SDC should be complete before the UAT of the
New Application
Warranties
o In case the MG NREGS, RDPR Dept decides to procure the hardware requirements for the DC from the
SOLUTION PROVIDER, the SOLUTION PROVIDER shall be responsible for the comprehensive on site
maintenance and support for this hardware infrastructure.
o In case MG NREGS, RDPR Dept intends to procure the hardware for DC through the SOLUTION
PROVIDER, it should be the responsibility of the SOLUTION PROVIDER to ensure that all warranties and
support are procured and provided for the entire contract period. The warranties should be procured in the
name of the MG NREGS, RDPR Dept. It is thus the responsibility of the SOLUTION PROVIDER to provision
for the costs, related to warranties for the entire contract period, while quoting in the commercial proposal.
o For any COTS (Commercially of the Shelf) products proposed by bidders for new implementation, it is
necessary for the bidders to obtain authorisation from the respective software vendors (OEM). Any bids
without such authorisation shall be liable for disqualification.
The SOLUTION PROVIDER shall be responsible for installation of other system software including Software
Solution and the database software or any other components required for the MG NREGS, RDPR DEPT
solution.
The SDC has already implemented physical & environmental controls in the State Data Centre, including
UPS, AC, physical security etc and these basic services shall be extended by the SDC to the SOLUTION
PROVIDER for the project. However, it is the responsibility of the SOLUTION PROVIDER to ensure that the
systems are performing inline with the requirements of the Project as per the SLA.

4.4 User Acceptance Testing

Functional & non-functional testing of application system
The MG NREGS, RDPR Dept will appoint a Third Party Auditors (TPA) to perform audit of the entire new
system. It will be the TPA who shall represent the MG NREGS, RDPR Dept in providing acceptance to all the
deliverables provided by the SOLUTION PROVIDER. The TPA agency would be selected through a separate
tender and the selected agency would have a high level of credibility, audit experience and background with
adequate domain expertise in the area of Information Technology, Security Audits, SLA monitoring and
consulting.
The 3rd party review will focus on the following:
Deliverable Audit This audit will focus on reviewing the deliverables. The review will focus on comparing
the
o Completeness of the deliverables as well as the
o Compliance of the deliverables to best practices and global standards.
Process Audit This audit will focus on checking the processes being followed while preparing the
deliverables. The processes will be evaluated against the standards specified by the SOLUTION PROVIDER.
Implementation Audit The implementation audit will focus on reviewing the implemented system. It will
verify the performance, functional compliance, security compliance and SLA monitoring.

MG NREGS, RDPR Dept would perform a detailed acceptance testing over the application deployed over
SDC from all locations from where the system is expected to be accessed along with a test from the web
portal.
The applications would be tested by the MG NREGS, RDPR Dept with respect to the parameters laid down in
Scope of Work.
The MG NREGS, RDPR Dept will undertake an exercise of Testing, Acceptance and Certification of the
system through a TPA, as soon as the SOLUTION PROVIDER declares the system ready for this purpose
before Go-Live. SOLUTION PROVIDER shall coordinate with the MG NREGS, RDPR Dept and/or the
nominated agency for performing the acceptance testing and certification. The testing will be performed after
deployment of the solution at SDC. The testing will be performed from selected sites and web portal. The
testing would be performed before the pilot is initiated.
Hardware acceptance testing
The quality of hardware procured under the contract will be verified by performing burn test. The MG
NREGS, RDPR Dept would use the hardware devices procured under this contract for a period of one month
before giving it an acceptance.
A Third Party Auditors would be involved to verify the configuration of the system and ascertain whether it
meets all known standards mentioned the RFP. The auditor will also verify the warranty related documents.

4.5 Pilot run of the project

The SOLUTION PROVIDER shall carry out the pilot implementation and testing of the New Application as per
details prescribed by the MG NREGS, RDPR Dept. The pilot would be carried out with all the features of the
system in a place as per decision of MG NREGS. The Pilot shall be carried out in the connected & integrated
production environment. The SOLUTION PROVIDER shall address the issues/ fix the bugs identified during
the pilot phase before Go-Live. The SOLUTION PROVIDER will have to maintain a log of the bugs found
during this period. The list of bugs would have to be addressed by the 10th day of their logging. This would
ensure that the SOLUTION PROVIDER is not stuck with bug fixes till the end and the fix may be tested in
production. The SOLUTION PROVIDER shall obtain a sign-off from the MG NREGS, RDPR Dept after
successfully addressing the issues.

4.6 Operations & Maintenance (O&M) of the Solution

* The SOLUTION PROVIDER shall be responsible for the over-all management of the system including the
core application software and entire related IT Infrastructure (as per Bid if any). The following describe
some prominent items of responsibility but the list need not to be treated final.

o Web Portal
o Application Software including the Integration Component for integrating with external agencies and any
3rd party component used in the application software
o Hardware and Software Server System including COTS software systems like OS and RDBMS at state
data centre
The SOLUTION PROVIDER shall ensure compliance to uptime and performance requirements of system as
indicated in the SLA in the RFP and any upgrades/major changes to the software shall be planned
accordingly by SOLUTION PROVIDER for ensuring adherence to the SLA requirements.
Application Support & Maintenance
o During the contract period, SOLUTION PROVIDER shall be completely responsible for defect free
functioning of the application software and shall resolve any issues that include bug fixing, improvements in
presentation and/or functionality and others at no additional cost during the operations & maintenance period
within a duration agreed between MG NREGS, RDPR Dept and the SOLUTION PROVIDER, any additional
time will attract penalty.
o SOLUTION PROVIDER shall provide the latest updates, patches/ fixes, version upgrades relevant for the
solution components agreed upon by the MG NREGS, RDPR Dept.
o The SOLUTION PROVIDER shall be responsible for software version management, and software
documentation management reflecting current features and functionality of the solution. All planned changes
to application systems shall be coordinated within established Change Control processes to ensure that:
Appropriate communication on change required has taken place
Proper approvals have been received
Schedules have been adjusted to minimize impact on the production environment
o The SOLUTION PROVIDER shall define the Software Change Management & Version control process and
obtain approval for the same from the MG NREGS, RDPR Dept. For any changes to the software,
SOLUTION PROVIDER has to prepare detailed documentation including proposed changes, impact to the
system in terms of functional outcomes/additional features added to the system etc. SOLUTION PROVIDER
is required to obtain approval from the MG NREGS, RDPR Dept for all the proposed changes before
implementation of the same into production environment and such documentation is subject to review at the
end of each quarter of operations & maintenance support.
o For performing of any functional changes to system, which are deviating from the signed-off Functional
Requirements/System Requirements, a separate Change Control Note (CCN) shall be prepared by the
SOLUTION PROVIDER and effort estimates shall be mutually agreed between SOLUTION PROVIDER and
MG NREGS, RDPR Dept. This is applicable to the change requests

coming up after the Go-live stage. Before, the go-live stage, such changes and feedbacks from MG NREGS,
RDPR Dept pertaining to functional specifications will be incorporated by the SOLUTION PROVIDER without
any additional costs to MG NREGS, RDPR Dept.
o Any changes/upgrades to the software performed during the operations & maintenance phase shall be
subjected to the comprehensive & integrated testing by the SOLUTION PROVIDER to ensure that the
changes implemented in the system meets the desired and specified requirements of MG NREGS, RDPR
Dept and doesnt impact any other function of the system
The SOLUTION PROVIDER shall review security advisories (such as bulletins generally available in the
industry) on a regular basis to determine vulnerabilities relevant to the IT assets and take necessary
preventive steps.
Infrastructure Maintenance: This clause would come into force only if the SOLUTION PROVIDER has
been mandated with the purchase of hardware required for the application (if any). In case, MG NREGS,
RDPR Dept has accepted the mandate of purchasing hardware, as per the specifications of the SOLUTION
PROVIDER, for the application, then SDC would be in charge of maintaining the hardware.
o The essence of the hardware maintenance contract is to ensure that all the components of hardware work
perfectly in unison and deliver rated performance during the period covered by the agreement between the
SOLUTION PROVIDER and the MG NREGS, RDPR Dept and that the systems uptime is upto the standards
prescribed in the RFP.
o The SOLUTION PROVIDER would be responsible for guarding the systems against virus, malware,
spyware and spam infections using the latest Anti virus enterprise / corporate edition suites which include
anti-malware, anti-spyware and anti-spam solution for each Server. The Anti-virus suite and updates will have
to be provided by the SOLUTION PROVIDER at regular intervals as and when the new signatures are
released by the OEM. The cost of the software suite shall also be mentioned in the commercial bid. The
SOLUTION PROVIDER for the purpose of support on new upgrades & patches shall have a back to back
arrangement with the vendors/SOLUTION PROVIDER from whom the software suite is purchased. The copy
of the same shall be submitted to MG NREGS, RDPR Dept.
o The anti virus should have the subscription for three years server download real-time updates and
upgrades from the OEM site. The anti virus patches and updates will be pushed from State Data Centre
(SDC). During the preventive maintenance visits, the SOLUTION PROVIDER will make sure that the latest
updates is loaded in all the systems.
o The SOLUTION PROVIDER shall have the back to back agreement with 24/7 premier support with
antivirus OEM, which shall ensure that any critical issues w.r.t. virus/antivirus/backup recovery/Application
related issues are addressed within the 24 hrs. The copy of such agreement shall be provided by the
SOLUTION PROVIDER to the MG NREGS, RDPR Dept. Such agreement shall be valid throughout the
contract period.

o SOLUTION PROVIDER should provide solution to virus alerts when they occur (with in 24 hrs) or earlier in
case of emergency. SOLUTION PROVIDER has to take corrective action in case systems get affected due to
virus activity.
o The SOLUTION PROVIDER shall maintain the Hardware and Software (including Applications,
Databases, OS, Antivirus, Backup s/w or any s/w related for application deployment &
maintenance/support etc) for a period of 3 years from the formal Go-Live.
o The SOLUTION PROVIDER shall perform rectification of system software problems due to crashing or
malfunctioning of the OS; within the time limits prescribed in the SLAs.
o The SOLUTION PROVIDER shall perform installation of upgrades of system software, which should be
under taken as part of preventive maintenance. The critical updates shall be implemented immediately.
Rectification of system software problems due to crashing or malfunctioning of the OS; within the time limits
prescribed in the SLAs.
o The successful bidder shall procure licenses as required for the complete IT infrastructure supplied under
this contract. The license certificate has to be procured in the name of the MG NREGS, RDPR Dept, GOK.
o The essence of the software maintenance contract is to ensure that the entire systems software works
perfectly in unison and delivers rated performance during the period covered by the agreement between the
SOLUTION PROVIDER and the MG NREGS, RDPR Dept and that the systems uptime is up to the standards
prescribed in SLAs.
o This includes the design of an appropriate System Administration policy with precise definition of duties,
adequate segregation of responsibilities and obtaining the approval for the same from the MG NREGS,
RDPR Dept. System Administration includes the activities listed below:
Performance tuning of the system (application and database) to enhance systems performance and
comply with SLA requirements on a continuous basis
24x7 monitoring & management of availability & security of the infrastructure & assets (including data,
network, servers, systems etc).
o The SOLUTION PROVIDER shall monitor security and intrusions into the system, which include taking
necessary preventive and corrective actions.
o The SOLUTION PROVIDER shall monitor and record, server & network performance and take corrective
actions to ensure performance optimisation on a daily basis.
o Escalation and co-ordination with other vendors for problem resolution wherever required.
o System / Database administration tasks such as managing the access control system, creating and
managing users and other related work
o SOLUTION PROVIDER is required to study the detailed data storage and backup & Recovery
requirements of the MG NREGS, RDPR Dept including the

storage space required with necessary specifications and document it as part of SRS.
o SOLUTION PROVIDER shall design and implement adequate data backup and restoration procedures for
new data (including the database and all other data elements generated by the system and users).
SOLUTION PROVIDER shall ensure that Data backup is maintained till the last transaction occurring in the
system. The data synchronization between the Data Centre and DR site shall also be designed and
implemented by SOLUTION PROVIDER. SOLUTION PROVIDER shall also maintain the monthly data
backup on the external backup tapes, in an encrypted form, which should be moved to a secured location
agreed with the MG NREGS, RDPR Dept on a quarterly basis. The SOLUTION PROVIDER shall maintain
the adequate stocks of spares to meet the requirements. The MG NREGS, RDPR Dept reserves the right to
verify the stocks at any time.
o The SOLUTION PROVIDER shall enable audit logs for the server/system activities and such audit logs
shall be analysed at regular intervals to identify and address the security and performance issues. The
SOLUTION PROVIDER shall also produce and maintain system audit logs on the system for a period agreed
to with the MG NREGS, RDPR Dept. On expiry of the said period the audit logs should be archived and
stored off-site at a location agreed with the MG NREGS, RDPR Dept.
o Support to system users with respect to attending to their requests for assistance in usage and
management of the application
o The SOLUTION PROVIDER shall proactively deploy any s/w agent to monitor the hardware and software
for any signs of a breakdown/failure and plan maintenance accordingly. The SOLUTION PROVIDER shall
undertake scheduled maintenance for as per a predetermined plan.
o Develop the Standard Operating Procedures (SOPs), in accordance with the ISO 27001 & ITIL standards,
for PD Infrastructure management. These SOPs shall cover all the aspects including Infrastructure
installation, monitoring, management, data backup & restoration, security policy, disaster recovery,
operational procedures etc. The SOLUTION PROVIDER shall obtain sign-offs on the SOPs from the MG
NREGS, RDPR Dept and shall make necessary changes, as and when required, to the fullest satisfaction of
MG NREGS, RDPR Dept.
o Whenever a component has to be replaced because of technical, functional, manufacturing or any other
problem, it shall be replaced with a component of the same make and configuration. In case the component
of same make and configuration is not available, the replacement shall conform to open standards and shall
be of a higher configuration specifically approved by MG NREGS, RDPR Dept. Other important activities
shall include but not limited to:
Daily maintenance of system configuration
Implementation of system security features
Overall security of the network (excluding KSWAN)
Day-to-day disk space management

 Database tuning for performance

Tracking the servers performance taking remedial and preventive actions in case of problems
Proper upkeep of storage media for taking backups
o SOLUTION PROVIDER will undertake preventive maintenance measures as a part of overall responsibility
for maintenance of the System. It will include the following activities:
Form PM policy in consultation with MG NREGS, RDPR Dept
Frame PM schedules
PM must cover entire system
PM activities must be conducted at least once in a quarter
o The SOLUTION PROVIDER shall be eligible to claim the cost of replacement of components lost or
damaged due to theft, arson, natural calamities or proven mishandling of the equipment by the operators of
the MG NREGS, RDPR DEPT, at the published rates thereof, based on the certificate given by the MG
NREGS, RDPR Dept.
o The SOLUTION PROVIDER, may, if so advised technically and if applicable due to Bid, get a
dysfunctional hardware component repaired in lieu of its replacement, subject to ensuring the overall
compliance of the requirement of uptime.
o As a part of infrastructure and facility management reporting, the SOLUTION PROVIDER will provide
following, but not limited to, system generated reports.
Daily health check up report to be part of the monthly maintenance report
Daily performance status including downtime for servers
Daily, weekly and monthly reports on activities related to system administration
Daily, weekly and monthly reports on activities related to database administration
PM report with date, time, name of personnel, his observations and action taken
List of issues faced, action taken and their status
User Profiles and Account Management
o SOLUTION PROVIDER is required to design and implement the user management processes and obtain
sign-off from the MG NREGS, RDPR Dept for such process.
o The user-id naming & protocol shall be designed and implemented for all the user ids. Such naming
convention and protocol shall be signed-off with the MG NREGS, RDPR Dept, which shall be adopted across
the State.
o Necessary user account creation, management polices and procedures shall be defined and implemented
by the SOLUTION PROVIDER including obtaining approval for each user id created in the systems. Separate
user id shall be created or each employee, which uniquely identifies that employee across the network.
o The end users shall only be provided with role based privileges and access. Such roles, privileges shall be
signed-off with the MG NREGS, RDPR Dept MG NREGS, RDPR Dept.
o System administration tasks should include tasks such as managing the access control system, creating
and managing users, etc.

o Produce and maintain system audit logs on the system for a period agreed to with the MG NREGS, RDPR
Dept. The audit logs should be archived and stored as per the Mandatory security requirements given in the
Section 12 of the RFP.
o The SOLUTION PROVIDER shall perform system hardening which involves assessment and review of
threats to various entities such as Operating System environment, Database tier/Application Tier or
Webservers, end user systems, etc from non-authorized personnel and creation of a Security Policy to
specifically mitigate these threats. The Security Policy should then be applied on all entities of the system.
o The systems would be subjected to a suitable audit by the MG NREGS, RDPR Dept and all the
recommendations provided by the auditor should be addressed by the SOLUTION PROVIDER to the
complete satisfaction of the MG NREGS, RDPR Dept.

4.7 SLA Monitoring

Service levels agreed with the SOLUTION PROVIDER would be monitored by the MG NREGS, RDPR
Dept MG NREGS, RDPR Dept on a monthly basis and payments would be made for each month after
subtracting the total penalties arising due to non compliance of the SLA
The SOLUTION PROVIDER shall develop an SLA Measurement and Monitoring System (SMMS) for
measuring and reporting the SLAs
The SMMS shall be developed in conjunction with the MG NREGS, RDPR Dept solution
SOLUTION PROVIDER shall ensure that proposed SMMS address all the SLA measurement
requirements and calculation of applicable penalties aas per this RFP
It would be the responsibility of the SOLUTION PROVIDER to generate appropriate MIS reports both in
hard and soft copies to ensure accurate capturing of the work carried out during the month.
Payments to be made for each month would be calculated on the basis of the monthly MIS reports
generated from SMMS
With respect to the functions and activities to be undertaken by the vendor under the scope of this project, no
outsourcing will be allowed. All the personnel deployed during the contract period shall be full time employee
on the roll of selected bidder.

4.8 Exit Management

At the end of the contract period or during the contract period, if any other agency is identified or selected by
the MG NREGS, RDPR Dept MG NREGS, RDPR Dept for providing O & M Services for the Software
Solution, the SOLUTION PROVIDER selected through this bid is required to provide necessary handholding
and transition support, which shall include but not limited to the following:
a. Handing over the updated and complete source code for the application software including the
configuration files, setup files etc.
b. SubMG NREGS, RDPR Dept of updated system documentation as per the documentation requirements
mentioned in the earlier section
c. Handing over all the system manuals provided by the system software vendors including the media
(CDs/DVDs)
d. Handing over the system software including the media
e. conducting detailed walk-through, demos and training for the MG NREGS, RDPR DEPT solution to the
new vendor to the full satisfaction of the MG NREGS, RDPR Dept MG NREGS, RDPR Dept
f. Addressing the queries/clarifications of the new agency regarding the MG NREGS, RDPR DEPT solution

g. Non-performance of the any of the activities by the SOLUTION PROVIDER may lead to forfeit of the
performance bank guarantee issued by the SOLUTION PROVIDER.

For Requirements of generating reports, dashboards , Analytics - FRS

(Annexure-C) shall be read in conjunction with the National Rural
Employment Guarantee Act & Rules (Annexure A & B). It is the
responsibility of the bidder to deliver the solutions as per FRS and Act.

4.9 Other Details

4.9.1 MG NREGS, RDPR DEPT is going to provide database access for this Software Solution
Application. The said data is captured by the existing software solutions of MG NREGS, RDPR Dept
and the same shall be accessed.
4.9.2 Volume of Data for Reporting Purpose
The number of Job Cards holders working in a financial year are touching about 20Lakhs at present and
can increase upto 50 lakh. The offered web-based solution shall be scalable and architected to provide
the reporting functions for this volume of data.
The number of on-going works at a given point of time can be estimated to be around 3Lakhs and
this can increase upto 10Lakh on-going works at a given point of time.
At the end of specified period (not less than one year), to be decided by MG NREGS, RDPR Dept
MG NREGS, RDPR Dept, the data could be archived and a separate reporting, queries, Analytics,
etc system could be evolved for archived data. However, none of pending/on-going works data
should be archived irrespective of the vintage of its inception/age. At the same time, unless decided
otherwise, the archived data shall have same reporting, queries, Analytics etc as for live
database and would run on year-wise data.
4.9.3 Reporting Needs for Entire Contract period
The Reports are going to evolve over a period of time and the needs for new reports will arise through
out the contract period. Reports can be categorized as follows (see FRS for details in Annexure-C):
A. General Reports including all apsects of on-going works, completed works, shelf of works, all
and various statistics on wages, person-days, material expenses, office/GP/Taluk/district/State reports on
all aspects of MG NREGS etc
B. Matrix Reports with each cell of the matrix being hyperlinked. The drill-down shall be from State
level to GP level to inidividual work and individual labour/Job Card level who worked on a given
project.
C. Graphical Reports :Pie Charts, Bar Charts, Trend Charts, etc
D. Drill Down features: The Reporting application shall reach at the lowest level of data available. In
general, the drill-down shall have capacity to go upto the lowest granular level of data which would be
controlled as per need and user privileges.
E. Analytics:
The general discipline of Analytics is well understood and data Analytics would be required to be
done to achieve the goals of MG NREGS, RDPR Dept Act & Rules and the FRS. As per availble data,
the software solution should provide

statistics, analysis and analytics (office wise, officer wise, GP wise, Line Department, district, taluk and
sub-taluk wise) of
a. average payment time,
b. average Person Days,
c. on Muster Rolls,
d. on wages, material and other payments,
e. work and person days generation - spatially and area wise (patterns shall be discovered in this regard
for practical action)
f. Mean, Median, Standard Deviations & other Statistical features of transactions, works, person-days,
MG NREGS review points, above points shall be calculated and made available.
g. proposals for Business Process Re-engineering
h. Default prediction and prevention
i. Ranking of officers, offices, districts, departments on rational and transparent criteria, etc.
j. etc
F. Query Builder: A good functional query builder shall be provided to meet the report generation
requirements of the MG NREGS, RDPR Dept and its users.
G. See Annexure-J for details and the same is the minimum level of functionalities for PoC and the same
shall be scaled up as per this Scope of Work, and, any report incidental to the Scope of Work and
meeting the objectives of the MG NREG Scheme shall be delivered.
4.9.4 Number of Reports
The reports will come from various sections of the Act mentioned in the FRS (Annexure-C). This
number could change as per due intimation by MG NREGS, RDPR Dept MG NREGS, RDPR
Dept,
The Selected bidder will have to design reports sitting with the MG NREGS, RDPR Dept Team. Reports
will get changed/modify/evolve over a period of 12 months.
The report shall be treated as different reports only when they are logically distinct, capture
and/or produce different logical results and fields. Any two or more reports substantially giving same
information will all be treated as a SINGLE report (merely giving same or substantially same
information at different administrative locations or levels will not be treated as different reports). In this
sense
(i) 750 different HTML Reports,
(ii) 500 different graphical reports,
(iii) 250 different dashboards
(iv) a user-friendly and powerful Query Builder, and,
(v) Analytics capability
are required in total. MG NREGS, RDPR Dept can alter this requirement. The decision of MG NREGS,
RDPR Dept whether two or more reports logically constitute single or more than one report shall be
final.

PDF and Excel Export of Reports

Reports needs to have user friendly with export functionality for both PDF, Excel/Other standard outputs
Bidders are expected to read Act and FRS and prepare sample reports in the proof of concept
presentation.

Section 5: Project Implementation Schedule

Timelines for Project
Entire Rollout must be completed along with validation as per deadlines given below.
Timelines for Complete Project Implementation
Project Timelines
*Module-Wise Roll Out shall be permitted at the discretion of MG NREGS, RDPR Dept.
MG NREGS, RDPR Dept, may give provisional clearances and/or do provisional finalisation of the
S.No.
Milestone
Deadline
(Days)
documents
in order to meet the
above timelines. However
it will be the
responsibility of Bidder to
1
Contract
Sign-off
T0
incorporate any changes in the application at a later date which might be necessitated due to
2
SRS
DocumentGuarantee Act,
T0+Rules,
20 Schemes and FRS document
requirements
of National Rural
Employment
as per Scope of Work. MG Finalisation
NREGS, RDPR Dept shall intimate this requirement and the same
3 be treated as part of main
Finalization
of User
T0+ 35
shall
requirements
and the Scope
of Work.
Acceptance Test
Document
4
Customization/Develop T0+ 90
ment of Application
All Modules
5
Demonstration &
T0+ 100

Section 6: Acceptance Testing and Certification Process

MG NREGS, RDPR Dept, reserves full right to have single Roll Out / Go-Live of the entire Software
Solution, or, go ahead with Module Wise Roll Out/ Go Live. The security and other audits shall be
undertaken as per the decision of MG NREGS, RDPR Dept, in this regard. The Security and other
technical Audits shall be by vendors empanelled by e-Governance Department or by approved vendors
of Ministry of Information Technology, Govt of India. The details of this shall be as per SRS document.
The aim of acceptance testing and certification is to make sure the project meets the Specifications,
functional and performance requirements as mentioned in RFP
MG NREGS, RDPR DEPT will constitute a committee of experts for acceptance testing of the
software as per user acceptance test document.
MG NREGS, RDPR DEPT will work with Bidder after finalization of RFP for writing of User
Acceptance Test Document,
MG NREGS, RDPR DEPT may appoint a third party auditor/agency for certification for Security and
Performance.
The Third party agency will lay down guidelines and norms for the Security testing and certification
Third Party Agency will also establish a process for notifying bidder of any deviations in the
deliverables early in the schedule for corrective action.

6.1 User Acceptance Test and Functional Audit

This audit will focus on the functional compliance of the software as per the accepted software
requirements Specifications. A User Acceptance Test document will be used for functional testing. User
Acceptance Test document will be prepared by Bidder just after finalization of the System Requirements
Specifications The user acceptance test document must be accepted by before pilot certification.
TPA will use its own testing tools for User Acceptance testing.
Third Party agency however will use its own set of test data for certification.

6.2 Security and Implementation Audit

Security Audit will be performed after User Acceptance Testing as per the Security Requirements in
the RFP. TPA is also going to do a security audit of software solution and entire configuration including
data centre.
For security testing of the solution, TPA will do penetrative testing. TPA will use it own security and
penetration testing tools.
Issues raised by TPA will be fixed by Bidder in the time frame agreed and entire solution will again
be tested for Security, functional and performance requirements.
In this the MG NREGS, RDPR DEPT may constitute a committee or commission a third party or ask
the Bid Winner to have the certification (Security and Performance) from among relevant vendors
empaneled by e-Governance Dept, Govt of Karnataka or relevant vendors empaneled/approved by Dept
of Information Technology, Govt of India for/after Go-Live (Module Wise and Overall). All the changes
desired by the certification process shall be implemented by bidder free of cost and within a deadline
provided by MG NREGS, RDPR DEPT. The audit shall

be done, as per the decision of MG NREGS, RDPR Dept, concurrently for each Software Module
separately or more than one Modules taken together.

6.3 Legacy Data Migration and Backup mechanism Compliance

Review
TPA will check the compliance regarding availability of legacy data from manual system. TPA will also
check the backup and restore mechanism and its effectiveness. TPA will conduct a backup and restore
operation to check the compliance.

6.4 Other Compliances

MG NREGS, RDPR Dept may audit the various documents like training material, user guides,
administration guides for its effectiveness and quality.
Over and above MG NREGS reserves the right to check on its own or use any other mechanism for
ensuring the compliance mentioned above.

Section 7: Payment
Terms
and
5 shall beSchedules, Service Level Agreements,
solution cost
of
decided by the
Modules (i) to (xii)
Conditions MG NREGS,
(see Price Bid) shall

RDPR Dept as
be divided
7.1 Definition of FINAL
Acceptance
Testing
per Scope
of
equally among 12
Work and SRS
software Modules
Final Acceptancedocument.
Testing isThe
date after complete deployment/implementation, rollout,
(see price bid
for Training to 100 Master Trainer as
User Acceptancepayments
Testing and
per scope of work.
Module (i) to (xii))
hardware,
Security and Performance Testing will be conducted as part of Final Acceptance Testing.
for delivery of
serveris GO-LIVE for Application. The MG NREGS,and
Final Acceptance Testing
RDPR Dept, reserves full right
this
Milestone
for
application
to accept and go ahead
with Module-Wise
Roll Out. In case this is done then GO-LIVE shall mean
supplies
(as per
each of 12
Module-Wise Go-Live.
The
Module Wise Go-Live or Roll-Out shall beModules,
for single the
or more than one
SRS) to
meet
Module at a time the
of MG NREGS, RDPR Dept, shall be final
in
this
regard.
specific
the decision
requirement
payment shall A
be
order by MG NREGS,
RDPRnoDept,
mentioning
the
specific
of point
5 for Module Wise Roll Out/Go Livemade
@30%
shallshall
be @50%
Modules Going Live
be mandatory pre-condition for such a Roll-Out/Go
Live.15%
The payment
(including
of
the
quoted
schedule mentioned hereunder shall be read accordingly.
already paid) of
cost. The rest of
7.2 Payment Schedules
equal-cost of the
the payment for
maintenance
said Module.
the same shall
must
be
7
Complete
Rollout
T0+
150
80% of total
be AFTER
notified
at
(Go-Live)
of
full
software solution
successful Pilot
demonstration
Softwar Solution
least three cost (including 30%
and UAT
working daysalready paid on any
compliance (if
in advance. specific Modules)

* S.No.
In case the Bid Winner Milestone
is able to deliver successfully
Upper Timelimit
8 mile-stone ahead of the
Successful
T0+ 150
any
deadline asTraining
fixed above
(Days)
Completion
for
100
7.5 Notices
then
1 the Bid Winner shallContract
be eligibleSign-off
to immediately
T0
Master
Trainers
2
SRS
Document
T0+
20
receive payment corresponding to the milestone
Finalisation
successfully delivered irrespective
of the timeline or
3 elaspsed since T0. This
Finalization
User T0+
time
shall not beofapplicable
to 35
Acceptance
Test
item no 9, 10, 12 and 13 which will be paid strictly as
Remaining Training Go-Live to
9 timeline stated in these
Document
per
points.
(from Go-Live to until Completion of
4
Customization/Dev
T0+ 90
completion of
elopment
ofbe at sole Training
# Roll Out of individual Modules
training shall
completion
Application
All as
discretion of MG NREGS,
Dept.
forRDPR
Master
Trainers
Modules
perDelivery
Scope of Work)
7.3
Penalty for Late
5
Pilot DemonstrationT0+ 100
Time will be the essence
of the
& Approval
of contract
and of this work as MG
NREGS,
RDPR Dept
Software Solution
MG NREGS, RDPR Dept
meet very
withhas
UATto(Moduletight time and delivery
deadlines,
therefore,
Wise)
timely delivery and adherence to delivery
schedule is essential part of the
requirement of successful implementation.
10 successful adherence
Three Months
Roll
Non
to timefrom
limits(Complete
of
Complete
Roll
Out
Out
)+
90
Days
delivery as stated in this bid document,
point5,no
7) result
and; in particular, in(see
Section
shall
in declaring the work unsuccessful and
closure of the contract for breach of
contract condition without any financial or
cost liability to MG NREGS, RDPR Dept.
11
The Hardware and
This is without prejudice
to other
remedies under
Server
Application
the Contract including deducting
softwarefrom
will the
be Contract
paid
as per
Price, as liquidated damages,
anyactual
losses delivery
suffered by
pertocontract.
MG NREGS, RDPR Deptasdue
omissions and
6
Module
Wise
Roll- T0+150
However,
the MG
commissions of the Bid Winner.
Out
of
Individual
NREGS, RDPR Dept
Modules
shall not #
accept any

7.4 Scheduled Maintenance

such delivery before

Six hours of scheduled maintenance

successful will be allowed
completion
of point
every month. The scheduled
maintenance
shall only be
no
5
except
for
carried from 11 PM to 5 AM. The scheduled
meeting
requirements of point

Payment Due*
85% of total
software solution
NIL
cost (not to be paid
NIL
before Go-Live)
(including 80%
NIL
already paid)
Payment shall be
done on-prorata
NIL
basis (per batch of
upto 30) on the
cost of training in
the bid.
Any
This
shall
be paid
training batchIn
of
Module-Wise.
more
than
30
will
this sum-total of
be paid extra
on
software
solution
pro-rata
basis
cost of Modules (i)
[(Cost
30 Price
to
(xii) of
(see
batch)X
Bid)
shall(No
be of
trainees)/30]
divided equally
5% of software
among
12 software
solution cost
Modules
(see -price
taking
payment
to
bid Module (i) to
90% of
software
(xii))
and
for
cost
(including
delivery of this 85%
software cost
Milestone
for each
already
paid) the
of
12 Modules,
payment shall be
made @15% of
equal-cost of the
said Module.
This shall be paid
Module-Wise. In
this sum-total of
software

 All notices and other communications under this

contract must be in writing, and must either be mailed
by registered mail with acknowledgement Due. Or
hand delivered with proof of it having been received.
If mailed, all notices will be considered as delivered
after 5 days, of the notice having been mailed. If hand
delivered, all notices will be considered, when received
by the party to whom the notice is meant and sent for.
All notices under this contract shall be sent to or

delivered at
the address as
specified by
the parties.
A Notice
shall be
effective
when
delivered or
on the
Notices

effective date, whichever is

later.

7.6 Master Service

Agreement
MG NREGS, RDPR
DEPT, Government of
Karnataka will sign a
master service agreement
for the terms, conditions,
clauses in the RFP.

Section 8: Intellectual Property, Confidentiality and Legal

Indemnification
8.1 Intellectual property Rights

MG NREGS, RDPR DEPT, Government of Karnataka shall have source code and license rights for
all the application software including source code, configuration files, documentation developed
specifically for the application. However, intellectual property rights for any software
artifact/components available with Bidder prior to application development will remain with Bidder. For
this purpose components included in the solution but available with Bidder prior to this work shall be
clearly indicated in the technical proposal.
Bidder shall submit to MG NREGS, RDPR Dept any changes in code/document/any other software
artefact within one month of such change.

8.2 Confidentiality

Both parties undertake to each other to keep confidential all information (written as well as oral)
concerning the business and affairs of the other, which has been obtained or received as a result of the
discussions leading upto or the entering of the contract
After the entering of the contract the Department and the Bidder shall keep confidential and shall
not, without the written consent of the other party hereto, divulge to any third party any documents, data,
or other information furnished directly or indirectly by the other party hereto in connection with the
Contract, whether such information has been furnished prior to, during or following completion or
termination of the Contract. Notwithstanding the above, the Supplier may furnish to its Subcontractor
such documents, data, and other information it receives from the Department to the extent required for
the Subcontractor to perform its work under the Contract, in which event the Supplier shall obtain from
such Subcontractor an undertaking of confidentiality similar to that imposed on the Supplier under this
Clause
The Purchaser shall not use such documents, data, and other information received from the Supplier
for any purposes unrelated to the Contract. Similarly, the Supplier shall not use such documents, data,
and other information received from the Department for any purpose other than the design, procurement,
or other work and services required for the performance of the Contract.

8.3 Limitation of Liability

Except in cases of gross negligence or willful misconduct
neither party shall be liable to the other party for any indirect or consequential loss or damage, loss of
use, loss of production, or loss of profits or interest costs, provided that this exclusion shall not apply to
any obligation of the Supplier to pay liquidated damages to the department and
the aggregate liability of the Bidder to the Department, whether under the Contract, in tort, or
otherwise, shall not exceed the amount specified in the Contract Price.

8.4 Force Majeure

The Supplier shall not be liable for forfeiture of its Performance Security, liquidated damages, or
termination for default if and to the extent that its delay in performance or other failure to perform its
obligations under the Contract is the result of an event of Force Majeure.
For purposes of this Clause, Force Majeure means an event or situation beyond the control of the
Supplier that is not foreseeable, is unavoidable, and its origin is not due to negligence or lack of care on
the part of the Supplier. Such events may include, but not be limited to wars or revolutions,earthquake,
fires, floods, epidemics, quarantine restrictions, and freight embargoes.
If a Force Majeure situation arises, the Supplier shall promptly and no later than seven days from the
first occurrence thereof, notify the MG NREGS, RDPR DEPT in writing of such condition and the cause
thereof. Unless otherwise directed by the Department in writing, the Supplier shall continue to perform
its obligations under the Contract as far as is reasonably practical, and shall seek all reasonable
alternative means for performance not prevented by the Force Majeure event
The decision of the Department with regard to the occurrence, continuation, period or extent of Force
Majeure shall be final and binding on the Supplier.

8.5 Public Disclosure

All materials provided to the MG NREGS, RDPR DEPT by bidder are subject to Country and Karnataka
public disclosure laws such as RTI etc.

8.6 Disclaimer
Department reserves the right to share, with any consultant of its choosing, any resultant Proposals in
order to secure expert opinion.

Section 9: Disputes and Law

Settlement of Disputes
The Purchaser and the Supplier shall make every effort to resolve amicably by direct informal
negotiation any disagreement or dispute arising between them under or in
connection with the Contract.
If the parties fail to resolve such a dispute or difference by mutual consultation within twenty-eight (28)
days from the commencement of such dispute and difference, either party may require that the dispute
be referred for resolution to the formal mechanisms, described below (The date of commencement of the
dispute shall be taken from the date when this clause reference is quoted by either party in a formal
communication clearly mentioning existence of dispute or as mutually agreed) :
a. The mechanism for resolution of disputes for bidders shall be in accordance with the Indian
Arbitration and Conciliation Act of 1996. The Arbitral Tribunal shall consist of 3 (Three) Arbitrators.
Each Party shall nominate an Arbitrator and the two nominated Arbitrators shall mutually agree and
nominate a third Presiding Arbitrator.
b. The Arbitrators shall necessarily be retired High Court Judges
c. The place for arbitration shall be Bangalore.
Governing Law
The Contract shall be governed by and interpreted in accordance with the laws of the India. The High
Court of Karnataka at Bangalore and Courts subordinate to such High Courts shall have exclusive
jurisdiction in respect of any disputes relating to the tendering process, award of Contract and execution
of the Contract.
In all cases, this contract shall be governed by and interpreted in accordance with the Law of the Union
Of India. In this context, the expression Law takes within its fold Statutorylaw, Judicial Decisional
Law and Delegated Legislation as well

Section 10: Exit and Handover

Termination of Contract
Termination for Default
The Department may, without prejudice to any other remedy for breach of Contract, by Notice of default
sent to the Supplier, terminate the Contract in whole or in part:
if the Supplier fails to deliver any or all of the Goods or Related Services within the period specified
in the Contract, or within any extension thereof granted by the Department.
if the Supplier, in the judgment of the Department has engaged in corrupt, fraudulent, collusive, or
coercive practices
Any representation made by the bidder in the proposal is found to be false or misleading
if the Supplier commits any breach of theContract and fails to remedy or rectify the same within the
period of two weeks (or such longerperiod as the Department in its absolute discretion decide) provided
in a not in this behalf from the Department
Consistently not meeting the SLAs as defined in this RFP.

Termination for Convenience

The Department, by Notice sent to the Supplier, may terminate the Contract, in whole or in part, at
any time for its convenience. The Notice of termination shall specify that termination is for the
Departments convenience, the extent to which performance of the Supplier under the Contract is
terminated, and the date upon which such termination becomes effective
The Goods that are complete and ready for shipment within thirty days (30) days after the Suppliers
receipt of the Notice of termination shall be accepted by the MG NREGS, RDPR DEPT at the Contract
terms and prices. For the remaining Goods, the MG NREGS, RDPR DEPT may elect:
To have any portion completed and delivered at the Contract terms and prices; and/or
to cancel the remainder and pay to the Supplier an agreed amount for partially completed Goods and
Related Services and for materials and parts previously
procured by the Supplier

Consequences of Termination
Upon Termination of the Contract, the Supplier shall
Prepare and present a detailed exit plan within five calendar days of termination notice receipt to the
designated individual in the MG NREGS, RDPR DEPT.
The designed individual in the MG NREGS, RDPR DEPT and along with designated team will
review the exit plan. If approved, Supplier shall start working on the same immediately. If the plan is
rejected, Supplier shall prepare alternate plan within two calendar days. If the second plan is also
rejected, MG NREGS, RDPR DEPT will provide a plan for Supplier and it shall be adhered by in
totality.
The Exit Plan shall cover at least the following :-

 Execute all documents that may be necessary to effectively transfer the ownership and title, including
OEM warranties in respect of all work
Handover all developed codes, related documentation and other Configurable Items, if any in his
possession;
The supplier will sign a completion certificate at the end of successful completion (all points tracked to
closure) of the Exit Plan
At end of three years contract period a similar exit plan needs to be worked out. In that case timelines
can be as per mutual convenience but within the last ninety (90) days of expiry of support period.

Annexure -A
Visit URL
www.nrega.nic.in
for copy of National Rural Employment Guarantee Act, 2005

ANNEXURE-B

Visit URL
www.nrega.nic.in
for MG NREGS Rules, Operational Guidelines, Unemployment
Allowance Rules -

ANNEXURE-C
Functionl Requirement Specifications
(read with Annexure-J)
for
Web Based Application for MG NREGS A Module Based Process Automation through end-to-end Web
Solution

The following pages captures the essential requirements that a software solution shall fulfill in order to
effectively implement the mandate of the MG NREGS. The Annexure-J which contains the Proof of
Concept Write-Up covers in details how the software solution is expected to deliver the
functionalities.
It is visualized that the software solution shall be a very effective web based application, with strong
application and user support. It is envisaged that down the years potentially on-line user could touch
50,000
The software solution should be able to capture data (at present close to 15000 public servants a figure
which will increase with increase) and operationalize the data so that tracking of each MG NREGS
aspect is achieved real-time or close to real-time. The details in this regard are given below.
The reports shall be generated as per need; in addition to that, default regular reports shall be created as
per the Act, Rules and Annexure A&B attached herewith. Apart from these reports the software solution
shall also create a Query Builder which will allow intelligent query building at the level of users of the
solution.
The response time and SLAs from the software solution side on these reports and queries shall be as per
Annexure-H.
The State of Karnataka has Karnataka State Wide Area Network (KSWAN) and State Data Centre with
appropriate approvals the same could be put to use for the purposes of the MG NREGS, RDPR DEPT.
SYSTEM REQUIREMENTS
The proposed solution should have service oriented architecture.
Software should support data exchange with external systems using XML based web services.
USERS of the SYSTEM
The focus of the work of MNREGA is Village and Gram Panchayat. There are 5627 Gram Panchayats,
176 Taluks, 30 Districts and One MG NREGS.
At least three to four users at Gram Panchayat Level needs to be supported.
Total Expected Users in the System : 20000
Out of 20000, at least 15000 are going to have digital signature support in the system.

Digital Signatures are procured and distributed by MG NREGS itself but for those 15000 users digital
signature support will be required at different steps of the workflow.
The architecture and design of the system is such that it should support the scale which is mentioned
above.
DATA EXCHANGE REQUIREMENTS
All the data exchange of the proposed system to another system is going to happen through XML based
web services. These web services may be used over encrypted channels.
SYSTEM REQUIREMENTS
THE PROPOSED SYSTEM SHOULD WORK IN BOTH ONLINE AND OFFLINE MODES.
ONLINE MODE OPERATION
The desired system is a centralized web based system having accessible over internet to Browsers.
OFFLINE MODE OPERATION REQUIREMENTS
There are 5627 gram panchayats in Karnataka. A lot of them has internet connectivity issues and a few
of them has intermittent internet connectivity. The desired software is a web based centralized software
system.

Software System for Gram Panchayats having No Internet Connectivity

The software should have a client which can be installed independently on the Gram Panchayat
computer. The client should be self sufficient it means there should be a single installer having all the
components if required of database, application server and software. The client should almost having
zero configuration required to install and run the application. This is one of the critical requirements
since at gram panchayats level technical know how to resolve the technical issues of installation and
the system is going to be single window of all MNREGA related works.
The installation of software will just require putting the Gram Panchayat code and Digital Signature of
Gram Panchayat.
This piece of functionality is included in the scope of work and no additional payment will be done for
this piece of work.
Synching of Data to Central Server

The synching process should be able to sync to the central server. The data should be extracted digitally
signed which can be synched to a taluk or district office at any interval of time. The system should have
capability to take care of multiple sync/duplicate sync.
At central server level there should be a detailed encrypted logs of the synching process.
Software System for Gram Panchayats having Intermittent network connectivity
System should support disconnected offline mode of operation whenever internet connection becomes
available, the data should automatically sync with the central server. This process should be almost
without any manual intervention.
System should keep detailed encrypted logs of the synching process.
Multi-Language Support
System should have support for Kannada language for all the masters, transactions and reports. Kannada
Language specific keyboard may be supported to provide this functionality.
MODULE WISE FUNCTIONAL REQUIREMENTS
THE FUNCTIONAL REQUIREMENTS MENTIONED IN THIS DOCUMENT ARE
INDICATIVE ONLY. THE SOLE PURPOSE OF PROVIDING THIS FUNCTIONAL
REQUIREMENTS ARE TO HELP AND GUIDE THE PROSPECTIVE BIDDERS IN THEIR
BID PREPARATION.
THESE REQUIREMENTS WILL PROVIDE A BROAD FRAMEWORK DURING AS IS AND
TO BE PROCESSES. AS IS AND TO BE DOCUMENTS ONCE PREPARED BY BIDDER AND
APPROVED BY MG NREGS WILL FORM THE BASIS OF SOLUTION DELIVERY.
The number of MIS reports shall be as mentioned in Scope of Work

Finance and Accounting

CASH BASED AND ACCRUAL BASED ACCOUNTING SUPPORT
The proposed system should support both Cash based as well as Accrual based Accounting.
Finance and Accounting module of MG NREGS is on similar lines of Government
Accounts/Government owned PSU/accounts of Government of Karnataka. So the software must
have the features for finance and accounts control for MNREGA.
MNREGA has certain expenditure controls like only 6% of total expenditure can be on administrative
expenses.

Any change in rules/policies and procedures in the accounts should be implemented within thirty days of
intimation.
Account Head Support
To categorize and control the flow of fund and expenditure the software application
must support hierarchical account code.
Applicability of Accounting Head:
An accounting head may be applicable at certain level of accounting unit [MG NREGS, Zilla Panchayat
Accounts, Taluk Panchayat Accounts, Gram Panchayat Accounts].
This applicability may be enforced for a particular period.
Accounting Units
There are 5627 Gram Panchayat in Karnataka. For the effective management of finances each of these
gram panchayats can be treated as Accounting Units.
This implies monthly trial balances of the gram panchayat should be prepared as per double entry
government accounts norms.
Taluk Panchayat Trial balances should be its own trial balance of the month plus sum of trial balances
of the lower level accounting units which are gram panchayats.
Zilla Panchayats On the similar lines of Taluk Panchayats, zilla panchayats trial balances should be
zilla panchayat its own trial balance and jusridictional taluk panchayat trial balances and gram panchayat
trial balances.
MG NREGS Level Accounts At state level trial balance will be States own trial balance and
consolidation of trial balances of 30 districts, 176 Taluks and 5627 gram panchayats.
These consolidated accounts will form the accounts of MNREGA Accounts.
The trial balance preparation at any of the above mentioned accounting units shall be as per accounting
principles of accrual and cash based accounting. As stated above both accrual and cash based methods
needs to be supported.
These trial balances or monthly account preparation should be as per the established accounting
practices of Journal Voucher Preparation, Audit Support and Posting to General Ledger
Cash Book Management
Cash Book functionality needs to be maintained from GP Level to State Level.

Software should have a provision to close the cash book daily, weekly, fortnightly/monthly. The closure
of cash book should be digitally signed. Once a cash book is closed no entry/adjustment entry can be
permitted to the cash book.
The cash book should have provision to support both Cash and Bank Transactions.
MG NREGS is in the process of shifting for most of its electronic payment direct to account using
EFMS system from central account. In case of such payments still the cash book at GP/Taluk and
District level needs to be updated with a virtual entry and tag that this update is due to payment at State
level.
Balancing and for payments related to EFMS the cash book should be properly updated.
All the cash book entries should be properly supported by vouchers.
The software should have provision to navigate from cash book to original source documents. All the
accounting documents and workflow can be navigated from the cash book to the original source
documents.
Software should be able to provide cash analysis as per Government accounting norms before posting to
General Leader of the Gram Panchayat.
Bank Accounts Related Functionalities
Each beneficiary in the MNREGA is either having a bank account or is going to have a bank account.
Additionally bank accounts are maintained at
Gram Panchayat Level
Taluk Panchayat Level
Zilla Panchayat Level
Most of the payments are going to happen through EFMS (E-Payment directly to bank accounts), still
few of payments are going to happen through cheque book.
The software should have provisions for
Bank Account Management, Cheque Book/leaf Management, Cheque Management.
Bank Accounts Reconciliation:
Software should have provisions for Account Reconciliation for all three modes
- online (means integrating to bank either through XML based web services or ftp based data backup)
- Excel or CSV based file upload

- Manual reconciliation each cheque by cheque reconciliation

The complete history/logs of reconciliation including failures should be available and should be
encrypted.
Further, now, there is a special eFMS system of payment by GPs and other Implementing Agencies
under MG NREGS. In this system a single pooled central account at the district level is used for
payment of bills of GP and other Implementing Agencies. The GP and IAs trigger payments from this
single pooled bank account electronically through use of DSC/PKI. The accouting and cash book writing
shall adequately take care of this. The software solution shall also full integrate with this eFMS system
of NICs NregaSoft.
In future, UID/Aadhaar based payments will become the standard payment method of MG NREGS, and,
the software solution shall fully support and integrate with the same.
Expenditure Control and Management
Software should support expenditure accounting for all accounting units from the Gram Panchayat, taluk
panchayat, zilla panchayat to MG NREGS.
Software should allow head of account wise and Accounting Unit wise (Lowest one is Gram Panchayat)
expenditure controls to be exercised. Detailed Account head wise comparison between different
accounting units in a particular time period/over a particular time period is required for prudent financial
control and better fund utilization.
For all project oriented expenditures of MNREGA the upper limit for which expenditures can be
permitted is sanctioned cost. Software should enforce this limit
Software should allow particular Head of Accounts Association with a particular type of Bills.
As soon as a bill is accepted in the system it should automatically prompt a single Head of Account/a
group of Accounts to be associated with the bill.
System should provide a mechanism to provide a checklist associated with the bill.
System should allow checklists to be associated with the workflow steps.
System should also have a provision to associate a workflow with a particular bill.
System should have a provision for a particular step of workflow to be digitally signed.
System should allow workflow steps to be defined in such a way that few steps of workflow may cross
Accounting units i.e. one step of a workflow may be executed at Gram Panchayat and next step of
workflow may be executed at Taluk Panchayat or Zilla Panchayat level or even MG NREGS.

Software should allow preconditions to be associated with a particular step of the workflow.
Software should have provision to track the status of a particular bill through the workflow steps.
Software should have a provision for pre-audit and post-audit of the bills.
The software should have provisions to be integrated with IVR (Interactive Voice Response) solution for
tracking of the status of the bill.
Definition and Association of Rules
Software should have provision for definition of expenditure rules. The provision should be such that
rules can be defined at user level and they may be enforced at any of the accounting unit level or even
project level.
SUPPORT OF FIFO
In passing the bills FIFO violations reports needs to be generated.
Fund Management
Requisition of Funds:
Software solution should provide requisition of funds from one Accounting Unit (Gram Panchayat,
Taluk Panchayat, Zilla Panchayat, MG NREGS) to another account (any one of the above).
The fund requisition should always accompany the bills for which funds has been requisitioned.
Software should have provisions for selecting the passed bills for which funds can be requisitioned.
When the fund requisition comes the requisition itself should show the amount pending in accounts
and the account heads under which they had been kept.
Relevant accounting records/vouchers needs to be generated for support and posting should happen in
relevant books of accounts.
Fund Release Request from MNREGA to Government of India
There are expenditure limits and other rules which needs to be complied before fund requisition can be
made to Government of India.

System should be able to define these conditions and once these conditions has reached should have
provision to create the fund requisition requests to Govt. of India.
If there is any shortfall in expenditure taking into accounts various ongoing projects, pending bills
the system should be able to identify where the works or passing of bills needs to be expedited for
meeting the work completion or financial utilization criteria.
Fixed Asset Accounting
The primary purpose of the MNREGA is the creation of employment in the village. In the process of
implementation of Projects fixed assets (whether new/repair/remodelling) gets created.
The system should have a provision to generate Work in Progress Accounts for an ongoing Project to
account for work in progress. In MNREGA there are close to two lakhs ongoing projects. So two lakhs
work in progress accounts needs to be maintained. These work in progress accounts should contain all
the relevant details of material and labour expenditure.
Again the work in progress accounts needs to be aggregated from Village, GP, Taluk, District and MG
NREGS.
Once the ongoing peroject is completed, the asset categorization should happen as per the accounting
rules for transfer of work in progress to the fixed assets. This is at this point fixed asset register comes
into picture.
The software system should support fixed asset register, depreciation of assets (this is going to be
notional in case of MNREGA but still for purpose of evaluation and effectiveness of scheme) and the
assets created over a period of time. These assets may be categorized into various groups.
Audit and Certification of Accounts at Gram Panchayat Level
System should have feature for certificate of acceptance of monthly accounts of Accounting Units
(GP/Taluk/ZP/MG NREGS and a work flow needs to be associated with that.
The system should have provision for back tracing from Monthly Accounts to Accounting Statements To
Vouchers to Original Source Documents. Web based linkage support must be provided for the same.
System should also provide the mechanism for definition of types of expenditures for which pre-audit
and post-audit must be done.
It should also have a provision where for a particular accounting unit each of the expenditures must be
audited.

Stores, Material Management and Procurement

Schedule of Rates:
MNREGA projects require 60:40 ratio of labor and material expenditure.
Definition of Schedule of Rates
Schedule of Rates can be defined at MG NREGS Level and District level.
MG NREGS takes Karnataka Public Words Department Schedule of rate as its schedule of rate.
If an item is available both at State level as well as District level for preparation of estimate in that
district schedule of rate defined at that level will take precedence.
Schedule of rate should be defined at the lowest level of item/labour cost. This is required in the case
that let us say in case of revision of minimum labour charges - all the schedule rates where this labour
rate is defined should be changed automatically.
Software should have provision for keeping multiple revision of schedule of rates. The history of
revisions in schedule of rates should be maintained item wise.
Stores Support
Each of the projects where there is a material component this material needs to be purchased,
sometimes stored and then released to the project. (In MNREGA there is a provision for 60:40 ratio of
labour and material component).
All the store related transactions like Receipt of Materials, Issue of materials, Invoice, Ack, Return
Invoice needs to be supported.
Procurement Management
The procurement management module should support all the procurement from GP level to MG
NREGS level.
A valid purchase order needs to be there for receipt of materials for use in the MNREGA projects.
The software should have provision for defining procurement entity. There are different procurement
powers available at different level of authorities in GP, Taluk, Panchayat and MG NREGS.
Software should have provision for procurement on
- Single Source Selection
- Under limit of one lakh and five lakh powers

The relevant provisions of procurement should be implemented in the software.

The actual bidding process in the Government of Karnataka happens through the E-Procurement portal
of Government of Karnataka.
Software should have a provision to provide all the the relevant steps in the procurement Process (other
than the bidding process which happens through E-Procurement Portal of Government of Karnataka).
The system should automatically be able to create purchase requisition against an work order/estimate
and then through proper procurement rules (as per KTPP act).
Delegation of Power Support for Purchase
Software should have provision for defining the delegation of power and enforcing while approval of
purchase requisitions.
The software should be able to implement workflow and while approval of purchase requisitions should
enforce the delegation of power.
In case of tender purchase/quotation purchase the inviting and accepting authority should be defined.
All through this process the work order, estimation, accounting unit should be properly tagged through
this process.
Purchase Order
The software should be able to create purchase order through the system. The purchase order should be
able to define all the relevant details like delivery location in the case of MNREGA projects this can be
actual work execution location. It is also possible to define multiple delivery schedules depending on the
progress of execution of the work.
System should have provision to terminate the purchase order.
Modifications/Cancellation in Purchase Order
System should have provisions for modifications in purchase order. The modification of purchase order
should be able to update the relevant fields of quantity, delivery date and location.
All the modification and cancellations in the purchase order should happen through the proper
government procedures and relevant work flows must be associated with that.

Receipt of Materials
The receipt of materials during execution of work or in case of services purchase by Taluk/District/MG
NREGS can happen only against a purchaser order. The relevant records like Material Purchase Note,
Invoice should be automatically generated by the system.
Material Receipt note also should have provision for recording the accepted quantity.
Three way Matching while Passing Material Purchase Bills
All the material purchase bills should be matched three way for
Bill itself
Purchase Order
And the Material Receipt Note with accepted material quantity
Issue of Material for work execution
Issue of material happens against a work order which gets created against an approved estimate.
Software should support creation of multiple material issue requests against an approved work order.
The items sanctioned in the work order is the upper limit of the requisitioned materials.
In case the work order gets modified through a supplementary work order/supplementary estimate the
new revised limit should be enforced.
Stores Associated with the GP
The majority of work execution in MNREGA is at Gram Panchayat Level. It is quite usual to have
multiple work executions going on at same time.
There may be physical storage of material at single location or scattered through out the gram panchayat.
For monitoring and work execution purchases the software should be able to treat all these scattered
MNREGA work locations as racks/bins in a virtual store where the material is stored.
This will allow to show the material position at any moment of time and it is possible to see the work
order wise stock/inventory positions.
The work in Progress accounts should be updated with respect to unused material/disposal of material
and diversion of material to another work projects.

Work Execution Management System

The main input to the work execution Management Systems are approved projects for Gram Panchayat
and in case of inter-panchayat works taluk panchayats
The technical estimates of the project will be prepared for each of these approved projects.
The number of projects for which the technical estimates needs to be prepared will be capped by the
anticipated labour demand.
IN A GIVEN YEAR THERE ARE GOING TO BE THREE LAKHS ESTIMATE IN THE
SYSTEM. WITH THE INTRODUCTION OF NEW SYSTEM IT IS EXPECTED THAT
NUMBER OF ESTIMATES WILL RISE SO THE SYSTEM SHOULD BE ABLE TO
SUPPORT CLOSE TO 15 LAKH ESTIMATES ANNUALLY/At-a-given-time.
Template Driven Estimate Preparation
Except for few cases most of the estimates will be template driven. The templates of the estimates will
be provided by MG NREGS.
For field related work the technical estimate will capture the physical location (latitude, and longitude)
of the work. In case photographs need to be taken the estimate will also capture the photograph which
will be time stamped and geo-tagged before start of the execution of the work.
Mobile Devices Support While Preparing Estimates
For locations where there is no issue of mobile phone signals the estimates will be prepared using the
mobile handsets and data update at central server will happen instantly.
In these cases the mobile handsets itself will capture the GPS location as well as geo-tagged and
timestamped photos.
Minimum Handsets which needs to be supported will be: Nokia and Android based handsets. Any other
device support will be over and above this.
Availability of Templates on the Mobile Handsets
Estimates are going to be prepared using templates. These templates should be available on the mobile
handsets.
The templates which are applicable to the works approved at GP Level/Taluk level corresponding to
that village is only going to appear on the handsets.
During estimate preparation the details (GPS, Geo-tagged and time-stamped photographs) will be
captured on the mobile devices directly and sent to central server.

Estimate Preparation using GPS Specific Devices

In situations where no mobile signals are present the details will be captured on the device itself.
The devices/exported data out of devices will be brought to a location like GP/Taluk where internet
connectivity is there and the exported data should be uploaded in the system through a single click. This
should immediately become available on the central server and populate the GIS layers.
Mobile Devices/GPS Specific Devices will be provided by MG NREGS. Supply/Purchase of the mobile
handsets and GPS devices are not in the scope of work.
Real Time Tracking of Estimates Preparation at MG NREGS
The estimate preparation and progress can be tracked real time on the Google Map/ any other provided
mapping platform at the MG NREGS.
The software should be able to create different layers corresponding to Estimates completed/Estimates
started/Works completed/Works under Execution
The software should also have provision to create layer for different categories of work.
Integration of Schedule of Rates
The entire estimate preparation step will be integrated with schedule of rates as mentioned in the
inventory and store management software.
Roughly the entire process of estimate preparation will be completed on the mobile handsets. These
schedule or rates should automatically get picked up on the mobile handsets. They should not be entered
on the mobile handset.
Approval of Estimate
Approval of estimates should be done through a workflow process. The workflow in turn should be
guided by the delegation of power specific to the category of work.
At last step of the sanction of the estimate it will be digitally signed.
For material drawal/purchase and bill approval the estimate is going to be the upper limit.
Supplementary Estimates
In case the labour/material requirement at the field execution time came out to be larger than the
estimate the supplementary estimates needs to be prepared. The approval process will be same as
original estimate.
The original estimate and supplementary estimate will always be tagged to each other and usage of one
will show the linkage to the other estimate.

Execution of Work
Demand of Job
Execution of work in the proposed system can be trigged by a number of method
(a) Job Seeker calls the centralized call centre, provides his job card number and demands for job. (This
is oral request)
(b) Job Seeker approaches the GP and applies demands for the job (paper based request).
Job Seeker module at this point should connect with the SMS module to notify the GP as well as the job
seeker about the status of demand of job.
To make the system more effective and useful it is desired that the job seeker will tell its taluk and
village name and his own name or job card holder name.
Software should be able to search the database and pop up at call centre the recommended names. The
call centre is going to select one name out of the listed out names. The search having mistakes in names
needs to be supported in the module.
The software should automatically route the job card application to the corresponding Gram Panchayat.
System should assign the work to the job seeker
(a) In case of executing work it will be assigned one among the available
(b) In case 10 people demands are there and it not possible to assign the job, a new work for which
technical estimate is approved.
If none of the above matches the request for job application should be routed to Taluk Panchayat office.
e-Muster Roll shall be issued under signatures of Programme Officer (EO TPS) for the labourers and the
e-NMR has a specific number and validity for 15 days.
Execution of Job
Execution of jobs happens at village level. The software should automatically trigger the required
sequence of activites of material drawal schedules etc.
Work in Progress Data
The software should be able to take work in progress tables where entire financial progress as well as
physical progress can be seen. All expenses related to labour/material and relevant details can be seen at
single place.

eMB: E-Measurement Book

(a) The software should support E-Measurement of the execution of work.
(b) Intermediate as well as final measurements will be taken in the filed by the concerned officer using
the mobile handsets/GPS devices whichever will be applicable.
(c) The measurements parameters should be entered on mobile devices/GPS devices in the field itself
which later on gets uploaded on the server.
(d) Once at the central server this measurements are going to be digitally signed. This digitally signed
eMeasurement Book will form the basis of final payment/intermediate payments.
(e) The closed eMB should be available on mobile for usage for inspection social audit/third party
monitoring etc.
Integration with GIS Module
The eMeasurement Book should automatically integrate with the GIS module.
Integration of Payment Module of Finance and Accounts
The photos geo-tagged and stamped will form the basis for bill payment and will automatically flow to
the Bill Payment module.
Planning Management System
The MNREGA is a demand driven project and the central assistance is based on the projected demand of
labour from Karnataka. The projected demand of labour is obtained through annual labour demand
planning.
The basic unit of planning is village itself. There are close to 30000 villages, 173 taluks and 30 districts
in Karnataka.
The planning process mandated by MNREGA, Govt. of India is a bottom up planning the software
should support bottom up planning from Village, Gram Panchayat, Zilla Panchayat and State
Government. Bottom up planning means the labor demand, cost, timing and schedule of demand and
benefits will be planned at village level and then will be aggregated at Gram Panchayat, Zilla Panchayat
and State Government level.
The entire planning process is done in two types of plans
District perspective plans which are five year plans with base levels and yearly target and
achievement of each indicator disaggregated at District, taluk and Garm Panchayat level.

Annual Plan which is the limited to the next financial year only.
For planning and work execution perspective MNREGA has defined categories of works. Software
solution should allow the definition/addition/modification of categories of works. The software solution
should also allow the sub-categories to be defined at Gram Panchayat Level, Zilla Panchayat Level or at
State Government level.
District Perspective Plans
The preparation of district perspective plans are as per the table formats and procedures as per
Guidelines (Annexure-B). The software solution should allow the indicators to be defined, modified and
their progress with respect to yearly/annual plans.
The district perspective plans for five years are prepared through village wise survey. The offered
solution should provide the mechanisms to enter the data post-survey. Once the survey is done and data
is collected the software should have a provision to enter the survey data into the system. These should
be enabled in the Software as per Act and MG NREGS Guidelines.
As per Annexure A & B the software should support one time entry of Panchayat-wise (i) list of
infrastructure already existing and (ii) List of infrastructure that are missing out of the list of
Assets (iii) requirement of resources for creation of missing infrastructure alongwith
programme-wise inflow/share of that Panchayat out of all development programmes,andm (iv)
estimated employment generation in terms of both self and wage employment while creating
missing infrastructure.
After the Software system mentioned in this document becomes operational asset creation
update gram panchayat wise should happen automatically.
Definition of Development Indicators
The offered solution should have a provision for definition of development indicators and year wise
progress of those indicators.
Development Indicators may be defined at Gram Panchayat level which may be aggregated at taluka
level/district level and state level.
Software should also have provision for indicators at taluk, district and even at State level.
Incorporation of Constraints in Planning Process
Software should allow the application/removal of
Constraints like in case of wage employment, number of potential mandays generation from identified
works/activities is to be divided by (Minimum wages (60%) plus material cost (40%) assuming 60:40
wage material ratio ( e.g. if Rs.60 is minimum wage than Rs.

40 be taken as material cost and as such number of mandays be divided by 100 to arrive at number of
persons to be employed.
Constraints like proportion of fund allocation on creation of new assets and maintenance of new assets.
Constraints on Category of Works - Generation of labour for particular financial year in a Gram
Panchayats/Set of Gram Panchayats/taluk panchayats/set of taluk panchayats/Districts/Set of Districts. A
particular category may be disabled or a certain percentage may be forced or distribution of labour
demand under different category of works may be enforced.
There may be additional type of constraints which may be defined or applied.
The constraints may be applied in Annual Preparation of plans or district perspective plans which are
five year in nature.
Annual Planning Process
In all the planning processes of MNREGA, unit of planning is village. The annual plan is a rolling plan,
and approved shelf of projects may carry over from one financial year to next financial year.
Human Resources Management Module
In MG NREGA System there are going to be three types of people
(a) Government of Karnataka Employees
(b) Employees Hired on temporary basis by Government of Karnataka
(C) Employee Posted by different Man Power Agencies
THERE ARE APPROXIMATELY GOING TO BE TEN THOUSAND (10000) PEOPLE IN THE
SYSTEM. The capacity planning for Self Service Portals for both Employee and Manager should
happen keeping in mind these requirements
Employee Self Service Portals
For all the above three categories of users (a), (b) and (c) there are going to be self service portals.
These self service portals are going to be single point of window related to all HR matters.
Leave transactions for all categories and all other transactions like Transfer, Training request can be
managed through the system.
It might be noted that leave rules are going to be different for all three categories. For category A leave
rules of Government of Karnataka applies for (b) and (c) there can be different leave rules.

Manager Self Service Portals

All the employees mentioned above in (a), (b) and (c) which have one or more reporting under their
head must have Manager Self Service Portals.
Reporting Hierarchy Capture
HRMS software should capture the reporting hierarchy of all the 10000 system in the people.
Document Management System and Relevant Data Capture
HRMS system should have a document management system as part of its solution where the relevant
documents can be scanned and stored.
There should be a document explorer to see all the documents tagged with an employee, a manpower
agency.
Attendance Management System
System should have an inbuilt attendance management system. This system should form as a core of
payment in case of man power based payments and leave for all other employee categories type.
The attendance management system should be able to take uploaded data from Bio-Metric attendance
system or other kind of attendance records.
This attendance management system will also be used for payment of labour wages in case of work
execution.
System should be able to integrate with leave module, transfer module and deputation management
module.
Joinning Management System
A large number of people are going to come through manpower placement agencies.
All the joining related transactions needs to be performed in the system iself. The system should assign
an unique ID to every working employee in the system.
DIGITAL SIGNATURE MANAGEMENT SYSTEM
All the employee or set of employees in the all the above three categories are going to have digital
signatures.
Digital signatures are having validity period associated with that.

Digital Signatures are received in quantity at MG NREGS and then distributed to the district offices.
System should capture details of distribution, issue and expiry of the digital signature.
Association of digital signature with Joinning/Transfer/Leave/Retirement/Resignation System
All the relevant transactions of
Joinning
Transfer
Leave
Retirement
And Resignation should trigger the corresponding updates for Digital Signature Management System
module.
PAYROLL Management System
All the category A employees who are Government of Karnataka employees gets salary paid through
HRMS Software of Government of Karnataka.
All other categories of salary payments for (b) and (c) are going to be managed by this software.
The taxes and other deductions for (b) and (c) manpower placement agencies must be managed through
this software.
LEAVE Management System
The software should maintain the leave account of all the three kinds of employees mentioned above (a),
(b) and (c).
These accounts and their application of rules the number of days that can be availed, sequence in
which it can be availed, minimum and maximum taken together should be implemented in the system.
System should have a workflow mechanism which along with the reporting hierarchy should trigger
the sanction of leave.
It may be noted that the sanctioning authority for different kinds of leaves might be different.
Double Wages/Additional Man Power Placements
Software should implement the double wages for first two categories and for third additional charges for
Man Power Placements.

Show Cause Notices/Disciplinary Actions

System should implement show cause actions/disciplinary actions corresponding to all three categories
of employees.
It should be noted that in category (3) man power placement agency the show cause notices will be
issued to the agency directly.
Training Management System
There should be a training management system for the MG NREGS where the training schedules date
of training, people taken training etc. should be maintained and implemented.
Transfers and Joinning
For Category A transfers and joining are maintained in HRMS software of GoK for rest two categories
they need to be implemented in this software.
Grievances/Complaint Management and Ombudsman Module
The software should have
Grievance/Complaint Management and Ombudsman module.
The complaints can be received by
(a) Paper based requests (right from CM office to GP office)
(b) Through a phone call to the Call Centre
(c) Through SMS
(d) Through personal visit to Government offices.
(e) through online filing of the complaint
System should also have a provision to accept complaint on behalf of others.
For effective handling of the system there is a provision of ombudsman in the MNREGA System.
In general an Ombudsman is there at every district level.
Routing of Complaints
Complaints should be routed based on the administrative hierarchy of the MG NREGS
With Every office in administrative hierarchy there should be a provision to tell where the complaint
will be informed and where it will be actually dealt.
Processes Related to Complaint Resolution
All the processes related to complaint resolution like seeking reports from sub-ordinates, marking to
the sub-ordinate offices, mis-sent needs to be supported.
Citizen Feedback System

Along with every complaint resolution there should be a provision of the citizen feedback which gets
automatically tagged to the complaint.
Ombudsman
All 30 districts will soon have Ombudsman who, in turn, a formal authority to examine complaints on
and with respect to MG NREGA implementation. Ombudsman has authority to issue formal orders for
recovery, recommendations for disciplinary action etc. All these will be provided by the Module plus the
orders of Ombudsman will reach proper quarters both physically as well as electronically for follow up
action.
Every Ombudsman is going to have a portal on his own.
Software should have a provision to make this ombudsman portal public.
Call Centre and IVR Support
Software should have provision for at least 50 Call centre executive logins.
There should be specific portal for call centre executives.
Various transactions can be defined on the call centre portal:
Inclusion/Deletion of name in job card
Demand of Job/Work
Complaint Management
Etc.
System should have a provision to configure and say which all transactions are going to be performed as
part of this.
IVR Support
At very basic system should integrate with IVR System for
Grievance ID and Tacking
Job Card ID Tracking
Job/Work Order No.Tracking
Payment Status Tracking
These databases should be integrated with IVR Menu.
Apart from above functional requirements from the software solution. The following technical and other
stipulations shall also be fulfilled by the software solution

System Requirements

Expected Capacity of the System

At its peak operating capacity system is going to have upto 50,000 Users in sometime in future. At any
moment when the system is functional, most of these users will be working on the system (concurrency
of 6000). The scalability of transactions, reports should be designed with this broad requirements.
At application will also be handing upto 55Lakh Job Cards and upto 15Lakh concurrently on-going
works.
Redundancy and High Availability
This software solution is supposed to be a highly reliable and scalable application. The Redundancy is
desired at Hardware level, Database Level as well as Application Level. In case of failure at one server
either software or hardware the switchover of application should be almost instantaneous. All the going
on transactions should be replicated means there should be support for session level replication.
Security
All the certificates issued/services offered should be signed by digital key and application must have
compliance with respect to IT Act.
The developed software should be security audited.
Audit Trail
There should be complete audit trail of the transactions in the system.
Logs
Logs generated in the system should be encrypted with a digital key.
SMS based Decision Support System
Application should accept the workflow updates and route the application as per the SMS sent by cases
workers at different stages of the workflow.
Also the status of the works/complaints and other process etc. can be queried through an SMS just like
PNR enquiries are done through SMS.
IVRS Support
Software should automatically connect to IVRS system for automatic dialling on the phone number in
database of the Officers & sub-ordinates. The provisioning of menu system for navigation of IVRS
should be available.
Designated officers and their sub-ordinates should be able to update the work/complaint status as well as
give reports through IVRS navigation system.
Document Management System
To effectively index and manage all the scanned documents coming as part of work/complaints and
other processes connected with MG NREGS, an effective document management system should be in
place for indexing, cataloguing of the documents
Query Builder
Taking various parameters of application, approval etc. the application should provide a query builder as
part of it. The generated reports should be HTML based with printer friendly print version/options and
navigable.
Virtual User: The Superior Officers/Officials shall have ability to be the Virtual User for all levels
administratively subordinate to him. This is essential so that a senior officer can see and go into details
whatever his subordinate can see/do. While this should be Guided touring, the Superior Officers shall
not be able to do transactions/decisions/changes (unless the same happens to be his responsibility) but
only fully view them.

Functional Requirements

Self Service Portals for

Case Workers & relevant Public Servants
EO TPS,
CEO ZP
State Level
Self Service Portals means home pages where works/complaints and other details of MG NREGS
processes can be opened online. This home page should be navigable through the breadcrumbs and other
means.
Service Delivery Counters
Software should be able to provision appropriate counters. The number of counters can any time be
increased or decreased by the department. There should also be timing restriction to prevent
unauthorized use. This timing restriction should be flexible and can be increased or decreased as per the
requirement.
Protocol/Standards Compliance
The solution shall be compliant with National Portal Framework and E-Governance Standards as
laid down in http://egovstandards.gov.in/

Other Deliverables:
Solution Provider Deliverables:
Herewith is the list of deliverables
1. Architecture (Scalable Solution proposal/POC, Technical Architecture)
2. Well written , Documented, Reviewed ,Unit Tested & Maintainable Code as per the Industry Standards
3. Project plan for each release
4. Status Report /Progress Dash Board/Communication Plan (In a format & frequency mutually decided)
5. Non-Functional Specifications & Boundary Conditions (Beyond of which either application may FAIL OR NOT
perform up to the mark)
6. Single POC (who can take decisions & will communicate/co-ordinate between customer / representative & vendor)
7. Complete Deployment Diagram of the Hosted Solution ( with hardware stack & software details) along with Go-live
support details
8. Static UI/Screen Diagrams ( To get approved by the customer)
9. Project Process documentation (RUP/Agile SCRUM/XP )
10. Data backup plan, restore mechanisms & disaster recovery/ business continuity plan
11. End-user training plans/manuals.
12. Test Cases, Test Results
A. Functional
B. Non-Functional ( Security, Load, Performance)

Other Aims
The software solution shall provide for
1. The project aims that ultimately all the relevant officers and officials of government and its agencies
will all have digital signature certificates.
2. It is expected that Unique Identification Authority of India (Aadhaar) will issue sizable number of
UIDs to population in India in next two years. The software solution be compatible and capable of using
Aadhaar numbers which will authenticate identity. In this numerous possibilities will open up. The
software solution shall be created so that this scaling up could be harnessed at a relevant point of time

Annexure D
Technical evaluation is only a qualifying criteria. The financial bids of technically qualified
bidders will be opened by MG NREGS, RDPR Dept (Minimum Qualifying Score = 65)

Technical Evaluation Criteria

S.No.
1 Total Marks = 100

3
4

6.

Description
Organizational Turnover (last
three financial year average)
(In Crores)

Marks
7 Marks: > 100 = 7 Marks
50-100 = 6 Marks 20-50 = 5
Marks 10-20 = 3 Marks < 10
= 1 Marks
Experience in Government or 8 Marks 5 Projects 8 Marks
Govt PSU IT Works within 4 Projects 7 Marks 3
last Six years
Projects 6 Marks 2 Projects
4 Marks
POC Demo (see Annexure-J 65 Marks
read with Annexures Z)
Hardware Infrastructure 5 Marks
Proposed and
architecture plan having
the following minimum
details i. The servers
proposed for deployment
along with their roles &
responsibilities; (2
Marks) ii. List of all
possible threats of failure
within the proposed
architecture and possible
solutions (1 Mark) iii. Risk
Management Plan (2
Marks)
Application Software
10 Marks
Proposed Give technical
details of the solution
proposed, brand and make of
products, software solution
architecture details
Training Management
5 Marks Training Plan : 3
Marks Earlier Trainings
Given to at least 100 users : 2
Marks. Work
Order/Agreement copy and
training certificate must be
provided as a proof.

Annexure E
Performance Bank Guarantee
(For 10% of award of total contract work value)
This shall be executed on the 300 Rs/ stamp paper.
PERFORMANCE BANK GUARANTEE

To
MG NREGS, RDPR Dept, GoK
M S Building, Karnataka Government Secretariat
Dr B R Ambedkar Veedhi, Bangalore - 560001
OUR LETTER OF GUARANTEE NO.: ______________
In consideration of MG NREGS, Department of Rural Development & Panchayat Raj, Government of
Karnataka having its office at M S Building, Dr B R Ambedkar Veedhi Bangalore - 560001 (hereinafter
referred to as MG NREGS, RDPR DEPT which expression shall unless repugnant to the content or
meaning thereof include all its successors, administrators and executors) and having entered into an
agreement dated ________ / issued Purchase Order No. _________ dated ___________
with/on M/s ________________________ (hereinafter referred to as The Supplier which expression
unless repugnant to the content or meaning thereof, shall include all the successors, administrators, and
executors). WHEREAS the Supplier having unequivocally accepted to supply the materials as per terms
and conditions given in the Agreement dated _______ /Purchase Order No._______ dated _________
and MG NREGS, RDPR DEPT having agreed that the Supplier shall furnish to MG NREGS, RDPR
DEPT a Performance Guarantee for the faithful performance of the entire contract, to the extent of 10%
(ten percent) of the value of the Purchase Order i.e. for _____________________________________
.
We, _____________________________ (The Bank) which shall include OUR successors,
administrators and executors herewith establish an irrevocable Letter of Guarantee No. __________ in
your favour account of _______________________ (The

Supplier) in cover of performance guarantee in accordance with the terms and conditions of the
Agreement/Purchase Order.
Hereby, we undertake to pay up to but not exceeding _________ (say ____________ only) upon receipt
by us of your first written demand accompanied by your declaration stating that the amount claimed is
due by reason of the Supplier having failed to perform the Agreement and despite any contestation on
the part of above named supplier.
We .. (The Bank) undertake to pay to the MG NREGS, RDPR DEPT
money so demanded notwithstanding any dispute or disputes raised by supplier in any suit or proceeding
pending before any court or tribunal relating thereto our liability under the present being absolute and
unequivocal.
This Letter of Guarantee will expire on ________________ including 30 days of claim period and any
claims made hereunder must be received by us on or before expiry date after which date this Letter of
Guarantee will become of no effect whatsoever whether returned to us or not.
This guarantee shall be governed by and construed in accordance with the Indian Laws and we hereby
submit to the exclusive jurisdiction of courts of Justice in India for the purpose of any suit or action or
other proceedings arising out of this guarantee or the subject matter hereof brought by you may not be
enforced in or by such count.
We lastly undertake not to revoke this guarantee during its currency except with the consent of MG
NREGS, RDPR DEPT in writing.
Date
Place
For and Behalf of the Bank
Signature and Address.

Annexure F
Format For Deviation Statement

S.No.

RFP
Section/Clause
No.

Deviation

Reasons

Remarks/Impact

Annexure G
Request for Clarifications (RFC)

Bidders requiring specific points of clarification may communicate with MG NREGS,

RDPR Dept during the specified period using the following format.
Bidders Request for Clarification
Name of Organization
Name &
position of
Full address of the
Signature
of Authorized Signatory
Date:
submitting request
person submitting request organization including
phone, fax and email
points of contact
Company Seal:
Tel:
Fax:
Email:
S. No
Bidding Document Content of RFP
Points of
Reference(s)
requiring
clarification
(section number/ Clarification
required
page)
1
2

Sl.ANNEXURE-H
No.
SLA Parameter Baseline Metrics Basis of
Business Hours Non-business
(BH)
(NBH)
Sl. No.
SLA Parameter Baseline Metrics Measurement
Basis of
Business Hours Hours
Non-business
downtime
inIA
of this
shallSLA,
ensure
onethat additional
Measurement
(BH)
Hours penalty
(NBH)
hours / 24 all
transaction
such errors
is defined
are
shall be charged.
Post Go-Live Support and Maintenance
of
logged
bydays
the following
and
logs
1
Timely updation Within 1 month hours*no.
Every month
If
notsuch
complied
For less than
per
period
(1
should
activities:
be
1.
accessible
of patches /
SOLUTION
with the mutually baseline
month).
Generating
Review/report
a report
service packs /
PROVIDERfor
agreed
upgrades performance
13
Resolution
of
2
hours
The
Solution
through
for
a
particular
EMS.
fixes from product
needs to prepare within 1 month
metrics (i.e.
10
Critical
Percentage
faults
Provider
should
SOLUTION
department
For 99.6%)
lower penalty of
vendors
of
the inof data 0%
a report stating
from athe sign-off
the
loss
new in
system
online / offline
ensure
PROVIDER
standard
under date,
format
will
afterofperformance
(i.e.MC.
less
application
any newthat
release
penalty
1.25% of the
mode at SDC
no
circumstance,
comply
with
the the
submit
99%),
platforms
of patches
/hitting at
0.5%
will be thanFor
eachpenalty
slab ofof
the
MG packs
NREGS,
requirements
button
providing
byof the 1.5 0.5%
% of the
MC shall
service
/ by
charged
downtime
RDPR
an index
value
a mock be charged
(for each
fixes ofDept
all conducting
MC.
below 99%
Operational Phase Hardware Related
should
drill
any
to demonstrate additional
slab
solutionincur
baseline
an(1%)
5
Capacity of the
Ability to handle
loss
of
data
the
at
the
compliance.
The
drop
in
performance,
components by
additional 0.5% of
Database Server
30000 transactions
SDC
(central
mock drills will be
0.5 MC
% ofwill
MCbeas
respective
per hour repository)
repeated
which
at
such
additional
penalty
product vendors
charged
as
6
Capacity of the
Ability to handle
comes
through
periodic intervals as shallpenalty.
be charged.
along with
an
This isFor
Application Server
40000 transactions
the
software
the department
will lower
performance
impact
analysis
of
excluding
the time
per hour solution
of the
prescribe
in the
(i.e.for
less
than 99%),
incorporating
the
scheduled
7
Availability of
97%
Solution
Provider.
document
penalty
of 1.5 % of
same. Based
on
maintenance.
Software Solution
This
needs
to
be
the
MC
shall be
mutual agreement
Services at the Data
measured
and
charged
(for each
with PD the
Centre
tracked.
additional
slab (1%)
required patches /
Operational Phase Resource Management
Appropriate
drop
in
performance,
service packs /
8
Average Portal
< 7 Sec
Measured
backup
0.5 % of MC as
fixes need using
to be For lower
page loading at
the
mechanisms
EMS/suitable performance (i.e.
additional penalty
incorporated
SDC level
tool.
need
toa be
less than 99%),shall be charged.
withinNonmonth
11
Average issue
8 Hours
availability
End-user
established.
of any penalty
If the average
of 1.5 % For lower
from the signed
resolution time for
of
measurement
the
services
response/resoluti
of
the
MC
shall be performance (i.e.
off report.
calls
received
at
would
system
amount
will
be
to
on
charged
time,
exceeds
(for
less of
than
2
Security breach due 0%
Findings of audit andeach
Penalty
25 99%),
% of
MGto
NREGS,
deviation
adopted
and
the
additional
prescribed
slab
penalty
0.75 %
application
subsequently through the MC shallofbe
RDPR Dept with
frequency of
limit,
(.25%)
for
drop
a
month,
in
of
the
MC
shall
MG NREGS, RDPR charged. Past 1 daybe
Criticality
measurement
then
performance,
1% of the1%
chargedextra
(for 25%
each
Dept tools
of breach,
Medium
shall be
MC
of MC
willas
be
additional
of MC
shall beslab
determined during charged
additionalaspenalty
(2%) drop in
chargable.
implementation
penalty
shall
be charged.
performance,
0.5
3
Timely updation of
Within 1 month
Every two
month
If not
complied with
9
Percentage
of
H/W
or
0%
stage.
The
The
%
of
statistics
from
%
of
MC
as
patches / service
SOLUTION
the mutually agreed
S/W
complianceEMS,
is
analysis
of to upgrades
additional
penalty
packsfailure
/ fixeswithin
from the
PROVIDER
needs
within
1
SDC
linked
to
%
event
of
log
shall
be
shall
be
charged.
product vendors of
prepare a report
month from the signattempts used
toany
determine
the application
stating
new
off date, penalty of
successful availability
(<10 of patches
of online/ 0.5% will be charged
platforms
release
sec) or % ofservices
over the
service packs
/ fixes of the MC.
attempts not
Internet
(For this
of all solution
successful purpose
the number
components
by
(>10Sec). E.g.
of
connection
failures
respective product
Out of 100 for
the
sessions
vendors along with an
attempts, ifinitiated
only analysis
by the of
impact
once the page
internal
users
shall
incorporating the
loading takes
also
beBased
considered).
same.
on
more than 10
mutual agreement
seconds, then
with%PD the required
of compliance
is
patches
/ service
99%. This packs / fixes need to
measurement
will
be incorporated
be after removing
within a month from
effects of internet
the signed off report.
connectivitySimulating
or
4
Concurrent connects =6000
the stated For lower
other aspects
not
(users) to Web
load
and testing the performance (i.e. less
attributablesystem
to the performance than 99%), penalty of
Server (Internet
Solution Provider
Users and other
using load testing
1.5 % of the MC shall
12
Average
issue
The SOLUTION
external
users)15 Hours
tools For the purpose be charged (for each
resolution time for
PROVIDER
additional slab (1%)
calls resolved at
should maintain
drop in performance,
MG NREGS,
all H/W and S/W
0.5 % of MC as
RDPR Dept with
appropriately to
Criticality Low
ensure maximum
uptime. Downtime
due to H/W or

ANNEXURE-I
(v) GIS
Sl. Module

Items
(v)
Qty
Man-Month Rate
System/Application
2
(vi)
Administrator
Bidders
are required
to quote
costs as percum
the following schedule:
Management
System
Manager
(the
price-bid shall be inclusive
of all applicable taxes, duties, charges and levies etc)
Module
Total
D
(vii)
(vii)
InComplaints/Grievance
the column 2 of following tables, where Yes/No is not indicated for a component, the indicated quantity is
Sl.
Items
Man-Month Rate
the
minimum
requirement.
Management
Module
1
Developers
(viii) Ombudsman Module (viii)
2
SQA / Tester
(ix)
1. Hardware
Material at SDC(ix)
(including
3 year
3 Digital Signatures
Technical
Writerwarranty maintenance)
Certificate
Management
SN
Item
OEM Total Specificatio Unit Rate E
No of units Total cost
Module
ns Management
(in Rs)Contract)
AM
& PMC (Annual Maintenance & Project
(x)
Module
(x)
1 Social Audit
Application
Servers /
Rate for upto a batch of size
(xi)
Reporting,
(xi)
Sl No
Training Details
Web
Servers
30*
Personnel
Costs
Dashboarding
and
21.
Database
Training of upto 1500 Master
Analytics
Module
Trainers at Bangalore and/or
(xii) TrainingServers
&
(xii)
3
Portal
Mysore.
The cost of
organising
Performance
Monitoring
Additional Functionality / Feature
in Software
Man
Month Rate
Servers
and infrastructure to be borne
System Module
The entire financial
Blade
Servers
5
by MG NREGS, RDPR Dept
(xii) Database
Server
(xiii)
implications of the rates
Chassis
MG NREGS, RDPR Dept but at
Software
Training
CostDual CPU
6
quoted would be
least
two
Trainers
per
batch
of
(xiv) Application
(xiv)
Blade Server
calculated using the
Software Rack Mount
* 7In case a given
batch to be trained is bigger than 30 then pro-rata basis
formula (T) = A + B +
(xv) All will
other
Software
(xv)
Server
(Single
payment
be
made
CPU) in above
cost not covered
C+ D*36 + (E * 9) +
8
DNS/Directo
points
F*50
Note ry
(licence
The factor being multiplied
1. In case, the MG NREGS, RDPR Dept requires new features and
server/DHC
s, if any,
with 9 is the expected
functionalities
to be added in the proposed application after Go-live, the
P Server
shall beProvider
number of man month of
Solution
will be responsible to undertake related development work.
9
SAN Storage
perpetu
effort which may be
Here
it should be noted that the additional effort required to complete the
10 with
Backup
al
required for software
work,
in man months, would be decided after mutual consultation between the
Server
support
enhancements during the
MG
NREGS, RDPR Dept and the Solution Provider, while the man month
Please
as
per
contract period.
rates mentioned here will be applicable. Any development of the Software
add/modify/del
Clause
The cost E has been
Solution or Other Software suppled by the Solution Provider but needing not
ete
21
of
multiplied by a factor of 50
more than 15 man-days (in a given quarter) will be treated as part of AMC in
components
as E is cost of training a
2Section
nd and 3rd year and Free Maintenance in 1 st Year and not payable by MG
as
4 per the
batch of upto 30 strength
NREGS,
RDPR Dept as per this clause.
solution
Scope
and it is expected 1500
2.suggested
The above rates are being taken for estimation of costs pertaining to
of
persons in 50 batches of
additional
Total (A) development in software that may come up after Go-live till next
Work)
30 persons each would be
three
years and
hence must be valid for
that period.
2.
Software
(including
1st year AM & PMC)
Total
(B) (FullApplications/Solution
cost of
trained.
3.Name
The cost
for project lead and project management
will be factored
of Application
software)
A Module
Based in the
additional development rates quoted above.
Web Based

Pricing
Schedule
(vi) 1Human
Resource

Application for
MG NREGS
Module Wise Cost
(including
development,
integration, licences
if any,
Sl. database all Items
Qty
costs
1 included) in
2nd Year AM & PMC 1
2
3rd Year AM & PMC 1
Indian
Rupees.
Total

(i) Job Card & Demand

(i)
Registration and Planning
Module
(ii) Estimate Preparation
(ii)
Module & e-Measurements
Module
(iii) Finance, Accounting & (iii)
Wage and Bill Payment
Module
(iv) Material Management (iv)
& Asset Management

Cost
C

ANNEXURE-J
POC Write-Up
(TOTAL MARKS = 850; FINAL SCORE BASED ON %AGE MARKS SCALED DOWN TO OUT OF 65)

1. The PoC is explained in paragraphs below, however, overall requirement and

evaluation of the PoC shall be based on the benchmark of deliverables as stated in
Scope of Work in Section-4 above. Therefore, the write-up below shall be read
together with and in context of the Scope of Work. The awarding of marks shall be
done accordingly.
2. The PoC shall create a home page for dummy (or actual) 100GPs, 10 Taluks, 3
District ZP offices with the following staffing pattern (note that the same dummy or
actual data of GP/TP/ZP can be used to demonstrate all the subsequent PoC points,
including, Reports, Analytics etc)
a. ZP Office (i) One CEO ZP (ii) One Ombudsman (iii) Two Deputy Secretary ZP &
Project Director DRDA (iv) District MIS Cooridinator (v) Two Supervisors (vi) Five Case
Workers (vii) Five Data Entry Operators (viii) One Grievance/Complaint Case Worker
b. Taluk Pachanyat Samiti (i) One EO TPS (ii) One Assistant Director Taluk (iii) One
Taluk MIS Cooridinator (iv) Two Supervisors (v) Five Case Workers (vi) Three Data Entry
Operators (vii) One Grievance/Complaint Case Worker
c. GP (i) One Adhyaksha (ii) One PDO (iii) One GP Secretary (iv) Two Data Entry
Operators (v) One Grievance/Complaint Case Worker
d. The application must support role based access control for authorization purposes.
Note: District-Taluk-GP linkage shall be uniquely defined in case of dummy data. The
dummy names such as GP1, GP2, Taluk 1, Taluk2, District 1, District2 etc can be used
in case of dummy data creation by the bidder.
Each staff/personnel shall have a login ID with intuitive login name (such
<Deisgnation.OfficeName.Location> (PDO.GP.Kanakapura etc). The login id of a
government servant shall be linked with his (i) email id (ii) Mobile No; (just like
facebook allows this). In this, the first login could be as per based on Official ID, and,
once logged in, an employee shall be asked to give his email and mobile no
(compulsory), thereafter, the government servant can use (i) Regular Login ID (ii) His
email id (iii) Mobile number, to login. The email facility or email PoP shall be created
and demonstrated for each of these personnel. (75 marks)
3. Note, that all relevant issues, requests for work/Job Cards, grievances/complaints
etc, if filed (i) On-line (ii) Call-Centre (iii) CSCs etc, shall be routed to the correct
destination office by the Software Solution. The option to mark copy of any
issue/request/grievance/complaint to office/officers higher in hierarchy shall be
configurable and demonstrated in the PoC. The routing to the correct destination
offices of requests, grievances, applications etc shall be demonstrated in PoC. This
routing shall be capable of correctly routing of an application/request/complaint based
on
a. the address of the applicant and/or
b. address of the destination office. (50 marks)

4. Planning (130Marks), Job Card Registration (30marks) & Work Demand

Module (30Marks) PoC:
a. Planning PoC:
i. In the Planning Process multiple Grama Sabhas may be conducted in one GP. In the
Grama Sabha the work lists are created, assessed, discussed, prioritized (category
wise separate prioritization) and approved. The steps involved in this regard are
1. Works and work(s)/work-lists recommended by GP/TP/ZP or Line Departments or
other agencies/authorities are consolidated village-wise, and, put by Software Solution
in the relevant folder Recommended List of Works for XYZ Village in ABC GP
(5 marks)
2. The Grama Sabha will consider all these plus any other works in their meeting in the
village.
3. Grama Sabha proceedings shall be attended and signed by at least 25 Job Card
Holders of that village/GP. The signed proceedings of the Grama Sabha shall be
scanned and uploaded in the software solution. The software solution shall track this.
(5 marks)
4. Data entry of works approved by the Grama Sabha. The software solution shall track
this. (10 marks)
5. The software solution shall keep a track of uploading of proceedings and work list
data entry GP wise. Each proceeding shall be uniquely numbered using following
scheme
Grama Sabha Proceeding Number = District/Taluk/GP/Year/Meeting No. (10 marks)
6. Once entered, the approved list cannot be deleted or modified (though additional
list of works can be added with due approval of the Grama Sabha). The digital
signatures of the PDO shall seal it. (10 marks)
7. The work-lists approved in subsequent or multiple Grama-Sabhas for a given GP
shall automatically append to the existing list of works already approved and entered
category and sub-category wise. (5 marks)
8. Prioritization, short-listing, Annual Action Plan preparation shall be based on this
entered list of GS approved works.
9. In this each of the work in the entered list of works shall be (without an option to
delete any work)
(i) categorized under one of 16 permissible category of works. In case the work does
not belong to any of the 16 permissible category of works, then the work shall be
categorized as impermissible ; (5 marks)

(ii) 16-categories shall be further sub-divided into sub-categories as per Annexure-2

(primarily based on wage-material ratio, such that works in a given sub-category of a
given category will have same/similar wage:material ratio); (5 marks)
(iii) Prioritized (within each category and sub-category) (5 marks)
(iv) The rough cost for each work can also be entered. However, this would be a rough
figure at this stage as the detailed estimate is not yet prepared. (5 marks)
10. The Gram Panchayat, Taluk, District or other authorities shall have not have option
to add any work which has not come as duly approved from Grama Sabha. These
authorities can send their list of works for consideration and approval of Grama Sabha
by entering their works into the software solution. These works shall be entered
category and sub-category wise, and, shall be automatically sent to concerned GPs
folder Recommended List of Works for XYZ Village in ABC GP
11. The number of Job Cards in a GP gives the upper limit of labour budget of the GP.
The said limit being:
Upper Limit on Labour Budget of a GP = 100 X No of Job Cards in the GP
Practically, the actual labour budget of last year could be the basis for drawing up
Annual Action Plan of forthcoming year. Alternately, option shall be offered by Software
Solution to assign Labour Budget equal to Actual Labour Demand in the previous year
PLUS anticipated %age increase in Labour Budget. For example,
Let Actual Labour Budget of a GP in 10-11 = X (based on anticipated Labour Demand
of x1 persondays)
Let Actual Labour Demand in 10-11 = y1
Then the Labour Budget for 11-12 could be derived, optionally, based on the following
two formulae
(i) Labour Budget of 11-12 = Labour Budget based on anticipated Labour Demand of
(x1 + 10% of x1), or,
(ii) Labour Budget of 11-12 = Labour Budget based on actual Labour Demand of (y1 +
10% of y1)
Higher of the two shall be selected by Software in default mode (with option to switch
to either of the two projections). (10 marks)

12. The Planning Module shall seek and get actual month-wise Labour
Generation/Personday (PD) done in the last financial year in the GP. This shall be
calculated in terms of PD generated in a given month as %age of total PD generated in
the financial year. Using this, the total PD and likely expenditure shall be calculated for
the whole year for which Action Plan is being prepared month-wise. This calculation
shall be done for each GP and each Implementing Agency, and, summed up to obtain
Taluk wise, district-wise and full State expected PD generation and expected
expenditure (month-wise). For the purpose of PoC. This spread month-wise shall be
taken as follows
(10 marks)
13. The Planning Module shall ensure the Annual Action Plan of a GP is as per above
April
May
June
July
August Septemb
Labour Budget. The works shall be selected in the prioritization order (category
and
er
sub-category wise). 5%
6%
3%
3%
6%
9%
14. The State and theOctober
district CEO
shall
have
option
to
affix
upper
limits
and/or lower
Novemb Decemb January Februar March
limits on each of the 16 category
of
works
(and
the
sub-category)
to
be
enforced
in the
er
er
y
Annual Action Plan preparation.
For example,
say Category-1
9%
9%
10%let us11%
13% is Water
16%
Conservation Works. Then State/District shall have option to fix lower and/or upper
limit of, say, 25% (in money terms). Similarly, Roads Category of works could be
similarly assigned upper limit of, say, 10% (in money terms). Once this is done, then
Software Solution shall enforce it in preparation of the Annual Action Plan of the GPs in
the State/District. (10 marks)
15. Software Solution shall ensure that overall 60:40::Wage:Material Ratio is
maintained at a Gram Panchayat level (with minimum 60% funds of MG NREGS being
spent on unskilled labour wages) in Annual Action Plan preparation of the GP. This shall
be done using the information of Wage:Material ratio as per sub-categorization
(Annexure-2). The Software Solution shall enforce proper combination of works to
ensure that at least 60% (in money terms) funds are allotted and used for payment of
unskilled wages to Job Card Holders. This shall be finalized in terms of actual estimates
once the detailed estimates are created using the Estimation Preparation
Module. This shall be ensured

The deemed
worklist is
approved
prepared
oras
actually
per above
approved
proposals

at least by the time District

Action
Plan
finalized
by end of November. The
andAnnual
worklist
consolidated
reaches
CEO
GP
and
ZP,isVillage-wise
who
shall examine
Finance, Accounting &
Wage
and
Bill
Payment
Module
shall keep a track of
from point of admissibility of works from MG
this and highlight at regular
intervals
any deviation
from this minimum
The (configurable)
NREGS
worklist
guidelines.
is placed
The
for
inadmissible
discussion
works
and shall
requirement. (15 marks) be
decision
sent back
of the
toGrama
GP for Sabha
reconsideration. The
other admissible
works
have to
16. The time-lines and prescribed
schedule
forshall
Planning
is approved.
attached herewith in
Grama
The
Zilla
Sabha
Panchayat
delibrates
shall
the
approve
list
and
the
Annexure-3.
approves/rejects/modifies
admissible
works within 15-days
the worklist.
of receipt
A final
17. It shall be possible to track all planning processes across the state and take
duly approved
failing
which the
worklist
worklist
is shall
givenbe
bydeemed
Grama Sabha
to
corrective actions in time to ensure adherence to prescribed time-limits. The Planning
have been approved. The ZP can add certain
Module shall automatically
highlight
deviations
from
the
prescribed
time-limits of MG
The GSwhich
works
approved
are admissble
worklist goes
and to
areGP.
of The
"InterGP
NREGS, and, take suo-moto
corrective
action
to
the
extent
possible
by
way of issuing
prioritizes
Taluk"
nature
the list as per GP's Labour Budget
SMS and email alerts, printed
notices
etc.
(10 marks)
(Labour
Budget
is based
on expected Labour
18. The actual Persondays
generation
andThere
Labour
of an to
area/GP shall be
Demand
The
approved
in a GP).
worklist
asshould
perDemand
Labour
be attempt
Budget
select
become
works
in
"Annual
all/maximum
number
for of
the
villagesand persondays
continuously kept a trackshall
of, and,
in case
the Action
actualPlan"
labour
demand
in the GP.
district,
and,
enter
cannot
into
delete
"Shelf
any
ofwork
Projects".
(unless
This
it
achieved in the actual execution
ofGP
works
crosses
75%
of the
originally
approved
violates
MG
NREGS
"Annual
Guidelines)
Action Plan"
and
as
can
perPlanning
merely
Labour Module shall
annual labour budget (in consolidated
terms of
labour
demand);
then
this
priotitise
Budget
shall
the be
worklist.
sent
by extent
CEO ZPthat
to State
automatically trigger action
to enhance
(to an
shalllevel,
be configurable) the
which,
in
turn,
sends
it
to
Ministry
of
Rural
labour budget and increase the Annual Action Plan for the concerned area/GP. This
The prioritized
Development,
Govt
and GP
of list
India
approved
State
Worklist
All
shall be done by taking works
as per priority
of as
works
inPlan.
thegoes
Shelf of Projects or
to
the
Taluk/Block
district
annual
Panchayat
action
plans
for
approval.
are
EO
TPS
Grama Sabhas Approved list of works. In case the said list of approved works of
shallthen
consolidated,
examine
and,
the worklist
financial
to admissibility
of the
offor conduct of new
Grama Sabha is inadequate
the Module
shallasrequirements
trigger
and alert
works are
State
as per
arrived
MG NREGS
at. EachGuildelines.
work in theThe
action
Grama Sabhas. The Additional Action Plan to be included for meeting increased labour
inadmissible
plan
shall have
works
a unique
shall be
work
sentcode
backassigned
to GP for
demand shall be 5000Persondays per GP at a time (subject to upper limit of Job Card
change
to
it.
by EO TPS
No X 100). Each work in the Annual Action Plan shall be assigned a unique Work ID
and the same shall be used
the life-cycle
of (Programme
the work (see MG NREGS
Thethroughout
Taluk/Block Executive
Officer
website: www.nrega.nic.in
to
see
the
Work
ID
assigning
method
or use your own
Officer) and TPS can only refer back
to GP such
method for PoC purposes).
The
PoC
shall
demonstrate
similar
assigning
of unique ID to
works in the worklist which violate MG NREGS
works. (10 marks)
Guidelines. The other works in the approved list
be approved
without Action
changePlan
by TPS
19. The planning processmust
for creation
of Annual
for a financial year starts
within
15
days
of
receipt
(EO
shall
place
the Planning Process is as
from 15th August of the preceding year. As per above details, the
worklist
in
TPS
within
ten
days
of
receipt
of
follows
list). In case EO/TPS fail to approve the worklist
as sent by GP within 15-days, then it shall be
deemed to have been approved by TPS. The
TPS can add certain works which are admissible
and are of "inter-GP" nature

b. New Job Card PoC (30 marks): A citizen shall be able to apply for new Job Card
via (in PoC demonstrate Online Method and direct GP method)
i. Online (web-based)
ii. Call Centre - Call Centre shall get full support of software solution
iii. At the Gram Panchayat or Taluk office
iv. In a Common Service Centre
v. The software solution shall demonstrate the following features
1. receive applications
Step-by-Step Planning Process
2. capture all relevant details of the applicant (see checklist below)
3. compare the received Works
application
againstora selected
standard
are identified
orchecklist
chosen or as given below
(i) Applicant addition in an
existing
Job
Card
or
new
one?
proposed by villagers, GPs or Line Depts or
other Agencies
(ii) If addition in existing then
Job Card Number In this the following shall be the procedure
The Applicant shall be asked to give his Job Card Number and other details as per
checklist. However, in case an Applicant does not know his Job Card number; then the
software shall record this fact that

the Applicant does not know his/her Job Card Number. Further, the search using
Applicant Name, Village Name, GP, Taluk and District Name shall be enabled. The Call
Centre can hand-hold the Applicant to identify his correct Job Card (using other
data/information for verification such as father/husband/other family member
names).
(iii) Name
(iv) Fathers/Guardians Name
(v) Gender (Male/Female)
(vi) Address where ordinarily resident
i. house number/area (either),
ii. village,
iii. GP,
iv. taluk,
v. district
(vii) Date of Birth/Age (take either and calculate the other)
(viii) Whether BPL or not (Yes/No)
(ix) SC/ST/OBC/Others (optional)
(x) Ration Card No (optional)
(xi) Election ID Card No (optional)
(xii) UID No (optional)
(xiii) Mobile/Contact No (optional)
4. Issue acknowledgment with a unique number. Acknowledgment number shall be
numeric one with specific fields reflecting State, Department, District, Taluk, GP,
Month, Year, Serial Number.
5. reject with reasons if the application is without all the mandatory points of the
checklist (rejection shall be immediate in case any of the checklist points are missing).
The rejection shall mention the reasons/points missing which led to on the spot
rejection of the application.
6. The software shall have ability to catch multiple/duplicate Job Cards by a single
family/person. For the purpose of PoC, the comparison shall be done based on UID
(dummy data), name and other similar fields. The ability of software to catch attempts
to get duplicate Job Cards will be a point to be demonstrated in the PoC. In case of
duplicate application, the request shall be rejected by proper endorsement to the
applicant.
7. A valid request shall be escalated to the concerned GP with a copy to EO TPS (for
information and record)

8. An application with all mandatory points of checklist, and, which is not a duplicate
shall be processed further by the Gram Panchayat. In this the PDO will conduct
requisite local field and other enquiries and decide on the application within 15
working days of date of receipt of the application.
9. The decision arrived at by the PDO shall be entered by him in the software.
10. The decision shall be informed to the applicant locally at the GP, via Mobile SMS,
Call Centre Call-up, Online status update. The Job Card number shall be informed as
well.
11. The physical Job Card shall be printed in the prescribed format/paper and issued to
the applicant locally at GP level.
vi. Appropriate log of the transaction shall be created (see Annexure-1)
c. A citizen or a group of citizens with a valid Job Card(s) shall be able to apply for
unskilled work in the GP where he/they have a Job Card via (in PoC demonstrate Online
and direct GP method)
i. Online (web-based)
ii. Call Centre - Call Centre shall get full support of software solution
iii. At the Gram Panchayat or Taluk Office
iv. In a Common Service Centre
v. The software solution shall demonstrate the following features (30 marks)
1. Receive application for unskilled work via any of the above means
2. The application shall be treated at par with Form-6. It should be converted into
format of Form-6
3. Checklist points shall be
(i) Job Card Number(s)
(ii) Name(s)
(iii) Fathers/Guardians Name(s)
(iv) Number of days for which employment sought (capture individually for each
applicant)
(v) Period (dates: from-to) for which employment sought.
(vi) Mobile/Contact Number(s) (optional)
(vii) UID Number(s) (optional)
4. Issue acknowledgment with a unique number one application can contain more
than one applicant request, and, in such a case single acknowledgment shall be
issued.
5. If any mandatory checklist point is missing, then issue rejection on the spot citing
missing mandatory checklist point(s). [separate decision shall be given for each person
if a single application contains more than one name].

6. Only a valid and existing Job Card Holder can apply for unskilled work.
7. The Applicant shall be asked to give his Job Card Number and other details as per
checklist. However, in case an Applicant does not know his Job Card number; then the
software shall record this fact that the Applicant does not know his/her Job Card
Number. Further, the search using Applicant Name, Village Name, GP, Taluk and
District Name shall be enabled. The Call Centre can hand-hold the Applicant to identify
his correct Job Card (using other data/information for verification such as
father/husband/other family member names).
8. A valid request shall be escalated to the concerned GP with a copy to EO TPS (for
information, record and action in case of ALERTS)
9. The software shall know the village of the Applicant from his/her Job Card Number
itself. The Software shall throw up list of on-going MG NREGS works in the GP, with
works in the village of the applicant at the top. The PDO shall assign suitable work to
the applicant by tagging him to one of the on-going works. The dates (from:to) shall be
captured as well (see Annexure-1).
10. The list of on-going MG NREGS works in a village shall include works by all
Implementing Agencies (including the Line Departments). Similarly, the new work
assignment shall be from the among the works in the Shelf of Projects (including
those of Line Departments in that village/GP).
11. If number of applicants exceed 15 then a new work can be started for them in their
own village. This shall be done in a case where either there is no on-going work in the
village of the applicants or the work available is inadequate (this shall be calculated
based on billing status of the concerned work as compared to the estimated cost of the
work; together with the Job Card Holders already working on the said work). In case
number of applicants are less than 15 then new work shall not be started and they
shall be accommodated in an on-going work only. The formula for calculating whether
or not the on-going work in a village is adequate shall be as follows
(i) Let Estimated Cost of Work = X
(ii) Let Total Labour-days in the work = Y Persondays
(iii) No of labour already working (as per actual attendance in muster roll in the last
payment bill) = n1
(iv) Let number of new applicants for work = n2
(v) Let number of days for which employment is sought by new applicants = d1

(vi) Let number of persondays already paid for = d2

(vii) Then, Available Employment = Y d2 n1X20
(viii) If Available employment > {[n2X15] or [n2Xd2] - whichever of the two is
more}; then assign new Job Seekers in the same work. Else assign them to a
new/another work.
(ix) Splitting of applicants to more than one work can be done using above
calculations of adequacy.
12. The decision shall be informed to the applicant locally at the GP, via Mobile SMS,
Call Centre Call-up, Online status update, regular postal dispatch.
d. An Applicant shall be in a position to ascertain status of his application citing the
acknowledgment number at any point of time. The software shall fully support all
means of such a query (as per points no i to iv mentioned above)
e. In case of non-assignment of a work/issuance of Job Card within 10 days from date
of application, the EO TPS shall be given an ALERT MESSAGE to do the work
assignment either at EO TPS level or ensure that PDO of GP does this assignment. At
the time of login by PDO and EO TPS into the software system, the ALERT MESSAGE
must pop up, forcing them to take a decision the pending requests for work/job card
issuance.
f. The e-Muster Roll shall, accordingly, be triggered to be issued from NregaSoft of NIC
by the software solution. In case of PoC, this trigger in the form of relevant XML file
and/or other software trigger/output shall be demonstrated. Note that NregaSoft issues
e-Muster Roll for relevant dates for the relevant Job Cards for the assigned work.
5. Estimate Preparation & e-Measurements Module PoC (100 marks)
Standard templates for preparing the estimates of works that may be taken up under
MG NREGS are attached herewith as Annexure-5. The Schedule of Rates (SoR) is also
attached herewith as Annexure-6. (Note that these are DUMMY for PoC purposes
actuals can also be used by the Bidder) By using SoR and Standard Estimation
Templates, the estimates shall be prepared for all the works in the Annual Action Plan
or Shelf of Projects. In fact, the Annual Action Plan cannot be approved without
estimates of works having been done.
Now, for the purpose of PoC the bidder shall create 38 different estimates as per the
template (Annexure-5) provided herewith using data provided in Annexure-7. The
following shall be demonstrated
(i) Each estimate shall be time and date stamped at each stage, viz, (a) preparation (b)
technical countersignatures & approval (c) administrative approval (d) launch or start
date (e) each time the executed work is measured (physical measurement of work) (f)
each time bill is prepared (g) each time bill payment is made (h) date of final
completion of work (i) date of final bill preparation (i) date of final bill payment.

(ii) Technical estimate can be prepared only for such a work which exists in the Annual
Action Plan or in the Shelf of Projects (as prepared in the Planning Module). All such
works shall have a unique work ID/Code. In other words, software solution shall not
allow generation or feeding of estimate of a work which does not exist in the Annual
Action Plan or Shelf of Projects. Note, that Annual Action Plan is the shortlisted
version of Shelf of Projects wherein the shortlisting has been done based on the
available Labour Budget of a GP/TP/District. However, the estimate preparation can be
done for works in Annual Action Plan or those available in Shelf of Projects. [shelf
of projects is simply all the works duly approved in Grama Sabha and grouped GP
wise]
(iii) However, Administrative Approval shall not be accorded to a project unless it is in
Annual Action Plan. The procedure to bring a project/work from Shelf of Project to
Annual Action Plan is given above in Planning Module.
(iv) For the purpose of PoC the preparation of estimates using Standard Templates shall
be based on the data in Annexure-7; the estimate shall be prepared by Bidder
demonstrating that feeding relevant data in a mobile device leads to creation of full
estimate (in Standard Estimate Template). In this the Bidder shall feed in the basic
details of a work, including, name, Work ID, financial year etc (see Annexure-7) in the
mobile device. Then the basic data for preparation of the estimate shall be fed into the
mobile device; this shall lead to preparation of the standard estimate. The Standard
Estimate shall be uploaded into the software solution using (i) GSM/GPRS/SMS/MMS
communication; and, (ii) Physically connecting the mobile device with computer
system, and, data uploading. All estimates once uploaded/captured in the software
solution shall be digitally signed and approved by the Technical Personnel preparing
the estimate.
(v) An estimate duly prepared and approved by competent authority cannot be
subsequently altered without proper approval of the same/relevant authorities. The
technical hierarchy and method in this regard shall be as follows
1. Preparation of estimates Section Officer/Technical Assistant
2. Technical Countersignatures AEE/Next higher in hierarchy
3. Technical Approval AEE/EE/Relevant Technical Authority
4. Administrative Approval GP/EO TPS/Line Dept Head/CEO ZP
5. Launch of Work GP/Line Depts concerned authority. This shall be done only with
issue of e-Muster Roll and not otherwise. The NregaSoft of NIC issues e-Muster Roll.
6. Issue of e-Muster Rolls (using NregaSoft of NIC) shall be by EO TPS/PDO GP (to be
issued online and digitally signed)
7. Work measurement shall be permitted only AFTER e-Muster Roll has been issued for
the relevant work by EO TPS or PDO of a GP. The software solution and mobile device
shall enforce this.

Naturally, no bill can be prepared or triggered for payment without measurements, or,
in other words, without e-Muster Roll having been issued for a work (Note: Each work
has a unique ID)
8. The software solution and e-MB shall not allow booking of more labour generation (in
person days PD terms) than the PDs as per Muster Rolls issued.
(vi) In addition to demonstration using available data in Annexure-7, the estimates
preparation shall have to be demonstrated during the PoC using actual field data which
must be captured by taking the mobile device to the actual work-site/field. In doing
this the time&date and geo-stamping of the measurements/ dimensions of the
estimates shall happen. The pre-measurements of the work-site shall also have
time&date and geo-stamping (lat-long). This geo-stamp (lat-long) with time&date
stamp becomes finger-print of the work (together with the Work ID). Any other work
with same or almost same geo-stamp shall lead to conclusion of possible duplication of
works. This ability of the software solution (to catch possible duplication) shall be
demonstrated in the PoC.
(vii) Similarly, the PoC shall demonstrate the capturing of the field measurements
(once the work execution starts) together with time, date and geo-stamping
(longititude & latitude). This and all of the above shall be done using a hand-held
mobile device to be operated by technical personnel. The work execution
measurements shall, naturally, be done within a practical distance, say 100meters, of
the original geostamp of the work-site (captured at the time of preparation of the work
estimate). The software shall not allow field measurement to be recorded or accepted
unless the device is within prescribed distance (Annexure-5), say 100meters, of the
original geostamp of the work-site as captured during the estimate creation. The upper
limit on deviation between geostamp captured during estimate making and the
execution measurement is dependent on the category/type of work. The details in this
regard are mentioned in Annexure-5. This ability shall be demonstrated in the PoC.
(viii) The mobile device shall be capable of geo-stamping both with mobile network
connectivity and without it (satellite based). The degree of accuracy achieved in
geostamping shall be mentioned.
(ix) The mobile device shall be capable of holding at least 200 estimates at a given
point of time along with all measurement and related data.
(x) The mobile device shall be capable of connecting to computer systems and
synchronize data, share/update data based on the vintage of time&date stamp
(updation to be done based on digital signature authorization and bio-metric
authentication of the technical personnel). The software solution shall ensure that it is
always the latest data which is used to update the present status data of a work.

(xi) The mobile device shall also be capable of sending measurements and other work
related data remotely using GPRS/GSM and SMS. The Passcode based authentication
shall be built-up.
(xii) The software solution shall be able to fully support, integrate and interface with
the mobile devices. The Technical Personnel shall be authorized to make changes in
the measurements as recorded in the mobile device upon porting of the same to
Software Solution. These changes shall be recorded and audit trail created for future
reference. This option to edit the ported measurements from the mobile devices into
Software Solution shall be enabled or disabled at the discretion of the System
Administrator.
(xiii) The mobile devices shall function as electronic-Measurement Book (e-MB). Once
the data is sent/ported to the software solution, the technical personnel shall digitally
sign the data to authenticate, validate, and ensure non-manipulation.
(xiv) The changes in SoR shall lead to change in estimates. In case SoR are changed
during the execution of a work (while work is partly completed) then the changes in
SoR shall affect only the un-executed part of the estimate. The double/multiple/part
estimation templates shall be accordingly created by the software solution. However,
the changes in SoR shall be done only by the competent authority. The changes shall
be approved through digital signatures certificates and bio-metric authentication. The
decision to incorporate the impact of changes in SoR shall be optional to the
concerned Line Dept/Implementing Agency for all on-going works. In case the impact is
to be incorporated then concerned technical and administrative authorities shall
digitally sign and approve the changes and also authenticate them with biometrics.
However, the increases in minimum wage rates must be immediately incorporated for
unexecuted portions of the works/new works.
(xv) The e-Measurement shall be linked to automatic preparation of e-bills and also
linked to e-MR of MIS (both at the time of downloading as well as entry). This will
trigger electronic payments for both wages and material directly into the correct
accounts. Note that measurement of the work determines the actual bill payable and
the same shall be divided between labour/wage payments and material payments. The
PoC may demonstrate this triggering ability though XML exchange or as stand-alone
model.
6. Finance, Accounting & Wage and Bill Payment Module PoC (100 marks)
The Finance, Accounting (including bill processing) Module shall be demonstrated in
the PoC. The existing e-FMS (electronic Fund Management System) shall be used for
bill as well wage payments, however, the calculations and billing which trigger the eFMS payments shall be computerized (bill preparation shall be based on electronic
measurement of mobile devices which act as e-MB as explained in point no 5).

Further, it shall demonstrate support to manual cheques and other negotiable

instruments.
The work completion certificates and other relevant data shall be generated
automatically.
The other features of this Module shall be evaluated in the PoC as per requirements
explained in the FRS (Annexure-C). The marks shall be awarded in the PoC by pointwise checking the demonstration of the requirements cited in FRS (Annexure-C).
7. Human Resource Management System (80 marks)
A complete HRMS system shall be developed including leave management, payments,
performance evaluation etc.
The following shall be demonstrated in the PoC
(A) All the personnel shall be provided email id and login id from the software solution.
The email & login IDs of about 5627 PDOs, 5627 Adhyakshas, 176 EO TPS (one in each
taluk), 2000 Field Technical Personnel @15 per taluk (engineering,
agricultural/horticulture/forestry), 30 CEO ZP, 30 Deputy Secretary/PD NREGA, 30
District MIS Coordinators, 176 Taluk MIS Coordinators, should be demonstrated.
(B) The work of each of these personnel is different. The software shall be able to track
the following and demonstrate in the PoC
a. For evaluation of each Technical Personnel (Engineering/ Agriculture/ Forestry/
Horticulture)
i. No of works in Shelf of Projects pertaining to his jurisdiction (this will be in terms of
GPs) (100 marks for Shelf of Projects having Labour Part in PDs equal or more than
projected Labour Demand)
ii. No of works in the Annual Action Plan pertaining to his jurisdiction (this will be in
terms of GPs) (100 marks for Annual Action Plan having Labour Part in PDs equal or
more than projected Labour Demand)
iii. No & %age of works for which estimate has been prepared (as on a given date)
(%age based evaluation)
iv. No & %age of works for which estimates are pending to be prepared (as on a given
date) (%age based evaluation)
v. No & %age technical approvals accorded against total works in the Annual Action
Plan (%age based evaluation)
vi. No & %age of works for which technical approvals are pending against total works
in the Annual Action Plan (%age based evaluation Nil pendency = 100% marks)
vii. No & %age of works started out of total approved works in the Annual Action Plan
(%age based evaluation)
viii. No & %age of works completed out of (a) total approved works in the Annual
Action Plan, (b) total works which are started (%age based evaluation)

ix. No & %age of works on-going out of (a) total approved works in the Annual Action
Plan, (b) total works which are started (%age based evaluation)
x. Average time needed for completion of project (Category Wise, Sub-Category Wise,
GP wise, Taluk wise) (100 marks if equal or better than average time in the District,
more the time lesser shall be the marks)
xi. No & %age of Works which were billed in last 15-days as percentage of total ongoing works (%age based evaluation)
xii. Persondays generated in %age terms viz-a-viz Persondays projected in a given
period for the GPs of his jurisdiction. (%age based evaluation)
xiii. List of on-going Works which has not been billed since 60-days (%age based
evaluation ongoing vs not billed)
xiv. No of on-going works at a given point of time (on-going means a work which has
been billed/paid for in the last 30-days and is not yet completed).
b. For evaluation of a Adhyaksha, PDO & DEO of a GP (evaluation method shall be
same as mentioned for point (a) above)
i. No of times logged into the software solution in the last one week, fortnight, one
month, quarter, and six months.
ii. Average time spent per visit of login into the software solution.
iii. Date of conduct of Grama Sabhas in GP. Is it within the prescribed deadline. Cut
20% marks for each week of delay out of total 100 marks assigned to this.
iv. Date of approval of plan by Gram Panchayat. Is it within the deadline prescribed?
Cut 20% marks for each week of delay out of total 100 marks assigned to this.
v. Average days/time taken to decide/finalize the bills once the bill is presented. Ideal
time is 2-days. Cut 20% marks for each day of delay.
vi. No and %age of bills decided within 2-days of their presentation as against total
bills presented do this for present month, last 30 days, for whole quarter, six months
and the financial year wise.
vii. No of works in Shelf of Projects pertaining to his GP.
viii. No of works in the Annual Action Plan pertaining to his GP
ix. No & %age of works started out of total Annual Action Plan (as on a given date in
Financial Year)
x. No of on-going works at a given point of time (on-going means a work which has
been billed/paid for in the last 30-days and is not yet completed).

c. It is adequate for the purpose of PoC to demonstrate evaluation of above personnel.

In the actual software, naturally, many more points of evaluation, and, for each and
every personnel shall be evolved.
(C) The software solution shall enable automatically sending of SMS, emails, notices,
etc to a single individual, group, or, all or selected category of personnel, based on
evaluation score. This shall be demonstrated.
(D) Payment of salaries in HRMS shall be linked with the evaluation and Finance &
Accounts Module shall trigger payments as per rules based on evaluation score. This
linkage and connection between salaries and evaluation shall be configurable. This
shall be demonstrated.
(E) The method to score evaluation marks for the purpose of PoC shall be - each of
above evaluation points shall have maximum of 100 marks and depending on the
performance (read brackets above to know the method to evaluate each point) the
marks shall be awarded. The salaries shall be equal to %age marks scored (against
maximum marks)
8. Complaints/Grievance Management Module (80 marks)
This is a self explanatory Module. Idea is to have a complaint/grievance module which
is interactive one with the complainant, and, obtains his feedback on the
closure/decision on his complaint. If he is unsatisfied with the resolution/reply of a
complaint then the said complaint is automatically escalated to the next higher
level/officer. This continues to happen until State Level. This way a complainant need
not run from pillar to post to have his voice heard. Full Call Centre & IVR support shall
be given as well. This Grievance/Complaint Management System shall relate to general
complaints and will not be restricted to MG NREGS complaints alone. In fact, it is
expected that full, separate and independent tracking and reporting, dashboarding, etc
will be built for complaints/grievances. The Grievance Management System shall
support and provide on-line/electronic complaint receiving/handling/replies. The
Grievance Management System shall receive, process, track and dispose the received
complaints/grievances. The logins, administrative hierarchy for RDPR & MG NREGS
shall be leveraged so that independent but integrated reporting and processing is built
for Grievance Management System. In this it shall be assumed that each office spread
across the State and 30 Districts and 5627 GPs, has a dedicated cell/government
servant(s) who deal with receipt, processing, follow-up, disposal and compliance
reporting on grievance/complaints. This should be captured through an appropriate
WORKFLOW. The workflow shall be enabled for the same. Please, read the SoP
prescribed for grievance/complaints handling in MG NREGS issued by MoRD, GoI
(Annexure-9) and same shall form the bench-mark to evaluate the demonstration of
the PoC of this Module.
9. Ombudsman Module (60 marks)
All 30 districts have Ombudsman who, in turn, is a formal authority to examine
complaints on and with respect to MG NREGA implementation. Ombudsman has
authority to issue formal orders for recovery, recommendations for disciplinary action
etc. All these shall be provided by the Module plus the orders of

Ombudsman will reach proper quarters both physically as well as electronically for
follow up action. The PoC shall demonstrate the following
(A) A petitioner shall be able to submit petition/complaint to Ombudsman
i. Online (web-based)
ii. Call Centre - Call Centre shall get full support of software solution
iii. At the Gram Panchayat or Taluk office or ZP Office (Ombudsman Office)
iv. In a Common Service Centre
(B) Information to be captured for Petitioner(s) [in petition-form]
a. Job Card Number (Optional - this should automatically generate other data such as
Name, Address etc)
b. Name
c. Fathers/Guardians Name
d. Gender (Male/Female)
e. Address where ordinarily resident
1. house number/area (either),
2. village,
3. GP,
4. taluk,
5. district
f. Date of Birth/Age (take either and calculate the other)
g. SC/ST/OBC/Others (optional)
h. Ration Card No (optional)
i. Election ID Card No (optional)
j. UID No (optional)
k. Mobile/Contact No (optional)
(C) The Module shall have the following functionalities
a. New Complaint Registration
b. Club more than one complaint and hear them together
c. Assign dates to petitions for hearing
i. Allocate fix days in a week automatically or allot hearing dates manually
ii. Configurably assign a particular number of petitions for one hearing
iii. Fix weeks/months within which all cases shall be assigned a date for hearing
iv. Assign priority (Regular, Important, Critical, Highly Critical). The Critical and Highly
Critical shall be heard at least twice and three times in a fortnight.
v. Assign configurable upper limit to dispose off petitions depending upon the priority
(Regular = 45 days, Important = 30 days, Critical = 20 days, Highly Critical = 10days)
d. Categorize complaints into different types
i. Type-1 (time limit to resolve = x1 days)

ii. Type-2 (time limit to resolve = x2 days)

iii. Type-3 (time limit to resolve = x3 days)
iv. Type-4 (time limit to resolve = x4 days)
v. Type-5 (time limit to resolve = x5 days)
e. Each Complaint shall have
i. Complainant/petitioner(s)
ii. Respondent(s)
f. Create and issue Notices & get compliance from both Complainants and
Respondents, in this, ensure
i. parties to appear for hearing (paper, online, sms, call centre based)
ii. EO TPS, Engineers and PDO to report on the issue within a prescribed time limit (the
report could be submitted via e-reports or on-line or scanned ones or paper based)
iii. The generic method to do this shall be to prepare standard notices and letters
and also have option to scan and attach any other file with these notices/letters
g. On each date of hearing, Ombudsman could issue
i. General Order (seek reports, club cases, hear arguments etc)
ii. Interim Relief/Order
iii. Final Order/Award
h. The orders could be ex-parte or in presence of parties. The orders shall be issued to
both Complainant(s) and Respondents via, email, online, paper, scan and sending.
i. There shall be MIS reports on all complaints such as cases filed, pending, disposed,
pending beyond timelimit etc.
10. Reporting, Dashboarding & Analytics Module (115 marks):
a. The matrix reports formats at the (i) State Level (ii) Division Level (iii) District Level
(iv) Department Level (v) Taluk level (vi) Sub-taluk level (vii) Individual Application
Abstraction level, are in Annexure-Z. These generic formats needs to be developed.
b. Note that the default Matrix Reports will be as per formats contained in Annexure-Z.
Other reports such as Work Wise, Financials Wise, etc shall be selectable
11. All the aspects and facets of MG NREGS shall have SMS, Mobile, Call Centre
Support and Integrated Voice Recording System including Complaints, Labour
Demand, any other

ANNEXURE-K
Concurrent Users
The most common question regarding a websites performance is not how fast the website is or how it scales, but
something more fundamental:
What should the performance goal be in terms of concurrent users?
Should it be one hundred concurrent users? A thousand? Ten thousand? Does it require one server or a hundred to
handle the load?
Theres a good reason for how many times this question comes up: its tricky and theres no definitive answer. If it is a
new website its anyones guess what the demand will be. Even if it is an existing website, web analytics software
typically give marketing reports on how many customers were acquired per month or per week, and even a per-day
measurement but doesnt give the numbers required. The reason is the difference between average and instantaneous
peak. It doesnt matter if only 5% of a sites capacity is used all year if the site was unusable for a critical period. The
only thing that matters in terms of protecting your site against crashes and slowdowns is instantaneous peak.
So while marketing speaks in terms of transactions a day or even unique customers on the site, the only measurement
useful for capacity planning is how many people were on the website at the same time, the instantaneous peak. By on
the website, I mean looking at their browsers at a page on the website, regardless of whether that customer is reading or
clicking. Its tempting to use hits/sec or transactions/sec, which are fine metrics, but what happens when you redesign
the site for higher performance and the number of hits/sec or transactions/sec drops as a result? The capacity of the site
may have gone up, but the number of hits/sec would drop. In the end you need a metric that is implementation
independent.
The question of figuring out the maximum number of concurrent users is made even more difficult because a surprising
number of people tasked with speccing a website dont understand the business, and that is critical to increasing the
accuracy of the estimate. In the end, it is still a guessing game, not only because of the unknowns, but because it
involves the future. Even if you have an existing website with accurate web logs, its impossible to tell the future and
guarantee that there wont be a huge traffic spike someday.
So, it is impossible to be really accurate and were reduced to being close enough. What are the penalties for getting it
wrong? Guess too low, and a site may experience a slowdown or crash during a critical period. Will that merely annoy
your customers, or will the company lose money? If its the later, then it pays to reduce the chances of a crash
happening. But what happens if you over spec a site and theres too much excess capacity? The downside is added cost
and complexity, but thats the price that needs to be paid for reducing the risk; in this way, building in excess load
capacity is like insurance.
Lets take a look at what the typical systems engineer has in terms of information. If the site exists at least theres some
data, although it almost never has the information thats actually needed. The information that comes from the site tends
to be marketing statistics. Thats nice, but how in the world can you possibly figure out the simultaneous peak user load
from that?
Obviously the more information you have about a business the more accurate the guesses, but lets start with a common
situation: the person setting up the website has no idea about the business and no way of getting any information. It
sounds strange, but that happens more often that you would believe.
For example, lets say marketing reports that the site either has or expects to have an average of 150,000 visitors per
month. First calculation is easy: figure out the number of visitors per day. If the site is used equally 7 days a week, then
divide by 30. If, however, the site is used mostly during the week youd divide by the number of non-weekend days in a
month, around 21.7.
For the sake of simplicity lets assume the site is used equally throughout the week for a per-day visitor number of
5,000. The next step is to figure out how many hours of the day the site is most active, which will differ from business to
business. If you actually know the nature of the business and can identify the peak hours, then by all means, use those,
but if you dont, then figure on using 12 hours as a rule of thumb.
Average visits per hour = (5000 average visitors/day) / 12 hours = 417
To figure out the average concurrent users you need to know the average length a user stays on the site. This can be
obtained either from the web metrics, or, if that isnt available, using a stopwatch and going through a couple of user
scenarios yourself on the site, reading all of the material and filling out forms just like a typical user.
Once you know the average visit length, you can then calculate average concurrent users. The key to understanding this
calculation is the concept of levels of concurrency. If a user spends on average 10 minutes on a site, then one level of
concurrency, i.e. one user simulator could simulate 6 visits in an hour, 60 minutes divided by six minutes per visit.

Average Concurrent Users = Visits per hour / (60 min/hour / average visit)
Using the 10 minute figure above, with an hourly visit rate of 417 gives an average concurrent user level of just 69, a far
cry from the 150,000 per month figure we started with. The math isnt hard, but its faster to type into the online form
we use every day at Web Performance, Inc..
Check out this great easy-to-use online calculator:
http://www.webperformance.com/library/tutorials/CalculateNumberOfLoadtestUsers/
Now we know the average number of users on the site at one time, which is useful, but is still short of the number we
need to know: the instantaneous peak number of concurrent users. Based on absolutely no science whatsoever, in the
load testing business we use a multiplier range from 3 to 6 depending on the accuracy of the average concurrent user
number.
The more important it is to your business to not have a slowdown, the higher the multiple. In the above example that
would put your safe number of concurrent users at 414, the target that would need to be verified by a load test.
As an engineer it bothers me having to guess at these numbers, but then again, guessing is part of engineering. As more
websites switch to the automatically scalable architectures enabled by cloud-computing this type of guesswork will be
less important. Until then, run these calculations on your own website and let me know how close or how far they come
to reality.

ANNEXURE-L
3
(i) The
iii. bidder
Risk Management
Year
Date

List
out and
NAME
OFgive
THEPresent Status of
shallPlan
have
iv.
Number of
each of awarded
FIRM
PRE-QUALIFICATION (TECHNICAL
executed
Anything
or Else asBID SHEET)
Works/Projects work/project
Place
executing
deemed
to fit
theby bidder
Awarded to
(attach self
"Web Based8 Application
for
MG
A Module
Based
Process Automation thro
satisfaction
Application
of NREGS
Software Acomplete
bidder
write-up
[(i) work
attested
Technical Evalution
government
Proposed
and technical
order No, (ii) COMPANY/FIRM
documentary
SEAL
department or
proposalAwarding
on the Agency
proof of the
A
Name of the Firm
PSU/Board one
points mentioned
Name, (iii) Date status)
IT works of
shall be submitted
of Award, (iv)
B
Tender No
value not less
and attached
Financial
as Value
C
Item Particulars
than 10 Crore
detailed of
and
Award, (v) Year
S.No
rupees; OR, (ii)
separateofwrite-up.
award (attach
1
The bidder shall be in IT business and worked for a Year
Shall have
Done or self
Not attested
Done? copy
Government Department or a Govt Public Sector
executed
Give technical
or
as proof of
Undertaking in the last three years (as on
executing
detailstoofthe
the
claims)
01.01.2013) [LoI/Work order/Completion
satisfaction
solutionof
proposed,
Certificates]
department
brand and
twomake of
IT works
products,
of notsoftware
less solution
than 5 architecture
Crores
details
Rupees
each;
Training
OR, (iii)
A complete write-up
9
2009-10
ShallManagement
have
(1)
and technical
2010-11
executed
Training
or Plan (2) proposal on the
2011-12
executing
EarliertoTrainings
the
points mentioned
satisfaction
Give No of
of Trainees shall be submitted
2012-13
department
in
Last
Two
Years.
and
attached
as
2
The bidder must have implemented at least three
Year
threeWork
IT works of web-based
detailed
and solutions either for
software
not less
Order/Agreement
than 3
separate
write-up.
Government
of Karnataka/Government
of
Crore
copy
Ruppees
and training
Donestate
or Not
Done? If or for Govt
India/other
governments
eachcertificate must
be done then
numbers
Boards/Govt
PSUs/Govt
Corporations as on
provided as a2009-10
proof.
or
shall
be
given
01.01.2013
The bidder shall
before
10
indicate any 2010-11
deviations to2011-12
terms
and conditions if
2012-13
2009-10 or before
any, otherwise
it will
2010-11
be presumed that, Total No of Projects
+ Financial Value
the bidder has
2011-12
4
Theaccepted
bidder shall
Attach
Attached or Not
terms
andSelf
2012-13
not have
been ofDeclaration
Attached
conditions
the
blacklisted
by
tender (substantial
Government
deviationoffrom terms
Karnataka/Gover
& conditions shall
nment
of to rejection of
lead
India/other
the bid state
as
governments
technically
and unresponsive)
their
PSUs/Boards/Co
rporations
5
Organizational
Turnover
(in Attach
self
This is to certify that the undersigned
has read
the complete
RFP
and the tender
Rs
Crores)
attestedChartered
documents along with the Anneuxures and understood them; and accepts all the
Accountant
Profit-Loss
terms & conditions laid therein. Further it is to certify that
the information
submitted
Account
and
Balance
Sheet
above and elsewhere by the FIRM/undersigned is true and correct to the
best of
my
(Year
Wise)
knowledge and belief. It is certified that I am authorized to act on behalf of the FIRM
I am claiming to be the Authorized2009-10
Representative/Signatory of.
2010-11
Signatures WITH
2011-12
Seal of
6
Experience eAwarded
Authorized
Gov Projects or
Signatory
IT Projects in
Name of
Government or
Authorized
Govt PSU
Signatory
within last SIX
Deisgnation of
YEARS (number
the Authorized
of projects
Signatory
awarded and
Address for
correspondence
of Authorized