Model DPR Guidelines

e-Governance in Municipalities: Model DPR Guidelines for State Level DPR
Ministry of Urban Development
e-Governance in Municipalities
Model DPR Guidelines

For
State Level Detailed Project Report
April 2010

Contents
Abbreviations & Acronyms _____________________________________________ 1
List of Tables ________________________________________________________ 3
Preface _____________________________________________________________ 5
General Instructions for DPR Preparation_________________________________ 7
1.
Background of the Project ________________________________________ 8
1.1
Title of the Project __________________________________________________ 8
1.2
Mission Mode Project _______________________________________________ 8
1.3
Project Funding Criteria ____________________________________________ 8
1.4
Permissible Components _____________________________________________ 8
1.5
Project Phases _____________________________________________________ 9
1.6
Details of stakeholders ______________________________________________ 9
1.7
Approval of Appraisal Report: ______________________________________ 10
2.
Project Overview ______________________________________________ 11
2.1
Goals ____________________________________________________________ 11
2.2
Benefits __________________________________________________________ 11
2.3
Objectives ________________________________________________________ 12
2.4
Project Institutional Structure _______________________________________ 13
3.
Urban Services & Service Levels __________________________________ 15
3.1
Overview _________________________________________________________ 15
3.2
Services proposed through State Level Solution ________________________ 15
3.3
Organization Structure, Functions and Services of Departments __________ 16
3.4
Study of Municipal Acts and Byelaws _________________________________ 17
3.5
Study of Other e-Governance Initiatives ______________________________ 18
3.6
Business Process Reengineering (TO-BE Process) _______________________ 18
3.7
Proposed Service Level Benchmarks __________________________________ 18
3.8
Perceived Benefits _________________________________________________ 19
4. Solution and Technology __________________________________________ 21

4.1
AS-IS IT landscape ________________________________________________ 21

Application Details ____________________________________________________ 21
Hardware, Network Infrastructure Components ____________________________ 21
Network / Server Architecture ___________________________________________ 22
Information Security Measures __________________________________________ 23
4.1.1
4.1.2
4.1.3
4.1.4
4.2
TO-BE IT Landscape ______________________________________________ 23

Solution Architecture __________________________________________________ 23
Application Architecture________________________________________________ 25
Information / Data Architecture _________________________________________ 26
4.2.1
4.2.2
4.2.3

4.2.4
4.2.5
4.2.6
4.2.7
4.2.8
4.2.9
Technology / Deployment Architecture ____________________________________ 26

User Interface_________________________________________________________ 27
Network and Server Architecture ________________________________________ 28
Security architecture ___________________________________________________ 30
Integration with SWAN & SDC __________________________________________ 31
Service Level Agreements (SLA) & Monitoring Tool ________________________ 31
4.3
Conformance to Standards __________________________________________ 31

4.3.1 Interoperability Standards ______________________________________________ 31
4.3.2 Data Standards _______________________________________________________ 32
4.3.3 Security Standards ____________________________________________________ 32
4.3.4 Localization Standards _________________________________________________ 32
4.4
IT Change Management ____________________________________________ 32
4.5
Service Provision & Consumption by ULBs ___________________________ 32
4.6
Continuity Measures _______________________________________________ 32
4.7
Support/ Help Desk ________________________________________________ 32
4.8
Roll out Strategy __________________________________________________ 32
4.9
Option Analysis ___________________________________________________ 33
5.
Capacity Building and Change Management _______________________ 34
5.1
Need for Change Management _______________________________________ 34
5.2
Identification of Stakeholders _______________________________________ 34
5.3
Organization Structure _____________________________________________ 35

Current Organization __________________________________________________ 35
Proposed Organization _________________________________________________ 35
5.3.1
5.3.3
5.4
Staffing and Deployment Strategy ____________________________________ 36
5.5
Training Strategy __________________________________________________ 36

Training Need Assessment and Content Development ________________________ 36
Identification of Delivery Channels for imparting training ____________________ 37
Preparation of Training Schedule ________________________________________ 37
5.5.1
5.5.2
5.5.3
5.6
Knowledge Management____________________________________________ 37
Monitoring & Evaluation __________________________________________ 38

6.1
Monitoring & Evaluation Framework ________________________________ 38

Clearly defined Objectives ____________________________________________ 38
Define Organization and Identify Roles and Responsibilities ________________ 39
Approach for M&E process ___________________________________________ 40
6.1.1
6.1.2
6.1.3
Assumptions & Risk Management ___________________________________ 43

7.1
Process for Risk Management _______________________________________ 43
Pubic Private Partnership (PPP) ____________________________________ 49

8.1
Need for PPP _____________________________________________________ 49
8.2
PPP for e-Governance ______________________________________________ 49
8.3
Engagement Models for Service Provisioning & Service Delivery__________ 50
8.4
Revenue Model ____________________________________________________ 50

8.5
Key considerations _________________________________________________ 51
Project Implementation Strategy & Sustainability Plan __________________ 53

9.1
Stakeholders Involvement___________________________________________ 53
9.2
Institutional Structure______________________________________________ 53
9.3
Tendering and Bid Process Management ______________________________ 54
9.4
Project Implementation & Rollout ___________________________________ 54
9.5
Project Phasing Strategy ____________________________________________ 54
9.6
Sustainability Plan _________________________________________________ 55
10
Project Costing ________________________________________________ 57
10.1
Detailed Bill of Material For State level solution ________________________ 57
10.2
Detailed Bill of Material For Roll out in Selected ULB _________________ 59
10.3
Financing Plan ____________________________________________________ 61
11
Annexures ____________________________________________________ 62
11.1
Annexure 1 - Checklist for State Level Nodal Agency____________________ 62
11.2
Annexure 2 Functional Requirement Specifications ___________________ 66
11.3
Annexure 3- Risk Log _____________________________________________ 118

Abbreviations & Acronyms

Description
ACA
Additional Central Assistance
BOM
Bill of Material
CBOs
Community Based Organization
CEO
Chief Executive Officer
CSC
Citizen Service Centre
CSMC
Central Sanctioning Monitoring Committee
D2D
Department to Department
DPR
Detailed Project Report
G2B
Government to Business
G2C
Government to Citizen
G2G
Government to Government
HR
Human Resources
ICT
Information and Communication Technology
JNNURM
Jawaharlal Nehru Urban Renewal Mission
MeDD
Municipal e-Governance Design Document
MIS
Management Information System
MMPs
Mission Mode Projects
MoUD
NeGP
National e-Governance Programme
NGOs
Non Government Organizations
NMMP
National Mission Mode Project
POP
Point of Presence
PPP
Public Private Partnership
RWAs
SDC
Resident Welfare Association

State Date Centre


SeMT
SIC
Description
State e-Governance Mission Team
State Implementation Consultant
SLNA
State Level Nodal Agency
SLSC
State Level Steering Committee
SLSS
State Level Software Solution
SMART
Specific, Measurable, Achievable, Realistic, Time bound
SWAN
State Wide Area Network
ULB
Urban Local Body
M&E
Monitoring and Evaluation

List of Tables
Table
Number
Description
List of Identified eight Services
Project Funding Criteria
Total Project Cost
Population Details of State and Selected ULB
Municipal Revenue & Expenditure for Selected ULB
Services proposed through State Level Software Solution (SLSS)
Departments, Functions and Inter-Relation of Selected ULB
Classification of ULBs
Summary of Municipal Acts and Bye-Laws
10
Variation points w.r.t. Municipal Acts & Bye-Laws
11
Proposed Service Level Benchmarks
12
Benefits Perceived
13
Details of Existing IT System/ Applications
14
Details of Hardware, Network & Infrastructure (Existing)
15
Present Status of SWAN, SDC and CFCs
16
Network / Server Architecture for Existing System
17
Details of Application Architecture
18
Details of Information / Data Architecture
19
Details of Application Interfaces
20
Network / Server Architecture for Proposed System
21
Option Analysis for Selecting Proposed Technology
22
Stakeholder Identification

Table
Number
Description
23
Objectives for Monitoring &Evaluation
24
Roles & Responsibilities for Monitoring &Evaluation
25
Approach for Monitoring &Evaluation
26
Monitoring Process : Ownership & Timeframe
27
Strategy Level Risks
28
Project Level Risks
29
Operational Level Risks
30
Calculation of Risk Measure
31
Chart for Risk Ranking
32
Stakeholder Involvement
33
Timeline Completion for Key Milestones
34
Sustainability and Key factors
35
State: Summary of Project Cost (Investment & Recurring Costs)
36
State : Year-wise Expenditure Distribution
37
Selected ULB: Summary of Project Cost (Investment & Recurring Costs)
38
Selected ULB: Year-wise Expenditure Distribution
39
Financing Plan (Central/ State / ULB share)

Preface
The Government of India has formulated the National e Governance Plan (NeGP), part of
which includes a National Mission Mode Programme (NMMP) for e Governance in
Municipalities. This NMMP intends to roll out e-Governance in Municipalities on a nationwide basis and has now been included as a part of the Jawaharlal Nehru Urban Renewal
Mission (JNNURM). National Mission Mode Project (NMMP) on e-Governance in
Municipalities envisages covering Urban Local Bodies (ULBs) in 35 mission cities identified.
e-Governance in Municipalities is expected to:
Focus on clearly identified list of citizen services that would be covered with clearly
laid down service levels and outcomes that would be achieved.
Improve efficiency and effectiveness in interaction between local-government and its
citizens and other stakeholders (i.e. Non-governmental organizations (NGOs),
community based organizations (CBOs), residents welfare associations (RWAs),
private sector, etc);
Improve quality of internal local-government operations to support and stimulate
good governance;
Bring about transparency and accountability in the governance of urban local bodies;
Enhance interface between urban local bodies and citizens; and
Help improve delivery of services to citizens.
Thus for the ULBs/Corporation, the NMMP would:
Bring about improvements in efficiency and effectiveness of business

processes/functions of the ULBs/Corporation
Institute a mechanism of result based monitoring and evaluation
Ensure economy (cost efficiency) in the design and implementation of the project
Improve the system for decision making with respect to planning and delivery of
municipal services to the citizen and with in.
Ensure effective project management to track progress.
For the Citizens, the NMMP would:
Significantly improve the Quality of Service provided by the Corporation

Transparent, effective and efficient service delivery to the Citizen.
Provide more service delivery channels for hassle free service for Citizen
Define service level for timely delivery of services to the Citizen
Following are the services / management functions that will be covered in the first phase of
the project, as provided in e-Governance guidelines of JNNURM as in Table 1
Table 1: List of identified eight services
S.No.
Services/ Management Functions
Registration and Issue of Births/ Deaths Certificate
Payment of Property Tax, Utilities Bills and Management of Utilities that

S.No.
Services/ Management Functions

come under the ULBs
2.1
Property Tax
2.2
Water Supply & Other Utilities
Grievances and Suggestions
Building Approvals
Procurement and Monitoring of Projects
5.1
e-Procurement
5.2
Project/ Ward works
Health Programs
6.1
Licenses
6.2
Solid Waste Management
Accounting System
Personnel Information System
The SLNA/ ULB will prepare Detailed Project Report (DPR) for development of State Level
Software Solution (SLSS) of e-Governance in municipalities to be covered under the Mission
Mode Project on e-Governance. This document provides reference format and guidelines for
preparing State Level DPR for e-Governance project in ULBs. This document has been
prepared in reference to Municipal e-Governance Design Document (MeDD) prepared by
MoUD, guidelines for preparation of DPR by Ministry of Information Technology (MIT), eGovernance guidelines under JNNURM etc.

General Instructions for DPR Preparation

A general reference framework for preparation of DPR at State level is mentioned below:
DPR for state level solution shall be prepared and submitted by selected ULB along
with the state (SLNA).
The state level DPR will cover design, development, implementation and roll-out of
the state level software solution (SLSS) including O&M for 2 years.
The DPR will also include the IT infrastructure requirements & application
customization requirements for selected ULB, in order to avail the services from
SLSS.
DPR shall indicate sustainability of SLSS (provisioning and delivery), in terms of

PPP, beyond 2 years of operations.
The DPR shall also indicate the capacity building requirements for state and selected
ULB.
The DPR is to be accompanied by a separate Executive Summary, which should

essentially provide summary / snap shot of all sections of DPR.
The DPR shall be appraised by SLNA at state level as per checklist attached at
Annexure-1 and the approval note should be accompanied with DPR.
The DPR is to take into account the various open standards published/ being
published by GOI under NeGP (http://egovstandards.gov.in)
Further feedback and suggestions for improving the DPR Preparation Toolkit are
welcome and may be suggested to the MoUD.

1. Background of the Project

This section requires information as per the template/format provided below which covers
details like Project Title, Funding Criteria, Project Eligibility Test, Nature of e-Governance
project, the Initiating and Implementing partners of the project.
1.1
Title of the Project
The title of the project should describe the proposed services to be provided under the project,
period and location of implementation and any other critical aspects.
1.2
Mission Mode Project
The DPR should mention in this section if the proposed state falls under the purview of
JNNURM Mission Mode Projects.
1.3
Project Funding Criteria
All the DPRs will follow the funding pattern as per JNNURM Guidelines.
Table 2: Project Funding Criteria
S.No.
Category of Cities
Grants
Central State
ULB or para statal

share / loan from
financial institution
Cities/UA with 4 million

population as per 2001 census
plus
35%
15%
50%
Cities/UA with million plus but less

than 4 million population as per 2001
census
50%
20%
30%
1.4
Permissible Components
The permissible components as per JNNURM guidelines include:

Application software
Capital and initial costs including hardware, infrastructure and system software
Cost for GIS (Application, platform etc.)
Data digitization
Cost for STQC certification
Cost for Monitoring Tool & Helpdesk
Project Management
Cost for Change Management through Capacity building & Knowledge Management
Annual expenditure cost (operation & maintenance cost / ongoing communication
cost/ license fees etc.) for first two years after commissioning
The cost of land and building, site preparation, civil infrastructure, employees cost, electricity
and communication costs, etc. is not included under permissible components; and shall be
borne by State Government / ULB.

1.5
Project Phases
In this section, the DPR shall clearly mention all the phases of the Project and implementation
in addition to a strategy for carrying out the activities of various phases in detail.
1.5.1
Pilot Phase
The e-governance project implementation undertaken by State shall be categorized as a Pilot

when rolling out of SLSS is carried out in selected ULB or other mission cities for the first
time.
1.5.2
Roll out subsequent to Pilot phase
In this section, the DPR shall define a road map/ strategy for roll out of SLSS in the
remaining mission cities of the state. The DPR shall also mention how the learning for the
pilot phase shall be incorporated while rolling out the solution in a large scale.
1.6
Details of stakeholders
Project Initiator Details

In this section, the DPR shall provide the details of SLNA/ULB if specific department is
initiating and the name and job title of the key contact person who would be responsible for
initiation and rollout of the e-Governance project in the SLNA/ULB. For example, The
Commissioner / CEO / Executive Officer etc. The contact details of nodal officer other than
the person responsible, for follow-up and liaison work related to the proposal should also be
provided.
Contact details
Name
Designation
Address
Fax
Landline
Mobile
Email
:
:
:
:
:
:
:
Implementing Agency/ Partner Details

In this section, the DPR shall provide the contact details of nodal officers/ key persons
responsible for State Level Nodal Agency (SLNA), State Implementation Consultant (SIC),
State e-Governance Mission Team (SeMT) and liaison work related to the above should be
provided by ULB.
State Level Nodal Agency (SLNA)
Name
Address
Fax
Landline
Mobile
Email
:
:
:
:
:
:

State Implmentation Consultant (SIC)
Name
Address
Fax
Landline
Mobile
Email
:
:
:
:
:
:
State e-Governance Mission Team (SeMT)
1.7
Name
Address
Fax
Landline
Mobile
Email
:
:
:
:
:
:
Approval of Appraisal Report:
The SLNA/ULB shall provide details about appraised project details by State Level
Steering Committee (SLSC) to State Level Nodal Agency (SLNA) and whether the
project is considered for approval by SLSC. The appraisal report of the SLNA shall be
provided along with the DPR.
10

2.
Project Overview
Based on the project background details, the DPR shall define goals & objectives of the
project. Examples are provided in this section for easy understanding and reference purposes.
2.1
Goals
Goals are high order objectives/long term outcomes that the project shall contribute. The
general practices of the project are guided by goals. It is critical to set realistic and relevant
goal(s) for the project as it helps to:
Plan an approach for implementing the project

Provide a systematic way for evaluating performance
Ensure greater buy-in through most of the organization
Ensure that results obtained are not erratic in nature
For example: Ensure satisfied citizens and government by developing a hassle free and
transparent e-governance solution enabling increased levels of service delivery to citizens.
2.2
Benefits
The JNNURM guidelines have laid down the outcomes that are desired as part of the National
Mission Mode Project for e-Governance in Municipalities. The service levels are desired to
ensure efficiency, transparency and reliability of such services at affordable costs to realize
the basic needs of common citizens. The impact of successfully achieving this vision would
be a more satisfied citizen/ business/ government. Thus, each goal should state the impact in
terms of:
Benefits to Citizens / Community

Benefits to Government
Benefits to Business
General/ Mutual benefits
Examples of benefits:
Decrease in cost of accessing/ using services
Free availability of application forms online etc.
Reduction in time for accessing/ using services
By instant uploading of online applications leading to automated approval process etc.
Improved quality of services
Lack of errors in processed documents etc.
Reduction in red tape
Reduction in number of levels required for approval etc.
Simplification of procedures
No need to visit various Departments/Offices for approvals, sanctions etc.
11

2.3
Objectives
Identify SMART Objectives : Objectives are the specific and immediate outcomes of the
project. S.M.A.R.T refers to the acronym that describes the key characteristics of meaningful
objectives, which are Specific, Measurable, Achievable, Realistic and Time Bound.
Specific (concrete, detailed, well defined): Specific means that the objective is
concrete, detailed, focused and well defined. Objectives must be straight-forward and
emphasize action and the required outcome.
Measurable (numbers, quantity, etc.): If the objective is measurable, it means that the
measurement source is identified and we are able to track the actions as we progress
towards the objective. Measurement is the standard used for comparison.
Achievable (feasible, actionable): Objectives need to be achievable because if the

objective is too far in the future, it will be difficult to remain motivated and strive to
attain it.
Realistic (considering resources): The achievement of an objective requires various

resources, such as, skills, money, equipment, etc. Realistic means that all such
essential resources are available or possible to arrange.
Time-Bound (a defined time line): Time-bound means setting deadlines for the
achievement of the objective. Deadlines need to be both achievable and realistic.
Example of SMART objectives:
2.4
the
Minimizing the number of customer visits for registration of birth and death from 5 to 2 times.
Reducing the time required to request the service by 50% and overhead costs by 20%.
Solving 100% grievances within stipulated time of 3 months
The following captures an analysis of these criteria for the stated objective:
Summary of Total Project Cost
An overall cost estimate shall be prepared for the complete duration of the project ( 1 year
implementation & 2 years of O&M) with documented assumptions against each item. The
cost in the state level DPR shall include both:
Cost for design, development, implementation of SLSS

Cost for solution roll out in Selected ULB
A summary of total project cost estimated shall be provided in the format given in Table 3
below.
12

Table 3: Total Project Cost (INR in Lakhs)
Costs
Year 1
Year 2
Year 3
a). Cost for State level Software Solution (SLSS)

Capital/ Investment Costs
Recurring Costs
Total (a)
b). Cost for solution roll out in Selected ULB
Capital/ Investment Costs
Recurring Costs
Total (b)
Grand Total (a+b)
2.4
Project Institutional Structure
2.4.1
State level Institutional Structure
In this section, DPR shall mention setting up a steering committee at the state to provide
guidance and assistance for implementation and rollout. It shall include the details of
arrangements such as
Project Steering Committee
Project management team comprising of representatives from state, ULBs and SIC
SLNA shall also create the following teams under its control to carry out the overall project
implementation and monitoring.
Process Team comprising of domain expert(s), representative from identified ULBs

covering all 8 service areas to define the standard processes and to standardize forms
for each of the service areas across State.
Technology Team comprising of dedicated technical member of SLNA, SIC, SeMT

representatives to define metadata standards, interoperability compliances, defining
and monitoring service levels, information security, data protection and exercising
strategic control of IT assets.
Capacity Building Team comprising of Capacity Building & Knowledge

Management Expert and domain expert(s) for managing the Capacity Building and
Knowledge Management with ULBs and at SLNA as well in alignment with the
framework defined by MoUD.
SLNA shall clearly define the roles and responsibilities of all the teams. Further, DRP should
also propose the contractual arrangements between SLNA, ULBs and Agency for project
implementation & rollout. Also, the road map/ phasing strategy for all ULBs (under mission
and non-mission cities)for joining the state level solution needs to defined in the DPR.
13

2.4.2 State Implementation Consultant (SIC)

In this section, DPR should identify engagement of a State Implementation Consultant to
assist the SLNA in preparation of State level DPR, RFP, Bid process management for
selection of Software Development Agency (SDA) / Application Service Provider (ASP),
overall project management from project inception to implementation stage and co-ordination
with various stakeholders.
14

3.
Urban Services & Service Levels
3.1
Overview
In this section, the DPR shall provide details like demographic characteristics of the State,
population growth, economic base, key drivers of economy and municipal revenues &
expenditure for the selected ULB.
Table 4: Population Details of State and Selected ULB
S.No.
Year
Population (lakh)
1981
1991
2001
2011(Projected)
Average Annual
Growth Rate (%)
Table 5: Municipal Revenue & Expenditure for Selected ULB

S.No.
Year
Revenue ( Rs. Lakhs)

Tax
2005-06
2006-07
2007-08
2008-09
2009-10
Non Tax
Expenditure
( Rs. Lakhs)
State Transfers
/ Grants
3.2 Services proposed through State Level Solution

In this section, the DPR would detail out the services to be provided as part of SLSS. The
services provided shall be categorized as G2C Government to Citizen, G2B Government
to Business, G2G Government to Government as well as services having internal and
external interfaces.
For example: Services associated with citizens should be classified as External and services
associated with internal working of the department, like staff management etc. should be
classified as Internal. The same has been given in Table 6 below.
15

Table 6: Services proposed through State Level Software Solution (SLSS)

S.No.
Reform Areas
Service
Interface
Function
Service
Category
Registration and Issue of Births / Deaths

Certificate
External
G2C
Property Tax, Utility Bills and Management of

Utilities that come under the ULBs e.g. Water
Supply
External
G2C
External
G2C
Building Approvals
External
G2C, G2B
Internal /
External
G2G
Health Program : Licenses, Solid Waste

Management
External
G2B / G2C
Accounting System
Internal
D2D
Internal
D2D
Any other Module

(The DPR should mention details of other modules
which has been already existing and other than this
which is proposed for development &
implementation but not part of the above core
JNNURM modules)
3.3 Organization Structure, Functions and Services of Departments

The DPR shall document the Organization structure, functions and services of the department
in the Selected ULB, providing the eight identified services. A similar detailing shall be
provided for the related department, incase the state identifies to implement services beyond
the eight defined under JnNURM guidelines. DPR shall also capture the current state of
affairs of various departments and map the services and associated processes at the
Department & its related branches and interlinked organizations.
Table 7: Departments, Functions and Inter-Relation of Selected ULB
Department
Function
Services
16
Associated
Processes
Inter-relation

3.4 Study of Municipal Acts and Byelaws

In this section, the DPR shall detail out on the following:
a. The DPR shall indicate the number/ classification of cities (as per the definition of the
project i.e. Mission Cities, Class-I cities and other cities) and number of ULBs for the
respective cities in below table:
Table 8: Classification of ULBs
Cities
(JNNURM
Mission Cites/
Class-I/
Others)
No. of
Municipalities
No. of
Corporations
No. of Notified
Area Authority
Any Other
b. Details on Municipal Act(s) in the state and byelaws in the ULBs (for pilot study, ULBs
for mission cities / class-I cities or beyond can be considered) in table below. The DPR
shall also provide details of municipal act(s) and byelaws in the table 9 and variations in
table 10 below.
Table 9: Summary of Municipal Acts and Bye-Laws
Act(s) of State
Bye-Laws
Prevailing in
< Specify the name of

ULB>
Table 10: Variation points w.r.t. Municipal Acts & Bye-Laws

S.No.
Details of the Services
Municipal Acts
JNNURM Core Modules

1
Registration and Issue of Births / Deaths

Certificate
Property Tax, Utility Bills and Management

of Utilities that come under ULBs e.g. Water
Supply
Building Approvals
17
Bye-Laws

S.No.
Details of the Services
Municipal Acts
Health Program: Licenses, Solid Waste

Management
Accounting System
Bye-Laws
Other Modules
(Other modules to be mentioned here)
3.5
Study of Other e-Governance Initiatives
In this section, DPR shall provide details on existing status and level of implementation of
other e-Governance initiatives like SWAN/ SDC/ CSC etc. in the State.
3.6
Business Process Reengineering (TO-BE Process)
Based on the study conducted in the pilot ULBs in the above section, this section shall
include:
Analysis of existing processes for identified services under SLSS

Identify gaps and areas of process improvement
Design of optimal process for each service catering to the needs of ULBs
Customization requirements based on specific variation in processes, functionalities,
workflow etc. of ULBs with respect to SLSS
Detailed To-Be process flow diagrams along with workflow, inputs, outputs, users
*Note: The details of the proposed modules have to be covered in terms of functional
requirement specifications has been provided in Annexure 2 separately.
3.7
Proposed Service Level Benchmarks
In this section, the DPR shall identify service level benchmarks for each service module (as
per below table), in line with Handbook on Service Level Benchmarks for e-Governance in
Municipalities published at the national level. A roadmap on how these service levels shall
be attained needs to be provided. In case the state chooses an intermediary service level
during the initial phases of the project, the an intermediary service level should be clearly
defined and roadmap & timeline for achieving the final service levels should also be
provided.
18

Table 11: Proposed Service Level Benchmarks

S.No.
Service Modules
Service Level
Benchmarks
Intermediary
Service Level
Benchmarks
(if any)
Timelines to
achieve the
final Service
Level
Benchmarks
JNNURM Core Modules

1
Registration and Issue of Births /

Deaths Certificate
Property Tax, Utility Bills and

Management of Utilities that
come under the ULBs e.g. Water
Supply
Building Approvals
Procurement and Monitoring of

Projects
Health Program : Licenses, Solid

Waste Management
Accounting System

Other Modules
3.8
(The DPR should mention

details of other modules which
has been already existing and
other than this which is proposed
for development &
implementation but not part of
the above core JNNURM
modules )
Perceived Benefits
The DPR shall also detail out the benefits for the various categories of stakeholders like
citizens, SLNA, ULB, vendors, etc.
For example : The value/ benefits can be in terms of indicators like reduction in time-frame
for processing of activity/ service/ function etc, reduction in terms of costing, etc.
The details for the same shall be provided in the table 12 below.
19

Table 12: Benefits Perceived

S.
No.
Services
Birth Registration System
Payment of property Tax
Payment of Water Supply &

Other Utilities
Grievances & Suggestions
Building Approval
e-Procurement
Monitoring of Projects /
Ward Works
Licenses
Solid Waste Management
10
Accounting System
11
Personnel Information
System
Delivery
Channel
Time
Taken
Efficiency /
Functionality
Corporation /
Citizen Centers
/ Web enabled
Min/
Hrs /
Days
%
( Internal/
External )
20
User
Charges (eGov)
(Rs)
Cost of
Service
Frequency
of Visits
(Rs)
Number of
visits
required
Benefits to
Citizens
Benefits
to ULBs

4.
Solution and Technology
This section shall provide the details of SLSS fulfilling the key requirements from technology
prospective, keeping in view the centralized e-Governance solution being conceptualized,
designed, developed and implemented to deliver identified services. This solution must cater
to the Municipal Act(s) of the State, and should have the provision for ULB specific
customizations. It should be designed in a way to manage the variations in bye laws of ULBs.
4.1
AS-IS IT landscape
This section shall provide details of IT software applications, and infrastructure that currently
exists in the state.
4.1.1
Application Details
This section of DPR shall provide details about applications that are currently available
in the state. The details of such applications are to be provided as per below table.
Table 13: Details of Existing IT System/ Applications in State
S#
Applicatio
n Suites /
Modules
Services
Performe
d by
Applicati
on Suite
Year of
Implem
entation
Technology
Platform
(Complete
technology
stack
including
front end,
back end,
middleware
etc.)
Applicat
ion
Architec
ture
No of Users,
Transaction
Volume per
year & data
volume
1
2
4.1.2
Hardware, Network Infrastructure Components
In this section, the DPR shall provide details on existing hardware, network & infrastructure
components (if any) available in the state and how the existing components can be re-used or
integrated with the proposed setup.
The DPR shall also provide details of number of physical locations, departments / offices,
users in the department, existing delivery channels like Citizen Facilitation Centers (CFC),
SWAN, SDC etc.
Table 14: Details of Hardware, Network & Infrastructure (Existing)
S.No.
Department
/ Location
List of Hardware, Network

Infrastructure
(Existing)
21
Re-usability
(Yes/ No)
Impleme
nted At
(State /
ULB
Name)

S.No.
Department
/ Location
List of Hardware, Network

Infrastructure
(Existing)
Re-usability
(Yes/ No)
Table 15: Present Status of SWAN, SDC, CFCs etc.

S.No.
Component
Status
Re-usability status
(Yes/ No)
1
2
3
4.1.3
Network / Server Architecture
This section shall provide details of existing network/server architecture (if any) of the state:
A detailed diagram of current network & server architecture should be provided.
Existing network architecture/devices details (including disaster recovery, hosting servers
etc.) that can be used by the state.
Table 16: Network / Server Architecture for Existing System
Existing (AS-IS) Scenario
Description
Location 1
Location 2
Location 3
Location
(n)
Total
Back-end (including database management tools used)
Middle ware (including application software)
Front-end delivery channels (including application software)
Network devices (the existing network design should be provided schematically separately)
22

4.1.4
Information Security Measures
The following are the key points that need to be discussed in this section with regard to
managing data security:
Details of any existing security policies

Detailed inventory of security related applications / hardware such as firewalls, antivirus servers, intrusion detection systems etc.
State should examine if the current security measures can be re-used for the proposed egovernance infrastructure. The same should be clearly mentioned in the DPR.
4.2
TO-BE IT Landscape
State Level Software Solution (SLSS) is the centralized solution that would facilitate the
delivery of municipal services to various stakeholders across the state. The centralized
application software shall deliver all the identified services, as per JNNURM guidelines.
In this section, DPR shall describe the technical components required as a part of the
centralized solution to be deployed. This should include technology platforms, database
software, application / web server software, application frameworks/products or any other
component that shall be used to implement the solution. In case different modules use
different technology components, all details for all these modules shall be included.
4.2.1
Solution Architecture
The SLSS architecture should address the following requirements:

(i)
Multi-tenant Environment: Considering the federal structure and independence of

ULBs, the SLSS should be designed in a way to provide independence to ULBs to
manage their data and environment. This section should provide details on how the
administration of application for individual ULB in the state, in terms of following,
shall be done:
i. Creation and management of access and login rights
ii. Handling ULB specific business logic and bye-laws
iii. Customizations specific to ULBs for dynamic business workflow,
forms/reports, language, look and feel
iv. Management of ULB content in the application
(ii)
Customization of Existing Applications:

The DPR should provide details about the viability of customization or incorporation
of existing applications (identified in section 4.1.1) into new application and should
cover the following details:
i. Strategy for customization, integration & testing of existing modules with
SLSS including details about maintenance support for 3 years.
(iii)
Plug & Play Facility: The SLSS should be able to provide independence to ULBs in
availing selected services, as required.
(iv)
Scalability: The solution architecture should be able to address the future scalability
requirements, in terms of both application (to add new services in SLSS) and
infrastructure (to provide services of other ULBs of state as they are also expected to
23

plug into the same solution in future), even though the current DPR shall include the
requirements of all the ULBs in the Mission cities only.
(v)
Sizing: The DPR shall analyze and suggest technologies like virtualization, cloud
computing etc for seamless addition hardware/ software to meet the requirements of
ULBs in future and also to handle seasonal loads and future expansion.
(vi)
Security: Appropriate restrictions shall be built in to maintain State/ ULB specific

user level security and user accesses. Appropriate network, infrastructure, database,
operating system level security needs to be built around the application.
The DPR needs to detail out the security requirements and the methods &
technologies to provide such facilities. DPR shall consider the guidelines issued on
implementing security standards and digital certificates & biometrics published by
DIT available at http://egovstandards.gov.in.
(vii)
Transaction Accounting & Management: As the application will be deployed in a

multi-tenancy environment and shall be used by multiple ULBs, there is a need that
the solution should support this cost-sharing model through a transaction accounting
& management module. Moreover, facilities should be built in to take care of
transactions accounting in offline mode. The DPR shall provide details on this
module and its functionalities considering the above factors and also the customized
reporting requirements of state/ ULBs
(viii)
Audit trail: As there shall be critical users carrying out critical transactions, the
application should have a facility to record & generate audit log for data access in the
solution. The DPR shall provide details on the same.
(ix)
Domain name: The SLSS will be used by multiple ULBs in the state. The usage of
domain name for individual ULBs should also be finalized before hand. Preferably,
sub-domain nomenclature should be followed and domain names must be registered
before hand. The DPR shall provide details on the same.
(x)
External Interfaces: The DPR shall provide details on how the SLSS will interact
with external systems like GIS, Payment Gateway, Other existing systems in ULBs
etc. The above interaction should be seamless in nature.
(xi)
Offline working at ULB: The DPR should specify the services that shall continue to
operate in case connectivity to SLSS is temporarily unavailable. Such services should
be worked out in coordination with SLNA. It will also include details on offline
working of these services (part / full cycle). DPR shall also identify the risks involved
while carrying out critical transactions in the offline mode particularly for financial
transactions.
Keeping in view, all the above key requirements, a solution needs to be conceptualized, and
details of the solution needs to be provided here. Illustrative solution architecture for the State
Level Solution can be as shown below.
24

Figure 1: Solution Architecture

The DPR should define the solution architecture detailing below mentioned components:
Users
Access channels
Gateways
Presentation layer
Business services layer
Security layer
Data layer
External interfaces
4.2.2
Application Architecture
This section should provide details of all applications/modules that would be part of the
solution, along with business functions, which each of these modules would cater to, and the
technical architecture of each of these applications. The same should be provided as per
below illustrative table:
Table 17: Details of Application Architecture
S.
No.
Application/
Module
Service /
Function
delivered
e.g. Birth & Birth

&
Death
Death
registration
Technology
Stack
Type &
number of
Users
----
ULB users,
and
Citizens.
Approx.
Users = 1
25
Transaction
Volume p.a.
Data
Volume
50,000
50 GB
(Approximately
equal to the
number
of
births / deaths

million
reported in a
(equivalent year)
to
the
population
of
the
ULB)
4.2.3
Information / Data Architecture
This section should provide details of all important data entities/ data sets, along with the
owner system. This information should be provided as per below table. Please note that these
data entities must comply with metadata and data standards notified by DIT on the
website http://egovstandards.gov.in.
Table 18: Details of Information / Data Architecture

S. No
Data
Brief Description
Entity
/
Data Set
e.g. Name
Owner System
Name of a citizen or an Birth

&
employee of the state / Module
ULB
Key Attributes
Death First Name, Last

Name, Fathers
Name etc.
This section should also provide details of all interactions/ interfaces, that each of the
application modules has with other modules. This information should be provided as per
below table.
Table 19: Details of Application Interfaces
S. No.
Originating
Target
Purpose
Module
/ Module /
Application
Applicatio
n
e.g Property Accounting Whenever

Batch (Run Property
someone
at the end details,
Tax
pays tax, an of day )
amount,
entry of the
transactio
same should
n details
be reflected
in Accounts
module
4.2.4
Type
of Data Set Technolog
to
be y / Tool
Interface
exchang used
ed
None
Technology / Deployment Architecture
This section should provide details of various types of servers to be deployed along with the
software components would be deployed on these servers. The DPR will also identify the
26

hosting facility (SDC / or third party data centre) for SLSS in this section. Details on suitable
technologies adopted to help in scalability of hardware and software should be provided here.
The deployment architecture should be able to be upgraded or replaced independently as
requirements change. Suggestive three-tier deployment architecture has been provided below.
Figure 2: Deployment Architecture
4.2.5
User Interface
The DPR shall identify various types of user interface required while dealing with various
stakeholders. For example,
External users like citizens/business users would be able to access non-restricted
areas of the application over internet. The public web server and the internal
firewall a part of the public DMZ would be configured to render only those
application pages that can be accessed publicly.
The following figure depicts the access path in case of external users:
27

Figure 3: Deployment Architecture: External users

Internal users of the Internal department would be connected through SWAN
and would access the application over intranet.
Internal users of Other government agency communicating with the centralized
application would access the applications via web services (over SSDG/SWAN).
The following figure depicts the access path in case of internal users:
Figure 4: Deployment architecture: Internal users

4.2.6
Network and Server Architecture
In this section, the DPR shall propose network architecture for connecting the SLSS. For the
same, the DPR shall provide details on:
28

Network architecture to connect the State Data Centre (SDC)/ third party data
centre and various ULBs over State Wide Area Network (SWAN), wherever
available, or any local network service provider
Appropriate business to technical requirement mapping should be provided
while discussing about solution infrastructure
Essential components such as routers, switches, etc.
Interfaces
that
would
be
provided
to
external
governmental
agencies/departments viz. State Police, Courts, etc.
Infrastructure in terms of back-end, middleware and front-end
Figure 5: Network Architecture
Table 20: Network / Server Architecture for Proposed System

Proposed (TO-BE) Scenario
Description
Location 1
Location 2
Back-end (including database management tools used)
Middle ware (including application software)
29
Location 3
. Location
(n)
Total

Proposed (TO-BE) Scenario

Description
Location 1
Location 2
Location 3
. Location
(n)
Total
Front-end delivery channels (including application software)
Network devices (the proposed network design should be provided schematically separately)
Information Security
4.2.7
Security architecture
The State DPR shall define security architecture for SLSS and its various components in this
section. For example: An illustrative security architecture for the centralized application and
the various components have been shown as below:
Figure 6: Security Architecture

User level security: Restricted areas of the application shall only be accessible
over WAN
Network level security: Network traffic shall be encrypted using SSL &
Secured connectivity to provide between the CFC/ ULB and the SDC
30

Infrastructure level security: Application infrastructure shall be hosted in a

DMZ & Firewalls and IPS shall be installed to detect/prevent unauthorized
activities
Application level security: Role based access, encryption of user credentials,
data, storing of User credentials for external and internal users in separate
repositories
Apart from the above the DPR shall provide details on:
Anti-virus and software patch management strategy.
Security policies proposed to be applied
Frequency of review of various components of the infrastructure e.g. General
Systems Audit, Vulnerability Assessment & Penetration Testing, and
Applications Audit etc.
Data migration and data security policy for the ULBs to move to the new system
Details about third party reviews of the infrastructure from security point of
view.
4.2.8
Integration with SWAN & SDC
This section should discuss integration of the application and the associated hardware
with the SWAN and SDC. Some of the salient points of this section will be:
Details about integrating the solution with the SWAN infrastructure
Details about the backbone on which all departmental and core applications
would reside
Details about how the municipalities and other field offices can hook to the
nearest PoP of the SWAN, through leased lines
Details for the centralized access of key applications the State would host for the critical
servers in the State Data Center (SDC).
4.2.9
Service Level Agreements (SLA) & Monitoring Tool
DPR shall identify and define the SLA to measure the performance standard and the processes
executed through application solution. For example:
Percentage of availability of network

Timeframe to respond to outages to revive critical business processes
Remedies on outage of a problem
Escalation procedures to the next level in case of breach of SLAs
Any 24 x 7 x 365 monitoring of the entire solution
As some of the service levels will be met at the State and some at the ULB level, DPR
has to also propose a mechanism and process to monitor the service levels at the State
and ULB level to measure the SLAs. The DPR shall also identify any SLA monitoring
tools to track SLAs at both state and ULB levels.
4.3
4.3.1
Conformance to Standards
Interoperability Standards
This section should provide details of standards in terms of message formats, protocols and
technology that shall be adopted across various modules / applications. DIT is currently
working on technical standards for interoperability. The DPR should ensure that complete
solution designed under this DPR should comply with these standards.
31

4.3.2
Data Standards
In this section, the DPR shall provide details on all key data sets & meta data. Care should be
taken that the data definitions and standards of all important data entities should be in line
with standards published by DIT. These can be accessed at http://egovstandards.gov.in
4.3.3
Security Standards
Guidelines for security standards including biometrics and digital signature certificates are
notified and available on DIT website http://egovstandars.gov.in. The DPR should ensure that
complete solution designed under this DPR should comply with these standards, to ensure
that appropriate security controls are in place to ensure the security of the applications.
4.3.4
Localization Standards
Localization standards, like Font standards are notified, and available at the DIT website. All
applications should comply with these standards to ensure common look and feel across
various applications deployed in government.
4.4
IT Change Management
In this section, the DPR shall provide details on the IT change management strategy to be
adopted once the centralized software application is adopted by multiple ULBs. Since multitenancy architecture is chosen for the implementation of the software, the issue of version
control should be addressed sufficiently. In case of a new version of software, a clear strategy
of how all ULBs will be informed and migrated should be detailed out in DPR.
4.5
Service Provision & Consumption by ULBs
In this section, the DPR should provide details on how the solution would be delivered to the
ULBs. The solution would be centrally deployed and ULBs from mission cities across the
state would plug into this solution. The details on the approach that is adopted to facilitate this
should be provided in this section, along with the steps that service provider (SLNA/ ASP), or
the service consumer (ULB / private parties) would need to follow.
4.6
Continuity Measures
This section should describe the issues and risks surrounding the IT infrastructure
(hardware and software) and the risk mitigation plan for the continuity of the services in
case of unforeseen events. Some of the key points that shall be covered are:
Details of the data backup policy
Details of the Business Continuity and Disaster Recovery plan
Compliance with DIT guidelines on business continuity and disaster recovery
4.7
Support/ Help Desk
In this section, the DPR should provide details on the How the Operations would be managed
and users provided support once the system is implemented. The DPR should provide details
on the structure of the helpdesk, and channels through which this support would be provided.
The DPR should provide details on any service levels, that this helpdesk / support group is
intended to maintain.
4.8
Roll out Strategy
32

DPR should provide details on the strategy of rolling out the solution to remaining ULBs of
mission cities in the state. This should include timelines and ULBs where the solution would
be rolled out. The DPR should also define the strategy to roll out solution other ULBs of the
state.
4.9
Option Analysis
After having a fair idea of overall architecture, this section shall provide details on various
technology options available and provide an analysis on which technology to be adopted.
While rating the options, details about the re-use of existing infrastructure shall also be
provided. The DPR should cover the following points:
Detailed costs benefit analysis of all the options.
Reasons and details of the option selected.
The description of various options considered should be provided in Table 21below.
Table 21: Option Analysis for Selecting Proposed Technology
Detailed description of various options and reasons for selection/rejection
(For example: Technology including Back-end, middleware, front-end, networking, and
security standards being adopted)
Option 1:
Option 2:
Option 3:
Selected Option:
33

5.
Capacity Building and Change Management
Managing large-scale change programme for multiple ULBs simultaneously will pose various
technical and cultural challenges for SLNA. To address these challenges, it will be essential
for SLNA to have a structured plan in order to usher in the new changes. This section should
detail out change management and capacity building plans of the ULB. The Change
Management Plan should be detailed and exhaustive to include the topics of governance,
working groups, change readiness assessment, case to change, identification of various
stakeholders, communication strategy, monitoring performance, etc. The costs specific to
each item identified under capacity building should be included in the DPR.
All change management issues raised by the stakeholders from all quarters may be recorded
and processed by the SLNA on a periodic basis. This may comprise of amending any of the
personnel policies of the ULB or MA & UD.
5.1
Need for Change Management
Since, e-Governance program envisages fundamental attitudinal and technical change, The
DPR shall detail out the need for change management at various levels. The DPR shall also
comprise the critical issues envisaged by the SLNA in the change management process at
both the SLNA and ULB, along with the mitigating strategies.
5.2
Identification of Stakeholders
In this section, the DPR shall mention the key stakeholders identified in the Stakeholder
Analysis exercise including key areas to be addressed for the overall change. An example for
the same has been provided in Table 22 below:
For example: The State Implementation Consultant (SIC) shall be a primary stakeholder
whose role and responsibility shall include ensuring all aspects of project management i.e.
scoping, implementation, monitoring cost, time, quality, human resource, risk,
communication, procurement, change, partnership.
Table 22: Stakeholder Identification
S.
No.
Stakeholder
Roles and
Responsibilities
SLNA
Define policies
Approval of
works/projects
Monitoring
Intervention
Strategic decision
making
Dual role in Change
Management
Communication:
Communication
partners as well as
audience
34
Training and
Communication
Needs
Change
Management
Impact
Shift in the
Decision
Making
Response time
Customer
Orientation
Technical
Training
Training
Strategy
Communication
Strategy
Wear
Communication
the
hat of both
Training
Partner and
Audience
Long Term
Training
Technical
and
Behavioral
training.
clearly
demarcated
of the policy
changes, to
enable the
working group to
define and frame
work plan
Partnership
with the Change

Management
Communicators

S.
No.
Stakeholder
Roles and
Responsibilities
Employees
5.3
5.3.1
Training and
Communication
Needs
Responsiveness
Customer
Centricity
System and
Data
Operations
Perform duties in
timely manner
Interface with
internal and
external customers
Participate in
defining policies
Training
Strategy
Communication
Strategy
Skill
and
competency
building
through
training
programme
Long Term
Behavioral
and Short
Term
Rigorous
Technical
Training
Awareness
creation and
sensitization
of change
through
communicati
on
Organization Structure
Current Organization
In this section, the DPR shall provide details of existing functional entities/ departments and
their detailed organization structure at State and selected ULB. Roles and responsibilities of
all key positions, various working groups, committees, and relationships shall also be
highlighted. The details of the existing number of employees under each functional entity
shall be provided in DPR to understand the user base for various applications.
Relationships with other departments/ stakeholders to understand the functional integration of
departments needs to be provided.
5.3.3
Proposed Organization
Looking at the current organization structure and future requirements, the DPR shall propose
an organization structure at State and ULB for carrying out project. The proposed
organization structure shall highlight how the gaps envisaged with the earlier structure have
been overcome. Elaboration on new roles and responsibilities, nature of the relationship
between governing committees and stakeholders, their objectives and reporting structure
envisaged for the new organization structure needs to be provided. Special focus should be
given to the IT Organization within SLNA as it will be the backbone of the entire project.
For example: The team formed at the state can act as the Project management Unit (PMU)
reporting to a Project Steering Committee. The State Implementation Consultant (SIC) shall
assist the PMU at the state level and help in implementation and roll-out of the project.
The SLNA can obtain guidance from the organization structure envisaged by MoUD for the
programme as shown below.
35

State Level Steering

Committee (SLSC)
MoUD
State e-Governance
Mission Team (SeMT)
Advisory
SLNA
Capacity
Building Team
SLNA
Process/
Functional
Team
Technical
Team
Project Management Unit including

State Implementation Consultant
Application Service Provider
(Implementation & Roll Out)
Urban Local
Bodies (ULB)
Figure 7: Institutional Structure for State
5.4
Staffing and Deployment Strategy
In this section, the DPR shall provide the current and proposed staffing and deployment plan
eliciting the staff strength, roles, skill sets required, duration etc for each team (Existing and
proposed). DPR shall identify process specialists comprising of functional experts for the
eight identified processes, Capacity Building, Change Management and M&E experts for the
project.
The DPR shall mention the mechanism for staffing, sourcing plan, role description of the
proposed new positions and the deployment plan at relevant stages of the project.
For example: The modus operandi for selection of staff can be by deploying or deputed from
any of the existing SLNA team, ULBs or any other department or appointment of external
consultants.
5.5
Training Strategy
As sensitizing the e-Governance program to various stakeholders shall be a challenge for

SLNA, hence a tentative training strategy including Training Need Assessment (TNA) and
delivery ensuring both internal and external stakeholders shall be envisaged in the DPR.
5.5.1
Training Need Assessment and Content Development
In this section, the DPR shall include a strategy on how training needs shall be assessed at the
state and ULBs along with the detailed training requirements.
For example: Training needs can assessed at the state level considering the proposed
organization structure at the state and ULB level and in consultation with the SIC (if
applicable). The trainings may include functional, technology, soft skills trainings etc. for
identified stakeholders.
36

MoUD at the National level shall assist the State in identifying trainings and developing a
skeleton for the content to be delivered for the e-Governance project. The DPR shall make
provision for the customization and localization of the content at the state level at per the
requirement of the state and the ULBs.
5.5.2
Identification of Delivery Channels for imparting training
In this section, the DPR shall provide a strategy to identify various delivery channels (e.g.
training institutions) at the state and ULBs for imparting the proposed trainings to the various
stakeholders.
For example: The delivery channels can be ATIs, local educational institutes, in-house
training centers etc.
5.5.3
Preparation of Training Schedule
The DPR shall include tentative training schedule/ plan & frequency proposed for the various
trainings to be conducted.
5.6
Knowledge Management
DPR shall propose a knowledge management tool or any other mechanism for managing the
critical content, lesson learnt, best practices etc. for the project.
37

Monitoring & Evaluation
Monitoring and Evaluation (M&E) will help in the process of measuring, recording,
collecting, processing and communicating information to assist in project management
decision making.
A diagrammatical representation of the M&E process has been given in figure shown. M&E
will play a critical role in all the phases viz. of the overall project implementation.
Initiation Phase
Implementation Phase
Post-Implementation Phase
Hence, to have smooth and effective M&E system
in place, it is important for State to have an
integrated and streamlined M&E Framework at
State & ULB level.
6.1
Monitoring & Evaluation Framework
In this section, DPR shall define M&E framework

for the project implementation. State shall either
adopt for M&E framework defined for the program
at the National level by MoUD or take guidance
from the same. Following steps shall be considered
while designing M&E framework at State Level.
6.1.1
Clearly defined Objectives
In this section, the State needs to identify its

objectives for M&E at Project level at the State and
ULB level. Illustrative objectives at Project level
has been presented in Table 23. DPR shall provide
the details in the same format.
Figure 8: M&E Process
38

Table 23: Objectives for Monitoring &Evaluation

Stakeholder
Illustrative Objectives
State
Program Level
Identify state coordinator for Monitoring and Evaluation of all ULBs
Define scope of M&E for state and ULBs in line with the M&E
framework defined at National level
Create M&E plan and oversee its roll out (Physical and Financial
progress)at State and ULBs
Design standard reporting templates for Monitoring for ULBs for
capturing data for State and ULBs
Co-ordinate with MoUD and provide reports at regular intervals
without fail
Provide guidance to involved stakeholders as and when required
Project Level
6.1.2
Collect information (progress report) in specific interval

Analyse and monitor the overall growth of project
Identify and address challenges, deviations and risks
Make interventions as and when required and make policy level
decisions
Define Organization and Identify Roles and Responsibilities
For overseeing M&E at ULB, it has to identify a high-level committee at ULB level. M&E
team and other co-ordinators needs be identified along with their roles and responsibilities.
An illustrative organization chart for M&E with roles and responsibilities has been presented
in table 24 below. DPR shall provide the details in the same format.
Table 24: Roles & Responsibilities for Monitoring &Evaluation
Role
State Level Steering
Committee (SLSC)
State
Level
Nodal
Agency (SLNA)
Illustrative Responsibilities
Oversee overall progress of the project
Circulate notices pertaining to department functionalities
and co-ordinate with SLNA for high level intervention if
required
Chair review meetings with project In-Charge
Co-ordinate with MoUD for communicating overall M&E
Circulate the Quarterly Progress Reports prepared by

MoUD to State Coordinator of M&E and ULBs
Select State Coordinator of M&E
Take policy level decisions and prepare guidelines and
formats
Monitor Fund release
Monitor overall implementation at state and rollout in
ULBs
39

Role
Project In-charge
Technical Team
Change
Team
Management
Illustrative Responsibilities
Overall in-charge of Program execution, Monitoring and
Evaluation
Provide direction and assist M&E team as and when
required
Handle critical project deviations and risks and devise
resolution and Mitigation plans
Make action plans for future
Update progress status to project Steering Committee on a
regular basis
Would be responsible for Technical Monitoring of project.

Collect, compile and analyze the report from Hardware
integration team, System support team and Quality
assurance team and send it to Project in-charge
Will monitor the progress for Capacity Building and

Change Management
Track successful completion of the training programs
Assess effectiveness of trainings
Assess effectiveness of communication campaigns
Prepare monthly / quarterly status reports to Project InCharge
6.1.3 Approach for M&E process

Monitoring
Components and its indicators identified
will form input of project plan. During the
monitoring process, the milestones for
various indicators would be monitored at
regular intervals to determine the status. If
any deviations found, control mechanism
would be put into place to take corrective
actions at the minimal required period to
achieve the desired output. In case of any
change in the project plan, the same would
be communicated with the output. An
approach for monitoring process has been
presented in the diagram.
Figure 9: Approach for Carrying out Monitoring

Process
40

Evaluation
Evaluation would be carried out at post implementation stage as End-Line survey.
Evaluation would also be carried on continuous basis after Program Implementation as ExPost Implementation survey for continuous improvements till achievement of desired goals.
Figure 10: Approach for Carrying out Evaluation Process

A suggestive approach for M&E would be divided into various sub-activities as mentioned
below.
WHAT: Identifies what needs to be monitored and evaluated?
State has to identify variables/ indicators for input, process, output as a part of monitoring
process and outcome/ impact as a part of evaluation process. The identified indicators would
be measured/ verified (in terms of Progress, Timelines, Resources allocated, Deviations,
Risks and Funds utilised) against pre-defined plan. Illustrative list of variables/ indicators for
input, process, output and outcomes/ impact have been presented in table 25. DPR shall
include details in the same format.
Table 25: Approach for Monitoring &Evaluation
Phases
Input
Process
Output
Outcome/ impact
Variables/ Indicators
Define M&E framework
Define monitoring plan and schedule
Empowered committee formed
Process of identification of stakeholders
Vendor selection process
Customisation of software application
Testing and integration
Implementation
System Integration
Capacity building
Risk Management
Training of identified personnel
Opening of CFCs/ Kiosks/ Facilitation centers etc.
Turn around Time
41

Phases
Variables/ Indicators
Number of visits required to the office per service per customer
Time taken to provide service
Percentage increase in revenue
Customer satisfaction level
Customer awareness
HOW: Answers the various modes to be undertaken for Monitoring and

Evaluation process.
Monitoring: ULB would use various modes for carrying out the monitoring process. An
indicative list of such tools are mentioned below:
Framework defined at National level (Monitoring)
Schedule and Resource Plan defined in the planning phase
Online Tools at ULB level
Quarterly Progress Report formats developed at National Level
Standard formats developed at State level
Team meeting, project review, feedback
Audit by outside agency like IRMA
Evaluation: States would use the Performance Report cards in Hand book for Service
Level Benchmark on e-Governance in municipalities to report the progress in order to
carry out Baseline and End line Survey. The various modes would be:
Reports generated through the developed system
Feedback from Citizens
Surveys / Questionnaires
Engagement of 3rd party
Usage of self assessment forms
WHEN: Defines the frequency of reporting the results obtained from monitoring
and evaluation
ULB would determine frequency for reporting and would be appropriately spaced, so that
the data collection is not repetitive or cannot be interpreted to obtain accurate results.
WHO: Identify key resources for carrying out the monitoring process. Illustrative
data has been presented in table 26. DPR shall include the details in same format.
Table 26: Monitoring Process: Ownership & Timeframe
Process
Responsibility
Monitoring project timelines

Monitoring quality
Monitoring capacity building
42
Timeframe

Assumptions & Risk Management
With the broad understanding of above sections, the section on Assumptions and Risk
Management would cover the following:
7.1
Risk Management Process
Organization
management
Benefits envisaged
management
structure
due
for
risk
to
risk
Process for Risk Management
In this section, DPR shall define the process for

Risk Management. For example, the Risk
Management Process may have the following
five (5) steps as shown in the diagram.
Risk Management Plan
In the first step in the Risk Management Process, DPR shall identify the objectives for risk
management. This will help the state to contain the risks in strategic and organizational
context.
a. Risk Identification
After defining the objectives, the DPR shall identify and classify the risks that need to be
acted upon. In order to do so the DPR shall consider all dimensions of the project and its
environment.
For example: Risks can be at various phases of the project and can also be associated with
various Technology, Procurement, Sustainability, Capacity Building, Stakeholders, Security
etc.
Based on the above, risks can broadly be classified into:
Strategy Level Risk
Project Level Risk and
Operational Level Risk
Strategy level risk: This deals with risks resulting from a strategy level decision or change.
DPR shall provided list of Strategic Level Risk in Table 27 below. An illustrative list has
been provided for reference. Stakeholders involved against each shall be identified in
advance.
Table 27: Strategy Level Risk
Risk
Policy
Decision
Examples
Policy coordination
Central / State coordination and support unit
Adopting standardized guidelines defined at
National/ State level
43
Stakeholders
Involved

Risk
Examples
Delay in release of funds
Environmental/
Regulatory
Risks
Administrative Risks
Transfer of key officials
Legal and Contractual Risks
Stakeholders
Leadership commitment
Lack of co-ordination with MoUD/ State
Financial Risk
Stakeholders
Involved
Project Level Risk: This deals with risks related to the ability to understand and manage the
project complexities and project environment. Not addressing them will result in not
delivering the expected results that can bring in desired benefits. DPR shall provide list of
Project Level Risk in Table 28 below. An illustrative list has been provided for reference for
addressing the risks at Project level in line with the vision to achieve the desired objectives.
Stakeholders involved against each shall be identified in advance.
Table 28: Project Level Risks
Risk
Project Scope,
Planning and
Management
Financial Risk
Environmental/
Regulatory
Risks
Technology
Risk
Examples
Managing complexity level in the project

Incorrect Project scope identification
Requirements and Scope Definition
Project planning, monitoring and control
Cost and Time overrun
Inappropriate Cost Estimates

Insufficient funds available
Administrative Risks
Improper or insufficient Legal and contractual
risks
agreement with the vendors, contractors etc.
Intellectual Property Rights
Data Privacy and Security
Improper integration with state infrastructure

Improper Software application rollout
Transactions not being auditable
Inadequate accuracy or precision in Output
levels
Obsolescence of technologies
44
Stakeholders
Involved

Risk
Examples
Stakeholders
Unavailability of connectivity up to the lowest

level
External stakeholders Citizens
Lack of co-ordination among stakeholders
Indifferent attitude of stakeholders
Lack of familiarity with the new system and
policy changes
Non acceptance of the system
Effective communication between ULB and its
stakeholders
Achieving
Outcomes
Non-Compliance to citizens charter

Meeting Service Level Benchmarks in terms of
service delivery timeframe and service quality
standards
Meeting citizens satisfaction/ expectations
Human
resources
Stakeholders
Involved
Changes in the Organizational Structure

Ineffective awareness in staff
Unclear Roles and Responsibilities with
accountability
Challenge with attitude and adaptability to
change
Capacity Building via various development
modes and trainings
Increase in Staff Productivity
Information and knowledge sharing
Operational Level Risk: These risks will arise out of day-to-day activities and management of
the project from inadequate or failed processes, people, and systems or from external events.
The Project Manager or the Team Leader appointed by state would manage these risks on a
day-to-day basis. DPR shall provide list of Operational Level Risk in Table 29 below. An
illustrative list has been provided for reference. Stakeholders involved against each should be
identified in advance.
Table 29: Operational Level Risks
Risk
Roll out and

Integration
Examples
Full scope not covered while performing

quality testing
Difficulty in integration with existing
infrastructure
45
Stakeholders
Involved

Risk
Organizational
factors
Examples
Day to day operations and maintenance
Key members of the project moving out

Personnel and training issues - skill
shortage
Additional staff responsibilities alongside
project work
Data and
information
system
Procurement
Risks
Schedule/
Timeline/ Cost
Overrun
Stakeholders
Involved
Digitisation of legacy data

Ready availability and accessibility of data
and information
Data and information quality
Capacity to analyze data and utilize
information
Contractual issues
Mismatch between the nature of task and
procurement process
Failure to deliver satisfactory results
Unrealistic Schedules/ Timelines/ Cost
Over-run in schedule deadlines and
milestones
Change in priorities towards the project ;
Lack of funds
* Please note that the above-mentioned list of risks is an indicative list and DPR shall identify
risks depending on the environment of State. DPR shall also identify the stakeholders (i.e.
who is involved or affected) against the risks identified.
b. Risk Assessment and Evaluation
Risk assessment would provide the:
Details on the likelihood (Probability and frequency) of the risk event to happen, and
Details of the impact, cost or consequences (Economic, political, social) of that event
occurring?
In this section, DPR shall describe the risk assessment criteria to be used by the State and also
provide a rationale behind choosing the risk assessment criteria. For each risk identified in
above section, the DPR shall analyze the potential consequences/ impact and frequency/
likelihood of occurrence of the potential harm in terms of cost, schedule, performance etc. A
risk assessment matrix may to be prepared combining the frequency/ likelihood and the
impact. Thus,
46

Risk Measure = (Threat Impact) * (Likelihood of Exploitation)

The values of the Risk Measure would be classified as High, Medium and Low based on the
Risk Measure as shown below in table 30:
Table 30: Calculation of Risk Measure
Impact
Low -1
Medium -2
High -3
(Score 1)
(Score 2)
(Score 3)
Low
Low
Medium
(Score 2)
(Score 4)
(Score 6)
Low
Medium
High
(Score 3)
(Score 6)
(Score 9)
Medium
High
High
Probability
Low -1
Medium -2
High -3
The description of the value obtained from the Risk Ranking chart is as mentioned below.
Table 31: Chart for Risk Ranking
Score
Risk Category
Description
6, 9
Extreme
Risk will have a high impact on Project and require immediate

action for mitigation. Mitigation plan with strong monitoring
process should be included.
3, 4
Medium
Risk will have moderate impact on Project. Mitigation plan with

strong monitoring process should be included.
1, 2
Low
Risk will have low impact on Project. Cost benefit analysis

needs to be performed while devising the mitigation plan.
c. Risk Mitigation Strategy based on Risk Evaluation Matrix

The DPR shall identify the risk mitigation strategy and plan for risks identified in above
section. Some of these methods can be as mentioned below:
Avoidance : Not performing an activity that could carry risk
Reduction : Methods that reduces the severity of the losses
Retention: Accepting the loss when it occurs
Transfer/ Share : Transfer or share the risk with various partners involved
47

d. Risk Monitoring
After identifying, assessing and preparing risk mitigation plan, it is very important to monitor
the risks on periodic basis. Risks can be entered in the Risk Logs which is to be reviewed in
its entirety by ULB on a pre-determined frequency. A sample of Risk Log has been attached
at Annexure 3.
Risk monitoring shall also include:
Assessing mitigation effectiveness
Reassessing exposure & new risks
48
Model Guidelines for State Level DPR for implementation of e-Governance in ULBs under JNNURM
Pubic Private Partnership (PPP)
In this section, the DPR shall identify the PPP arrangements for implementing e-Governance
programme in partnership with private sector. The term private in PPP encompasses all nongovernment agencies including corporate sectors, voluntary organizations, self-help groups etc.
8.1
Need for PPP
In this section, the DPR shall define the need for PPP in context of the e-Governance project. For
example the needs can be:
8.2
Lack of capital
Inadequate infrastructure
Technological complexities
Lack of capacity & resources
PPP for e-Governance
Based on the above needs, DPR shall detail out the PPP arrangements that can be implemented either
in part or as full service component. PPP can be envisaged in:
Service Provisioning
Service Delivery
Service Provisioning: Service provisioning is the process of preparing and equipping a system to
allow it to provide services to its users. For e-Governance in Municipalities program, development,
deployment, maintenance & operations of the SLSS in terms of application/ hardware/ network/ other
infrastructure etc., shall form the service provisioning.
Service Delivery: Service delivery refers to making sure that the implemented solutions reach the
stakeholders, people and places effectively and in agreed time-frame. For e-Governance in
Municipalities program, delivery channels that will be utilized by ULBs to access SLSS for delivering
the services to citizens shall form the service delivery.
Different models that can be envisaged in service provisioning are given below:
ASP (Application Service Provider): In this model, the infrastructure is owned by state while the
application is developed and managed by the private partner. The government contracts to avail the
services of partner for delivery of services as per mutually agreed services levels and commercial
terms. In this model, the public and private sectors work together to implement ASP model and
build the networks and portals to provide e-governance services.
SaaS (Software as a Service): In this model, private partner owns complete infrastructure and
application and customers pay to access and use application over a network through a hosted, webnative platform operated by the software vendor (either independently or through a third-party).
Under such arrangement, the asset transfer on service termination of the private partner is very
critical.
Thus, the DPR shall weigh the various options/ models available for PPP. The options range along a
continuum within the extreme of almost complete ownership and responsibility of operations,
maintenance, capital investment and commercial risk with the public sector through joint responsibility
to complete private responsibility.
8.3
Engagement Models for Service Provisioning & Service Delivery
BOO (Build Own Operate): In this model, the preferred partner designs, develops and
implements the project, most often, entirely at its cost and operates the system for a pre-specified
period. It is characteristic of this model to entrust the end-to-end responsibility to the selected
partner i.e. both the back-end and the front-end. The options of the partners, in terms of the
disposition of assets and control at the end of term are kept open till the end of period sometimes
called the concession period.
BOOT (Build Own Operate Transfer): Build, Own, Operate, and Transfer (BOOT) model is a
popular PPP model used to build and improve infrastructure, enhance efficiency and economic
growth. A BOOT funding model involves a single organization, or consortium (BOOT provider)
for designing, building, funding, owning and operating the scheme for a defined period and then
transferring the ownership to an agreed party.
Joint Venture: A joint venture (often abbreviated as JV) is an entity formed between two or more
parties to undertake any economic activity together. The parties agree to create a new entity by
both contributing equity, and they then share in the revenues, expenses, and control of the
enterprise. The venture can be for one specific project only, or a continuing business relationship.
Joint venture (JV) model implies co-operation of public and private sectors to provide services.
However, the basic idea of JV in PPP is sharing of benefits (joint) and risks (venture) by the public
and private sectors in the long-term.
8.4
Revenue Model
The DPR shall provide the details on selected revenue model envisaged under the PPP arrangements.
While selecting the revenue model, the DPR shall understand the business requirements of a sample
set of ULBs as the revenue model chosen based on study conducted for selected ULB might not be
feasible or right fit for rest of the ULBs in the state.
Few revenue models are explained below:
Transaction Based Approach: Under this approach, private party would make an initial
investment in setting up systems and structures and in return would be allowed to charge based on
the number of transactions.
Fee Based Approach: Under this approach the private party would make an initial investment in
setting up systems and structures and in return would be allowed to fix nominal charges (in
consultation with government) for public services to be collected either from government or
public, e.g. Collecting nominal charges for issuance of birth certificate, death certificate etc.
Cost Saving Approach: This approach is specifically used where the Government brings about
substantial changes in existing processes through extensive Government process reforms and use
of information technology, which leads to large scale of savings in terms of staff and real estate.
Under this approach, private party provides the initial investment along with their management
expertise and in return, they are entitled to share the cost saved, e.g. cost saving due to online
processing of property transfer and registration document can be shared.
50
Full Service Approach: Under this approach, the private sector is hired as a contractor to take
over certain responsibilities of the Government, and may retain staff on the governments behalf,
in return for a fee.
Shared Revenue Approach: The shared revenue approach is adopted where there are ways in
which the government may generate new revenue from enhanced services. This increased revenue
can be used as a way to offset project costs, or finance the investment made by the private sector.
Licenses: For internal services as personnel management system and financial management,
sharing of revenue can be based on licenses required.
Advertising & Sponsorship Fee Approach: Under this approach, the government may collect
fees in exchange for direct advertising by a private company on a government website, indirect
marketing or by sponsorship arrangements. The advertising arrangements could be based upon a
measurable outcome, such as the number of users who visit or purchase items from the website
advertised.
8.5
Key considerations
The DPR shall provide details on how revenue arrangements can be made considering various types of
services and their nature. The DPR shall also address the some key considerations as details provided
below.
(i) Roles and responsibilities: DPR shall clearly define role and responsibilities of all parties i.e. State
Govt, ULB and private partner. For example: Role of the SLNA shall be creation of Policies for
adopting e-Governance
(ii) Key Considerations: Some of the key features of PPP implementation that shall affect the overall
cost/revenue model for potential private partners are:
Ownership definition
IPRs
Asset Transfer
Entry / Termination provisions
Security requirements
Service level agreements
Confidentiality requirements
Business continuity requirements
Change management
Risks Involved in PPP
(iii) Business Model: The proposed PPP shall clearly be explained in the areas of:
Service deployment plan
Demand projections and price elasticity of demand
Fees and fee setting mechanism
Revenue projections for the operator
Estimated investment (including phasing of investment) and operating costs
Proposed cost sharing arrangements between state, centre and private participant
(iv) Financial Analysis: A Cost benefit analysis of PPP shall be carried out to explain the
sustainability of the model in the future.
51
(v) Feasibility Management: Feasibility Management shall provide clear information concerning all
existing and expected factors, which may support or oppose the implementation of the PPP options.
For example: Feasibility management of selected PPP option shall be defined in terms of following:
Analysis of a government commitment and community support for a certain option
Well-researched and negotiated legal contract
Strong regulatory and institutional environment
Analysis of the state of utility, existing regulation, financial viability and risks
52
Project Implementation Strategy & Sustainability Plan
Based on complete understanding of project, technology infrastructure requirements, various

stakeholders involved, this section shall include a way forward for project implementation & roll out
and its sustainability after the mission period. The section shall include following:
9.1
Stakeholders Involvement
DPR shall identify stakeholder groups, their stake, roles and relevant benefits accruing to them. Table
32 below illustrates some primary stakeholder and beneficiaries who are directly impacted by the
services.
Table 32: Stakeholder Involvement
Stakeholder and their Roles
Example of Benefit
Citizens
(e.g. local elected representatives, direct

beneficiaries of the services provided by ULB
etc.)
Benefits in terms quality, cost, time taken to

receive services, provision for customer care,
jobs, involvement, environmental issues, etc
Value perceived
Municipality
(e.g. Municipal Corporation, Municipality,

Ministry of Urban Development etc)
Ease of process
Less workload
Less paper work & no cumbersome manual
processes
Level of service provided, legislation, taxation,
etc.
Employees
Job security, working conditions, minimum

wages, etc
Capacity building, funding support, etc
(i.e. Employees of the above government

organizations)
Facilitators
(i.e. training institutes, development partners,
NGOs etc.)
9.2
Institutional Structure
Identify an institutional structure to guide the implementation and management of project at state and
ULBs along with defined roles and responsibilities of each position. An illustrative institutional
structure at state is shown in figure 11.
53
Figure 11: Illustrative Institutional Structure at ULB
9.3
Tendering and Bid Process Management
The DPR shall identify and provide details on various tendering processes to be undertaken for
implementing the project. Some of them are as following:
Selection of Software Development Agency / Application Service Provider
Selection of technology/ hardware/ network infrastructure
Selection of capacity building consultant
9.4
Project Implementation & Rollout
9.5
Functional Requirement Study, Development of modules for application including data

preparation, data migration, module testing etc.
Deployment criteria (horizontally across all offices/sites involved or vertically with full
functionality in one site on pilot / roll-out basis).
Overall Integration, User acceptance testing & Go-Live
STQC certification
Capacity Building
Roll out in selected ULB
Delivery Channels Selection
Project Phasing Strategy
The DPR shall specify detailed quarter-wise schedule of phasing of project activities and schedule of
implementation for each phase. It should also include strategy on application roll-out in the remaining
ULBs in mission cities and non-mission cities in near future. DPR should mention critical
dependencies identified in the project and expected timelines for completion of key milestones. The
details should be provided in Table 33 provided below.
54
Table 33: Timeline Completion for Key Milestones

Project
Activities
Responsibility
Target
Date
Project Duration
Year 1
Year 2
Year 3 and so on
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
9.6
Sustainability Plan
In the sustainability plan, DPR shall describe the procedural, staffing, budgetary and contractual
arrangements that will ensure sustainability of project and its outcomes during and beyond the mission
period.
Procedural Sustainability
In this section, the DPR shall provide information on processes and procedures that shall be
followed for smooth functioning of the project.
Resource Sustainability
In this section, DPR shall provide the information related to sustainability of the human
resources deployed for the project. It includes tenure commitments of the key officials from the
government, key technical staff identification, Strategy for hiring, training and replacing key
technical staff to ensure the smooth project implementation.
Financial Sustainability
In this section DPR shall provide the factors considered for the financial sustainability of the
project, like Government commitments for O&M budgetary support, how the ongoing staffing
costs be absorbed, and the source of the funding in case of a PPP failure etc.
Note: Since the Additional Central Assistance (ACA) is limited for only two years after the
completion of implementation of project, the State and selected ULB shall clearly mention the
sources of funds and explain its proposed financial plan (i.e. sources of funds) & sustainability
after 3 years. The DPR shall also include details of existing charges levied by ULB & the
volume of revenue (if any) for the service components for at least last three years; and the
proposed charges & expected volume of revenue beyond three years.
Contractual Sustainability
In this section, DPR shall provide the steps required for the issues related to legal and policy
framework, authentication/security of Private Partner transactions, design of Service Level
Contract and ability to enforce them for project consultant, suppliers, vendors and private
partners, ways to prevent monopoly of PPP.
Table 34 mentioned below shall be filled in by the State & selected ULB for the different
sustainability areas identified and the key factors considered.
55
Table 34: Sustainability and Key factors
S. No.
Areas
Procedural Sustainability
Resource Sustainability
Financial Sustainability
Contractual Sustainability
Description
Key factors
Action steps
56
10 Project Costing
10.1 Detailed Bill of Material For State level solution
The DPR shall provide detailed BOM (Bill of Material) separately under two categories i.e. one time
capital investment cost and recurring cost for every component for state level implementation in table
35 and 36. It should be noted that:
The expenditure under Miscellaneous header will not be admissible.
ACA is for 3 years only (including one year of implementation).
Table 35: State: Summary of Project Cost (Investment & Recurring Costs)
S.No.
Particulars
Quantity
Unit Cost
(in Lacs)
Total Cost
(in Lacs)
A. Capital Investment
1.
Network Infrastructure
Components
2.
Hardware & Server

Infrastructure Components
3.
Security Infrastructure
Components
4.
System Software
5.
Application Software
6.
GIS Components
7.
STQC certification
8.
Monitoring Tool
9.
Help-Desk
10.
11.
Others (if any)

Total Capital Investment (A)
B. Operational Cost
11.
Project Management
12.
Capacity Building
57
S.No.
Particulars
13.
Network Connectivity
14.
Licenses
15
AMC
Quantity
Unit Cost
(in Lacs)
Total Cost
(in Lacs)
Total Operational Cost (B)

TOTAL COST (A+B)
Table 36: State : Year-wise Expenditure Distribution

S.No.
Particulars
Year 0
(in Lacs)
Year 1
(in Lacs)
Year 2
(in Lacs)
1
Components
2.
Hardware & Server

3.
Components
4.
System Software
5.
6.
GIS Components
7.
STQC certification
8.
Monitoring Tool
9.
Help-Desk
10.
11.
Others (if any)
B. Operational Cost
11.
Project Management
12.
Capacity Building
58
S.No.
Particulars
13.
14.
Licenses
15
AMC
Year 0
(in Lacs)
Year 1
(in Lacs)
Year 2
(in Lacs)
TOTAL COST:
10.2 Detailed Bill of Material For Roll out in Selected ULB

The DPR shall provide detailed BOM (Bill of Material) separately under two categories i.e. one time
capital investment cost and recurring cost for every component for the state level implementation in
table 37 and 38 for the Selected ULB too for the permissible components specified under JNNURM.
It should be noted that
The expenditure under Miscellaneous header will not be admissible
Detailed assessment of the existing infrastructure also needs to be provided
ACA is for 3 years only (including one year of implementation).
Table 37: Selected ULB: Summary of Project Cost (Investment & Recurring Costs)
S.No.
Particulars
Quantity
Unit Cost
(in Lacs)
Total Cost
(in Lacs)
1
Components
2.
Hardware & Server

3.
Components
4.
System Software
5.
Customization of
6.
GIS Components
7.
Others (if any)
Total Capital Cost (A)
59
S.No.
Particulars
Quantity
Unit Cost
(in Lacs)
Total Cost
(in Lacs)
B. Operational Cost
8.
Project Management
9.
Capacity Building
10.
11.
Licenses
12.
AMC
13.
Others (if any)

TOTAL COST (A+B)
Table 38: Selected ULB: Year-wise Expenditure Distribution

S.No.
Particulars
Year 0
(in Lacs)
Year 1
(in Lacs)
Year 2
(in Lacs)
1
Components
2.
Hardware & Server

3.
Components
4.
System Software
5.
Customization of
6.
GIS Components
7.
Others (if any)
Total Capital Cost (A)

B. Operational Cost
60
S.No.
Year 0
(in Lacs)
Particulars
8.
Project Management
9.
Capacity Building
10.
11.
Licenses
12.
AMC
13.
Others (if any)
Year 1
(in Lacs)
Year 2
(in Lacs)

TOTAL COST (A+B)
10.3 Financing Plan

The year-wise breakup of source (Central Government / State Government/ ULB/ Other including
private sector support) , the amount of funds and the form of assistance (Centrally Sponsored Scheme,
ACA, State assistance, external aided, etc) over the project life, shall be provided, as per the Table 39
below. Details on other sources of funds (if any) shall also provided.
Table 39: Financing Plan (Central/ State / ULB share)
Period
Centre
State
ULB
Amount
Amount
Amount
(Rs. Lakhs)
(Rs. Lakhs)
(Rs. Lakhs)
Other
Sources of
Funds (If
any)
Total
(Rs. Lakhs)
Year 1
Year 2
Year 3
Total
Since the Additional Central Assistance (ACA) is limited for only two years after the completion of
implementation of project, the State & selected ULB shall clearly mention the sources of funds and
explain its proposed financial plan after 3 years, i.e. the sources of funds / financing plan to sustain the
project. The SLNA/ ULB shall provide details of the existing charges levied by ULB and the volume
of revenue (if any) for the service components of at least last three years and the proposed charges and
expected volume beyond the three years.
61
11 Annexures
11.1
Annexure 1 - Checklist for State Level Nodal Agency
1. Planning Phase
(A) Process:
1
Is the organization structure defined to ensure process re-engineering in the DPR?
How are the processes standardized across the State?
How has the BPR been done for the identified services under NMMP, JNNURM?
Provide Organizational structure details in the SLNA:
S.
No.
Domain Expertise
Information Technology
Process Champions
Capacity Building
Urban Planning
Monitoring & Evaluation
Any Other (please specify)
Component
State e-Governance
Mission Team (SeMT)
State Implementation
Consultant (SIC)
Remarks/ Role
Interface with State Level Institutions:
S.
No.
Proposed by
(month-year)
Existing
Any other (Pls specify)
Existing
Proposed by
(month-year)
Remarks/ Role

(B) Technology:
1
Does that software application proposed support multi-tenancy for all the ULBs in the State?
Have Open Standards, and the other software standards described under the NeGP programme
been applied in the software application?
Is the application proposed integrated with other State Mission Mode Projects like e-Procurement,
SDC, SWAN, SSDG, State portal etc. and other internal functions?
Have exhaustive details regarding the software solution design been provided as part of the DPR
submitted?
Is the Disaster Recovery site and processes identified?
Framework for common application across the state following details are to be provided:
S.
No.
Component
Existing
Proposed by
(month-year)
Remarks
Proposed
Remarks
Project Management/
Implmentation Unit (PMU/ PIU)

System Integrator/ Application
Service Provider for

application(s) deployment
Common Application(s) (No. of
applications)
Common Server side hardware
Common Server side software

licenses
Any other (pls specify)
Features of Application:
S. No.
Component
STQC certified solution
Customized/
Existing
Bespoke
development
Platform / technology
Scaling up facility
Interoperability with other

applications
Integration with existing
63

S. No.
Component
Existing
Proposed
Remarks
State portals/ initiatives

7
Common Infrastructure of the State to be utilized by ULBs:
S. No.
5
6
7
8
Component
Usage
State Wide Area

Network
(SWAN)
State Data Centre
(SDC)
Vertical and Horizontal

linkages for ULBs at
District and Block level
Hosting of the
centralized
application(s) at SDC
Integration with state
portal by ULBs
State eProcurement
portal
National Urban
Information
System (NUIS)
scheme
State Portal
State Service
Delivery
Gateway (SSDG)
e-Forms
Existing in the
State/ Proposed to
be in place by
(month/year)
Utilization
mentioned in
DPR
For GIS components
Linkage of the all the

ULBs with state portal
For service delivery
For process
standardization
Any other (pls

specify)
2. Implementation Phase
1 Details to be provided for the following personal and process:
S. No.
Component
Domain experts
IT skills personnel
e-Governance personnel
Personnel for interface with

ULBs
Existing
Proposed by
(month/year)
Remarks
64

S. No.
Component
Training need analysis
Training
institutes
identified
Process standardization
7
8
Existing
Proposed by
(month/year)
Remarks
3. Sustainability Phase (Operations & Maintenance)

1
Have the NeGP Guidelines for Operational Model for implementation of State MMPs and
(Replicable Central/ Integrated MMPs) by the Line Ministries/State Department been followed?
Have the DPR consider PPP for all the service provisioning & delivery components (Application,
IT infrastructure, Network, Delivery infrastructure)?
Have the service levels for PPP framework like Availability/ Accessibility/ Reliability been
defined?
What are the engagement model, revenue model and service delivery model considered in the
DPR?
Following details are to be provided for Public Private Partnership (PPP):
S. No.
1
2
3
4
5
6
7
8
Component
Existing
Proposed
Remarks
State Level PPP

arrangements
PPP Service Provider
Engagement Model
Service Provisioning Model
Service Delivery Model
Revenue Model
Contract Management
Operations & Maintenance
Arrangements
Any other detail (pls
specify)
4. Monitoring and Evaluation

1 Has the Steering Committee been formalized for monitoring of the project at all levels (ULB &
SLNA)?
2 Has the Monitoring & Evaluation committee be identified and informed?
3 Has the base line survey been done for the identified service across State?
65

11.2
Annexure 2 Functional Requirement Specifications
Note: Indicative functional specifications for the proposed centralized e-Governance application has
been provided below based on MeDD guidelines. However, functionality for the proposed solution
shall be prepared in light of the pilot study conducted across the state based on the Municipal Acts and
Bye-Laws.
1.1
Birth & Death Registration Module
S.
No.
Requirement
Existing
Module
(Yes /
No)
Proposed
Module
(Yes /
No)
Existing
Module
(Yes /
No)
Proposed
Module
(Yes /
No)
User Authentication
1
First level of security

The municipal corporation users to have access to various databases and
to query on the different master maintenance tables based on the userids and passwords.
2
Second level of security
The usage of pin codes, Token and key, Biometric Authentication
Methods such as Finger Print Technology etc for second level of
authentication may be considered and justification is to be provided for
the same
Master Maintenance
3
4
Details of Hospital details (Addition/Modification/Deletion/ Search).

Details of Registrar
(Addition/Modification/Deletion/ Search).
5
Details of maintaining Fees for Birth and Death
6
Details of Birth Delivery
7
Details of Birth application details (Addition/Modification/Deletion/
Search).
8
Details of Cause of Death (Addition/Modification/Deletion/Search).
Birth Registration
9
10
11
12
13
S.
No.
Ability to add/modify/delete the Birth details

Ability to generate the Birth Registration Slip.
Ability to facilitate the inclusion of the Childs Name, if not provided
during registration.
Ability to cancel the Registration details.
Ability to facilitate the capture the request for Birth certificate and
retrieve details of the applicant based on the Registration Number
Requirement
66

Death Registration
14
15
16
Ability to add/modify/delete Death details.

Ability to generate the Death Registration Slip.
Ability to cancel the Registration details. Remarks can be added with
the cancelled record
17 Ability to facilitate the capture the request for Death certificate and
retrieve details of the applicant based on the Registration Number
MIS & Reports
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Various reports information of Birth registrations based on Registration

No, Registration Date, Date of Birth, Issues , Non-Issues Month & Year
Wise
MIS for Actual time taken for issuing a Birth/ Death
MIS for total number of birth/ death certificates re-issued without
service charge
MIS for Accessibility/ Availability of facility centers
Reports births Sex Wise in a particular year
Reports on Fathers Literacy wise in a particular year
Reports on Fathers Occupation wise in a particular year
Reports on Mothers Literacy wise in a particular year
Reports on Mothers Occupation wise in a particular year
Reports on Year-Wise Issues
Various reports can be generated Year of Death-wise based on Date and
Cause of death
Reports of Deaths based on Occupation-wise in particular year
Reports of Deaths based on Sex-wise in particular year
Reports of Deaths based on Cause of death-wise in particular year
Reports of Deaths based on Issued and not issued between two specified
applied dates
67

2.1
S.
No.
Property Tax Module

Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
User Authentication
1

The municipal corporation users to have access to various databases
and to query on the different master maintenance tables based on the
user-ids and passwords.
2
authentication may be considered and justification is to be provided
for the same
3
Entry of new records, modify existing records, delete existing
records.
Inclusion of New Assessee
4
5
6
7
Entering/ adding the applicant details for new assessment.

Generation of a new assessment application acknowledgment receipt.
Facility of modifying/ deleting an existing record.
Generation of the special notice to the assessee indicating the amount
of tax to be paid.
8
Entering of the revision petition application into the system.
9
Generation of the acknowledgement for the appeal petition
application received.
10
Facility of entering the appeal petition hearing date into the system.
Change of Ownership
11
Facility of entering/ adding the application details for title transfer of

property.
12
Facility of issuing an acknowledgement.
13
13
Facility of entering/ adding the field verification details for title
transfer property.
14
Enter/add the approval details for title transfer property
15
Enter/add the fee payment details for title transfer property.
16
Facility of generating the endorsement for the title transfer property
after the property is transferred and the fees is paid.
Assessment & Collection of Property Tax By ULB and citizen interface
17
18
19
20
21
Calculation of Property Tax to be levied based on the building type,

area, usage details etc.
Change property tax computations and determine arrears/refunds etc.
with proper controls/ authorization.
Enter/add the assessment details and property tax levied.
Enter/add the Arrear details and property tax levied for assessment.
68

S.
No.
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
22
23
Generation of the details of Property Tax paid for the assessment.

Generation of enter/ add the application details for exemption from
property tax.
24
Enter/add the application details for vacancy remission from property
tax.
25
Facility of entering/ adding the application details for write-off from
property tax.
26
Facility of issuing an acknowledgement.
General Revision of Assessment
27
Accepting requests for Revision.
28
Updation of the assessment database based on the field verification
details.
29
Entry of the property modification details.
30
Entry of the penalties details.
31
Capturing of the approval details.
Master Maintenance
32
Details of Revenue Zones (Addition/Modification/Search)
33
Details of Revenue Wards (Addition/Modification/Search)
34
Details of Revenue Blocks (Addition/Modification/Search)
35
Details of Locations (Addition/Modification/Search)
36
Details of Apartments/ Complexes (Addition/Modification/Search)
37
Details of Nature of Use of the Buildings
(Addition/Modification/Search)
38
Details of Building Classification Type
39
Details of Roof Type Master (Addition/Modification/Search)
40
Details of Wall Type Master (Addition/Modification/Search)
41
Details of Floor Types (Addition/Modification/Search)
42
Details of Unit Rates (Addition/Modification/Search)
43
Details of Tax Rates (Addition/Modification/Search)
44
Details of Depreciation Rate (Addition/Modification/Search)
45
Details of Bill Collector Master (Addition/Modification/Search)
46
Details of Service Tax master (Addition/Modification/Search)
47
Exemption details master (Addition/Modification/Search)
48
Occupier details (Addition/Modification/Search)
49
Details of Bank Master (Addition/Modification/Search)
MIS & Reports
50
Field Verification Checklists
51
Special Notices
52
Demand Notices
53
Collections:
Bill Collectors Collection(Counter Collection, Direct bank
remittance)
Election Ward wise Collection

Locality wise Collection
Penalty on Late Payment Collection
69

S.
No.
54
55
56
57
58
59
60
61
62
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
Penalty on Unauthorized Construction

Revenue Block wise Collection
Revenue Ward wise Collection
Revenue Zone wise Collection
Street wise Collection.
Registers
Arrears Register
Area Base Register

DCB Register
Exemption Details Register
PT Register
Register of Appeals for the Year
Register of Distraints
Register of Warrants
Remittance/Daily Col Register
Receipts/Payments Register of PT for the Year
True Extract of PT Demand Register
Vacancy Remission Register
Write Off Register.
Certificates
Ownership Certificate
Valuation Certificate.
Other Notices
Final Notice
Warrant Notice.
Apartment Details, Complex Details, Group Housing Details, Row
Housing Detail
Building Age wise Assessment List
Monthly List of Buildings Requiring Levy of PT or Revision of PT
Occupiers Notice Details
Occupiers Other Than Owners
Tax Section Circle No. (Property details by the owner)
70

2.2 Water Supply Module

S.
Requirement
No.
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
User Authentication
1

user-ids and passwords..
2
for the same
New Water tap Connection
3
Acceptance and maintenance of the application details

(Addition/Modify/Search/Cancel).
4
Generation of an application acknowledgment receipt.
5
Generation of the field verification checklist.
6
Entry of the details regarding the field verifications.
7
Entry of the approval and remarks of the AE/ME.
8
Tracking the application/file status of the applicant.
9
Order details for new connection.
10 Capturing of the meter reading as on date for metered-connections.
Change of Use
11 Facility in entering/adding the application details for Change of use.
12 Facility of modifying/ deleting an existing record.
13 Generation of an application acknowledgment receipt.
14 Generation of the field verification checklist.
15 Entry of the details regarding the field verifications.
16 Entry of the approval and remarks of the AE/ME.
17 Tracking the application/file status of the applicant.
18 Order details for change of usage.
Assessment and Collection of Water Tax
19 Calculation of water charges.
20 Maintenance of the details of arrears.
21 Generation of demand notices.
22 Details of the payment collected from the consumer.
23 Maintenance of the advance charges
24 Facility of modifying/ deleting an existing record
25 Facilitates printing of demand notices.
Closing/Holding and Reconnection
26
Capturing of
Applications.
the
details
for
Closing/Holding/Reconnection
71

S.
Requirement
No.
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
27 Generation of an application acknowledgment receipt.

28 Generation of the field verification checklist.
29 Entry of the approval and remarks of the AE/ME.
30 Tracking the application/file status of the applicant.
31 Order details for Closing/Holding/Reconnection.
Master Maintenance
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Details of Revenue Zones( Addition/Modification/Search)

Details of Revenue Wards( Addition/Modification/Search
Details of Revenue Blocks ( Addition/Modification/Search)
Details of Locations (Addition/Modification/Search).
Details of Bill Collector (Addition/Modification/Search)
Details of Application Type (Addition/Modification/Search)
Details of Connection Types (Addition/Modification/Search)
Details of Water Sources Types (Addition/Modification/Search)
Details of Usage Type (Addition/Modification/Search)
Details of Pipe Size Master(Addition/Modification/Search)
Details of Security Deposit Master (Addition/Modification/Search)
Details of Meter Cost (Addition/Modification/Search).
Details of Charges (Addition/Modification/Search)
Details of regularization penalty (Addition/Modification/Search)
Details of Enclosure document (Addition/Modification/Search)
Details of Demand and penalty period
48 Details of penalty (Addition/Modification/Search)
49 Details of slab rates for metered connection Master
50 Details of slab rates for non-metered connection Master
51 Details of bank master (Addition/Modification/Search)
52 Details of bulk sanctions Master (Addition/Modification/Search)
53 Details of probable days of Application processing Master
54 IDs such as Water Tax ID and Property Tax ID
(Addition/Modification/Search) and mapping of these IDs
MIS & Reports
55
56
57
58
59
60
61
62
63
Acknowledgment for application

Intimation letter or proceedings for tap connection
Work order
Consumer register (All Water Tap Connections Details)
Disconnection Notice for unauthorized Connection
Disconnection Notice for existing Connection
List of Tap Connections Sanctioned in Specified Period
Demand Register
Arrear Demand Register (All Water Tap Connections Arrears list)
72

S.
Requirement
No.
64 Preprinted Demand Notice
65 Bill collector wise collected Water charges
S.
Requirement
No.
66
67
68
69
70
71
72
73
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
Location wise collected Water charges

Zone wise collected Water charges
Arrear Details individual list
Report for all Water Tap connections DCB
Block wise DCB report.
Individual DCB report
Modification /Reconnection Details report
Assessment Register details
73

3.1
Public Grievances
S.
Requirement
No.
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
User Authentication
1

2
for the same
Master maintenance
3
Ability to maintain different types of grievances caused to the

citizens, department or section that needs to address the grievance,
number of days within which the grievance needs to be addressed and
nature of grievance whether it is financial or non-financial .
4
Ability to maintain the statuses of the grievances registered in the
Municipality (Add/Modify/ Search).
5
Ability to maintain the details of work/application that has not been
addressed within the prescribed time, number of days of delay and
compensation paid per day in case of delay in SLA of the grievances
registered in the Municipality
(Add/Modify/ Search)
6
Ability to maintain the details of officers designated to redress
grievances mapped to the department-section.
7
Ability to maintain the compensation details from the Officer
Responsible and payment details to the citizens if the applications are
not processed within the prescribed time. (Breach of SLA).
8
Ability to maintain ULB wards details
9
Ability to map each application is related to a particular departmentsection.
Grievance Registration
10
11
12
13
14
Ability to accept applications, generate unique grievance id and

generate acknowledgement and verify status with the unique
grievance id
Ability to allow section heads to allot the grievance to the concerned
officer responsible and update the status of the registered grievance
Ability to update the status after each level of necessary action has
been taken
Ability to verify the specified time limit of grievance Re-dressal and
calculation of compensation to be paid to citizen as per time limit
Ability to integrate with other modules such as Property Tax, Water
Tax using the unique Grievance ID.
74

S.
Requirement
No.
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
MIS & Reports

15
16
17
18
19
20
21
22
23
24
25
A section wise grievance register is printed for a given period with its
status.
Statistics Report on section-wise number of grievances received/
handled/ pending/ disposed (Type wise/Zone wise/ward wise) and the
details of staff attending it.
Grievance Disposal Register department wise
Grievance Status Summary
Action taken reports
Analytical reports for Performance evaluation as an ULB and
department wise.
Department wise SLA Parameters.
Status by source of complaint.
Department-wise compensation paid along with Response Time for
Grievance Resolution.
Survey report for Awareness levels among Citizens about the
Grievance cell.
Grievances raised to public disclosure.
75

4. Building Plan Approval

S.
No.
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
User Authentication
1

2
methods such as Finger Print Technology etc for second level of
for the same
Building Plan Approval
1
6
7
Ability to add/update the following information in the system:

Application type name
Category name
License category name
Layout category name and category description
Surveyor/licensed architect
Revenue village name
Circle Division Master
Zone/Ward
Enable applicants to fill and submit the building plan application
online and to attach necessary drawings in the soft copy. Allow
municipal officials to access/download the same for verification of
particulars.
Enable staff to enter required documents for building permission
based on the height of the proposed structure. Various categories
based on the height should be allowed to be entered.
Facilitate entering of the building application details such as applicant
information, building information, licensed architect information, and
the technical and fee details.
Facilitate checking of the physical documents submitted by the
applicant for building plan approval. Based on these an
acknowledgement should be generated and given to the applicant.
Facilitate checking and assessing the balance fee charges for an
applicant and calculate the total amount to be paid.
Facilitate entering of the inspection and scrutiny details for the
building plan permission such as the Site Inspection Report (fields
such as application no., applied for, application date, applicant details,
usage, building category, inspector details, date of inspection, etc.),
Fee & Charges Calculations, and Certificate and Document
Verification Report. Further system should facilitate generation of an
endorsement or building permission order to the applicant, based on
76

S.
No.
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
the scrutiny.
Generate application reference for Building Plan Application/ Layout
Application for the applicant and facilitate online tracking of the
status of the application.
9
Online help should be available to the user for each system function.
Topics covered in the user manual shall also be available through the
online help.
10 Enable integration of the module with the following module to
facilitate exchange of data: Property Tax, Vacant Land Tax, Water
Tax, File Movement, Grievance Redressal, Court Cases, Financial
Accounting, Assets & Inventory, Advertisement Tax, Trade Licenses,
Project/ward works, and schemes.
11 Track delays in approval steps and maintain an audit log of the
approval process steps.
12 Ability to check for pending taxes if any add as functionality
interface.
13 Ability to track arrears due to the ULB and the robustness of the
system needs to be maintained
Layout Approval
8
1
2
3
6
7
8
Enable to enter the required documents for layout permission.

Facilitate adding/updating the required mapping documents for layout
permission.
Facilitate entering of the layout application details such as applicant
information, physical layout details, licensed architect, and the
technical data and fee details.
Facilitate entering of the nature and details of unauthorized
construction, if any, on the layout. Further, facilitate entry of the
notice details in relation to the same.
Enable applicants to fill and submit the layout approval application
online along with provision to attach necessary drawings in the soft
copy. Facilitate online verification of the documents submitted for
layout approval.
Facilitate checking and assessing the balance fee charges for an
applicant and calculate the total amount to be paid.
Generate application number for the applicant to be used by him for
online tracking of his applications status.
Facilitate entering of the inspection and scrutiny details for the layout
permission.
Name of Road
Length of Road
Existing Road Width
Proposed Road Width
Affected Road Width
Municipality
No. of Properties Affected
No. of Consents Taken
77

S.
No.
Requirement
9
10
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
No. of Structural Compensation Paid

No. of Structural covered by Court Order
Facilitate entry of and maintenance of following data, at a minimum,

on Road Widening
Facilitate entry and maintenance the following details by the system
in relation to the approved layout:
Reserved Open Spaces
Bus Bays
Parking Lots
Play Grounds
Junction Improvements
Encroachments
Drains
Water Supply
Sewerage
Electricity Lines
78

5.
Procurement & Monitoring of Projects
5.1
e-Procurement (Works)
S.
No.
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
User Authentication
1

2
for the same
Create Indent
1
2
Facilitates online creation of the works indent.

Facilitates hierarchy based workflow in the system for creation and
approval of the indent.
3
Allows linking of the indent with the overall project code.
4
Provides online templates for the indents &estimate preparation.
5
Facilitates upload of documents and plans.
6
Facilitates storing of the Schedule Of Rates (SOR in the system).
7
Integration with existing budgeting/project management module or
back-office application.
Approve Indent
1
3
4
Facilitates online review of submitted indent by the relevant

approver and capture comments of the approvers at each stage.
Captures references of all indent actions (creation, approvals,
rejections, etc).
Supports use of Digital Certificates for providing administrative
approval and technical sanction online. Allows attaching of
supporting documents with the online approval order.
Allow tracking of the indent throughout the creation and approval
cycle using the unique indent number.
MIS: Support generation of reports on:
Indents created, by type of work, value, region, etc.
Indents approved, rejected, and reasons for the same.
79

S.
No.
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
Prepare and Publish NIT

1
Facilitates online creation of the NIT. The online template (form)
should provide relevant fields to facilitate easy entry of information
by the creator.
2
Provides library of forms/templates for NIT, and tender forms.
3
Able to able to upload a tender document to the system.
4
Ability to seamlessly integrate with the indenting module.
5
Facility to select the type of tender (single, open, restricted) at the
time of NIT creation.
6
Allow to specify the minimum requirements to be fulfilled by a
bidder against each evaluation parameter.
7
Allows the bidder to bid against a parameter, if the bidder does not
fulfill the minimum requirement specified against that parameter.
8
Allow selection of multiple bid evaluation stages.
9
Facility to enter the tender schedule in the system.
10
System automatically disallows downloading of tender form beyond
the last date of procurement of tender document, disallow viewing of
a bid by the department staff before the bid opening date, etc.
11
Allow online submission of the draft NIT to the competent authority
for approval.
12
Facilitate time-tracking based escalation in case of delays at any
stage of approval.
13
Supports online review and approval of the draft NIT.
14
Allows upcoming, open, and awarded tenders to be posted on the eProcurement website
15
Viewing of the NIT requires the login information of the enlisted
contractors.
16
Facility to upload multiple corrigendum and addendum linked to the
original NIT.
17
Allow tenders to be tracked throughout their lifecycle in terms of
stage of processing, comments at various stages of evaluation, and
the decisions made.
18
Online generation of reports regarding sale/download of tender docs
and receipt of fees/EMD, list of bidders, etc.
Receive Bids
1
Allows intending bidders to download the tender document from the
e-Procurement website without paying the tender document fee (or
on payment as decided by the State).
2
Provides Integration with payment gateways for online payment of
EMD, tender document fee, etc., as decided by the State.
3
Allows registered contractors to upload and store the frequently
required certificates, statements.
4
Allows registered contractors to log-on to the e-Procurement website
for submission of bids.
5
Provides templates and support multiple contractors bidding as a
consortium.
80

S.
No.
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
Facilitates upload of drawings, technical specifications, contractors

terms & conditions (where requested in NIT), and other data on the
project along with the bids.
7
Facilitates double authentication of the bidder using Digital
Certificates: first at the time of login on system, then again at the
time of submitting the price bid.
8
System does not allow a bidder to submit a bid or to edit an earlier
submitted bid beyond the last date of bid submission.
9
Provides functionality for holding pre-bid meeting online.
10
Allow contractors to track the status of their bids online using the
bid submission number
11
Audit trails for entire tender lifecycle, from NIT creation to bids
received and selected.
Evaluate Bids & Award Contract
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Supports online access and viewing of bids by the Inviting Officer

on the scheduled date & time of bid opening.
Supports workflow for evaluation, and approvals (from competent
authorities, tender committees, etc.).
Supports separate workflows for bid evaluation based on number
and type of stages employed (Pre-Qualification, Technical,
Commercial and Techno-commercial evaluation stages).
Facilitates system tracking of the evaluation process.
Generate compliance matrices and comparative charts of received
bids to aid in evaluation by the Inviting Officer, and tender
committee.
System allows evaluation & compilation of the common set of terms
& conditions.
Record comments from all approvers at different stages of
evaluation.
Support automatic evaluation of technical and price bids by the
system using pre-specified criteria.
Support online viewing of tender opening event simultaneously by
remote bidders (e.g. in the form of chat).
Facilitate viewing/downloading of bid evaluation results and bids of
other qualified bidders, depending on the evaluation stage.
Supports automatic/manual revision of the list of eligible bidders for
sending out alerts for online tender opening event, based on the
result of the initial stages of evaluation.
System recommends L1 for selection by default.
On rejection of a bid at any stage, system makes it mandatory for the
competent authority to provide valid reason for the same.
Archiving of the entire tender proceedings as per the IT Act, 2000.
15

Tenders floated by value, type of work, & region-wise, etc.
Dynamic Pricing (Auction)
81

S.
No.
Requirement
Provides simplified menu based workflow to create online auction

by the Auction Administrator.
Allows users to be created and assigned different roles like that of
Auction Administrator, Departmental Originator, Super-Originator,
etc.
Facilitates specification of the following auction parameters at a
minimum:
Item name and quantity
Bid Decrement/Increment
Auction period or end time
Automatic extension time window
Facilitates proxy bidding for contractors, if decided by the
department.
Supports the following options:
Both Reverse and Forward auctions
Auction types- English, Dynamic Sealed bid, etc.
Auction rules- lowest/highest bid wins, highest/lowest quantity
wins etc.
Supports multi variable bidding, assigning weights to different
variables and use of formulae in an auction.
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
Supports dependent auctions i.e. it should open an auction only on

the successful completion of the previous auction.
Allows department to assign weights to different contractors based
on their past performance and quality in an auction.
Allows viewing of the lowest going price in real time, by the
bidders.
Allows Inviting Officer to view history of items and price bids
during the live auction and after with date and time stamp.
Disallows divulging the identity of the participating bidders on the
system.
Supports display of images or multi-media content, URL,
documents, and spreadsheets attachment with each auction item.
Provide option to the departmental administrator to auto-approve or
manually approve the winner in the auction.
Support for parcel auctions.
Allow generation of MIS on types of auctions and results, contractor
participation, %savings in price, etc.
Allow department to send notifications and pop-up messages to
participating bidders during the auction.
Show in real-time the time remaining for close of the auction up to
the last second to both department administrator and participating
bidders.
Provide a contractor administration module to add, delete, enable or
disable the contractors or contractor group.
82

S. No.
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
Supplier Management
1
Single site for Dept/ULBs registration as well as for applying for a

DSC.
2
Allows contractors/suppliers to apply online for departmental
registration as well as for procuring the necessary DSC.
3
Allows system to issue a unique application number to each
applicant for departmental registration as well as for DSC.
4
Allows applicants to track the status of his application online using
the application numbers provided to them.
5
Maintains database of enlisted contractors, architects, suppliers with
proper contact information to send out alerts on new tenders,
corrigendum, GOs, etc.
6
Tracks the validity period of departmental registration (and
blacklisting period) and DSCs of contractors.
7
Facility to the contractor to upload required documents (certificates,
statements, etc) in his personal space available to him after
registering online.
8
Facilitates applicants to save incomplete (partly filled) registration
application online for a specific period of time (e.g. 90 days) before
submitting for review.
9
Provides single point login for submitting response to tenders of any
department.
10
Single point login for submitting response to tenders of any
department.
11
Facilitates registered contractors to update information on their
business, address, etc. from time to time on the system.
Contractor Management
1
2
3
4
5
Provides template library for contracts with common set of terms

and conditions.
System tracks contract through various stages
Active, close, terminated.
Pre contract stages such as under construction (contract
document under construction)
Under negotiation (negotiations underway between department
and supplier) should also be supported.
Facilitates digital signing of rate contract by the competent authority
on the system, and issue of the same to the selected supplier.
Allows selected supplier to receive and acknowledge the electronic
copy of RC on the system using his digital signature certificate.
Allows integration of the Competitive Bidding and RC Catalogue
Management modules to facilitate instant availability of information
on contract terms and conditions, payment conditions, delay
clauses, etc. to the RC Catalogue Management module.
System alerts the Stores in-charge and the contracted suppliers
83

S. No.
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
when the contract is approaching its renewal date.

7
Allow extension of contract allowed under special conditions.

System should request specification of appropriate reasons for the
extension.
e-Procurement (Goods) Contract Management
1
Template library for contracts with common set of terms and

conditions. Further, user should be able to define the contract on the
selected vendor.
2
Systems tracks contract through various stages.
3
Facilitate digital signing of rate contract by the competent authority
on the system, and issue of the same to the selected supplier.
Allow selected supplier to receive and acknowledge the electronic
copy of RC on the system using his digital signature certificate.
4
Allows integration of the Competitive Bidding and RC Catalogue
Management modules to facilitate instant availability of information
on contract terms and conditions, payment conditions, delay
clauses, etc. to the RC Catalogue Management module.
5
System alerts the Stores in-charge and the contracted suppliers
when the contract is approaching its renewal date.
6
Allows extension of contract allowed under special conditions.
Indent Management
1
2
3
6
7
8
9
Rate contract catalog contains the item name, item code (system
generated or manual, as decided), a description of the item, unit of
measurement, supplier name, supplier part number (if any), rate
contract unit price, etc.
Allows products to be identified (searched) by more than one
specific identifier such as description, item code, etc.
Allows the maintenance and hosting of individual catalogues to be
controlled according to the terms of an individual agreement
between the department and its particular suppliers.
Allow catalogues in a compliant format, to be transacted through
the system for the
following options:
Supplier maintains and hosts the catalogues
Department maintains and hosts the catalogues
Suppliers and/or department maintain catalogues that are
hosted by the vendor.
Support steps for updating catalogues such as editing, reviewing,
and releasing catalogues for publishing. Any supplier updated
catalogue must be approved by the department before publishing.
Allows the department to construct and maintain menus (directory)
for the catalogues/items on the system.
Allows flexible pricing on the system for an item.
Facilitate assignment of unique code to items and sub items.
Facility to control viewing of selected item catalogues based on the
84

S. No.
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
permission level of the user.

10
Support multiple currency and language for catalogues.
Order Management Inventory Management (Health Services)
1
Facilitates tracking of inventory position of items using unique item

identifier.
2
Facilitates update of items receipts by departmental users.
3
Facilitates specification of reorder points in the system.
4
Allows configuration of order size based on the consumption of the
user.
5
Allows configuration of order size based on the consumption of the
user.
6
Tracks inventory levels and consumption information at the
consumer entities and stores to generate inventory reports, track
stock outs, etc.
Create and Approve Requisition
1
Facility for raising an online requisition by different users

(purchasers).
2
Automatically generate a unique requisition number to each new
requisition allowing it to be tracked on the system.
3
Allow each participating purchasing department to define
workflow, privileges, and set parameters that govern the approval
processes required for requisitions.
4
Provide the following requisition related features:
Allow attaching of files along with the requisitions.
Create part requisition that can be completed at a later time
Save requisitions for multiple use
Cancel/modify requisition
Support multiple delivery addresses
5
Support requisitions for listed goods and services in various
categories such as hardware, software, office equipment, drugs and
pharmaceuticals, motor vehicles, maintenance services, etc.
6
Support electronic shopping basket functionality when procuring
using online catalogues.
7
Allow setting of requisition consolidation period.
8
In case of editing/rejection of requisition by the approver, the
approver should be able to provide reasons for the same in the
system.
9
Integration with existing budgeting module (of purchasing
departments) or back-office application to facilitate validation of
order cost with available departmental budget, to avoid cost
overruns.
Purchase Orders to Payment
1
Automatic creation of PO, once the requisition has been approved

by the appropriate authority.
85

S. No.
Requirement
System should consolidate POs based on the parameters specified

by a department.
In relation to POs, the following should be supported:
Create & release of PO to the selected single supplier.
Create & release of split PO to the selected suppliers.
Create & release of POs in one lot or multiple need based
orders.
Creation of balance between easy and difficult delivery
destinations or policy as defined by the department.
Allow editing/cancellation by the purchaser/purchasing department
of the system generated PO before release.
System should provide for entering comments/reasons.
The purchaser/purchasing department should be able to selectively
release POs.
Automatic release of PO to the supplier only when such
configuration is provided by the purchasing department.
Allow the following modes of release of PO to the suppliers:
Directly update the suppliers operational systems, if available
Email with attachments
Fax
Printed output
Support electronic confirmation from the supplier upon receipt of
the online PO, using his DSC.
Automated email alerts to facilitate the creation and approval
workflow in the organization.
Allow suppliers to maintain user accounts on the portal. All alerts,
documents etc. are posted and/or mailed to these accounts.
Maintain record of all POs released supplier wise for the generation
of the draw reports to be used for demand estimation for future
procurement.
Allow entering of QA request for the third part QA agency.
Allow the QA agency to post the QA inspection results on the
system. System should alert the supplier, PO owner of the posting.
Support updating of receipt information on the system as follows:
Receipt of quantities more or less than the PO quantity, but
within specified tolerances.
Return part orders by line items, providing reason for return.
Cancel if supplier short delivers, or of unacceptable quality.
Allow purchaser to issue and update the GRN on the system.
Allow supplier to raise a bill request on the system for the delivered
goods, for the subsequent release of the payment.
System should automatically generate bill on the basis of PO, GRN,
and QA report entered into the system.
Allow settlement of payment after three way matching (Bill, PO,
goods receipt note) either on the system or on the departments
internal financial system.
Allow integration with payment gateways.
4
5
6
8
9
10
11
12
13
14
15
16
17
18
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
86

S. No.
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
19
20
Support Purchasing Card (P-Card) functionality.

Allow maintenance of QA inspection records, and GRNs (or
rejection notices) issued by the purchaser against each PO, for
existing suppliers.
21
Allow configuration of the workflow for bill verification and release
by the purchasing department.
22
Maintain auditable record of all requisitions, POs, approvals,
rejections, deliveries, and cycle times for these processes.
Management Information System (MIS) & Miscellaneous
1
2
3
4
Facilitates Department to configure/develop reports on different

parameters for trend analysis, reports on contractor participation
etc.
Provides the option for reports to be saved and printed in different
formats e.g. excel, word etc.
Common instrument numbering system for the State (Unique
procurement instrument identifier), if decided.
Facility to conduct opinion polls from contractors/suppliers,
departmental users, in order to improve the functionality/services
of the e-Procurement solution.
Help section for the contractors/suppliers and departmental users.
FAQ section to be built and continually updated with recent
learnings.
Sections providing policy documents of department, terms of use,
rules of tendering, feedback, queries, etc. should be provided on
the site.
System validations at the time of data entry, and issue of system
generated numbers (e.g. tender submission, contractor registration
numbers, etc.) so that incorrect entries and duplications are
avoided.
Auto population of form fields with previously entered data, as
applicable. Facilitate users to modify the auto-populated fields, as
applicable.
Localization
1
In respect of local settings:

The base currency of the System must be Indian Rupees.
However, system should support other currencies, such as
required in case of global
tenders.
The System must be compliant with Indian tax regulations and
other relevant legislation.
The System should be compliant with Indian IT act 2000 and
other relevant legislation.
Workflow and Configurability
1
Application workflow and privileges should be capable of being

configured based on the organization structure of the department.
87

S. No.
Requirement
Each department level configuration should be able to support

multiple sub-departments to take care of the multiple locations and
divisions with in the department.
The work flows should be flexible and configurable based on:
The product category
Spending limits
Approval limits
Intra department relationships
Inter department relationships
Supports transaction level assignment of responsibilities. The
authorized user should be able to assign different users for:
Accepting tender fee
Tender opening at all the stages
Issuing corrigendums
Dynamic workflows should be facilitated where the
creator/approver can select the next approver/reviewer.
Supports event based alerts to the authorities during the creation
and approval process.
Supports configuration of roles such as the system administrator,
super user for the departments.
Supports the diverse requirements of multiple departments.
Supports time stamping of all workflow steps such as creation,
submission, approval, rejections, etc.
Supports integration of the e-Procurement solution with existing
legacy systems or enterprise resource planning (ERP) modules to
facilitate seamless data flow between the applications.
5
6
7
8
9
10
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
Personalization
1
Supports user specific portals (entry points). The user portals can be
differentiated based on the type and level of the user, such as different
views for departmental users, contractors, the Governmental users
(Secretary, Minister, CM, etc.). The views will contain content that is
relevant to the type of user.
2 Simple graphical user interface (GUI) providing ease in navigation and use.
Provision of clear display of server date and time, user details, etc. on all
pages.
88

5.2
Project Ward Work
S.
Requirement
No.
1
10
11
12
13
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
Allow issue of Work Order to the selected contractor online. The

system should verify receipt of digitally signed undertaking (in
response to the Tender Acceptance Notice) from the contractor
before allowing issue of Work Order
Allow integration of the Tendering and Project/Ward Works
modules. Integration should facilitate instant availability of
information on contract terms and conditions, payment conditions,
delay clauses, etc. to the Project/Ward Works module.
Allow integration with the Project Accounting module in order to
facilitate tracking previous payments/advances released to a
contractor, cost overruns, etc.
Allow initiation of online measurement book. Enable contractors
login to access and update completed work information in the online
measurement book. Support uploading of measurements in the form
of pre-specified excel spreadsheet, text, etc. formats.
Send alerts to contractors and departmental staff on critical dates for
updating the online measurement book, verification of measurement
book, generation of bill, bill approval, and release of payment, etc.
System should track a contract through various stages- Active, close,
terminated. Pre contract stages such as under construction (contract
document under construction) and under negotiation (negotiations
underway between department and contractor) should also be
supported.
Facilitate login of concerned departmental officials for the purpose of
entering project related information and for providing approvals at
various stages.
Sub Engineer/SDO should be able to upload inspection reports,
photographs, etc. on the system for review of higher up authorities.
Further, system should allow documents, as necessary, to be attached
with the contract, such as the material consumption, notices issued to
the contractor, etc.
Capture information on project analytics, such as percent of work
completed against time elapsed, corresponding payments made, work
extensions, delays, etc.
Track system entries and approvals on the system against the
specified time durations. In case of delays, the system should
escalate the matter to the next higher authority.
The delaying authority shall be required to provide reasons for the
delay in the system.
Support automatic generation of the bill based on verified MB
entries, and other contract agreement terms and conditions.
Track project delays on the part of the contractor. Apply penalty
clauses at the time of preparation of the bill.
Maintain all reports/audit trails as required for the AGs audit
purpose. Compliance with relevant provisions of the Works Manual,
89

S.
Requirement
No.
14
15
16
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
Account Code, Finance Code, and appropriate statute, etc.

Allow entry of third party verification information on project
progress, quality control in the system
Maintain central repository of all contract information- Contract
status, contracted parties, contract period, goods or services covered,
and contact point(s). System should provide alerts on renewal date of
a contract
Contractor performance by class, value, type of projects
Projects on track, delayed, completed, abandoned
Defaulting contractors (non completion of projects, delayed
projects, etc.)
Project accounting- % payments made vis--vis the %
completion of project
The MIS facility should have separate interfaces for different
users (dept level/ULB, etc.)
Work wise Status
Ward wise Status
Contractor wise pending bills
Ward wise pending details.
90

6.
Health Module:
S.
Requirement
No.
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
User Authentication
1
2
for the same
3
Ability to enter new records, modify existing records, delete existing
records.
4
Ability to generate acknowledgment.
5
Ability to generate field verification checklist report for any given
date.
6.1
Licenses Module
S. No.
Requirement
Facility for addition and updating of the ULBs information in the

ULB Master
Facility for addition and updating the sanitary zone/division
information in the Sanitary Zones/wards/Division Master
Facility for addition and updating of the following in the Revenue
Wards Master:
Various revenue wards information under sanitary
zones/wards/divisions.
Various revenue blocks under revenue wards information.
Facility for addition and updating the Election Wards Information
Facility for addition and updating the Locality categories
Facility for addition and updating the sanitary ones/ward/division
allocation to Sanitary Inspectors
Facility for addition and updating:
Trade categories
Sub-trade categories.
Facility for configurations of the following:
Late fee details for the corresponding time periods in the
penalty fee master
Trade rates
Revenue Block Categorizations.
2
3
4
5
6
7
Existing
Module
(Yes /
No)
Propose
d
Module
(Yes /
No)
91

S. No.
Requirement
Facilitate the recording of the details of an applicant for a new trade

license.
Facilitate the preparation of the inspection report for recording the
findings of the field inspection of the applicants premises. Facility
for SI/HO to provide his comments.
Facilitate recording the NOC/Installation Permission Details, which
will be later used for checking while issuing the License to Industry/
Factory.
Facility for Municipal Commissioner to view the recommendations
of the SI/HO on a new license application. Facilitate the
Commissioner to also enter his remarks in the system.
Facilitate the capturing of the license fee/late fee details (Cheque/
DD details, etc.)
Facilitate the generation of a new license after the information on
supporting documents, fee details, and the necessary approvals are
recorded in the system. Facility of printing of the license document
from the system.
Facilitate recording the application details from the application form
submitted by the applicant.
Facilitate recording of the trade License renewal details.
Facilitate recording of the Panchanama details collected from the
sanitary inspectors report.
Facilitate generation of the list of defaulters who havent paid their
renewal fee. Facilitate generation of the list of license holders who
wish to close their trades on their own.
Updation of the status of a trade license as active or closed, and
the reasons for closure are entered.
Facilitate recording of the details from the application submitted by
the applicant for change of Title
Facilitate generation of license with changed title, after the
necessary supporting documents, fee, and approvals are entered in
the system.
Facilitate capturing of details of the un-assessed trades, i.e.,
individuals performing trade without a proper trade license
Track the renewal notices sent to the license holders to renew their
License. Further, track response dates, late fee applicability, etc
Facilitate capturing of grievances against a license, or in general.
Facilitate generation of demand collection and balances revenue
ward-wise for the ULB.
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Existing
Module
(Yes /
No)
Propose
d
Module
(Yes /
No)
6.2 Solid Waste Management

S.
Requirement
No.
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
92

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Facility for addition of the new division details to the Division

Master.
Facility for entering location details under particular division of the
Municipality.
Facility for entering various data on public toilets of the Municipality
to be entered into the Public Toilets Master.
Facility for integration with the Personnel Management System to
obtain information on the following types of staff under the sanitary
wing of the Municipality:
Route employees.
Sanitary inspectors responsible for checking the sanitation
activities, and the divisions allotted to them.
Sanitary maistry / jawan responsible for checking the sanitation
activities, and the divisions allotted to them.
Facility for entering details of the garbage-collection place such as the
garbage collection place type, name, and fees collection location.
Facility for entering coordinates of dustbins located at various
locations within the Municipality.
Facility for entering different types of vehicles available to be entered
into Vehicle Type Master.
Facility for entering details of the Hospitals/Hotels/Lodges located in
the Municipality.
Facility for entering the details of the transmission station.
Facility for entering the details of the dumping ground to be entered
in the system.
Facility for the Sanitary Inspector to enter the attendance of the
employees in the system.
Facility for entering the details of the trip sheet, which includes the
information about the vehicle used for transporting the garbage, and
the number of trips it makes, to be entered into the Trip Sheet Table.
Generation of tentative allocation of workers to locations based on
historical garbage collection patterns.
Facility for recording of the garbage volumes from different locations
dumped at the dumping grounds.
Generation of tentative allocation of vehicles to locations and routes
based on historical garbage collection patterns and the optimal
routing.
93

7.
S. No.
Accounting Module
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
User Authentication
1

The municipal corporation users to have access to various
databases and to query on the different master maintenance
tables based on the user-ids and passwords.
2
The usage of pin codes, Token and key, Biometric
Authentication Methods such as Finger Print Technology etc
for second level of authentication may be considered and
justification is to be provided for the same
Accounting System
3
Facility for incorporating all formats for reporting and books

of accounts as prescribed in the National Municipal Accounts
Manual.
4
Facility for incorporating of existing formats of registers in
specific ULBs.
5
Some of the Reports required are
Accounts analysis reports (Revenue, Expenditure,
fixed assets etc)
Charts of accounts listing report
Inactive accounts listing report
Suspense accounts report
Consolidation report
Inter department transaction details report
Unapproved inter-department transaction details
report
General Ledger report
Journals Report
Journals Day book report
Journals- Vouchers report
Trial balance report
Cash book reports
Bank Reconciliation Statement
Payments
6
7
8
Facility for maintenance of master database of all suppliers,

contractors and vendors.
Facility for calculation of Sales Tax, Tax Deducted at Source
etc.
Accounting system should book the liability on entry of these
amounts and an appropriate entry should be made based on
double entry accrual based accounting principles.
Allow add and modify invoices, credit and debit memos, pre-
94

S. No.
10
11
12
13
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
payments, holds, invoice notices etc.

Allow disbursement of payments(salary,
contractors/suppliers, administrative expenses, PF, profession
tax, etc)
Employee database and calculation of salary and statutory
(PF, PT, etc) payments for each employee
Entry of the consolidated salary and Statutory (PF, PT etc.)
payment amounts for each department in the accounting
Final payment register
Payment exception report
Stopped payment report
Invoice register
Invoice aging report
Invoice approval status report
Accounts payables trial balance report
Period close exception report
Posted invoice register
Posted payment register
Unaccounted transaction report
Receipts
14
Receipts of collections (Property Tax, Water Tax, rent,

Grants, Security Money and Earnest Money, etc.)
15
Enter and update citizens identification number, name and
address
16
Allow enter/ modify discounts or waivers
17
Record/ Modify a bill raised as an asset
18
Final receivable register
Revenue trend analysis statement
Ageing Reports for both debtor and creditor, (Ageing
report should be user defined)
Fixed Assets
19
20
21
22
23
24
Accounting System should be able to maintain the Fixed

Asset Register.
Allow query asset based on asset number.
Allow add/update certain details like description or category,
change an assets location, responsible employee,
Manufacturer, Model, Warranty details.
Facility to calculate the Depreciation of Assets, based on
different formulae for example straight line method etc.
Allow mass addition transfer, mass depreciation, revaluation,
retirement of assets
Update information from fixed asset module to general
95

S. No.
25
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
ledger module
Financial reports regarding assets
Asset depreciation report
Quarterly statement of departmental assets
Transaction history report (Addition, transfer,
Retirement etc)
Asset register report
Asset retirement report
Asset by category report
Cost detail report
Budget
26
27
Provision for budgeting

Facility for display warning messages in case the budgetary limits
are exceeded
28
Support analysis
29
Budget approved report
Budget trend analysis
Variance Analysis of Budget Vs Actual
Financial Statements
30
31
Balance sheet
Income and Expenditure account
Receipts and Payment Account Showing the receipts
and payments of cash major head wise along with
schedules
Cash Flow Showing the receipts and payments of cash
bifurcated into operating, investing and financing
activities
Regular Registers:
Abstract Register of Receipts and Payments
Register of Investments
Register of Adjustment
Advance Ledger
Deposit Ledger
Loan Register
Fixed Assets Register
Appropriation Register
Register of unpaid bills
Register of dishonored cheques
Borough/ Zone/ Ward wise Accounts
96

8.
Sr.
No.
Personal Information System:

Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
User Authentication
1

user-ids and passwords..
2
for the same
Manpower Planning
1
Enable users to maintain a head-count budget of the ideal

workforce, which will be used to look at the variances based on the
actual staff strength.
2
Ability to identify gaps of required competencies and available
competencies.
3
Define budgets against Departments, jobs, grades, positions or any
combination of these.
4
Ability to review budgets over a period of time. This review should
be able to be made by Department, division, unit etc. Also by job/
position or combination.
5
Ability to view the status of budgets and actual and also variances of
budgets over time.
Position Management
6
7
8
9
10
11
12
13
14
15
16
Ability to encumber (reserve) a position that is not currently filled

Ability to track the history of the position (e.g. former employee(s)
in position) and also maintain position and pay history of current
employees.
Ability to update salary amounts for each classification and
scale/bracket.
Ability to automatically calculate and transfer salary when an
employee transfers to a different Department/division, as authorized,
even mid-pay period.
Ability to assign multiple employees to a single position (job
sharing).
Ability to assign a single employee to multiple positions.
Ability to track filled and vacant positions by position number.
Ability to plan Shifts and Schedule manpower accordingly.
Ability to administer multiple shift schedules.
Ability to identify shift plans for Departments and work crews based
on actual or forecasted workload.
Ability to identify requirements by type of job or specific
97

Sr.
No.
Requirement
Existing
Module
(Yes / No)
Proposed
Module
(Yes / No)
qualifications.
Ability to administer shift plans considering defined requirements
along with employee preferences, qualifications, and availability.
18
Ability to process day-to-day changes in the shift schedule based on
transactions that affect requirements or availability of staff.
19
Ability to identify and utilize on-call staff.
20
Ability to administer various workweeks and part-time
arrangements.
Promotions
17
21
Ability to capture data regarding proposals for promotions for both

gazetted and non gazetted employees from different
Departments/ULBs
22
Ability to link promotions to a variety of employee related issues.
Employee Separation
23
Ability to capture data regarding proposals for resignations for all

employees from different Departments
24
Ability to reject resignation proposal of employees placed under
suspension for disciplinary reasons
Relevance & Timeliness of Accessing Information
25
Ability to maintain employee records and data tables on an effective

date basis, allowing inquiry and reporting for effective manpower
planning and budgeting.
26
Ability to/raveling/flexible security to provide access to information
on a need to know basis.
Reporting
27
MIS can be for a particular date or date range, in different fields like
Department, section, name and designation of the employee etc. The
system should be able to generate, but should not be limited to, the
following reports:
Staff turnover
Staff movement
Vacancy requisitions
Promotions
Resignations
Employee Cost
98

Sr. Requirement
No.
Integration and Interface
Existing
Module
Proposed
Module
28
Ability to export information to spreadsheets (e.g. Microsoft Excel)

for year-end review.
29
Ability to interface with knowledge database to access information
relating to Government Orders and checklists for the processing of
Information.
Workforce Recruitment
30
Ability to maintain application information in the fields of

(indicative):
Name,
Gender,
Address,
Telephone number,
Business number,
Preferred method of contact (e.g. phone, mail, etc.)
Date of application,
E-mail address,
Source of application,
Date of Birth,
Ethnicity,
Status (e.g. applied, declined, recruited etc.)
Type of application (e.g., temporary, permanent etc.)
Salary history,
Employment history,
Language proficiency
Education,
Disability (Y/N)
Position(s) applied for (multiple)
Exams (e.g., psychical/medical)
Work Restrictions,
Licenses/certifications/registrations,
Caste category
Passport number
Martial status
PAN number.
99

Sr.
No.
31
32
33
34
35
36
37
38
39
40
41
42
43
44
Requirement
Existing
Module
Proposed
Module
The system shall be able to maintain job information in the fields of

but is not limited to:
Number of job openings
Employee number of person requesting, authorizing, and
initiating requisition
Job descriptions
Position number/job code
Salary Plan
Scale of salary grades
Job location
Working hours
Start date
Full-time/part-time
Necessary educational level, work experience.
Ability to provide a summary of the applicants that have been hired
against the job requisition.
System acceptance of electronic applications (e-mail, Intranet,
Internet, electronic forms) including optical scanning to enter
resumes and convert into data for further references.
Ability to enable applicants to learn about and apply for multiple
jobs.
Ability to track the number and types of positions for which an
applicant applies.
Ability to compare requirements of a vacant position with an
applicants existing skills to determine necessary training and
overall fit.
Maintenance of different types of tests and associated
questionnaire.
Ability to generate questionnaire based on competencies defined for
a job.
Ability to record and maintain proper information for cases of
applications on compassionate grounds.
Ability to maintain complete employee information, historical and
current. Especially in the area of maintaining images (photos, CVs,
appraisals, etc.).
Ability to resurrect an expired employment list if required.
Ability to notify applicant that additional documentation is needed
or put an eligible applicant on hold till the Department gets all
needed information for hiring.
Ability to track progress of a candidate in any step of the
recruitment process.
Ability to maintain history of interviewed but not selected
candidates.
100

Sr. Requirement
No.
Interviewing
Existing
Module
Proposed
Module
45
46
System possesses efficient tools like a Scheduler/ Calendar

Ability to view a list of applicants invited for an interview at the
State.
47
Allow users to enter interview results and select successful
applicants.
48
Allow users to view a listing of successful applicants and their
relevant details.
Online Forms
49
Ability to provide for online forms where Human Resource systems

do not provide self-service or when self-service is available as a
backup.
50
Availability of a repository for online forms.
51
Ability to submit forms electronically to processing centre.
52
Ability to index forms to allow easy user access.
Contractual Terms
53
Ability to record the following basic information about the contract

between the State and the candidate:
Contract duration
Contract type
Contract information.
Reporting
54
Ability to generate, but is not limited to, the following reports:

Applicant selection
Applicant statistics
Applicants by Name
Applicants by education and qualifications
Vacancies
Applications made on compassionate grounds
Promoted applicants
Transferred applicants
Direct recruitments
Performance Management
55
56
57
58
Ability to position specific KRAs and targets

Ability to use a variety of appraisal models as templates to support
appraisal process.
Enable users to define rating codes to assist in rating an employees
performance. These codes may be alphanumeric.
Facility to allow users defines a rating model and the associated
rating scales and weights of relevant employee skills or
competencies.
101

Sr.
No.
59
Requirement
Existing
Module
Proposed
Module
Ability to define an unlimited number of criteria, criteria groups and

evaluation scales to meet the needs of your department needs.
60
Ability to maintain appraisal model in a catalogue.
61
Ability to create anonymous appraisals in the system.
62
Ability to deliver just-in-time training to fill performance gaps.
63
Ability to include qualifications as an appraisal element.
64
Ability to send reminders to respective employees to submit/ review
appraisals.
Training Development
65
System should provide every course with a unique code, specific

topics and objectives.
66
Ability to use planning tools to determine course demand for a
period based on pre-bookings and/or actual attendance from the
previous year.
Self-Service
67
Enablement of application of training for approval by the
appropriate supervisors via self-service functionality.
68
Ability to allow employees to search for classes based on topic, text,
language and location, etc. using a full-text search engine.
69
Ability to allow employees to view training calendar and details.
70
Ability to allow employees to enroll in classes or cancel
participation in classes.
71
Ability to allow employees to pre-book classes that are not yet
scheduled.
72
Ability to view date, time and content on courses and events that
have been booked.
Compensation Management - Benefit Plans
73
Allow enrolment of employees in benefits programs and plans.
Employees will be enrolled according to the following criteria:
Base
Grade
Years of service
74
Allow setting up the following types of benefits plans for employees
over a specified number of years old (in order of priority):
Health benefits
Insurance benefits for employees, spouses, and children
Investment (unit trust)
Leave benefits
Pensions
75
Ability to define a benefit plan as required.
76
77
78
79
Ability to assign benefit plan codes by employee based on their

classification (to identify level of benefits for which each employee
qualifies)
System to allow the entry of pre requisites needed.
System to have the ability to define plan status.
Ability to track employees coverage and coverage level based on
102

Sr.
No.
Requirement
Existing
Module
Proposed
Module
their position.
Managing Benefits
80
The system shall allow for the maintenance of the following benefits
costs and employee deductions information:
Age-graded rate tables
Salary rate tables
Service rate tables
Flat rate tables
Calculation rules tables
Premium
Coverage
Age
Service dates
Rounding rules
Min/max coverage
Benefits deduction from payroll (e.g. insurance premiums).
Managing General Provident Fund
81
82
Allow the DMA/ULBs to define eligibility rules for admission to

GPF for employees.
Allow the DMA/ULBs to:
Process GPF balance
Process GPF temporary advance
Modifying GPF subscription.
Travel Management
83
84
85
Ability to interface with knowledge database to access information

relating to Government Orders and checklists for the processing of
leave travel concessions (LTCs) for employees.
Ability to enter travel data by respective employee with prior
approval by respective approver, either before or after the trip.
Ability to facilitate application of travel or tour advances and send
trip requests automatically to the appropriate approver via
workflow.
Payroll Processing - Payment and allowance & Deduction Processing

86
87
88
89
Ability to calculate payments based on employee compensation

rules, and employment contract.
Ability to calculate different type of pays. For example basic,
allowances, bonus etc.
Ability
to
define
pay
type.
For
example
hourly/daily/weekly/monthly etc.
Ability to define different pay elements. Pay elements could be
103

Sr.
No.
90
91
92
93
94
95
96
97
98
99
Requirement
Existing
Module
Proposed
Module
fixed value or calculation based on other pay elements

Ability to group employees by Department in any manner without
having to set up multiple employee records for each Department.
Ability to maintain an integrated security design to ensure that
employees dont get paid twice in one payroll period without
authorization.
Ability to make automatic calculations for flexible benefits.
Ability to view Employee costs per Department/division and costs
per job, position.
Ability to give employees the option of prepaying some of their
deductions when they go on leave. The system should automatically
deduct funds from an employees prepaid deduction balance if the
employees normal pay is not sufficient to cover the deduction
Ability to make automatic calculation of mid-pay period changes to
pay, benefits, deductions, and taxes.
Ability to generate monthly pay-slips for the employees, for at least
last 6 months.
Ability to pay an employee from more than one Department and
split salary and benefits among Departments, including retirement
benefits.
Ability to process payroll on the following frequencies:
Biweekly,
Monthly
Semi-monthly,
Bi-monthly,
On-demand (i.e., terminations, vacation advance, court order,
ratification.).
Allow maintenance of salary code tables and code descriptions. It
should also have the ability to formulate multiple user-defined codes
including, but not limited to:
Salary,
Hourly rate,
Vacation,
Daily Allowance
HRA
Deputation Allowance
Sick,
Overtime,
Meals and lodging,
Expense reimbursement,
Various overtime reason codes,
Uniform allowance,
Bonus and Premium pay,
Taxable non-cash benefits,
Administrative Leave,
Travel Allowances,
Disability Pay,
Holidays,
104

Sr.
No.
100
Requirement
Existing
Module
Proposed
Module
Others (user defined).

Allow maintenance of salary code tables and code descriptions. It
should also have the ability to formulate multiple user-defined codes
including, but not limited to:
Salary,
Hourly rate,
Vacation,
Daily Allowance
HRA
Deputation Allowance
Sick,
Overtime,
Meals and lodging,
Expense reimbursement,
Various overtime reason codes,
Uniform allowance,
Bonus and Premium pay,
Taxable non-cash benefits,
Administrative Leave,
Travel Allowances,
Disability Pay,
Holidays,
Others (user defined).
105

Sr.
No.
101
102
103
104
105
106
107
108
109
110
111
112
113
Requirement
Existing
Module
Proposed
Module
Allow different account codes and cost centers for different

employee types can be defined for the same salary code.
Ability to allow use of an earning or deduction code to calculate
another earning or deduction code as part of formula calculations.
Payroll database should be automatically updated when changes are
made to the employee record database
Time sheet information could include, but not be limited to:
Employee name,
Employee number,
Department name & number,
Work function number/description,
Class number/title,
Regular pay hours,
Overtime hours and reason,
Leave information,
Multiple pay rate,
Leave balances,
Sick balances,
Other balances (set by any user defined criteria).
Ability to enter and monitor attendance details of all the employees.
Attendance details can be entered in the fields of:
Time spent in office,
Overtime hours and reasons,
Type of leave if not attended work.
Ability to enter attendance information:
Online, interactive by employee,
Batch,
Multiple data entry capability including card readers, bar
coding, etc.
Ability to account for time based on type of absence or attendance.
Ability to submit corrections.
Ability to request cancels or modifies requests time off, and receive
approval or denial from immediate supervisor.
Ability to monitor attendance records on a daily, weekly, and
biweekly basis.
Ability to pay all types of reimbursements through payroll.
(Medical etc.)
Ability to track and maintain work schedules by position,
classification, and/or employee.
Ability to track actual hours worked by work schedule by position,
classification, and/or employee.
106

Sr.
No.
114
115
116
117
118
119
120
Requirement
Existing
Module
Proposed
Module
Pay check procedure should incorporate but not be limited to the

following fields:
Personal account number
Department number
Employee name
Period ending
Issue date,
Class number
Pay rate
All types of payment and reimbursements (e.g., regular,
overtime, paid leave, etc.)
Gross pay
All earning and deduction types adequately itemized and
defined by taxability status
Cumulative hours for time-limited employees,
Current and Year to Date Totals:
Employee pension
Income tax
Insurance
All other deductions
Medical compensation
Vacation hours balance
Sick leave hours balance
Other leave hours balances (multiple categories)
Gross earnings
Taxable/non-taxable earnings
Workers comp (injury leave)
Other deductions and amounts
Total deductions
Net pay.
Ability to automatically update payroll database when Finance
Department makes pay rate changes.
Ability to handle salary advances & facilitate recovery of salary
advances on the payday.
Ability to make back dated calculations. For example if staff
received promotion letter in June, effective April 17th, the system
should be able to pay off difference for 15 days of April and month
of May.
Ability to get reports on payroll for comparisons. For example
Year-to-date and Last year-to-date, this month and last year-samemonth etc.
Ability to update master salary scales during wage/ salary revisions.
Ability to pay a rate greater than a specific rate based on a
percentage entered as a bonus rate in the employees database.
107

Sr.
No.
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
Requirement
Existing
Module
Proposed
Module
Ability to calculate bonuses and premiums based on fixed rupee

amounts, percentages of base pay, pro-rated on hours of paid service
or paid with minimum paid service and to designate which bases are
subject to mandatory payroll deductions.
Ability to cash out accumulated leave balances by user defined
formulas and criteria.
Ability to have payroll adjustments reflected in correct pay period.
Ability to have an established base pay regardless of hours worked.
Ability to have different hourly rates for an employee for different
days within the same payroll period
Ability to allow for pre-calculation of payroll outside of the normal
payroll system.
Ability to re-calculate payroll for changed hours, etc.
Ability to make one time payment. For example for people working
on a specialized program, Employee of the month/ year reward etc.
Ability to provide for online ad-hoc calculation of employees pay
check amount.
Ability to support separate tax tables for special pay calculations
(flat tax).
Ability to perform online calculation of pay and benefits for
terminated employee based upon termination date.
Ability to report all changes to employees pay, deductions, taxes,
etc.
Ability to report tax payments by employee.
Ability to change tax filing status and number of exemptions of a
particular employee.
Ability to report retirement deductions by employee.
Ability to transfer salary and benefit costs electronically to the
budget application from payroll and human resource modules for
position budgeting and personnel salary and benefit projections.
Ability to calculate different types of bonus. E.g. performance bonus
etc.
Ability to calculate bonus outside the system.
Facility to import and update as pay element for employees
Ability to add or update bank information for direct deposit and
expense reimbursement.
Ability of system to calculate bonus based on appraisals, grades and
days on work in a year.
Any updation of records, pay elements should be with a reason
code.
Ability to produce benefit eligibility lists upon request for
employees.
Ability to request downloads of payroll information to begin budget
preparation by Finance Department.
Ability to provide for payroll reconciliation facilities. For example
provide reconciliation between the following:
Differences in salaries of existing employees from previous
108

Sr.
No.
Requirement
Existing
Module
Proposed
Module
years
Differences in salaries between new & resigned employees
Bonus Triggering
146
Ability to calculate bonuses, based on the following information:

Employee type
Employment term
Bonus details
Bonus calculation base
Reason code
Date joined
Last pay date
In service date
147 Ability to accept user-defined formulas for calculating bonuses.
148 Ability to make fixed payments to employees, by effective dates.
The system shall also be able to trigger backdate adjustments and to
pro-rate bonuses.
149 Ability of system to generate bonus letters, increment letters.
Payments/Deductions Type
150
Allow for, but is not limited to, the following deductions and
advancement:
Medical benefit deductions
Special retirement scheme deduction
Ad hoc and regular deductions and payments
Loans and advancements
Housing Loans
Vehicle
Educational
Festival advances
Court order deductions
Fixed and variable payments and deductions.
Fixed Payments/ Deductions
151
152
153
Ability to calculate fixed monthly payments/deductions (FPD).

FPDs may be amount or formula
Amount-based FPD is paid/ deducted directly from employee
payrolls.
Allow FPD deductions to be pro-rated according to the effective
date and expiry date of the FPD.
Variable Payments/Deductions
154 Ability to calculate variable payments/deductions (VPD). VPDs
may be amount or formula-based.
155 Amount-based VPD is paid/ deducted directly from employee
payrolls.
156 VPD input and approval workflow can be decentralized to branch
departments.
109

Sr. Requirement
No.
Suspension Functions
Existing
Module
Proposed
Module
157
158
Ability to provide suspension functions in the Payroll system.

Ability to handle different types of suspension, including all payroll
exceptions.
159 Allow suspension functions to be used for the suspension of
payments, or processing of specific payment types/for specific
periods.
Advance Payments
160
Ability to perform advance payments (e.g. exit staff, hardship

reasons).
161 Allow a staffs final payment to be made on a last working date,
instead of the last pay date.
Statutory Contribution Administration
162
Ability to define all rules and criteria, calculate, record, withdraw,

and/or deduct contributions, at the minimum, of statutory
contributions according to the respective Statutory Acts. The
statutory returns should be captured by the system.
163 Ability to incorporate all types of statutory reports and have the
ability to meet new laws and requirements as they develop.
Payroll Master Record
164
Display the status of each of the following payroll transactions:

Incur-Month
Payroll Audit Trail Code
Trans-Status
Ledger-Posting-Status
Settlement Means.
Cost Tracking
165
Allow users to track, at the minimum, the following cost:

Project payroll cost.
Pay slip Presentation
166
Ability to generate employee pay slips on-line for printing by

employees through Employee Self-Service.
167 Group items on pay slips by salary code and by incur-month.
168 Capability to handle different pay slip designs.
Reporting
169
Ability to maintain an unlimited earnings history and should have

the capability of generating different payroll related reports. For
example
Payroll register
Deductions register
Tax register.
110

Sr.
No.
170
Requirement
Existing
Module
Proposed
Module
Ability to maintain an efficient archiving program to manage the

generation, administration and evaluation of archived payroll files.
171
Provision for the following user friendly reporting capabilities:
Easy data management and information retrieval
Data mining and analysis
Flexible reporting
Annual package tracking.
Integration and Interface
172
Integrated to the following systems of the finance department:

General Ledger
Accounts Payable.
173
Ability to integrate with travel expenses and benefits in order to
trigger automatic payments/deductions in employee payroll records.
Workforce Administration - Maintain Basic Data
174
175
176
177
178
179
180
181
Ability to automatically generate the Employee ID, personal data in

a sequentially order.
Ability to build model for Department/division etc. The
Departmental Chart can be viewed from different angles like
positions held, vacant, vacant budgeted, vacant not budgeted,
temporary responsibility etc.
Ability to change users indicative data such as name, address,
contact information, beneficiaries, etc
Ability to track and maintain personnel action changes for each
employee.
Ability to track employee language abilities by language, level of
proficiency.
Ability to track transactions based on the transaction date
Ability to notify via e-mail when action is required regarding
employees (e.g., personnel changes, evaluation dates, etc.)
Ability to transfer an employee to a different Department or payroll
unit without reentering the entire employee file.
111

Sr.
No.
182
Requirement
Existing
Module
Proposed
Module
Ability to automatic monitor dates for Human Resource processes,

allowing officials to specify date-driven reminders to initiate follow
up activities (for example, expiration of probationary period, pay
increases, return to work, performance review)
Employee History
183
Maintenance the employee history, including tracking employee

events in chronological order (e.g. hire, rehire, transfer dates)
184 Ability to track at all procedural levels by type, dates and
employee:
Salary Change
Performance Report Appeals
Grievances (status, date of event and final ruling)
Workers compensation status
Disciplinary actions (paid/unpaid etc)
Future leave approval (e.g., approved, deferred, rejected)
Status changes
Leave status (vacation, sick, injury or any other user definable
field)
Work Restrictions (e.g. no lifting)
Modified Duty (e.g. night duty hours)
185 Ability to maintain employee personnel history online beyond the
life of the employee
186 Ability to record exit interview information (e.g. interviewer name
187 Ability to maintain employee turnover data (e.g. termination/
resignation reasons)
Job Information
188
Ability to maintain, but is not limited to, the following information:

Employee employment designation
Employee grade level
Employee job level
Employee designation
Employee probation dates
Employee compensation rate & frequency
Employee annual benefits base rate
Employee pay scales.
112

Sr. Requirement
No.
Employment Contracts
Existing
Module
Proposed
Module
189
Allow users to set up standard employment contracts with the

following information:
Contract types (standard, bonding, overseas posting)
Contract duration
Contract clauses (effective dates, status, description, comment)
Contract templates for different employee types.
190 Enable users to generate and print out employment contracts.
Contract Tracking
191
The system shall maintain the following contract information:

Duration
Start date
Expected end date
End date
Minimum & maximum length of service
Employee-specific clauses
Probation dates & reasons.
Security Levels
192
Tracking the system security level and the security key card(s)
issued to employees.
193 Ability to maintain the following security information:
Effective dates
Status
Card number
Comments
Employee ID.
194 Provision for information confidentiality and allow for different
user access level.
195 Allow users to audit, track, add, amend and delete information
based on user security access level.
Prior Work Experience
196
Maintain the following prior work experience of employees:

Employment tenure (start and end dates)
Names of previous employers
Relevant work experience
Location
Job titles
Pay rates.
113

Sr. Requirement
No.
Checklists
Existing
Module
Proposed
Module
197
Ability to create checklists for users to ensure performance of

established procedures.
198 Ability to assign checklists to users and monitor the status of tasks
in assigned checklists.
Templates
199
Ability to maintain templates for report and standard letters. Once a

report template is generated it should be available to all authorized
users to avoid duplication
Dependents/Beneficiaries
200
Allow users to record the following information on dependents

and/or beneficiaries:
Names
Relationship to employee
Type of relationship
Addresses/contacts
DOB
Place of birth
Location
Gender
Marital status
Occupation
Leave Management - Absence Data
201
Allow users to define absence data such as:

Absence types
Codes.
Annual Leave
202
203
204
205
206
207
Ability to track leave by type, (e.g. maternity, casual, sports,

optional, commuted, half pay, study, hospital, earned, disability,
compensatory etc.), reason, hours accrued, accrual frequency (e.g.,
monthly, pay period, etc.), automatic adjustments based on length of
employee service, carryover balances and accrual limits.
Ability to keep track of holidays and to define weekly holidays and
other holidays.
Ability to send e-mail to supervisor to withdraw/disable facilities of
an employee when he/she is going on leave. For example NT
password etc.
Ability to track leave used in lieu of sick leave.
Ability to set a trigger files for notification for expiration of a type
of leave status (e.g. expiration of a temporary position, etc.).
Ability to trigger required supporting documentation based on use of
leave (e.g. doctors notes, etc.).
114

Sr.
No.
208
Requirement
Existing
Module
Proposed
Module
Ability to track concurrent leave status (e.g. maternity leave with

sick leave).
209 Number of days of a leave to be rule based.
210 System not to force above or similar calculations or adjustments
unless confirmed as the Department may want to adjust sick leave
against available annual leave.
211 Ability to track leave taken by employee, type of leave, hours taken,
and balance.
212 Ability to alter criteria as per the changes in the policy.
213 Ability to suspend and restart accruals.
214 Ability to track eligibility and qualifications for family medical
leave, sick subjective/other leave.
215 Ability to compute termination pay-offs.
216 Ability to track annual physical exams as well as other physical tests
(e.g., Fitness test, etc.).
217 Ability to track professional license renewals required for position
(e.g., medical positions) and to track reimbursement of renewal
costs.
218 Ability to track safety-sensitive position employees for drug/alcohol
testing and maintain separate confidentiality for record.
219 Provision for leave accruals earned during paid absence should be
accumulated but not credited for use until employee returns to duty.
220 Ability to assign leave benefits based upon level and classification
of employee.
221 Facility for leave encashment.
222 Provide a detailed order stating the approval/rejection of leave
request.
Self-Service
223
Enable on-line application of leave for approval by the appropriate

supervisors via self-service functionality. Users shall also be able to
view their leave entitlements and balance on-line.
224 The system:
Check for approval from supervisors
Check for a substitute appointment for the person taking leave.
Leave Schedule
225
226
Allow for supervisor to view employees leave schedule and allow

for tracking of staff working on shifts. The system shall also allow
for the creation of leave charts.
Integrated to on-line Employee Attendance System
115

Sr. Requirement
No.
Employee Relationship Management - Disciplinary Actions
Existing
Module
Proposed
Module
227
Allow users to maintain information on the following employee

disciplinary activities:
Violations requiring disciplinary action
Disciplinary actions processes and activities
Types of disciplinary action
Details of disciplinary incidents and resolutions
Tracking of disciplinary cases
Employee Grievances
228
Allow users to maintain information on the following employee

grievances:
Types of workplace grievances
Grievance actions processes and activities
Types of grievances
Details of grievances and resolutions
Reporting
229
Ability to generate, but is not limited to, the following reports:

Employee disciplinary history
Employee disciplinary letters
Employee grievances history
230 Ability to provide for Employee movement tracking. It should be
able to provide detailed MIS reports on employees. For example
employee information in respect to hiring, job assignment,
transfers, salary revision, awards, recognition, promotion,
demotions, and warnings till the employee leaves the Department.
231 Ability to link to the Confidential reports(CR)
Loan and Advance Management - Loan Management
232
233
234
235
236
237
238
Ability to accrue or charge interest either through a loan account or

through a designated account.
Facility of e-mailing respective Departmental Branch (e.g.
Treasuries & Accounts) to credit account of an employee and also
e-mail an employee on approval or rejection of loan.
Ability to recover loans on the salary day.
System to provide for tiered interest rate facility.
Ability to defer installment and recalculate installment values after
deferment.
Ability to project loan commitment of a Department.
Facilitate holding of different types of loans by a single employee.
116

Sr. Requirement
No.
Management of Employees Qualifications - Qualifications Management
239
240
241
242
243
244
245
Existing
Module
Proposed
Module
Ability to define profiles for employees, applicants, work centers,

tasks, jobs and positions, specifying the type of information to be
stored in each profile such as qualifications, requirements,
preferences, dislikes, and potential.
Ability to identify specific requirements of a job or task as essential,
allowing the comparison of individual candidates based on only the
most important attributes.
Ability to record the qualifications required while performing
specific jobs or tasks, including work-related skills and specific
certifications or licenses in the qualifications catalogue.
Ability to identify qualifications such as memberships/licenses that
may expire and require renewal, and track expiration dates.
Ability to link qualifications that are similar and define them as
alternatives, meaning that one qualification can be used in place of
another to fulfill all or some of another requirement; for example,
several years of education may be an alternative to a year of
experience
Ability to match an individuals skills or qualifications to those
required for a position to identify any gaps and then propose training
and development plans to acquire the necessary skills
Ability to track job classification in fields of:
Record of job classification code(s)
Licenses, Certificates and Registration requirements
Degree Requirement
Minimum Requirements
Salary scale
Workers Compensation code
Employee type (part time or full time),
All other user defined information.
117

11.3 Annexure 3- Risk Log
Project :
Date of Log:
Prepared by:
Validated by :
Basic Risk Information
Risk
Number
Risk
Responsibility Date
Description
Reported
Date:
Risk Assessment and Mitigation Information

Last
reviewed
Impact
Impact
Mitigation
Description Strategy
H/ M /L
<<Provider <<What is <<Name

of
a unique the
the
Team
risk
identifier
member/
about?>>
for
the
stakeholder
Risk>>
responsible for
taking
action>>
Day/
Month/
Year
Day/
Month/
Year
<<Enter
the date on
which the
risk was
reported>>
<<Enter
the latest
date
on
which the
risk was
Updated>>
<<Enter the
probability
of
impact
High/
Medium/
Low
according to
probability
definitions>>
<<What
will be the
impact on
the project
because of
the
identified
risk>>
<<Enter the
types
of
strategy to
be adopted
for
mitigating
the risk
a)Avoidance
b)
Reduction
c) Retention
d)Transfer/
Share>>
Risk Response Information
Timelines Completed
Actions
Day/
Month/
Year
Planned
future
Action
<<Enter
the
timelines
for
mitigating
the risk>>
<<List
by date
what
actions
will be
taken to
respond
to risk
in
future>>
<<List of
all actions
taken
to
respond to
risk>>
Risk Status
Day/
Month/
Year
a) Open
b)No
Plan
(NP)
c)Plan
enacted (PE)
d)Plan
Effective
e)Closed
118


Model DPR Guidelines

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Model DPR Guidelines

Hochgeladen von

Copyright:

Verfügbare Formate

e-Governance in Municipalities: Model DPR Guidelines for State Level DPR

Ministry of Urban Development

Ministry of Urban Development