Model DPR Guidelines

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

1

Ministry of Urban Development

“e-Governance in Municipalities”

Model DPR Guidelines

For State Level Detailed Project Report

April 2010


1

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

4.1.1 Application Details ____________________________________________________ 21 4.1.2 Hardware, Network Infrastructure Components ____________________________ 21 4.1.3 Network / Server Architecture ___________________________________________ 22 4.1.4 Information Security Measures __________________________________________ 23

4.2 TO-BE IT Landscape ______________________________________________ 23 4.2.1 Solution Architecture __________________________________________________ 23 4.2.2 Application Architecture ________________________________________________ 25 4.2.3 Information / Data Architecture _________________________________________ 26


2

4.2.4 Technology / Deployment Architecture ____________________________________ 26 4.2.5 User Interface _________________________________________________________ 27 4.2.6 Network and Server Architecture ________________________________________ 28 4.2.7 Security architecture ___________________________________________________ 30 4.2.8 Integration with SWAN & SDC __________________________________________ 31 4.2.9 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 ULB’s ___________________________ 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 5.3.1 Current Organization __________________________________________________ 35 5.3.3 Proposed Organization _________________________________________________ 35

5.4 Staffing and Deployment Strategy ____________________________________ 36

5.5 Training Strategy __________________________________________________ 36 5.5.1 Training Need Assessment and Content Development ________________________ 36 5.5.2 Identification of Delivery Channels for imparting training ____________________ 37 5.5.3 Preparation of Training Schedule ________________________________________ 37

5.6 Knowledge Management ____________________________________________ 37

6 Monitoring & Evaluation __________________________________________ 38 6.1 Monitoring & Evaluation Framework ________________________________ 38

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

7 Assumptions & Risk Management ___________________________________ 43 7.1 Process for Risk Management _______________________________________ 43

8 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


3

8.5 Key considerations _________________________________________________ 51

9 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


1

Abbreviations & Acronyms

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 Ministry of Urban Development

NeGP National e-Governance Programme

NGOs Non Government Organizations

NMMP National Mission Mode Project

POP Point of Presence

PPP Public Private Partnership

RWAs Resident Welfare Association

SDC State Date Centre


2

Abbreviations & Acronyms Description

SeMT State e-Governance Mission Team

SIC 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


3

List of Tables

Table Number

Description

1 List of Identified eight Services

2 Project Funding Criteria

3 Total Project Cost

4 Population Details of State and ‘Selected’ ULB

5 Municipal Revenue & Expenditure for ‘Selected’ ULB

6 Services proposed through State Level Software Solution (SLSS)

7 Departments, Functions and Inter-Relation of ‘Selected’ ULB

8 Classification of ULBs

9 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


4

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)


5

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 nation-wide 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

1 Registration and Issue of Births/ Deaths Certificate

2 Payment of Property Tax, Utilities Bills and Management of Utilities that


6

S.No. Services/ Management Functions

come under the ULBs

2.1 Property Tax

2.2 Water Supply & Other Utilities

3 Grievances and Suggestions

4 Building Approvals

5 Procurement and Monitoring of Projects

5.1 e-Procurement

5.2 Project/ Ward works

6 Health Programs

6.1 Licenses

6.2 Solid Waste Management

7 Accounting System

8 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), e-Governance guidelines under JNNURM etc.


7

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.


8

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 ULB or para statal share / loan from

financial institution Central State

1 Cities/UA with 4 million plus population as per 2001 census

35% 15% 50%

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


9

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 :


10

State Implémentation Consultant (SIC)


State e-Governance Mission Team (SeMT)


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


11

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.

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

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

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.


12

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:

the

The following captures an analysis of these criteria for the stated objective:

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

• 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


13

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.


14

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.


15

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) Average Annual Growth Rate (%)

1 1981

2 1991

3 2001

4 2011(Projected)

Table 5: Municipal Revenue & Expenditure for ‘Selected’ ULB

S.No. Year Revenue ( Rs. Lakhs) Expenditure ( Rs. Lakhs)

Tax Non Tax State Transfers / Grants

1 2005-06

2 2006-07

3 2007-08

4 2008-09

5 2009-10

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.


16

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

S.No. Reform Areas Service Interface Function

Service Category

1 Registration and Issue of Births / Deaths Certificate

External G2C

2 Property Tax, Utility Bills and Management of Utilities that come under the ULBs e.g. Water Supply

External G2C

3 Grievances and Suggestions External G2C

4 Building Approvals External G2C, G2B

5 Procurement and Monitoring of Projects Internal / External

G2G

6 Health Program : Licenses, Solid Waste Management

External G2B / G2C

7 Accounting System Internal D2D

8 Personnel Information System Internal D2D

9 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 Associated Processes

Inter-relation


17

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 Bye-Laws

JNNURM Core Modules


2 Property Tax, Utility Bills and Management of Utilities that come under ULBs e.g. Water Supply




18

S.No. Details of the Services Municipal Acts Bye-Laws


6 Health Program: Licenses, Solid Waste Management

7 Accounting System


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.


19

Table 11: Proposed Service Level Benchmarks

S.No. Service Modules Service Level Benchmarks

IntermediaryService Level Benchmarks

(if any)

Timelines to achieve the

final Service Level

Benchmarks

JNNURM Core Modules


2 Property Tax, Utility Bills and Management of Utilities that come under the ULBs e.g. Water Supply




6 Health Program : Licenses, Solid Waste Management

7 Accounting System


Other Modules

9 (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.8 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.


20

Table 12: Benefits Perceived

S. No.

Services Delivery Channel

Time Taken

Efficiency / Functionality

User Charges (e-

Gov)

Cost of Service

Frequency of Visits

Benefits to Citizens

Benefits to ULBs

Corporation / Citizen Centers / Web enabled

Min/ Hrs / Days

% ( Internal/ External )

(Rs) (Rs) Number of visits

required

1 Birth Registration System

2 Payment of property Tax

3 Payment of Water Supply & Other Utilities

4 Grievances & Suggestions

5 Building Approval

6 e-Procurement

7 Monitoring of Projects / Ward Works

8 Licenses

9 Solid Waste Management

10 Accounting System



21

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#

Application Suites / Modules

Services Performe

d by Application Suite

Year of Implementation

Technology Platform

(Complete technology

stack including front end, back end,

middleware etc.)

Application

Architecture

No of Users, Transaction Volume per year & data

volume

Implemented At (State / ULB

Name)

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)

Re-usability (Yes/ No)

1


22

S.No.

Department / Location

List of Hardware, Network Infrastructure

(Existing)

Re-usability (Yes/ No)

2

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)


23

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, anti-

virus servers, intrusion detection systems etc. State should examine if the current security measures can be re-used for the proposed e-governance 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


24

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.


25

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

Technology Stack

Type & number of

Users

Transaction Volume p.a.

Data Volume

1 e.g. Birth & Death

Birth & Death registration

---- ULB users, and Citizens. Approx. Users = 1

50,000 (Approximately equal to the number of births / deaths

50 GB


26

million (equivalent to the population of the ULB)

reported in a year)

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 Entity / Data Set

Brief Description Owner System Key Attributes

1 e.g. Name Name of a citizen or an employee of the state / ULB

Birth & Death Module

First Name, Last Name, Father’s 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 Module / Application

Target Module / Application

Purpose Type of Interface

Data Set to be exchanged

Technology / Tool used

1 e.g Property Tax

Accounting Whenever someone pays tax, an entry of the same should be reflected in Accounts module

Batch (Run at the end of day )

Property details, amount, transaction details

None

4.2.4 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


27

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:


28

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:


29

• 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 Location 3 …. Location (n)

Total

Back-end (including database management tools used) Middle ware (including application software)


30

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


31

• 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 Conformance to Standards

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


32

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 multi-tenancy 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 ULB’s 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 ULB’s 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


33

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:


34

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

Training and Communication Needs

Training Strategy

Communication Strategy

1 SLNA • Define policies • Approval of

works/projects • Monitoring • Intervention • Strategic decision

making • Dual role in Change

Management Communication: Communication partners as well as audience

• Change Management Impact

• Shift in the Decision Making

• Response time • Customer

Orientation • Technical

Training

• Wear the hat of both Training Partner and Audience

• Long Term Training

• Technical and Behavioral training. clearly demarcated

• Communication of the policy changes, to

enable the working group to define and frame work plan • Partnership with the Change Management Communicators


35

S.No.

Stakeholder Roles and Responsibilities

Training and Communication Needs

Training Strategy

Communication Strategy

2 Employees • Perform duties in timely manner

• Interface with internal and external customers

• Participate in defining policies

• Responsiveness • Customer

Centricity • System and

Data Operations

• Skill and competency building through training programme

• Long Term Behavioral and Short Term Rigorous Technical Training

• Awareness creation and sensitization of change through communication

5.3 Organization Structure 5.3.1 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.


36

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.

SLNA

Process/ Functional

Team

Capacity Building Team

Technical Team

State Level Steering Committee (SLSC)

State e-Governance Mission Team (SeMT)

MoUD

Project Management Unit including State Implementation Consultant

Application Service Provider (Implementation & Roll Out)

Urban Local Bodies (ULB)

SLNA

Advisory


37

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.


38

6 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


39

Table 23: Objectives for Monitoring &Evaluation

6.1.2 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 Illustrative Responsibilities

State Level Steering Committee (SLSC)

• 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

State Level Nodal Agency (SLNA)

• 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

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

• 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


40

Role Illustrative Responsibilities

Project In-charge • 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

Technical Team

• 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

Change Management Team

• 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 In-

Charge

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


41

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 ‘Ex-Post 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 Variables/ Indicators

Input • Define M&E framework • Define monitoring plan and schedule

Process • 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

Output • Training of identified personnel • Opening of CFCs/ Kiosks/ Facilitation centers etc.

Outcome/ impact • Turn around Time


42

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 Timeframe

Monitoring project timelines

Monitoring quality

Monitoring capacity building


43

7 Assumptions & Risk Management

With the broad understanding of above sections, the section on Assumptions and Risk Management would cover the following:

• Risk Management Process

• Organization structure for risk management

• Benefits envisaged due to risk management

7.1 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 Examples Stakeholders Involved

Policy Decision

• Policy coordination • Central / State coordination and support unit • Adopting standardized guidelines defined at

National/ State level


44


Financial Risk • 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

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


Project Scope, Planning and Management

• Managing complexity level in the project • Incorrect Project scope identification • Requirements and Scope Definition • Project planning, monitoring and control • Cost and Time overrun

Financial Risk • Inappropriate Cost Estimates • Insufficient funds available

Environmental/ Regulatory Risks

• Administrative Risks • Improper or insufficient Legal and contractual

risks • agreement with the vendors, contractors etc. • Intellectual Property Rights • Data Privacy and Security

Technology Risk

• Improper integration with state infrastructure • Improper Software application rollout • Transactions not being auditable • Inadequate accuracy or precision in Output

levels • Obsolescence of technologies


45


• Unavailability of connectivity up to the lowest level

Stakeholders

• 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

• 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


Roll out and Integration

• Full scope not covered while performing quality testing

• Difficulty in integration with existing infrastructure


46


• Day to day operations and maintenance

Organizational factors

• Key members of the project moving out • Personnel and training issues - skill

shortage • Additional staff responsibilities alongside

project work

Data and information system

• Digitisation of legacy data • Ready availability and accessibility of data

and information • Data and information quality • Capacity to analyze data and utilize

information

Procurement Risks

• Contractual issues • Mismatch between the nature of task and

procurement process • Failure to deliver satisfactory results

Schedule/ Timeline/ Cost Overrun

• 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,


47

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

The description of the value obtained from the Risk Ranking chart is as mentioned below.

Table 31: Chart for Risk Ranking

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

Impact

Probability

Low -1 Medium -2 High -3

Low -1 (Score 1)

Low

(Score 2)

Low

(Score 3)

Medium

Medium -2 (Score 2)

Low

(Score 4)

Medium

(Score 6)

High

High -3 (Score 3)

Medium

(Score 6)

High

(Score 9)

High

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.


48

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

Model Guidelines for State Level DPR for implementation of e-Governance in ULBs under JNNURM Ministry of Urban Development

8 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 non-government 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:

• Lack of capital • Inadequate infrastructure • Technological complexities • Lack of capacity & resources

8.2 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, web-native 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,


50

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.


51

• 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 government’s 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.


52

(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


53

9 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

(i.e. Employees of the above government organizations)

• Job security, working conditions, minimum wages, etc

Facilitators

(i.e. training institutes, development partners, NGOs etc.)

• Capacity building, funding support, 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.


54

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

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


55

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.


56

Table 34: Sustainability and Key factors

S. No. Areas Description Key factors Action steps

1 Procedural Sustainability

2 Resource Sustainability

3 Financial Sustainability

4 Contractual Sustainability


57

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. Knowledge Management

11. Others (if any)

Total Capital Investment (A)

B. Operational Cost

11. Project Management

12. Capacity Building


58

S.No. Particulars



13. Network Connectivity

14. Licenses

15 AMC

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 Network Infrastructure

Components




Components

4. System Software

5. Application Software

6. GIS Components

7. STQC certification

8. Monitoring Tool

9. Help-Desk

10. Knowledge Management

11. Others (if any)

B. Operational Cost




59

S.No. Particulars

Year 0 (in Lacs)

Year 1 (in Lacs)

Year 2 (in Lacs)


14. Licenses

15 AMC

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





Components




Components

4. System Software

5. Customization of

Application Software

6. GIS Components

7. Others (if any)

Total Capital Cost (A)


60

S.No. Particulars



B. Operational Cost




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)



Components




Components

4. System Software

5. Customization of

Application Software

6. GIS Components

7. Others (if any)

Total Capital Cost (A)

B. Operational Cost


61

S.No. Particulars

Year 0 (in Lacs)

Year 1 (in Lacs)

Year 2 (in Lacs)




11. Licenses

12. AMC

13. Others (if any)


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 Other Sources of Funds (If

any)

Total (Rs. Lakhs) Amount

(Rs. Lakhs)

Amount

(Rs. Lakhs)

Amount

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


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?

2 How are the processes standardized across the State?

3 How has the BPR been done for the identified services under NMMP, JNNURM?

4 Provide Organizational structure details in the SLNA:

S. No.

Domain Expertise Existing Proposed by

(month-year)

Remarks/ Role

1 Information Technology

2 Process Champions

3 Capacity Building

4 Urban Planning

5 Monitoring & Evaluation

6 Any Other (please specify)

5 Interface with State Level Institutions:

S. No.

Component Existing Proposed by (month-year)

Remarks/ Role

1 State e-Governance

Mission Team (SeMT)

2 State Implementation

Consultant (SIC)

3 Any other (Pls specify)


63

(B) Technology:

1 Does that software application proposed support multi-tenancy for all the ULBs in the State?

2 Have Open Standards, and the other software standards described under the NeGP programme been applied in the software application?

3 Is the application proposed integrated with other State Mission Mode Projects like e-Procurement, SDC, SWAN, SSDG, State portal etc. and other internal functions?

4 Have exhaustive details regarding the software solution design been provided as part of the DPR submitted?

5 Is the Disaster Recovery site and processes identified?

6 Framework for common application across the state – following details are to be provided:

S. No.

Component Existing Proposed by (month-year)

Remarks

1 Project Management/

Implémentation Unit (PMU/ PIU)

2 System Integrator/ Application

Service Provider for

application(s) deployment

3 Common Application(s) (No. of

applications)

4 Common Server side hardware 5 Common Server side software

licenses

6 Any other (pls specify)

7 Features of Application:

S. No. Component Existing Proposed Remarks

1 STQC certified solution 2 Customized/ Bespoke

development

3 Platform / technology 4 Scaling up facility 5 Interoperability with other

applications

6 Integration with existing


64


State portals/ initiatives


8 Common Infrastructure of the State to be utilized by ULBs:

S. No. Component Usage Existing in the State/ Proposed to

be in place by (month/year)

Utilization mentioned in

DPR

1 State Wide Area Network (SWAN)

Vertical and Horizontal linkages for ULBs at District and Block level

2 State Data Centre (SDC)

Hosting of the centralized application(s) at SDC

3 State e-Procurement portal

Integration with state portal by ULBs

4 National Urban Information System (NUIS) scheme

For GIS components

5 State Portal Linkage of the all the ULBs with state portal

6 State Service Delivery Gateway (SSDG)

For service delivery

7 e-Forms For process standardization


2. Implementation Phase

1 Details to be provided for the following personal and process:

S. No. Component Existing Proposed by (month/year)

Remarks

1 Domain experts 2 IT skills personnel 3 e-Governance personnel 4 Personnel for interface with

ULBs


65

S. No. Component Existing Proposed by (month/year)

Remarks

5 Training need analysis

6 Training institutes identified

7 Process standardization


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?

2 Have the DPR consider PPP for all the service provisioning & delivery components (Application, IT infrastructure, Network, Delivery infrastructure)?

3 Have the service levels for PPP framework like Availability/ Accessibility/ Reliability been defined?

4 What are the engagement model, revenue model and service delivery model considered in the DPR?

5 Following details are to be provided for Public Private Partnership (PPP):


1 State Level PPP arrangements

2 PPP Service Provider 3 Engagement Model 4 Service Provisioning Model Service Delivery Model 5 Revenue Model 6 Contract Management 7 Operations & Maintenance

Arrangements

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


66

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)

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 user-ids 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 Details of Hospital details (Addition/Modification/Deletion/ Search). 4 Details of Registrar

(Addition/Modification/Deletion/ Search).

5 Details of maintaining Fees for Birth and Death (Addition/Modification/Deletion/ Search).

6 Details of Birth Delivery (Addition/Modification/Deletion/ Search).

7 Details of Birth application details (Addition/Modification/Deletion/ Search).

8 Details of Cause of Death (Addition/Modification/Deletion/Search). Birth Registration 9 Ability to add/modify/delete the Birth details 10 Ability to generate the Birth Registration Slip. 11 Ability to facilitate the inclusion of the Child’s Name, if not provided

during registration.

12 Ability to cancel the Registration details. 13 Ability to facilitate the capture the request for Birth certificate and

retrieve details of the applicant based on the Registration Number

S. No.

Requirement

Existing Module (Yes / No)



67

Death Registration 14 Ability to add/modify/delete Death details. 15 Ability to generate the Death Registration Slip. 16 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 Various reports information of Birth registrations based on Registration

No, Registration Date, Date of Birth, Issues , Non-Issues Month & Year –Wise

19 MIS for Actual time taken for issuing a Birth/ Death 20 MIS for total number of birth/ death certificates re-issued without

service charge

21 MIS for Accessibility/ Availability of facility centers 22 Reports births Sex Wise in a particular year 23 Reports on Father’s Literacy wise in a particular year 24 Reports on Father’s Occupation wise in a particular year 25 Reports on Mother’s Literacy wise in a particular year 26 Reports on Mother’s Occupation wise in a particular year 27 Reports on Year-Wise Issues 28 Various reports can be generated Year of Death-wise based on Date and

Cause of death

29 Reports of Deaths based on Occupation-wise in particular year 30 Reports of Deaths based on Sex-wise in particular year 31 Reports of Deaths based on Cause of death-wise in particular year 32 Reports of Deaths based on Issued and not issued between two specified

applied dates


68

2.1 Property Tax Module S. No.

Requirement Existing Module (Yes / No)





3 Entry of new records, modify existing records, delete existing records.

Inclusion of New Assessee 4 Entering/ adding the applicant details for new assessment. 5 Generation of a new assessment application acknowledgment receipt. 6 Facility of modifying/ deleting an existing record. 7 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 Facility of modifying/ deleting an existing record. 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 Calculation of Property Tax to be levied based on the building type,

area, usage details etc.

18 Change property tax computations and determine arrears/refunds etc. with proper controls/ authorization.

19 Facility of modifying/ deleting an existing record. 20 Enter/add the assessment details and property tax levied. 21 Enter/add the Arrear details and property tax levied for assessment.


69

S. No.



22 Generation of the details of Property Tax paid for the assessment. 23 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 (Addition/Modification/Search)

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


70

S. No.



• Penalty on Unauthorized Construction • Revenue Block wise Collection • Revenue Ward wise Collection • Revenue Zone wise Collection • Street wise Collection.

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

55 Certificates • Ownership Certificate • Valuation Certificate.

56 Other Notices • Final Notice • Warrant Notice.

57 Apartment Details, Complex Details, Group Housing Details, Row Housing Detail

58 Building Age wise Assessment List 59 Monthly List of Buildings Requiring Levy of PT or Revision of PT 60 Occupiers Notice Details 61 Occupiers Other Than Owners 62 Tax Section Circle No. (Property details by the owner)


71

2.2 Water Supply Module S. No.




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


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 the details for Closing/Holding/Reconnection

Applications.


72

S. 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 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 Bill Collector (Addition/Modification/Search) 37 Details of Application Type (Addition/Modification/Search) 38 Details of Connection Types (Addition/Modification/Search) 39 Details of Water Sources Types (Addition/Modification/Search) 40 Details of Usage Type (Addition/Modification/Search) 41 Details of Pipe Size Master(Addition/Modification/Search) 42 Details of Security Deposit Master (Addition/Modification/Search) 43 Details of Meter Cost (Addition/Modification/Search). 44 Details of Charges (Addition/Modification/Search) 45 Details of regularization penalty (Addition/Modification/Search) 46 Details of Enclosure document (Addition/Modification/Search) 47 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 (Addition/Modification/Search)

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 Acknowledgment for application 56 Intimation letter or proceedings for tap connection 57 Work order 58 Consumer register (All Water Tap Connections Details) 59 Disconnection Notice for unauthorized Connection 60 Disconnection Notice for existing Connection 61 List of Tap Connections Sanctioned in Specified Period 62 Demand Register 63 Arrear Demand Register (All Water Tap Connections Arrears list)


73

S. No.



64 Preprinted Demand Notice 65 Bill collector wise collected Water charges S. No.



66 Location wise collected Water charges 67 Zone wise collected Water charges 68 Arrear Details individual list 69 Report for all Water Tap connections DCB 70 Block wise DCB report. 71 Individual DCB report 72 Modification /Reconnection Details report 73 Assessment Register details


74

3.1 Public Grievances S. No.

Requirement Existing Module

(Yes / No)

Proposed Module

(Yes / No) User Authentication 1 First level of security



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

section.

Grievance Registration 10 Ability to accept applications, generate unique grievance id and

generate acknowledgement and verify status with the unique grievance id

11 Ability to allow section heads to allot the grievance to the concerned officer responsible and update the status of the registered grievance

12 Ability to update the status after each level of necessary action has been taken

13 Ability to verify the specified time limit of grievance Re-dressal and calculation of compensation to be paid to citizen as per time limit

14 Ability to integrate with other modules such as Property Tax, Water Tax using the unique Grievance ID.


75

S. No.


(Yes / No)

Proposed Module

(Yes / No)

MIS & Reports 15 A section wise grievance register is printed for a given period with its

status.

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

17 Grievance Disposal Register department wise 18 Grievance Status Summary 19 Action taken reports 20 Analytical reports for Performance evaluation as an ULB and

department wise.

21 Department wise SLA Parameters. 22 Status by source of complaint. 23 Department-wise compensation paid along with Response Time for

Grievance Resolution.

24 Survey report for Awareness levels among Citizens about the Grievance cell.

25 Grievances raised to public disclosure.


76

4. Building Plan Approval S. No.


(Yes / No)

Proposed Module



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

Building Plan Approval 1 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

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

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

4 Facilitate entering of the building application details such as applicant information, building information, licensed architect information, and the technical and fee details.

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

6 Facilitate checking and assessing the balance fee charges for an applicant and calculate the total amount to be paid.

7 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


77

S. No.


(Yes / No)

Proposed Module

(Yes / No)the scrutiny.

8 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 1 Enable to enter the required documents for layout permission. 2 Facilitate adding/updating the required mapping documents for layout

permission.

3 Facilitate entering of the layout application details such as applicant information, physical layout details, licensed architect, and the technical data and fee details.

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

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

6 Facilitate checking and assessing the balance fee charges for an applicant and calculate the total amount to be paid.

7 Generate application number for the applicant to be used by him for online tracking of his application’s status.

8 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


78

S. No.


(Yes / No)

Proposed Module

(Yes / No)• No. of Structural Compensation Paid • No. of Structural covered by Court Order

9 Facilitate entry of and maintenance of following data, at a minimum, on Road Widening

10 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


79

5. Procurement & Monitoring of Projects 5.1 e-Procurement (Works) S. No.


(Yes / No)

Proposed Module




Create Indent 1 Facilitates online creation of the works indent. 2 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 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).

2 Supports use of Digital Certificates for providing administrative approval and technical sanction online. Allows attaching of supporting documents with the online approval order.

3 Allow tracking of the indent throughout the creation and approval cycle using the unique indent number.

4 MIS: Support generation of reports on: Indents created, by type of work, value, region, etc. Indents approved, rejected, and reasons for the same.


80

S. No.


(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 e-

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


81

S. No.


(Yes / No)

Proposed Module

(Yes / No)6 Facilitates upload of drawings, technical specifications, contractor’s

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 Supports online access and viewing of bids by the Inviting Officer

on the scheduled date & time of bid opening.

2 Supports workflow for evaluation, and approvals (from competent authorities, tender committees, etc.).

3 Supports separate workflows for bid evaluation based on number and type of stages employed (Pre-Qualification, Technical, Commercial and Techno-commercial evaluation stages).

4 Facilitates system tracking of the evaluation process.

5 Generate compliance matrices and comparative charts of received bids to aid in evaluation by the Inviting Officer, and tender committee.

6 System allows evaluation & compilation of the common set of terms & conditions.

7 Record comments from all approvers at different stages of evaluation.

8 Support automatic evaluation of technical and price bids by the system using pre-specified criteria.

9 Support online viewing of tender opening event simultaneously by remote bidders (e.g. in the form of chat).

10 Facilitate viewing/downloading of bid evaluation results and bids of other qualified bidders, depending on the evaluation stage.

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

12 System recommends L1 for selection by default.

13 On rejection of a bid at any stage, system makes it mandatory for the competent authority to provide valid reason for the same.

14 Archiving of the entire tender proceedings as per the IT Act, 2000.

15 MIS: Support generation of reports on: Tenders floated by value, type of work, & region-wise, etc.

Dynamic Pricing (Auction)


82

S. No.


(Yes / No)

Proposed Module

(Yes / No) 1 Provides simplified menu based workflow to create online auction

by the Auction Administrator.

2 Allows users to be created and assigned different roles like that of Auction Administrator, Departmental Originator, Super-Originator, etc.

3 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

4 Facilitates proxy bidding for contractors, if decided by the department.

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

6 Supports multi variable bidding, assigning weights to different variables and use of formulae in an auction.

7 Supports dependent auctions i.e. it should open an auction only on the successful completion of the previous auction.

8 Allows department to assign weights to different contractors based on their past performance and quality in an auction.

9 Allows viewing of the lowest going price in real time, by the bidders.

10 Allows Inviting Officer to view history of items and price bids during the live auction and after with date and time stamp.

11 Disallows divulging the identity of the participating bidders on the system.

12 Supports display of images or multi-media content, URL, documents, and spreadsheets attachment with each auction item.

13 Provide option to the departmental administrator to auto-approve or manually approve the winner in the auction.

14 Support for parcel auctions. 15 Allow generation of MIS on types of auctions and results, contractor

participation, %savings in price, etc.

16 Allow department to send notifications and pop-up messages to participating bidders during the auction.

17 Show in real-time the time remaining for close of the auction up to the last second to both department administrator and participating bidders.

18 Provide a contractor administration module to add, delete, enable or disable the contractors or contractor group.


83

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 Provides template library for contracts with common set of terms

and conditions.

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

3 Facilitates digital signing of rate contract by the competent authority on the system, and issue of the same to the selected supplier.

4 Allows selected supplier to receive and acknowledge the electronic copy of RC on the system using his digital signature certificate.

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

6 System alerts the Stores in-charge and the contracted suppliers


84

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

2 Allows products to be identified (searched) by more than one specific identifier such as description, item code, etc.

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

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

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

6 Allows the department to construct and maintain menus (directory) for the catalogues/items on the system.

7 Allows flexible pricing on the system for an item. 8 Facilitate assignment of unique code to items and sub items. 9 Facility to control viewing of selected item catalogues based on the


85


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


86


(Yes / No)

Proposed Module

(Yes / No)2 System should consolidate POs based on the parameters specified

by a department.

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

4 Allow editing/cancellation by the purchaser/purchasing department of the system generated PO before release.

5 System should provide for entering comments/reasons. 6 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.

7 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

8 Support electronic confirmation from the supplier upon receipt of the online PO, using his DSC.

9 Automated email alerts to facilitate the creation and approval workflow in the organization.

10 Allow suppliers to maintain user accounts on the portal. All alerts, documents etc. are posted and/or mailed to these accounts.

11 Maintain record of all POs released supplier wise for the generation of the draw reports to be used for demand estimation for future procurement.

12 Allow entering of QA request for the third part QA agency. 13 Allow the QA agency to post the QA inspection results on the

system. System should alert the supplier, PO owner of the posting.

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

15 Allow purchaser to issue and update the GRN on the system. 16 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.

17 Allow settlement of payment after three way matching (Bill, PO, goods receipt note) either on the system or on the department’s internal financial system.

18 Allow integration with payment gateways.


87


(Yes / No)

Proposed Module

(Yes / No)19 Support Purchasing Card (P-Card) functionality. 20 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 Facilitates Department to configure/develop reports on different

parameters for trend analysis, reports on contractor participation etc.

2 Provides the option for reports to be saved and printed in different formats e.g. excel, word etc.

3 Common instrument numbering system for the State (Unique procurement instrument identifier), if decided.

4 Facility to conduct opinion polls from contractors/suppliers, departmental users, in order to improve the functionality/services of the e-Procurement solution.

5 Help section for the contractors/suppliers and departmental users. FAQ section to be built and continually updated with recent learning’s.

6 Sections providing policy documents of department, terms of use, rules of tendering, feedback, queries, etc. should be provided on the site.

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

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


88


(Yes / No)

Proposed Module

(Yes / No)2 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.

3 The work flows should be flexible and configurable based on: • The product category • Spending limits • Approval limits • Intra department relationships • Inter department relationships

4 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 corrigendum’s

5 Dynamic workflows should be facilitated where the creator/approver can select the next approver/reviewer.

6 Supports event based alerts to the authorities during the creation and approval process.

7 Supports configuration of roles such as the system administrator, super user for the departments.

8 Supports the diverse requirements of multiple departments. 9 Supports time stamping of all workflow steps such as creation,

submission, approval, rejections, etc.

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

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.


89

5.2 Project Ward Work S. No.



1 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

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

3 Allow integration with the Project Accounting module in order to facilitate tracking previous payments/advances released to a contractor, cost overruns, etc.

4 Allow initiation of online measurement book. Enable contractor’s 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.

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

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

7 Facilitate login of concerned departmental officials for the purpose of entering project related information and for providing approvals at various stages.

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

9 Capture information on project analytics, such as percent of work completed against time elapsed, corresponding payments made, work extensions, delays, etc.

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

11 Support automatic generation of the bill based on verified MB entries, and other contract agreement terms and conditions.

12 Track project delays on the part of the contractor. Apply penalty clauses at the time of preparation of the bill.

13 Maintain all reports/audit trails as required for the AG’s audit purpose. Compliance with relevant provisions of the Works Manual,


90

S. No.



Account Code, Finance Code, and appropriate statute, etc. 14 Allow entry of third party verification information on project

progress, quality control in the system

15 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

16 MIS: Support generation of reports on: • 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.


91

6. Health Module: S. No.






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 Existing

Module (Yes / No)


1 Facility for addition and updating of the ULBs information in the ULB Master

2 Facility for addition and updating the sanitary zone/division information in the Sanitary Zones/wards/Division Master

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

4 Facility for addition and updating the Election Wards Information 5 Facility for addition and updating the Locality categories 6 Facility for addition and updating the sanitary ones/ward/division

allocation to Sanitary Inspectors

7 Facility for addition and updating: • Trade categories • Sub-trade categories.

8 Facility for configurations of the following: • Late fee details for the corresponding time periods in the

penalty fee master • Trade rates • Revenue Block Categorizations.


92

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


9 Facilitate the recording of the details of an applicant for a new trade license.

10 Facilitate the preparation of the inspection report for recording the findings of the field inspection of the applicant’s premises. Facility for SI/HO to provide his comments.

11 Facilitate recording the NOC/Installation Permission Details, which will be later used for checking while issuing the License to Industry/ Factory.

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

13 Facilitate the capturing of the license fee/late fee details (Cheque/ DD details, etc.)

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

15 Facilitate recording the application details from the application form submitted by the applicant.

16 Facilitate recording of the trade License renewal details. 17 Facilitate recording of the Panchanama details collected from the

sanitary inspectors report.

18 Facilitate generation of the list of defaulters who haven’t paid their renewal fee. Facilitate generation of the list of license holders who wish to close their trades on their own.

19 Updation of the status of a trade license as ‘active’ or ‘closed’, and the reasons for closure are entered.

20 Facilitate recording of the details from the application submitted by the applicant for change of Title

21 Facilitate generation of license with changed title, after the necessary supporting documents, fee, and approvals are entered in the system.

22 Facilitate capturing of details of the un-assessed trades, i.e., individuals performing trade without a proper trade license

23 Track the renewal notices sent to the license holders to renew their License. Further, track response dates, late fee applicability, etc

24 Facilitate capturing of grievances against a license, or in general. 25 Facilitate generation of demand collection and balances revenue

ward-wise for the ULB.

6.2 Solid Waste Management S. No.




93

1 Facility for addition of the new division details to the Division Master.

2 Facility for entering location details under particular division of the Municipality.

3 Facility for entering various data on public toilets of the Municipality to be entered into the Public Toilets Master.

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

5 Facility for entering details of the garbage-collection place such as the garbage collection place type, name, and fees collection location.

6 Facility for entering coordinates of dustbins located at various locations within the Municipality.

7 Facility for entering different types of vehicles available to be entered into Vehicle Type Master.

8 Facility for entering details of the Hospitals/Hotels/Lodges located in the Municipality.

9 Facility for entering the details of the transmission station. 10 Facility for entering the details of the dumping ground to be entered

in the system.

11 Facility for the Sanitary Inspector to enter the attendance of the employees in the system.

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

13 Generation of tentative allocation of workers to locations based on historical garbage collection patterns.

14 Facility for recording of the garbage volumes from different locations dumped at the dumping grounds.

15 Generation of tentative allocation of vehicles to locations and routes based on historical garbage collection patterns and the optimal routing.


94

7. Accounting Module S. No. Requirement Existing

Module Proposed Module

(Yes / No) (Yes / No) User Authentication 1 First level of security



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 ULB’s.

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 Facility for maintenance of master database of all suppliers,

contractors and vendors.

7 Facility for calculation of Sales Tax, Tax Deducted at Source etc.

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

9 Allow add and modify invoices, credit and debit memos, pre-


95


Proposed Module

(Yes / No) (Yes / No) payments, holds, invoice notices etc.

10 Allow disbursement of payments(salary, contractors/suppliers, administrative expenses, PF, profession tax, etc)

11 Employee database and calculation of salary and statutory (PF, PT, etc) payments for each employee

12 Entry of the consolidated salary and Statutory (PF, PT etc.) payment amounts for each department in the accounting

13 Some of the Reports required are • 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 Some of the Reports required are

• Final receivable register • Revenue trend analysis statement • Ageing Reports for both debtor and creditor, (Ageing

report should be user defined)

Fixed Assets 19 Accounting System should be able to maintain the Fixed

Asset Register.

20 Allow query asset based on asset number. 21 Allow add/update certain details like description or category,

change an asset’s location, responsible employee, Manufacturer, Model, Warranty details.

22 Facility to calculate the Depreciation of Assets, based on different formulae for example straight line method etc.

23 Allow mass addition transfer, mass depreciation, revaluation, retirement of assets

24 Update information from fixed asset module to general


96


Proposed Module

(Yes / No) (Yes / No) ledger module

25 Some of the Reports required are • 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 Provision for budgeting 27 Facility for display warning messages in case the budgetary limits

are exceeded

28 Support analysis 29 Some of the Reports required are

• Budget approved report • Budget trend analysis • Variance Analysis of Budget Vs Actual

Financial Statements 30 • 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

31 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


97

8. Personal Information System: Sr. No.


Proposed Module

(Yes / No) (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 user-ids and passwords..


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 Ability to “encumber” (reserve) a position that is not currently filled 7 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.

8 Ability to update salary amounts for each classification and scale/bracket.

9 Ability to automatically calculate and transfer salary when an employee transfers to a different Department/division, as authorized, even mid-pay period.

10 Ability to assign multiple employees to a single position (job sharing).

11 Ability to assign a single employee to multiple positions. 12 Ability to track filled and vacant positions by position number. 13 Ability to plan Shifts and Schedule manpower accordingly. 14 Ability to administer multiple shift schedules. 15 Ability to identify shift plans for Departments and work crews based

on actual or forecasted workload.

16 Ability to identify requirements by type of job or specific


98

Sr. No.


Proposed Module

(Yes / No) (Yes / No) qualifications.

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


99

Sr. No.


Proposed Module

Integration and Interface 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.


100

Sr. No.


Proposed Module

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

32 Ability to provide a summary of the applicants that have been hired against the job requisition.

33 System acceptance of electronic applications (e-mail, Intranet, Internet, electronic forms) including optical scanning to enter resumes and convert into data for further references.

34 Ability to enable applicants to learn about and apply for multiple jobs.

35 Ability to track the number and types of positions for which an applicant applies.

36 Ability to compare requirements of a vacant position with an applicant’s existing skills to determine necessary training and overall fit.

37 Maintenance of different types of tests and associated questionnaire.

38 Ability to generate questionnaire based on competencies defined for a job.

39 Ability to record and maintain proper information for cases of applications on compassionate grounds.

40 Ability to maintain complete employee information, historical and current. Especially in the area of maintaining images (photos, CV’s, appraisals, etc.).

41 Ability to resurrect an expired employment list if required. 42 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.

43 Ability to track progress of a candidate in any step of the recruitment process.

44 Ability to maintain history of interviewed but not selected candidates.


101

Sr. No.


Proposed Module

Interviewing 45 System possesses efficient tools like a Scheduler/ Calendar 46 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 Ability to position specific KRAs and targets 56 Ability to use a variety of appraisal models as templates to support

appraisal process.

57 Enable users to define rating codes to assist in rating an employee’s performance. These codes may be alphanumeric.

58 Facility to allow users defines a rating model and the associated rating scales and weights of relevant employee skills or competencies.


102

Sr. No.


Proposed Module

59 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 Ability to assign benefit plan codes by employee based on their classification (to identify level of benefits for which each employee qualifies)

77 System to allow the entry of pre requisites needed. 78 System to have the ability to define plan status. 79 Ability to track employee’s coverage and coverage level based on


103

Sr. No.


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 Allow the DMA/ULBs to define eligibility rules for admission to

GPF for employees.

82 Allow the DMA/ULBs to: • Process GPF balance • Process GPF temporary advance • Modifying GPF subscription.

Travel Management 83 Ability to interface with knowledge database to access information

relating to Government Orders and checklists for the processing of leave travel concessions (LTC’s) for employees.

84 Ability to enter travel data by respective employee with prior approval by respective approver, either before or after the trip.

85 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 Ability to calculate payments based on employee compensation

rules, and employment contract.

87 Ability to calculate different type of pays. For example basic, allowances, bonus etc.

88 Ability to define pay type. For example hourly/daily/weekly/monthly etc.

89 Ability to define different pay elements. Pay elements could be


104

Sr. No.


Proposed Module

fixed value or calculation based on other pay elements 90 Ability to group employees by Department in any manner without

having to set up multiple employee records for each Department.

91 Ability to maintain an integrated security design to ensure that employees don’t get paid twice in one payroll period without authorization.

92 Ability to make automatic calculations for flexible benefits. 93 Ability to view Employee costs per Department/division and costs

per job, position.

94 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 employee’s prepaid deduction balance if the employee’s normal pay is not sufficient to cover the deduction

95 Ability to make automatic calculation of mid-pay period changes to pay, benefits, deductions, and taxes.

96 Ability to generate monthly pay-slips for the employees, for at least last 6 months.

97 Ability to pay an employee from more than one Department and split salary and benefits among Departments, including retirement benefits.

98 Ability to process payroll on the following frequencies: • Biweekly, • Monthly • Semi-monthly, • Bi-monthly, • On-demand (i.e., terminations, vacation advance, court order,

ratification.).

99 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,


105

Sr. No.


Proposed Module

• Others (user defined). 100 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).


106

Sr. No.


Proposed Module

101 Allow different account codes and cost centers for different employee types can be defined for the same salary code.

102 Ability to allow use of an earning or deduction code to calculate another earning or deduction code as part of formula calculations.

103 Payroll database should be automatically updated when changes are made to the employee record database

104 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).

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

106 Ability to enter attendance information: • Online, interactive by employee, • Batch, • Multiple data entry capability including card readers, bar

coding, etc.

107 Ability to account for time based on type of absence or attendance. 108 Ability to submit corrections. 109 Ability to request cancels or modifies requests time off, and receive

approval or denial from immediate supervisor.

110 Ability to monitor attendance records on a daily, weekly, and biweekly basis.

111 Ability to pay all types of reimbursements through payroll. (Medical etc.)

112 Ability to track and maintain work schedules by position, classification, and/or employee.

113 Ability to track actual hours worked by work schedule by position, classification, and/or employee.


107

Sr. No.


Proposed Module

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

115 Ability to automatically update payroll database when Finance Department makes pay rate changes.

116 Ability to handle salary advances & facilitate recovery of salary advances on the payday.

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

118 Ability to get reports on payroll for comparisons. For example Year-to-date and Last year-to-date, this month and last year-same-month etc.

119 Ability to update master salary scales during wage/ salary revisions. 120 Ability to pay a rate greater than a specific rate based on a

percentage entered as a bonus rate in the employee’s database.


108

Sr. No.


Proposed Module

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

122 Ability to cash out accumulated leave balances by user defined formulas and criteria.

123 Ability to have payroll adjustments reflected in correct pay period. 124 Ability to have an established base pay regardless of hours worked. 125 Ability to have different hourly rates for an employee for different

days within the same payroll period

126 Ability to allow for pre-calculation of payroll outside of the normal payroll system.

127 Ability to re-calculate payroll for changed hours, etc. 128 Ability to make one time payment. For example for people working

on a specialized program, Employee of the month/ year reward etc.

129 Ability to provide for online ad-hoc calculation of employees pay check amount.

130 Ability to support separate tax tables for special pay calculations (flat tax).

131 Ability to perform online calculation of pay and benefits for terminated employee based upon termination date.

132 Ability to report all changes to employee’s pay, deductions, taxes, etc.

133 Ability to report tax payments by employee. 134 Ability to change tax filing status and number of exemptions of a

particular employee.

135 Ability to report retirement deductions by employee. 136 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.

137 Ability to calculate different types of bonus. E.g. performance bonus etc.

138 Ability to calculate bonus outside the system. 139 Facility to import and update as pay element for employees 140 Ability to add or update bank information for direct deposit and

expense reimbursement.

141 Ability of system to calculate bonus based on appraisals, grades and days on work in a year.

142 Any updation of records, pay elements should be with a reason code.

143 Ability to produce benefit eligibility lists upon request for employees.

144 Ability to request downloads of payroll information to begin budget preparation by Finance Department.

145 Ability to provide for payroll reconciliation facilities. For example provide reconciliation between the following: • Differences in salaries of existing employees from previous


109

Sr. No.


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 Ability to calculate fixed monthly payments/deductions (FPD).

FPD’s may be amount or formula

152 Amount-based FPD is paid/ deducted directly from employee payrolls.

153 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). VPD’s

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.


110

Sr. No.


Proposed Module

Suspension Functions 157 Ability to provide suspension functions in the Payroll system. 158 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 staff’s 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.


111

Sr. No.


Proposed Module

170 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 Ability to automatically generate the Employee ID, personal data in

a sequentially order.

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

176 Ability to change users’ indicative data such as name, address, contact information, beneficiaries, etc

177 Ability to track and maintain personnel action changes for each employee.

178 Ability to track employee language abilities by language, level of proficiency.

179 Ability to track transactions based on the transaction date 180 Ability to notify via e-mail when action is required regarding

employees (e.g., personnel changes, evaluation dates, etc.)

181 Ability to transfer an employee to a different Department or payroll unit without reentering the entire employee file.


112

Sr. No.


Proposed Module

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


113

Sr. No.


Proposed Module

Employment Contracts 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.


114

Sr. No.


Proposed Module

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

203 Ability to keep track of holidays and to define weekly holidays and other holidays.

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

205 Ability to track leave used “in lieu” of sick leave. 206 Ability to set a trigger files for notification for expiration of a type

of leave status (e.g. expiration of a temporary position, etc.).

207 Ability to trigger required supporting documentation based on use of leave (e.g. doctor’s notes, etc.).


115

Sr. No.


Proposed Module

208 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 Allow for supervisor to view employee’s leave schedule and allow

for tracking of staff working on shifts. The system shall also allow for the creation of leave charts.

226 Integrated to on-line Employee Attendance System


116

Sr. No.


Proposed Module

Employee Relationship Management - Disciplinary Actions 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 Ability to accrue or charge interest either through a loan account or

through a designated account.

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

234 Ability to recover loans on the salary day. 235 System to provide for tiered interest rate facility. 236 Ability to defer installment and recalculate installment values after

deferment.

237 Ability to project loan commitment of a Department. 238 Facilitate holding of different types of loans by a single employee.


117

Sr. No.


Proposed Module

Management of Employees Qualifications - Qualifications Management 239 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.

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

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

242 Ability to identify qualifications such as memberships/licenses that may expire and require renewal, and track expiration dates.

243 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

244 Ability to match an individual’s 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

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


118

11.3 Annexure 3- Risk Log

Project : Date of Log:

Prepared by: Validated by : Date:

Basic Risk Information Risk Assessment and Mitigation Information Risk Response Information

Risk Number

Risk Description

Responsibility Date Reported

Day/ Month/ Year

Last reviewed

Day/ Month/ Year

Impact

H/ M /L

Impact Description

Mitigation Strategy

Timelines

Day/ Month/ Year

Completed Actions

Planned future Action

Day/ Month/ Year

Risk Status

<<Provider a unique identifier for the Risk>>

<<What is the risk about?>>

<<Name of the Team member/ stakeholder responsible for taking action>>

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

<<Enter the timelines for mitigating the risk>>

<<List of all actions taken to respond to risk>>

<<List by date what actions will be taken to respond to risk in future>>

a) Open b)No Plan (NP) c)Plan enacted (PE) d)Plan Effective e)Closed

Model DPR Guidelines

Documents

Transcript of Model DPR Guidelines