U.S. Department of Justice

Office of Community Oriented Policing Services

Tech Guide

How to plan, purchase and manage technology (successfully!)

A Guide for Executives, Managers and Technologists

LAW ENFORCEMENT
Copyright © 2002 by SEARCH Group, Incorporated. The U.S. Department of Justice reserves a

royalty-free, nonexclusive and irrevocable license to reproduce, publish or otherwise use, and to

authorize others to use, this book for Federal Government purposes. No part of this book may be

reproduced in any form, by any means (including electronic, photocopying, recording or otherwise) without the prior permission of the U.S. Department of Justice or the authors.
Law Enforcement Tech Guide

How to plan, purchase and manage technology (successfully!)

A Guide for Executives, Managers and Technologists

U.S. Department of Justice

Office of Community Oriented Policing Services

By Kelly J. Harris and William H. Romesburg

This publication was supported through cooperative agreement number 2001-CK-WX-K064 from

the U.S. Department of Justice, Office of Community Oriented Policing Services, awarded to

SEARCH Group, Incorporated, 7311 Greenhaven Drive, Suite 145, Sacramento, CA 95831. Contents of this publication do not necessarily reflect the official position or policies of the U.S. Department of Justice.
August 2002

Dear Colleague,

Technology has long been a two-edged sword for law enforcement. While the benefits of implementing technology are obvious, the obstacles to getting the most from that technology often are not. In a

time when growing responsibilities greatly increase the duties of local law enforcement agencies, a

natural response is to turn to technology as a force multiplier. The COPS Office presents this guide in

an effort to make the process of fully leveraging new technologies as seamless as possible.

Technology can help law enforcement agencies better serve their communities by automating timeconsuming tasks, dispatching personnel more efficiently, and improving an agency’s ability to collect

and analyze data as well as disseminate it to both internal and external audiences.

Implementing technology can be a long and difficult process. Before new technology can be implemented, the organization’s needs must be determined, its relevant business processes analyzed, and

its full range of options evaluated. Many law enforcement agencies have difficulty dedicating personnel, expertise, and funds for such a project. COPS grants help support agencies in their efforts to

embrace new technologies.

This guide is designed to help law enforcement agencies implement new technologies. It contains

step-by-step analyses of the technology planning, acquisition, implementation, and integration

processes that focus clearly on supporting public safety and community policing objectives.

This guide is designed to help you reduce crime and disorder through the successful utilization of

information technology. I wish you the best of luck in harnessing technology to better serve your

communities. Now more than ever, community policing keeps America safe.

Sincerely,

Carl R. Peed

Director

Office of the Director

U.S. Department of Justice

Office of Community Oriented Policing Services

Washington, D.C. 20530
vii

Acknowledgments .................................................................. xii

About the Guide ....................................................................... 3

Assumptions...About You ........................................................ 4

Assumptions...About Your Project ........................................... 4

How this Guide is Organized ................................................... 5

Definition of Icons ................................................................... 6

Where to Go from Here ........................................................... 7

Law Enforcement IT Projects: A Roadmap to the Guide .......... 8

Seven Facts You Should Know BEFORE

 Reading this Guide .............................................................. 11

Chapter 1

Establish a Decisionmaking Structure ................................... ................................... 23

Step 1: Identify an Executive Sponsor .................................... 24

Step 2: Identify Stakeholders ................................................. 24

Step 3: Create a Project Decisionmaking Structure ................ 25

Step 4: Involve Other Subject Matter Experts in

 Committee Deliberations .................................................... 34

Step 5: Make the Most of Committees: Conduct

 Effective Meetings................................................................ 35

Step 6: Make Determinations about Staffing In-house

 or Outsourcing Project Staff Support .................................. 37

Chapter 2

Hire, Assign and/or Train a Project Manager Hire, Assign and/or Train a Project Manager........................ ........................ 43

Sample Project Manager Job Description .............................. 44

Project Manager’s Responsibilities ......................................... 46

Contents

About the Guide

Seven Facts You Should

Know BEFORE Reading this

Guide

Part I:

Build the Foundation
viii

Project Manager Tool Kit ....................................................... 47

Executive Sponsors: Make the Most of Your

 Project Manager .................................................................. 47

Chapter 3

Develop a Project Charter Develop a Project Charter ...................................................... ...................................................... 51

A 12-Step Program for Developing the Charter ..................... 52

Step 1: Write the Vision Statement ........................................ 52

Step 2: Give the Project a Name ............................................. 53

Step 3: Get the Big Picture, Conduct an

 Environmental Scan ............................................................ 53

Step 4: Build the Business Case .............................................. 56

Step 5: Include Background or Historical Information,

 if Relevant ............................................................................ 58

Step 6: Establish the Project Scope ......................................... 58

Step 7: Establish Preliminary Project Objectives .................... 59

Step 8: Note Major Project Assumptions and Constraints ..... 59

Step 9: Develop Initial Timelines and Preliminary Budget .... 59

Step 10: Include Project Planning Methodology .................... 60

Step 11: Provide Project Team Organizational Chart and

 Membership Roster ............................................................. 60

Step 12: Sign, Seal and Deliver ... ........................................... 60

Part I Assignments Part I Assignments ................................................................. ................................................................. 61

Chapter 4

Assess Current Business Processes Assess Current Business Processes......................................... ......................................... 67

Define the Organization’s Business Processes ........................ 68

Define the Current Technology Environment ........................ 72

Define How Technology is Used to Accomplish Business

 Processes .............................................................................. 73

Find Room for Improvement ................................................. 74

Chapter 5

Determine Stakeholder and User Needs Determine Stakeholder and User Needs ................................ ................................ 79

Individual Interview Techniques ............................................ 81

Focus Group Techniques ........................................................ 82

Part II:

Conduct a

Needs Analysis
ix

Chapter 6

Develop General System Requirements Develop General System Requirements................................. ................................. 91

Compile the Requirements ..................................................... 91

Define General Hardware Requirements ............................... 93

Define General Software Requirements ................................. 94

Define General Interface and Integration Requirements ....... 96

Create a Conceptual Design Illustration ................................. 97

Chapter 7

Make the Decision — Build or Buy ...................................... ...................................... 103

Project Cost Considerations ................................................. 104

Managing Technology Resources ......................................... 106

The Decision ........................................................................ 107

Part II Assignments Part II Assignments.............................................................. .............................................................. 108

Chapter 8

Project Planning: What is it and Why are We Doing it? ...... 115

Five Important Facts to Know about Project Plans ............... 116

Executive Sponsors: Prepare Your Organization

 for Change ......................................................................... 117

Chapter 9

Conduct Scope Planning ...................................................... ...................................................... 121

1. The Scope Statement: What’s In, What’s Out .................. 122

2. Project Objectives: Measures for Success ......................... 124

3. Scope Management Plan: Prevent ‘Scope Creep’ .............. 125

Chapter 10

Develop the Project Timeline............................................... ............................................... 129

How to Develop an Estimated Project Schedule ................... 129

Determine Project Activities and Their Order ...................... 130

Estimate How Long the Activities will Take .......................... 130

Draft a Project Schedule and Seek Input .............................. 132

Create a Schedule Management Plan ................................... 132

Post It! .................................................................................. 134

Part III:

Create a Project Plan
x

Chapter 11

Estimate Costs and Develop a Budget Estimate Costs and Develop a Budget .................................. .................................. 137

The Project Budget ............................................................... 138

Gather Internal and External Cost Data ............................... 139

Create a Project Budget of Initial Costs ................................ 142

Estimate Recurring Costs and Include in Budget ................. 144

Plan for Ongoing Updates to Project Budget ........................ 145

Final Advice .......................................................................... 145

Chapter 12

Create a Risk Management Plan .......................................... .......................................... 149

How to Create a Risk Management Plan .............................. 150

Maintaining the Plan ........................................................... 155

Risk Management Plan: Essential and Indispensable .......... 155

Chapter 13

Prepare a Comprehensive Communications Plan ................ ................ 159

Keep the Right People Informed .......................................... 159

Get Input and Feedback ....................................................... 162

Establish a Paper Trail: Create the Project Filing Cabinet ..... 162

The Project Web Site ............................................................ 163

Part III Assignments Part III Assignments ............................................................ ............................................................ 165

Chapter 14

The Art of Procurement The Art of Procurement ....................................................... ....................................................... 173

Step 1: Research Your Jurisdiction’s Procurement

 Requirements .................................................................... 174

Step 2: Form an Evaluation Team ......................................... 175

Step 3: Select a Procurement Tool ........................................ 175

Step 4: Develop Functional Specifications ........................... 179

Step 5: Create Evaluation and Selection Criteria .................. 181

Step 6: Evaluate Bid Responses and Select a Finalist ............ 182

Chapter 15

Create the Contract Create the Contract .............................................................. .............................................................. 187

Understanding the Process .................................................. 188

Crafting the Contract Documents ........................................ 188

Components of a Contract ................................................... 189

Part IV:

Acquire the

Technology
xi

Tips for Negotiating a Solid Contract ................................... 198

Part IV Assignments Part IV Assignments ............................................................ ............................................................ 200

Chapter 16

Prepare an Implementation Plan ......................................... ......................................... 207

Creating the Implementation Plan ....................................... 207

What to Put in the Plan ........................................................ 208

Yet Another Plan to Maintain .............................................. 209

Chapter 17

Develop and Use Quality Assurance Tests Develop and Use Quality Assurance Tests ........................... ........................... 213

Quality Assurances and Testing ........................................... 213

How to Prepare a Test .......................................................... 215

Sample Test Language .......................................................... 215

Use Test Results to Evaluate Vendor

 and Product Performance .................................................. 220

Part V Assignments Part V Assignments.............................................................. .............................................................. 221

Chapter 18

Ensure the Success of Your Technology Initiative: Ensure the Success of Your Technology Initiative:

 Ongoing Tasks Ongoing Tasks................................................................... ................................................................... 229

Project Closeout Tasks .......................................................... 230

Checklist of Recurring Tasks ................................................ 231

Chapter 19

Grant Management and Compliance................................... ................................... 235

Manage Your Grant .............................................................. 236

Top 5 Grant-related Blunders ............................................... 238

Who Can Help? .................................................................... 239

Part VI Assignments Part VI Assignments ............................................................ ............................................................ 240

Appendix 1

Information Technology Descriptions Information Technology Descriptions................................. ................................. 247

Appendix 2

Glossary ............................................................................... ............................................................................... 263

Appendix 3

Bibliography of Resources Bibliography of Resources.................................................... .................................................... 275

Part V:

Implement the

Technology

Part VI:

Maintain the

Technology

Appendices
xii

Acknowledgments

This publication was prepared by SEARCH, The National Consortium for Justice

Information and Statistics, Gerald E. Wethington, Chair, and Gary R. Cooper, Executive

Director. The project director was David J. Roberts, Deputy Executive Director. Kelly J.

Harris, Director, Justice Information Technology (IT) Services, and William H.

Romesburg, Consultant, wrote this publication. Twyla R. Cunningham, Manager,

Corporate Communications, and Juliet S. Farmer, Writer/Researcher, edited this

publication. Jane L. Bassett, Publishing Specialist, and Mark Navarro, Webmaster,

provided layout and design assistance. The Federal project monitor was Nancy Leach,

Social Science Analyst, Program/Policy Support and Evaluation Division, U.S. Department of Justice (DOJ), Office of Community Oriented Policing Services (COPS).

This publication is copyrighted and may not be reproduced in whole or in part without

prior permission of the U.S. DOJ or the authors. In accordance with accepted publishing

standards, the COPS Office and the authors request that proper acknowledgment

accompany any such use.

Suggested Citation

Harris, Kelly J., and Romesburg, William H. Law Enforcement Tech Guide: How to plan,

purchase and manage technology (successfully!), A Guide for Executives, Managers and

Technologists, Washington, DC: U.S. Department of Justice, Office of Community

Oriented Policing Services, 2002.

About Us

SEARCH, The National Consortium for Justice Information and Statistics, is a nonprofit

organization of the States dedicated to improving the criminal justice system and the

quality of justice through better information management, the effective application of

information and identification technology, and responsible law and policy.

We serve the Nation’s justice agencies — police and sheriffs’ departments, courts,

prosecution and public defense, juvenile justice, corrections/jails, probation/parole and

criminal history record repositories — through a broad array of activities, resources and

products. Our focus is on criminal history systems, integrated justice information

systems, information technology (planning, purchasing, managing) and cybercrime

investigation. Our services include in-house and onsite technical assistance and training,

resource development (Websites, publications, white papers, conferences, workshops),

public policy assistance and model development (model legislation, standards and

procedures, best practices) in these focus areas. SEARCH online resources provide

information on law enforcement IT, integrated justice, justice software solutions and IT

acquisition at www.search.org.
xiii

About the Authors

Kelly J. Harris Kelly J. Harris is Director of Justice IT Services for SEARCH, where she develops and Kelly J. Harris

directs activities and manages staff under three programs: the National Technical

Assistance Program, the National Clearinghouse for Criminal Justice Information

Systems, and the Community Oriented Policing Services Making Officer Redeployment

Effective (COPS MORE) Technical Assistance program, all funded by bureaus and

agencies of the U.S. DOJ. Kelly has organized numerous national symposia on justice

integration, conferences on justice, e-government and the Internet, and workshops on

justice IT issues. She also has written many articles, technical bulletins and reports for

publication by SEARCH or the U.S. DOJ on justice system automation and integration.

Kelly has a bachelor’s degree in Political Science and Communications from the University of California, Davis.

William H. Romesburg is a SEARCH Consultant, as well as a Public Safety Consultant for William H. Romesburg

Cit Com. Inc., where he manages programs to ensure that planned and developed

methods and procedures are in place for successful implementations of public safety

technology. Bill has served as consultant to dozens of law enforcement agencies throughout the United States on public safety and automation projects, including agencies in

Alaska, California, Texas and Ohio. He has also held several law enforcement positions,

including police and fire dispatcher for 3 years and sworn police officer for 6 years. Bill

has a master’s degree in Public Administration from California State University, Fullerton, and earned a Level 2 certification from the Project Management Institute.

During 2001, Kelly and Bill presented a series of five national technical assistance

workshops on “Law Enforcement Technology IT Planning and Implementation” to the

COPS MORE Top 100 grantees (those grantees with the largest dollar amount in grants

and, therefore, the most full-time officers to redeploy). The regional workshops, funded

by a COPS Office grant, provided tools and resources to help those agencies overcome

obstacles to technology implementation. Kelly’s and Bill’s efforts focused on mobile

computing issues and technologies, as well as computer-aided dispatch and records

management systems (CAD/RMS), procurement processes and other issues.

Kelly and Bill have provided technical assistance to dozens of State, local and regional law

enforcement agencies that addresses their IT needs. This assistance includes technology

planning, development, improvement, acquisition, management and integration of

justice information systems, including CAD/RMS, mobile computing, field reporting,

jail management and crime analysis technologies. Their background in IT project

management, combined with the onsite work they have conducted nationwide and the

valuable lessons they learned from the COPS MORE workshops, means they have seen

what works and what doesn’t. Their experience has shown that employing tools to

improve information management — such as decisionmaking structures, strategic plans,
xiv

project management best practices and policies and standards — are critical to the

success of law enforcement IT acquisition. They have compiled best practices, procedures

and strategies for successfully undertaking complex law enforcement IT initiatives, and

are ready to share their knowledge and expertise.

Law Enforcement Tech Guide

Review Committee

SEARCH extends its deepest thanks and appreciation to the following members of the

Law Enforcement Tech Guide Review Committee, who participated in an advisory

capacity during the preparation of this Guide. These individuals have direct experience in

law enforcement IT planning, procurement, implementation and management and

generously contributed their time and expertise over a period of many months, providing

critical review and comments on early drafts of the Guide, as well as insights on law

enforcement IT projects that were incorporated throughout this document. Their

contributions to the successful completion of this Guide cannot be overstated.

Piper Charles Piper Charles

Major, Charlotte-Mecklenburg (NC) Police Department 

Ronald Glensor Ronald Glensor

Deputy Chief, Reno (NV) Police Department

William Telkamp

Commander, Altamonte Springs (FL) Police Department 

Gordon Wasserman

Chief of Staff, Philadelphia (PA) Police Department
About

the

Guide
Your agency needs a new computer-aided dispatch, records management, automated

vehicle location, evidence management, fingerprint identification, crime analysis and/or

some other automated information system. So where do you start?

Sure, there’s lots of literature out there on project planning and management, information technology (IT), strategic planning and the like (and we encourage you to read it, so

please see Appendix 3 of this Guide for references to publications we recommend). But

there are some special challenges that government agencies and law enforcement, in

particular, must contend with when they plan, buy, install and use new technologies.

Unfortunately, as many of you who have already experienced purchasing and implementing new technologies know, the process is simply not as easy as buying a product,

plugging it in and flipping a switch. Whether you buy an off-the-shelf solution or build a

custom system in-house, it is essential that certain steps be taken to ensure that the

project has the proper user support, is clearly defined, stays on track and within budget, project has the proper user support, is clearly defined, stays on track and within budget,

is designed to meet specific business needs or solve a particular problem, and can operate

within the constraints of a new or existing technical environment. within the constraints of a new or existing technical environment.

This Guide presents accepted and standard project management principles and strategies, but it has been adapted to and designed for the unique needs, limitations, challenges and opportunities faced by the law enforcement community. It details how an

agency can plan for, purchase, implement and use computer-aided dispatch, records

management, jail management and mobile data systems, to name a few. Regardless of the

technology your agency would like to pursue, these are standard processes that you

should follow in planning, purchasing and implementing a solution.

This Guide is particularly beneficial because much of the material and information has

been shaped by the successes, failures and lessons learned by law enforcement agencies

across the country as they navigated through these difficult projects.

HOW TO USE THIS GUIDE

The Law Enforcement Tech Guide is intended to provide strategies, best practices,

recommendations and ideas for successful IT planning and implementation. This Guide

should not be construed as specific legal advice for any specific factual situation. This

publication is meant to serve as a guideline for situations generally encountered in IT

planning and implementation environments. It does not replace or supersede any policies,

procedures, rules and ordinances applicable to your jurisdiction’s procurement and

contract negotiations. This Guide is not legal counsel and should not be interpreted as a

legal service.

About the Guide
4 About the Guide

Assumptions...

...About You

To prepare this Guide, we had to make some assumptions about you, the reader. We

think you could be one of many different people within your agency, and perhaps a

combination of several. Perhaps you are the Chief or Sheriff who must lead this effort.

Boy are we proud of you for picking up this book — keep reading, you are critical to this

effort! Or you may be a supervisor, manager, records clerk, dispatcher or detective. In any

case, you were imprudent enough to volunteer to shepherd this effort, or you inherited

this project unwittingly (or unknowingly), but certainly not by choice. Your knowledge of

the agency’s operations, the movement of and need for information to accomplish your

daily business needs, and your talent for making critical law enforcement decisions is

integral to this project’s success.

You may be the person in your agency responsible for technical support (and that does

not exclude you from also being one of the other types of readers as well!). If so, you will

be called upon to analyze existing and new technologies and help determine the best

technical solutions to meet the business needs of your agency.

Finally, you may be a project manager who possesses useful project management skills,

yet who has little experience with law enforcement. Or, you may not have any project

management skills, but you’ve been assigned to manage this task nonetheless. Either way,

your role of project manager is pivotal to this effort. You’re the “go-to” person for project

information and coordination. You have the unenviable responsibility of keeping the

project on track and within budget while adhering to the established timeframes.

In most law enforcement agencies, both sworn and civilian personnel must wear many

different hats; very few agencies have the resources for a fully staffed IT support department or to hire a dedicated project manager. We assume many of our readers will fall into

one or more of the categories above. If so, this Guide is for each of you.

...About Your Project

This Guide makes the assumption that your project has already been funded, and/or a

decision has been made to move forward with the project. It does not assume, however,

that funding has been set aside for project management because all too often we find that

is not the case.
About the Guide 5

How this Guide is Organized

This Guide is organized into six Parts that reflect key elements of the IT planning, buying

and implementation process:

Part I Build the Foundation

Part II Conduct a Needs Analysis

Part III Create a Project Plan

Part IV Acquire the Technology

Part V Implement the Technology

Part VI Maintain the Technology

If your project is already underway, you could easily skip right to the “Part” that best

reflects where you are in your current project. However, because each Part builds upon

the preceding, we encourage you to read all parts and chapters, regardless of your

project’s current status. You may, for example, be at the point of purchasing your

technology, so Part IV would be most suited to your immediate information needs. In

this case, we suggest that you also review the previous chapters, as they provide key

guidance on strategies to make the purchasing process easier and ensure that you buy the

right solution for your agency (for example, how to garner end-user involvement and

support for the solutions selected, precisely identify the operational requirements for the

system, establish risk management plans and formulate a solid budget, among other

tasks).

This Guide is also packed with a variety of tools. In the margins and throughout the

pages of the Guide, you will find tips, checklists, suggested techniques, definitions and

other helpful how-to information. Each chapter, for example, begins with a section that

answers the four “W”s about the topic: What is it, What Why do it, Why Who is involved and Who When

to do it. At the end of each Part is an Assignments Table, where we provide specific action

items for key members of the project team for a “quick and easy” reference to major tasks

and responsibilities relevant to that Part. We have included appendices with references to

resources, sample documents, checklists and other tools to assist you during your project

planning, purchasing and implementation process. Icons used throughout the Guide will

direct your attention to specific issues or topics.
6 About the Guide

Definition of Icons

Throughout this Guide, icons are used to draw your attention to important concepts,

ideas and, in some cases, warnings. We also use icons to highlight sections that certain

personnel within your agency should pay particular attention to. Below are the icons and

what they represent.

Executive Sponsor

The Executive Sponsor (defined on page 24) is the project spokesperson, decisionmaker

and leader. Executive Sponsors, primarily the Chief or Sheriff or other high-ranking

decisionmaker within an agency, will find recommendations and advice just for them

when they see this icon in the margins.

Operational Experts

Operational Experts are the end users of the technology and those intimately involved

with the business processes of the law enforcement agency, and can include patrol

officers, records clerks, dispatchers, detectives, crime analysts, community-oriented

policing experts, etc. Words of advice for Operational Experts will accompany this icon.

Technical Experts

Technical support staff will be busy not only analyzing the existing technological

environment, but also evaluating technical solutions. These Technical Experts will benefit

from recommendations indicated by this icon.

Project Manager

The Project Manager has a lot to juggle when it comes to overseeing the planning,

purchasing and implementation of IT. This icon will alert Project Managers to activities,

issues and concepts they must be careful not to overlook during each of these phases.

Stop Sign

Remember what we said: Lots of IT projects fail. When you see a stop sign icon, pay

particular attention, as it will indicate where others have encountered trouble in their

projects. The stop sign indicates pitfalls to avoid.

Grant Requirements

Be accountable to your grants. This icon will alert you when grant requirements may

come into play.
About the Guide 7

Regional

More and more IT efforts involve more than one agency and jurisdiction. This icon

symbolizes multijurisdictional and regional efforts. When you see it, it will provide

special advice for dealing with the unique nature of regional IT projects.

Tips

If we’ve heard or know of shortcuts or have useful ideas on how to tackle a particular

issue, we’ll use this icon to let you know.

Checklists

Checklists are always handy tools for making sure all the bases and steps are covered.

We’ll use this icon when we can provide a handy list of ideas or to-dos for your project.

Where to Go from Here

So, how does your law enforcement agency navigate this minefield of IT projects and

planning? How do you set up an appropriate chain of command to provide leadership

and decisionmaking on these projects? What are the critical elements that shape a

successful plan for IT purchase and implementation? What do you need to be aware of

when you buy technology? How do you appropriately manage risk associated with these

projects? How do you manage change and ensure user support for the solution your

agency purchases? If you are asking these questions, congratulations! You have made the

first steps toward a rational and strategic approach to your IT initiative. Keep up the

questioning and follow the strategies in this Guide, and you’ll be doing your best to

ensure IT success within your agency.
8 About the Guide

Law Enforcement IT Projects:

A Roadmap to the Guide
Seven Facts You

Should Know

BEFORE

Reading this

Guide
Fact #1

Implementing IT is difficult.

Fact #2

Planning and installing IT is different than other projects.

Fact #3

IT planning and implementation is not a one-time activity.

Fact #4

IT must support the strategic business mission, goals and

objectives of the law enforcement agency.

Fact #5

Successful projects require strong project management.

Fact #6

All projects require a plan.

Fact #7

Successful IT implementation can happen!
Seven Facts You Should Know

BEFORE Reading this Guide

Automated information systems information systems are a critical component of effective policing. Immediate information systems

access to information benefits virtually all levels of the criminal justice system. It means

arming patrol officers with real-time information about people, places and criminal

incidents. It means providing jailers with immediate access to an inmate’s criminal

record, religious preference and gang affiliation. It means providing Chiefs and Sheriffs

with access to crime statistics at a moment’s notice. Simply put, information systems arm

everyone from cadets to Chiefs with tools to make better decisions. And that can mean

only one thing: improved officer and public safety.

But getting there isn’t going to be easy. There are some things you should know before

you undertake an information technology (IT) project. After reading these seven facts,

share them with all of the individuals who will be involved in your project.

Fact #1

Implementing IT is difficult.

While the benefits to automation are numerous, planning and implementing IT is a

major undertaking that is not always met with success. In fact, consider what the

Standish Group found in a study of over 8,000 public and private IT projects:

Source: Source The CHAOS Report (1994), www.pm2go.com. www.pm2go.com

Information

System:

A purposefully

designed system that

brings data,

computers,

procedures and

people together in

order to manage the

information that is

important to an

organization’s

mission.

— Webster’s New

World Dictionary of

Computer Terms,

Seventh Edition
12 Seven Facts You Should Know

IT initiatives are difficult because: IT initiatives are difficult because:

• They are big projects that often take more than several years and several budget

cycles to complete.

• They often cross lines of authority.

• They deal with technology AND with aligning technology to an agency’s specific

business processes.

• They are time-sensitive.

There are many issues that challenge successful IT implementation. That’s why there is

such a detailed process for doing it right. We can’t list the multitude of things that could

go wrong on any given day in any particular project, but we will warn you of the biggies,

the sure-fire clues that indicate an IT project is endangered.

IT projects are particularly in jeopardy when: IT projects are particularly in jeopardy when:

• IT is considered a technology issue to be handled by technical staff only, rather

than a business issue with technical solutions.

• Users and upper management fail to understand how IT can enable law enforcement agencies to meet their business mission. It makes it difficult, then, to create a

strategic vision for IT in the agency.

• Upper management and/or end users are not involved in the IT planning, purchasing and/or implementation processes.

• Users do not see the benefit of IT or how it makes their jobs easier and better.

• Project management best practices are not followed in the planning and implementation of the project.

• Budgets do not fund or agencies are not authorized to hire (or outsource) dedicated IT staff and skilled project managers.

• Funding streams exist that:

— have such tight timeframes that they don’t allow for effective planning;

— fund the purchase of technology only, and not critical planning; and

— provide one-time funding for IT, and fail to provide ongoing support.

• Failure to follow systems development lifecycle principles (more information on

that later) that include long-term and continuous maintenance, planning, enhancement and budgeting for technology.

• Allowing the mere availability of technology to drive the decision to automate,

rather than the business needs of the agency driving the decision.
Seven Facts You Should Know 13

Fact #2

Planning and installing IT is different than other

projects.

Procuring technology is different than, say, purchasing office furniture. Okay, this may

seem to be an obvious statement, but you may be surprised to learn that many agencies

(and maybe yours has been one of them) do not put much more effort into IT procurement than buying a new desk, for example. The catalog comes, the furniture looks great,

the vendor promises complete satisfaction and that the piece is top-of-the-line and stateof-the-art. It’s also, they promise, made for any law enforcement agency. So you buy it.

Case closed.

But buying a desk that perhaps isn’t perfect won’t affect how many criminals are

apprehended and how quickly officers respond to an emergency. Information technology, on the other hand, often radically changes the way an agency does business — and it

should! It can help officers better identify and deal with suspects, make dispatchers more

effective, aid analysts in identifying crime patterns and detectives in solving cases. If

chosen hastily, however, technology can jeopardize mission-critical law enforcement

activities, and/or hamper users and management, so its potential benefits may never be

realized.

Furthermore, because IT impacts mission-critical activities, its implementation causes

major changes and most folks are reluctant when it comes to accepting change. So, while

a desk may be criticized for not having enough writing space or drawers, these issues will

not readily cause the department to throw the desk away and waste a great deal of

taxpayer dollars. Dissatisfied users of an information system, on the other hand, can (and

in numerous instances have) cause an information system’s downfall and demise, despite

large investments of time and money.

Fact #3

IT planning and implementation is not a onetime activity.

Read and repeat this sentence: “Technology planning, acquisition and implementation is

not a one-time activity.” The process is cyclical in nature (see graphic on page 14),

following what is known as the systems development lifecycle (SDLC), a process with systems development lifecycle

several stages, including planning, procurement, implementation and management.

However, the successful implementation of a system does not signal the end of the

planning process. Systems implementation really signals the beginning of a new phase of

evaluating the recently adopted system and planning for systems maintenance, upgrade,

enhancement and replacement.
14 Seven Facts You Should Know

With rapid advances in hardware and software, new system functionality is available

almost immediately after a system is implemented. That is not to suggest an agency

postpone acquisition in anticipation of the “latest” system. It only means that after a

system is installed, the planning process continues to take new technology, functionality

and capability into consideration. In addition, you’ll find user expectations change

quickly when new systems are implemented, and the demands placed on the systems

escalate.

Also, new State and Federal laws will continue to require automation from law enforcement agencies. Budgets must reflect this commitment to SDLC. Funding agencies must

be convinced to apply lifecycle costing methods when allocating funds to account for lifecycle costing

downstream expenses associated with operation, maintenance, training and coordination of change. Remember that one-time grants will not fund a lifetime of technology

support and replacement. support and replacement.

■ Systems Development Lifecycle
Seven Facts You Should Know 15

Fact #4

IT must support the strategic business mission,

goals and objectives of the law enforcement

agency.

Information technology can be an effective tool for any business to meet its overall

strategic objectives. But first, those business objectives must be outlined in a strategic

plan. Then, information systems can be designed that meet those strategic business

objectives.

Like any business, a law enforcement agency should first prepare a strategic business

plan that articulates the organization’s overall mission, goals and objectives. From this

strategic business plan, an agency can develop a strategic vision for information technology and its role in the agency. The strategic IT vision directly supports the mission, goals

and objectives of the agency.

This means the Chief/Sheriff must:

1) Have a strategic business plan in place that articulates the organization’s mission, goals strategic business plan

and objectives;

2) Recognize the mission-critical role of IT in policing;

3) Create a systematic process for continual planning, maintenance and support of

information systems; and

4) Develop a strategic IT vision document strategic IT vision document. strategic IT vision document

■ Strategic

Business Plan

Drives Agency IT

Vision
16 Seven Facts You Should Know

A strategic IT vision will articulate how technology will assist the agency in meeting its A strategic IT vision will articulate how technology will assist the agency in meeting its

core business mission and establish an ongoing process to evaluate, upgrade and core business mission

enhance those technologies as business goals and technology change. Agencies meet this

broad strategic IT vision through a series of individual projects projects that build the IT capabili- projects

ties of the agency, as illustrated on page 15.

This level of planning and coordination is essential for the various individual projects to

come together, integrate properly and collectively support the agency’s goals. come together, integrate properly and collectively support the agency’s goals.

INFORMATION TECHNOLOGY AND ITS ROLE IN THE

METROPOLITAN POLICE DEPARTMENT,

WASHINGTON, DC (MPDC)

“Information technology...makes it easier for the MPDC to share information with the

community quickly and effectively. As such, new information technology is a critical part of

the MPDC’s evolving strategy of community policing and crime prevention.”

“Technology does not drive itself; it is not created for its own purpose. New technology

must be reflective of, and advance, the new strategy of the Department.”

From Information Technology and the MPDC: Moving Into the Next Century

Fact #5

Successful projects require strong project

management.

A successful project is one that is completed on time and within budget, and meets user completed on time and within budget, and meets user

needs and expectations needs and expectations. That’s a tall order. That’s where needs and expectations project management project management comes in. project management 

What is project management and why is it so important?

The Project Management Institute (www.pmi.org) gives us a definition of project

management in its publication A Guide to the Project Management Body of Knowledge

(PMBOK®): “The application of knowledge, skills, tools and techniques to project

activities in order to meet or exceed stakeholder needs and expectations from a project.

Meeting or exceeding stakeholder needs and expectations invariably involves balancing

competing demands among:

• Scope, time, cost and quality.

• Stakeholders with differing needs and expectations.

• Identified requirement (needs) and unidentified requirements (expectations).”

Quality project management is critical to ensuring a successful project Quality project management is critical to ensuring a successful project. Quality project management is critical to ensuring a successful project

“

”

If an agency’s

business

mission is

vague or not

clearly

understood, the

IT projects

developed are

much less likely

to successfully

support the

strategic goals

of the

organization.

— Maj. Piper Charles

CharlotteMecklenburg (NC)

Police Department
Seven Facts You Should Know 17

Fact #6

All projects require a plan.

Successfully automated and integrated information system projects are preceded and

accompanied by continual, comprehensive and strategic planning, which allows system

stakeholders to develop a roadmap for the future.

A good plan determines the range of user needs, identifies automation priorities and

considers technology and data standards. It focuses on the human and funding resources

required to support these systems. It embraces the systems development lifecycle. The

plan addresses operational systems specifications, hardware and software standards,

existing systems and the environment in which the automated system will work.

Planning ensures that all users have their needs addressed by the system. Planning also

includes a complete business process review to find better, more effective and more

efficient ways of doing business. It contemplates future needs of the agency and users,

scheduled upgrades and replacements.

Fact #7

Successful IT implementation can happen!

Now that we’ve scared you into returning to the pen and paper, let us also tell you that IT

initiatives can and have been successful. But they are successful because project leaders

and team members followed best practices for planning and managing the projects from

idea to inception, such as clearly defining the project; getting the right people involved;

setting realistic goals, objectives and timelines; developing a thorough project plan;

accurately and honestly assessing risk; properly negotiating contracts; developing

structured implementation and training plans; and establishing benchmarks and

performance metrics for assessing and evaluating the project’s success.

And that is what this Guide is intended to do — walk you through the process of properly

planning and implementing an IT initiative. It will focus specifically on how to tackle

individual technology projects within a law enforcement agency. It’s a Guide that the

Chief/Sheriff, Project Manager, end user or technologist can pick up the minute the

phrase is uttered “let’s get a new ___________”(enter the information technology of

your choice in the space provided).

So read on! The rest of this Guide will tell you step by step how to prepare and execute a

plan for your technology project. Good luck!

A project is a

temporary endeavor

undertaken to create a

unique product or

service. ‘Temporary’

means that every

project has a definite

beginning and a

definite end. ‘Unique’

means that the

product or service is

different in some

distinguishing way

from all similar

projects or services.

— PMBOK®
Technological progress is like an axe in the

hands of a pathological criminal.

— Albert Einstein

Part I:

Build the

Foundation
Have you read the

“Seven Facts” section

yet? If not, it is important

that you read it before

you continue any further.
CHAPTER 1

ESTABLISH A DECISIONMAKING

STRUCTURE
Chapter 1:

Establish a Decisionmaking

Structure

A decisionmaking structure for your IT project that:

• provides leadership and accountability,

• defines the business of the agency,

• analyzes technical environments, policies and solutions, and

• effectively manages projects.

To ensure that there is a well-defined decisionmaking structure with clear responsibilities and authority, that the structure is officially sanctioned and that it involves users

to address business problems.

Agency leadership (Chief, Sheriff and upper management), users (patrol officers,

investigators, dispatchers, records clerks, crime analysts, community policing experts,

etc.), a dedicated Project Manager and technical staff.

Immediately — before your project gets underway.

Projects, like police organizations, require structure and disciplined rules if they

are to be successful. The decisionmaking structure defines the project’s “ decisionmaking structure chain of chain of

command,” documenting the command roles and responsibilities roles and responsibilities of the various people roles and responsibilities

responsible for project actions.

This chapter provides strategies strategies and strategies best practices best practices for getting the right people best practices

involved and developing a formal structure for governing a project from planning formal structure

to implementation. The decisionmaking body will provide oversight and is integral

to carrying out all of the work identified in this Guide.

Technology project success depends on user involvement, strong project management

and a sound structure for project planning and decisionmaking. Without these essential

elements, even the most well-intended and state-of-the-art technology is likely to fail, as it

would be designed without strong leadership, effective management, proper planning

and the support, input and commitment of the end users.

IT projects require significant buy-in at all levels. The Chief or Sheriff must support the

initiative from a financial, personnel and business perspective. Users must be willing to

use the technology once it is in place. Technologists must understand the technical

environment and successfully support the automated systems.

What

Why

Who

When
24 Part I: Build the Foundation

Thus, planning for technology is not simply a technical issue to be resolved by the

agency’s technical staff. Planning, purchasing, implementing and using IT successfully is

a complicated process that can be impacted by political, organizational, legal, technical,

cultural and personality issues. Furthermore, the decision to implement IT must be

based upon a particular business need within an organization, rather than the mere

availability of technology driving the decision to automate.

Step 1

Identify an Executive Sponsor

You must first identify an Executive Sponsor, one who will accept the ultimate accountability for the project and who has the authority to sanction the project and make it a

priority. This individual will serve as the champion, spokesperson and leader for the

technology initiative.

Additionally, the Executive Sponsor will serve as the project’s ultimate decisionmaking

authority, committing resources (both human and financial), approving budgets and

seeking funding to support the project.

Obviously, this individual must hold a significant rank within the organization, or at least

be vested with appropriate decisionmaking authority. We have found that the most

successful projects are led by an Executive Sponsor who is a Chief or Sheriff. In larger

agencies, or if a project affects a single unit within the agency, sometimes the Deputy

Chief or Sheriff who presides over the unit is the Executive Sponsor.

Step 2

Identify Stakeholders

It is critical at the earliest stage in your IT project to identify those people who will be

affected by it. Make sure to consider not only those folks who will be using the system,

but also those who indirectly play a role in achieving the success of the system. As an

initial step, the Project Management Institute advises that it is critical to:

• identify the stakeholders,

• determine their needs and expectations, and then,

• manage and influence those expectations to ensure a successful project.

Obvious key stakeholders will include the Project Manager, system users, your law

enforcement agency, and the Chief/Sheriff or Executive Sponsor. But also consider the

variety of internal and external project stakeholders:

Without agency leader

involvement, projects

can be hampered by

personality and turf

issues, lack of funding

or any multitude of

issues that require the

agency executive to

mediate and/or

neutralize.
Chapter 1: Establish a Decisionmaking Structure 25

• City Council or County Commission, and any other policymakers and purse-string City Council or County Commission

holders.

• The public. The public is increasingly interested in law enforcement information The public

and requesting crime maps and statistics for their communities. Law enforcement

agencies will also need to solicit public input for their community policing and

other programs. In addition, some policing agencies answer to a police commission and/or an independent public board. (The Los Angeles Police Department,

for example, answers to a Board of Police Commissioners, comprised of five

civilians appointed by the mayor whose role is to “serve as the citizens’ voice in

police affairs ... .”)

• The media. The media

• Other government and public safety agencies Other government and public safety agencies. Integration and information sharing Other government and public safety agencies

with other authorized justice agencies should be considered, such as with the fire

department, prosecuting attorney and the courts. Agencies outside of public

safety, such as housing, public works, parks and traffic engineering, are critical to

community policing and problem solving.

• Others as dictated by your unique needs. Others

Step 3

Create a Project Decisionmaking Structure

One thing is for certain: Successful IT planning and implementation cannot be achieved

without a well-defined decisionmaking structure. There are many ways to set up a

decisionmaking structure to govern IT initiatives.

In this section, two decisionmaking structure models are offered that specifically reflect

the differences between large-scale IT initiatives (undertaken by large, regional or

multijurisdictional policing agencies) and narrowly focused projects of smaller scope (in

small- to medium-sized agencies). We suggest that you review both models, as one or a

combination of both may suffice for your initiative, given the size of your agency and the

scope of your project.

Follow Structure #1 if:

— Your agency is large (typically, an agency is considered “large” if it employs over

100 sworn officers).

— Your project is large (involving multiple technologies, or a technology that affects

multiple units or the entire department).

— Your project is a regional effort (involving multiple agencies and/or

jurisdictions).

See

page 27.

Project

stakeholders are

individuals and

organizations who are

actively involved in

the project, or whose

interests may be

positively or

negatively affected as

a result of project

execution or

successful project

completion.

—PMBOK®
26 Part I: Build the Foundation

Follow Structure #2 if:

— Your agency is small- to medium-sized (fewer than 100 sworn officers).

— Your project is narrowly focused (for a large agency, perhaps it is a project within

a specific unit).

— Financial limitations restrict the amount of human resources that can be

allocated to project planning.

MAKE A NOTE OF IT!

Representatives of the Decisionmaking Structure will:

✓ Articulate a united vision and determine the scope and focus of your IT project.

✓ Identify legal, policy, administrative, funding, technical and political obstacles to achieving

automation and integration.

✓ Define and sanction project objectives, tasks and timetables.

✓ Garner support from other relevant decisionmakers (City/County Council).

✓ Monitor planning, implementation and management of IT.

✓ Define the operational requirements for an automated solution.

✓ Oversee systems acquisition.

✓ Resolve obstacles to implementation.

✓ Review system performance.

✓ Make recommendations concerning systems improvements, enhancements and next steps.

See

page 32.
Chapter 1: Establish a Decisionmaking Structure 27

Structure #1

Suggested for Large Agencies/

Multijurisdictional Efforts

Although there are many ways to configure a project decisionmaking structure, the

following illustrates a common and basic structure comprised of a Steering Committee to Steering Committee

which two additional groups report: a User Committee and a User Committee Technical Committee. Technical Committee Ad

hoc working groups hoc working groups may be convened for specific short-term tasks. hoc working groups

■ Sample Project Decisionmaking Structure #1

1.3 USER COMMITTEE

Subject matter/business process experts

Patrol Officers, Dispatchers, Records Clerks

Identifies systems operational requirements

1.4 TECHNICAL COMMITTEE

IT support staff

within the agency and from parent IT organization

Analyzes technical environment

Identifies technical solutions

1.5 AD HOC

WORKING GROUP

Focused on a particular

project, e.g.,

computer-aided dispatch

(CAD)

1.5 AD HOC

WORKING GROUP

Focused on a particular

project, e.g.,

records management

system (RMS)

1.5 AD HOC

WORKING GROUP

Focused on a particular

project, e.g.,

researching mobile

computing devices

1.5 AD HOC

WORKING GROUP

Focused on a particular

project, e.g.,

transferring data from

CAD to RMS

EXECUTIVE SPONSOR

Chief/Sheriff

Ultimate decisionmaking authority

Provides leadership and accountability

1.1 STEERING COMMITTEE

Deputy Chief(s)/Sheriff(s), i.e.,

Records, Identification, Dispatch, Jail

Provides leadership, creates vision, removes obstacles

1.2 PROJECT MANAGER

The person responsible for all project-related

tasks and deliverables

Directs User and Technical Committees

Informs Steering Committee
28 Part I: Build the Foundation

1.1 The Steering Committee

Who Captains, Lieutenants, high-ranking nonsworn employees (i.e., dispatch

supervisor, records supervisor, IT manager).

Role Adopt a shared vision; commit to and guide the project; dedicate staff

resources; keep abreast of project progress, risks, challenges, successes;

provide update reports to Executive Sponsor; remove project barriers;

deal with policy and personnel obstacles; and render decisions on issues

that impact project scope, time and cost.

Members of the Steering Committee are generally high-level managers and/or supervisors within the agency. These individuals can assign and commit staff within their

department, division or unit to participate in the project as needed. This group will

ensure that a structured project management process is adopted and followed for the IT

project. The Steering Committee will provide constant guidance and oversight to the

project, its progress and deliverables, and will make most decisions related to the project.

They will keep the Executive Sponsor informed of project progress and advise the

Sponsor of specific action the Sponsor may need to take to remove project barriers or to

garner resources. Additionally, Steering Committee members are often individuals from

the agency who are involved in broader agency strategic planning initiatives and will

make sure that the IT project is properly aligned with the agency’s budget, as well as

overall business objectives, such as community oriented policing.

For regional efforts, the Steering Committee should be comprised of the Chiefs/Sheriffs of

each of the agencies involved in the initiative. Appointing alternate representatives for the each 

Chiefs/Sheriffs is not recommended, unless they are given full decisionmaking authority for not

their agency.

1.2 The Project Manager

Who Ideally, an individual who has project management skills, experience

and/or training, dedicated in a full-time manner to the success of the

initiative.

Role To provide overall project direction, manage the project’s schedule, serve

as a single point of contact with vendors, direct/lead team members

toward project objectives, review and approve project deliverables,

handle low-level problem resolution, serve as liaison to the Steering

Committee.

“

”

It’s essential to

have a unified

department

approach with

all senior

management

around the

table.

— Timothy Bray

Illinois State Police

Note:

A detailed discussion

of how to hire, assign

and/or train a Project

Manager

can be found in

Chapter 2.
Chapter 1: Establish a Decisionmaking Structure 29

The Project Manager must be selected with careful consideration and may need to be

empowered to forego his or her normal duties and assignments, sometimes for periods of

up to 2 years or more, depending on the project. The Project Manager is responsible for

virtually all aspects of the initiative and is formally accountable to both the Steering

Committee and the Executive Sponsor. (Informally, the Project Manager is accountable

to the User and Technical Committees.) In the event that outside assistance is used (such

as contract consultants), the Project Manager will also be responsible for coordinating

activities in terms of adopting any recommended project methodology and/or

deliverables and facilitating resources (i.e., ensuring that a group of individuals are

available for a meeting). The Project Manager assumes the greatest degree of project

responsibility and accountability within this framework.

To complete the decisionmaking structure, two other components are essential: User and

Technical Committees. While the Steering Committee sets policy, makes key decisions

and commits agency resources, its members are not generally involved in the daily

operational information flow within and between the agencies, nor do they (or should

they) know the technical solutions to these issues. The User Committee is essential for

understanding, analyzing and defining the business of the law enforcement agency, while

the Technical Committee assesses current technical environments and formulates the

technical solutions that enable automation and information sharing.

1.3 The User Committee

Who Subject matter and business process experts for the functions to be

addressed (i.e., patrol officer, detective, dispatcher, records clerk, crime

analyst, property manager).

Role To assist and support in creating a project charter (Chapter 3) and

ultimately the project plan (Part III). To analyze existing workflows,

define business processes (Chapter 4), look for efficiencies and establish

the requirements of any new system.

The User Committee will include the “front-line” personnel and key users of the technology. Think of it this way: If a particular group of individuals, patrol officers, for example,

will use the technology, they MUST be represented on the User Committee. Obviously

not every patrol officer needs to be included, but key representative(s) who are in the

field and know the day-to-day business of a patrol officer should have a seat on the

Committee. Individuals serving on this Committee can include patrol, detectives,

dispatch, records clerk, crime analysts and managers. Determining who should be on the

Committee will be governed by the specific business processes being addressed (see

example next page).

The User Committee

should be focused on

defining the business,

not technical,

solutions for the

system.
30 Part I: Build the Foundation

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

This group will be charged with analyzing current business processes and practices,

identifying ways to improve workflow and efficiency, and defining how the system will

support their business needs to make their work more efficient and effective and solve

particular problems. The User Committee will evaluate software and technical solutions

to their business requirements.

EXAMPLE

Anycity’s Chief has decided to replace or enhance the department’s CAD/RMS. In assigning

individuals to the “User Committee,” the Chief appointed the following individuals for the

following purposes:

DISPATCHER Uses the system on a daily basis to properly dispatch units

and capture critical call information.

PATROL OFFICER Enters incident reports on a mobile computer that directly

accesses and feeds the new records system.

DETECTIVE Uses the system to build cases.

RECORDS CLERK Enters, validates and maintains information entered in the

system.

CRIME ANALYST Uses data stored in the system to provide valuable

information on crime trends.

POLICE SUPERVISOR Uses information captured in the new system for

AND MANAGER management of statistics and staff allocation.

CITY GIS Explores the integration of CAD and RMS with the Geographic

REPRESENTATIVE Information System (GIS).

Committees should

follow the rule of

12: the maximum

number of individuals

who should participate

on a committee for

effective

decisionmaking.
Chapter 1: Establish a Decisionmaking Structure 31

1.4 The Technical Committee

Who Dedicated technical staff from the agency, as well as City/County/State

IT staff if support is provided to the agency by the parent organization or

central data processing shop of the local jurisdiction.

Role To understand the vision proposed by the Steering Committee and the

User Committee’s workflow and business needs. To analyze the agency’s

existing technical environment. To research and propose solutions to the

agency’s business needs and problems.

The Technical Committee will take its cues directly from the User Committee. Once the

User Committee has defined what it needs from a business perspective, the Technical

Committee will analyze those needs with a focus on the agency’s current technical

environment and potential industry solutions. The Technical Committee may be heavily

involved in either “building” the solution in-house or evaluating solutions proposed by

vendors. This Committee will also have to make important recommendations about

training, assigning and hiring staff to implement, support and maintain the new system.

1.5 Ad Hoc Working Groups

Throughout the course of the project, it may be necessary to convene ad hoc working

groups to focus on particular issues. These groups may be formed to look at specific tasks

and business processes that require more in-depth research or analysis, or to carry out

research on and development of a variety of project-specific plans, models, policies and

directions. Ad hoc working groups are assembled on a temporary basis to address a

specific issue or task.

EXAMPLE

XYZ police department is planning for a new CAD/RMS. The following ad hoc working

groups were formed:

✔ Crime Analysis

✔ Data Transfer from CAD to RMS

✔ Mobile Access to CAD and RMS Data

✔ Management Statistics

✔ Automated Field Reporting

The decisionmaking

structure should not

be disbanded. It will

be dynamic, perhaps

changing scope, focus

and membership over

time, as priorities,

project phases and

projects change. A

decisionmaking

structure remains

intact to continually

assess the technology

initiative and plan for

its next phases and

future enhancements.

○○○○○○○○○○○ ○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○
32 Part I: Build the Foundation

Structure #2

Suggested for Smaller Agencies/

Narrowly Focused Projects

Obviously, if your agency is a small one, or if the project is relatively narrow in scope,

your decisionmaking structure may, for example, consist of one committee in which the

Chief, users and technical experts all participate. The important concept to note is that

representatives from the leadership, business and technical specialties should participate

on the committee.

The following structure illustrates how small- to medium-sized agencies generally

arrange their project’s decisionmaking structure. This approach is more common in

projects with limited staff size and responsibility. In this instance, the Steering, User and

Technical Committees are merged together in one Steering Committee. The chain of

command in this example is more direct, as there are fewer individuals involved in the

project. Also, agency personnel with specific expertise can be called upon to advise and

assist the Committee with research and other tasks on an as-needed basis.

EXECUTIVE SPONSOR

Chief/Sheriff

Ultimate decisionmaking authority

Provides leadership and accountability

STEERING COMMITTEE

Deputy Chief(s)/Sheriff(s), i.e.,

Records, Identification, Dispatch, Jail

End users, IT staff

Provides leadership, creates vision, removes obstacles

PROJECT MANAGER

The person responsible for all project-related

tasks and deliverables

■ Sample Project Decisionmaking Structure #2
Chapter 1: Establish a Decisionmaking Structure 33

CAD Project

Platform Team Leader

STEERING COMMITTEE

Police Chief, Fire Chief, Sheriff and

Assistant City Manager

Consultant

PROJECT MANAGEMENT

Deputy Chief, Reno PD, and the

Project Manager

PROJECT MANAGER

ASSISTANT

PROJECT MANAGER

Fire RMS

Platform Team Leader

Police RMS

Platform Team Leader

CMS

Platform Team Leader

MIS

Platform Team Leader

CAD Team

Fire RMS Team

Police RMS

Team

CMS Team

MIS Team

As we said in the beginning of

this section, decisionmaking

structures can be configured in a

variety of ways. The key point is

that Executive Sponsors, upper

management, users and

technologists play an important

role in any structure. This is the

decisionmaking structure

established to govern the City of

Reno and Washoe County’s

Public Safety and Justice

Project.

In this decisionmaking structure,

the Steering Committee is

comprised of the executive

sponsors (Chiefs, Sheriff and

Assistant City Manager). The

project management team,

comprised of the Deputy Chief of

the Reno Police Department and

the Project Manager, oversee the

daily project activities. A

consulting firm has been hired to

work on this project, and reports

directly to the project management team. The committee

structure is organized so that

there is a “team” for each major

IT project underway. Each team

has a designated leader, and

each team is comprised of both

the user representatives and

technology support staff.

RENO/WASHOE COUNTY (NV)

DECISIONMAKING

STRUCTURE
34 Part I: Build the Foundation

Step 4

Involve Other Subject Matter Experts in

Committee Deliberations

Make sure not to plan your project in a vacuum! Carefully assess other information

systems (new and old) and technology projects taking place around your initiative and

gather information on them. As discussed in the “Seven Facts” section of this Guide, any

IT project you undertake should be managed in relationship to the broader IT vision your

agency has adopted. In other words, receiving a grant to purchase and implement a new

CAD system means that you must plan and purchase the system while considering its

integration with new and/or existing records management, geographic information,

automated vehicle location systems and other law enforcement technologies.

But your agency should also look beyond in-house technology to identify potential

information sharing with other justice agencies that will provide efficiencies and leverage

the benefits of automation. For example, when implementing a new RMS, a law enforcement agency should look at the potential of electronically sending incident information

to the prosecuting attorney’s office and the court. Automating the warrant process and

sharing the data with the court is another way law enforcement agencies benefit from

electronic capture, storage and sharing of information.

To appropriately do this, representatives of other agencies and/or internal or external

projects that can impact the primary project should be asked to provide input and

coordinate efforts. For example, if the current project focuses on a new CAD/RMS, other

individuals asked to provide input and consultation to Committees or Working Groups

could include a representative from the court automation team, a representative from the

City who is working on a new citywide GIS, and the architect designing a new communications center. This may also be an appropriate time to consider input from a member of

the public (if the public is identified as a key stakeholder).
Chapter 1: Establish a Decisionmaking Structure 35

Step 5

Make the Most of Committees: Conduct

Effective Meetings

What makes a good meeting?

- Short and to the point

- Well organized

- Clearly defined and understood meeting objectives

- Everyone contributes fully

- Everyone feels comfortable if they wish to disagree

- Any conflict is constructive and creative

- Decisions are made and action is planned

- The group openly reviews their effectiveness

- Meetings begin and end on time

How to conduct a meeting:

1. Define the purpose

2. Set an agenda

3. Set a timeframe with start and end times for the

entire agenda, as well as individual agenda items

4. Start on time

5. Always keep minutes

6. Keep everyone focused

—www.telstra.com/business

Nothing is more frustrating for overworked law enforcement personnel than participating in meetings that fail to yield tangible results or make marked progress and that are

held just for the sake of it. For the most part, folks who participate in the decisionmaking

structure have full-time jobs in addition to this project. When those groups are called

upon to meet and work, it is essential to make the most of their valuable and limited

time. Make sure each Committee agrees to follow structured meeting procedures by:

✓ Electing or appointing a Committee Chair

who will commit to leading the Committee

and respond to task requests.

✓ Establishing consistent meeting times and

dates (e.g., every other Wednesday at 2 p.m.). dates

✓ Preparing and distributing an agenda for each agenda

meeting. The agenda should be complete with

time allocations for the full meeting, as well as

breakdowns for each topic. The Project

Manager and Committee Chair are responsible for making sure the meeting sticks to the

agenda and the times allotted. Agendas

should be:

➔ Focused — stick to a subject and have

specific objectives or goals;

➔ Not have too many topics — cramming

an agenda with too many major issues is

overwhelming;

➔ Complete with background information

(if available) on each topic; and

➔ Distributed a few days before the meeting

so members have time to review the

topics and prepare.

✓ Determine voting procedures for each voting

meeting. For most projects handled within a

single agency, a simple majority vote is

generally acceptable.
36 Part I: Build the Foundation

In large-scale or regional efforts, equality in voting should be established. Each agency

participating in the effort will have one vote, and decisions must be unanimous.

✓ A note taker should be present at all meetings. Meeting minutes Meeting minutes should be Meeting minutes

prepared and distributed for every Committee meeting. This prevents returning

to previously resolved issues or covering the same topics time and time again.

✓ Adopt a problem escalation and resolution process problem escalation and resolution process so the rules are clearly problem escalation and resolution process

established at the outset of the project. Here’s an example:

EXAMPLE

The following problem escalation and resolution process will be followed for problems

(e.g., resource availability or scheduling) that may arise during the course of the project:

Step 1 A Committee member will report problem to Project Manager.

Step 2 Project Manager will research the issue, identify resolution options and make

a recommendation to the Steering Committee.

Step 3 Based on the nature of the issue, the Project Manager will seek resolution

approval from the Steering Committee.

Step 4 The Project Manager will keep track of problems and their formal resolution.

Step 5 Following an approval or denial by the Steering Committee, the Project

Manager will notify the original requestor of the action taken. There is no

appeal process.

See Appendix 3 for recommended reading and World Wide Web sites regarding best

practices for conducting effective meetings.

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

Record major ideas

and action items on a

flip chart so all team

members can review

them. Before each

meeting is over,

prepare a list of action

items and the person/

persons responsible

for them and display

on the flip chart.
Chapter 1: Establish a Decisionmaking Structure 37

Step 6

Make Determinations about Staffing

In-house or Outsourcing Project Staff

Support

After reviewing this chapter and understanding more about your own project, you may

be concerned about staffing for this effort. Perhaps you are concerned about the availability and/or skill levels of existing staff. Perhaps there are personalities within the organization that have a difficult time working together or that could use a mediator or skilled

facilitator to guide and referee discussions. Perhaps you just need objective, neutral and

outside input during each phase of your project.

In determining whether you should handle this project in-house or outsource it, you

should ask yourself, at a minimum, these questions:

• Who will guide/steer this project through its entire lifecycle?

• Who will establish action items and make task assignments?

• Who will be responsible for documenting project deliverables?

• Who will set meeting agendas and conduct follow-up?

• Who has expertise in project management best practices and planning?

• Who has expertise regarding the technology and current law enforcement IT

applications and their potential uses?

• Do we know enough about technology projects to ensure success?

• Do we have the time necessary to do this properly?

• Do we want to do this?

At this point, it may be time to consider outsourcing some staff functions if you find there

are not sufficient or skilled resources in-house to do so. This involves some honest

assessments about existing staff, their capabilities and current commitments. Project

leaders often base their decision to outsource on the following criteria:

❏ Skill levels of current staff. An objective and honest assessment must be made levels 

regarding the skill levels of current staff to handle the initiative, specifically in the

areas of project management and the specific technology you are trying to

implement.

❏ Project complexity. Aside from the obvious large-scale or multijurisdictional Project complexity

efforts, remember that even projects that appear relatively simple can require

expert knowledge and skills (consider the complexity of some interfaces: the scope

may be small, but the coordination and skill requirements can be immense). If a

Outsourcing: The

Force Multiplier

In addition to using

in-house staff,

outsourcing a number

of project activities to

a third party can help

an agency get more

work done in a shorter

timeframe.
38 Part I: Build the Foundation

project involves a high degree of complexity or will have a major impact on agency

operations, a detailed assessment of staff skill levels and availability will be

required.

❏ Budget allocations Budget allocations. Is there sufficient funding in the budget to allow outsourcing of Budget allocations

staff activities? Is there sufficient funding to compensate for overtime costs

associated with using in-house staff? As a general rule, consulting services will cost

approximately 10–15% of the project’s budget. An important concept to consider is

the likelihood that outsourcing will actually reduce project costs by preventing

costly project mistakes and by capitalizing on a consultant’s ability to negotiate

prices with vendors.

Many agencies turn to professional consultants or firms to assist with their projects. The

role of a good consultant includes one, or a combination, of the following:

• Expertise. The consultant provides knowledge or skills the agency does not have in- Expertise

house (e.g., an in-depth knowledge of the planning process or operational technology such as CAD/RMS/Mobile systems).

• Additional staffing. The consultant often performs tasks that an agency knows Additional staffing how

to do, but just doesn’t have time to do (e.g., organizing meetings, drafting documents, conducting interviews, etc.).

• Partnership. The consultant often participates as a Project Team member, contrib- Partnership

uting knowledge and guidance while empowering agency staff with the ability to

accomplish various tasks (e.g., providing guidance in the key elements of building

a business case, conducting strategic planning or facilitating meetings). The

outcome of such a partnership can be a more a structured initiative, with agency

personnel in command of their project.

Although outsourcing may enhance your chances of success, it will not relieve you from

the burden of project accountability. Therefore, it is critical that you appoint an agency

staff member to serve as the Project Manager, and you must insist upon using the

guidelines presented in this book (or some other accepted and structured methodology)

to properly plan and implement your technology initiative.

What is the biggest mistake that companies make with regard to IT

outsourcing?

“Companies believe they no longer have to manage IT because it is outsourced.”

— Peter Pijawka

President, Aligne
Chapter 1: Establish a Decisionmaking Structure 39

If you choose to outsource, at the very least make sure to:

• Detail the expected scope of work and other expectations for the consultant.

• Determine a realistic budget for the services.

• Request proposals for scope, timeline and cost of work from the consultant.

• Develop a clear contract with the consultant that includes the above items.

• Get at least three references.

• Request the consultant identify a strategy for his or her exit from the project when

concluded.

Remember: Consulting costs allowable under grants are usually

subject to rate caps. Be sure to check these limits prior to outsourcing.
CHAPTER 2

HIRE, ASSIGN AND/OR TRAIN A

PROJECT MANAGER
Chapter 2:

Hire, Assign and/or Train a

Project Manager

An individual accountable for all project-related activities and solely responsible for

the project’s scope, quality and budget.

To facilitate project accountability and organization. As the single point of contact for

agency leaders, project committees and working groups, vendors and subcontractors,

the Project Manager is the center of the project universe.

A full-time individual either currently on staff or hired specifically for the project.

Ideally, assigning existing staff should be done when the employee can be dedicated

exclusively to the project (not as an “additional assignment”). Your agency should try

to choose someone with strong project management experience.

As early as possible in the project, before major decisions are made about project

scope, goals and objectives, etc. A skilled Project Manager will possess a vast range of

experience to help complete all of the important project planning tasks.

If you don’t have someone at the helm of your project who is responsible for all

aspects of the initiative, it can quickly and easily spin out of control or fall apart

completely. Furthermore, a Project Manager keeps the “paper trail” on the project,

so to speak, documenting all issues, actions, decisions and phases. The Project

Manager is the individual responsible for all project stages, phases, tasks and

deliverables, and is answerable to the Executive Sponsor and Steering Committee.

This chapter will help define what the Project Manager does and help you assess

whether you have someone within your agency who can fulfill this critical role.

What

Why

Who

When
44 Part I: Build the Foundation

JOB OVERVIEW

The Project Manager will:

■ Oversee, plan, schedule and

control activities related to

planning and implementing

new law enforcement information systems.

■ Fulfill project objectives by

applying theoretical, managerial and communications skills

to satisfy project requirements.

■ Lead, coordinate and integrate

Committee and individual

efforts in this regard and build

positive professional relationships with users.

■ Report to the project’s Executive Sponsor and Steering

Committee, and preside in the

User and Technical Committees

and ad hoc working groups

throughout the course of the

project.

RESPONSIBILITIES

• Structures projects and activities.

• Develops project plans and schedules (using

the work breakdown structure (WBS)

discussed in Chapter 9).

• Manages projects within the established

schedule constraints.

• Controls project costs to ensure budget

performance and compliance with grant

requirements.

• Ensures compliance with agreed-upon project

management procedures.

• Manages, coordinates, integrates and

facilitates the efforts of individuals and

Committees and other resources associated

with the project.

• Supervises subcontractors and outside

professional services.

• Coordinates project planning activities.

• Coordinates project purchasing activities.

Interfaces with vendors to ensure conformance to specifications/standards and the

Project Plan, and with City/County procurement officials to ensure compliance with

purchasing/contracting regulations.

• Effectively communicates in meetings,

conversations and presentations in a concise,

clear and professional manner.

• Professionally directs and leads meetings.

• Prepares and issues written correspondence,

including progress reports, meeting agendas

and minutes, proposals and project summaries to project leadership, committees,

stakeholders and staff.

• Ensures timely follow-up to all commitments.

SAMPLE PROJECT MANAGER
45 Chapter 2: Project Manager

• Compiles all project files.

• Researches and applies appropriate technologies to support scope of work documents,

designs and specifications.

• Keeps in touch with technological developments within specific discipline/area of

expertise.

• Supports and interacts with other Project

Managers, where appropriate, to ensure the

success of their projects and the successful

integration between projects.

• Provides employee and contractor performance feedback as required.

• Develops a workload management plan

(resource planning) that organizes and

forecasts personnel allocation to assignments.

• Develops task estimates.

• Continually evaluates Project Plan for

alignment with the agency’s overall strategic

IT vision.

• Performs other duties as required.

REQUIRED SKILLS

• Ability to effectively organize and structure

activities.

• Strong analytical capabilities.

• Ability to grasp strategic concepts.

• Strong strategy development skills.

• Exceptional verbal and written communication skills.

• Good understanding of business and financial

principles.

• Ability to lead and facilitate multiple activities

and resources.

• Ability to develop master project schedule,

complete with work breakdowns and

assignments.

• Direct and control all work performed within

the WBS.

• Ability to assign tasks.

• Effective problem-solving skills.

• Basic computer usage skills.

PERSONAL ATTRIBUTES

• Strong interpersonal skills.

• Strong managerial skills.

• Team-building skills.

• Ability to motivate and develop others.

• Tenacious.

• Thick-skinned.

• Effective communicator.

WORKING CONDITIONS

 This project may require the following:

• Extended hours.

• Travel throughout the United States to review

other law enforcement automated systems

and attend applicable conferences and/or

training.

JOB DESCRIPTION
46 Part I: Build the Foundation

Project Manager’s Responsibilities

See: The rest of this Guide! The rest of this Guide!

Seriously, the Project Manager will be involved in all aspects of the agency’s IT project

and, indeed, should coordinate and lead the activities outlined in this book. The Project

Manager ensures that all appropriate planning requirements have been addressed

throughout the course of the project.

As we noted in “About the Guide,” this book is

written with the assumption that your agency

can dedicate existing staff or will hire a fulltime, in-house Project Manager. This Guide is

intended to walk you and your staff through a

project management strategy for law

enforcement information systems planning

and implementation. If, after reviewing this

chapter, you determine your agency does not

have the in-house resources or will not be

hiring a full-time Project Manager, you may

need to outsource the project management

role. We want you to be aware that any firm or

individual that you may outsource this role to

will (and should!) have established project

management methodologies and techniques

that they follow. Those methodologies may

differ from this Guide in the order they are

completed or what they are called. This Guide,

in that case, will serve to educate you — prior

to outsourcing — about key project

management issues and tasks, and can be

used as a reference in working with the

contractor you have chosen. It may become a

particularly useful tool if your contractor has

little or no experience in law enforcement

information systems planning and

implementation (we would discourage you

from contracting with one who doesn’t have

much experience, but we realize that

sometimes budget limitations and availability

can limit your choices). In any event, we want

you to know that when you outsource, you will

be following your contractor’s methodology

for project management, but that the Guide,

nevertheless, will be a useful tool in that

process. Even if your agency elects to

outsource project management

activities, there must be an agency

staff member who is responsible for

overseeing the entire project and

representing the agency’ s interests; no

vendor can do that.
47 Chapter 2: Project Manager

Project Manager Tool Kit

Now that you’ve gone to the trouble of securing a good Project Manager, make sure you

provide this person with tools to make him or her effective at this job, such as those listed

below.

• Ongoing training in effective project management is worth its weight in gold, or at

least the registration fees. If you are reassigning someone in your department to

manage this project, find a 3- to 4-day project management course that person can

attend.

• Encourage your Project Manager to join a professional project management

organization and to network with Project Managers from other police agencies in

your area.

• Suggest the Project Manager review helpful online resources, complete with online

project support information, such as those listed in Appendix 3.

• Purchase a solid project management software package.

• Check out colleges and universities for project management information and

courses.

• The Project Management Institute (www.pmi.org) is one of the best resources for

tools and support for the Project Manager. Information on PMI can be found in

Appendix 3.

Executive Sponsors: Make the Most of Your

Project Manager

As you’ve gathered so far, many agency staff will be important to the success of an IT

implementation. However, two individuals in particular are critical to a project’s survival,

and their relationship with each other is key. As we have mentioned, your role as the

Executive Sponsor cannot be overemphasized, particularly in relation to providing

continuous support and direction to the other critical project person: the Project

Manager.

The rest of this Guide will focus on the critical tasks that will occur throughout the life of

the project to continually ensure that the project is on track, properly focused and within

budget. As Executive Sponsor, you must do the following to effectively complete these

tasks and realistically deal with the project’s challenges, opportunities and difficulties:

• Supply the Project Manager with training, training, if needed, and the appropriate tools training, 

(mentioned above).

• Empower Empower the Project Manager — i.e., give the Project Manager authority to call Empower

meetings, assign tasks to team members and enforce completion of those assign-
48 Part I: Build the Foundation

ments. Ensure that the Project Manager has sufficient authority to provide teams

with the necessary resources (i.e., time, personnel, funds, research, education, etc.)

to complete their assignments in an effective and timely manner. The Project

Manager must either have direct authority to make these assignments, or at least

have the authority to meet with other agency staff who control these resources to

make the assignments.

• Understand and embrace the principles of risk management risk management (see Chapter 12). Risk risk management

management will allow Project Team members to assess the challenges and

opportunities of the project from the start and help craft contingency plans to deal

with them effectively. It is important that the Project Manager understand your

commitment to effective risk management and planning.

And, perhaps most importantly:

• Encourage and commit to open lines of communication with the Project Manager Encourage and commit to open lines of communication with the Project Manager. Encourage and commit to open lines of communication with the Project Manager

It is critical that the Project Manager be able to openly and honestly discuss the

project, its status, challenges and opportunities with the Executive Sponsor and the

Steering Committee. You should provide an open, comfortable forum for discussing the project, its progress and obstacles on a regular basis. Projects invariably slip

in deadline and sometimes budget, and always experience challenges and difficulties. It is critical that when these challenges occur, the Project Manager is able to

openly communicate issues with members of the decisionmaking structure and

agency leadership. This will allow appropriate and immediate corrective actions to

take place to avoid the project spiraling out of control.

○○○○○○○○○○○○○○○○○○○ ○○○○○○○○○○○○○○○○○○○○○○○

Daunted by the task of finding a Project Manager who has law enforcement, IT and

project management experience?

It’s true, finding a single individual with all of these skills is a challenge. If you can’t

assign or hire a person with all three of these skills, an individual with solid project

management experience is preferred, as he or she will most likely be capable of seeking

out good technology advice while helping craft a solution that meets the business

needs of the agency . That, many say, is more important than someone with a great

deal of technical experience who has little understanding of the business needs of the

law enforcement agency.

Roles Played by

Project Manager

• Task master

• Coach

• Cheerleader

• Social Worker

• Advocate

• Defender

—Taken from A

Practitioner’s Guide to

Managing Projects in

the Information Age.

“

”

Every project,

no matter how

complex or

apparently

simple, must

have a single

point of

leadership with

overall

responsibility

and

commensurate

authority, if it

is to have any

hope of success.

— David J. Roberts

SEARCH
CHAPTER 3

DEVELOP A PROJECT CHARTER
Chapter 3:

Develop a Project Charter

A document that contains an IT project description, complete with scope, objectives,

organization and staffing, a decisionmaking structure, the project management

approach and initial resource requirements.

The Charter provides guidance to project staff and team members in planning and

designing a system to meet the guiding vision of the Executive Sponsor and Steering

Committee.

The Project Manager and Steering Committee, with the advice and input of the User

and Technical Committees.

Shortly after the decisionmaking structure is formed and prior to developing the full

Project Plan.

The Charter defines the scope and objectives scope and objectives of the project and is a reference point scope and objectives

by which all activities can be measured to see if they meet the measured vision for the project, vision

as defined by the Executive Sponsor and Steering Committee. It defines what the

project is committed to deliver, a budget for doing so, the human resources

available and the methodology to be followed for project planning and implementation. In short, the Charter defines the rules of engagement rules of engagement for a project. rules of engagement

A Charter puts everyone involved and/or affected by the project on the “same

page.” Leaders, managers, users and supporters of the system have a clear understanding and a reference document to constantly assess the project’s direction. The

Charter is not the Project Plan document. It does, however, form the basis for the

Plan and lays out the strategy and methodology that will be followed in creating

the Plan.

This chapter will outline the components of a Project Charter and help you build

this important first guiding document for your project.

The Project

Charter is a

document that

formally recognizes

the existence of a

project. It should

include: 1) Business

need that the project

was undertaken to

address; and 2) The

product description.

—PMBOK®

What

Why

Who

When
52 Part I: Build the Foundation

A 12-Step Program for Developing the

Charter

When final, the Project Charter will include:

• Business Case Statement

• Background

• Vision Statement

• Scope Statement

• Objectives

• Planning Methodology

• Initial Timelines

• Preliminary Budget

Step 1

Write the Vision Statement

The first order of business for the Steering Committee is to craft a vision statement for

the project. It is a means to garner consensus and buy-in at the very start of the project

from the principal decisionmakers. The vision brings a tangible reality to what the

agency will address with the new system and plays a major role in defining the project

scope and developing realistic project objectives and milestones.

“Vision answers the question: What will success look like?,” says the Alliance for

Nonprofit Management (www.allianceonline.org). “A vision statement should be realistic

and credible, well articulated and easily understood, appropriate, ambitious and

responsive to change. It should orient the group’s energies and serve as a guide to action.

It should be consistent with the organization’s values.”

From the vision statement, the Project Manager, project committees and ad hoc working

groups can drill down deeper to define the project. It will allow these groups to set a

realistic scope for the effort, articulate the problem IT will solve and/or the functionality

it will provide, and the business requirements for doing so.

How do you create a vision statement? The Executive Sponsor and Steering Committee How do you create a vision statement?

should hold a meeting just to develop the vision statement. Brainstorm, encouraging

everyone’s input, and think about these questions:

• How do you want this IT effort to impact your agency?

• What role will this project play in your agency?

“The charter is a

document that

conveys the purpose

and requirements of

the project to the

Project Team — the

‘who,’ ‘what,’ and ‘why’

of the project.”

— The Project

Management Memory

Jogger

A vision is a

guiding image of

success formed in

terms of a

contribution to

society. If a strategic

plan is the “blueprint

for an organization’s

work, then the vision

is the ‘artist’s

rendering’ of the

achievement of that

plan.”

— From “Strategic

Planning FAQs” at

www.allianceonline.

org/faqs.html
53 Chapter 3: Develop a Project Charter

• How do you see business processes changing as a result of the new technology?

• How will things be different when this problem is solved?

• What will success look like?

Each individual should share his/her vision of success with the group. The key will be to

look for commonalities, as well as differences, in vision/ideas.

Project Managers Project Managers: You should facilitate this discussion and help the group explore its Project Managers

individual and collective vision. You should record the results and draft a concise vision

statement to be presented back to the Steering Committee for review, revision and approval.

The vision should be reworked and revised until all members are in agreement. (Note: The

vision can and may evolve throughout a strategic planning process, particularly after what

may be learned in the environmental scan process discussed in Step 3.)

SAMPLE VISION STATEMENT:

To establish and maintain an integrated CAD/RMS that maximizes efficiency of

agency personnel and management, while making complete and accurate

information available on a timely and secure basis, thereby enhancing public and

officer safety.

Step 2

Give the Project a Name

This step is pretty straightforward, we think. The name should be descriptive about the

product to result from this effort (e.g., Integrated CAD/RMS Project), which helps give

the initiative an identity among the stakeholders.

Step 3

Get the Big Picture, Conduct an Environmental

Scan

Now that you have a name and vision statement for your IT initiative, you should conduct

an environmental scan (ES). The ES is simply an initial step in the planning process that

helps the Executive Sponsor, Steering Committee and others on the Project Team gain a

perspective on their initiative. It is the “forest from the trees” exercise that ensures that

the project does not simply become an “island” in the “sea” of other projects.
54 Part I: Build the Foundation

Codes, Rules and Ordinances

At the City and County levels, which codes, rules and ordinances will affect your project and

how? If you are a State-level law enforcement agency that plans to roll out technology to

locals, will these have an impact? In either case, an understanding and compliance with

codes, rules and ordinances will be necessary.

Economy

The economic situation, whether in your jurisdiction, statewide and nationally, will impact

your project in a variety of ways. Will IT professionals be available for hire? Will the cost of

equipment and technology plummet or soar? Will your agency face a staffing shortage, or

will its budget be cut?

Federal and State Legislation

Review both existing and potential Federal and State policies and laws that may impact your

project. Mandates for gathering and sharing information can have a major effect on the

design of your systems. Requirements to collect racial profiling information, for example,

have impacted the types of information and the methods for collecting it in policing

agencies across the country. With the renewed focus on counter-terrorism, new State and

Federal laws are bound to impact law enforcement information gathering and sharing.

Human Resources

Assess the availability of personnel within your agency, as well as those outside your agency,

that will be needed to support system planning and implementation. What are some of the

roadblocks? Are there other major IT projects underway that may impact the ability of

County IT to support your effort (if that is their role)? Does your agency have sufficient IT

staff and/or are those staff sufficiently trained to support new technologies? How will your

staff be impacted by this large project?

Budget and Capital Resources

For most jurisdictions, there is no question: Money is tight. You need to carefully assess the

budget for this project and look at realistic cost comparisons to projects similar to yours in

size and scope. What other monetary resources do you have available for this effort (grants,

donations, etc.)? What are the unique budget issues in your jurisdiction? What are some of

the major capital improvement projects underway and how do they impact this project?

How will long-term maintenance be funded?

Organizational Structure

Particularly from an IT support perspective, you should determine how IT will be managed,

both in planning and implementation and long-term. Does your agency have an in-house IT

staff, or will the City or County IT shop support the system? Perhaps a combination of

both? What is the chain of command for making decisions about IT?

Internal and External Issues to Scan
55 Chapter 3: Develop a Project Charter

Policies and Procedures

Research the published policies and procedures that pertain to your agency. Don’t forget to

also consider business practices that may not be formally prescribed, but that are done out

of historic practice (e.g., “we’ve always done it that way”).

Politics

And we’re not just talking Election Day politics here. We know each agency has its own

internal politics. Don’t forget to take an honest look at how that may affect your project and

its priorities. Also, if City, County, State or agency leadership is changing, it is important to

make every effort to predict whether priorities will shift.

Public Opinion

The public sentiment about crime, technology and policing in general may impact your

project. A formal public opinion poll is probably not necessary; however, you should assess

the climate of public opinion in your jurisdiction related to these issues. Strong public

support is important, particularly if the agency’s IT initiatives require funding such as a

bond referendum.

Stakeholders

As mentioned in Chapter 1, it is important to properly identify those stakeholders who will

be affected by the project and the technology implementation. Now, and as the project

moves forward, continuous assessments should be made to ensure that the right individuals

are involved. As the project progresses, different stakeholders may come into the picture as

different activities take place.

Technology and Standards

What technology is your agency working with now? Does the broader government structure

(City, County or State) have IT standards with which you must comply? Where is technology going in general? How will this impact what you may be able to do in the future? What

technologies are other law enforcement agencies testing at this time? Is the proposed

technology proven reliable or leading edge? These are some of the questions you should be

asking during this assessment.

Regional Decisions

Assess what other public safety and justice agencies in your region are doing. For example, if

your agency is interested in sharing information with law enforcement agencies in

neighboring jurisdictions, you should determine whether those agencies have made specific

decisions that may impact your project. Have they developed strategic plans for their IT

initiatives? What technologies are they pursuing? Is there a justice information system

integration initiative underway at the City, County or State level?
56 Part I: Build the Foundation

The ES allows you to systematically assess factors that present opportunities for improving the success of, or that present major obstacles to, the project. It requires a continuous

gathering and analysis of internal and external data available to an organization from a gathering and analysis of internal and external data

variety of sources. (See the chart on pages 54-55 for typical issues to scan.)

Sometimes referred to as a situation or “SWOT” assessment, an ES contains the

following:

• An internal scan that identifies the strengths (S) strengths (S) and strengths (S) weaknesses (W) of the agency. weaknesses (W

• An external scan that identifies external opportunities (O) opportunities (O) and opportunities (O) threats (T) threats (T) to the threats (T) 

agency.

Some of the results from the ES will be specifically outlined in the Charter, while other

results will help to craft components of the Charter and the Project Plan. In any case, the

ES helps identify emerging issues that will be of strategic importance during the life of the

project and help the Project Team identify potential opportunities and threats, and craft

appropriate responses to both.

Step 4

Build the Business Case

One of the key tasks in project planning is to educate current, future and other potential

stakeholders about the benefits and payoffs of the new IT system. Even if all the stakeholders seem to support the idea, it is still critical to articulate the need and state the

benefits of the new system. Building a business case that clearly justifies the project is benefits of the new system

critical for the Project Team, those who will be affected by the end product, and key

policymakers and funding entities. Think of the business case as your project’s marketing

plan.

The business case should be built on two tracks:

1) to address issues pertaining to direct users of the system, and

2) to address issues essential to funding and other decisionmaking bodies.

So, how do you build the business case? As a Project Manager, think about how you So, how do you build the business case?

would justify a large commitment of money and resources in technology to your Chief/

Sheriff. What would you say to convince him/her of this project’s importance? How will

you convince the users of the new system that the initiative is important for them? What

would you say to the patrol officer who will be using new laptop computers, for example,

to create reports in the field?

Executive Sponsors Executive Sponsors: You will most likely have to appear before a funding agency or Executive Sponsors

policymaking body that will ask why it should support and fund this project (particularly in

light of other competing government priorities). What will you say?

“A well-crafted

business case is a

powerful

communication tool

that can increase

support for the effort.”

— From And Justice

For All: Designing

Your Business Case

for Integrating Justice

Information
57 Chapter 3: Develop a Project Charter

A strong argument should be crafted in terms of operational benefits to the agency and

public. So for the benefit of direct users of the system and the Executive Sponsor, for

example, you may want to discuss broadly how implementing IT results in myriad

benefits, such as:

• More accurate and complete data available in a more timely fashion.

• Reduction of redundant data entry, which leads to greater efficiency and accuracy.

• Significant reduction of paper documents.

• Better decisionmaking by officers in the field, detectives investigating a crime and

management in allocating resources.

• More complete, accurate, timely and accessible information will improve reporting

and trend analysis, streamline data processing and workflow, and will ultimately

enhance public and officer safety.

Users of the system will want to know how it will make them more efficient and effective,

and how they can work better and faster. For example, you may explain how the new

integrated system will automatically provide officers with call for service information and

incident and arrest history, as well as any alerts for a particular address while the officer

is en route to the call (without having to initiate a query).

If you are pursuing a new automated field reporting system, you may want to extol the

virtues of the system’s built-in edit checks that will allow officers to accurately fill out

reports. Drop-down menus, spell check and automatically-populated fields will make an

officer much more efficient in report generation. Explain how reports prepared on

laptops in the field are generally more accurate (no need to translate officer handwriting)

and are available much more quickly than a paper form that is returned to the records

bureau for data entry. Officers can also benefit from the automated systems’ ability to

identify suspects, crime patterns and potential crime problems much more quickly than

manual systems, and at an earlier stage, allowing a proactive approach to policing.

Obviously, there will be other unique benefits in your agency or jurisdiction that you will

want to highlight in the business case.

Funding bodies and policymakers will want to know how public safety will be improved,

and how agencies will leverage existing technology investments and work with other

agencies to maximize technology investments (i.e., police designing systems to share

information with fire, courts and other justice agencies).

Other business case builders include unfortunate, yet powerful, anecdotes of human loss

and tragedy that could have been avoided or averted due to technology availability.

In preparing the

business case, make

sure to account for

expenditures and

investments already

made in existing or

“legacy” technologies

and the benefits

realized from those

systems. Also

describe how those

investments will be

leveraged in the new

effort.

The business case

articulates why the

project is important in

terms of operational

benefits to the agency,

the justice system in

general and the

public, which

ultimately results in

the enhanced

administration of

justice and increased

public safety.
58 Part I: Build the Foundation

Step 5

Include Background or Historical Information, if

Relevant

If information is available about the results of previous project activities and the decisions made and lessons learned, include this in the Charter. It can also be useful to

document the major reasons for past project failure to avoid the same mistakes in the

future. Similarly, include information on approaches that have been successful.

Step 6

Establish the Project Scope

A written scope provides a basis for developing, articulating and confirming a common

understanding of project scope among the stakeholders. Scope clearly defines the

boundaries of the project boundaries of the project. Defining scope also identifies which activities are “in” the boundaries of the project

project and which activities are excluded.

Scope addresses:

• What users want (functions). What

• How well the user requirements are met (quality of ). How

• When and how it must be developed (constraints). When

• Why (the value in the project). Why

At this stage, scope should be defined in a

relatively concise statement. Later, during the

Project Plan development, scope will be fleshed

out in very specific detail by the User Committee

and the Project Manager (see Chapter 9).

We will introduce the concept of the scope-time- scope-timecost triangle here. As you are developing scope, cost triangle

both initially for the Charter and later in more

detail for the Project Plan, keep in mind that

“Scope: The first

phase of the project

where the who, what,

where, why, when and

how are determined at

a very high level.”

— IT Professional’s

Guide to Project

Management

Discuss alternative solutions to the problem. Building a strong business

case means that you have also considered other potential solutions to the

problem but ruled them out for one reason or another. The business case

for this project will be stronger if decisionmakers see the justification for

the proposed project compared to alternative solutions.
59 Chapter 3: Develop a Project Charter

should any one of the three “triangle” components grow, there is a direct effect on the

other “corners” of the triangle. Thus, as scope “grows,” so does the cost of the project and

its scheduled completion time.

Step 7

Establish Preliminary Project Objectives

The User Committee should spend some time developing preliminary project objectives

for the Charter. Objectives break down scope to the next level of detail. Objective

statements should be quantifiable in terms of time, money and technical quality that the

project must achieve to be considered successful. These will be further detailed and

explored during the needs assessment (Chapter 5) and developed more fully in the full

Project Plan.

Step 8

Note Major Project Assumptions and Constraints

Assumptions and constraints are circumstances and events that can affect the success of

the project and are generally out of the control of the Project Team. Many of these issues

will be explored during the ES. Those with high likelihood of occurring should be listed

in the Charter. For example, a constraint may be that there will not be ample or additional funding for hiring new or additional IT staff to support the project. An assumption

for an RMS project, for example, may be that the current CAD will not be replaced and

must remain operational for two more years.

Listing these assumptions will provide assistance in making decisions and, in some cases,

justifying those project decisions.

Step 9

Develop Initial Timelines and Preliminary Budget

Based on the scope of the project, it is useful in the Charter to articulate some general

timeframes and deadlines for the full project, as well as broad timelines for major

milestones and deliverables. These timetables will be honed and detailed in the full

Project Plan.

Be careful what you

promise IT will do ...

Many agencies have

over-promised returns

on investments in

technology, only to

have to explain later

why these

expectations have not

been met. Make sure

to back up arguments

by providing empirical

research and

examples based on

research and

statistics.
60 Part I: Build the Foundation

Step 10

Include Project Planning Methodology

The Charter should include a discussion of the major project planning tasks that will take

place, such as conducting a needs assessment, developing a requirements definition,

doing a risk assessment, completing budget estimates and developing the full Project

Plan. This will give all stakeholders an outline and order for project planning tasks.

Step 11

Provide Project Team Organizational Chart and

Membership Roster

The project planning structure is important to detail in the Charter. Obviously, not all

agency users of the system can participate on the planning team, but through an

organizational chart and roster, they can see those who are representing them. Those not

on the team, but interested in contacting members to provide input or comments about

the project, can do so.

Step 12

Sign, Seal and Deliver

That’s right, the Charter should be signed! The Executive Sponsor and members of the

Steering Committee should sign the finished document. The Project Manager should

distribute the Charter to anyone who has a stake in the project.

What’s Next?

Assess Current Systems and Processes .............................................. Chapter 4

Conduct Interviews and Focus Groups .............................................. Chapter 5

Identify General System Requirements ............................................. Chapter 6

Make the “Build or Buy” Decision ..................................................... Chapter 7

It is important to have

buy-in up front from

the Chief to the users,

and you do this with

an aggressive

marketing plan.

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○
Part I Assignments 61

EXECUTIVE SPONSOR

Role 1. Ultimate decisionmaker

2. Provide oversight and guidance

3. Align project priorities with parent organization

4. Resolve management issues

5. Commit human and financial resources

Build the 1. Make sure your agency has a strategic business plan in

 Foundation Tasks place (Seven Facts You Should Know, page 15)

2. Commit to the project (Chapter 1, page 23)

3. Appoint the Steering Committee (Chapter 1, page 28)

STEERING COMMITTEE

Role 1. Allocate resources

2. Provide knowledge and recommendations

3. Remove project barriers

4. Update/inform Executive Sponsor

Build the 1. Assign staff to User and Technical Committees

 Foundation Tasks (Chapter 1, pages 29, 31)

2. Assign/hire Project Manager (Chapter 2)

3. Adopt a vision for the initiative (Chapter 3, page 52)

PROJECT MANAGER

Role 1. Manage project (e.g., activities, deliverables, schedule)

2. Provide overall project direction

3. Single point of contact with vendors

4. Direct/lead team members toward project objectives

5. Review and approve project deliverables

6. Handle problem resolution

7. Update/inform Steering Committee

Build the 1. Develop meeting schedule and agendas

Foundation Tasks (Chapter 1, page 35)

2. Facilitate Steering and User Committees in developing a

Project Charter (Chapter 3)

3. Conduct an environmental scan (Chapter 3, page 53)

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

PART I ASSIGNMENTS
62 Part I: Build the Foundation

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

PART I ASSIGNMENTS, CONTINUED

USER COMMITTEE

Role 1. Business experts who will analyze and document existing

business processes and develop new processes for

information flow and management within the agency

2. Provide input to the Steering and Technical Committees

Build the 1. Assist in developing the Project Charter (Chapter 3)

Foundation Tasks 2. Build the business case (Chapter 3, page 56)

3. At the direction of the Project Manager, begin developing

project scope (Chapter 3, page 58)

4. Advise/inform Steering Committee

TECHNICAL COMMITTEE

Role 1. Review existing technologies

2. Make recommendations about new technology based on

business needs, as defined by the User Committee

Build the 1. Form Committee (Chapter 1, page 31)

Foundation Tasks 2. Include IT staff from parent organization, if appropriate

(Chapter 1, page 31)

3. Assist in developing the Project Charter (Chapter 3)
“If you don’t know where you want to get

to...it doesn’t matter which way you go!”

— Lewis Carroll, Through the Looking Glass

Part II:

Conduct a

Needs Analysis
CHAPTER 4

ASSESS CURRENT BUSINESS PROCESSES
Chapter 4:

Assess Current Business Processes

An objective assessment of how your agency does business today with a focus on

improving efficiency and effectiveness.

Technology acquisition must be driven by business objectives. Documenting current must

business processes and identifying how they can be improved establishes the starting

point of a conceptual system design.

The Project Manager is responsible for coordinating the tasks within this chapter. The

User Committee and other select employees will be involved in defining business

processes, while the Technical Committee will assist with defining the current

technology environment. All project participants may take part in identifying

opportunities for improvement.

After the project’s decisionmaking structure and Project Charter are in place, and

simultaneously with the development of the Project Plan, but before any decision is

made regarding technology procurement.

In Part I, you learned about the importance of preparing a Project Charter, which

defined your project’s scope in very broad terms. In this chapter, we’ll discuss how

you can begin gathering information that will help refine those broad terms into a

conceptual design. Specifically, this chapter is designed to help you gather the

following information:

1. What are your organization’s current “business processes?”

2. What technology does your agency have in place today?

3. How does your agency use its technology to accomplish business objectives?

4. Are there opportunities for improvement both with and without the use of

technology?

In addition to serving as the starting point for determining technology needs,

conducting a thorough business process analysis will yield many ancillary benefits.

Agencies that have taken these steps routinely report the discovery of antiquated

policies, old habits and other obsolete practices that give way to newfound

efficiencies and improvements, many of which are unrelated to technology!

In order to define how your organization uses technology to accomplish its business

objectives, you must define both your current business processes and technology

environment.

What

Why

Who

When
68 Part II: Conduct a Needs Analysis

Define the Organization’s Business

Processes

Just about everyone has used or seen a map (especially in law enforcement!). The purpose

of a map, of course, is to provide perspective and direction: two key elements that guide

people and prevent them from getting lost. Business process mapping seeks to do the

same thing by helping to “map out” how people, information and paperwork travel

through your organization.

So, what is a business process? It’s nothing more than a written description of the things

that employees do every day. While business processes are simple enough to define, their

importance in determining the technical approach cannot be overstated; business

processes are at the center of all successful technology initiatives, as they are what

technology seeks to enhance or improve. Here’s an example of a common business

process:

While booking a prisoner, the jailer completes form X. The original is placed in the

records “in-box,” copy 1 is given to the arresting officer, and copy 2 goes into the

prisoner’s property bag.

Project Managers Project Managers: You probably have a solid understanding of the major business processes Project Managers

in your organization (after all, most police departments have only slightly more than a

dozen major processes). Despite your general knowledge, the focus of this chapter requires

the participation of employees who specialize in various processes. As the Project Manager,

you will be responsible for coordinating and facilitating Steps 1 and 2.

The following three steps are designed to enable the Project Manager to effectively guide

the User Committee through documentation of the existing business processes.

Step 1

Review User Committee Membership, Augment if

Necessary

Review your User Committee members and be sure that they adequately represent all of

the major business areas of your agency, supplementing the committee with new

members, if necessary. Remember, you’ll be relying on these people to define how

business is done, so they need to be thoroughly familiar with their own assignments, as

well as understand how their area of expertise relates to the organization as a whole.
69 Chapter 4: Assess Current Business Processes

This is a relatively

simple task that is

often met with

confusion, as

participants tend to

“overthink” their

assignment. So, the

rule here is: KEEP IT

SIMPLE!

Step 2

Put the User Committee to Work!

The next step will be to convene the User Committee and request that they define and

categorize their business processes. The Committee should be tasked with defining each

specific process, and then breaking the process down into subprocess and then further

into activity, each concept drilling down a bit more than its predecessor as to the “who,

what, where, when, why and how” involved in a particular process.

Review the following examples that break down two common business processes — filing

a report and booking a suspect:

“The trick to defining

your needs is to

describe what you

want to do with

technology, not what

you think you need to

buy.”

— From The Planning

Process: Define Your

Needs, by Anna Mills,

www.techsoup.org

FILING A REPORT

PROCESS

SUBPROCESS

ACTIVITY

The greatest level of detail, describing who does what,

when they do it and how much they do

Example: The on-duty watch commander delivers an average of

12 approved reports to the records bureau at least 20 times each

day

A greater level of detail, describing who does what and when

Example: The on-duty watch commander delivers approved reports

to the records bureau every hour

The highest level for process mapping purposes

Example: The records bureau processes reports from patrol
70 Part II: Conduct a Needs Analysis

With the basics defined, it’s time for the Project Manager to assemble the User Committee and start the process by asking each participant to identify as many processes,

subprocesses and activities as possible. The Committee should review the above examples to clarify the concept.

Step 3

Get It in Writing

Once each of the participants has completed his or her assignment, the Project Manager

should reconvene the group. The purpose of this meeting is to allow the participants to

share their defined processes with the rest of the group in an effort to refine and clarify

the organization’s business processes.

Most departments

cannot obligate an

employee to do

business process

mapping full-time.

Therefore, be sure to

allocate a substantial

amount of time for

participants to

conduct this

assignment (3 or 4

weeks is usually

required).

BOOKING A SUSPECT

PROCESS

SUBPROCESS

ACTIVITY

The greatest level of detail, describing who does what,

when they do it and how much they do

Example: Within 30 minutes of arriving at the jail, the arresting

officer must complete forms 811, 836 and 122 prior to leaving

A greater level of detail, describing who does what and when

Example: Upon arrival at the jail, the arresting officer must book his/her suspect

The highest level for process mapping purposes

Example: Patrol books suspects into jail
71 Chapter 4: Assess Current Business Processes

Project Managers Project Managers: Business process mapping is often outsourced by police agencies because Project Managers

internal assessments can be met with resistance, and challenging long-standing beliefs is

often discouraged. As the Project Manager, you must recognize that such bias may exist and

encourage participants to openly identify inefficient or ineffective operations.

During the meeting, participants should literally draw out their processes, subprocesses

and activities on large sheets of paper, and spread them out across a large table (butcher

paper is great for this assignment), with each participant using a different colored ink

pen. To illustrate what a simple process should look like, review the following, which

describes the simple process of relaying briefing information at the start of a shift:

We suggest convening

the meeting in a room

with ample free table

and wall space. Also,

these meetings

usually require a full

day, so plan ahead!

DISPATCH

SERGEANT

WATCH 3

OFFICER

WATCH 3

OFFICER

WATCH 3

OFFICER
72 Part II: Conduct a Needs Analysis

Project Managers Project Managers: During this step, you will serve as the meeting facilitator. As such, you Project Managers

must encourage participants to work with each other in terms of showing how related

processes overlap. As an example, ask a dispatch representative to work with the patrol

representative in drawing the relationship between dispatch assigning calls for service and

patrol responding to them.

At the conclusion of the day’s meeting, the Project Manager should hang the drawings

around the room (if adequate wall space is available) and invite all Project Team members to visit the room during their shifts to review the newly formed business process

maps for supplemental information.

After about a week (or whenever a day goes by without new comments), the Project

Manager should carefully document the newly defined processes in a Business Process Business Process

Baseline report. Most business process mapping professionals use a software application Baseline

like Microsoft Corp.’s Visio to translate written work descriptions into an electronic

format; however, clear hand drawings are perfectly acceptable and require far less time to

prepare.

The report signals the conclusion of documenting the organization’s business processes.

You will use this document throughout the remainder of Part II as reference for understanding how the organization currently accomplishes its business objectives.

Executive Sponsors Executive Sponsors: Be ready for resistance to business process mapping. It is strikingly Executive Sponsors

similar to an organizational “time and motion” study, which sometimes leads to the

elimination of jobs by revealing inefficiencies. To mitigate the issue, meet with union

representatives and other leaders prior to authorizing the study. You should explain that

business mapping is designed to reveal new opportunities for advancing the organization’s

efficiency and effectiveness through the use of technology. The net benefit and goal is to

improve officer safety, not eliminate jobs.

Define the Current Technology Environment

Before your agency can determine what technology is required, it must identify what it

has today. In terms of identifying critical information, the Project Manager should rely

upon the Technical Committee (and/or City/County Chief Information Officer) to supply

a written description of the existing technology and infrastructure, including:

• Description of manual and automated information systems.

• Listing of computer systems and networks.

• Identification of databases that are accessible.

• Description of volumes of transactions.
73 Chapter 4: Assess Current Business Processes

• Identification of existing configuration for CAD/RMS/Mobile applications.

• Relationship between applications, including CAD, RMS, Jail, Court, Substations,

Fire, GIS, etc.

Technical Experts Technical Experts: In the event your project will rely upon mobile data devices, you will Technical Experts

also need to gather information on the existing radio technology, including:

• A description of existing facilities and their ability to support mobile applications

and report writing.

• Availability of bandwidth.

• Type of infrastructure (radio, cellular, etc.).

Place all of the compiled information into a Technology Baseline report, thus concluding Technology Baseline

the process of documenting the existing technology. You will use this document as the

basis for the following:

1. Identifying how current technology is used to accomplish business objectives in the

following section.

2. Determining how business processes could become more efficient or effective

through the introduction of new technology (how the application of new technology can help streamline and improve processing can be discussed during stakeholder interviews/Focus Group meetings, which are addressed in Chapter 5).

3. The written summary of the existing technology environment in any procurement

documents (vendors will want to know what exists today).

Define How Technology is Used to

Accomplish Business Processes

Armed with descriptions of the current business and technology environments, as

spelled out in the Business Process Baseline and Business Process Baseline Technology Baseline reports, it’s time to Technology Baseline

overlap the two reports, seeking to identify how the existing technology is used to

accomplish the agency’s business processes. You should take this opportunity to carefully

review the agency business processes to determine where inefficiencies or bottlenecks

currently exist that prevent the agency from reaching its established business goals. This

is the perfect time to consider reengineering or changing processes to streamline

workflow if you do identify less-than-optimum workflow procedures.

For example, consider how computers are used to receive, dispatch and monitor calls for

service, including telephone devices, enhanced 911 interfaces, CAD applications, wireless

infrastructure, etc. Or, seek to identify the technology that is used when booking a

prisoner (i.e., digital cameras, LiveScan devices, etc.).
74 Part II: Conduct a Needs Analysis

Project Managers Project Managers: Facilitate a meeting of the User and Technical Committees. During the Project Managers

meeting, ask participants to identify how the technology described in the Technology

Baseline report is used in each process defined in the Baseline Business Process Baseline report. For Business Process Baseline

example, ask dispatchers to explain how an existing CAD is used (or not used) to accomplish

various processes, subprocesses and activities described by dispatch, patrol, records and

other participants. Update the Business Process Baseline report to include the newly Business Process Baseline

defined use of technology. The resulting document will be used throughout the balance of

Part II as a “snapshot” of the organization’s current environment.

Find Room for Improvement

The Business Process Baseline report now includes not only the current business Business Process Baseline

processes, but also a summary of how existing technology is employed.

The document is an invaluable tool for examining methods to improve service delivery,

efficiency and overall effectiveness. The Steering Committee should seize the opportunity

to review the content of the report by recruiting as many internal and external stakeholders as possible.

The completed report should be disseminated to each key project stakeholder with a

request to identify methods for improvement both today and in the future, with the use

of new manual or automated processes.

Once the report is returned by the stakeholders, the Steering Committee should ask the

Project Manager to collect and compile the recommendations, which should summarize

the following:

• The identification of current manual business processes that could be improved

through the use of existing technology.

• The identification of current manual business processes that could be improved

through the use of future technology, identifying the major technology categories

associated with the recommendation (i.e., CAD, RMS, Mobile, Automated Field

Reporting (AFR), Jail Management Systems (JMS), etc.).

• Current business processes that are likely to change as a consequence of implementing new technology.

• The identification of specific technology that may be gained, lost or modified as a

consequence of business process improvements.

• The identification of efficiency gains and other benefits (including new functionality) likely to be achieved as a consequence of changing business processes.
75 Chapter 4: Assess Current Business Processes

Once complete, the report should be returned to the Steering Committee for a thorough

review that would focus on the following:

• What (if any) suggestions for improvement should your organization enact?

• How does the organization benefit from implementing new manual or automated

processes?

• Is the organization ready for change?

• What collateral issues would be impacted by changing any operations?

The decisions that stem from such a review not only improve the health and growth of

the organization, but also define the purpose of any technology initiative(s).
CHAPTER 5

DETERMINE STAKEHOLDER AND USER

NEEDS
Chapter 5:

Determine Stakeholder and

User Needs

Project success depends on user and stakeholder input. There are various methods for

getting key project stakeholders involved in expressing their needs for a new IT system

and their views on organizational change that may be caused by a new system.

To reach out to as many people who are impacted by your project as possible to make

sure all stakeholders have a voice and an opportunity to provide input. The more

input, the more likely your project will be a success.

The Project Manager will be primarily responsible for meeting with virtually all

project stakeholders.

Shortly after documenting your business processes and current technology

environment.

In the simplest terms, this chapter offers techniques for soliciting ideas from

project participants about what they need to make their daily work more efficient,

their “wish list” for new and improved methods of accessing and using information, and to encourage them to “look outside the box” at the potential enhancements IT can offer them. While that may seem like an easy task, it is actually one of

the most difficult — especially when one has to interview dozens or hundreds of

people!

This chapter is designed to capitalize on the Project Manager’s communication

skills by relaying best practices for conducting interviews and Focus Groups within

law enforcement organizations. It offers techniques to determine the best forum

for eliciting feedback from stakeholders, as well as what to say during the meetings

and how to record the findings.

Project Managers Project Managers: We assume that you will be responsible for conducting the interviews and Project Managers

Focus Groups discussed throughout this Chapter.

During this phase, you will gather information that will ultimately help craft the general

hardware, software and interface requirements of any new system(s). The need to collect

feedback from the people who will ultimately use the system is critical. Equally important

is the method by which their feedback is sought and obtained.

What

Why

Who

When
80 Part II: Conduct a Needs Analysis

The Project Manager will meet with a variety of project participants, including key

stakeholders and committee members. Determining the best approach for gathering

information is usually based upon the size of the Project Team and the nature of the

initiative. However, a mix of individual interviews and Focus Groups is almost always

required.

To help determine when to use individual interviews versus Focus Group techniques, we

have assembled the following guidelines:

Note: How to

develop the more

detailed functional

requirements and

specifications

necessary for

procurement

documents is

addressed in

Part IV, Acquire

the Technology. Interview Technique

Interviewee Individual Interviews Focus Groups Explanation

Administrators (including

Executive Sponsor and

Steering Committee)

X

Administrators, by their

rank, can inhibit the

communication process

and should be

interviewed individually

rather than participate in

Focus Groups.

User and Technical

Committees

X e When five or mor

people share a common

area of knowledge, it is

best to interview them as

a group, rather than

individually. Based upon

the scope of your

project, it is possible to

have many Focus

Groups emerge from the

User and Technical

Committees.

External Stakeholders

(e.g., County officials,

funding bodies, other

justice agency

representatives, etc.)

X By their nature,

stakeholders (both

internal and external)

possess unique

knowledge and are not

generally interviewed as

a group.

Subject Matter Experts

(i.e., individuals needed

for a specific component

of the project, such as

an expert on the

message switch)

X s These participant

possess unique and

specific knowledge that

would not be well suited

to a Focus Group format.
Chapter 5: Determine Stakeholder and User Needs 81

User participation is one of the critical success factors in any law enforcement technology

initiative. The more users who contribute to the system’s design, the more successful the

project will be!

Project Managers Project Managers: User involvement in law enforcement initiatives is often stymied by Project Managers

chain-of-command and shift barriers. You must overcome such obstacles if your project is to

be a success. Approach the Steering Committee and request assistance in making various

employees, or groups of employees, available for interviews or Focus Groups. If necessary,

arrange for meetings with employees during hours that are beyond your usual work shift.

Most importantly, be creative in reaching out to your stakeholders — they won’t reach out

to you! If you want your project to be a success, you need to go out of your way to solicit

their input.

Executive Sponsors Executive Sponsors: Project Managers are often frustrated with their inability to access key Executive Sponsors

personnel due to shift work or chain-of-command barriers. As the Executive Sponsor, you

may be relied upon to flex employee schedules or to temporarily waive existing chain-ofcommand structures in order to foster communications. We suggest that you speak to your

Project Manager during this phase and ask if you can be of assistance (subordinates are

often reluctant to go to the Chief or Sheriff for assistance).

Individual Interview Techniques

As the design of your agency’s new technology initiative starts to take shape, you must

interview key stakeholders to identify their priorities and aspirations for the new

technology. Generally, these meetings require approximately 1 hour and should be

conducted in an environment and at a time that is convenient for the interview subject.

While interviews are fairly straightforward, advance planning will vastly improve the

quality of information you collect. Therefore, we recommend that the interviewer

provide the following information to participants, at least a week prior to the interview:

1. A Brief Introduction: Provide subjects with an overview of the interview purpose A Brief Introduction

and a copy of the Project Charter. For example:

We plan to replace the existing records management system and this interview

will mark the beginning of the system design. The interview will give you a

chance to speak with the Project Manager about your opinions and goals for the

new project.

2. A Summary of Responsibilities A Summary of Responsibilities: Always let participants know what is expected of A Summary of Responsibilities

them. Few things are more uncomfortable than interviewing someone who hasn’t

prepared for an interview. We suggest providing the participant with some advice

on how to prepare for the interview, such as:
82 Part II: Conduct a Needs Analysis

During the interview, you will be asked to discuss your needs as they pertain to our

planned new records management system. You should be prepared to respond to

the following questions:

• What are the functions and responsibilities of your current assignment?

• What information systems do you use in your work (e.g., CAD/RMS, etc.)?

— computer hardware and software used

— manual methods used

— analysis and reporting performed

— connectivity to outside agencies (e.g., interfaces)

• What are the strengths and weaknesses of the technology you are using?

• To what degree are the manual systems meeting your needs?

• What are your ideas for improving current operations?

• Are there other systems issues that we should be aware of?

• What new technologies have you seen or heard about?

3. A “What-To-Bring” List A “What-To-Bring” List: Interview participants may prepare for meetings by A “What-To-Bring” List

jotting down notes or collecting forms. Rather than rewriting this information, ask

participants to bring copies of their “wish lists” and other documents that they

want to talk about during the meeting.

At the conclusion of the interview, be sure to thank the participant and carefully organize

any notes taken. (This is especially valid when conducting dozens or hundreds of

interviews.)

Focus Group Techniques

Focus Groups are a somewhat informal technique that can help to assess user needs while

designing the system. In a Focus Group, bring together six to nine users to discuss issues

and concerns about the features of the new system. Focus Group sessions typically last

about 2 hours and are run by a moderator who maintains the Group’s focus. We assume

that the Project Manager will moderate the Focus Groups for the technology initiative.
Chapter 5: Determine Stakeholder and User Needs 83

FOCUS GROUP FORMATS

There are two general Focus Group formats: SWOT and Traditional. Generally, a SWOT

format is used when asking users to plan for replacement systems, while a Traditional

format is preferable when introducing entirely new technology.

SWOT Focus Groups

The SWOT format is an effective tool for identifying the SWOT Strengths Strengths and Strengths Weaknesses Weaknesses of Weaknesses

existing systems, as well as for defining the Opportunities Opportunities and Opportunities Threats Threats presented by the Threats

initiative. The following techniques are similar to those presented in developing the

broader environmental scan, discussed in Chapter 3.

Facilitating the SWOT format is simple and the outcome of the process will provide

valuable information on what to include and exclude in the conceptual design of your

new technology.

To conduct a SWOT analysis:

1. Gather a group of users from within a particular functional area to talk about a

specific aspect of the current environment (i.e., dispatchers to talk about CAD).

2. Provide them with relevant sections from the Business Process Baseline report Business Process Baseline

(described in Chapter 4) at least a week in advance of the Focus Group meeting.

3. Advise participants to familiarize themselves with both the current business

processes, as well as the current technology presented in the report.

Project Managers Project Managers: Remember that facilitating Focus Groups requires advance research and Project Managers

knowledge. You must be sufficiently knowledgeable about both the business of the law

enforcement agency and the technology (both what is existing in your agency and what is

available in the industry) if you are to push the conversation forward and elicit substantive

input from attendees. Bringing in outside experts for input and assistance in facilitating

these groups can often be of great benefit.

During the Focus Group session, pose the following questions to attendees and write

down their responses on a flip chart. Feel free to use as many sheets as necessary. When a

page is full, tape or tack it to the wall, so that the group can continue to view the information as new topics are discussed.

• What are the Strengths Strengths of the current technology? Strengths

Encourage honesty in this exercise, as participants should feel free to express their

own opinions, not those of the group. The moderator should be scanning

Think SWOT!

STRENGTHS

WEAKNESSES

OPPORTUNITIES

THREATS
84 Part II: Conduct a Needs Analysis

participant answers for key elements that must be retained in the new technology.

It may be necessary to occasionally remind users of any inherent strengths of the

existing system, such as its stability, existing knowledge base or years of

customizing it to perfect its capabilities.

• What are the Weaknesses Weaknesses of the current technology? Weaknesses

Usually, this question produces a lengthy list. Try to extract very specific elements

from broad answers. For example, if an attendee says, “the current system is too

slow,” the moderator should probe by asking, “What do you mean?” Or, “When do

you notice that the system is slow?” These are important elements to consider in

designing the new system.

• What Opportunities Opportunities for improvement exist? Opportunities

The moderator should point out to the attendees the relevant portions of the

Business Process Baseline report that identify current business processes and Business Process Baseline

technology. The moderator should then ask the attendees to identify what

opportunities exist for improving the current business processes and technology to

better support the business goals of the organization. Their responses will define

the focus of the technology initiative. After all, if there are no benefits to be had by

introducing new technology, then why even consider it? Try to identify specific

modules and functionality that should be improved. The participants should be

encouraged to cast aside their assumptions about “the way things are done around

here” and state what, in a perfect world, they hope to accomplish through the

project.

Project Managers Project Managers: Remember that attendees may not know what Project Managers

opportunities exist unless they have somehow been exposed to vendor

products or external agencies. Consequently, you may find yourself

educating attendees on the types of functionality afforded by modern

applications and then inquiring about how the users would view such a

transition.

• What Threats Threats will emerge from this process? Threats

Participants should identify the major obstacles and risks to a successful project.

This is often a difficult question that can require you to coax responses from them.

Suggest to the participants some sample answers, such as, “What about funding?”

The goal is to gain insight into the barriers that need to be avoided while managing

this project.

After the participants have provided all of their answers, these should be listed on several

sheets of flip chart paper and hung on the walls around the room. Some of those pages

might look like the following, which is taken from a Dispatcher Focus Group that talked

about its CAD system:

Regardless of the

Focus Group

approach you choose,

both require that the

moderator take

copious notes. If you

have the resources

available, use a notetaker who is objective

and nonthreatening to

the group (such as a

cadet or, perhaps, an

assistant from your

parent organization).

As you will learn, the

moderator is often

busy speaking with

participants.

Interrupting a Focus

Group meeting to take

notes can be

distracting to the

process.
Chapter 5: Determine Stakeholder and User Needs 85

DISPATCHER FOCUS GROUP

Strengths of Current CAD:

Everyone is Proficient

Easy to Use

Weaknesses of Current CAD:

System is slow

System fails about twice/year

Can’t get statistics from CAD

Alarm billing maintained manually

Can’t send calls to MDTs

Can’t retrieve RMS information

Duplicate NCIC data entry

Opportunities for Improvement:

Make it faster

Make it more reliable

CAD could give us statistics

Let CAD do alarm billing for us

Connect CAD to MDTs and RMS

Enter NCIC data one time only

Threats to Success:

Might be too expensive

Training must be adequate
86 Part II: Conduct a Needs Analysis

At this point, the moderator should ask the participants to indicate the three most

important responses for each question. Based on our experience, the easiest way to

accomplish this task is to provide each attendee with several red, yellow and green

stickers.

For each of the four questions, participants individually place a red sticker next to the

issue that they feel is the most important, followed by a yellow sticker for the second

most important and, finally, the green sticker for the third most important issue.

Once your participants have completed their prioritization, take some time to review the

findings and ask the group if there are any surprises. You should attempt to foster

discussion on unanticipated findings, seeking to reveal even more information that will

be useful in designing the new system.

Traditional Focus Groups

If your agency is introducing entirely new technology (such as an RMS, where there is

none presently), it may be more useful to approach users in a Traditional Focus Group

environment.

Like the SWOT format, the moderator will assemble a small group of users who are

knowledgeable about a particular subject area (i.e., detectives, patrol, etc.) to discuss the

concept of new technology and ask for feedback regarding the design.

During these sessions, the moderator generally starts the meeting by describing how the

participant’s specific area of knowledge is commonly impacted by new technology. For

example, during a meeting with a group of property/evidence technicians, the moderator

would want to describe how most modern RMS applications allow officers to create

printed barcode labels that can be affixed directly to articles during the booking process.

Then, as the technicians receive the items, they simply use an RMS barcode reader to

scan the items, which would retrieve all of the data related to that item and, in some

cases, conduct national and local database inquiries and updates automatically.

The moderator should use the Business Process Baseline report and ask the Focus Group Business Process Baseline

participants to envision how technology could improve the speed or quality of their

specific business processes. The moderator should summarize each response and write it

across the top of a flip chart page. Then, the group should be asked to provide additional

information about the idea and write it in the space below the idea. Once an idea has

been sufficiently documented, the sheet should be hung on the walls of the meeting

space.

If you don’t know how

technology could

improve operations for

a particular group, just

ask them! Often, the

attendees have been

exposed to technology

beyond the

organization (through

trade shows,

colleagues, local

agencies, etc.), and

they have seen the

new capabilities of IT

and how it could make

certain aspects of their

job better.
Chapter 5: Determine Stakeholder and User Needs 87

After the various business processes presented in the report have been discussed, there

should be several sheets of paper hanging on the walls. Based on our property/evidence

example, they may look like this:

PROPERTY/EVIDENCE FOCUS GROUP

Current Process:

Articles are booked using a handwritten

form filled out by the officer. Technicians

must retype the information from the form

into an Access database and NCIC.

Ideas for Improvement:

Create Single Point of Data Entry

Interface RMS with our Access database

Use barcode labels to speed receiving

Replace the Access database with an

RMS module

PROPERTY/EVIDENCE FOCUS GROUP

Idea: Create Single Point of Data Entry

Have officers type information directly

into an electronic RMS form, instead of

writing it by hand

Make the RMS form transfer data into our

Access database

Have the RMS automatically enter NCIC

data upon entry by the officer

Recognizing that not every idea will become a reality, the moderator should ask the users

to prioritize the various ideas presented during the Focus Group. Similar to the SWOT

format, the participants should be asked to indicate their individual choices for the three

most important ideas by using the same three color-coded stickers.

Once the participants have completed their prioritization, the moderator should take

some time to review the findings and ask the group if there were any surprises, attempting to foster discussion on unanticipated findings, and seeking to reveal even more

information that will be useful in designing the new system.

Regardless of the interview technique, the net outcome should be enough information for the Project Team to use as a basis for documenting the general system

requirements, the subject of Chapter 6.
CHAPTER 6

DEVELOP GENERAL SYSTEM

REQUIREMENTS
Chapter 6:

Develop General System

Requirements

Translating research, interviews and Focus Group meetings into general hardware,

software and interface requirements for the new system(s).

The requirements will become the core material of the conceptual design and

procurement documents.

The Project Manager uses the Technical and User Committees to draft the various

system requirements.

Documenting requirements can only occur after you have defined the project’s scope

and have interviewed the project’s stakeholders and users.

Once an organization has completed the difficult task of envisioning what their

new technology should accomplish, the next step is to begin describing what tools

will be needed in order to achieve those goals.

In this chapter, we’ll focus on the principles behind coordinating the Project

Team’s technical and operational resources for the purpose of defining (for the first

time) precisely what hardware, software, interface and performance standards will

likely be required.

Compile the Requirements

By now, your project’s basic scope should be fairly well defined in terms of major

categories (CAD, RMS, Mobile, etc.), depending on the scope of your project. Using the

tools developed in Chapters 4 and 5, the major categories must now be further defined.

In Chapter 4, we established a baseline of existing technology that the organization uses

for accomplishing its business objectives. In Chapter 5, stakeholders analyzed how

effectively that technology baseline meets their needs, and discussed what specific tools

they would require in the future to improve efficiency and effectiveness.

Under the direction of the Project Manager, the Project Team must now translate the

information culled from Focus Groups and interviews into specific hardware, software

and interface requirements. This step is interpretive, and requires the Technical and User

What

Why

Who

When
92 Part II: Conduct a Needs Analysis

PROJECT TEAM

TRANSLATES OPPORTUNITIES

INTO REQUIREMENTS:

Hardware: Modern Processor,

Redundancy Needed

Software: Statistics,

Alarm Billing

Interfaces:

CAD- Mobile,

CAD-RMS,

CAD-NCIC

DISPATCHER FOCUS GROUP

Strengths of Current CAD:

Everyone is Proficient

Easy to Use

Weaknesses of Current CAD:

System is slow

System fails about twice/year

Can’t get statistics from CAD

Alarm billing maintained manually

Can’t send calls to MDTs

Can’t retrieve RMS information

Duplicate NCIC data entry

Opportunities for Improvement:

Make it faster

Make it more reliable

CAD could give us statistics

Let CAD do alarm billing for us

Connect CAD to MDTs and RMS

Enter NCIC data one time only

Threats to Success:

Might be too expensive

Training must be adequate

Committees to carefully review the flip charts and notes from the stakeholder meetings.

Using the Dispatcher Focus Group example from Chapter 5, this step might look like this:
Chapter 6: Develop General System Requirements 93

In this example, the Project Manager would have supplied the User and Technical

Committees with the Dispatch Focus Group flip chart, requesting that they review the

notes and develop general hardware, software and interface requirements. The requirements would be written and returned to the Project Manager for assembly.

Define General Hardware Requirements

Technical Experts Technical Experts: In order to identify the size of various hardware components (i.e., disk Technical Experts

size, processor speed, etc.) that may be required for the new initiative, the Technical

Committee will need to review the organization’s relevant transaction volumes, both current

and projected, for a period of 5 years.

The Project Manager should collect and provide the following information to the

Technical Committee, in advance of preparing the general hardware requirements:

General Sizing Questions:

• Number of facilities where CAD/RMS will be accessed

• Number of vehicles equipped with mobile data devices

• Number of CAD workstations

• Number of concurrent CAD users

• Number of RMS workstations

• Number of concurrent RMS users

Specific Transaction Volumes:

• Total Calls for Service

• Incidents/Crime Cases

• Arrests

• Field Interviews

• Accident Reports

• Traffic Citations

• Pawn Slips

• Warrants Issued

• Subpoenas Served

• Temporary Restraining Orders on Record

• Registrants

• Licenses

• False Alarms
94 Part II: Conduct a Needs Analysis

Projects may require more or fewer transaction volumes, depending on the scope of the

project. For example, if the project scope is limited to a mugshot imaging system, it may

not be necessary to gather statistics on CAD workstations.

The Technical Committee is responsible for developing the general hardware requirements, including, at a minimum:

• General Hardware Environment (client/server, thin client, etc.)

• Network Design

• Operating System

• Database Standard

• Hardware Manufacturer Standard (server, desktop PCs, mobile devices,

handhelds, monitors, etc.)

In addition to reviewing the interview or Focus Group documentation, the Technical

Committee must supplement the general requirements with their expertise and knowledge of the current and planned technical infrastructure.

Define General Software Requirements

Users: The User Committee is responsible for developing the general software requirements, Users

which are modules of the major software categories. In our dispatch example, the User

Committee identified two required modules (Statistics and Alarm Billing) of the CAD

application (major category).

In order to identify required software modules, the User Committee should understand

which modules are commonly associated with the major categories. Listed in the chart on

the next page are modules that are commonly associated with the most common police

technology initiatives. Committee members should use these modules as a starting point,

recognizing that additional site-specific modules may also be required.

A critical success factor is ensuring that the new technology is designed in

concert with the parent organization’s hardware and software standards, as

well as future or strategic IT plans. For the overwhelming majority of police

agencies, this means ensuring that the technology uses the same operating

system, network standards and hardware manufacturer as that of the City or County (if such

standards exist). By doing so, the agency can capitalize upon existing human and financial

resources while preventing fractured support and high vendor maintenance costs in the

future.

Module: A portion of

a program that carries

out a specific function

and may be used

alone or combined

with other modules of

the same program.

Client: The client

part of a client/server

architecture. Typically,

a client is an

application that runs

on a personal

computer or

workstation and relies

on a server to perform

some operations. A

thin client is a client

designed to be

especially small so

that the bulk of data

processing occurs on

the server.
Chapter 6: Develop General System Requirements 95

Functionality that relates to...

entering calls for service into CAD

assignment of personnel to incidents

how CAD monitors units, calls and responders

supplying CAD with required data, such as a geofile or AVL data

how CAD communicates with other users (within CAD and RMS)

the specific needs of supervisors

using the CAD for training new dispatchers

the tools that are made available for CAD to access (premise history, etc.)

CAD’s ability to supply real-time statistic information

preparing alarm bills, warnings, etc.

allowing CAD to issue and store various permits (alarm, party, etc.)

screen mapping tools

how RMS captures and maintains files related to people

how RMS captures and maintains files related to vehicles

how RMS captures and maintains files related to addresses/locations

how the records bureau processes reports

enabling officers to write/submit reports from remote locations

case receipt, distribution and document management

analyzing crime statistics

how articles are entered and maintained within the RMS

initial booking of prisoners

maintaining human resource information

scheduling, assigning, managing required training and certifications

tracking police equipment

internal affairs, administrative reporting

entry and maintenance of pawn ticket information

collision reporting, citation issuance (parking and moving)

tracking officer activity for statistical purposes

issuing and maintaining various agency-issued permits (weapons, etc.)

issuing and maintaining various agency-issued licenses (bike, alcohol, etc.)

specific animal-related calls for service and subsequent reporting

entering report information directly into RMS

the device’s ability to communicate with CAD, RMS and external entities

the screen layout

the number and type of inquiry forms that may be used (NCIC, etc.)

how the device receives a dispatched call for service

what type of CAD and RMS commands are available on the device

how a touch-screen device is controlled

which data elements are imported from CAD into the report forms

how the AFR will assist officers with report completion

creating, filing and correcting reports, narratives and forms

electronic case filing and distribution

how reports are corrected, approved and/or rejected by supervision

the initial receipt of a prisoner

how prisoners are conclusively identified

detailing all prisoner profile data

assignment of quarters/cell

prisoner transports to/from court and other facilities

ordering, preparing, auditing food preparation/service

financial software for managing inmate spending and commissary

monitoring prisoner health-related matters

store ordering, purchases

psychological units within the jail

Computer Aided

Dispatch (CAD)

Records

Management

System (RMS)

Mobile Data

Automated Field

Reporting (AFR)

Jail Management

System (JMS)

Module

Incident Entry ............................

Dispatching Unit/Incident ..........

Status Monitoring Dispatch .......

Support Files .............................

Messaging .................................

Supervisory Functions ..............

Training Functions .....................

CAD Inquiry Tools .....................

Statistics ....................................

Alarm Billing .............................

Permits ......................................

Mapping ....................................

Master Name Index ....................

Master Vehicle Index .................

Master Location Index ...............

Incident Reporting .....................

Field Reporting ..........................

Case Management .....................

Crime Analysis ..........................

Property/Evidence .....................

Arrest/Booking ..........................

Personnel ..................................

Training .....................................

Inventory ...................................

Administration ...........................

Pawn .........................................

Traffic ........................................

Activity Log ...............................

Permits ......................................

Licensing ...................................

Animal Control ..........................

Report Writing ...........................

Messaging .................................

Display ......................................

Forms ........................................

Call Receipt ...............................

Commands ................................

Touch Screen .............................

CAD Data Capture .....................

Error Correction .........................

Report Writing ...........................

Case Management .....................

Approvals ..................................

Detention Processing ................

Identification ..............................

Classification .............................

Housing .....................................

Transportation ...........................

Food Service .............................

Accounting ................................

Medical .....................................

Commissary ..............................

Mental Health ............................
96 Part II: Conduct a Needs Analysis

The User Committee should consider additional issues that may not be present in

interview or Focus Group documentation, such as integration with existing systems

(local and regional).

Define General Interface and Integration

Requirements

Defining the general interfaces and integration requirements is often conducted by both

the User and Technical Committees User and Technical Committees. While most user requests will be recorded, be sure User and Technical Committees

to consider the following interfaces as well:

Integrated Justice: Local, regional, State and Federal databases may need to be integrated

with your new application. Be sure to consider the possibility of sharing information with

these databases, even if the project budget cannot sustain such costs at the present time.

CAD or RMS to Parent Organization: Cities and counties maintain databases on

building/safety (which show blueprints), permit issuance (which can reveal owner

information), personnel and many other valuable resources. Be sure to investigate the

possible uses of such interfaces.

CAD or RMS to Geographic Information Systems (GIS): Virtually all modern CAD

applications must be able to access a valid street file in order to operate properly. Many

RMS products require access to GIS resources for crime analysis, statistics and address

verification. This often-overlooked interface is crucial to the success of a CAD/RMS

installation. installation.

City or County engineering departments should be able to provide the status of “basemaps,” which contain core map information. If your project calls for automated vehicle

location (AVL) capabilities, you will need a base-map that includes x/y coordinates (for

the longitude and latitude readings for any point on the map).
Chapter 6: Develop General System Requirements 97

Create a Conceptual Design Illustration

Once the committees have submitted their findings, it is useful to document the information in a graphic display that will represent the conceptual design of the technology

initiative. The conceptual design is useful for conveying a high-level perspective of the

project’s scope, general requirements and connectivity with internal and external

resources.

Each project will necessitate various inclusions within the conceptual design, as determined by the project’s scope. For example, an RMS conceptual design prepared for a

Sheriff ’s Department is shown on the next page.

The Project Team should prepare the conceptual design and distribute it among project

participants for review and comment, updating the document based on user feedback.

Ultimately, the conceptual design would be included in any procurement-related

documents.

The conceptual design will be the foundation for developing more detailed

performance and functional requirements, as addressed in Chapter 14.
98 Part II: Conduct a Needs Analysis

Narcotics10

Crime Analysis11

Investigative

Follow-up12

Investigations

Case Management13

Interfaces14

Administration

Ad Hoc Search

Capability15

Personnel and

Training16

Pawns17

Internal Affairs

Records

Management

System

Automated Report

Writing

Arrest Reports1

Traffic Reports2

Signature Forms3

Property/Evidence4

Crime Lab5

Optical Imaging6

Field Interview7

CAD

Supervisor

Approval of

Submitted Report

Records Modules Websites8 9

▲

CAD

Jail

State

DMV

GIS Base Maps

LiveScan

AFIS

▲ ▲ ▲

▲

▲

▲

▲

▲ ▲ ▲

▲

▲

▲

▲

▲ ▲

Continuous

exchange

of data

Investigative

follow-up

Automatically populates

report fields

▲

SAMPLE RMS

CONCEPTUAL DESIGN
Chapter 6: Develop General System Requirements 99

1 Interface with AFIS and LiveScan to prevent redundant entry of booking information.

2 Includes all standard State traffic forms and interfaces with local RMS, DMV and automated citation

programs.

3 A blank, universal signature form.

4 Pre-formatted property/evidence forms will be supplemented with deputy-provided data. A barcode label

will be generated and affixed onto the property. Property/evidence staff will receive the property and scan the

item into RMS, which will retrieve all case data online. Any serialized property will be automatically checked

through State/NCIC and local databases. As property is moved and ultimately disposed of, barcode readers

scan the item at each point of movement.

5 Building on the property/evidence barcoding usage, evidence submitted to the lab for processing is also

tracked via barcode technology. As evidence is processed and lab supervisors approve results, the status and

ultimate disposition is updated into the originating online case file for viewing.

6 Optical scanning equipment will be used for storing various objects related to crime reports (e.g., bad checks,

photographs, etc.).

7 CAD will also populate known information into field interview forms, which are then uploaded to the RMS

master name and vehicle records.

8 RMS will be capable of posting records data to various Websites (based on preset guidelines and security).

9 When a report written online arrives in the records bureau, copies are automatically distributed to preset

recipients. For example, RMS will automatically prepare press releases, deleting preset information and

language. Automated UCR/NIBRS coding occurs as reports are received by the records bureau for automated

weekly, monthly and annual statistic reporting. A Warrants module will enable receipt, update and

abstraction of warrants. A Temporary and Permanent Restraining Order database will enable online access

and verification of existing court orders.

10 In addition to case management functionality, the Narcotics module also includes a confidential informant

database, accounts payable features and access to subpoena files.

11 Comprehensive, flexible search and select criteria with ability to conduct analysis on all database elements,

including geographic crime analysis tools essential to creating crime prediction models.

12 All case notes, supplemental reports and documentation may be amended to the original report. Based on the

work completed, the system will reevaluate the solvability of the event, notifying supervisors of the investigative status.

13 Initially, the Case Management module will check reports for content, then assign solvability factors and

make a recommendation to investigative supervisors regarding case assignment, based on existing investigator workload.

14 Can also include Court, District Attorney’s Office, NCIC and Building and Safety interfaces, Internet access,

automated citation programs, and message switch for mobile access to RMS.

15 Ad hoc searching enables user-friendly record searches from the simple (tell me how many auto thefts

occurred in the County yesterday) to the complex (find all field interview subjects with a tattoo of a knife on

their left arm who own a red car). More complex search routines may be saved for automatic daily, weekly or

monthly reporting.

16 Maintains comprehensive employee database regarding employment history and training qualifications. The

module also makes training recommendations, schedules training and can prepare reimbursement documentation automatically upon course completion.

17 Enables receipt and upload of pawn data via disk or manual entry.
CHAPTER 7

MAKE THE DECISION — BUILD OR BUY
Chapter 7:

Make the Decision —

Build or Buy

Based on all the

project activities and

work to this point, the

Project Manager and

the User and Technical

Committees will

provide a

recommendation on

the “build or buy”

decision to the

Steering Committee.

A critical decisionmaking process involving whether to purchase the required

software from a vendor or build a custom solution from scratch.

Because the methods, issues, costs and impact of buying a law enforcement software

package from a vendor are very different from those that are involved with creating a

customized solution.

The Executive Sponsor and Steering Committee, on the advice of the Project Manager

and User and Technical Committees.

This decision must be made after the conceptual design has been prepared, and prior

to the start of any type of procurement.

With the completed conceptual design, your project’s technology goals are well

defined. Now, the challenge is to find the right tool for the job. In the world of law

enforcement IT, there are two options:

1. “Buy” the necessary technology from a vendor that specializes in public Buy

safety hardware and/or software.

2. Use internal or external technologists to “build” the technology based build

exclusively on the needs of the organization.

The scope of this chapter excludes hardware, as it is assumed that law enforcement

agencies will not attempt to design or develop actual hardware devices such as

laptops or radio towers. (Although the authors have been exposed to such ingenuity, this development is extremely rare and not advised.)

Therefore, this chapter focuses on the considerations your agency must address

prior to deciding whether to buy or build a software solution.

It is a closely held belief within public administration that law enforcement agencies (and

government in general) should almost always buy “off-the-shelf ” packaged software,

because building custom government applications is wrought with risk, unanticipated

costs and seemingly endless development cycles. Government technology “build” horror

stories have become urban legends. Ever heard the following “build” nightmares?

What

Why

Who

When
104 Part II: Conduct a Needs Analysis

LEARN FROM THEIR MISTAKES!

California Department of Motor Vehicles: A 1987 drivers’ license and registration

overhaul project was expected to cost $26 million and last for 5 years. The project was

cancelled in 1993 after $45 million was spent, with no net benefit.

Pacific Gas & Electric: This 1995 customer information system project was expected

to cost $80 million and last for 2 years. The project was cancelled in 1996 after $60 million

had been spent, with only 10 percent of the project goals complete.

While different analysts have reached different conclusions about the causes of such

failures, there is a general sense that they were largely doomed from the onset because of

a failure to carefully consider whether buying a solution would have been the best course

of action.

Note: the build or buy decision may be easy for many agencies. Recognizing that the Note

majority of police agencies in America probably don’t have their own dedicated software don’t 

engineers, the concept of designing and building a solution in-house may be academic to

most. In this case, your obvious choice would be to pursue a vendor-supplied option.

However, for those agencies that do possess dedicated technology resources (whether inhouse or supplied by a City or County parent organization), it is imperative to objectively

assess the basic feasibility of building a software package. To do so, your project’s

Steering Committee should examine and discuss the following project cost and technology resource issues.

Project Cost Considerations

As a general rule, police agencies should expect the “buy” option to be considerably less

costly, and more readily available, than the “build” option. Agencies building their own

customized applications will bear all of the dollar costs for a single use of the application,

with little or no ability to recover costs. For example, an agency that invests $2 million in

a customized CAD/RMS solution must bear all development, testing and installation

expenses.

Conversely, a vendor would view a $2 million CAD/RMS “build” as an investment to be

recovered (at a minimum!) by licensing the software to multiple clients. Thus, a vendor

could offer a CAD/RMS software package, valued at $2 million, to hundreds of police

agencies for a fraction of the cost while still accomplishing their primary goal:

profitability.
105 Chapter 7: Make the Decision — Build or Buy

In Chapter 11 we discuss methods for developing one-time and recurring cost estimates

for the purpose of budgeting. When considering a “buy versus build” decision, agencies

must supplement those costs with both direct and indirect costs.

Direct Costs Direct Costs: Because off-the-shelf packages are designed for “Anywhere PD,” they rarely Direct Costs

meet an agency’s needs perfectly. Police customers are typically faced with three choices:

1. Use as-is.

2. Change the way the agency does business to fit the product.

3. Customize the software.

While the first and second options will likely compete with the project’s stated objectives,

the third option will certainly result in actual project cost inflation. (To measure the rate

of inflation, simply contact various vendor client references and ask how much the

vendor’s price changed from proposal to live date.)

BUILD

• Customized

• Dedicated staff must:

- Design

- Build

- Support

- Document

- Train

- Update and Enhance

• Development time

• High cost

• Future uncertain

BUY

• Lower costs

• Not customized

• Vendor can/will provide:

- Support

- Training

- Documentation

- Upgrades

•Vendor future uncertain
106 Part II: Conduct a Needs Analysis

Indirect Costs Indirect Costs: While agencies can be lured to “build” solutions because of the benefits Indirect Costs

that can accrue from customization, the recurring costs can be staggering. Simply

compare a vendor’s annual maintenance fee for an off-the-shelf package (which averages

17.5 percent of initial software costs) with the cost of retaining or replacing full-time

technology employees dedicated to support a built application. Assume you’ll need a

minimum of four employees: a software engineer, database manager, network specialist

and help desk/support technician.

After carefully analyzing the identifiable project costs, your agency’s Project Team and

Steering Committee must determine the relative importance of cost as it relates to the

project’s objectives.

Managing Technology Resources

Assuming that an agency is equipped with available technology staff and is considering

building an application, it must consider how best to use such resources. For example, if

your organization has two software developers, the Steering Committee must decide

whether they would be most effectively used in writing software code that is available

commercially or in developing unique systems that simply cannot be purchased at any

price. Additionally, the use of technology staff may negatively impact their initial duties,

such as managing legacy systems and running the daily IT operations.

Another consideration is the potential impact of staff instability on a “build” project.

Most public organizations experience significant IT staff turnover in any given 5-year

period. Although vendor software developers and contractors face the same prospects,

they recognize that their contractual obligations cannot be altered by the loss of staff and

they typically have more flexibility to react to such changes than their public-sector

counterparts.

Skill sets required within most organizations change rapidly as technology evolves. The

Steering Committee and Project Team must realistically assess your jurisdiction’s ability

to develop and maintain the skill levels required to keep pace with technology shifts that

can bring value to the agency.

In addition to managing technical resources, the Steering Committee must consider the

importance of ancillary staff who are crucial to any software initiative, such as technical

writers and trainers. Both training and documentation are considered critical success

factors and require the use of skilled and experienced experts in each field, regardless of

whether your agency chooses to “build” or “buy.” All too often, training and documentation are the first victims of cost overruns. Therefore, it is particularly important that your

agency carefully examine its approach toward these critical project elements.

Remember that the

more a vendor’s

package is

customized, the more

the project actually

resembles a “build”

decision. In addition,

when it comes time to

“upgrade” the

package, you will have

to pay for the

customization to the

new version, as the

vendor’s standard

upgrade will no longer

work with your

customized product.
107 Chapter 7: Make the Decision — Build or Buy

Finally, it is important to remember that most “build” solutions require significantly

more time to complete than “buy” solutions. Build solutions are the result of a software

development lifecycle that can last anywhere from 6 months to 6 years, depending on the

size of the initiative. Conversely, vendors have already developed, installed and tested

such applications well before an agency buys them. If a build decision is made, your

project’s decisionmakers must evaluate whether the additional time required is justified

by an increase in the quality of service delivered by the resulting software.

The Decision

Regardless of whether your agency chooses to “build” or “buy,” we recommend that your

agency proceed with conducting a comprehensive procurement process. Agencies that

choose to build a solution should have their own in-house staff compete with the private

industry vendors, responding to procurement documents and enabling them to be

objectively compared to their competitors.

The purpose of such competition is twofold. First, it’s likely that a “build” decision will

need to be justified to various project stakeholders, such as elected officials, who will

require such information prior to making a decision. A bid response is an excellent

instrument for articulating the various ways that an in-house solution could best meet

the objectives of the organization. Second, compelling internal staff to articulate their

work plan in writing is the first step toward defining their roles and responsibilities, thus

establishing a client relationship with the agency.

Part IV of this guide is designed to provide insight into the best practices for conducting

procurement under the assumption that the agency will proceed with a “buy” approach.

What’s Next?

Undertake the Project Planning Process ............................................ Chapter 8

Define the Project Scope and Objectives ........................................... Chapter 9

Create Project Schedules, Deliverables and Milestones .................... Chapter 10

Develop the Project Budget .............................................................. Chapter 11

Create a Plan to Manage Risk .......................................................... Chapter 12

Communicate and Document Project Activities .............................. Chapter 13

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○
108 Part II: Conduct a Needs Analysis

EXECUTIVE SPONSOR

Role 1. Ultimate decisionmaker

2. Provide oversight and guidance

3. Provide leadership and support for needs analysis tasks

4. Make personnel available for interviews and Focus Group

meetings

Needs Analysis 1. Meet with union representatives and other leaders

 Tasks prior to business process review to explain why this activity

is important and to allay fears (Chapter 4, page 72)

2. Make personnel available to participate in committees,

interviews and Focus Groups (Chapter 5, page 81)

3. With input of Steering Committee, make the “build” or

“buy” decision (Chapter 7)

STEERING COMMITTEE

Role 1. Provide knowledge and recommendations

2. Remove project barriers

3. Update/inform Executive Sponsor

4. Review key documents

Needs Analysis 1. Review Business Process Baseline report (Chapter 4)

Tasks 2. Review General System Requirements, Interface and

Integration Requirements, and Conceptual Design

Illustration (Chapter 6)

3. Advise Executive Sponsor on the “build” or “buy”

decision (Chapter 7)

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

PART II ASSIGNMENTS
Part II Assignments 109

PROJECT MANAGER

Role 1. Coordinate all tasks and activities

2. Facilitate meetings and Focus Groups

3. Understand business process reengineering principles

4. Research technology and its application to law

enforcement agencies

5. Document all findings

Needs Analysis 1. Review User and Technical Committee membership to

Tasks make sure they represent the major business processes

in the agency (Chapter 4, page 68)

2. Prepare a final Business Process Baseline report with

input of User and Technical Committees (Chapter 4)

3. Prepare agendas for interviews and conduct individual

interviews (Chapter 5, page 81)

4. Lead Focus Group sessions (Chapter 5, page 83)

5. Research other agencies using technology

(Chapter 5, pages 83, 84)

6. Document results of interviews and Focus Groups

(Chapter 5)

7. Prepare General System Requirements

(Chapter 6, Page 93)

8. Prepare General Interface and Integration Requirements

(Chapter 6, page 96)

9. Prepare Conceptual Design Illustration

(Chapter 6, page 97)

10. Make a “build” or “buy” recommendation (Chapter 7)

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

PART II ASSIGNMENTS, CONTINUED
110 Part II: Conduct a Needs Analysis

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

USER COMMITTEE

Role 1. Analyze and document existing business processes and

develop new processes for information flow and

management

2. Provide input to the Project Manager and

Technical Committee

Needs Analysis 1. Define and categorize business processes

Tasks (Chapter 4, page 69)

2. Participate in interviews and/or Focus Groups

(Chapter 5)

3. Compile General Software Requirements

(Chapter 6, page 94)

4. Define General Interface and Integration Requirements

(Chapter 6, page 96)

5. Recommend whether to “build” or “buy” a solution

(Chapter 7)

TECHNICAL COMMITTEE

Role 1. Review existing technology

2. Make recommendations about new technology based on

 business needs, as defined by the User Committee

Needs Analysis 1. Develop a written description of existing agency

Tasks technology and infrastructure (Chapter 4, page 72)

2. Participate in interviews and/or Focus Groups

(Chapter 5)

3. Compile General Hardware Requirements

(Chapter 6, page 93)

4. Define General Interface and Integration Requirements

(Chapter 6, page 96)

5. Recommend whether to “build” or “buy” a solution

(Chapter 7)

PART II ASSIGNMENTS, CONTINUED
If you fail to plan, plan to fail.

— Anonymous

Part III:

Create a

Project Plan
CHAPTER 8

PROJECT PLANNING:

WHAT IS IT AND WHY ARE WE DOING IT?
Chapter 8:

Project Planning: What is it

and Why are We Doing it?

A dynamic process that results in a document that guides the entire IT project design,

procurement, implementation and future enhancements. It articulates each of the

deliverables, deliverables, the deliverables, procedures procedures and procedures resources resources needed to produce them, and the resources quality

measures they must meet to be accepted. This document can grow and change during

the project’s lifecycle.

The Plan is the repository for all project-related research, decisions, deliverables and

documents. It is the playbook for the entire project. Project planning increases the

success of projects through early detection of problems via constant monitoring of the

projects’ “vital signs.”

The Project Manager and the User and Technical Committees are involved in discussions, decisions and research. The Project Manager should be responsible for Project

Plan documentation. The Steering Committee and Executive Sponsor must endorse

and sign the Plan.

Following formal development of the decisionmaking structure (Part I) and in

conjunction with the development of the needs analysis (Part II).

The Project Plan serves as the detailed roadmap guiding continued project

planning, procurement, implementation and management. It is a disciplined effort

to produce decisions and actions. The resulting Plan will catalog the decisions

about what to do, and when, why and how to do it. It is an inclusive process, and is

designed to keep all project stakeholders “on the same page.”

While the Project Charter (Chapter 3) is a succinct document that illustrates the

vision and intent of the proposed project and its key sponsors, the Plan articulates

the specifics of getting the project done. The Project Charter is a key building block

and starting point for the Plan.

A thorough Project Plan also assists in managing user expectations by detailing

exactly what will be accomplished, how and when, and by whom. The process and

subsequent documentation keeps things focused and moving forward. By documenting issues that have been dealt with and decided upon, it prevents “covering

the same ground,” which can often bog a project down.

What

Why

Who

When
Part III: Create a Project Plan 116

Five Important Facts to Know about

Project Plans

1. Project Plans are dynamic. The Plan will evolve and change as the Project Team, Project Plans are dynamic

Project Manager and others conduct research and more clearly define the scope and

objectives of the project. In addition to printed versions, the Plan can also be posted

electronically so that the nature and evolution of the project can be charted for

everyone involved. Doing so will not only enforce a singular vision of the project, but

will also enable all those involved to see and constantly track progress that has been

made, achievements they can be proud of, and decisions that have shaped the project

to date.

2. Project planning is a creative process. Project planning is a creative process. Given the pace at which technology and Project planning is a creative process. 

business are changing, ideas and decisions made at a particular point in the process

may be altered significantly as new thoughts and information become available. As

noted by the Alliance for Nonprofit Management (www.allianceonline.org), “The

fresh insight arrived at today might very well alter the decision made yesterday.”

3. Project planning is not necessarily a linear process. Project planning is not necessarily a linear process. Some planning activities are Project planning is not necessarily a linear process. 

related to and dependent upon other decisions. For instance, developing project

objectives is dependent upon finalizing the scope statement, while detailing

deliverables can only occur after both scope and objectives are completed. However,

scope, objectives and deliverables may be revisited and modified pending the results

of a thorough risk assessment and/or the resource requirements analysis.

4. To be effective, Project Plans must be To be effective, Project Plans must be used, reviewed, maintained and updated

constantly. This sounds obvious, but too often organizations go through the planning constantly

process only to shelve their Plan and never actually use it. The Plan will be the litmus

test, if you will, for all project-related activities. The Project Team must constantly

reaffirm the scope and objectives of the project so that when, for example, they are

negotiating a vendor contract, they can always consult the Plan to compare the

organization’s needs versus the vendor’s proposals.

5. Planning should not go on forever. Planning should not go on forever. Do your employees sneer or groan when “plan- Planning should not go on forever. 

ning” is mentioned? Often, they do so for a reason. Planning needs to be managed

(hence the Project Manager!) and kept on a tight schedule. Too often the planning

process is drawn out indefinitely, causing participants to lose interest or feel as

though they will never begin to see the results of their planning efforts. The point is

not to get paralyzed in the process. Set realistic timeframes and develop a schedule

for the Plan that establishes a timeframe and planning goals.

“

”

A thorough

Project Planning Process

provides the

structure and

procedures to

ensure that

adequate time

and effort is

put into

identifying the

project scope,

deliverables,

resource

requirements

and risks.

— Chief

Information Officer

Web Site, Treasury

Board of Canada

(www.ciodpi.gc.ca)
Chapter 8: Project Planning 117

You must establish formal procedures for managing change throughout the life of your

project. (Don’t worry, we’ll help you do that.) We wanted to point out, however, that this is a

critical factor in successful project planning and implementation. Things change. Scope

will change. Timelines will be altered. Budgets will shift. But there MUST be a formal,

thoughtful and controlled procedure for each alteration to any aspect to the project. This

will ensure not only that the change is well researched and documented, but also that there

are proper methods for approval and that all project participants are notified about the

change and its impact on other parts of the project.

Once your Project Plan is complete, you will have defined formal procedures for making

changes to the project scope, timeline, budget and other resources. And, in each chapter

describing these concepts, we’ll address change management procedures.

Executive Sponsors: Prepare Your

Organization for Change

An aspect of change management you must be extremely sensitive to and involved in is

the organizational/human resources impact. You must help prepare the organization to

support the changes that result from the introduction of automation.

During the needs analysis, current processes are identified, mapped and analyzed to

identify ways to improve them for efficiency. Job positions may be redefined and

processes streamlined. This may threaten some employees: some may believe their jobs

will be eliminated and others may simply perceive that they will be removed from their

“comfort zone” by change. Be aware that employees often begin their resistance to change

early in the process. As Executive Sponsor, you must continually espouse the benefits of

the change and manage the expectations of employees, adjusting the organization’s

infrastructures in order to prepare employees for the changes that will be supported by

the implementation of IT. You must also prepare them for the fact that their job responsibilities may shift and change (say from data entry to quality control), but that the intent

is to improve the department’s operations, not to eliminate jobs.
Part III: Create a Project Plan 118

Project planning is...

• Disciplined

• Research-based

• Continuous

• Dynamic

• Inclusive

The Project Plan’s Table of Contents

Obviously, your Project Plan can be structured in many ways, but these are the main

components that should be included in any plan:

I. ........ Project Charter Project Charter

II. ........ Scope, Project Objectives and Scope Management Plan

III. ........ Project Schedule and Milestones Project Schedule and Milestones

IV. ........ Budget

V. ........ Risk Management Plan

VI. ........ Communications Plan

The Project Charter was created in Part I of this Guide. The remaining chapters in Part III

will address the other major components of your Project Plan — from scope through

communications.
CHAPTER 9

CONDUCT SCOPE PLANNING
Chapter 9:

Conduct Scope Planning

A process to precisely define and document specific activities and deliverables for a

particular project.

Defining the project scope and objectives clarifies and defines the project focus and

keeps activities in control and within agreed-upon boundaries. It also establishes a

formal process for proactively managing changes in project scope.

Led by the Project Manager, the User and Technical Committees will be most involved

in defining scope, objectives and approach, to be adopted by the Steering Committee.

Following the needs analysis (see Part II).

When your Project Team developed the Project Charter, that document served as

the formalization and kickoff for the project. It was assembled to garner stakeholder commitment and authorization to move the project forward. While some

initial scope boundaries and high-level objectives were included in the Charter, the

Project Plan must contain very detailed and specific scope requirements.

This chapter will help you and your Project Team dive into scope planning and

develop a substantively detailed scope statement, project objectives and a Scope

Management Plan.

Careful scope planning is comprised of three key elements:

1. A scope statement scope statement that provides scope scope statement

definition with:

a. Supporting detail

b. Work breakdown structure;

2. Project objectives Project objectives; and a Project objectives

3. Scope Management Plan. Scope Management Plan

What

Why

Who

When

Each of these elements is essential

to establishing and justifying a

clear scope definition, and creates

a process to manage potential

scope changes.

Supporting Detail

Scope Definition

Work Breakdown Structure
122 Part III: Create a Project Plan

1. The Scope Statement:

What’s In, What’s Out

The scope statement “provides a documented basis for making future project decisions

and for confirming or developing common understanding of project scope among the

stakeholders,” says the Project Management Institute (PMI). The scope statement should

make very clear what is “in” the project and what is “out.” For example, agency X has

decided that the computer-aided dispatch (CAD) system will be redesigned and replaced.

Although the agency also recognizes the need to replace the existing records management system (RMS), it simply cannot afford to do so at this time. Therefore, during scope

definition, the agency decides that while CAD is “in,” RMS is “out.”

How do you Prepare the Scope Statement?

The Project Manager and User Committee should work together to develop the scope

statement using the following input:

• Executive Sponsor and Steering Committee vision.

• Results of the environmental scan.

• Business process review, needs analysis and analysis of the existing technological

environment.

• Available human and financial resources.

• Quality desired from the project.

The User Committee should consider and document:

• The major functionality to be implemented (decision support, data entry, manage- functionality

ment statistics).

• Types of deliverables deliverables that are in scope and out of scope (e.g., CAD, but not deliverables

automated vehicle location (AVL)).

• Types of data that are in scope and out of scope. Types of data

• Data sources or databases Data sources or databases that are in and out of scope. Data sources or databases

• Which units will be affected and/or expected to use the system (dispatch, patrol, units

crime analysis, etc.).

• What is specifically out of scope. of scope
Chapter 9: Conduct Scope Planning 123

a. Supporting Detail

Much of what was prepared for the “business case” in the Project Charter (Chapter 3, “business case”

page 56) will become the supporting detail for the scope statement. Additional detail

may be identified as the Project Team fleshes out the scope statement.

Major project assumptions and constraints assumptions and constraints should also be catalogued in the scope assumptions and constraints

statement’s supporting detail. The assumptions and constraints should relate back to the

agency’s business objectives and overall mission and goals. For example, the agency’s

overall mission may be to move toward a problem-solving paradigm. Thus, the technology implemented must be developed to support that goal. It is critical, then, that the

scope be continually assessed to ensure that it is aligned with the organization’s mission,

goals and overall objectives.

If there are specific grant requirements grant requirements and/or directives for the project, they too should grant requirements

become part of the supporting detail for the scope statement.

b. Work Breakdown Structure

Once the scope has been sufficiently detailed and defined, it can be broken down into

smaller elements or projects that produce specific deliverables. Dissecting scope in this

manner is commonly referred to as a work breakdown structure (WBS). Each of these

subcomponents of the scope must, obviously, be directly related to and descendant from

the scope. Therefore, no activities that are outside of the scope of the project should be

included in the WBS. Breaking the scope into manageable pieces begins to define

activities and milestones that, once completed, will comprise the full project scope.

A WBS FOR A MOBILE COMPUTING PROJECT

Mobile Computing Project

Project Management

Wireless Communications Structure

Software

Laptops

Mounting Devices

Training

Test and Evaluation

For once it’s safe to

make an assumption!

In fact, it’s required.

Project Plans rest

upon certain

assumptions

regarding various

project themes and

participant responsibilities. The

assumptions will be

used primarily for

decisionmaking and

sometimes for

dictating participant

responsibilities. (To

the extent possible,

verify that your

assumptions are

valid.) Consider the

following examples:

• Patrol and records

employees are willing

to change business

operations to take

advantage of the

functionality offered

by the new CAD/RMS.

• The Steering

Committee will

participate in the

timely execution of the

Project Plan (i.e.,

timely approval cycles

and meeting when

required).

• The Project Team

will abide by the

guidelines identified

within this Plan.
124 Part III: Create a Project Plan

2. Project Objectives:

Measures for Success

Project objectives are “quantifiable criteria that must be met for the project to be

considered successful,” says PMI. They are the yardsticks by which success is measured.

Objectives are a critical part of scope because they help the Project Team, stakeholders

and users assess whether or not the finished product(s) did what it was supposed to do,

how well it did and, ultimately, if it was a success. Thus, objectives must include measures

of quality, quality time,cost, performance, performance reliability and/or reliability functionality. functionality

Objectives are important to review in the context of scope to ensure that the Project Team

is not trying to do something that is clearly impossible, too broad (or narrow), or simply

not consistent with the scope.

Project objectives should be specific and achievable if they are to be of any value. Overreaching or generic objectives create unrealistic expectations and should be avoided.

Consider the following examples:

— Instead of saying, The new RMS will help our citizenry, say

The new RMS must provide online case summary statistics to inform community

watch groups and the public in general.

— Instead of saying, The new RMS should reduce paperwork, say

The new RMS should include an optical imaging component that must reduce

paper document storage by at least 50 percent.

— Instead of saying, The new RMS should offer improved access to data, say

The new RMS should enable users to create ad hoc reports.

Objectives offer the organization principles by which decisions are based. As the project

matures, it is likely that the decisionmaking structure will be confronted with difficult

choices. During the decisionmaking period, the Project Team should be able to turn back

to the project’s objectives for guidance and direction.

Think SMART!

Objectives are:

SPECIFIC

MEASURABLE

ACCEPTABLE

REALISTIC

TIME-SENSITIVE
Chapter 9: Conduct Sc ope Planning 125

3. Scope Management Plan: Prevent

‘Scope Creep’

Scope planning is not finished until you have developed a thorough Scope Management

Plan. This is a critical activity designed to effectively guide and control projects. Many

projects fail due to a shift in focus to deliverables that were not part of the original project

scope. The Scope Management Plan should be a formal process and it should be documented in the Project Plan.

The issues to be addressed in the Scope Management Plan include:

• How scope will be managed throughout the project and how to establish a formal

process for managing change.

• An assessment of the project’s scope, as originally defined, and how likely and how

dramatically it may change during the course of the project.

• A clearly defined process for how scope changes will be:

— identified,

— classified, and

— prioritized.

• A requirement that any change requests must be documented on a Project Change

Request form that details the proposed change, the individual or group proposing

the change, why the change is being proposed and the Project Manager’s review

decision. If accepted, the Executive Sponsor (or his or her designee) must approve

the change.

• A process for measuring the impact the change in scope will have on the project,

particularly in terms of quality, time and cost.

Executive Sponsors Executive Sponsors: You (or your designee) must approve scope changes. After all, scope Executive Sponsors

changes will definitely impact the project’s quality, timeline or cost (remember the scopetime-cost triangle introduced on page 58). Only the Executive Sponsor, or his or her

designee, can approve project and potential funding changes.

The goal, of course, is to spend sufficient effort defining the scope up front to minimize

the need for major scope changes later.

Keeping the scope of a project focused is difficult. In his informative paper, “Scope

Containment in Information Systems Projects” (www.newgrange.org/white_papers/

scope_containment_ininformation_.htm), Ted Marcus explains that once a project is

underway, some new dynamics occur:

• Project Team members (and other users) learn more and realize that what they

Scope planning is

INCOMPLETE without

the Scope

Management Plan!
126 Part III: Create a Project Plan

originally asked for may not be exactly what is needed, so a change in scope or

requirements is necessary;

• The business needs may change during the course of the project, so that what was

originally articulated in scope is no longer needed; or

• The marketplace and IT offerings have changed.

The bottom line is that scope changes will occur during your project. A structured

process for documenting, analyzing and approving such changes is key to avoiding an

out-of-control project or unanticipated surprises, such as changes in timeline or cost.

According to Gary H.

Anthes in a

Computerworld article

titled, “No More

Creeps!,” one survey

found that 44% of

respondents said poor

requirements

definition is the

reason for scope

creep, while another

found that only 16%

of Project Managers

say “no” to user

requests for

“significant changes.”
CHAPTER 10

DEVELOP THE PROJECT TIMELINE
Chapter 10:

Develop the Project Timeline

A mechanism to ensure the project is completed on time within the resources

available, and avoids delays and associated cost overruns.

Overdue projects cost more money, impact deadlines on existing and other projects,

can cause sacrifices in quality, and can result in stakeholder and user frustration and

loss of confidence.

The Project Manager will set realistic schedules, as well as deliverable and milestone

deadlines.

Following scope planning.

Throughout the life of your project, you will need to constantly balance the

constraints of time (length of time the project takes to complete), quality and cost.

As we’ve mentioned before, these three sides of the triangle are constant rivals

throughout the project — when one “point” on the triangle grows, so do the

others. A good Project Manager can usually contain two of the three triangle

points; achieving all three is a real challenge. In Chapter 9, we discussed how to

carefully define your project’s scope. In this chapter, we’ll deal with how to nail

down an aggressive, yet realistic, project schedule.

How to Develop an Estimated Project

Schedule

PMI says effective project time management is comprised of five processes:

• Activity Definition

• Activity Sequencing

• Activity Duration Estimating

• Schedule Development

• Schedule Control

First you must define which activities activities will produce the various project deliverables, activities

determine their order and their order dependence on one another, and how dependence long each activity long

will take. By analyzing the appropriate activities, order and dependence, you will be able

What

Why

Who

When
130 Part III: Create a Project Plan

to create an actual schedule and, finally, as we have reiterated in earlier chapters, a means

to control control the schedule and any changes to it. control

Determine Project Activities and Their Order

You will want to use the work breakdown structure developed in the scope definition

(Chapter 9) to assist you in determining both the activities activities and activities deliverables deliverables that will be deliverables

captured in your project timeline. You will then have to logically sequence those activities. That’s easy to do when you’re dealing with some of the initial planning and needs

assessment activities. It gets a little more complex when you get into systems implementation issues.

In any event, create a logical flow of activities. Clearly delineate when one activity

depends on the completion of another before it can get underway, as well as when the

completion of that activity signals the start of a different, new activity. Also look at what

activities can run parallel to one another.

As you are determining the various activities, make sure to define the major deliverables

and milestones and indicate if they have a preset “due” date. This will be particularly

important when we get to milestone reviews (page 134 of this chapter).

Be careful not to establish “unrealistic” milestones that can cause major schedule

problems down the line, such as:

• Creating an end date designed to impress, rather than one based on the actual

work necessary to complete the project.

• Not having quality objectives, as we discussed in Chapter 9, so that a milestone is

not complete until it meets certain quality controls.

• Shifting activities into the next milestone without a careful evaluation of the

impact and a reschedule of the rest of the project.

Estimate How Long the Activities will Take

Now that you’ve listed all the activities, deliverables and milestones, think about how

long each activity will take. This will be based on some understanding about just how

long the activity would take under ideal circumstances, augmented by several other

things: staff resources, availability and capabilities; any historical documentation on past

projects; and the assumptions and constraints you catalogued during the scope definition

process.

PMI Definitions

Activity: An element

of work performed

during a project that

normally has an

expected duration, as

well as cost and

resource

requirements.

Deliverable: A

measurable, tangible,

verifiable outcome that

must be produced to

complete a project or

part of a project.

Milestone: A

significant event in the

project, usually

completion of a major

deliverable.
Chapter 10: Develop the Project Timeline 131

— Staff Availability and Capability

When determining how long a task will take, you must consider the percentage of time

an individual (or several individuals) can devote to the task. You should also involve

those who will be working on the task to help you estimate the accuracy of the time

allotments. You must also take into consideration the staff expertise in the areas they will

be working on. If this is the first time an individual is working on a project of this nature,

training may be needed, and there may be a learning curve that will add to the project

timeline.

— Historical Documentation

Look at the schedules from past projects to help you get a realistic look at timelines,

where the project may have gone astray and what tactics kept it on track. Or ask another

department or agency for historic records to review. Remember to keep the current

project’s timeline up-to-date in order to track “estimated versus actual” timelines for use

in future projects.

— Assumptions and Constraints

You’ll also want to consult the assumptions and constraints that you documented in the

scope definition process. These issues may directly impact the timeline of your project.

For example, you may have documented that a particular “constraint” to your project

would be that County IT staff are busy rolling out a new financial system that won’t be

complete until 2 months into the projected start date of your project. The County IT staff

availability will impact your deliverables schedule and you’ll want to plan accordingly.

Schedules should be

built “from the bottom

up.” Schedules built

by people other than

those who will be

doing the work won’t

be accurate.

Obviously, appropriate

oversight and

management of this

task is necessary.

Executive Sponsors: It is tempting to want to impose a schedule on your

Project Team. DON’T! While your priorities are important and will be built into

the schedule process, you will set the project up for failure if you dictate a

schedule rather than direct your Project Manager and staff to conduct this

detailed assessment of the timeframe needed to realistically and successfully complete the

project. You can help by adjusting resources and priorities, but you should not force a

schedule on the team.
132 Part III: Create a Project Plan

Draft a Project Schedule and Seek Input

By this point, your schedule should be relatively detailed. It should have:

• Project start and finish dates.

• Activity duration estimates.

• Deliverables and milestones.

• Resources assigned to activities.

• Calendars: one for the entire project and another for staff resources that details

when each individual works, takes time off, is on vacation, etc.

Take a look at the example of an RMS project timeline on the next page and then run

your project schedule by the Project Team for a reality check.

Create a Schedule Management Plan

Scheduling, like many activities throughout the project, will be an iterative process —

but it must be managed. There will be changes to the schedule, and those changes must

be “thoroughly integrated with the other control processes,” such as scope and overall

project change control, says PMI. Aside from activity and other estimations that just may

be “off,” scheduling will change when there are scope or other major project changes.

With scheduling, there is a fine balance between creating a detailed enough schedule, yet

avoiding one that is so tightly drafted and so granular in detail from the outset that

frequent changes are necessary just to make the schedule realistic. Too many schedule

changes resulting from an unrealistic or overly detailed schedule at the outset will

frustrate managers and Project Team members, and will almost accustom them to

ignoring set deadlines.

Schedule control Schedule control should be comprised of these things: Schedule control

Schedule Management Plan. This plan will discuss how changes to the schedule will be

managed. Change requests, for example, should be required in writing.

Performance Reports. Regular performance reports provide details about project status,

including which deadlines have been met and which have not. We recommend that

performance reports — whether prepared by the vendor or internal staff — be provided

on a weekly or biweekly basis. Monthly reports are not recommended because if a

problem surfaces, it can go unchecked for a month or longer before it is reported to and

addressed by the Project Manager. This amount of lag time can make it much more

difficult to correct the problem and get the project back on track. The Project Team

should also have a “milestone review” session following the completion of major

milestones.

Project Managers:

Schedules should be

detailed. Some

sources indicate that if

the schedule is in

increments longer

than 1 week, it is not

detailed enough.

Project Team

members need a

weekly goal —

otherwise they risk

being off by a week.

Multiply that by

multiple tasks and

people, and the

project could easily

end up way off

schedule.
Chapter 10: Develop the Project Timeline 133

We suggest you use a

project management

software program to

assist you in building,

maintaining and

appropriately tracking

your project schedule.

Programs with Gantt

and other activity

dependency charts are

most useful to allow a

visual display of your

project’s activities and

their dependencies,

milestones and

timelines.

Task

Progress

Milestone

Summary

Rolled up Task

Rolled up Milestone

Rolled up Progress

Split

External Tasks

Project Summary

External Milestone

Deadline

ID

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

Task Name

Phase I: Project Orientation

Project Kick-Off, Interviews, Data Collection

Phase II: Develop the Project Plan

Deliver Conceptual Design

Phase III: Prepare Request for Proposal (RFP)

Prepare Document (Interviews, Review, Regular Meetings)

Vendors Respond to RFP

Phase IV: Proposal Evaluation and Selection

Demonstrations, Site Visits, Identify Finalist Vendor

Phase V: Contract Negotiations

Negotiate Contract, Seek County Approval

Phase VI: Implementation

Project Initiation Session

Requirements Validation/Finalize Hardware Requirements

Develop Project Plan

Hardware Off-site Installation

RMS Software Installation

RMS Subsystem Tailoring and Customization

RMS Equipment On-site Installation

RMS Subsystem Interfaces

RMS Ancillary Systems Installation

Deliver RMS As-Built Specification Documents

RMS Functional Testing

Final RMS Equipment Installation

RMS Subsystem Performance Testing

RMS User Training

RMS Production Cutover/Final Certification

RMS Refresher Training

Program Evaluation

Conduct Redeployment Tracking

 1st Half 2nd Half 1st Half 2nd Half 1st Half 2nd Half 1st Half 2nd Half

JAN MAY SEPT JAN MAY SEPT JAN MAY SEPT JAN MAY SEPT

Estimated

Project

Schedule
134 Part III: Create a Project Plan

Milestone Review. Taken together, milestones complete your entire project. Their

importance, and the quality with which they are met, are critical to the project’s success.

It is important that as each milestone is met, you gather the Project Team together to

review and analyze the milestone completion itself and the process for its completion,

and adjust the schedule for future deliverables and milestones, if necessary.

Post It!

Once the project schedule is complete, post it in a high profile location so all team

members can easily review it. The timeline will also be a component of the project Web

site to be developed, which we will discuss in Chapter 13: Prepare a Comprehensive

Communications Plan.

And remember: Keep the timeline up-to-date for archival and historical purposes! And remember: Keep the timeline up-to-date for archival and historical purposes!
CHAPTER 11

ESTIMATE COSTS AND DEVELOP A BUDGET
Chapter 11:

Estimate Costs and

Develop a Budget

What

Why

Who

When

Estimating initial and recurring costs in terms of people, materials, equipment and

services (both internal and external) to complete and maintain the entire project.

So your agency and funding bodies will know how much money to allocate toward

initial and recurring costs in order to make the project a success.

Project Manager, your parent organization’s finance representative and possibly your

grant writer (if your agency or jurisdiction has one).

Once the scope is defined and the schedule completed.

A typical annual law enforcement budget is divided between human and capital

resources, with each half competing for a shared slice of government revenue. While

agencies generally excel at budgeting for manpower and equipment, the practice of

preparing initial and recurring budgets for IT initiatives continues to evade most

agencies.

Consequently, many IT initiatives are challenged by a lack of financial and human

resources, particularly following implementation, when unanticipated support and

maintenance costs commonly arise.

In this chapter, we’ll focus on the key elements for properly estimating initial and

recurring costs for a technology initiative.

Initial Costs versus Recurring Costs. Initial costs are one-time

expenses your agency incurs, such as the purchase of a squad car.

Recurring costs are comparable to the continuing costs necessary to

operate the squad car, such as fuel, maintenance and insurance.
Part III: Create a Project Plan 138

The budget should

include estimates for:

• Hardware

• Software

• Operating Costs

• Staff Costs

• Training

• Skills Development

• Maintenance

• Consultants

The Project Budget

Agencies preparing an IT project budget will generally fit into one of three “starting

point” scenarios:

1. Our agency has been preparing for years as part of a capital improvement project,

and has X dollars dedicated for the initiative.

2. We want to buy technology, but aren’t sure of what it will cost.

3. Our agency applied for and received a grant — so let’s start spending because time

is running out!

Despite varying levels of planning, each of the three scenarios begins with the agency

preparing a “guesstimate” of how much money needs to be set aside to cover the human

and material costs for the project, both today and in the future.

During our research, we found that many agencies that failed to create a budget reported

that they either didn’t know how to do it or thought someone else (in the City or County)

was doing it for them. Therefore, in an effort to prevent the further waste of thousands, if

not millions, of dollars, we wish to definitively state: YOU ARE RESPONSIBLE FOR

CREATING YOUR OWN PROJECT BUDGET! CREATING YOUR OWN PROJECT BUDGET!

Now, let’s show you how ...

Preparing the project’s budget is not rocket science. It is actually very simple, and

requires only a few steps — and a little bit of research:

1. Gather Internal and External Cost Data.

2. Create a Project Budget of Initial Costs.

3. Estimate Recurring Costs and Include in Budget.

4. Plan for Ongoing Updates to Project Budget.

The fundamental element on which all project budgets are built is knowing what you

want to buy. Therefore, start with the project scope you developed (Chapter 9). Your want to buy

scope statement specifies the technology that is being sought (i.e., CAD, RMS, Mobile

Computing, etc.). Using those broad terms as the foundation, the first step in actually

preparing the budget is to gather the two types of cost information that are related to the

project scope: internal and external.
Chapter 11: Estimate Costs and Develop a Budget 139

Q&A:

What are cost

recovery fees?

Some agencies must

transfer funds from

their budget to that of

their parent

organization’s IT

management division

in order to “pay for”

technology support,

management, etc.

Gather Internal and External Cost Data

Internal Costs

Essentially, the internal costs are those over which your agency has direct financial

responsibility and control, including: personnel costs (i.e., Project Manager, technical

support staff, etc.), infrastructure costs (i.e., network connectivity, possibly hardware),

cost recovery fees, etc. Internal costs are the easiest to identify because they already exist

within your budget framework; they simply need to be mined and identified. Internal

costs are almost always left out of a project’s budget because they are considered “inkind,” or existing costs. Regardless of their pre-existing condition, you must identify

internal costs for two reasons:

1. Recurring Costs Recurring Costs - Although we explore the calculation of recurring costs later in Recurring Costs

this chapter, you need to recognize that the failure to identify internal costs as part

of the overall project budget will skew recurring cost calculations and lead to

unanticipated costs in the future (a very bad thing).

2. Grant Compliance - Agencies that receive grants are usually required to produce Grant Compliance

matching funds as a condition of the grant. Although internal costs can translate

into matching funds when properly budgeted, remember a COPS grantee cannot

use Federal funds in place of any local funds previously appropriated or regularly

spent on any item.

External Costs

These are the costs that most agencies associate with procurement and are generally

lumped together in three main categories: hardware, software and services. External

costs encompass more than just the vendor-supplied products and services. They also

include the staff, resources, supplies, infrastructure, consultants and virtually all project

elements that fall beyond the direct financial control of the agency or the parent organization. Specifically, the following are considered external costs:

Agencies should consider procuring their own hardware, independent of any vendor contracts, for two

reasons:

1. Law enforcement agencies are eligible for hardware discounts from many manufacturers

(vendors are not).

2. Vendors almost always levy a surcharge of between 5% – 10% on the client for having

to order/purchase hardware components.

Make sure you discuss this approach with your Technical Committee, including their ability/desire to

manage this acquisition themselves. You must also place the burden on your software vendor to provide

you with a complete and detailed list of the hardware specifications required for their software solution.

A Note About

Matching Funds:

Agencies should look

within the organization

to identify all the costs

for which they are

responsible. Allowable

matching funds will

vary, however,

depending on the

requirements of the

grant award or

program.
Part III: Create a Project Plan 140

“IT is a significant

cost to organizations;

often, IT is cited as the

number two expense,

following personnel.”

— ‘What Every

Manager Needs

to Know About

Budgeting’

Tutorial at

www.rms.net

Hardware: This includes the actual servers, workstations, laptops and other computer

hardware that will be necessary for the project, including infrastructure (network

components) and telecommunications devices (including wireless modems). Hardware

costs are usually any “capital” expense related to the project. Think of these expenses as

objects that are purchased by and reside within the organization.

Software: This includes all the software required to make the system operational,

including: operating system software (e.g., Windows NT, XP), vendor-supplied application software (e.g., Vendor X’s CAD application), third-party software (e.g., software that

is required for the proper operation of the application, such as Crystal Reports) and any

network management tools.

Services Services: These are the hourly costs that can be attributed to people doing something for

the project, including:

— project management,

— installation (if applicable, don’t forget to include mobile data device installation

fees into this category if your in-house maintenance staff will not be installing the

devices),

— training,

— support,

— consulting, etc.

In addition to the “people costs,” there are some indirect service costs that are necessary

for some types of law enforcement technology initiatives. For example, agencies may be

required to pay a recurring “service fee” to a cellular wireless infrastructure provider for

mobile data.

Other External Costs Other External Costs: Generally, “other costs” are exception-based. That is, these may or

may not be included in your budget, depending on special circumstances, such as new

building construction or a communications center remodel.

The cost of services may be difficult to ascertain from the vendor without

asking for the costs directly — vendors are often unwilling to divulge

hourly rates for specific services (such as training) unless the client

demands they be identified. What is the risk of not doing so? Vendors can

manipulate and escalate services and software customization costs after the system is

implemented, when the agency has very few options. These costs should be identified prior

to signing the contract, and should be included in the contract.
Chapter 11: Estimate Costs and Develop a Budget 141

Identifying External Costs Identifying External Costs: Unfortunately, there are no hard and fast rules for identifying

the external costs of specific law enforcement technology components. For example, it’s

virtually impossible to identify an “average cost” for a CAD system simply because there

are so many variables: agency size, vendor selected, number of required licenses, number

of workstations, level of customization and much more! The list of variables that impact

project cost is staggering and prevents the identification of averages.

Now, some good news: you aren’t the first agency to enter into an IT initiative! So don’t

reinvent the wheel. Consider the following sources for identifying your initial external

costs:

■ References (Networking) References (Networking): The least technical, and fastest, method for seeking basic References (Networking)

budget information is simply contacting agencies that have already purchased the

solution you seek. Most agencies are pleased to offer such information as a courtesy to

fellow law enforcement organizations. Simply ask them for a copy of their project’s

budget (remember, this stuff is public-accessible information, so in the rare event an

agency declined your offer, it would still be possible to access the information through

the City or County Clerk’s office). If they procured their solution through competitive

bidding (i.e., Request for Proposal process), ask them if cost summaries are available.

While information from references is usually the fastest source, it is also the least reliable

because it will not be a true apples-to-apples cost comparison. However, it should provide

you with a range of external costs that can be amended as more knowledge is obtained.

■ Request for Information (RFI) Request for Information (RFI): Prepare and issue a request for information, or RFI Request for Information (RFI)

document. Basically, it’s a written request from you (the issuing agency) to the vendor

community, asking for “ballpark” pricing and product information. The responses will

likely yield more reliable price ranges than reference checks alone, given that RFIs usually

provide the vendors with the project’s basic information, including: project scope,

internal resources and basic expectations for the project. RFIs are not without detriments: First, the RFI boldly announces to the vendor-world that you are a marketable

client. Consequently, expect a deluge of literature and phone calls shortly after issuing

the document. Second, RFIs can lead to becoming “married” to a vendor, thus skewing

the Project Team’s objectivity.

■ Outsourcing: Not surprisingly, outsourcing the cost estimating portion of the project Outsourcing

is generally the most reliable. Consultants are continuously exposed to vendor proposals

and can predict most project costs within a 5% margin of error. Naturally, such service

comes with a cost (and, ironically, becomes a budgetary line-item itself ).

Note:

See page 176

for more

information

on RFIs.
Part III: Create a Project Plan 142

Create a Project Budget of Initial Costs

Before we discuss the method for preparing a project budget of the initial (or one-time)

costs, we should clarify our use of the term “one-time.” Remember, information technology is never a one-time-only expense. Rather, it is an ongoing and permanent element of

the law enforcement business. For our purposes in this chapter, we must refer to the need

for creating a budget of the initial costs as a critical element of the overall project budget,

which must include recurring costs as well. Remember, agencies that fail to plan for Remember, agencies that fail to plan for

ongoing, recurring project expenses are more likely to fail ongoing, recurring project expenses are more likely to fail. ongoing, recurring project expenses are more likely to fail

After you gather data on the basic internal and external costs, most of the ingredients are

in place to prepare an “initial project budget” that represents the costs associated with

the initial cost impact of the project. However, you need to identify three additional costs

in the budget that are based upon project subtotals: contingency, bonding and consulting

costs.

■ Contingency costs Contingency costs: Traditionally, contingencies are calculated at 10% of the hardware Contingency costs

and software costs. However, in recent budgets, we have witnessed contingencies that are

based on 15% of total project costs. The decision should be based on the agency’s level of

knowledge of vendor performance. If your agency is conducting initial budget planning,

a larger contingency is reasonable. If your agency already has a vendor quote, the

decision should be based on feedback from previous vendor clients (remember to ask

them the percentage difference between estimated and actual costs).

Budgeting for contingencies is also important to protect your agency from unanticipated

additional costs it may have to incur. For example, your agency may find that the

computer room is too small to house additional servers once they are delivered, or that

the air conditioning system is inadequate to cool the computer room. Perhaps new T-1

lines must be added or additional software licenses were not anticipated, but are needed

at the time of implementation. Contingency funding could help offset the costs for

vendor or agency issues not anticipated, even in the most thorough planning process.

■ Bonding costs Bonding costs: Many governmental agencies require vendors to supply various forms Bonding costs

of bonding, including performance, maintenance and payment. There are nuances to

each, but for budgetary purposes, assume a cost of 1% of the total project costs for each

bond. (Note: It is possible to have the vendor pay for these costs through rigorous Note

contract negotiations, but for budgetary purposes, assume that you will be responsible.)

■ Consulting costs Consulting costs: As a rule of thumb, “full-service” project consultants — those who Consulting costs

provide needs analysis, project planning, procurement assistance, contract negotiations

and implementation assistance — will receive an average of 15% of total project costs.

The Budget

Duration

Timeline:

Initial, one-time

costs occur between

project start date and

system acceptance.

Recurring costs

occur after system

implementation.

Contingency

costs:

Funding set aside for

unforeseen, and

generally

unbudgeted,

expenditure

requirements.
Chapter 11: Estimate Costs and Develop a Budget 143

In terms of budget duration, refer to the project timeline that you developed in Chapter

10. The initial, one-time costs should cover all of the internal and external expenses that

occur during the period between project start date and system acceptance. All other costs

will be post-live date and should be considered recurring.

We suggest that agencies prepare their one-time budget using a spreadsheet application

and begin by listing the primary internal and external costs, using a range of pricing as

determined through references, RFI or outsourcing. To illustrate our suggestion, review

the following sample one-time cost summary for a fictitious RMS/JMS project. Note: The

example is a cost summary. Behind the summary would be the breakdown of individual

costs associated with each category (i.e., the specific cost of each server, workstation,

etc.).

■ Sample Initial Costs

ITEM

Hardware

Software

Services

Subtotal

Professional Services

Contingency

Bonding

Project Subtotal

ITEM

Hardware

Software

Services

Subtotal

Contingency

Project Subtotal

DESCRIPTION

Primary/Backup Server, Infrastructure, Desktops

RMS, JMS, 300 Concurrent, Minor Customization

Installation, Management, Interfaces, Modifications

Consulting

10% of Hardware/Software

Vendor Performance Bond

DESCRIPTION

None

Existing City Oracle and Windows License Fees

Existing Project Manager, 1 Support Technician

10% of Hardware/Software

LOW

$ 175,000.00

$ 750,000.00

$ 675,000.00

$ 1,600,000.00

$ 350,000.00

$ 92,500.00

$ 16,000.00

$ 2,058,500.00

LOW

$ -

$ 32,000.00

$ 140,000.00

$ 172,000.00

$ 3,200.00

$ 175,200.00

$ 2,233,700.00

HIGH

$ 260,000.00

$ 1,600,000.00

$ 1,150,000.00

$ 3,010,000.00

$ 400,000.00

$ 186,000.00

$ 30,100.00

$ 3,626,100.00

HIGH

$ -

$ 34,000.00

$ 150,000.00

$ 184,000.00

$ 3,400.00

$ 187,400.00

$ 3,813,500.00

ONE-TIME

ONE-TIME

RMS/JMS-External RMS/JMS-Internal

Project Totals

The initial project budget will naturally change as the project evolves. Depending on

which of the three starting point scenarios best applies to your agency, you may have to

adjust the initial budget on a monthly or semimonthly basis as new facts are discovered.

However, once the project nears the point of contract signing, the initial budget should

become more concrete, with the ranges of high vs. low narrowing to a margin of 2.5%

error.

This initial budget will be closely linked with the project’s Risk Management Plan

(Chapter 12), as acceptable cost over-runs must be tracked using this document.
Part III: Create a Project Plan 144

Estimate Recurring Costs and Include in

Budget

Recurring costs are generally predicted on an annual basis, although we have seen

recurring cost prediction models created on a biannual basis during the first 5 years of a

system’s usage.

The recurring costs are based upon percentages shown below, and are generally determined by whether your agency will be purchasing a vendor’s maintenance package or

conducting in-house maintenance with existing staff. The difference is clear, but be sure

to note that support costs may be internal or external, depending on your support

choice. If they are internal, be sure to include these in your budget so that funding for

these support resources continues post-implementation.

Recurring Cost Calculations

Hardware ............................. 10% of One-time Costs

Software ............................... 12.5% of One-time Costs

Services (Internal Only) ....... Dependent on Agency Compensation

Contingency ......................... 10% of the Recurring Hardware and Software Costs

■ Sample Recurring Costs

LOW

$ 17,500.00

$ 93,750.00

$ -

$ 111,250.00

$ 17,500.00

$ 11,125.00

$ -

$ 139,875.00

LOW

$ -

$ 34,000.00

$ 150,000.00

$ 184,000.00

$ 18,400.00

$ 202,400.00

$ 342,275.00

HIGH

$ 26,000.00

$ 200,000.00

$ -

$ 226,000.00

$ 20,000.00

$ 22,600.00

$ -

$ 268,600.00

HIGH

$ -

$ 36,000.00

$ 160,000.00

$ 196,000.00

$ 19,600.00

$ 215,600.00

$ 484,200.00

ITEM

Hardware

Software

Services

Subtotal

Professional Services

Contingency

Bonding

Project Subtotal

ITEM

Hardware

Software

Services

Subtotal

Contingency

Project Subtotal

DESCRIPTION

Primary/Backup Server, Infrastructure, Desktops

RMS, JMS, 300 Concurrent, Minor Customization

Installation, Management, Interfaces, Modifications

Consulting

10% of Hardware/Software

Vendor Performance Bond

DESCRIPTION

None

Existing City Oracle and Windows License Fees

Existing Project Manager, 1 Support Technician

10% of Hardware/Software

LOW

$ 175,000.00

$ 750,000.00

$ 675,000.00

$ 1,600,000.00

$ 350,000.00

$ 92,500.00

$ 16,000.00

$ 2,058,500.00

LOW

$ -

$ 32,000.00

$ 140,000.00

$ 172,000.00

$ 3,200.00

$ 175,200.00

$ 2,233,700.00

HIGH

$ 260,000.00

$ 1,600,000.00

$ 1,150,000.00

$ 3,010,000.00

$ 400,000.00

$ 186,000.00

$ 30,100.00

$ 3,626,100.00

HIGH

$ -

$ 34,000.00

$ 150,000.00

$ 184,000.00

$ 3,400.00

$ 187,400.00

$ 3,813,500.00

ONE-TIME RECURRING

ONE-TIME RECURRING

RMS/JMS-External RMS/JMS-Internal

Project Totals

Very large

organizations may

need to track recurring

costs more frequently,

given the volume of

cashflow for internal

and external support

costs.
Chapter 11: Estimate Costs and Develop a Budget 145

Plan for Ongoing Updates to Project Budget

Once the one-time and recurring cost estimates have been developed, the only thing left

to do is prepare the Project Team (and your stakeholders in general) for budgetary

updates and changes, as new information is learned or as project risks become reality.

It is critical to communicate with all Project Team members that budgets are prediction

models up to the point that a contract is signed, and then they become models guidelines guidelines. guidelines

Budgets are always subject to change, based upon unknown factors. Therefore, it is

important to create a realistic expectation that the budget may change as the project budget may change

progresses.

The extent to which cost overages are allowable will be determined by the Steering

Committee’s Risk Management Plan (Chapter 12) and available funding.

Final Advice

Before you embark upon preparing your project budget, consider the following tips:

Supplanting: Okay, we said it — the “ Supplanting S” word. Supplanting occurs when agencies budget S

money for a project, then receive grant money and replace the budgeted money with the

grant funds. This action is forbidden by most granting agencies. Therefore, when

preparing a project budget, be sure to discuss potential grant funding sources with your

parent organization before committing funds to ensure that your grant funds are

supplementing — rather than supplanting — locally budgeted funds.

Finance Representation: Remember that one of your key Steering Committee members Finance Representation

should be a representative from your parent organization’s finance department or

division. Such representatives are invaluable, as this is their specialty, so be sure to rely

upon their expertise for conducting budget and planning sessions that are in concert

with your organization.

You may also hear the

term Total Cost of

Ownership (TCO)

as you do research

and prepare your

budget. Like recurring

cost calculations, TCO

refers to the total costs

associated with

ownership, usage and

maintenance of the

system over time.
CHAPTER 12

CREATE A RISK MANAGEMENT PLAN
Chapter 12:

Create a Risk Management Plan

Risk management is a planning process that prepares the agency for dealing with

potentially harmful events that could happen in a technology initiative.

To be proactive about identifying and managing potential risks and developing

contingency plans to mitigate or avoid the negative impact of the risk. Preparing for

potential risks helps to ensure that the agency’s response is planned, measured and

controlled.

The Executive Sponsor, Project Manager and Steering, User and Technical Committees.

Risk management is conducted continuously throughout most projects, however,

formal risk management planning can only start once the scope of the project has

been identified. This is because it is difficult to identify risks until your project scope is

refined.

Most public employees correlate risk management with insurance, or perhaps the

City or County’s Risk Manager. While they both manage exposure, that’s where the

similarity ends. In technology initiatives, risk management is a forward-thinking

process that requires project leaders to envision challenges or threats to the project

and develop contingencies for handling such events. In law enforcement, this

concept is similar to the proactive vs. reactive approach to fighting crime. So, think

of this chapter as your technology initiative’s prearrival contingency planning

guide!

Risk management is an essential component that project participants often sidestep

because it requires forward thinking about events that may be inconceivable at the

project’s onset. Consequently, the vast majority of law enforcement technology initiatives

never take into account how the agency will handle events that can threaten the project’s

quality, time or budget.

Based on our contact with hundreds of law enforcement agencies, we’ve learned that

most project managers simply don’t know how to pull a Risk Management Plan together.

So, we’ll start with the basics: How to create a Risk Management Plan.

What

Why

Who

When

Executive

Sponsors: Project

teams are often

tempted to drop risk

avoidance from their

“to do” list, in favor of

more tangible and

pressing tasks. As the

Executive Sponsor,

you must motivate

your Project Team not

only to develop the

Risk Management

Plan, but also to

update it on a regular

basis. Think of the

Risk Management

Plan as your team’s

insurance policy.
Part III: Create a Project Plan 150

Products that involve

proven technology

will, all other things

being equal, involve

less risk than products

that require innovation

and invention.

— PMBOK®

How to Create a Risk Management Plan

Step 1

Identify the Risks

The initial step in preparing a Risk Management Plan is to convene the project’s User,

Technology and Steering Committees to introduce the concept that “sometimes, bad

things happen.” In fact, they happen more often than not. Remember the Standish

Group report’s statistics (see page 11), which indicate that more than half of the projects

cost nearly twice their budget and resulted in less than half of the required functionality?

Thwarting the unexpected isn’t always possible, but it is usually predictable and

manageable.

During the initial meeting, the Project Manager should ask the Project Team to identify

potential “bad things” that could happen during the course of the project. The members

should be encouraged to share war stories from other agencies, attendance at conventions, or even first-hand experiences. (This is rarely a quiet meeting!)

Examples of ideas should range from the basic to the complex,

as illustrated in the list to the left. Using Focus Group meeting

techniques like those described in Part II, the Project Manager

should write each idea on a white board or flip chart so that

each idea is clearly visible to the participants. That way, new

ideas can be measured against existing ones, ensuring that

there are no duplications. After there are about 25 to 50

items, take a break and get ready to quantify!

Step 2

Categorize and Quantify the

Identified Risks

The next step in creating a Risk Management Plan is categorizing the identified risks in three ways:

1. Likelihood: The first question that the team must resolve is Likelihood

how likely the risk is to occur, based upon what is known

today (remember that as new information is discovered,

these categories should be updated). Categorize the

likelihood in one or more of these categories:

RISK ASSESSMENT

The City/County decides not to

fund our project

Our vendor goes out of business

during implementation

Our Project Manager quits

The vendor can’t deliver the

software on time

The software we require uses a platform

other than MS Windows NT
Chapter 12: Create a Risk Management Plan 151

Remote: This risk will probably not occur. Remote

Possible: This risk might occur. Possible

Likely: This risk will probably occur. Likely

2. Area of Impact Area of Impact: Next, the Project Team should determine which of the three critical Area of Impact

project areas (time, quality and/or budget) will be impacted by the risk. Some risks

may impact one or all of these areas.

3. Severity: The team must consider the severity of the consequences of a particular Severity

risk, based upon the overall impact that such an event would have upon the

initiative. The decision on ranking the severity of a risk is clearly subjective, and is

usually based on the Project Team’s judgment and knowledge of the specific

conditions that surround the initiative. The categories for this section are:

Low: The risk is manageable through planning and action, and may not impact Low

project time, quality or budget.

Medium: The risk may be manageable through planning and action, although Medium

the event will probably have a negative impact on the project’s time, quality or

budget.

High: The risk will seriously impact project time, quality or budget. Planning or High

action may not be capable of saving the initiative.

Using our examples gained during the risk identification process, we’ve categorized them

as illustrated in the graph on page 152:

Some agencies prefer

to quantify risks

numerically,

particularly the larger

agencies that need to

deal with a large

number of issues. For

example, an agency

may give each

identified risk a

number from 1 to 10

based on the

perceived probability

(likelihood) and

severity, with 10 being

the most probable/

severe. Those risks

with higher ratings

could be dealt with

first and most

aggressively.
Part III: Create a Project Plan 152

RISK

The City/County

decides not to

fund our project

Our vendor goes out

of business during

implementation

The vendor can’t

deliver the

software on time

Our Project Manager

quits

The software we

require uses a

platform other than

MS Windows NT

LIKELIHOOD

Remote

Possible

Likely

LIkely

Possible

AREA OF IMPACT

Time, Quality, Budget

Time, Quality, Budget

Time

Quality

Time, Budget

SEVERITY

High

High

Medium

Low to Medium

Low to Medium

After identifying and classifying the potential risks, the Project Team is ready to drill

down even further into the details of the three areas that could be impacted by a risk

occurrence, including:

• How much time is likely to be lost? time

• How much of the project’s quality would be sacrificed? quality

• How much could it impact the budget? budget

Quantifying each risk may require the Project Team to make predictions that can be

refined later, as more details are discovered. In keeping with our example, the graph on

page 153 shows how we quantified our risks:
Chapter 12: Create a Risk Management Plan 153

RISK LIKELIHOOD SEVERITY TOLERANCE AREA OF

IMPACT

QUANTIFICATION

The City/County

decides not to

fund our project

Our vendor goes

out of business

during

implementation

The vendor can’t

deliver the

software on time

Our Project

Manager quits

The software we

require uses a

platform other

than MS

Windows NT

Remote

Possible

Likely

LIkely

Possible

Time, Quality,

Budget

Time, Quality,

Budget

Time

Quality

Time, Budget

2-5 Years

All Aspects

Total Budget

2-3 Months

20-30% Loss

10% Cost Overrun

2-6 Months

All Aspects

6 Months

(per IT)

$400,000

High

High

Medium

Low to Medium

Low to Medium

Avoid

Avoid

Mitigate

Mitigate

Accept

COMMON SOURCES OF RISK INCLUDE:

• Changes in requirements

• Design errors, omissions, misunderstandings

• Poorly defined or understood roles and responsibilities

• Poor estimates

• Insufficiently skilled staff

— PMBOK®
Part III: Create a Project Plan 154

Step 3

Determine Your Tolerance Level for Risks

Once the risks have been identified, categorized and quantified, the Project Team must

adopt an initial level of acceptance for each risk in advance of developing a response plan.

For each risk, the Project Team must identify one of three levels of tolerance (as illustrated in the graph on page 153):

Avoid: The avoidance label is often used for risks that have the capacity to negatively Avoid

impact the project’s budget, timeline or quality but have little known recourse. For

example, the risk within our chart regarding the vendor going out of business may be

labeled as a risk to avoid (through careful vendor evaluation and selection).

Mitigate: The majority of risks will be categorized with this label. Generally, these are Mitigate

risks that can be compensated or resolved through the development and execution of a

response plan.

Accept: The Project Team will likely find some risks to be acceptable, not requiring the Accept

development of a response plan. Generally, acceptable risks are either strategic in nature

or have minimal impact on the project’s budget, timeline or quality.

Step 4

Create a Response Plan

With each of the risks identified, classified and quantified, the Project Team should be

ready to develop a response plan. The response plan seeks to identify how the Steering

Committee and Executive Sponsor will minimize the negative impacts associated with

any risk occurrence.

The actual response will be creative and based upon the unique circumstances surrounding the initiative. Generally, however, the Steering Committee and Executive Sponsor

should consider the following:

For an impact on project time: Consider methods for preventing the slippage in the first For an impact on project time

place through (a) careful contract language (including liquidated damages, holdbacks,

etc.) and (b) the creation of a realistic timeline that assumes delays (in other words,

increasing the time necessary for various tasks based upon the assumptions of the

Steering Committee and Executive Sponsor about the risk(s) involved in various project

tasks). The response would then be predicated upon the use of contract language and

predefined actions that would help to minimize the impact on the initiative.

Liquidated

Damages: A

contract provision that

compels the vendor to

pay the police

department money if

the vendor misses a

promised deadline. As

an example, a

department may

require a vendor to

compensate them at a

rate of $1,000 per day

for each day an

interface is delivered

late.

Holdbacks: A

contract provision that

allows the Sheriff’s

office to keep a

percentage of a

vendor’s invoice until

after the vendor

successfully

completes certain

milestones (like

project completion).

Holdbacks are useful

for keeping the vendor

interested in

completing all of the

tasks associated with

a project, even those

that are less profitable

than others.
Chapter 12: Create a Risk Management Plan 155

For an impact on project quality: Attempt to verify the vendor’s full range of capabilities For an impact on project quality

very early on in the procurement process. Many Risk Management Plans call for vendors

to verify their ability to perform before contract signing, while others refuse to consider

vendor products that cannot supply 80% or more of the required functionality. Additional tools include the insistence that vendors subscribe to fulfilling the letter of the

contract as well as the spirit. In such circumstances, agencies identify both the functional

specifications (the precise description of how a product should operate), as well as the

conceptual goal (a high-level description of how a product should function). Again, the

enforceable contract language would determine the response.

For an impact on project budget For an impact on project budget: In general, projects will cost more than original For an impact on project budget

estimates. By identifying the extent of a budget overage in the Risk Management Plan,

the Steering Committee and Executive Sponsor can identify a project contingency that

should be a concrete budgetary line item. As a general rule, agencies should assume that

their project will require 10%–15% more funds than those originally estimated. The

response for these occurrences should identify those situations in which the Steering

Committee is willing (and unwilling) to approve budgetary overages.

Maintaining the Plan

As referenced throughout this chapter, new risks are continuously being identified, while

existing risks are refined. Therefore, each Project Team meeting should include a few

minutes to discuss the Risk Management Plan, providing for new discussions and

updates throughout the entire project lifecycle. Remember, devastating risks could arise

even in the final phases of a project!

Risk Management Plan:

Essential and Indispensable

Armed with a comprehensive Risk Management Plan, the project leaders are much more

likely to manage events as they occur in a manner that takes advantage of available

human and financial resources, rather than simply reacting randomly. A Risk Management Plan allows the project’s Steering Committee and Executive Sponsor to control the

project, rather than allowing unscheduled events to steer the project.

Aside from the clear benefits of accountability and management, projects that are

designed with a comprehensive Risk Management Plan are perceived more positively by

project sponsors and elected officials, because these key individuals are made aware of

potential problems well in advance of their occurrence. Consequently, the project’s

management demonstrates control of the project’s time, quality and budget.

“

”

Risk

management

helped make us

successful and

meet our

deadlines.

— Tom Hennig

San Joaquin County

(CA) Sheriff’s

Department
CHAPTER 13

PREPARE A COMPREHENSIVE

COMMUNICATIONS PLAN
Chapter 13:

Prepare a Comprehensive

Communications Plan

Communications

planning involves

determining the

information and

communication needs

of the stakeholders:

who needs what

information, when will

they need it and how

will it be given to

them.

— PMBOK®

Strategies for communicating project status and activities to key stakeholders, and

methods for developing historical project records and archives.

First, to keep users and stakeholders informed, involved and up-to-date on project

activities. Second, to create a “paper trail” of historical documentation critical when

personnel change, for grant reporting purposes and for future project planning.

Project Manager.

Begins at any time during the Build the Foundation or Project Planning phases and

continues through the life of the project.

We’ll talk about communications in this chapter on two tracks: First, disseminating information to groups of individuals through status reports, written documentation, messages, electronic media, etc. Second, the need to document project

information for historical and reporting purposes. Both of these strategies should

be outlined in the “Communications Plan” chapter of your Project Plan.

Keep the Right People Informed

It should be a major priority during your project to keep the lines of communication

open among not only all Project Team members and the decisionmaking structure, but

also with all end users and interested parties. There are different types of information

needed depending on the group you are communicating with, and many ways to

communicate the information.

First, determine the different groups who need project information, such as:

• The Steering Committee

• The Project Team

• Users and stakeholders not directly involved in project activities

• External agencies

• Funding bodies and granting agencies

• The public

What

Why

Who

When
160 Part III: Create a Project Plan

Second, for each of these groups, you must determine the type of information they need, type

the level of detail they need and detail howoften they need it. For example, the Project Team often 

members will frequently (weekly, or depending on deliverables, daily) need a great deal

of detailed information (accomplishments, deadlines missed, problems, risks, issues,

decision items) about the project.

The Steering Committee, however, will need regularly scheduled (monthly) status reports

(major accomplishments, any challenges or setbacks that require their intervention) and

decision issues (major issues that require policy, funding or operational decisions).

You should determine a consistent schedule and method(s) for communicating project

status, information and updates. For some agencies, a departmentwide newsletter

distributed on a monthly basis is sufficient. Others provide oral briefing reports, and yet

others use email to share weekly project status and updates.

Creating a project Web site is one of the most effective methods of tracking the project

accomplishments and issues, posting documents and making other stakeholders outside

your agency aware of the project. Web site development for projects that include multiple

agencies and jurisdictions agencies and jurisdictions is the best method for communicating among the agencies. agencies and jurisdictions

Many agencies find that a combination of two or more of these methods works best.

You may want to build a chart like the one on the next page to help develop your

communications plan with each group. You should involve representatives from each

group to provide input and feedback as to the details of what each group will need, when,

and in what format.
Chapter 13: Communications Plan 161

Group

Info Needed

(Type) Detail Frequency

Communication

Method

Steering Committee Project status: Major

accomplishments,

problems or issues

that need resolution

High-level Monthly or during

regularly scheduled

project-related

meetings

Written status report

and oral report by the

Project Manager

during the meeting

Project Team

Members

Detailed information

about project

schedule, activities,

deadlines, plans,

issues, risks and

problems

V y ery specific A n t least weekl Variety: Email, writte

memos, oral reports

during meetings, both

scheduled and ad hoc

(if reports are oral, all

discussions must be

captured in minutes)

Users General updates about

project activities,

achievements and any

variations in schedule

General Monthly Monthly newsletter or

Web site (big events,

activities,

achievements may

warrant a special

email alert)

P t ublic General update abou

project activities,

achievements and

status

G y eneral M e onthl Web sit

External Agencies General update about

project activities,

achievements and

status

General Monthly Web site or Intranet

F , unding Bodies Project activities

accomplishments,

deadlines, funds

expended to date and

related budget issues

Detailed with regard

to funding

When reports are due

or requested

Formal, written

documentation
162 Part III: Create a Project Plan

Get Input and Feedback

You should not only send out information, but also create a means for gathering information and feedback on the project. Examples of input/feedback procedures you can

establish include Web-based forms, suggestion boxes, email messaging, chat sessions and

online editing.

Establish a Paper Trail:

Create the Project Filing Cabinet

It’s not uncommon in law enforcement agencies for personnel to “inherit” a project from

a predecessor. In career development, sworn personnel are often assigned on an annual

or biannual basis to different units within a department, including those dealing with

information technology. IT projects are often handed off mid-stream or before they’ve

officially begun, and often change hands several times before they are complete. Nothing

is worse than picking up a project mid-stream and having little or no documentation

about what has been done so far, what has been promised, what reports have (or have

not) been filed, and most importantly, how much money has been spent!

Part of your Project Plan is to create a strategy and methodology for documenting and

maintaining files on project activities. You should have a method and organized means

for keeping the following items:

1. Project Records Project Records. Any documentation regarding the project, including correspon- Project Records

dence, reports, memos, grant applications and awards.

2. Performance Reports Performance Reports. Also known as status or project reports, these documents Performance Reports

provide analysis on project scope, schedule, budget and performance on a regular

basis to the stakeholders, funding agencies and other users/requestors.

3. Change Requests Change Requests. As we’ve discussed in previous chapters, all changes (to scope, Change Requests

schedule, cost) must be handled through a formal and established written approval

process. All change requests should be documented and kept in the project files.

4. Problem Escalation and Resolution. In Chapter 1 (page 36) we discussed creating a Problem Escalation and Resolution

formal mechanism for how problems were to be resolved throughout the life of the

project. You should keep documentation of the problems and their resolution in

the project file cabinet.

5. Formal Acceptance. Include documentation on system acceptance testing (covered Formal Acceptance

in Part V, Chapter 17) and the signed acceptance itself.

6. Lessons Learned. This is an extremely useful document that will assist you in Lessons Learned

future technology projects. Once your project is complete, take the time to

document things that worked, things that didn’t work and the lessons you learned

from beginning to end. Don’t think you will remember for the “next time.” Write it Write it

Key players in your

technology initiative

may come and go

over the duration of

the project. All,

however, will be held

accountable by parent

organizations and

elected officials. That’s

why all key players

must commit to

developing and

maintaining accurate

communication plans.
Chapter 13: Communications Plan 163

down! And remember, someone else may need to refer to this document for a new down!

project they are planning.

7. Project Archives Project Archives. At some point, all project records will need to be archived. Project Archives

Historical databases, financial records, etc. may require formal processing and

archiving. A fully indexed project records set should be organized and stored at

your agency.

The Project Web Site

A project Web site is an excellent means for providing project documents and status

reports to a wide variety of interested parties. If you develop a project Web site, make

sure that you keep it up-to-date with the latest project news, activities and documents to

keep visitors coming back. If developing your own Web site isn’t possible, consider the

use of a Microsoft SharePoint Web service, which provides a preformatted project

management Web environment.

“

”

The project

status Web

page was by far

the single most

important tool

to keep our

vendor

committed to

the project

timeline.

— Ronald Glensor

Deputy Chief,

Reno (NV) Police

Department

■ Marin County (CA) Integrated Law Enforcement Information System Project

Web Site Screenshot #1
164 Part III: Create a Project Plan

■ Marin County (CA) Integrated Law Enforcement Information System Project

Web Site Screenshot #2

■ Kent (WA) Police Department Police Systems Replacement Project

Web Site Screenshot #1
Part III Assignments 165

EXECUTIVE SPONSOR

Role 1. Ultimate decisionmaker

2. Provide oversight and guidance

Project Planning 1. Commit to structured project planning; endorse and

Tasks sign Project Plan (Chapter 8)

2. Be sensitive to change management (Chapter 8, page 117)

3. Use the Project Plan (Part III)

4. Approve final project scope and ANY changes made to

scope from this point on (Chapter 9, page 125)

5. Do not force a schedule on the Project Team if at all

possible; instead, direct the team to develop a realistic

timeline (Chapter 10, page 131)

6. Review and approve project budget (Chapter 11)

7. Make risk management planning a priority

(Chapter 12, page 149)

STEERING COMMITTEE

Role 1. Provide knowledge and recommendations

2. Remove project barriers

3. Update/inform Executive Sponsor

4. Review key documents

Project Planning 1. Endorse and sign Project Plan (Chapter 8)

Tasks 2. Review and approve scope statement, project objectives

and Scope Management Plan (Chapter 9)

3. Provide input to, review and approve project timeline

(Chapter 10)

4. Provide input as needed during budget development

process (Chapter 11)

5. Participate in risk management planning (Chapter 12)

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

PART III ASSIGNMENTS
166 Part III: Create a Project Plan

PROJECT MANAGER

Role 1. Coordinate all tasks and activities

2. Keep aggressive meeting schedule to get the Project Plan

completed

3. Facilitate meetings

4. Solicit input and approvals from the Steering Committee

and Executive Sponsor

5. Conduct research regarding elements of project plans and

look at other agency plans

6. Document all findings

Project Planning 1. Lead User and Technical Committees in detailed project

Tasks scope definition (Chapter 9, page 121)

2. Detail scope based on a variety of inputs

(Chapter 9, page 122)

3. Produce work breakdown structure (Chapter 9, page 123)

4. Prepare Scope Management Plan (Chapter 9, page 125)

5. Prepare the project timeline based on User and Technical

Committee input (Chapter 10, page 129)

6. Create a management plan that will control the project

schedule (Chapter 10, page 132)

7. Develop the project budget (Chapter 11)

8. Lead meetings to identify project risks and their associated

ratings and tolerance levels, and create the Risk

Management Plan (Chapter 12)

9. Develop and implement a communications plan to address

information needs of various stakeholders (Chapter 13)

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

PART III ASSIGNMENTS, CONTINUED
Part III Assignments 167

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

USER COMMITTEE

Role 1. Provide input to Project Manager on scope, timeline,

budget, risk, communications

2. Conduct research within your own unit/area of

responsibility to gather comprehensive information for

the Project Plan

3. Meet on a weekly basis with Project Manager during

development of the plan

Project Planning 1. Assist in detailing project scope (Chapter 9, page 122)

Tasks 2. Define project objectives in terms of quality, time, cost,

performance, reliability and functionality

(Chapter 9, page 124)

3. Help develop the project timeline by accurately estimating

staff availability and capability in relation to the project

(Chapter 10, page 131)

4. Assist with development of project budget

(Chapter 11)

5. Participate in risk management planning (Chapter 12)

TECHNICAL COMMITTEE

Role 1. Provide input to Project Manager on scope, timeline,

budget, risk, communications

2. Conduct research within your own unit/area of

responsibility to gather comprehensive information for

the Project Plan

3. Meet on a weekly basis with Project Manager during

development of the plan

Project Planning 1. Assist in detailing project scope (Chapter 9, page 122)

Tasks 2. Define project objectives in terms of quality, time, cost,

performance, reliability and functionality

(Chapter 9, page 124)

3. Help develop the project timeline by accurately estimating

staff availability and capability in relation to the project

(Chapter 10, page 131)

4. Assist with development of project budget

(Chapter 11)

5. Participate in risk management planning (Chapter 12)

PART III ASSIGNMENTS, CONTINUED
168 Part III: Create a Project Plan

What’s Next?

Procure the Technology .................................................................... Chapter 14

Contract With a Vendor ................................................................... Chapter 15

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○
“Obstacles are those frightful things you

see when you take your eyes off the goal.”

— Henry Ford

Part IV:

Acquire the

Technology
GRANT COMPLIANCE NOTICE

Recipients of COPS Office grants are obligated to comply with certain requirements

when implementing grant-funded technology projects. These requirements include

Federal regulations. We recommend that your agency be thoroughly familiar with these

regulations:

■ 28 CFR 23, Criminal Intelligence Systems Operating Policies

■ 28 CFR 66.36, Uniform Administrative Requirements for Grants and Cooperative

Agreements to State and Local Governments: Procurement

■ 28 CFR 66.32, Uniform Administrative Requirements for Grants and Cooperative

Agreements to State and Local Governments: Equipment

The full text of these regulations can be accessed online at

http://www.access.gpo.gov/nara/cfr/cfrretrieve.html#page1. For more information on other areas

of compliance, see Chapter 19, Grant Management and

Compliance.
CHAPTER 14

THE ART OF PROCUREMENT
Chapter 14:

The Art of Procurement

What

Why

Who

When

A structured method for determining the required hardware, software and services

needed to fulfill the project goals and objectives.

In addition to meeting government mandates for purchasing, a well-planned procurement will (a) ensure that the chosen vendor can supply the agency’s functional

requirements, (b) foster competitive vendor pricing and (c) offer the agency choices

with regard to products and services.

Steering Committee, Project Manager, User and Technical Committees, and the

parent organization’s finance and purchasing representatives.

Once the decision has been made to purchase new technology.

Conducting a procurement is oddly similar to playing a game that is replete with

rules, penalties and winners. Most would agree that the biggest difference lies in

the fact that procurement is rarely fun.

Procurement is a process that enables your agency to create functional requirements and seek qualified providers. While the requirements should be sufficiently

detailed to allow the vendors to supply an accurate technical and cost solution, it

should not be so detailed as to border on data modeling or system design (after all,

if that were the case, you would be hiring programmers and not seeking a vendor

solution).

Law enforcement agencies are often frustrated by the complexity of purchasing

products and services. In this chapter, we seek to simplify some of the more

complex components of procurement by providing an overview of the process, a

review of how to select the right tool to get the job done, a suggested outline for

how to evaluate vendor offerings and, finally, a simple method for creating

functional specifications.

Procurement is governed by many rules that must be adhered to as a condition of being a

governmental agency. Those rules generally dictate how the procurement must be

conducted, although there is normally a good deal of agency discretion with regard to

creating the requirements and evaluating the vendors’ proposals. Nevertheless, require- Nevertheless, requirements should be well defined and the process should always be thoroughly followed. ments should be well defined and the process should always be thoroughly followed
174 Part IV: Acquire the Technology

A bid protest occurs

when one or more

vendors object to an

element of the

procurement process,

usually caused by the

agency’s failure to

follow the selection

process outlined in

the bid document.

When a bid protest

occurs, the vendor’s

attorney files a legal

notification with the

City or County,

notifying them of the

protest. The City or

County will ordinarily

suspend the

procurement until

such time that the

matter has been fully

resolved (which

usually requires

several months).

Therefore, playing by

the rules is absolutely

imperative.

Failure to adhere to rules or to clearly define requirements can result in a legal action

called a “bid protest” (or can cancel the process entirely — see sidebar).

After receiving the vendor proposals, your agency has the opportunity to carefully review

the various choices, seeking to identify the product that most closely meets your agency’s

needs. Ultimately, a winner is chosen and the project will move from the procurement

phase into the contract negotiations phase (see Chapter 15). The process normally

requires between 4 and 10 months, and it all starts in your own backyard.

LEARN FROM THEIR MISTAKES!

One Michigan city learned the importance of clearly defined requirements the hard way. It

was forced to issue its RFP three separate times because of technicalities found by the

City’s purchasing department after the documents had been released.

Step 1

Research Your Jurisdiction’s Procurement

Requirements

Youmust start the procurement process by gathering the specific procurement require- must start the procurement process by gathering the specific procurement requirements of the parent organization. Normally, the purchasing division or the City/County ments of the parent organization

attorney’s office will be able to provide you with a list of these required elements, which

often include the following:

■ Procurement Thresholds Procurement Thresholds: Most City or County governments have ordinances that Procurement Thresholds

require competitive procurement if the value of the purchase exceeds a certain dollar

amount (usually, the range is between $10,000 and $50,000). Therefore, the budget that

was developed in Chapter 11 will likely determine whether a competitive procurement is

necessary.

■ Advertising Requirements Advertising Requirements: Per local, regional or State law, governments are often Advertising Requirements

required to advertise their procurements in at least one publication for a specified period

of time. This requirement is often overlooked and is a common cause of bid protests.

■ Delivery Rules Delivery Rules: Aside from the due date (which is usually set by the agency), there may Delivery Rules

also be rules for how vendor proposals are to be submitted, including:

• The acceptability of electronic or faxed responses.

• The ability to submit responses via “overnight” delivery.

• The ability to include both vendor pricing and product offerings in a single

package.
Chapter 14: The Art of Procurement 175

■ Preproposal Conferences: Preproposal Conferences: Many organizations require that a preproposal conference Preproposal Conferences:

be held 2 or 3 weeks after the bid is released. Normally, conference attendance is

optional, but some City/County ordinances make them mandatory (i.e., if the vendor

fails to show up for the conference, the company is automatically disqualified). The

conferences usually last about 90 minutes and include the following: a vision statement

from the Executive Sponsor(s), a response to questions submitted by vendors (in writing

or orally), and a tour of the agency facilities.

■ Bid Opening Processes Bid Opening Processes: There are rules that dictate how to open a vendor’s response. Bid Opening Processes

For example, some agencies are required to open the envelopes (or boxes) in a public

forum, while others must have specific government employees present at opening (e.g.,

purchasing agent, attorneys, etc.). We also strongly suggest at this stage that you

designate a single point of contact single point of contact from your agency with the vendors. The procurement single point of contact 

process requires clear and unambiguous communication between the two parties. You

must ensure there is a single source of information and communication with the vendors.

Step 2

Form an Evaluation Team

It’s a good idea to form an Evaluation Team comprised of a cross-section of the Project

Team plus a representative from purchasing and, possibly, a City/County attorney (the

attorney will be useful in preparations for contract negotiations).

We suggest that you try to keep the Evaluation Team’s size to a minimum (around 6-10

people) because they will take on many time-consuming responsibilities during the

procurement process, such as analyzing all the proposals that are received, attending

vendor demonstrations, making telephone calls to vendor references, visiting references

(site visits), and attending Project Team meetings. Also, from a financial perspective,

remember that the Evaluation Team will likely be required to attend site visits that can be

costly if the sites are remote. The first task of the newly formed Evaluation Team is to

select the right tool for procuring the required technology.

Step 3

Select a Procurement Tool

Although a request for proposal is the most widely used tool for conducting a procurement, there are several other options that may be better suited to your agency’s needs.

Review the following five procurement tools to determine which is best suited to your

particular needs:

Be sure to prevent

vendors from

establishing “sidebar”

meetings with agency

employees — such

action can create the

appearance of

“collusion” and is

detrimental to the

procurement process.

Also, be prepared for

the vendors to ask

whether the project is

fully funded and

whether an extension

in filing proposals

could be granted.
176 Part IV: Acquire the Technology

1. Request for Proposal (RFP)

An RFP is a classic tool used by agencies seeking to obtain actual hardware, software

and services proposals from vendors, including proposed costs that address the

agency’s specific needs.

When to use an RFP: While an RFP delivers a complete proposal package, it requires a When to use an RFP

significant investment of time from the agency (particularly with regard to preparing

functional specifications related to the application that you need to purchase).

Therefore, an RFP is best suited to agencies that require a complete proposal response

from vendors (including costs) and that have ample time (at least 4–6 months) and

resources to properly prepare and execute the RFP process.

Normally, an RFP is used by agencies that are “serious” about procuring technology,

rather than those that are merely “testing the water” or seeking information. Aside

from the complexity of the process, an RFP will cost both the agency and the proposing vendors a significant amount of money. Preparing an RFP costs an average of

$50,000 in agency “in-kind” costs, while vendors spend an average of $25,000 to

respond to RFP documents (personnel time, document preparation, printing,

attendance at preproposal conferences, etc.).

Sections of an RFP Document Sections of an RFP Document: Sections of an RFP Document

A. Project Background: Provides the project’s history and outlines the major Project Background

applications being sought.

B. Rules of Preparation: Informs vendors of your agency’s rules for conducting the Rules of Preparation

procurement.

C. Volumes Volumes: Describes various statistics that help the vendors to size their Volumes

proposal (e.g., number of workstations to be licensed).

D. Vendor Response: Provides questions that pertain to the vendor’s qualifica- Vendor Response

tions, experience, proposed solution and pricing.

E. Functional Response: Provides functionality questions that are specific to the Functional Response

type of applications (see Step 5).

2. Request for Information (RFI)

An RFI is a document used to elicit generalized information about vendor products

and services. Pricing, if included at all, is generic and based on averages.

When to use an RFI When to use an RFI: An agency that seeks general information about a vendor’s When to use an RFI

products and services should use an RFI. Due to the fact that a proposal is not

requested, the RFI is noncompetitive and, therefore, does not require the same level of

planning and action of other procurement-related tools (such as an RFP). An RFI can

also be used as a precursor to an actual bidding document (i.e., RFP).

Resist the “full

disclosure”

temptation. While it is

important to inform

vendors of the

project’s purpose and

history, it is unwise to

inform them of the

project’s budget, grant

information or issues

that may be

compelling your

agency to act quickly.

Otherwise, these

issues could come

back to haunt you

come contract

negotiation time!
Chapter 14: The Art of Procurement 177

Note: In addition to

the procurement tool

sections described in

this chapter, all of the

tools — whether RFP,

RFI, RFQ, ITB or Solesource — should

include an appendix

that contains agencyspecific information

(e.g., Application

Program Interface

information,

organizational charts,

glossary and

definition of terms,

etc.) that would be

useful for vendors in

preparing their

responses.

Sections of an RFI Document Sections of an RFI Document: Sections of an RFI Document

A. Project Background: Defines the project’s purpose and informs vendors of the Project Background

scope of your inquiry (i.e., which applications you are interested in learning

more about).

B. Rules of Preparation: Briefly informs vendors of when your agency expects to Rules of Preparation

receive a response and any other general conditions of the RFI.

C. Volumes Volumes: This optional section provides information on your agency’s particu- Volumes

lar environment.

D. Requested Information: In this section, your agency should define exactly what Requested Information

it is interested in knowing about the vendor’s products and services (e.g.,

references, descriptions of products, normal implementation timeline, budgeting guidelines, key contact information, etc.).

3. Request for Qualifications (RFQ)

An RFQ seeks to determine whether a vendor meets minimum qualification standards

set by the issuing agency. Like an RFI, the RFQ does not request a proposal response

with prices and specific proposal details.

When to use an RFQ: Agencies frequently use an RFQ to establish a bidder’s list in When to use an RFQ

advance of conducting an actual procurement. The RFQ sets the bar for vendor

attributes and seeks to identify those vendors that will meet the agency’s minimum

standards. An RFQ, like an RFI, is a generally harmless document because it does not

place vendors in competition with one another. However, unlike the RFI, vendors

often respond quickly to an RFQ if they can meet the agency’s requirements because

the RFQ is an indication of a near-term RFP process. Although the RFQ is noncompetitive, it definitely needs to be reviewed by purchasing and City/County attorney

staff before release to ensure that your agency is not defining unlawful or unreasonable standards (e.g., the vendor’s name must start with a Z, etc.). Such mistakes could

corrupt the bidder’s list and, ultimately, a future procurement.

Sections of an RFQ Document Sections of an RFQ Document: Sections of an RFQ Document

A. Project Background: Provides vendors with basic information about the history Project Background

and purpose of the project.

B. Rules of Preparation: Briefly informs vendors of when your agency expects to Rules of Preparation

receive a response and any other general conditions of the RFQ.

C. Qualifications Request Qualifications Request: This section can assume two formats: It can either ask Qualifications Request

vendors to define their qualifications in various areas (references, hardware

standards, software platform, etc.), or your agency can define the standards and

ask if the vendor can meet or exceed them (e.g., System must be Microsoft XP

compliant - Yes/No).
178 Part IV: Acquire the Technology

4. Invitation to Bid (ITB)

The rarest of all procurement tools, an ITB defines the agency’s requirements and

contract inclusions, offering vendors an opportunity to “take it or leave it.” The ITB is

competitive in the event more than one vendor accepts the bid.

When to use an ITB: Rarely. An ITB is a complex document that includes When to use an ITB all of the

agency’s requirements, contractual terms and pricing mandates. Most importantly,

the contents of an ITB are not subject to negotiation — vendors either accept all the

terms or none. Therefore, preparing such a document is usually best left to professional external entities (consultants or attorneys). ITBs are usually only used when the

parent organization mandates that such an approach be taken.

Sections of an ITB Document Sections of an ITB Document: Sections of an ITB Document

A. Project Background: Provides the project’s history and outlines the major Project Background

applications your agency is seeking.

B. Rules of Preparation: Informs vendors of your agency’s rules for conducting the Rules of Preparation

procurement, including the contract that vendors must agree to, without

exception.

C. Volumes Volumes: Describes various statistics that help the vendors to size their Volumes

proposal (e.g., number of workstations to be licensed).

D. Vendor Response: Identifies your agency’s requirements for vendor hardware, Vendor Response

software, service, performance and pricing.

E. Functional Response: Identifies your agency’s functional requirements, asking Functional Response

the vendors to identify any exceptions. In an ITB, it is assumed that vendors will

supply all of the listed functionality.

5. Sole-source

In a sole-source procurement, the agency can show that the chosen vendor is the only

vendor capable of supplying the required hardware, software and services in the best

interest of the agency.

When to use a Sole-source Justification: In instances involving upgrades, or when an When to use a Sole-source Justification

agency is certain that only one vendor can supply the required technology. When

upgrading, justifying a sole-source procurement is fairly simple (functionality,

training, implementation, costs and speed are usually compelling issues that favor an

upgrade). Conversely, crafting a sole-source justification for a CAD, RMS or Mobile

Computing vendor is risky unless the vendor truly offers a very unique solution.

Otherwise, losing vendors can protest a sole-source justification in a maneuver similar

to a bid protest. (Vendors routinely check local, regional, State and Federal registers

that show government purchases.)
Chapter 14: The Art of Procurement 179

Sections of a Sole-source Justification: Agencies are required to use the U.S. Office of Sections of a Sole-source Justification

Management and Budget guidelines (see 28 CFR 66.36) for preparing a sole-source

justification. In summary, the guidelines require the following sections: Expertise of the

Contractor, Management and Responsiveness, Knowledge of the Engagement, Experience of the Contractor Personnel, Time Constraints, Uniqueness of the Vendor, Additional Information and Declaration.

Step 4

Develop Functional Specifications

We previously made reference to functional specifications, which are simply detailed

descriptions of exactly what you expect the new applications to do. The specifications are

extremely important because during procurement, vendors are required to divulge how

closely their product matches your functional requirements.

Most proposals contain thousands of specifications for each major application (CAD,

RMS, etc.) and are derived from the general specifications that you developed in Chapter

6. Your agency can compile specifications by asking the operational experts operational experts (users) to operational experts

write descriptions of the functionality they hope to attain by implementing new

technology. Encourage users to be as specific as possible: the more detailed the

description, the more valuable the specification.

For example, if the broad requirement is to provide dispatchers with additional tools to

check on unit status, the specification may read: “Ability to set audible reminders for

dispatchers to check the status of a unit after a user-defined period of time.”

We recognize that developing functional specifications can be an enormous challenge for

your agency, particularly if staffing is limited. Again, agencies that can’t (or don’t want

to) develop their own specifications are left with the standard choices: either outsource

this element to an external specialist (consultant) or network with other law enforcement

agencies that have recently completed procurement. Whenever possible, avoid reinvent- Whenever possible, avoid reinventing the wheel ing the wheel! ing the wheel

Borrowing another agency’s functional specifications does come with some degree of risk.

After all, what if your needs don’t exactly match up to theirs? To manage this, it will be

necessary for you (and your staff ) to read and amend every single specification! Other- read and amend every single specification

wise, you run the risk of ranking your vendor responses based upon the needs of others.

Regardless of how they are developed, functional specifications should be categorized

into a logical order (e.g., all dispatching specifications should be contained within a

single section titled “CAD Functionality,” etc.) and inserted into the appropriate location

within a bidding document (RFP, ITB, etc.). Then, response codes should be created to
180 Part IV: Acquire the Technology

allow vendors the opportunity to define how their proposed solution can meet the

specification. We suggest the use of codes that represent narrative responses that you

control. Allowing vendors to provide a narrative response greatly enhances the ambiguity

of their proposal and should be avoided. Once the codes are established, simply place

some brackets in the margin next to each specification to allow the vendors to “fill in the

blanks” with one of your codes. In keeping with our previous example, a common

specification with ordinary response codes would look like this:

VENDOR RESPONSE

a. Ability to set audible reminders for dispatchers

to check the status of a unit after a user-defined

period of time:

A. Exists in our current solution

B. Is under development

C. Minor customization required

D. Report-writer required

E. Major customization required

F. Not available in our solution

VENDOR RESPONSE OPTIONS

[ ]

Upon receipt of the vendor’s proposals, these functional responses should be tallied and

compared (see Step 6 for the evaluation and selection process).

A couple of words of caution regarding the creation of functional specifications:

• Occasionally we see agency RFPs that have functional specifications that all start

out with “System must have the ability to...”. Be judicious about using the words must have

must have because they represent an imperative that negates most of the response

codes. More importantly, if something is a must, then vendors will try to develop a

technical option for supplying it, which could result in higher-than-normal

customization costs.

• Avoid lengthy descriptions of functionality that contain more than one tightlyfocused specification. It might prevent vendors from accurately responding with a

single response code.
Chapter 14: The Art of Procurement 181

Step 5

Create Evaluation and Selection Criteria

Most agencies must include the evaluation and selection criteria in the bid documents,

per governmental requirements. However, it’s a good idea to include the information

even if you don’t have to because it allows vendors to better understand how you will be

evaluating their responses, and it compels you to plan ahead for how the evaluation will

occur. Like many procurement-related concepts, the evaluation and selection criteria may

be determined by the parent organization, so always remember to include a purchasing

representative in planning meetings.

The list below represents some standard criteria that are frequently used in the industry.

If your agency requires a mathematical ranking of each proposal, simply assign a numeric

value to each of the 16 criteria that will total 100 points. For illustrative purposes, we have

inserted some sample rankings:

POINTS

3

5

10

13

5

5

11

11

5

5

5

5

5

4

5

3

NUMBER

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

Remember: Failure

to follow local

procurement

requirements could

result in a failed

procurement!

CRITERIA

Adherence of the proposal to the specified format

Completeness of the proposal

Quality and depth of references

Level of service and responsiveness that the vendor commits to providing to

the agency

Financial stability and resources of the vendor

Experience and technical expertise of staff

Design, capability and functionality of system and application software, as

determined by the Evaluation Team

Current availability and ability to demonstrate installation of the proposed

software applications required by the agency

Level of integration between applications and demonstrated interfaces

with external systems/devices

Capability, design, reliability, warranty and expandability of proposed hardware

Economic feasibility and justification of all costs

Vendor willingness and ability to negotiate a contract acceptable to the

agency

Feasibility, timeliness and quality of the software implementation schedule

and conversion plans

Level of vendor assistance to be provided to the agency during the

implementation process

The number of hours and extent of user training

Quality and extent of the documentation to be provided
182 Part IV: Acquire the Technology

As spelled out in detail in Step 6, the Evaluation Team should carefully review each

proposal using these 16 criteria. If necessary, a quantitative score could be assigned to

each proposal based on a scale of 100, and the top two scoring vendors could be deemed

qualified to present an oral demonstration of their system’s capabilities to your Evaluation Team. If there is no need for a mathematical ranking, simply state that the Evaluation Team, at their sole discretion, will identify two semifinalist vendors that will be

invited to make oral demonstrations.

In terms of evaluating a vendor’s performance at an oral demonstration, we suggest the

use of survey instruments to gauge the feedback of personnel who will observe the

demonstration. Again, if a mathematical ranking is necessary, we suggest that the 16-

criteria scale be modified (to reflect the oral presentation instead of a written proposal)

and reused for the demonstration.

Shortly thereafter, the Evaluation Team should identify a single finalist vendor that will

undergo a comprehensive review (including telephone reference checks, site visits and a

possible secondary interview). Ultimately, the finalist vendor would be invited to enter

into a contract negotiation process with your agency (if negotiations are permitted by

your agency) and a contract would be signed. (See Chapter 15 for details on contract

negotiations.)

Step 6

Evaluate Bid Responses and Select a Finalist

Upon receipt of the proposals, your agency should review each response to determine

which systems are best able to meet your agency’s requirements. Evaluation Team

members should review each proposal for completeness and to ensure that it properly

addresses the functionality requirements of the bid document. You should take the

vendor’s specification responses to each category (CAD, RMS, etc.) and plot them sideby-side, for an easy-to-view comparison.

During this portion of the project, the methodology established in Step 5 (Evaluation and

Selection Criteria) should be applied, thus eliminating those vendors that fail to meet the

requirements.

Using the evaluation criteria as a guide, the Evaluation Team should evaluate qualified

proposals in depth. For each proposal, the team should (a) summarize, evaluate and rank

information pertaining to each major area of the specifications, and (b) obtain additional

information and clarification from responding vendors as required. Finally, the team

should narrow the list of vendors to two semifinalists that will be evaluated through

vendor demonstrations.

Evaluation Team:

- Review

- Summarize

- Evaluate

- Rank

- Clarify

- Choose semifinalists

Vendor Demos:

- Create an agenda

- Define scope

- Establish timeframe
Chapter 14: The Art of Procurement 183

During vendor demonstrations, your agency should prepare an agenda that identifies

what you want to see, rather than what the vendor wants to show you! You should insist

upon vendors demonstrating the products that have been proposed, instead of those that

are in development or planned for future release. The duration of the demonstration is

subject to your particular scope and need, ranging from a couple of hours for a specific

product demonstration (e.g., a laptop device) to a full week for a comprehensive, multiapplication review.

Ordinarily, the consultant or Project Manager will distribute survey forms that ask

evaluators to rank the vendor using the relevant criteria discussed earlier (Evaluation and

Selection Criteria). Following the demonstration, the survey results should be tabulated

and presented to the Evaluation Team for review. Based on the results, the team should

be capable of identifying a single finalist vendor for further review.

Once a finalist vendor has been identified, the Evaluation Team must undertake some

additional steps before determining whether the ranking vendor is “the one,” including:

■ Telephone Reference Checks Telephone Reference Checks: Evaluation Team members should contact their peers at Telephone Reference Checks

the reference sites listed in the vendor’s proposal response, as well as any others who are

identified through the process, seeking to learn more about the vendor’s performance.

The team should meet prior to conducting the calls and develop a list of questions that

are pertinent to the project. In addition to technology-specific questions, be sure to ask

some of the following:

• Was the project completed on time?

• Was the project completed within budget?

• In general, was your experience with the vendor favorable?

• If you had to do it over, would you still choose vendor X?

Be sure to allow at least 2 weeks for telephone interviews to be conducted (to allow for

call backs, missed calls, etc.) before reconvening the team.

In the City of Reno/

Washoe County (NV)

Public Safety and

Justice Project, the

Project Team

developed specific

scenarios and

provided data for the

vendor to demonstrate

with its products. The

team found that this

approach avoided the

“canned” sales demo

and required the

vendor to prove its

products could handle

the scenarios and the

agency’s data.

Obviously, vendors will provide their top references and successes. You should do a little

extra work and find out about other agencies using the products to get a full understanding

of user satisfaction. Make sure to spend ample time talking to end users of the product.

Sometimes technical staff will love an application, but users may have major problems with

the functionality of the product.
184 Part IV: Acquire the Technology

■ Assess Vendor Fit Assess Vendor Fit: Following the telephone reference checks, the team should meet Assess Vendor Fit

again to determine whether to continue with the review of the finalist, or select the

“runner-up” vendor, as an alternative.

■ Site Visits Site Visits: Assuming the vendor passes the reference checks, the next step is to Site Visits

schedule and conduct operational site visits of reference agencies that are the most

similar (in terms of project scope and size) to your agency. Usually, two visits will suffice,

although we have seen agencies conduct as many as six.

Like vendor demonstrations, we strongly suggest preparing an agenda for the site visit

that maps out what your Evaluation Team hopes to accomplish. The agenda usually

includes:

• An interview with the agency’s project manager.

• An opportunity to speak with users of the technology.

• An opportunity to witness the technology “in action” (e.g., visit a communications

center, see a laptop operating in the sunlight, etc.).

■ Discuss Site Findings Discuss Site Findings: Following the site visits, the Evaluation Team should meet again Discuss Site Findings

and discuss the findings based upon the selection criteria identified in the proposal

documents.

If, after the various examinations, the vendor remains a viable candidate, your agency

should notify the vendor that the company has been identified as a finalist vendor and

that contract negotiations may begin shortly. As a courtesy, you should also send

notifications to semifinalist vendors as well, requesting that they keep their proposals

valid in the event that your agency is unable to reach a successful agreement with the

finalist.

Now that you’ve identified the finalist, it’s on to contract negotiations!

After paying a site visit

to another agency,

your Executive

Sponsor should follow

up with a thank you

letter to the agency’s

Chief or Sheriff. This

point of etiquette is

often overlooked, but

can pave the way for

future consultations

with successful users

of the product, should

you contract with the

same vendor.
CHAPTER 15

CREATE THE CONTRACT
Chapter 15:

Create the Contract

What

Why

Who

When

A binding agreement between the agency and the chosen vendor that defines the

obligations between the parties, including deliverables, services and responsibilities.

Note: The terms “contract” and “agreement” are used interchangeably throughout Note

this chapter and mean the same thing.

Failure to negotiate a favorable agreement will leave the project exposed to tremendous risk and probable destruction.

A single authorized negotiator must be identified on both the side of the agency

(usually the Project Manager), as well as the vendor. Additional resource persons,

such as the parent organization’s legal counsel (City or County Attorney), should also

participate.

As soon as your agency identifies a finalist vendor.

For most police agencies, the contract negotiation process is the most difficult and

foreign project task. It’s particularly foreboding because the agency is at an

immediate disadvantage: your Project Manager is likely not an attorney and may

never have negotiated a contract, whereas the vendor will assign one or more

attorneys who negotiate contracts for a living.

Further increasing the difficulty is the immense pressure that agency negotiators

often feel during the process as they recognize that a leading factor in law enforcement technology failure is a poorly-worded contract.

This chapter seeks to take the mystery out of contract negotiations by explaining

the basic process and elements of a well-crafted vendor contract. In addition to

providing an overview of what to expect during the process, we’ll also explore the

actual documents that should be included, adding advice along the way for

securing the most advantageous language. Finally, we’ll review some tips for

helping to keep negotiations running smoothly and, ultimately, successfully. We

strongly recommend that your agency get help from the start of this process from

an attorney who is an expert in IT contract negotiations. Not that it can’t be done 

without one, but you must realize that your agency is at a disadvantage when

inexperienced agency staff negotiate with a vendor’s experienced team of contract

negotiators and attorneys.

Disclaimer:

You must follow the

policies and

procedures governing

contracts within your

jurisdiction. This

chapter is meant to

provide guidance and

offer best practices in

doing so, but is not

intended nor should

be construed as

providing legal advice

specific to your

situation and

jurisdiction. Please

see general disclaimer

on page 3.
188 Part IV: Acquire the Technology

Understanding the Process

The entire contract negotiation process will likely require several months of dedicated

effort from both the agency and the vendor. An average duration is approximately 4

months, yet more complex engagements have been known to require more than a year to

complete. The lengthy time requirements are driven by the multitude of documents that

must be prepared, as detailed in this chapter.

From the standpoint of the contract negotiation process, the following six steps are

normally required:

1. The agency prepares a draft primary agreement based upon advice from legal

counsel.

2. The primary agreement is supplemented with information from consultants and/

or the Project Team about the project’s scope.

3. The agency and vendor hold a discussion to identify the appropriate exhibits that

must be developed and combined with the agreement.

4. The agency prepares an initial draft of the contract with the related exhibits and

provides it to the vendor.

5. Meetings are held between the parties to identify the debatable issues — including

pricing — and suggest language changes.

6. A final agreement is reached and the contract is provided to elected officials for

ratification (or, in rare instances, a single project sponsor may have signatory

authority to approve a document without elected official approval).

Usually, step 5 is repeated many times over, with the parties debating various contractual

issues and refining the related agreement documents.

Crafting the Contract Documents

The creation of a solid contract is often a collaborative effort involving Project Team

members and external experts, including consultants and City/County attorneys. Your

agency’s legal counsel will ordinarily supply the contract’s framework, along with various

terms and conditions that are jurisdictionally required, ultimately creating a primary, or

“umbrella” agreement. Contract consultants are often useful for supplementing the City/

County attorney’s work, offering unique insight into the field of public safety software.

Finally, the Project Team is responsible for “filling-in” the project-specific information

that is gleaned from the vendor’s proposal response, usually in the form of exhibits to the

primary agreement.

Agencies should

never use the

vendor’s base

agreement, as it

places the vendor in a

commanding position

over the contract

structure and,

ultimately, the entire

project.

Pricing is always

negotiable. Rely upon

your budget, prepared

in Chapter 11, to

determine what the

products and services

should cost. If the

vendor pricing

appears too high,

request a percentage

discount to bring the

prices within the

project’s budget.

Remember, it never

hurts your position to

ask for reduced

pricing or other

incentives (e.g.,

additional services or

software licenses).
Chapter 15: Create the Contract 189

From a global perspective, the contract itself has a clear hierarchy, with the primary

agreement taking precedence over the exhibits, which fall beneath it:

City/County

 Required

 Terms/Conditions

“Legalese”

Numerous

 References

 to Exhibits

Defines

 Legal

 Obligations

 of the

 Parties

EXHIBITS

— Statement of Work

— Project Deliverables

— Project Timeline

— Payment Schedule

— More

■ Primary “Umbrella” Agreement

Components of a Contract

Before we get into the details of what topics should be included in the primary agreement

and related exhibits, a word of caution: Although this chapter reveals major categories

that should be included in any public safety software contract, it cannot substitute for the

experience of your legal counselors and expert consultants.

Primary Agreement

The place to start is with the City or County Attorney. He or she will probably provide a

copy of the City or County’s “standard boilerplate” agreement and begin to make

adjustments, based upon the scope of the project. If the attorney has never negotiated a

public safety contract, or is unfamiliar with software or hardware contracts, consider the

use of an external contract consultant who specializes in law enforcement software/

hardware contracts. Ordinarily, the primary agreement includes language that addresses

the following:

The most common

contract “sticking

points” usually relate

to indemnification and

penalties for failure to

perform (such as

liquidated damages,

defined in

Chapter 12).
190 Part IV: Acquire the Technology

■ STATEMENTS OF FACT

Definition of the Parties

Purpose of the Agreement

System Price

References to Exhibits

Form of the Agreement

Time for Performance under the Agreement

■ GENERAL CONTRACTS LANGUAGE

(modified for software contracts)

Contractor Rights

City/County Rights

Grounds/Procedures for Termination

– Default

– Bankruptcy

– Convenience

Laws to be Observed

Governing Law

Permits/Licenses

Taxes, Insurance, Expenses

Limitation of Liability

Indemnification and Hold Harmless

Force Majeure

Third-party Beneficiaries

Nondiscrimination Standards

Conflict of Interest

Notices

Modifications

Waiver

Headings

Number/Gender

Severability

Counterparts

Order of Precedence

Patents/Royalties

News Releases

Immigration Laws

Time is of the Essence

Confidentiality

Bonding

– Performance, Payment

■ SPECIFIC PROJECT REGULATIONS

Order/Delivery of Hardware

Equipment Condition

Site Preparation

What Constitutes Acceptance of Hardware and

 Software (see Chapter 17)

Rights to Source Code

The Role of Third-party Software Applications

The Role of External Equipment/Software

Documentation Standards

Training Requirements

Right to Conduct Background Checks on Vendor

 Employees

■ RECURRING VENDOR RESPONSIBILITIES

Contractor Commitments, Warranties, Representations

Basic Maintenance

Upgrade Process

Enhancement Procedures

■ PROJECT MANAGEMENT LANGUAGE

Problem Resolution (Arbitration, Other Methods)

Delivery and Installation Procedures

Certifications

Payment Terms

Management of Delays

Liquidated Damages for Contractor-caused Delays

Storage of Materials

Change Orders

Status Reporting

Contractor Obligations

The Right to Replace Vendor Project Manager/

 Employees

These general terms and conditions will comprise the umbrella

agreement, while project-specific material will need to be developed, based upon the vendor’s proposal and as a consequence

of meeting with the vendor and agreeing as to what the vendor

will be providing throughout the project.

THE PRIMARY AGREEMENT
Chapter 15: Create the Contract 191

Exhibits

Normally, attorneys will not offer advice on the exhibit-related content, simply because

they don’t understand it! Further, they generally assume that their client (the police

agency) is sufficiently knowledgeable in the product and services to create the related

exhibits to their own satisfaction.

Therefore, it’s up to the Project Team to prepare a list of exhibits and draft their general

content. The exhibits will be unique for each contract. Nevertheless, there are some

exhibits that we strongly suggest be included, as follows:

■ Statement of Work (SOW) Exhibit Statement of Work (SOW) Exhibit: The blueprint for your implementation, this Statement of Work (SOW) Exhibit

element of the contract defines each task involved in the entire project, which usually

includes the following for each purchased application (or technology):

– Project Kickoff

– Requirements Validation and Hardware Review

– Project Schedule Delivery

– Hardware Installation

– Base Software Installation

– Software Customization (if any)

– Interface Development and Testing

– Geofile Building (usually only for CAD)

– Ancillary System Installation and Connection (e.g., NetClock, etc.)

– File Building

– Documentation Delivery

– Training

– Interface Testing

– Production Cutover

– Functional Testing

– Reliability Testing

– Performance Testing

– Product Certification

– Refresher Training

Then, for each of the tasks listed above, the SOW should:

– Provide a description of the task.

– Identify personnel involved in the task.

Executive

Sponsors: City/

County Attorneys will

often equate

technology contracts

with public works or

other infrastructure

contracts. While there

are similarities (i.e.,

high-dollar deliverables, multiple and

complex services,

bonding requirements,

etc.), the two are

vastly different. Using

a public works

contract “template” for

a technology endeavor

can leave gaping

holes (i.e., the

absence of language

regarding performance, licensing, etc.)

and is strongly

discouraged.

Think SOW!

The SOW defines the

“who, what, where and

when” for virtually

every aspect of the

project.
192 Part IV: Acquire the Technology

– Identify the dates/times when the task is scheduled to occur.

– Identify the vendor and agency responsibilities related to the task.

– Describe what is considered to be completion of the task.

■ Training Plan Exhibit Training Plan Exhibit: A critical, and often overlooked, section of the SOW is the Training Plan Exhibit

development of a comprehensive training plan. Agencies must carefully evaluate the

vendor’s training options and craft a training plan that ensures adequate training for

both users and technical support staff. To better prepare you for developing the training

plan aspect of the SOW, consider the following:

— Training Types — Training Types

Direct Training. Direct Training. Direct training is often used when the pool of students is relatively Direct Training. 

small and requires intensive training (e.g., CAD dispatcher training). Due to the

one-to-one training relationship, this type of training is usually the most expensive.

Train the Trainer. Train the Trainer. The most common training approach, this method provides Train the Trainer. 

direct training to a small group of employees focused on both learning the

application, as well as how to train the balance of the organization’s employees. It

is generally the least expensive training option because it uses the fewest vendor

resources and relies heavily upon the agency to train its own.

Refresher Training. Refresher Training. About 6 weeks after going live with an application, many Refresher Training. 

agencies benefit from “refresher training,” wherein the vendor’s training staff

returns to the agency to revisit various training concepts and address questions

from users.

Mobile Patrol Training. Mobile Patrol Training. For large agencies, herding the entire patrol staff into Mobile Patrol Training. 

classroom training sessions can be difficult, especially with reduced workforces

and insufficient overtime budgets. To compensate for both, some agencies take the

training to the officers in the form of mobile training centers. Using a van or even a

vehicle (preferably without the cage), trainers can provide training to various

employees during their shift, in their area/beat.

— Training Location

Few police agencies are blessed with their own technology training centers,

requiring the agency to carefully consider where training will occur. Most vendors

will require that the agency supply a training facility with variable equipment

requirements, depending on the technology being implemented. Generally,

vendors recommend that agencies provide a room that is equipped with about a

dozen networked PCs, with a large overhead projector and screen toward the front

of the room.

Remember: If it’s

not in the SOW, it’s

not going to happen!

Many agencies have

found that video or

audiotaping training

sessions is an

invaluable tool. The

tapes can be used as

“refresher” training for

existing employees or

to partially train new

employees.
Chapter 15: Create the Contract 193

If your agency does not have additional space that can be dedicated for several

weeks to a training effort, consider relocating training to your parent

organization’s facilities or outsourcing to a local private technology training center.

— Training Costs — Training Costs

External: External: As you review the project budget, you will find that training is one of the External:

most costly elements. Training usually requires the vendor to provide on-site

visitations over an extended period of time. The visits can be costly to the vendor

in terms of travel and resources: While the trainer is working with your agency, he/

she cannot be actively involved in vendor sales, demonstrations or development.

Consequently, training costs tend to be very high, with the vendor seeking to

provide as little training as you are willing to accept.

Internal: Internal: The financial impact of training employees on new technology is obvi- Internal:

ously influenced by the type of technology being implemented and the size of your

agency. The least expensive internal costs are usually associated with CAD

implementations because the training is usually focused exclusively on the

dispatch employees. Conversely, the highest costs tend to be associated with RMS

products, as they usually require the training of a broad mix of employees,

including patrol, records, detectives, etc. Whenever line-level employees require

training, remember to forecast overtime expenses into your agency’s annual

budget.

■ Project Deliverables Exhibit Project Deliverables Exhibit: This section of the contract identifies Project Deliverables Exhibit everything that is

being supplied by the vendor that has a direct cost, including: hardware (description of hardware

equipment), software (full description of modules, interfaces, licenses, etc.) and software services services

(e.g., 100 hours of training at a rate of $500/hour, etc.).

Items that are excluded from this exhibit will reappear as change orders, so be extraordinarily diligent when reviewing the information. Because so much of the project

deliverables exhibit is of a technical nature, the project’s Technical Committee must

review the document before contract signing.

Note: Make sure to stipulate that the vendor provide the Note: most recent versions of software

and hardware at the time of delivery. This is critical, as there may be new releases

between the time the RFP is released, a vendor is selected, the contract is negotiated and

installation begins (sometimes upwards of 18 months).

Don’t be tempted to

reduce training to

satisfy budget

constraints: Lack of

adequate training is

the third most

common reason for

project failure!

 * * *

In the rare event the

vendor doesn’t supply

a list of project

deliverables in a

spreadsheet format,

insist on it!
194 Part IV: Acquire the Technology

Description

Contract Signing

Hardware Delivery

CAD Acceptance

RMS Acceptance

Training Completion

Documentation Delivery

Total System Acceptance

TOTAL

% of Total

2%

8%

15%

25%

15%

10%

25%

100%

Amount

$ 30,000

120,000

225,000

375,000

225,000

150,000

375,000

$1,500,000

EXHIBIT X — SAMPLE PAYMENT SCHEDULE

■ Payment Schedule Exhibit Payment Schedule Exhibit: A key component of the contract, this document serves to Payment Schedule Exhibit

identify when the vendor will be paid for tasks that are identified in the SOW. We suggest

a milestone-based payment schedule, in which the vendor is paid a percentage of the

contract for the successful completion of a particular project element. Here is an

example:

SOW Task Number

1

2

3

4

5

6

7

When negotiating the agreement, be sure to insist that the project timeline be

finalized before contract signing, to maximize the advantage and usefulness

of related agreement language. Also, consider mandating that any change in

schedule be approved in writing by both Project Managers (agency and

vendor). Finally, be sure that the schedule is prepared and maintained in a project

management software format for ease of management and update.

■ Project Timeline Exhibit Project Timeline Exhibit: The project timeline is a critical document because it defines Project Timeline Exhibit

the amount of time that will be required for the tasks identified in the SOW (plus a few

extras like project status meetings, etc.). That definition is crucial to the main agreement

language that controls various time-sensitive issues (such as liquidated damages, timetriggered payment incentives, or time-triggered holdbacks). The project timeline exhibit

is different from the overall project timeline that was developed during the creation of the

Project Plan. The project timeline exhibit is ordinarily prepared and maintained by the

vendor.

Remember:

Delivery does not

equal acceptance. See

Chapter 17, page 213,

to learn more.
Chapter 15: Create the Contract 195

■ Geofile Construction Document Exhibit Geofile Construction Document Exhibit: Agencies that are purchasing CAD applica- Geofile Construction Document Exhibit

tions must often convert their parent organization’s base geographic information

systems (GIS) into the CAD vendor’s preferred format. The GIS data are used for creating

a geofile in the CAD that verifies the addresses that are entered into CAD. Ordinarily,

undertaking such a procedure is exceptionally complex and warrants an individual

contract exhibit dedicated exclusively toward defining how the GIS material will be

converted, tested and ultimately installed into the CAD. Elements of this exhibit often

include:

• Defining all of the known information regarding the existing GIS resources (e.g.,

format, date of creation, accuracy in terms of x/y coordinates, human resources,

etc.), and

• Defining the vendor’s roles and responsibilities in the conversion, testing and

installation phases.

■ License Agreement Exhibit License Agreement Exhibit: Unless the attorneys have spelled out licensing agreement License Agreement Exhibit

language in the primary agreement, it will have to be developed as an exhibit. This

exhibit defines what rights the agency has with regard to the use of the vendor’s software,

which is normally licensed in one of three ways: individual workstation, concurrent user

or site license. The type of licensing will ordinarily determine the content of this exhibit.

If you are unfamiliar with license agreements, delegate their preparation to an expert

(attorney or consultant).

■ Agreement for Extended Services Exhibit Agreement for Extended Services Exhibit: Agencies that require the vendor to provide Agreement for Extended Services Exhibit

continuous product support will need to prepare this exhibit. The document will identify

the type of service (telephone, on-site, etc.), the availability (e.g., 8-5 each day or 24/7,

etc.) and the allowable timeframe for response and correction of various types of

problems (e.g., on-site within 24 hours if the system completely shuts down, or a phone

call within 10 minutes of a report of trouble). Finally, the document will detail the pricing

that has been negotiated for recurring support (ideally, with a 5-year cap). If you are

unfamiliar with support agreements, delegate their preparation to an expert (attorney or

consultant).

■ The Vendor’s RFP Response Exhibit The Vendor’s RFP Response Exhibit: That’s right! The vendor’s claims and assertions The Vendor’s RFP Response Exhibit

that were made in their response to your bid document are included as an exhibit.

Countless engagements have been saved by this simple procedure, which is linked to the

order of precedence language in the primary agreement (just identify the RFP response as

being the arbiter of functionality disputes). Because the response is often hundreds of

pages in length, a simple reference will suffice (in lieu of copying/inserting the whole

thing into the agreement). Make sure to include reference to all addendums and negotiated changes to the RFP. The contract should also mention which specifications prevail,

should the contract and RFP response be in conflict.

Be sure to negotiate

an escalation

procedure into the

Agreement for

Extended Services, in

which various priority

issues are upgraded to

the next highest level

after a specified period

of time. Also, try to

have the severity level

changed based on

“aggregate”

complaints (i.e., if you

have 50 little

problems, that in and

of itself becomes a

problem at the next

highest level).
196 Part IV: Acquire the Technology

■ Software Warranty Exhibit Software Warranty Exhibit: Vendors generally offer a 1-year warranty on parts and Software Warranty Exhibit

labor. However, the duration is negotiable and can be 2 years or longer. After negotiating

the duration, this exhibit includes the details about what constitutes a warranty-related

repair issue and the procedures for activating the document. Again, unless you are very

comfortable with the language of the software warranty, ensure that experts have

reviewed and approved of the language before signing the contract.

■ Subcontracts Exhibit Subcontracts Exhibit: Occasionally, vendors will partner with subcontractors to fulfill Subcontracts Exhibit

a portion of the SOW. Be sure to have a copy of the agreement that exists between the

prime vendor and any subcontractors. That information is instrumental in preventing

finger pointing and getting results! The contract should specify that the primary vendor

is responsible for the action and/or inaction by the subcontractor, not the agency.

■ Acceptance Test Criteria Exhibit Acceptance Test Criteria Exhibit: Acceptance test plans and criteria are a must for any Acceptance Test Criteria Exhibit

software project. See Chapter 17 for information on creating portions of this document.

■ Interface Control Document (ICD) Exhibit Interface Control Document (ICD) Exhibit: If the project includes interfaces, it must Interface Control Document (ICD) Exhibit

also include an ICD, which articulates how the interface(s) can and will operate. As a

general rule, the agency cannot supply too much information about any given interface. cannot supply too much information about any given interface

Interfaces that are concretely defined are less subject to delays and excuses! As a sample

ICD format, consider the following:
Chapter 15: Create the Contract 197

Interface Name

Interface Summary

Vendor X CAD Version

Vendor Y RMS Version

Vendor Y System Interface

Data Elements to be Exchanged

External System Interface

Protocols

Vendor Y Hardware Interface

Vendor Y Tasks

City Tasks

API Locations

Comments

Vendor X CAD data to Vendor Y RMS

Transfer of Vendor X CAD data to Vendor Y RMS product.

V 2002.1

V 3.45

Custom software development for Anywhere PD to use message

switch device to transfer data from CAD.

List of specific fields that need to be transferred from CAD to

RMS (i.e., call number, location, etc.).

TCP/IP

TCP/IP

CAD server Ethernet adapter.

Install and test internal communications software and connect to

City-provided network hub or switch equipment.

Provide City message switch communications and associated

equipment beyond hub.

See Appendix B for CAD API.

None

■ Documentation Exhibit Documentation Exhibit: This exhibit clearly defines the type of documentation to be Documentation Exhibit

provided under the contract, specifying the medium (CD, paper, other) and whether the

documentation is site-specific. (Some agencies must have the vendor’s documentation

amended by technical writers to reflect customization — this is often called “as-built

documentation.”)

■ Other Exhibits Other Exhibits: Remember, each contract is unique and requires site-specific docu- Other Exhibits

ments that would be developed over the course of the contract negotiation. There is never

a limit to the number of exhibits that can be attached to a contract.
198 Part IV: Acquire the Technology

Tips for Negotiating a Solid Contract

Single Points of Contact Single Points of Contact: Negotiating a contract of complexity requires clear and Single Points of Contact

unambiguous communication between the parties. To accomplish this, it is necessary to

assign a single representative from the Project Team (usually the Project Manager) to

communicate with a single representative from the vendor’s organization. This clearly

defined channel of communication will go a long way toward ensuring that neither the

agency nor the vendor are making promises that are not referenced in the contract.

Consider Videotaping Negotiation Meetings Consider Videotaping Negotiation Meetings: Recently, some agencies have recorded or Consider Videotaping Negotiation Meetings

videotaped their negotiation meetings with the vendor. The recording can be used as an

exhibit to the primary agreement for use in clarifying contract language (or showing

intent). While this approach has benefits in solving disputes, be sure to remember that

the agency’s assertions are also captured in the recording and are equally useful to the

vendor.

Handling Disputes Handling Disputes: During the course of contract negotiations, disputes will occur! Handling Disputes

Handling them in a professional manner will convey a sense of authority and place the

agency in a more commanding position. First, let’s review a few “Nevers”:

1. Never scream.

2. Never become violent.

3. Never embarrass yourself or the agency with unprofessional behavior.

You may be surprised that we would go to the length of listing these three “nevers” in a

publication written for peace officers. However, the authors have witnessed all three,

more than once (including a memorable moment when a project manager leapt across a

table and attempted to stab a vendor with a pen). In each instance, the behavior became

the issue and, ultimately, weakened the agency’s position.

How will you know when an issue has reached impasse? When one or more of the

following occur:

• A party says they simply cannot negotiate the issue.

• A party repeats their position more than once.

• An issue is debated for more than 10 minutes, with no apparent resolution in sight.

These three are just a few of the triggers for shelving the issue or taking a break. Remember that the party who takes command of the situation is in a stronger position, so don’t

hesitate to make a judgment that an issue should be temporarily suspended.
Chapter 15: Create the Contract 199

What’s Next?

Plan for System Implementation ...................................................... Chapter 16

Conduct Quality Assurance Testing ................................................. Chapter 17

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

Ultimately, issues that are impassable usually will be resolved through concession from

both parties. In such difficult issues, consider using language that enables “mutual

agreement,” such as “system acceptance will be determined by mutual agreement” as a

potential solution. Parties are often willing to agree to this because it enables both sides

to reserve the right to further debate the issue, should it ever arise.

Controlling Changes Controlling Changes: During the process, hundreds of changes will be made to contract Controlling Changes

documents. It is imperative that changes be evident to both parties (it is never advisable

to “sneak” one past your vendor). We suggest using a word processing application that

enables revision tracking and comment insertion.

Renegotiating the Contract Renegotiating the Contract: Surprisingly, few agencies are aware that contracts are often Renegotiating the Contract

subject to amendment and renegotiation. While making changes to a contract after it has

been ratified is not optimal, it is nevertheless possible so long as both parties are

mutually agreeable to the change.
200 Part IV: Acquire the Technology

EXECUTIVE SPONSOR

Role 1. Ultimate decisionmaker

2. Provide oversight and guidance

3. Provide leadership and support

4. Make personnel available for vendor evaluations and

site visits

Acquire the 1. Attend the preproposal conference and articulate the

Technology Tasks agency’s goals with regard to the project to the

competing vendors (Chapter 14)

EVALUATION TEAM (A SUBSET OF THE PROJECT TEAM)

Role 1. Provide knowledge and recommendations

2. Update/inform Steering Committee

3. Participate in all phases of procurement and contract

negotiations

4. Review, evaluate and select vendor

Acquire the 1. Form the Evaluation Team to participate in procurement

Technology Tasks and contract negotiations; augment with parent

organization’s finance representative and, possibly, the

City/County attorney (Chapter 14, page 175)

2. Select a procurement method (Chapter 14, page 175)

3. Review and approve procurement documents and

functional specifications (Chapter 14)

4. Evaluate responses from vendors (Chapter 14, page 182)

5. Conduct interviews, reference checks and site visits

(Chapter 14, page 182)

6. Select finalist vendor (Chapter 14, page 182)

7. Assign a single point of contact for the vendor/contract

negotiations, usually the Project Manager

(Chapter 15, page 187)

8. Participate in contract development (Chapter 15)

9. Prepare a list of and draft contract exhibits

(Chapter 15, page 191)

 10. Develop a payment schedule and project timeline to be

included in the contract (Chapter 15, page 194)

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

PART IV ASSIGNMENTS
Part IV Assignments 201

PROJECT MANAGER

Role 1. Coordinate all tasks and activities

2. Conduct all phases of procurement research

3. Prepare the procurement tool

4. Coordinate vendor demonstrations, site visits and

interviews

5. Act as single point of contact with vendor authorized for

contract negotiations

Acquire the 1. Research jurisdiction’s procurement requirements

Technology Tasks (Chapter 14, page 174)

2. Coordinate Evaluation Team duties, such as procurement

document development, evaluations, vendor

demonstrations, site visits and reference checks

(Chapter 14, page 175)

3. Lead User and Technical Committee focus groups to

develop functional specifications (Chapter 14, page 179)

4. Prepare the procurement document (Chapter 14)

5. Prepare draft contract based on legal advice and

jurisdictional requirements (Chapter 15)

6. Prepare a list of and draft contract exhibits

(Chapter 15, page 191)

7. Develop a payment schedule and project timeline to be

included in the contract (Chapter 15, page 194)

8. Formally track changes to contract documents

(Chapter 15, page 199)

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

PART IV ASSIGNMENTS, CONTINUED
202 Part IV: Acquire the Technology

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

USER COMMITTEE

Role 1. Provide input to the Project Manager and Evaluation Team

on procurement documents and vendor responses/

demonstrations

Acquire the 1. Participate in focus groups and develop written

Technology Tasks descriptions of functionality for new technology

(Chapter 14)

2. Develop vendor response criteria for functional

specifications (Chapter 14, page 180)

3. Create evaluation and selection criteria

(Chapter 14, page 181)

4. Participate in vendor demonstrations

(Chapter 14, page 183)

TECHNICAL COMMITTEE

Role 1. Provide input to the Project Manager and Evaluation Team

on procurement documents and vendor responses/

demonstrations

Acquire the 1. Participate in focus groups and develop written

Technology Tasks descriptions of functionality for new technology

(Chapter 14)

2. Develop vendor response criteria for functional

specifications (Chapter 14, page 180)

3. Create evaluation and selection criteria

(Chapter 14, page 181)

4. Participate in vendor demonstrations

(Chapter 14, page 183)

PART IV ASSIGNMENTS, CONTINUED
“Those parts of the system you can hit

with a hammer (not advised) are called

hardware; those program instructions that

you can only curse at are called software.”

— Anonymous

Part V:

Implement the

Technology
CHAPTER 16

PREPARE AN IMPLEMENTATION PLAN
Chapter 16:

Prepare an Implementation Plan

What

Why

Who

When

An Implementation Plan is the blueprint that enables project management to define

the rules that will guide the project toward completion.

Failure to conduct implementation planning could lead to missed deadlines, vague

responsibilities and, almost certainly, costly change orders.

The Project Managers (for both the agency and the vendor) work together with the

respective Project Teams to form an Implementation Team; the Steering Committee

and Executive Sponsor review and approve the Plan.

Implementation planning starts once the Statement of Work has been finalized. If the

project kick off is next week, you’ve waited too long!

This chapter may seem familiar if you prepared a Project Plan (as outlined in Part

III). An Implementation Plan is merely a variation of the Project Plan that includes

new material related to the vendor’s obligations. This chapter defines the documents that need to be collected or prepared in order to develop the implementation blueprint, also known as the Implementation Plan.

Creating the Implementation Plan

Did we mention that successful technology initiatives require careful planning? Like the

Project Plan that guided the Project Team to this point, the Implementation Plan is the

blueprint for completing the project. It is different from the Project Plan because your

Project Team now has an important new member — the vendor!

Although the primary agreement (as discussed in Chapter 15) includes a Statement of

Work and an “initial project plan,” nothing specifically addresses the “who, what, where,

when and why” like a solid Implementation Plan that can be used by both the agency and

the vendor.

The good news about creating an Implementation Plan is that most of your work should

already be done. Creating the plan merely requires that the Implementation Team modify

the “Project Plan” that was created in Part III to accommodate the role of the vendor.

Therefore, before you begin to craft the plan, you’ll need to retrieve two documents: your

Project Plan and your vendor agreement.

Remember: The

vendor agreement is

also known as the

contract, and consists

of a primary

agreement and a

variety of exhibits. See

Chapter 15.
208 Part V: Implement the Technology

What to Put in the Plan

The following is a description of the primary elements of a useful Implementation Plan.

Remember, each plan is unique, so adding or subtracting elements is normal.

This is merely a one-paragraph summary of the project’s general scope,

timeline and budget.

Look to your contract for the Project Deliverables Exhibit (you do have one,

don’t you?). Simply cut-and-paste it into this section, which defines what will

be delivered and when.

Use this section to record what has happened and when. Because this will

become a living document, it’s very important to record when something is

scheduled to be complete and, ultimately, when it was completed. Usually, a

simple three-column chart will suffice (Who, What, When).

All projects have unique terms and acronyms that need to be clearly defined

for all members to prevent confusion. You probably already have a glossary in

your RFP, so just cut-and-paste it into this section.

In keeping with the concept of planning ahead, this section mimics the Project

Plan’s approval process, in which the actual approval processes for

deliverables are defined. The only difference here is that you must be sure that

the approval process for vendor deliverables is consistent with the agreement

language. If you’re not sure, have your attorney or consultant review the

language first.

Again, taking the project organizational chart from the Project Plan, modify it

to include the vendor’s staff.

This brief statement addresses the potential use of subcontractors (e.g., your

vendor is supplying mobile hardware from a third-party vendor). This section

articulates the relationship between the vendors.

NOTE: As recommended in Chapter 15, your contract should specify that the

primary vendor — not your agency — is responsible for the action and/or

inaction by the subcontractor! Be sure this language makes it into the

Implementation Plan as well.

Refer to your vendor agreement for the specific responsibilities of the

contractor and the agency. Inserting those responsibilities into the Implementation Plan ensures that project participants without access to the agreement

documents clearly understand each party’s obligation.

Overview

Deliverables

Audit Trail

Definitions

Approval Process

Organizational

Structure

Relationships

Responsibilities

CHAPTER 1: PROJECT SUMMARY

CHAPTER 2: PROJECT ORGANIZATION
Chapter 16: Prepare an Implementation Plan 209

Include the objectives from the Project Plan.

Include those listed in the Project Plan and supplement the list with any

implementation-specific issues (e.g., elected officials impose a new time

restriction on the project, change orders up to $5,000 can be approved

without Steering Committee approval, etc.).

The original Risk Management Plan from the Project Plan should be valid and

recent, so cut-and-paste it into this document.

Describe the numbers and types of personnel needed to conduct the project.

Describe the required skill levels, start times, duration on the project, method

of obtaining the personnel, training required and phasing out of project

personnel.

Take the following sections from the Agreement and insert them into the plan

(remember, not everyone has access to the agreement, so this information is

helpful to the wider Project Team audience):

• Project Costs

• Payment Schedule

• Initial Project Schedule

Project Objectives

Assumptions/

Constraints

Risk Management

Plan

Staffing Plan

CHAPTER 3: MANAGEMENT PROCESS

CHAPTER 4: WORK, SCHEDULE AND BUDGET TOOLS

Select Contract

Exhibits

Yet Another Plan to Maintain

Once the Implementation Team has drafted the Implementation Plan, it goes to the

Steering Committee for review and approval, with the Executive Sponsor having final

approval/authority.

Similar to the Project Plan, the Implementation Plan will require updates at least once

per month (although in the early stages of the project, weekly updates are more appropriate). Generally the Project Manager is assigned to update the Plan and identify any

changes to the Steering Committee during regularly scheduled meetings.

Some agencies post the Implementation Plan to an agency Intranet site for widespread

communication of the project’s status and detail. We encourage agencies that have such

resources to take advantage of them (the more eyes the better!).
CHAPTER 17

DEVELOP AND USE QUALITY ASSURANCE

TESTS
Chapter 17:

Develop and Use

Quality Assurance Tests

What

Why

Who

When

Quality assurances are actually tests that ensure the vendor’s hardware and software

perform according to specification.

Failing to conduct any type of quality assurance testing could allow defective hardware

or software to be installed at your agency with little or no recourse.

Depending on the type of test, users, technical support staff, the Project Manager and

vendor staff may be involved. The Steering Committee and Executive Sponsor are

involved in evaluating vendor/product performance.

The type of test dictates when it is to be performed.

This chapter addresses the key elements associated with identifying and executing

the three most common benchmarks used for evaluating the quality of a public

safety vendor’s products (hardware and software), including: Functionality,

Reliability and Performance. Additionally, we have included sample text for use in

planning for any of the three testing scenarios. Whenever possible, the content of

these tests should be agreed upon by the agency and the vendor during contract

negotiations (see Chapter 15).

Quality Assurances and Testing

As the name implies, quality assurances (QA) are measurements by which agencies can

determine whether or not a vendor’s offering meets or exceeds minimum quality

standards. In the vast majority of cases, QA is measured by the success or failure of a

product as measured against various forms of acceptance testing.

Acceptance testing is the process that an agency uses to verify that the delivered and

installed product meets requirements specified in the procurement documents and

contract, and is ready for use. From the agency’s point of view, this usually means that

every user-oriented function should be thoroughly exercised and that any purchased

hardware should be free from defect.
214 Part V: Implement the Technology

Note:

Agencies should

attempt to include all

forms of acceptance

testing as elements of

the vendor contract.

A typical test is organized as a multi-layer script that guides the tester through a series of

data entry/retrieval actions:

• The first layer would seek to verify that the major functions are properly operating

in their most common mode.

• The next layer would seek to test specific modules.

• Lastly, the script may call for the tester to do something very specific, hoping to

examine functional specifications.

In the public safety software arena, agencies should employ the following types of

acceptance testing:

■ Functionality: This testing is designed to ensure that the vendor’s software is Functionality

functioning as described in product literature and, possibly, in their response to

the agency’s RFP. Functionality testing usually starts after users have been trained

and the software is in a “live environment.” The duration of the test can range from

no less than 30 days on up to 90 days, depending on the vendor’s willingness to

agree to the agency’s terms during contract negotiations.

■ Reliability: This testing is designed to determine the “uptime” of a vendor’s Reliability

solution. Typically, this testing involves the use of special software (e.g.,

WinRunner, LoadRunner) that simulates the volume of transactions that the

vendor claims to be acceptable. Reliability tests can be performed at any time or

place, although usually it is best to perform the test on-site after any software

customizations have been made to ensure that the “as-built” software conforms

with the vendor’s assertions regarding reliability. Reliability testing is often run

over a period of 5 to 7 days, with results being extrapolated to simulate a period of

1 year.

■ Performance: This testing is designed to determine the speed of the combined Performance

hardware and software package during various transactions. This involves using

scripts that instruct a user to enter various commands, input data, conduct search

routines, generate reports and perform other functions while the time it takes to

execute the command, task or search is recorded (either by a human with a

stopwatch or with approved software). Performance testing is usually conducted

late in the project, well after customization and interfaces have been built.

REPORT CARD DAY

Generally, there are three scores a tester can assign: Pass, Fail or Reservation.

A “Reservation” score indicates that the system passed the majority of tests within the

script, but failed to accomplish 100% of the tested features.

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○
Chapter 17: Develop and Use Quality Assurances 215

How to Prepare a Test

Aside from outsourcing the preparation of testing materials to a consultant, many

agencies start the process by relying upon vendor-supplied test plans. Generally, vendors

will provide a “sample test plan” to agencies as a courtesy during the RFP response

period, or upon request. This is usually a good starting point, although agencies often

have to tighten the pass/fail parameters because the tests are naturally biased in favor of

the vendor.

Other options include (a) using the test plans of other agencies that have recently

installed and tested the products, or (b) creating your own test plan based on the

vendor’s response to the RFP and the vendor’s product documentation. While the latter

suggestion is possible, it is both labor- and time-intensive and not recommended for

most agencies.

Sample Test Language

Each test plan is unique and can include virtually thousands of testing requirements,

making the provision of multiple samples impractical. However, on the next four pages

we have included sample testing procedure language for each of the three tests described

above. In an actual contract, the text would be followed by actual functional specification

tests and scripts, which would naturally be specific to the vendor’s product.
216 Part V: Implement the Technology

FUNCTIONAL SYSTEMS TEST — SAMPLE LANGUAGE

At least sixty (60) days prior to commencement of the functional systems testing, the vendor shall submit

for approval a detailed functional systems test plan based on the general procedures described herein

and that shall certify that the desired functionality has been delivered and meets all performance and load

benchmarks.

The test plan shall document how each functional specification is to be tested, the method of testing and

the anticipated results. This documentation shall describe each scenario to be used for each functional

specification. The functional systems test shall be conducted jointly by the agency’s Project Manager and

designees and the vendor. The functional systems test will:

• Demonstrate every functional attribute of the software, including system software, operating

system, utilities, interfaces, system administration procedures, all ancillary application program

modules and all management information requirements.

• Verify that all transactions with external systems are performing as specified.

• Test and verify that real-time recovery and switching to the backup system(s) operates as specified

by the vendor.

• Conduct full-scale load benchmarks based on scenarios jointly developed with the vendor and

approved by agency staff.

The test results shall be included in the test report and the agency’s Project Manager or designee shall

have the option of conducting an independent test of all or any of the functional requirements, as

specified in the Response Document.

Within fourteen (14) days after completion of functional systems testing, the vendor shall provide a

written report to document completion of the test, and to indicate test results, problems, solutions and a

schedule to implement such solutions. When the operating system, software and interfaces have been

delivered, installed and fully tested, including the functional systems test, and the system is ready for

reliability testing, the vendor shall provide written certification to the agency’s Project Manager that the

installation phase of the contract has been fully completed and all requirements have been met.
Chapter 17: Develop and Use Quality Assurances 217

The reliability test shall run for a period of thirty (30) consecutive days, twenty-four (24) hours a day for a

total of seven hundred twenty (720) consecutive hours after the system is implemented in production

mode. This period shall be known as the performance period. During the performance period, the agency

shall have the option to run in parallel mode all subsystems that will be replaced by the system until the

system is fully accepted. The performance period shall begin on the date the vendor notifies the agency

that the system is ready for reliability testing.

If there is a system failure, as defined below, deficits shall be corrected and the reliability test and the

performance period shall start over. The following criteria constitute the standard of performance:

The system shall operate in conformance with the vendor’s technical specifications and functional

descriptions, which shall satisfy the requirements of this proposal at a 100% accuracy level:

• As quoted in the vendor’s proposal

• As amended in the contract negotiations

• As amended throughout the design and development stages

• As formally documented

Operation use time and downtime shall be measured in hours and whole minutes. System failure

downtime is that period of time during which the scheduled productive workload, or simulated workload,

being used for reliability testing cannot be continued on the system due to failure of a software system

component. If simulated workload is being used for reliability testing, it shall be consistent with the data

processing requirements set forth elsewhere in this contract. Operational use time for performance testing

for a system is the accumulated time during which the system is in actual operation and can be used by

the agency.

Downtime for each incident shall start from the time the agency contacts the vendor’s designated

representative at the prearranged contact point until the system(s) is back in proper operating condition.

The vendor shall provide continuous telephone coverage to permit the agency to make such contact. Any

single failure or any series of failures of the system software that results in any of the following conditions shall be considered a system failure:

• Complete shutdown of the system. This includes failures that cause human intervention to

maintain critical operations or to restart the operating system or server applications software to

restore the system function.

• If three (3) seconds is the specified response time, then an increase to nine (9) seconds or longer

in five (5) transactions is a system failure.

• An increase in any single transaction response time of four (4) times the response time proposed

in the RFP, or longer. For example, if three (3) seconds is the specified response time, then an

increase to twelve (12) seconds in one (1) transaction is a system failure.

RELIABILITY TEST — SAMPLE LANGUAGE
218 Part V: Implement the Technology

• Loss of any of the basic system functions, such as the inability to transfer event messages between

workstations, loss of the use of all communication functions, or the inability of the system to

maintain folder status or event status on a current basis.

• Loss of all or a major part of the mobile functions; loss of the ability to communicate with most or

all of the mobile devices.

• Repeated failures of the same function or equipment component is unacceptable even if it does not

cause the conditions listed above for a system failure.

• More than two incidents of downtime per week for the same problem.

• Any critical entry or information control capability is not available at all active workstation

positions.

• The loss of the ability of the system to communicate (in either direction) with agency systems,

interfaces, data sources.

During the reliability test period the system shall be fully available, in excess of seven hundred sixteen

(716) hours, i.e., a total of four (4) hours or more of downtime (unavailable time) shall be considered

system failure.

The agency shall maintain appropriate daily records to satisfy the above requirements and shall notify the

vendor in writing of the date of the first day after the successful performance period. The date of

acceptance shall be the first day after the successful performance period. If the system fails to meet the

standard of performance after ninety (90) calendar days from the installation date or start of the performance period, whichever is later, the agency may at its option request a rescission of the contract and

request the immediate removal of the system. The impact on prior payments of such a rescission shall be

determined in contract negotiations.

RELIABILITY TEST — SAMPLE LANGUAGE (CONTINUED)
Chapter 17: Develop and Use Quality Assurances 219

All files and tables shall be capable of being updated online without adversely affecting performance or

degrading response time, as described below. The system shall provide the option of batch updates for

all files and tables in addition to the online updates described above. All necessary backups shall be able

to be done online without adversely affecting system operations, and without lockouts for updates. The

system shall provide the option of cold backups in addition to the online backups described above.

Appropriately formulated queries to interfaced databases shall be made without adversely affecting

system performance, i.e., asynchronous messaging capabilities. Such inquiries shall not tie up or lock up

the workstation.

The vendor shall provide the exact transaction response times for the proposed system, based on the

network and hardware requirements proposed in the RFP. These shall be used as the basis for the

response time testing and acceptance. Response time for data retrieval shall be measured from the point

of issuing the request (pressing the enter key) to displaying the record to the client.

The following method shall be used to measure response time: A representative mix of system

transactions based upon the peak daily loading from field operations, normal processing, records

operations and mobile computing activities shall be entered into the system for a period of twenty (20)

minutes via an automated product such as Mercury Interactive Corporation’s product “Load Runner” or its

equivalent. The vendor shall provide software to measure and print out transaction response times. The

response time shall be measured under peak workloads and meet or exceed the following:

TRANSACTION CRITERIA

Mean response time 7 seconds

Simple queries 3 seconds

Complex queries 10 seconds

Document retrieval request 7 seconds

Concurrent transactions per second 50

Transactions per minute 3,000

Capacity and Growth: The initial system software configuration shall be expandable to handle an

anticipated increase of workload comparable to the expected growth rate for the agency of 10% for each

of the five (5) years following implementation. This expansion shall allow the system to maintain the

specified system performance requirements, including response time.

System Availability: The system shall provide overall system availability (uptime) of 99.5%, excluding

planned downtime.

PERFORMANCE TEST — SAMPLE LANGUAGE
220 Part V: Implement the Technology

Use Test Results to Evaluate Vendor and

Product Performance

Following the actual testing process, agencies must evaluate the performance of the

vendor and its product(s), seeking to determine whether or not the vendor successfully

passed the various tests. Usually, agencies withhold acceptance of the technology until

after the vendor’s products have passed the testing phase (remember, acceptance is

linked to payment; thus, vendors have a shared interest with the agency in successfully

executing the testing process).

The Project Manager should work with the Steering Committee to interpret QA test

results. The Steering Committee is responsible for reaching a formal evaluation decision

regarding the vendor/product performance and making recommendations to the

Executive Sponsor regarding system acceptance/nonacceptance. Final acceptance

authority rests with the Executive Sponsor.

What’s Next?

Undertake Project Closeout and Recurring Tasks ............................. Chapter 18

Manage, and Comply With, Your Grant Award ............................... Chapter 19

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○
Part V Assignments 221

EXECUTIVE SPONSOR

Role 1. Ultimate decisionmaker

2. Provide oversight and guidance

Implement the 1. Approve Implementation Plan (Chapter 16, page 209)

Technology Tasks 2. Based on outcomes of Quality Assurance (QA) testing

and Steering Committee’s recommendation,

determine whether to accept/withhold acceptance

of technology (Chapter 17, page 220)

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

PART V ASSIGNMENTS

STEERING COMMITTEE

Role 1. Evaluate post-implementation vendor and product

performance

2. Provide knowledge and recommendations

Implement the 1. Review and approve Implementation Plan and continual

Technology Tasks updates (Chapter 16, page 207)

2. Using QA test results and staff input, formally evaluate the

performance of the vendor and its products

(Chapter 17, page 220)

3. Report acceptance/nonacceptance recommendation to

Executive Sponsor (Chapter 17, page 220)
222 Part V: Implement the Technology

PROJECT MANAGER

Role 1. Coordinate and oversee all tasks and activities

2. Work closely with vendor

3. Seek input of City/County attorney and project

consultant (if any) as needed

4. Advise Executive Sponsor, Steering Committee and

other players on implementation issues

Implement the 1. Organize an Implementation Team, comprised of staff

Technology Tasks from the vendor and agency Project Teams; start

implementation planning (Chapter 16, page 207)

2. Gather documents needed to prepare the Implementation

Plan (Chapter 16, page 207)

3. Organize and oversee regular meetings of the

Implementation Team as it drafts and updates the

Implementation Plan (Chapter 16, page 209)

4. Oversee Implementation Plan approval by decisionmakers

(Chapter 16, page 209)

5. Post the Implementation Plan to your agency Intranet

(Chapter 16, page 209)

6. Determine appropriate QA testing procedures, oversee

testing, help interpret QA testing outcomes and report to

decisionmakers (Chapter 17)

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

PART V ASSIGNMENTS, CONTINUED
Part V Assignments 223

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

PART V ASSIGNMENTS, CONTINUED

IMPLEMENTATION TEAM (A SUBSET OF THE PROJECT TEAM)

Role 1. Create the Implementation Plan

Implement the 1. Create the Implementation Plan document, modifying the

Technology Tasks Project Plan to accommodate the vendor’s role

(Chapter 16, page 208)

2. Participate in regular meetings to draft and continually

revise the document (Chapter 16, page 209)

TECHNICAL STAFF

Role 1. Participate in QA testing

Implement the 1. Assist with QA functionality, reliability and performance

Technology Tasks testing, focusing particularly on the performance of

hardware and software (Chapter 17)

2. Provide advice and expertise to staff and decisionmakers

(Chapter 17)

OPERATIONAL EXPERTS (USERS)

Role 1. Participate in QA testing

Implement the 1. Assist with QA functionality and performance testing,

Technology Tasks focusing particularly on exercising user-oriented functions

(Chapter 17)

2. Provide advice and expertise to staff and decisionmakers

(Chapter 17)
“Technology makes it possible for people to

gain control over everything, except over

technology.”

— John Tudor

Part VI:

Maintain the

Technology
CHAPTER 18

ENSURE THE SUCCESS OF YOUR

TECHNOLOGY INITIATIVE: ONGOING TASKS
Chapter 18:

Ensure the Success of Your

Technology Initiative:

Ongoing Tasks

What

Why

Who

When

A process to ensure that your agency’s new technology is maintained, its upgrades and

enhancements are planned, and that your staff continues to get the most out of the

new system.

Technology projects fail when a system is implemented, then neglected.

The Project Manager is responsible for keeping the technology initiative and related

issues in front of the decisionmaking structure.

At the conclusion of the project’s implementation phase (shortly after Project

Closeout).

Remember in “Seven Facts You Should Know,” (Fact #3, page 13 to be exact) we

told you that IT planning was a cyclical process. We said, “The successful implementation of a system does not signal the end of the planning process. Systems

implementation really signals the beginning of a new phase of evaluating the

recently adopted system and planning for systems maintenance, upgrade,

enhancement and replacement.” To maintain this process, follow the retrospective

and recurring tasks presented in this chapter to ensure the post-implementation

success of your technology initiative.

The roles of project participants do not evaporate once the technology “goes live.” The

Project Team must continue to meet on a regular basis (albeit far less frequently), to

conduct retrospective project reviews, prepare for technology enhancements and manage

support/warranty issues. In terms of frequency, most project management committees

continue to meet on a quarterly basis during the first year following the system’s “live

date,” and semiannually in the years that follow.
230 Part VI: Maintain the Technology

Project Closeout Tasks

Marking the conclusion of your technology project’s implementation phase is a task

called Project Closeout, which is the appropriate time to undertake the following

“retrospective tasks”:

■ Reassignment Reassignment: Reassign or release Project Team members to other projects (or Reassignment

previous assignments) as their full-time tasks are completed.

■ Project Post-evaluation: A thorough review, spearheaded by the Project Manager, Project Post-evaluation

which seeks to confirm that all project tasks have been accomplished. This task

requires an examination of the Project Plan and its details, including time, costs

and vendor deliverables.

■ Vendor Transition Meeting: A meeting between your agency’s Project Team and Vendor Transition Meeting

the vendor representatives to review any issues that may arise from the project

post-evaluation review and also to discuss warranty/maintenance responsibilities.

■ Post-project Meeting: Like the Kick-off Meeting, this gathering invites all project Post-project Meeting

participants to a large-scale discussion that focuses on project review, accomplishments, challenges and next steps. Usually, the Executive Sponsor recognizes and

rewards team members for their achievements.

■ Final Report Preparation: Prepare a final report that includes the project’s final Final Report Preparation

schedule, costs and quality results, as well as comparisons to the baseline, explanations and implications for the future. The report should include:

• A comparison of actual costs to projected costs.

• A summary of “lessons learned” for future technology projects.

• The signatures of Project Team members, which indicate internal acceptance

of the technology.

Although Project Closeout signals the end of the implementation, the project doesn’t

stop there!

The 70/30 Rule

“One should consider

the Total Cost of

Ownership (TCO)

when purchasing

computer systems.

Only 30 percent of the

total cost of owning a

computer system is

the initial purchase of

the hardware, software

and peripherals.

Seventy percent of the

ownership cost goes

to technical support,

repairs, training and

upgrades.”

— From “Technology

Budgeting Basics,”

by John Kenyon

(www.techsoup.org)
Chapter 18: Ongoing Tasks 231

Checklist of Recurring Tasks

Given the broad range of issues that need to be addressed following Project Closeout, we

offer this checklist of recurring tasks related to your project:

Keep the decisionmaking structure and committees intact Keep the decisionmaking structure and committees intact. The main commit- Keep the decisionmaking structure and committees intact

tees formed in the decisionmaking structure should continue to meet on a

regular basis to discuss the project. These committees may be dynamic, with

representatives changing over time based on responsibilities or changes in personnel, but

they nevertheless must continue to actively monitor the technology initiative. The

important recommendation here is that representatives from the executive, operational

and technical levels continue to play a role in the governance of the initiative.

Actively use the communications plan. Keep open lines of communication with Actively use the communications plan

all users and stakeholders about the technology initiative. This will keep the

interest alive in the technology and signal to users that the agency is interested

in (and committed to) making sure the technology is used properly and meets user needs.

Continuously monitor and document project activities, issues and user Continuously monitor and document project activities, issues and user

satisfaction. Continue to journal all project activities and issues (successes as satisfaction

well as problems) and give users an opportunity to express their feelings about

the technology and suggest enhancements or changes. User feedback can be obtained by

inviting user groups to speak at project meetings or via suggestion boxes (electronic or

otherwise).

Do not “shelve” the Project Plan. Too often Project Plans get relegated to the Do not “shelve” the Project Plan

library where they merely gather dust. The Project Plan really is a living

document and should be treated as such. We’ve yet to see a project that

accomplishes every single feature or function originally envisioned in the initial project

plan. It is common that some features, goals or objectives must be sacrificed due to

budget, policy reasons or some other factor. But these are important considerations for

enhancements or next phases of the project. The plan is also an important mechanism

for benchmarking performance to make sure the system is meeting anticipated goals and

objectives. Review it now and again for a refresher.

Review your contract Review your contract. Review your contract Again! Why should you continue to read contract

legalese (other than for its stimulating nature)? Because failure to review the

contract may mean that important and required tasks don’t get done! There

have been too many instances where agencies have put away the contract and failed to

realize that important conditions have not yet been met. Some agencies have even gone

to the extent of preparing a new fiscal year budget for “enhancements” that were really
232 Part VI: Maintain the Technology

part of the original contract! Take it out every now and then, brush off the dust, and give

it a good read. You may be surprised at what you find!

Revise your recurring costs budget and prepare for technology upgrade, Revise your recurring costs budget and prepare for technology upgrade,

replacements and enhancements replacements and enhancements. We talked about lifecycle planning through- replacements and enhancements

out the Tech Guide. The “lifecycle” also applies to budgeting. Now that the

technology is operating in a live environment, you may have even more concrete ideas

about the type of recurring costs you will have. Review the budget you created in Chapter

11 and update the recurring costs based on the existing contract.

Assess how your IT staff is handling support of the new system. Spend a good Assess how your IT staff is handling support of the new system

deal of time with your agency and your parent organization’s IT support staff to

determine if the staffing levels and staff expertise are adequate for system

support. You may find that you need new skill sets or additional support staff. Also, take

into consideration the project’s next phases and whether you will be increasing equipment roll out (e.g., purchasing more mobile computers to deploy in the field may mean

that more support staff will be required).

Remember that training should not be a one-time activity! Plan and budget for Remember that training should not be a one-time activity

continued training for users. Solicit feedback from users at all levels about what

types of additional or refresher training they need. This should be a budget

item each year.

Complete the “lessons learned” document Complete the “lessons learned” document. You’ll want to make sure that you Complete the “lessons learned” document

finalize the lessons learned document we discussed in Chapter 13, page 162.

This will be an important learning tool for future technology initiatives about

what worked and what didn’t.

In summary:

Don’t forget the

system lifecycle!
CHAPTER 19

GRANT MANAGEMENT AND COMPLIANCE
Chapter 19:

Grant Management and

Compliance

What

Why

Who

When

Undertaking the proper steps to ensure that your agency is complying with the

conditions of a grant.

Because the granting agency requires compliance and failing to do so may result in the

withdrawal of grant funds.

Agency grant managers, finance employees and others, depending on the type of

grant received.

As soon as a grant award is received.

Many police agencies fund their technology initiatives, in whole or in part, with

local, State or Federal grants. By accepting the grant, agencies are expected to

comply with various conditions, including grant compliance, monitoring and

proper financial accounting. This chapter will address the planning steps necessary

to prepare an agency for the complexity of achieving grant compliance in a

technology initiative.

Recognizing that there are dozens of grant programs available to law enforcement

agencies, this chapter does not attempt to guide agencies through the complexity

of any individual grant program. Rather, it attempts to identify some common

threads of grant management.

Congratulations Congratulations! The majority of police agencies are thrilled upon notification that they Congratulations

have received a grant award. The supplemental funds offered to police agencies by local,

State and Federal granting agencies can be the “make it or break it” factor in many

technology initiatives.

Now, manage it Now, manage it! Accepting a grant award is rarely condition-free. Most grants are Now, manage it

directly linked to objectives, such as addressing a particular social issue or redeploying

officers from reporting activities to street patrol or other community-oriented policing

activities, as directed by the granting agency. Consequently, there are usually conditions

that must be met as a term of using the funds, often referred to as program-related

requirements.
236 Part VI: Maintain the Technology

In addition to program compliance, there are also financial and reporting compliance

issues that your agency must address. By accepting a grant, your agency must agree to the

requirements that are identified in the grant award package. Usually, these conditions are

based on grant compliance mandates set forth by the U.S. Office of Management and

Budget (OMB). Because the Federal government distributes more grants than any other

entity, many State and local agencies defer to the OMB guidelines as a de facto standard.

In addition to the OMB guidelines, there are often additional program-specific conditions that must be upheld. For example, MORE technology grantees also must subscribe

to these Federal regulations regarding the implementation of grant-funded technology/

equipment:

• 28 CFR 23, Criminal Intelligence Systems Operating Policies

and these sections of Part 66, the Uniform Administrative Requirements for

Grants and Cooperative Agreements to State and Local Governments:

• 28 CFR 66.36, Procurement

• 28 CFR 66.32, Equipment

Manage Your Grant

While managing grant requirements is not difficult, it does represent a new set of

responsibilities that may be foreign to many law enforcement personnel. Like most topics

covered in this Guide, pre-planning will go a long way toward better grant management.

Start planning early in the process. Shortly after submitting a grant application, the

agency should determine who will be responsible for managing the various elements of

the grant, should it be awarded.

We suggest that your agency assign two people to manage the two areas of a grant: one to

manage and be accountable for the program requirements, and a second for the fiscal/

reporting requirements. Based on our experience, successful grant management is most

often achieved when the law enforcement agency and the parent organization’s finance

division work in concert on managing the grant. For example, the agency focuses on the

program requirements, while the City/County finance representative assumes responsibility for the fiscal/reporting requirements.

Should the grant be awarded, a grantee award package will likely be included, which will

illustrate all of the grant’s program, financial and reporting requirements. Both representatives should carefully review the requirements and determine who is responsible for

overseeing the various aspects of the grant.

The grant conditions should be provided to the Steering Committee to ensure that

program requirements become project objectives. Additionally, Steering Committee

The OMB provides

published standards

that dictate how

Federal grants are to

be managed. See

http://

www.whitehouse.gov/

omb/grants/

Access Federal

regulations online at

http://

www.access.gpo.gov/

nara/cfr/cfrretrieve.html#page1

Also, refer to the

“Grantee Toolbox”

section of the COPS

Office Website for

grant compliance

information: http://

www.usdoj.gov/

cops/toolbox/

grant_programs/

more/default.htm
Chapter 19: Grant Management and Compliance 237

oversight in grant-funded technology initiatives adds an additional layer of responsibility,

which can help to ensure that the project ultimately fulfills the grant requirements.

From that point on, the respective parties simply execute their responsibilities to the

grant. Typically, managing the grant includes the following activities:

• Preparing quarterly or semiannual financial status reports.

• Preparing annual program status reports.

• Occasional visits from the granting agency.

• Financial audits (depending on grant amount).

• General project oversight to ensure grant compliance.

• Organizing all grant-related documents.

To ensure proper organization and maintenance, we suggest that agencies create and

maintain a grant filing cabinet that contains the following folders:

File 1: File 1

Application and

“pre-award” data

File 3: File 3

Official award

documents from

the granting agency

File 4: File 4

All grant application

corrections and adjustments

File 5: File 5

A log of all financial status

reports (mandatory quarterly

or semiannual reports submitted to the granting agency that

identify how the grant money

was utilized, when it was drawn

down and other financial data)

File 6: File 6

All supporting data related

to the grant

File 2: File 2

A journal of all

correspondence

(internal and external)

related to the grant
238 Part VI: Maintain the Technology

Top 5 Grant-related Blunders

During our research for the Guide, we encountered MANY grant-related mistakes, but

the following warrant mention as the Top 5 Grant-related Blunders:

“We found out that we had a grant a month before it was set to expire, so we paid our

vendor the entire grant amount up front.”

Readers may be surprised by how many times this has occurred. If you need more time to

expend the grant funds, call your Grant Program Specialist and ask for an extension!

“After we accepted our grant, we drew down the whole amount at once so we could

collect interest on it.”

Oops! Granting agencies generally do not allow agencies to collect interest on the grant

funds they receive. In this case, the agency was forced to pay back the earned interest.

“After we got the grant, the City was able to take back the money budgeted for the new

CAD and use it for overtime shortfalls.”

The idea of replacing budgeted money with newfound grant money is known as “supplanting” and it is forbidden by virtually all grant programs forbidden by virtually all grant programs. See Chapter 11, page 145. forbidden by virtually all grant programs

 “When we found out our Grant Program Specialist was conducting a site visit, we called

our City Attorney and asked him to represent us.”

The Grant Program Specialist is your friend, not an enemy to be shielded against. Grant

Program Specialists are knowledgeable allies whose mission is to ensure your success, so

welcome their arrival and ask them for help whenever warranted!

1.

2.

3.

4.

Grant management underscores the importance of setting realistic objectives and building

in useful measurement procedures to demonstrate the impact and effectiveness of your

project. Be sure to plan effectively by:

• proposing realistic, measurable and accomplishable objectives (which are written

into your grant application), and

• developing adequate procedures for constantly measuring and reporting on these

objectives.
Chapter 19: Grant Management and Compliance 239

5. “After getting the grant and beginning implementation, we changed our objectives,

altered our Project Plan and didn’t buy the technology originally planned.”

A definite issue here! Remember, if you make changes to your grant application, they

have to be approved in writing by the granting agency before you implement the change. before

In some cases, using grant funds for purposes other than those approved by the granting

agency can result in civil and criminal prosecution, or at a minimum the return of grant

funds.

Who Can Help?

If you should ever find yourself confronting problems with a grant, remember just one

thing: CALL YOUR GRANT PROGRAM SPECIALIST! During our research, we found

literally dozens of agencies that believed that their Grant Program Specialist was an

auditor who would immediately “turn them in” if they were to place a call asking for help.

Nothing could be further from the truth!

Grant Program Specialists have a shared interest in the successful completion of your

project and can often solve problems directly over the phone. They can also send you

copies of your grant application or other documents you may have misplaced. For more

complex issues, they can work with the agency over time to reach a resolution.

State and Federal grant funding plays a critical role in providing necessary

“seed monies” for many technology issues. Grants are often a one-time

deal, however, so you must identify other State and local funding streams

that will help provide ongoing support, enhancement and upgrade for your

technology initiatives. Your annual budget must contain funding for technology and its

support. Therefore, agency directors, City and County leaders, legislators and other funding

decisionmakers must be educated on the need to fund technology on an ongoing and

continuous basis.
240 Part VI: Maintain the Technology

EXECUTIVE SPONSOR

Role 1. Ultimate decisionmaker

2. Provide oversight and guidance

Maintain the 1. Attend Post-project meeting; recognize/reward team

Technology Tasks members (Chapter 18, page 230)

2. Make decisions regarding maintenance, upgrade and

enhancement of the technology initiative, as well as

replacement issues (Chapter 18, page 231)

3. Sign off on all grants and meet with visitors from

granting agency (Chapter 19)

STEERING COMMITTEE

Role 1. Reallocate resources

2. Provide input, make decisions and present

recommendations to Executive Sponsor

3. Actively monitor the technology initiative

4. Provide oversight of grants

Maintain the 1. Reassign/release Project Team members to other projects

Technology Tasks (Chapter 18, page 230)

2. Attend/participate in project closeout meetings and tasks

(Chapter 18, page 230)

3. Continue to meet regularly to discuss issues and make

recommendations related to technology maintenance,

upgrade, enhancement and replacement

(Chapter 18, page 231)

4. With input of Project Manager and committees, make and

approve changes to Project Plan and other documents

(Chapter 18, page 231)

5. Revise recurring costs budget and plan for the next round

of funding (Chapter 18, page 232)

6. Provide grant oversight: review program requirements in

grants to ensure they become project objectives, and

ensure the technology project fulfills the grant

requirements (Chapter 19, page 236)

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

PART VI ASSIGNMENTS
Part VI Assignments 241

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

PROJECT MANAGER

Role 1. Coordinate and oversee all tasks and activities

2. Report to decisionmakers and liaison with technical and

operational experts

3. Stay involved with grant management and compliance

Maintain the 1. Organize and lead Project Post-evaluation, Vendor

 Technology Tasks Transition Meeting and Post-project Meeting

(Chapter 18, page 230)

2. Prepare project’s Final Report, submit to Project Team

for acceptance/signatures (Chapter 18, page 230)

3. Participate in ongoing committee/project meetings

(Chapter 18, page 231)

4. Report regularly to Steering Committee and Executive

Sponsor regarding system performance, maintenance,

upgrade, enhancement and replacement issues

(Chapter 18, page 231)

5. Continue to report to public regarding status of

technology initiative (Chapter 18, page 231)

6. Work with Technical and Operational Committees to

monitor technology initiative and document project activities

and issues (Chapter 18, page 231)

7. Work with Steering Committee regarding reviews and

updates to the Project Plan and other documents

(Chapter 18, page 231)

8. Monitor vendor agreement periodically to ensure that

important and required tasks are completed

(Chapter 18, page 231)

9. Assess adequacy of staffing levels and determine whether

new skill sets or additional support staff are needed

(Chapter 18, page 232)

10. Oversee provision of continual user training

(Chapter 18, page 232)

11. Prepare and disseminate the “lessons learned” document

(Chapter 18, page 232)

PART VI ASSIGNMENTS, CONTINUED
242 Part VI: Maintain the Technology

PROJECT MANAGER (CONTINUED)

12. For grant management and compliance, assist in

preparation of financial status reports and program status

reports; meet with granting agency staff; and report to

Steering Committee regarding grant compliance issues

(Chapter 19, page 237)

TECHNICAL COMMITTEE

Role 1. Provide input

Maintain the 1. Attend/participate in project closeout meetings and tasks

Technology Tasks (Chapter 18, page 230)

2. Continue to meet regularly to discuss issues related to

technology functionality and performance, maintenance,

upgrade, enhancement and replacement

(Chapter 18, page 231)

3. Document project activities and issues; provide to

Project Manager (Chapter 18, page 231)

4. Advise Project Manager regarding adequacy of staffing

levels and staff expertise (Chapter 18, page 232)

USER COMMITTEE

Role 1. Provide input

Maintain the 1. Attend/participate in project closeout meetings and tasks

Technology Tasks (Chapter 18, page 232)

2. Continue to meet regularly to discuss issues related to

technology functionality and performance, maintenance,

upgrade, enhancement and replacement

(Chapter 18, page 231)

3. Document project activities and issues; provide to

Project Manager (Chapter 18, page 231)

4. Advise Project Manager regarding adequacy of staffing

levels and staff expertise (Chapter 18, page 232)

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○

PART VI ASSIGNMENTS, CONTINUED
Part VI Assignments 243

GRANT MANAGEMENT/COMPLIANCE STAFF

Role 1. Ensure the agency is meeting its local, State or Federal

grant conditions

2. Inform Project Manager and Steering Committee

3. Keep comprehensive/complete documentation related to

grants

Maintain the 1. Follow the steps to assure grants are properly managed

Technology Tasks and the agency is in compliance with program, fiscal and

reporting requirements (Chapter 19, page 236)

2. Regularly inform the Project Manager and Steering

Committee of grant and compliance issues

(Chapter 19, page 236)

3. Prepare financial status reports and program status

reports and oversee financial audits

(Chapter 19, page 237)

4. Organize and maintain all grant-related documents

(Chapter 19, page 237)

5. Identify various funding streams and inform decisionmakers

(Chapter 19, page 239)

PART VI ASSIGNMENTS, CONTINUED

○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○○
Appendix 1:

Information

Technology

Descriptions
Appendix 1:

Information Technology

Descriptions

The following are descriptions of Computer-Aided Dispatch, Mobile Data Computing/

Automated Field Reporting, Records and Jail Management, and Geographic Information

and Computer Mapping Systems. While there are other law enforcement information

technologies, we chose to describe these in detail because they are the primary technologies funded through the COPS Making Officer Redeployment Effective (MORE) Program.

For information on other law enforcement technologies, please visit the SEARCH Web

site at www.search.org.

Each technology described in this section offers core data management capabilities, such as data capture and entry; search, retrieval and display; messaging; and

forming complex linkages between data elements.
248 Appendix 1

Effective handling of an

emergency CFS through a

geo-based CAD:

HOW IT WORKS

• A 911 CFS is received by a calltaker.

• E-911 ANI/ALI information

automatically populates the CAD

screen and the dispatcher adds call

details to CAD.

• The computer assigns a priority

rating to the call based on the

information entered; checks the

validity of the address using the

geofile; searches for historical

location information (previous

calls for service, hazardous

conditions, weapons, warrants,

etc.); then makes recommendations about dispatching available

officers and units (car, wagon,

foot/bike beats, etc.) to handle the

assignment based on unit

proximity, availability, etc. The

dispatcher can use a radio for

voice dispatch and/or “silent

dispatch” the call to officers with

mobile computers in their patrol

cars (silent dispatch involves

sending dispatch information to a

laptop in the field).

• The system constantly updates unit

and call status for the dispatcher

and officers to view.

• When officers have been

dispatched, they may use CAD to

query various systems, such as

State and Federal crime

information centers, NLETS, motor

vehicles, local records systems,

etc.

• The computer automatically

maintains status information,

listing all vehicles working on a

specific tour, their status and

current assignment. Response

times are documented and reports

are captured.

Computer-Aided Dispatch

The computer-aided dispatch (CAD) system has become an

indispensable technology tool in policing and public safety,

designed to handle all information related to receiving and

dispatching emergency calls for

service. For law enforcement,

the system is often the first

point of data entry, whether

processing an emergency 911

telephone call for service (CFS)

or managing an officer-initiated

car stop.

CAD fully automates the calltaking and dispatching

functions of a law enforcement agency and initiates and manages

dispatch and incidents. Used with automated vehicle location

(AVL) systems that track vehicle status information (see page

257), CAD systems can help prioritize calls for service and make

recommendations for unit and resource dispatching based on

beats, zones, closest resources and/or current unit activities.

Some CAD systems can also provide immediate access to

incident location history and information, such as number and

type of prior calls to the location, whether there are existing

warrants for residents, or if there are specific hazards related to

the location.

Based on a “geofile” or geographic database using map-based x

and y coordinates, CAD pinpoints and verifies the location of a

caller and incident regardless of whether it is an address,

intersection, common place, business, etc. The geobase is a

critical component of a CAD system, as it can link and identify

locations via the x/y coordinate, regardless of how a user enters

an address or location — this is important not only for accurately verifying a location, but also for statistical analysis of

incidents and CFS.

The latitude and longitude of a cellular caller, when available, can

also be used directly as a valid incident location.

An E911 interface maximizes the dispatch process by importing

the automatic name index (ANI) and automatic location

information (ALI) directly into the CAD.
Information Technology Descriptions 249

Typical CAD Features*

Technology Components Technology Components

— Dual displays (with computer mapping)

— Enhanced 911 (E911)/telephony

— Integrated radio

Primary Modules Primary Modules

— Incident entry (call-takers)

— Dispatching

— Status monitoring

— Administrative

— Training

— Statistics

— Alarm billing

— Permits

— Mapping

Inputs

— E911 ANI/ALI

— Radio data acknowledgments

(ACKs/NACKs)

— Event data

— National Crime Information Center

(NCIC)

— Geographic information systems (GIS)

— Automated vehicle location (AVL)

— Records management system (RMS)

information

— Parent organization data

— Mobile updates from field officers

Outputs Outputs

— RMS

— Incident dispatch to mobile devices

— Messages

Human Interface

— Who uses it?

• Call-takers

• Dispatchers

• Supervisors

• Patrol (via mobile data computers)

— Who supports it?

• Small-medium agency: at least !/TM FTE

• Large agency: 1 or more FTEs

• Vendor

— How long should it take to learn?

• Application: 40-60 hours

• Administrative support: 60-80 hours

• Depending on skill set

*This is not intended to be a comprehensive list of CAD features.
250 Appendix 1

Mobile Data Computing and

Automated Field Reporting

Mobile computing has become the catchall phrase for outfitting

an officer’s vehicle or person with the technology that, in effect,

allows him or her to be a

“mobile office.” Mobile

computing is actually comprised of several law enforcement hardware and software

technologies working together

to allow officers to access,

receive, create and exchange

information wirelessly in the

field.

Outfitted with wireless

communication technologies, officers can proactively query

local, State and national databases; receive and initiate CAD

events; view unit status; send e-mail; prepare and file incident

reports; issue citations; capture field interview information;

access department policies and procedures; research penal

codes; and perform many other activities, all via laptops or

hand-held units. The goal, of course, is to allow officers to do

anything in the field that they can do in-station — including

accessing electronic photos.

Some of the real benefits of mobile computing come through the

use of automated field reporting (AFR) software. AFR automates

the incident and other reporting processes from the patrol car.

Optimally, AFR allows the capture of incident and

report information and then electronically sends

the report to a supervisor for approval and

submission to the records management system

(RMS). Modern AFR software can increase officer

productively and streamline the reporting process

by allowing the officer to capture critical information in the field at the time of an incident. AFR

packages offer a variety of features to ensure data

integrity, such as drop-down menus, spellchecking, prefilled fields, pre-population of

multiple forms, error correction and more.

Increasing the effectiveness of

law enforcement personnel in the field

with mobile devices:

HOW IT WORKS

• After receiving dispatch

information via the mobile laptop

computer, the officer responds to

the incident, running queries and

other inquiries against databases

remotely.

• When the incident is closed, the

officer completes a required report

(incident, citation, accident, other)

via laptop or hand-held unit.

• Information is electronically

forwarded to a supervisor for

approval via wireless communications network.

• The supervisor makes a decision

whether to approve the report. If

approved, the report is electronically submitted to the records unit.

If it is not approved, the supervisor

can send the report back to the

officer for corrections.

• Once received by the records unit,

records staff performs quality

assurance on the report prior to

formally submitting it to the RMS,

but this entire process is done

electronically.
Information Technology Descriptions 251

The benefits of mobile computing are clear:

Officers who can receive dispatch information

and conduct their own instant queries from the

laptop have more immediate access to information that assists them in on-the-spot

decisionmaking. Preparing reports in the field

allows for more accurate and timely data due to

its capture in the field at the time of the event.

Additionally, the ability to transmit reports to

supervisors and headquarters means officers do

not waste valuable time returning to the precinct

or station to complete paperwork. Finally, the

instant access to (and exchange of ) information

can make officers more effective in community

policing strategies and interacting with citizens.

Typical Mobile Data Computing

Features*

Technology Components Technology Components

— Laptop computers

— Hand-held personal digital assistants

— Public or private radio systems

Primary Modules Primary Modules

— AFR

• CAD data capture

• Error correction

• Report writing

• Case management

— Incident retrieval and display

— Forms

— Call receipt

— Administrative

Inputs

— CAD incident data

— RMS data

— NCIC

— Other Federal, State and local databases

Outputs Outputs

— Incident reports

— NCIC uploads

• Stolen vehicles

• Warrants

— CAD scheduling data

— Data for integrated justice

— Variable exports

• Jail management system

• Ticket processing

• Parent organization applications

Human Interface

— Who uses it?

• Sworn personnel

• Command staff

• Supervisors

• Detectives

— Who supports it?

• Small-medium agency: at least !/TM FTE

• Large agency: 1 or more FTEs

• Vendor

— How long should it take to learn?

• Application: 20-30 hours

• Administrative support: 80-100 hours

• Depending on skill set and database

design

*This is not intended to be a comprehensive list of mobile computing features.
252 Appendix 1

Records Management System

A law enforcement records management system (RMS) is not

just a means to electronically collect and store reports and

information. Indeed, records

management systems of the

21st century have become a

key asset to effective policing,

offering robust analytical tools,

the ability to seamlessly share

information, develop complex

linkages between myriad data

and information, and assist in

effective management

strategies. The police RMS is a

key component to informed

and intelligent decisionmaking

and the basis for sound integrated justice information systems.

In its simplest form, an RMS captures, maintains and analyzes

all police agency and incident-related event information and is

vital to the day-to-day operations of tracking and managing

criminal and noncriminal events, investigations and personnel

information. An RMS automates the daily business practices of

entering, storing, retrieving, retaining, archiving, viewing and

exchanging records, documents, data, information or files

related to persons, vehicles, incidents, arrests, warrants, traffic

accidents, citations, pawn tickets, civil process paper service,

gun registration investigations, and property and evidence.

Information can also be captured in a variety of forms, including

digital photos (crime scenes, mugshots, evidence, etc.), audio

and video.

Standard RMS components include integrated information

tracking and management systems for each of these entities.

Modern RMS applications can form complex linkages between

each of these components, offering enhanced analysis and

multifaceted use of the data, including decisionmaking along the

following lines:

Information stored, linked, accessed

and analyzed via a robust RMS:

HOW IT WORKS

• Officers prepare reports via desktop

computer or mobile unit in the

patrol car and submit them

electronically to a supervisor, who

reviews them.

• Once the supervisor’s approval is

given, the report is automatically

added to the RMS.

• If property or evidence has been

received, it can be bar coded and

linked directly to the record in the

RMS.

• Information stored in the RMS

becomes available to agency users

(whose access is controlled by

system security), such as

detectives, crime analysis and

community-oriented policing

divisions, command staff and

others in the department for tactical

use and for developing strategies in

crime prevention and response.

• A public interface is built into most

records management systems to

provide information to the

community (in compliance with

privacy guidelines as mandated by

28 CFR 23).

• Appropriate RMS data and

information can be shared and

exchanged with other justice

agencies.
Information Technology Descriptions 253

■ Strategic: Offering the organization critical Strategic

information that assists in tactical planning,

resource deployment, performance assessments (individuals and units), risk assessment and management, and accountability.

■ Tactical Tactical: Providing officers and other Tactical

employees with immediate access to

complete, accurate, timely and integrated

information in a variety of formats (data,

images, photos and video). Allowing effective

analysis of crime trends and hotspots, thus

contributing to proactive — rather than

reactive — policing and to tactical

decisionmaking.

■ Investigative: Enabling the use of advanced Investigative

case management tools (case distribution,

tracking and disposition) for all personnel

assigned or involved with a case, including

modern property and evidence collection,

analysis and disposition tools, such as bar

coding and enterprisewide access to the

status of property and evidence.

■ Administrative: Providing information on Administrative

personnel, training and scheduling, as well as

information that can assist with developing

annual budgets and setting departmental

policies and procedures.

Modern RMS applications are focused on

improving data accuracy and the speedy retrieval

of information. They are designed to reduce data

entry (thereby reducing errors and duplicate

information entry into separate systems) and the

use and storage of paper documents. In general,

these systems can significantly streamline data

processing and workflow while improving the

overall quality of information captured.

Typical RMS Features*

Technology Components Technology Components

— Workstations

• Networked PCs

• Wireless devices

• Displays

— Servers

— Optical storage

— Hand-held devices

— Bar coding (property and evidence)

— Printers

Primary Modules Primary Modules

— Incident entry/Management

— Persons

— Vehicles

— Locations

— Arrests/Bookings

— AFR

— Crime analysis

— Uniform Crime Reporting

— National Incident-Based Reporting

— Traffic (citations, collisions, etc.)

— Investigations

— Property and evidence

— Personnel, training, scheduling

— Activity logs

— Crime alerts, hot sheets

— Inventory

— Administration

— Pawn

— Permits

— Licensing

— Animal control
254 Appendix 1

Human Interface

— Who uses it?

• Sworn personnel

• Records

• Command staff

• Supervisors

• Detectives

• Jailers

• Property/evidence clerks

• Crime analysts

• Dispatchers

— Who supports it?

• Small-medium agency: at least !/TM FTE

• Large agency: 1 or more FTEs

• Vendor

— How long should it take to learn?

• Application: 20-30 hours

• Administrative support: 80-100 hours

• Depending on skill set and database

design

*This is not intended to be a comprehensive list of RMS features.

Typical RMS Features (continued)

Inputs

— CAD incident data

— Mobile data (field officers)

• AFR

• Field interview cards

• Citations

— Personnel data entry

• Records

• Property

• Reports

• Detectives

• Officers

— NCIC data

Outputs Outputs

— Reports

— NCIC uploads

• Stolen vehicles

• Warrants

— CAD scheduling data

— Data for integrated justice

— Variable exports

• Jail

• Ticket processing

• Parent organization applications
Information Technology Descriptions 255

Jail Management Systems

An effective jail information management system (JMS) will

assist with the full management of a jail or correctional facility,

including tracking inmate and facility data. A JMS operates very

similarly to a

traditional RMS,

only it is tailored

to the information

management

needs of a

detention facility.

The JMS provides

capabilities for

inmate processing,

classification, cell

management,

property, commissary, scheduling and inmate programs. Inmate

information, such as medical history, gang affiliation, detention

history and visitor logs, as well as digital images like fingerprints

and mugshots, can be stored and linked within the JMS.

The effective JMS is integrated with automated fingerprint

identification and mugshot systems to handle digital fingerprint

and mugshot capture, searches, verifications and identifications

against a variety of internal and external databases. Property can

also be tracked and integrated into the JMS through the use of

bar coding technology. In some facilities, bar coding is also used

to track inmates as they move about the facility.

A key feature of JMS is its ability to assist in decisionmaking,

such as the objective classification of inmates based on their risk

level and gang affiliations; housing; and identifying inmates who

may be eligible for early release or specific programs.

Like the RMS, the JMS offers robust tools for data linkage,

analysis and sharing with other justice information systems. The

JMS can also be relied upon to assist with administrative and

personnel management features.

Improving the inmate management and

identification process through

integrated jail and imaging

technologies:

HOW IT WORKS

• A suspect is arrested and brought

to the booking station

• If outfitted, arresting officers may

transmit arrest information directly

to the JMS.

• At the station, fingerprints are

captured via a livescan device,

along with some basic information

on the individual for identity

verification and initial “match” with

the local database. In many cases,

the automated fingerprint

identification system (AFIS) then

electronically submits the prints to

the State and then on to the FBI in

participating States.

• Upon identification, information

about the offender is returned from

the State, Federal and local queries

and stored in the JMS.

• Meanwhile, a mugshot is also

captured digitally and stored in the

JMS.

• JMS pulls historical and other

information gathered and/or stored

within JMS to assist in making

classification and housing

decisions.

• JMS links photographs,

fingerprints and property to the

inmate’s record.

• A bar code label is affixed to the

inmate’s property and/or

identification wristband for tracking

purposes.
256 Appendix 1

Typical JMS Features*

Technology Components Technology Components

— Workstations

• Networked PCs

• Monitors

— Identix/Livescan

— AFIS

— Mugshot cameras/Workstations

Primary Modules Primary Modules

— Booking/Inmate processing

— Identification

• Wristbands/ID badges

— Classification

— Accounting

— Transportation

— Food processing

— Housing

— Commissary

— Medical screening

— Pharmacy

— Property

— Scheduling

— Cell management

— Inmate programs

— Mental health

Inputs

— CAD

— RMS

— AFIS

— NCIC data

— Mugshot

— Jail employees

— Arresting officers

— Patrol officers via mobile computer

Outputs Outputs

— State/Federal corrections databases

— Other justice information system partners

Human Interface

— Who uses it?

• Sworn personnel

• Records

• Command staff

• Supervisors

• Jailers

• Property/evidence clerks

• District Attorney’s Office

• Public Defender’s Office

• Courts

• Probation

• Parole

— Who supports it?

• Small-medium agency: at least !/TM FTE

• Large agency: 1 or more FTEs

• Vendor

— How long should it take to learn?

• Application: 30-40 hours

• Administrative support: 80-100 hours

• Depending on skill set and database

design

*This is not intended to be a comprehensive list of JMS features.
Information Technology Descriptions 257

Improving agency responses to crime

and enabling complex analysis for

crime prevention and preparedness

through GIS and computer mapping:

HOW IT WORKS

• When a call for service is received,

E911 ANI/ALI data populates the

CAD, and the GIS identifies the x/y

coordinates for the location.

• AVL provides information on

agency unit location and the CAD

draws upon GIS and AVL to assist

in formulating a response strategy.

• Post-incident, command staff and

others can review the incident and

the agency’s response and use GIS/

AVL to assist in analyzing the

effectiveness of the response and

determine areas for improvement.

• Crime analysts can conduct

comprehensive and complex

analysis of crime, location and

geographic data to identify

hotspots, trends and potential

emerging criminal activity. New

and/or improved strategies for

preventing and/or responding to

crime can be developed based on

these analyses.

• Community groups can access

similar information via the Web or

during meetings with law

enforcement officials to help

organize a more effective

community awareness and

response.

SCHOOLS

STREETS

BEAT

DRUG

TRAFFICKING

Geographic Information Systems,

Computer Mapping and Automated

Vehicle Location

For law enforcement agencies, the combination of geographic

information systems (GIS), computer mapping software, and

automated vehicle location (AVL) creates a powerful tool set for

responding to and fighting crime. GIS facilitates effective

planning for emergency response and helps agencies determine

crime mitigation priorities, analyze current and historical

events, and effectively analyze crime to assist in predicting and

responding to future events. Furthermore, GIS allows for

complex linkages and searches against a database, rather than

storing information in flat files that maintain few relationships.

GIS also provides critical information to emergency responders

en route to an incident to assist in tactical planning and

response.

Emergency Response

To develop an effective police response to an incident or

emergency means that law enforcement agencies must have

precise information about the

location of a crime, incident,

suspect or victim. The ability

to access and process information quickly while displaying it

visually allows decisionmakers

to more efficiently determine

the appropriate tactical

response.

GIS is complex in that it stores

information about a region in

the form of “layers” connected by a common frame of reference (x/y

coordinates). In addition to the specific coordinates, GIS also

contains a variety of other geographic references to a specific

location, such as addresses, place names, ZIP codes, phone numbers

and even indirect references to geography (i.e., “300 yards from the

County Jail”). This is where the true power of a GIS application

comes in to play. The ability to layer the multiple pieces of informa-
258 Appendix 1

tion about a location allows a GIS to view

either discrete pieces or levels of information or to increase the complexity of an

analysis by layering many levels of

information together to create a detailed

picture.

Thus, GIS, working with computergenerated mapping, has several important applications in a law enforcement

agency. A geo-based CAD system, as

discussed earlier, will pinpoint the precise

location of a 911 caller, an incident or a

location so that law enforcement

response is accurate. Used in conjunction

with AVL and global positioning systems

(GPS) that provide exact positioning of law enforcement units through satellite tracking, GIS can

assist in deploying the right units and resources to a scene.

Crime Analysis Crime Analysis

GIS and computer mapping have revolutionized the capabilities of law enforcement to conduct

comprehensive crime analysis. GIS software, combined with computer-generated mapping programs,

have replaced the traditional pin maps on the wall at headquarters that literally used push pins to

identify one-dimensional criminal activity. GIS and mapping now act as an interface for integrating,

accessing and displaying massive amounts of location-based information. With GIS, users can

visualize crime occurrences and multiple

layers of criminal activity

in relationship to a

variety of other factors.

For example, analysts can

look at drug activity in a

particular jurisdiction

and its relationship to

school locations or to

public telephone

locations. So the GIS

analysis not only

identifies areas of

criminal activity, but also

the factors that may

contribute to the activity

taking place in a particu-
Information Technology Descriptions 259

lar location or the particular

population that could be

affected by the activity. In

addition, simply looking at

crime density in particular

locations is an important tool

in making patrol allocation

decisions.

GIS has also become more

accessible to all agency users.

Not only is this information

directly accessible to a variety

of users through desktop

computer stations, but more

and more, agencies are

“pushing” the GIS and map software and capabilities to officers via laptops in the patrol cars and to

the public via the World Wide Web.

Typical GIS Features*

Technology Components Technology Components

— Server

— Displays

— Scanners

Inputs

— Base maps

— Layers from governmental agencies

(assessor, tax records, building/safety, etc.)

— CAD

— RMS

— Users

Outputs Outputs

— Maps

— World Wide Web

— RMS

Human Interface

— Who uses it?

• Sworn personnel

• Crime analysts

• Detectives

• Command staff

• Supervisors

— Who supports it?

• !/TM FTE

• Vendor

— How long should it take to learn?

• Application: 10-20 hours

• Administrative support: 80-100 hours

• Depending on skill set and database

design

*This is not intended to be a comprehensive list of GIS features.
Appendix 2:

Glossary
Acceptance testing Acceptance testing Chapter 17, page 213

The process that an agency uses to verify that the delivered and installed product meets requirements

specified in the procurement documents and contract, particularly regarding functionality, reliability and

performance.

Activity Activity Chapter 10, page 130

An element of work performed during a project that normally has an expected duration, as well as cost

and resource requirements.

Ad hoc working groups Ad hoc working groups Chapter 1, pages 27, 31

Groups that are formed as a subset to the project’s formal decisionmaking structure to look at specific

tasks and business processes that require more in-depth research or analysis, or to carry out research on

and development of a variety of project-specific plans, models, policies and directions. Assembled on a

temporary basis to address a specific issue or task.

Agreement for Extended Services Agreement for Extended Services Chapter 15, page 195

An exhibit in the contract that should be included if an agency requires continuous vendor product

support. It should identify the type of service, the availability and the allowable timeframe for response

and correction of various types of problems. The exhibit should detail the pricing that has been

negotiated for recurring support.

Assumptions and constraints Assumptions and constraints Chapter 3, page 59 and Chapter 10, page 131

Circumstances and events that can affect the success of the project and are generally out of the control of

the Project Team. Include in the Project Charter to provide assistance in making/justifying decisions.

Consult also when developing the project timeline and Risk Management Plan.

Automated Field Reporting (AFR) software Automated Field Reporting (AFR) software Appendix 1, page 250

AFR automates the incident and other reporting processes from the patrol car. Optimally, AFR allows the

capture of incident and report information and then electronically sends the report to a supervisor for

approval and submission to the records management system (RMS).

Automatic Vehicle Location (AVL) software Automatic Vehicle Location (AVL) software Appendix 1, page 257

Used by law enforcement agencies to remotely track the location of agency units via satellite global

positioning systems (GPS). AVL combines GPS technology, wireless communications, street-level

mapping and a user interface.

Best practices Best practices Chapter 1, page 23

Industry-proven processes or methods that, when executed effectively, lead to enhanced or superior

project performance and ensure the success of an undertaking (such as planning, procurement,

implementation and management).

Bonding costs Bonding costs Chapter 11, page 142

Bonds required may include those dealing with performance, maintenance and payment.

Appendix 2:

Glossary
264 Appendix 2

Business case Business case Chapter 3, page 56

The project’s marketing plan that articulates why the project is important in terms of operational benefits

to the agency, the justice system in general and the public. Used to educate and inform all project

stakeholders.

Business process Business process Chapter 4, page 68

A written description of the things that employees do every day in their job functions assessed on a

“what,” “why,” “when,” “how” and “where” basis. Business processes are what technology seeks to

enhance or improve.

Business Process Baseline report Business Process Baseline report Chapter 4, page 72

A report created by the Project Manager that documents an organization’s business processes. It is used

as a reference for understanding how the organization currently accomplishes its business objectives.

Client/Server Client/Server Chapter 6, page 94

An application that runs on a personal computer or workstation and relies on a server to perform some

operations. A thin client is a client designed to be especially small so that the bulk of data processing

occurs on the server.

Communications Plan Communications Plan Chapter 13, page 159

Formal and agreed-upon strategies for communicating project status and activities to key stakeholders,

and methods for developing historical project records and archives.

Computer-aided Dispatch (CAD) System Computer-aided Dispatch (CAD) System Appendix 1, page 248

Fully automates the call-taking and dispatching functions of a law enforcement agency and initiates and

manages dispatch and incidents.

Consulting costs Consulting costs Chapter 11, page 142

Generally, a full-service consultant who provides needs analysis, project planning, procurement

assistance, contract negotiations and implementation assistance, and will receive an average of 15% of the

total project costs.

Contingency costs Contingency costs Chapter 11, page 142

Funding that is set aside for unexpected and, therefore, often unbudgeted activities. On average,

contingencies range from 10–15% of the hardware and software costs.

Contract Contract Chapter 15, page 187

A binding agreement between an agency and a chosen vendor that defines the obligations between the

parties, including deliverables, services and responsibilities.

Decisionmaking structure Decisionmaking structure Chapter 1, page 23

A group of agency staff that provides leadership and accountability; defines the business of the agency;

analyzes technical environments, policies and solutions; and effectively manages projects. Requires

participation from three key representative groups within an agency: executive, business or operational,

and technical.
Glossary 265

Deliverable Deliverable Chapter 10, page 130

A measurable, tangible, verifiable outcome that must be produced to complete a project or part of a

project.

Environmental scan (ES) Environmental scan (ES) Chapter 3, page 53

An initial step in the planning process that helps the Project Team gain perspective on the initiative by

allowing the team to systematically assess factors that present opportunities or threats to the success of

the project. Sometimes referred to as a situation or “SWOT” assessment, an ES contains an internal scan

that identifies strengths (S) and weaknesses (W) of the agency and an external scan that identifies

external opportunities (O) and threats (T) to the agency.

Executive Sponsor Executive Sponsor Chapter 1, page 24

The individual who has the ultimate accountability for the project, having authority to sanction the

project and make it a priority. Serves as the project’s ultimate decisionmaking authority.

Exhibit Exhibit Chapter 15, page 191

Subsets of information related to the contract, usually created by the Project Team. Includes such

documents as: Statement of Work (SOW); Project Deliverables; Payment Schedule; and Project Timeline.

External costs External costs Chapter 11, page 139

The costs that most agencies associate with procurement, which are generally lumped together in three

main categories: hardware, software and services. They also include the staff, resources, supplies,

infrastructure, consultants and virtually all project elements that fall beyond the direct financial control

of the agency or the parent organization.

Focus groups Focus groups Chapter 5, page 82

A somewhat informal technique that can help to assess user needs while designing the system. Usually 6-9

users gather to discuss issues and concerns about the features of the new system.

Functional specifications Functional specifications Chapter 12, page 155 and Chapter 14, page 179

Precise descriptions of how a product should operate. These statements should be succinct. A Project

Plan and procurement document often contains numerous such functional requirements. During

procurement, vendors should be required to divulge how closely their product matches an agency’s

functional specifications.

Functionality testing Functionality testing Chapter 17, page 214

A type of acceptance testing designed to ensure that the vendor’s software is functioning as described in

product literature and, possibly, in their response to the agency’s RFP.

Funding streams Funding streams Seven Facts, page 12

Variety of means by which an agency may obtain funding for a project, including internal budgets, State

and Federal grant programs, bond measures, etc.
266 Appendix 2

Gantt chart Gantt chart Chapter 10, page 133

A popular project management charting method in which a schedule is displayed graphically. It consists

of a horizontal bar chart with time as the horizontal axis and either resources, jobs or orders as the

vertical axis. Individual operations are displayed as horizontal bars in the chart, indicating the time at

which the job begins and ends. Many variations on the Gantt chart exist to display additional kinds of

information. Gantt charts can be drawn physically on paper, but are usually implemented through

computer software.

Geofile Construction Document Geofile Construction Document Chapter 15, page 195

An exhibit included in the contract if an agency is purchasing a CAD application. Often the agency’s base

geographic information systems (GIS) must be converted into the CAD vendor’s preferred format. The

GIS data are used for creating a geofile in the CAD that verifies the addresses that are entered into CAD.

This is a very complex procedure and warrants an individual contract exhibit dedicated exclusively

toward defining how the GIS material will be converted, tested and installed into the CAD.

Geographic Information Systems (GIS) Geographic Information Systems (GIS) Appendix 1, page 257

Stores information about a region in the form of “layers” connected by a common frame of reference (x/y

coordinates). In addition to the specific coordinates, GIS also contains a variety of other geographic

references to a specific location. Other data sets include addresses, place names, ZIP codes, phone

numbers and indirect references to geography.

Hardware Hardware Chapter 11, page 140

Tangible devices that enable the use of various software programs. Includes servers, workstations,

laptops, infrastructure (network components) and telecommunications devices (i.e., wireless modems).

Holdbacks Holdbacks Chapter 12, page 154

A contract provision that allows an agency to keep a percentage of a vendor’s payment until after the

vendor successfully completes certain milestones. Useful for keeping the vendor interested in completing

all of the tasks associated with a project, even those that are less profitable than others.

Implementation plan Implementation plan Chapter 16, page 207

The blueprint that enables project management to define the rules that govern how technology will be

installed, tested and managed.

Information system Information system Seven Facts, page 11

A purposefully designed system that brings data, computers, procedures and people together in order to

manage the information that is important to an organization’s mission.

Initial costs Initial costs Chapter 11, page 137

One-time expenses to purchase technology and services for a project. Must be considered in conjunction

with recurring costs (see page 269).

Internal costs Internal costs Chapter 11, page 139

Those costs over which your agency has direct financial responsibility and control, including personnel

costs, infrastructure costs, cost recovery fees, etc.
Glossary 267

Invitation to Bid (ITB) Invitation to Bid (ITB) Chapter 14, page 178

A procurement tool used to define an agency’s requirements, contractual terms and pricing mandates.

Used rarely, an ITB requires a vendor to either accept all of the terms or none.

Jail Management System (JMS) Jail Management System (JMS) Appendix 1, page 255

Assists with the full management of a jail or correctional facility, including tracking inmate and facility

data.

License Agreement License Agreement Chapter 15, page 195

An exhibit included in the contract that defines what rights the agency has with regard to the use of the

vendor’s software.

Lifecycle costing methods Lifecycle costing methods Seven Facts, page 14

Methods to determine the total cost of owning the technology, from procurement through upgrade and/

or replacement.

Liquidated damages Liquidated damages Chapter 12, page 154

A contract provision that compels the vendor to pay the agency if a contracted deadline is missed.

Milestone Milestone Chapter 10, page 130

A significant event in the project, usually completion of a major deliverable.

Milestone review Milestone review Chapter 10, page 134

A session in which the Project Team gathers together to review and analyze milestone completion and the

process for its completion, and adjust the schedule for future deliverables and milestones, if necessary.

Mobile Data Computing Mobile Data Computing Appendix 1, page 250

Comprised of several hardware and software technologies working together to allow law enforcement

officers to access, receive, create and exchange information wirelessly in the field.

Module Module Chapter 16, page 94

A portion of a program that carries out a specific function and may be used alone or combined with other

modules of the same program.

Outsourcing Outsourcing Chapter 1, page 37 and Chapter 11, page 141

The act of hiring an outside source to perform a service that is beyond the agency’s existing resources,

usually a consultant.

Performance testing Performance testing Chapter 17, page 214

A type of acceptance testing that is designed to determine the speed of the combined hardware and

software package during various transactions.

Performance reports Performance reports Chapter 10, page 132

Provides details about project status, including which deadlines have been met and which have not.

Whether prepared by the vendor or internal staff, performance reports should be provided on a weekly or

biweekly basis.
268 Appendix 2

Primary Agreement Primary Agreement Chapter 15, page 189

The terms and conditions that govern the agency’s relationship with the vendor. The agency’s City or

County legal staff often prepare the primary agreement document.

Problem escalation and resolution process Problem escalation and resolution process Chapter 1, page 36

A formal and agreed-upon process established by the decisionmaking structure for resolving disputes and

problems during a project. Includes documenting any such problems and their disposition.

Project Charter Project Charter Chapter 3, page 51

A document developed early in the process (prior to the full Project Plan) that contains an IT project

description, complete with scope, objectives, organization and staffing, a decisionmaking structure, the

project management approach and initial resource documents. Provides guidance to project staff in

planning and designing a system.

Project management Project management Seven Facts, page 16

The application of knowledge, skills, tools and techniques to project activities in order to move the project

forward to completion and to meet or exceed stakeholder needs and expectations from a project.

Project Management Institute (PMI) Project Management Institute (PMI) Chapter 2, page 47

One of the best resources for tools and support for the Project Manager. See www.pmi.com.

Project Manager Project Manager Chapter 1, page 28 and Chapter 2, page 43

An individual dedicated to and accountable for all project-related activities and solely responsible for the

project’s scope, quality and budget. Responsible for virtually all aspects of the initiative and is formally

accountable to the Steering Committee and the Executive Sponsor.

Project objectives Project objectives Chapter 9, page 124

Quantifiable criteria that must be met for the project to be considered successful. A critical part of scope,

objectives must include measures of quality, time, cost, performance, reliability and functionality.

Project planning Project planning Chapter 8, page 115

A dynamic process that results in a document that guides the entire IT project design, procurement,

implementation and future enhancements. The Plan is the repository for all project-related research,

decisions, deliverables and documents.

Project scope Project scope Chapter 3, page 58

Clearly defines the boundaries for the project. Scope addresses what users want (functions); how well the

user requirements are met (quality of ); when and how it must be developed (constraints); and why (the

value in the project).

Project timeline Project timeline Chapter 10, page 129

A mechanism to ensure the project is accurately and realistically scheduled so that it can be completed on

time within the resources available. The timeline is critical to help avoid delays and associated cost

overruns. Includes activities, deliverables and milestones.
Glossary 269

Quality assurances (QA) Quality assurances (QA) Chapter 17, page 213

Tests that ensure the vendor’s hardware and software perform according to specification.

Records Management System (RMS) Records Management System (RMS) Appendix 1, page 252

A system that captures, maintains and analyzes all police agency and incident-related event information

and is vital to the day-to-day operations of tracking and managing criminal and noncriminal events,

investigations and personnel information.

Recurring costs Recurring costs Chapter 11, pages 137, 139, 144

Continuing costs that must be considered to support, maintain, and enhance hardware and software and

user skills. Determine in concert with initial costs (defined on page 266).

Reliability testing Reliability testing Chapter 17, page 214

A type of acceptance testing designed to determine the “uptime” of a vendor’s solution. Typically, this

testing focuses on hardware and involves the use of special software that simulates the volume of

transactions that the vendor claims to be acceptable.

Request for Information (RFI) Request for Information (RFI) Chapter 11, page 141 and Chapter 14, page 176

A procurement tool used to elicit generalized information about vendor products and services. Pricing, if

included at all, is generic and based on averages.

Request for Proposal (RFP) Request for Proposal (RFP) Chapter 14, page 176

A procurement tool used to obtain actual hardware, software and services proposals from vendors.

Request for Qualifications (RFQ) Request for Qualifications (RFQ) Chapter 14, page 177

A procurement tool used to determine whether a vendor meets minimum qualification standards set by

the issuing agency. Does not request a proposal response with prices and specific proposal details.

Risk management Risk management Chapter 2, page 48 and Chapter 12, page 149

A planning process that prepares the agency for dealing with potentially harmful events that could

happen in a technology initiative. The Risk Management Plan is prepared by the Project Manager and

Steering, User and Technical Committees.

Schedule Management Plan Schedule Management Plan Chapter 10, page 132

Provides a structured process for documenting, analyzing and approving changes in the project schedule.

The Schedule Management Plan should be a formal process that is documented in the Project Plan.

Scope Management Plan Scope Management Plan Chapter 9, page 125

Provides a structured process for documenting, analyzing and approving changes in project scope. The

Scope Management Plan should be a formal process that is documented in the Project Plan.

Scope planning Scope planning Chapter 9, page 121

A process to precisely define and document specific activities and deliverables for a particular project.

Clarifies and defines the project focus and keeps activities in control and within agreed-upon boundaries.

Establishes a formal process for proactively managing changes in project scope.
270 Appendix 2

Scope statement Scope statement Chapter 9, page 122

Defines what is to be included in the project, as well as what is to be excluded. Developed by the Project

Manager and User Committee.

Scope-time-cost relationship Scope-time-cost relationship Chapter 3, page 58

The project elements of scope, time and cost are inextricably linked and have a proportional relationship.

Should any one of these elements grow or reduce, the other two elements grow or reduce proportionally.

Software Software Chapter 11, page 140

What is required to make a system operational, including operating system software, vendor-supplied

application software, third-party software and any network management tools.

Sole-source Sole-source Chapter 14, page 178

A procurement tool used when an agency can show that the chosen vendor is the only vendor capable of

supplying the required hardware, software and services in the best interest of the agency.

Stakeholders Stakeholders Chapter 1, page 25

Individuals and organizations who are actively involved in the project, or whose interests may be

positively or negatively affected as a result of project execution or successful project completion.

Statement of Work (SOW) Statement of Work (SOW) Chapter 15, page 191

Included as an exhibit in a contract, the SOW defines each task involved in the entire project. It is the

blueprint for implementation.

Steering Committee Steering Committee Chapter 1, pages 27, 28

Members are generally high-level managers and/or supervisors within the agency. This group will ensure

that a structured project management process is adopted and followed. Provides constant guidance and

oversight to the project, its progress and deliverables, and will make most decisions related to the project.

Strategic IT Vision Document Strategic IT Vision Document Seven Facts, page 15

Articulates how technology will assist an agency in meeting its core business mission and establish an

ongoing process to evaluate, upgrade and enhance those technologies as business goals and technology

change.

SWOT SWOT Chapter 3, page 56 and Chapter 5, page 83

An acronym sometimes used in referring to a situation assessment, SWOT stands for Strengths,

Weaknesses, Opportunities, Threats. See Environmental Scan.

Systems development lifecycle (SDLC) Systems development lifecycle (SDLC) Seven Facts, page 13

A cyclical process regarding IT, with several stages, including planning, procurement, implementation

and management.

Technical Committee Technical Committee Chapter 1, pages 27, 31

Includes technical staff from the agency, as well as others from the agency’s parent organization (e.g.,

City, County or State), if such support is provided. This committee’s role is to analyze the agency’s existing

technical environment and to research and propose solutions to the agency’s business needs and

problems.
Glossary 271

Technology Baseline Report Technology Baseline Report Chapter 4, page 73

A report that documents an organization’s current technology environment. Created by the Project

Manager, with assistance from the Technical Committee, it is used to show how the current technology is

used, as well as in determining how new technology could improve efficiency. The Technology Baseline

Report is also used in the procurement process.

Total Cost of Ownership (TCO) Total Cost of Ownership (TCO) Chapter 11, page 145 and Chapter 18, page 230

Used in budget planning, TCO refers to the total costs associated with ownership, usage and maintenance

of the system over time.

User Committee User Committee Chapter 1, pages 27, 29

Includes subject matter and business process experts for the functions to be addressed. This committee’s

role is to assist and support in creating a Project Charter and ultimately the Project Plan. This committee

will analyze existing workflows, define business processes, and look for efficiencies and establish the

requirements of any new system.

Vision statement Vision statement Chapter 3, page 52

Written by the Steering Committee, the vision brings a tangible reality to what the agency will address

with the new system.

Work breakdown structure (WBS) Work breakdown structure (WBS) Chapter 9, page 123

A component of the scope statement. Dissecting scope by breaking it down into smaller elements or

projects produces specific deliverables and indicates who is responsible for enacting them. This

ultimately defines activities and milestones of the full project scope.
Appendix 3:

Bibliography

of Resources
Appendix 3:

Bibliography of Resources

■ Project Charter issues

Vision Statement Vision Statement

• http://www.allianceonline.org/faqs.html http://www.allianceonline.org/faqs.html

Website of The Alliance for Nonprofit Management. Provides details of what is in a vision statement, how

a vision statement is used and the benefits of a vision statement. Also details risk management and

strategic planning.

Business Case

• http://www.solutionmatrix.com/

Business case analysis site, offering tools, training and practical help for everyone who builds the financial

business case. Also offers resources, guides and a newsletter.

■ Needs Analysis

• http://www.isdesigners.com/serv01.htm

Provides a brief summary of a needs analysis and its benefits. The company conducts a training needs

analysis and designs the best solution based on their findings. The site provides “Tips for Writing

Training Objectives” and links to Instructional Techniques, Project Management and Evaluation topics.

■ Project Planning

• Tips for Ensuring Successful Technology Implementation. COPS Office Fact Sheet, November 26, 2001.

See http://www.usdoj.gov/cops/pdf/fact_sheets/e10011344.pdf http://www.usdoj.gov/cops/pdf/fact_sheets/e10011344.pdf

• http://www.prosci.com/t1.htm

Offers an excellent project planning toolkit for order. This resource tool addresses such issues as project

management, planning, methodology selection, team building, team selection, consultants, team

readiness, objective setting, project scope and project leadership. Website offers a toolkit overview and

table of contents.

• http://books.mcgraw-hill.com/cgi-bin/pbg/0071360506.html http://books.mcgraw-hill.com/cgi-bin/pbg/0071360506.html

Offers this best-selling book: Project Planning, Scheduling & Control, 3rd Edition, A Hands-On Guide to

Bringing Projects in on Time and on Budget. This practical, proven and easy-to-use book provides

guidance for effective project management. The site provides a description of the book, the table of

contents and online purchasing.

• http://www.wilsonmar.com/1projs.htm

An extensive online guide to using project plans. Includes: Project Management Frameworks; Project

Phases and Milestones; Project Goals and Outcomes; Project Processes, Roles and Deliverables; Roles:

Advisors and Consultants; Project Tasks; Risk Management; Project Management Software Tools; Project

Plan Views; and Best Practices for Project Management. Comments and questions can also be submitted

to a support contact via email.
Appendix 3 276

• http://www.planxpert.com/

PlanXpert is a practical project planning tool in the form of software for IT professionals. The PlanXpert

products provide a set of easy-to-use tools for creating a customized IT project plan, accompanied by a

methodology of proven practices. The site offers descriptions of the three products, methodology

concepts, planning and executing a project with the product. You can also request more information

about the products and order them online.

• http://gartner11.gartnerweb.com/public/static/hotc/hc00075520.html http://gartner11.gartnerweb.com/public/static/hotc/hc00075520.html

Offers online article from the Gartner Group: “What to look for in an IT strategic plan.”

■ Project Management Project Management

• http://www.pmi.org/

Website of the Project Management Institute, a professional organization for project managers. Includes:

a detailed description of a project and project management, information about annual seminars and

symposia, as well as membership and education information.

• A Guide to the Project Management Body of Knowledge. Project Management Institute. See http://

www.pmi.org/publictn/pmboktoc.htm.

• http://www.mde.net/cio/

A practical guide on how to manage any project. Offers a free project management template.

• http://www.projectmanagement.com/main.htm

Informational project management site includes these links: Resources (who can help), Links (to other

project management sites on the Web), Tools (what tools can be used), and Online (where help can be

found online).

• http://www.project-manager.com/

A complete online guide for anyone who must plan, implement and complete a commercial project. Get

professional advice, upgrade personal skills, exchange ideas or, above all, get your project up and running

on time and within budget.

• http://www.planview.com/

Offers project managing software. Includes product information and an extensive Support/Services link

that not only supplies online help, but also email addresses and telephone numbers of service personnel.

• http://www.microsoft.com/office/project/

Offers project management software with a free 60-day trial period to see if their features are right for the

project at hand. Provides information about the product, including support.

• http://www.tenstep.com/

Provides the information necessary to successfully manage projects, including processes, procedures,

techniques, best practices and templates. The site starts with the basics in a step-by-step approach and

becomes more and more sophisticated according to your specific project.

• http://www.4pm.com/articles/pplanning.html http://www.4pm.com/articles/pplanning.html

Resource site for project managers and executives offers project management articles, books, tools and

training courses. Includes brief descriptions, prices and online purchasing.

• http://www.performanceweb.org/default.htm

Website of the Performance Institute, a leading authority and repository on performance-based management practices. Site includes sections on IT and law enforcement.
Bibliography of Resources 277

• The Accidental Project Manager: Surviving the Transition from Techie to Manager. Patricia Ensworth.

This “cheat sheet” provides practical advice and critical information to manage successful software

projects. The companion Website, http://www.wiley.com/compbook/ensworth, provides downloadable

templates, forms and links to valuable resources.

• A Practitioner’s Guide to Managing Projects in the Information Age. Robert Ambrosino, Ph.D. Government Technology Press.

• IT Professional’s Guide to Project Management. Tech Republic. See http://www.techrepublic.com.

• Project Management Memory Jogger. Paula K. Martin and Karen Tate PMP, Martin Training Associates.

This pocket-sized book is an easy-to-use guide for working through any project. It features step-by-step

directions for the Martin Training Associates’ CORE Project Management® method that includes the

activities needed to complete any project successfully. See http://www.martintraining.net/resources/

pmmj.html pmmj.html.

• http://www.allpm.com/

This Website, the Project Managers Home Page, is intended to help project managers succeed by building

a worldwide community of project managers.

• http://www.projectmagazine.com/

This online magazine is a useful resource for project managers.

• http://www.newgrange.org/

Website of the New Grange Center for Project Management, an international Web-based organization.

• http://www.projectnet.co.uk/pm/pmt/pmt.htm

Project Manager Today: an online journal with links to articles dating back to 1998.

• http://www.pmboulevard.com/home.jsp

Project Manager Boulevard Website, which offers a knowledge center, online training, articles and other

resources.

• http://www.infogoal.com/pmc/pmchome.htm

Project Management Center Website, which offers links to project management news, articles and white

papers, events, organizations and experts.

• http://www.pmforum.org/

Website for the Project Management Forum, including links to a project management library, best

practices and online forums.

■ Risk Management Risk Management

• http://www.netcomuk.co.uk/~rtusler/index.html http://www.netcomuk.co.uk/~rtusler/index.html

Site addresses project risk management methods and disciplines to improve the chances of completing

the project on time, within budget and to meet the users’ requirements.

• http://www.aeat.co.uk/consulting/prm.htm

Describes the benefits of project risk management. Offers a service portfolio: definition of project risk

management, when it should be used, and a plan to ensure that the whole project team is aware of what

the risks are, their responsibilities in managing those risks, and how that will be achieved.

• Managing the Risks: A Guide for Improving RFP and Procurement Practices in Justice Technology

Acquisitions. Institute for Law and Justice, for National Institute of Justice, U.S. Department of Justice.
Appendix 3 278

February 23, 2000. Helps law enforcement agencies learn how to use an RFP to communicate effectively

with vendors and begin the process of developing shared expectations for the project. Provides references

and organizational contacts of practical, legal and educational use to justice professionals. See http://

www.ilj.org/infotech/casestudies/rfpbook.pdf www.ilj.org/infotech/casestudies/rfpbook.pdf

• http://www.allianceonline.org/default.htm

Website for the Alliance for Nonprofit Management offers great resources on strategic planning and risk

management.

• http://www.risksig.com/

PMI’s Risk Management Special Interest Group. Offers forums for the professional exchange of ideas on

topics related to project risk management. Includes links to newsletters, articles and resources.

• http://fcw.com/civic/articles/1998/civic_101298_77.asp

Article on civic.com on risk management for IT projects.

• http://www.cio.com/archive/041596_risk_content.html http://www.cio.com/archive/041596_risk_content.html

Article in CIO Magazine on risk management.

• http://members.ozemail.com.au/~thomsett/form/index.htm

Online risk assessment survey.

■ Procurement Procurement

• http://www.itpba.com/#mission

Website of the Information Technology Procurement Benchmarking Association, representing IT

procurement professionals. The ITPBA conducts studies to identify the practices that improve the overall

operations of its members, and offers free membership and newsletter.

• http://www.search.org/it-clearinghouse/default.asp

IT Clearinghouse offers database of justice agency procurement documents to use as models.

Outsourcing

• www.outsourcing.com

Website of the Outsourcing Institute, a global professional association that provides outsourcing

information, networking, resources, services and solutions.

• http://www.cio.com/research/outsourcing

Website of the Outsourcing Research Center.

Budgeting

• http://www.srcsoftware.com/

Company offers software to help businesses meet budgeting and financial reporting needs. Site provides:

information about the product, contact information, and a demonstration CD-ROM.

• http://www.techsoup.org/

articlepage.cfm?articleid=197&topicid=11&CFID=2022037&CFTOKEN=35938665

Article on “Technology Budgeting Basics: How much should you be spending?” in TechSoup.org.
Bibliography of Resources 279

■ Meetings

• Roberts Rules of Order, 2nd ed.

• How to Make Meetings Work. Michael Doyle and David Straus. Berkeley Publishing Group.

• http://www.telstra.com/business

Provides useful information on running meetings.

■ Dictionaries

• Webster’s New World Computer Dictionary.

• Random House Webster’s Computer and Internet Dictionary, 3rd edition.

• http://www.pcwebopedia.com

Online dictionary and search engine for computer and Internet terminology.

■ General Reference

• http://www.startwright.com/

A resource Website for IT project managers. Includes links to business process reengineering tutorials,

best practices, managing change, outsourcing and procurement resources, among others.

• http://www.rms.net/lc_briefs.html http://www.rms.net/lc_briefs.html (issue briefs)

• http://www.rms.net/lc_tutorial_series.htm (tutorials)

• http://www.rms.net/lc_visitor_forum.html http://www.rms.net/lc_visitor_forum.html (forum)

• http://www.rms.net/self_test.htm (self test)

This information resource offers issue briefs, tutorials and visitor forum areas on key IT issues, such as IT

budgeting and performance management, project funding and project proposals. It also offers a self test

to see how your agency’s IT decisionmaking process stacks up against those of “best practices” organizations.

• http://www.search.org/integration/funding.asp

Provides links to grant/funding opportunities.

■ Websites (Agencies, Organizations and Associations) Websites (Agencies, Organizations and Associations)

• http://www.search.org

Website of SEARCH, The National Consortium for Justice Information and Statistics. Offers sections on

integrated justice and law enforcement IT, with links to news, articles, organizations, standards, vendors

and other resources.

• http://www.usdoj.gov/cops/home.htm

Website of the Office of Community Oriented Policing Services, U.S. Department of Justice. Provides

links, news and information regarding COPS grants, programs and activities. A grant toolbox link

provides useful information for recipients of COPS grants.

• http://www.communitypolicing.org/

Website of the Community Policing Consortium. Offers a resource toolbox, publication, chat room and

other resource.
Appendix 3 280

• http://www.iacptechnology.org

Website of the International Association of Chiefs of Police’s Technology Clearinghouse, which offers

many useful links, including articles and publications, funding resources, RFIs/RFPs and practitioner

links.

• http://www.ialep.org/

Website of the International Association of Law Enforcement Planners. Offers members access to an

online Planning Abstract Service database.

• http://www.techsoup.org/index.cfm

The Website of TechSoup, the technology assistance site.

■ Integrated Justice Information Systems

• Defining Integration in the Context of Justice Information Systems: Toward a Common Understanding.

SEARCH, The National Consortium for Justice Information and Statistics. Provides a common framework

and vernacular for justice systems integration to assist practitioners, developers and other stakeholders

involved in planning efforts. See http://www.search.org/integration/

about_integration.asp#publications

• Toward Improved Criminal Justice Information Sharing: An Information Integration Planning Model.

International Association of Chiefs of Police.

• And Justice for All: Designing Your Business Case for Integrating Justice Information. Center for

Technology in Government. Offers a series of lessons and tools justice officials can use to build business

cases to win support and funding for integrated justice information systems.

• http://www.search.org/integration

This special SEARCH Website provides articles and news, resources, publications, and technical

assistance and funding information regarding integrated justice.

■ Law Enforcement IT

• http://www.search.org/it-clearinghouse/default.asp

The National Clearinghouse for Criminal Justice Information Systems, which provides justice agencies

with online access to a host of justice information resources, including impartial information on available

software solutions and a comprehensive, interactive database of justice agency RFPs.

• A Guide for Applying Information Technology in Law Enforcement. National Law Enforcement and

Corrections Technology Center (NLECTC). The Center offers support, research findings and technological expertise to help State and local law enforcement and corrections personnel perform their duties more

safely and efficiently: http://www.nlectc.org

• The Design of Information Systems for Law Enforcement. A Guide for Executives. Charles Drescher and

Martin Zaworski. A step-by-step process for determining agency needs for information — from gathering

to processing to utilization.

• Making Smart IT Choices. Center for Technology in Government. An IT guide for public managers who

are responsible for choosing, funding and building IT innovations.

• http://www.itmweb.com

The Information Technology Management Web offers a variety of online resources such as benchmark

tools, forums, books and white papers.
 FOR MORE INFORMATION:

U.S. Department of Justice

Office of Community Oriented Policing Services

1100 Vermont Avenue, NW

Washington, D.C. 20530

To obtain details on COPS programs, call the

U.S. Department of Justice Response Center at 1.800.421.6770

Visit the COPS Internet Web site by the address listed below.

www.cops.usdoj.gov