U.S. Department of Justice
Office of Community Oriented Policing Services 
Image of DOJ logo
Image of COPS logo
LAW ENFORCEMENT 
Tech Guide 
How to plan, purchase and manage technology (successfully!) 
A Guide for Executives, Managers and Technologists 
Image of Police truck and computer banks

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.

U.S. Department of Justice
Office of Community Oriented Policing Services 

Law Enforcement Tech Guide 
How to plan, purchase and manage technology (successfully!) 
A Guide for Executives, Managers and Technologists 

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

Image of DOJ Logo
U.S. Department of Justice
Office of Community Oriented Policing Services 
Office of the Director Washington, D.C. 20530 
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 time-
consuming tasks, dispatching personnel more efficiently, and improving an agencys 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 organizations 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

Contents
Acknowledgments..................................................................xii
About the Guide
About the Guide.......................................................................3
AssumptionsAbout You........................................................4
AssumptionsAbout 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
Seven Facts You Should Know BEFORE 
Reading this Guide..............................................................11

Part I:
Build the Foundation
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 ........................ 43 
Sample Project Manager Job Description..............................44
Project Managers Responsibilities.........................................46
Project Manager Tool Kit.......................................................47
Executive Sponsors: Make the Most of Your 
Project Manager..................................................................47


Chapter 3 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....9
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 ................................................................. 61 

Part II:
Conduct a Needs Analysis
Chapter 4 Assess Current Business Processes ......................................... 67 
Define the Organizations 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 ................................ 79 
Individual Interview Techniques............................................81
Focus Group Techniques........................................................82

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

Part III:
Create a Project Plan
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: Whats In, Whats 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


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

Part IV:
Chapter 14 Acquire the Technology
The Art of Procurement............................ 173 
Step 1: Research Your Jurisdictions 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 .............................................................. 187 
Understanding the Process..................................................188
Crafting the Contract Documents........................................188
Components of a Contract...................................................189
Tips for Negotiating a Solid Contract...................................198
Part IV Assignments ............................................................ 200 

Part V:
Implement the Technology
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 ........................... 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 .............................................................. 221 

Part VI: Maintain the Technology
Chapter 18 Ensure the Success of Your Technology Initiative:
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............................................................ 240 

Appendices
Appendix 1 Information Technology Descriptions ................................. 247 
Appendix 2
Glossary ............................................................................... 263 
Appendix 3
Bibliography of Resources .................................................... 275 

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 Nations 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 atwww.search.org.

About the Authors
Kelly J. Harris is Director of Justice IT Services for SEARCH, where she develops and
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 bachelors 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
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 masters 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. Kellys and Bills 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 doesnt. Their experience has shown that employing tools to
improve information management  such as decisionmaking structures, strategic plans,

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 
Major, Charlotte-Mecklenburg (NC) Police Department

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

PAGE 3
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, theres lots of literature out there on project planning and management, informa-
tion 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 implement-
ing 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
the 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.

This Guide presents accepted and standard project management principles and strate-
gies, but it has been adapted to and designed for the unique needs, limitations, chal-
lenges 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 jurisdictions procurement and
contract negotiations. This Guide is not legal counsel and should not be interpreted as a
legal service.

PAGE 4
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 agencys 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 projects 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 youve been assigned to manage this task nonetheless. Either way,
your role of project manager is pivotal to this effort. Youre 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.

PAGE 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
projects 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 Ws about the topic: What is it, Why do it, Who is involved and 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.

PAGE 6
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
Executive Sponsor Icon
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 Icon
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 Experts Icon
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
Project Manager Icon
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
Stop Sign Icon
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
Grant Requirements Icon
Be accountable to your grants. This icon will alert you when grant requirements may
come into play.

PAGE 7
Regional
Regional Icon
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
Tips Icon
If weve heard or know of shortcuts or have useful ideas on how to tackle a particular
issue, well use this icon to let you know.

Checklists
Checklists Icon
Checklists are always handy tools for making sure all the bases and steps are covered.
Well 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 youll be doing your best to
ensure IT success within your agency.

PAGE 8
Law Enforcement IT Projects:
A Roadmap to the Guide
Image of Roadmap Steps:
	1. Project is Initiated
	2. Establish a Decisionmaking Structure
		a. Recruit an Executive Sponsor
		b. Assign Key project members
	3. Create a project charter
		a. Articulate a vision, initial scope, and preliminary objectives
	4. Conduct a needs analysis
		a. Document Existing Technology
		b. Map and reengineer business processes
		c. Conduct user interviews and focus groups
		d. Identify system operational requirements
		e. Assess compatibility with existing and upgrade projects
		f. Prepare conceptual design
	5. Create a Project Plan
		a. Define scope, objectives, approach
		b. Determine milestones and timelines
		c. Conduct risk assessments
		d. Develop communications strategies
	6. Acquire the Technology
		a. Develop specifications and bid materials
		b. Evaluate and select a vendor
	7. Implement the Technology
		a. Create an implementation plan
		b. Form an implementation team
		c. Conduct system acceptance testing
		d. Provide training
	8. Manage change
		a. Conduct training
		b. Continue planning and budgeting
		c. Conduct project reviews and benchmarking
		d. Document project lessons learned
		e. Maintain/enhance system


Page 10
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! 

Page 11
Seven Facts You Should Know
BEFORE Reading this Guide

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
organizations
mission.
Websters New
World Dictionary of
Computer Terms,
Seventh Edition

Automated information systems are a critical component of effective policing. Immediate
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 inmates criminal
record, religious preference and gang affiliation. It means providing Chiefs and Sheriffs
with access to crime statistics at a moments 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 isnt 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:

Graph:
	52% of projects will cost 189% of original estimates
	Large organizations net only 42% of the original features and functions in the end product
	31% of IT projects are canceled before completion
	16% of large-scale projects are completed on time and within budget
Source: The CHAOS Report(1994), www.pm2go.com


PAGE 12
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 agencys specific
business processes.

 They are time-sensitive.

There are many issues that challenge successful IT implementation. Thats why there is
such a detailed process for doing it right. We cant 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 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 dont 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.

PAGE 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 state-
of-the-art. Its also, they promise, made for any law enforcement agency. So you buy it.
Case closed.

But buying a desk that perhaps isnt perfect wont 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 systems 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
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.

PAGE 14
Image - Systems Development Lifecycle
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, youll 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
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.

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

Executive Sponsor Icon
This means the Chief/Sheriff must:
1)Have a strategic business plan in place that articulates the organizations mission, goals
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.

Image:  Strategic Business Plan Drives Agency IT Vision

PAGE 16

"If an agencys 
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 
Charlotte-
Mecklenburg (NC) 
Police Department 

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
enhance those technologies as business goals and technology change. Agencies meet this
broad strategic IT vision through a series of individual projects that build the IT capabilities 
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 agencys goals. 

INFORMATION TECHNOLOGY AND ITS ROLE IN THE
METROPOLITAN POLICE DEPARTMENT,
WASHINGTON, DC (MPDC)
Information technologymakes 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 
needs and expectations. Thats a tall order. Thats where project management comes in.

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.

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

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 weve 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 projects 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. Its a Guide that the
Chief/Sheriff, Project Manager, end user or technologist can pick up the minute the
phrase is uttered lets 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!

Page 19
Part 1: Build the Foundation
Technological progress is like an axe in the 
hands of a pathological criminal. 
 Albert Einstein 

PAGE 20
Stop Sign Icon
Have you read the
Seven Facts section
yet? If not, it is important
that you read it before
you continue any further.


PAGE 21
CHAPTER 1
ESTABLISH A DECISIONMAKING
STRUCTURE


PAGE 23
Chapter 1:
Establish a Decisionmaking
Structure
A decisionmaking structure for your IT project that:

What
provides leadership and accountability,
defines the business of the agency,
analyzes technical environments, policies and solutions, and
effectively manages projects.

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

Who
investigators, dispatchers, records clerks, crime analysts, community policing experts,
etc.), a dedicated Project Manager and technical staff.

When
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 projects chain of
command, documenting the roles and responsibilities of the various people
responsible for project actions.

This chapter provides strategies and best practices for getting the right people
involved and developing a formal structure for governing a project from planning
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.

PAGE 24
Thus, planning for technology is not simply a technical issue to be resolved by the
agencys 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

Stop sign icon
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.

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 projects 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:

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

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

Other government and public safety agencies. Integration and information sharing
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.

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 o
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:
See page 27.
 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).

PAGE 26
Follow Structure #2 if:
See page 32.
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.


PAGE 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
which two additional groups report: a User Committee and a Technical Committee. Ad 
hoc working group may be convened for specific short-term tasks.

Image of flowchart

Sample Project Decisionmaking Structure #1

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

1.3 USER COMMITTEE 
Subject matter/business process experts
Patrol Officers, Dispatchers, Records Clerks
Identifies systems operational requirements

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.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.,
researching mobile
computing devices

1.5 AD HOC 
WORKING GROUP 
Focused on a particular
project, e.g.,
transferring data from
CAD to RMS


Page 28
1.1 The Steering Committee

"Its essential to 
have a unified 
department 
approach with 
all senior 
management 
around the 
table." 

 Timothy Bray 
Illinois State Police 

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 agencys budget, as well as
overall business objectives, such as community oriented policing.

Regional Icon
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
Chiefs/Sheriffs is not reccommended, unless they are given full decisionmaking authority for
their agency.


1.2 The Project Manager
Note:
A detailed discussion
of how to hire, assign
and/or train a Project
Manager
can be found in
Chapter 2.

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

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

Stop sign icon
The User Committee
should be focused on
defining the business,
not technical,
solutions for the
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 serving 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).

PAGE 30
Tips icon
Committees should
follow the rule of
12: the maximum number of individuals
who should participate
on a committee for
effective
decisionmaking.

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
Any citys Chief has decided to replace or enhance the departments 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 AND MANAGER Uses information captured in the new system for
management of statistics and staff allocation.

CITY GIS REPRESENTATIVE Explores the integration of CAD and RMS with the Geographic
Information System (GIS).

PAGE 31
Tips Icon
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.

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 Committees workflow and business needs. To analyze the agencys
existing technical environment. To research and propose solutions to the
agencys 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 agencys 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


PAGE 32
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 th
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 projects 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


PAGE 33
STEERING COMMITTEE 
Police Chief, Fire Chief, Sheriff and
Assistant City Manager

PROJECT MANAGEMENT
Deputy Chief, Reno PD, and the
Project Manager

Consultant

PROJECT MANAGER 

ASSISTANT 
PROJECT MANAGER 

CAD Project 
Platform Team Leader

CAD Team

Fire RMS 
Platform Team Leader

Fire RMS team

Police RMS 
Platform Team Leader

Police RMS Team

CMS 
Platform Team Leader

CMS Team

MIS 
Platform Team Leader

MIS Team

RENO/WASHOE COUNTY (NV)
DECISIONMAKING STRUCTURE

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
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
daily project activities. A
consulting firm has been hired to
work on this project, and reports
directly to the project manage-
ment team. The committee
structure is organized so that
there is a team for each major
each team is comprised of both
the user representatives and
technology support staff.


PAGE 34
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 attorneys 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).


PAGE 35
Step 5
Make the Most of Committees: Conduct
Effective Meetings
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.).

. Preparing and distributing an agenda for each
 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 meeting. 
For most projects handled within a
single agency, a simple majority vote is
generally acceptable.


Checklist Icon
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 item
4.Start on time 
5.Always keep minutes 
6.Keep everyone focused 
www.telstra.com/businessmeeting


PAGE 36
Tips Icon
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.


Regional Icon
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
should be prepared and distributed for every 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 so the rules are clearly
established at the outset of the project. Heres 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.


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


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


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


PAGE 38
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. Is there sufficient funding in the budget to allow outsourcing of
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 1015% of the projects 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 consultants 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 inhouse 
(e.g., an in-depth knowledge of the planning process or operational technology 
such as CAD/RMS/Mobile systems).

Additional staffing. The consultant often performs tasks that an agency knows how
to do, but just doesnt have time to do(e.g., organizing meetings, drafting documents, 
conducting interviews, etc.).

Partnership. The consultant often participates as a Project Team member, contributing 
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



PAGE 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 services.
 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.

Grant Requirements Icon
Remember: Consulting costs allowable under grants are usually
subject to rate caps. Be sure to check these limits prior to outsourcing.


PAGE 41
CHAPTER 2
HIRE, ASSIGN AND/OR TRAIN A
PROJECT MANAGER

PAGE 43
Chapter 2:
Hire, Assign and/or Train a
Project Manager

What
An individual accountable for all project-related activities and solely responsible for
the projects scope, quality and budget.

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

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

When
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 dont 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.


PAGE 44
SAMPLE PROJECT MANAGER JOB DESCRIPTION

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, manage-
rial 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 projects Execu-
tive 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 conform-
ance to specifications/standards and the
Project Plan, and with City/County procure-
ment 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 summa-
ries to project leadership, committees,
stakeholders and staff.

Ensures timely follow-up to all commitments.

PAGE 45
Compiles all project files.

Researches and applies appropriate technolo-
gies 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 perfor-
mance 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 agencys 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.

PAGE 46
Stop Sign Icon
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 full-
time, 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 doesnt 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 contractors 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.

Project Managers Responsibilities

Project Manager Icon
See: The rest of this Guide! 
Seriously, the Project Manager will be involved in all aspects of the agencys 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.


PAGE 47
Project Manager Tool Kit
Now that youve 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 his 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

Executive Sponsor Icon
As youve 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 projects 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 projects challenges, opportunities and difficulties:

 Supply the Project Manager with training, if needed, and the appropriate tools
(mentioned above).

Empower the Project Manager  i.e., give the Project Manager authority to call
meetings, assign tasks to team members and enforce completion of those assign- 
ments.

PAGE 48
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 (see Chapter 12). Risk
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.


Roles Played by
Project Manager
*Task Manager
Coach
Cheerleader
Social Worker
Advocate
Defender
Taken from A
Practitioners Guide to
Managing Projects in
the Information Age.


And, perhaps most importantly:
 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.


"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 

.......................................... 
Daunted by the task of finding a Project Manager who has law enforcement, IT and
project management experience?

Its true, finding a single individual with all of these skills is a challenge. If you cant
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.


PAGE 49
CHAPTER 3
DEVELOP A PROJECT CHARTER


PAGE 51
Chapter 3:
Develop a Project Charter

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

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

Who
The Project Manager and Steering Committee, with the advice and input of the User
and Technical Committees.

When
Shortly after the decisionmaking structure is formed and prior to developing the full
Project Plan.

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

The Charter defines the scope and objectives of the project and is a reference point
by which all activities can be measured to see if they meet the vision for the project,
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 implemen-
tation. In short, the Charter defines the rules of engagement for a project.

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 under-
standing and a reference document to constantly assess the projects 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.


PAGE 52
A 12-Step Program for Developing the
Charter

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

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 groups energies and serve as a guide to action.
It should be consistent with the organizations 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.

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 organizations
work, then the vision
is the artists
rendering of the
achievement of that
plan.
 From Strategic Planning FAQs at
www.allianceonline.
org/faqs.html


How do you create a vision statement? The Executive Sponsor and Steering Committee
should hold a meeting just to develop the vision statement. Brainstorm, encouraging
everyones 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?

PAGE 53
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 Manager Icon
Project Managers: You should facilitate this discussion and help the group explore its
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.


PAGE 54
Internal and External Issues to Scan 

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

PAGE 55
Policies and Procedures
Research the published policies and procedures that pertain to your agency. Dont forget to
also consider business practices that may not be formally prescribed, but that are done out
of historic practice (e.g., weve always done it that way).

Politics
And were not just talking Election Day politics here. We know each agency has its own
internal politics. Dont 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 agencys 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?

PAGE 56
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
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) and weaknesses (W) of the agency.
An external scan that identifies external opportunities (O) and threats (T) to the 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
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 projects 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 decision making bodies.

So, how do you build the business case? As a Project Manager, think about how you
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 projects 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?


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


Executive Sponsor Icon
Executive Sponsors: You will most likely have to appear before a funding agency or
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?

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

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

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

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.

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


PAGE 58
Tips Icon
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.

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. Defining scope also identifies which activities are in the
project and which activities are excluded.

Scope addresses:
What users want (functions).
How well the user requirements are met (quality of ).
When and how it must be developed (constraints).
Why (the value in the project).

Scope: The first
phase of the project
where the who, what,
where, why, when and
how are determined at
a very high level.
IT Professionals
Guide to Project
Management


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

Image of Scope-Time-Cost Triangle

We will introduce the concept of the scope-time-
cost triangle here. As you are developing scope,
both initially for the Charter and later in more
detail for the Project Plan, keep in mind that

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

Stop Sign Icon
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.

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

 
PAGE 60
Tips Icon
It is important to have
buy-in up front from
the Chief to the users,
and you do this with
an aggressive
marketing plan.

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


PAGE 61
PART I ASSIGNMENTS

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 Foundation Tasks
1.Make sure your agency has a strategic business plan in 
  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 Foundation Tasks
1.Assign staff to User and Technical Committees 
  (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 Foundation Tasks
1.Develop meeting schedule and agendas
 (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)


PAGE 62
Part 1 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 Foundation Tasks
1.Assist in developing the Project Charter (Chapter 3)
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 Foundation Tasks
1.Form Committee (Chapter 1, page 31)
2.Include IT staff from parent organization, if appropriate
(Chapter 1, page 31)
3.Assist in developing the Project Charter (Chapter 3)




PAGE 63
Part II:
Conduct a Needs Analysis

If you dont know where you want to get 
toit doesnt matter which way you go! 
 Lewis Carroll, Through the Looking Glass 


PAGE 65
CHAPTER 4
ASSESS CURRENT BUSINESS PROCESSES


PAGE 67
Chapter 4:
Assess Current Business Processes

What
An objective assessment of how your agency does business today with a focus on
improving efficiency and effectiveness.

Why
Technology acquisition must be driven by business objectives. Documenting current
business processes and identifying how they can be improved establishes the starting
point of a conceptual system design.

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

When
After the projects 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 projects scope in very broad terms. In this chapter, well 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 organizations 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.


PAGE 68
Define the Organizations 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? Its 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. Heres 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
prisoners property bag.

Project Manager Icon
Project Managers: You probably have a solid understanding of the major business processes
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, youll 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.


PAGE 69
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:

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!

FILING A REPORT
PROCESS
Image of notebook
The highest level for process mapping purposes
Example: The records bureau processes reports from patrol

SUBPROCESS
Image of Legal Pad
Image of Notebook
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

ACTIVITY
Image of Computer Screen
Image of Legal Pad
Image of Notebook
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

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


PAGE 70
Tips Icon
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
Image of jail cell bars
The highest level for process mapping purposes
Example: Patrol books suspects into jail

SUBPROCESS
Image of Computer Keyboard
Image of Jail Cell Bars
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

ACTIVITY
Image of Police Officer taking notes
Image of Computer Keyboard
Image of Jail Cell Bars
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

With the basics defined, its 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 organizations business processes.


PAGE 71
Project Managers Icon
Project Managers: Business process mapping is often outsourced by police agencies because
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:

Tips Icon
We suggest convening
the meeting in a room
with ample free table
and wall space. Also,
these meeting
usually require a full
day, so plan ahead!


DISPATCH
Image of computer bank/phone center

SERGEANT
Image of Sergeant's badge

WATCH 3 OFFICER
Image of Patrol Car

WATCH 3 OFFICER
Image of Patrol Car

WATCH 3 OFFICER
Image of Patrol Car


PAGE 72
Project Managers Icon
Project Managers: During this step, you will serve as the meeting facilitator. As such, you
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 days 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 
Baseline report. Most business process mapping professionals use a software application
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 organizations 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 Sponsor Icon
Executive Sponsors: Be ready for resistance to business process mapping. It is strikingly
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 organizations
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.


PAGE 73
 Identification of existing configuration for CAD/RMS/Mobile applications.

 Relationship between applications, including CAD, RMS, Jail, Court, Substations,
Fire, GIS, etc.

Technical Experts Icon
Technical Experts: In the event your project will rely upon mobile data devices, you will
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
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 Technology Baseline reports, its time to
overlap the two reports, seeking to identify how the existing technology is used to
accomplish the agencys 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.).


PAGE 74
Project Managers Icon
Project Managers: Facilitate a meeting of the User and Technical Committees. During the
meeting, ask participants to identify how the technology described in the Technology 
Baseline report is used in each process defined in the Business Process Baseline report. For 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
defined use of technology. The resulting document will be used throughout the balance of
Part II as a snapshot of the organizations current environment.

Find Room for Improvement
The Business Process Baseline report now includes not only the current business
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 new functionality) 
likely to be achieved as a consequence of changing business processes.


PAGE 75
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).



PAGE 77
CHAPTER 5
DETERMINE STAKEHOLDER AND USER
NEEDS


PAGE 79
Chapter 5:
Determine Stakeholder and
User Needs

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

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

Who
The Project Manager will be primarily responsible for meeting with virtually all
project stakeholders.

When
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 informa-
tion, and to encourage them to look outside the box at the potential enhance-
ments 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 interview dozens or hundreds of
people!

This chapter is designed to capitalize on the Project Managers communication
skills by relaying best practices for conducting interviews 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 Icon
Project Managers: We assume that you will be responsible for conducting the interviews and
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.

PAGE 80 
Note: How to
develop the more
detailed functional
requirements and
specifications
necessary for
procurement
documents is
addressed in
Part IV, Acquire
the Technology.

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 interviews 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:

Chart entitled Interview Technique

When interviewing Administrators (including Executive Sponsors and Steering Committees), 
use Individual Interviews.  Administrators, by their rank, can inhibit the communication 
process and should be interviewed individually rather than participate in Focus Groups.

When interviewing User and Technical Committees, use Focus Groups. When five or more 
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

When interviewing External Stakeholders (e.g. County officials, funding bodies, other
justice agency representatives) use Individual Interviews.  By their nature, stakeholders 
(both internal and external) possess unique knowledge and are not generally interviewed 
as a group.

When interviewing Subject Matter Experts (i.e. individuals needed for a specific component 
of a project, such as an expert on the message switch) use Individual Interviews.  These
participants possess unique and specific knowledge that would not be well suited to a Focus 
Group format.


PAGE 81 
User participation is one of the critical success factors in any law enforcement technology
initiative. The more users who contribute to the systems design, the more successful the
project will be!

Project Managers Icon
Project Managers: User involvement in law enforcement initiatives is often stymied by
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 wont 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 Icon
Executive Sponsors: Project Managers are often frustrated with their inability to access key
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-of-
command 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 agencys 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 ata time that is convenient for the interview subject.

While interviews are fairly straightforward, advance planning will vastly improve the
quality of information you collect. Therefore, we recommend that the interviewer
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
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: Always let participants know what is expected of
them. Few things are more uncomfortable than interviewing someone who hasnt
prepared for an interview. We suggest providing the participant with some advice
on how to prepare for the interview, such as:

PAGE 82
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: Interview participants may prepare for meetings by
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 interview, 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 Groups focus. We assume
that the Project Manager will moderate the Focus Groups for the technology initiative.


PAGE 83

Think SWOT!
STRENGTHS
WEAKNESSES
OPPORTUNITIES
THREATS

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
SWOT format is an effective tool for identifying the Strengths and Weaknesses of
existing systems, as well as for defining the Opportunities and Threats presented by the
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
(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 Icon
Project Managers: Remember that facilitating Focus Groups requires advance research and
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 of the current technology?

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


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

Tips Icon
Regardless of the
Focus Group
approach you choose,
both require that the
moderator take
copious notes. If you
have the resources
available, use a note-
taker 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.

 What are the Weaknesses of the current technology?

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 for improvement exist?
The moderator should point out to the attendees the relevant portions of the
Business Process Baseline report that identify current business processes and
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 Icon
Project Managers: Remember that attendees may not know what
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 will emerge from this process?
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:


PAGE 85
Image of Bulletin Board

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 
Cant get statistics from CAD 
Cant send calls to MDTs 
Cant 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 

PAGE 86
Tips Icon
If you dont 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.

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


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

PAGE 89
CHAPTER 6
DEVELOP GENERAL SYSTEM
REQUIREMENTS

PAGE 91
Chapter 6:
Develop General System
Requirements

What
Translating research, interviews and Focus Group meetings into general hardware,
software and interface requirements for the new system(s).

Why
The requirements will become the core material of the conceptual design and
procurement documents.

Who
The Project Manager uses the Technical and User Committees to draft the various
system requirements.

When
Documenting requirements can only occur after you have defined the projects scope
and have interviewed the projects 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, well focus on the principles behind coordinating the Project
Teams 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 projects 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


PAGE 92 
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:

Image of Bulletin Board
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 
Cant get statistics from CAD 
Alarm billing maintained manually 
Cant send calls to MDTs 
Cant 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 


PROJECT TEAM 
TRANSLATES OPPORTUNITIES 
INTO REQUIREMENTS: 
Hardware: Modern Processor, 
Redundancy Needed 

Software: Statistics, 
Alarm Billing 
Interfaces:
CAD- Mobile, CAD-RMS, 
CAD-NCIC 


PAGE 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 Icon
Technical Experts: In order to identify the size of various hardware components (i.e., disk
size, processor speed, etc.) that may be required for the new initiative, the Technical
Committee will need to review the organizations 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

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

Stop Sign Icon
A critical success factor is ensuring that the new technology is designed in
concert with the parent organizations 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.

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.

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.

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

Operational Experts Icon
Users: The User Committee is responsible for developing the general software requirements,
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.

PAGE 95

Chart explaining functionality

Computer Aided Dispatch (CAD)
Module Incident Entry
Functionality that relates toentering calls for service into CAD
Module Dispatching Unit/Incident
Functionality that relates toassignment of personnel to incident
Module Status Monitoring Dispatch
Functionality that relates tohow CAD monitors units, calls and responders
Module Support Files
Functionality that relates tosupplying CAD with required data, such as a geofile or AVL data
Module Messaging
Functionality that relates tohow CAD communicates with other users (within CAD and RMS)
Module Supervisory Functions
Functionality that relates tothe specific needs of supervisors
Module Training Functions
Functionality that relates to...using the CAD for training new dispatchers
Module CAD Inquiry Tools
Functionality that relates tothe tools that are made available for CAD to access (premise history, etc.)
Module Statistics
Functionality that relates toCADs ability to supply real-time statistic information.
Module Alarm Billing
Functionality that relates topreparing alarm bills, warnings, etc.
Module Permits
Functionality that relates toallowing CAD to issue and store various permits (alarm, party, etc.)
Module: Mapping
Functionality that relates toscreen mapping tools

Records Management System (RMS)
Module: Master Name Index
Functionality that relates tohow RMS captures and maintains files related to people
Module: Master Vehicle Index
Functionality that relates tohow RMS captures and maintains files related to vehicles
Module: Master Location Index
Functionality that relates tohow RMS captures and maintains files related to addresses/locations
Module: Incident Reporting
Functionality that relates tohow the records bureau processes reports
Module: Field Reporting
Functionality that relates toenabling officers to write/submit reports from remote locations
Module: Case Management
Functionality that relates tocase receipt, distribution and document management
Module: Crime Analysis
Functionality that relates toanalyzing crime statistics
Module: Property/Evidence
Functionality that relates tohow articles are entered and maintained within the RMS
Module: Arrest/Booking
Functionality that relates toinitial booking of prisoners
Module: Personnel
Functionality that relates tomaintaining human resource information
Module: Training
Functionality that relates toscheduling, assigning, managing required training and certifications
Module: Inventory
Functionality that relates totracking police equipment
Module: Administration
Functionality that relates tointernal affairs, administrative reporting
Module: Pawn
Functionality that relates toentry and maintenance of pawn ticket information
Module: Traffic
Functionality that relates tocollision reporting, citation issuance (parking and moving)
Module: Activity Log
Functionality that relates totracking officer activity for statistical purposes
Module: Permits
Functionality that relates toissuing and maintaining various agency-issued permits (weapons, etc.)
Module: Licensing
Functionality that relates toissuing and maintaining various agency-issued licenses (bike, alcohol, etc.)
Module: Animal Control
Functionality that relates tospecific animal-related calls for service and subsequent reporting
Module: Report Writing
Functionality that relates toentering report information directly into RMS

Mobile Data
Module: Messaging
Functionality that relates tothe devices ability to communicate with CAD, RMS and external entities
Module: Display
Functionality that relates tothe screen layout
Module: Forms
Functionality that relates tothe number and type of inquiry forms that may be used (NCIC, etc.)
Module: Call Receipt
Functionality that relates tohow the device receives a dispatched call for service
Module: Commands
Functionality that relates towhat type of CAD and RMS commands are available on the device
Module: Touch Screen
Functionality that relates tohow a touch-screen device is controlled

Automated Field reporting (AFR)
Module: CAD Data Capture
Functionality that relates towhich data elements are imported from CAD, RMS and external entities
Module: Error Correction
Functionality that relates tohow the AFR will assist officers with report completion
Module: Report Writing
Functionality that relates tocreating, filing and correcting reports, narratives and forms
Module: Case Management
Functionality that relates toelectronic case filing and distribution
Module: Approvals
Functionality that relates tohow reports are corrected, approved and/or rejected by supervision

Jail Management System (JMS)
Module: Detention Processing
Functionality that relates tothe initial receipt of a prisoner
Module: Identification
Functionality that relates tohow prisoners are conclusively identified
Module: Classification
Functionality that relates todetailing all prisoner profile data
Module: Housing
Functionality that relates toassignment of quarters/cell
Module: Transportation
Functionality that relates toprisoner transports to/from court and other facilities
Module: Food Service
Functionality that relates toordering, preparing, auditing food preparation/service
Module: Accounting
Functionality that relates tofinancial software for managing inmate spending and commissary
Module: Medical
Functionality that relates tomonitoring prisoner health-related matters
Module: Commissary
Functionality that relates tostore ordering, purchases
Module: Mental Health.
Functionality that relates topsychological units within the jail


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

Technical Experts Icon

Defining the general interfaces and integration requirements is often conducted by both
the User and Technical Committees. While most user requests will be recorded, be sure
to consider the following interfaces as well:

Operational Experts Icon
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. 

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


PAGE 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
projects scope, general requirements and connectivity with internal and external
resources.

Each project will necessitate various inclusions within the conceptual design, as determined 
by the projects scope. For example, an RMS conceptual design prepared for a
Sheriffs 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.


PAGE 98

Image of Flow Chart
Sample RMS Conceptual Design

CAD
Automatically populates report fields
Automated Report Writing
Arrest Reports1
Traffic Reports2
Signature Forms3
Property/Evidence4
Crime Lab5
Optical Imaging6
Field Interview7


Continuous exchange of data

Supervisor Approval of Submitted report

Records Management System

Investigative follow-up

Narcotics10
Crime Analysis11
Investigative Follow-up12
Investigations Case Management13

Interfaces14
CAD
Jail
State
DMV
GIS Base maps
LiveScan
AFIS

Websites8
Record Modules9
Administration
Ad Hoc Search Capability15
Personnel and Training16
Pawns17
Internal Affairs


PAGE 99

1Interface with AFIS and LiveScan to prevent redundant entry of booking information.

2Includes all standard State traffic forms and interfaces 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 Attorneys 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.

PAGE 101
CHAPTER 7
MAKE THE DECISION  BUILD OR BUY

PAGE 103
Chapter 7:
Make the Decision  Build or Buy

What
A critical decisionmaking process involving whether to purchase the required
software from a vendor or build a custom solution from scratch.

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

Who
The Executive Sponsor and Steering Committee, on the advice of the Project Manager
and User and Technical Committees.

When
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 projects 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
safety hardware and/or software.

2.Use internal or external technologists to build the technology based
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 ingenu-
ity, 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.

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.

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



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

Stop Sign Icon
Note: the build or buy decision may be easy for many agencies. Recognizing that the
majority of police agencies in America probably dont have their own dedicated software
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 projects
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.

PAGE 105
Image of Scales

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

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: Because off-the-shelf packages are designed for Anywhere PD, they rarely
meet an agencys 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 projects 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
vendors price changed from proposal to live date.)


PAGE 106
Indirect Costs: While agencies can be lured to build solutions because of the benefits
that can accrue from customization, the recurring costs can be staggering. Simply
compare a vendors 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 youll 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 agencys Project Team and
Steering Committee must determine the relative importance of cost as it relates to the
projects objectives.

Managing Technology Resources

Stop Sign Icon
Remember that the
more a vendors
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
vendors standard
upgrade will no longer
work with your
customized product.

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

PAGE 107
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
projects 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, its 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.

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


PAGE 108
........................................... 
PART II ASSIGNMENTS

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 Tasks
1.Meet with union representatives and other leaders 
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 Tasks
1.Review Business Process Baseline report (Chapter 4)
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)


PAGE 109
........................................... 
PART II ASSIGNMENTS, CONTINUED

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 Tasks
1.Review User and Technical Committee membership to
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)


PAGE 110
........................................... 
PART II ASSIGNMENTS, CONTINUED

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 Tasks
1.Define and categorize business processes
(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 Tasks
1.Develop a written description of existing agency
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)

PAGE 111
Part III
Create a Project Plan
If you fail to plan, plan to fail. 
 Anonymous 


PAGE 113
CHAPTER 8
PROJECT PLANNING:
WHAT IS IT AND WHY ARE WE DOING IT?

PAGE 115
Chapter 8:
Project Planning: What is it
and Why are We Doing it?

What
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, the procedures resources needed to produce them, and the quality 
measures they must meet to be accepted. This document can grow and change during
the projects lifecycle.

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

Who
The Project Manager and the User and Technical Committees are involved in discus-
sions, 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.

When
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 docu-
menting issues that have been dealt with and decided upon, it prevents covering
the same ground, which can often bog a project down.


PAGE 116
Five Important Facts to Know about Project Plans

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.cio-dpi.gc.ca)

1.Project Plans are dynamic. The Plan will evolve and change as the Project Team,
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. Given the pace at which technology and
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
procedures to noted by the Alliance for Nonprofit Management (www.allianceonline.org), The
ensure that fresh insight arrived at today might very well alter the decision made yesterday.

3. Project planning is not necessarily a linear process. Some planning activities are
related to and dependent upon other decisions. For instance, developing project
objectives is dependent upon finalizing the scope statement, while detailing the deliverables can only 
occur after both scope and objectives are completed. However, project scope, scope,
 objectives and deliverables may be revisited and modified pending the results
deliverables, of a thorough risk assessment and/or the resource requirements analysis.

4. To be effective, Project Plans must be used, reviewed, maintained and updated 
constantly. This sounds obvious, but too often organizations go through the planning
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
organizations needs versus the vendors proposals.

5. Planning should not go on forever. Do your employees sneer or groan when plan-
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.


PAGE 117
Executive Sponsors: Prepare Your Organization for Change

Executive Sponsor Icon
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 organizations
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 departments operations, not to eliminate jobs.

Stop Sign Icon
You must establish formal procedures for managing change throughout the life of your
project. (Dont worry, well 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, well address change management procedures.


PAGE 118
The Project Plans 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 
II........Scope, Project Objectives and Scope Management Plan 
III.......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.

Project planning is
 Disciplined
 Research-based
 Continuous
 Dynamic
 Inclusive


PAGE 119
CHAPTER 9
CONDUCT SCOPE PLANNING


PAGE 121
Chapter 9:
Conduct Scope Planning

What
A process to precisely define and document specific activities and deliverables for a
particular project.

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

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

When
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 stake-
holder 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 that provides scope
definition with:
a. Supporting detail
b. Work breakdown structure;

2.Project objectives and a
3.Scope Management Plan.

Each of these elements is essential
to establishing and justifying a
clear scope definition, and creates
a process to manage potential
scope changes.

Image of Scope Planning Flowchart
Scope Planning
Scope Statement
-Supporting Detail
-Scope Definition
-Work Breakdown Structure
Project Objectives
Scope Management Plan


Page 122
1. The Scope Statement:
Whats In, Whats 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, management 
statistics).
 Types of deliverables that are in scope and out of scope (e.g., CAD, but not
automated vehicle location (AVL)).
 Types of data that are in scope and out of scope.
 Data sources or databases that are in and out of scope.
 Which units will be affected and/or expected to use the system (dispatch, patrol,
crime analysis, etc.).
 What is specifically out of scope.


PAGE 123
Tips Icon
For once its safe to
make an assumption!
In fact, its 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.

a. Supporting Detail
Much of what was prepared for the business case in the Project Charter (Chapter 3,
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 should also be catalogued in the scope
statements supporting detail. The assumptions and constraints should relate back to the
agencys business objectives and overall mission and goals. For example, the agencys
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 organizations mission,
goals and overall objectives.

If there are specific grant requirements and/or directives for the project, they too should
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.

Image of Flowchart
A WBS FOR A MOBILE COMPUTING PROJECT
Mobile Computing Project
Project Management
Wireless Communications Structure
Software
Laptops
Mounting Devices
Training
Test and Evaluation


PAGE 124
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
quality, time, cost, performance reliability and/or 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.

Think SMART!
Objectives are:
SPECIFIC
MEASURABLE
ACCEPTABLE
REALISTIC
TIME-SENSITIVE

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 projects objectives for guidance and direction.



PAGE 125
3. Scope Management Plan: Prevent Scope Creep

Stop Sign Icon
Scope planning is
INCOMPLETE without
the Scope
Management Plan!

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 projects 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 Managers 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 Sponsor Icon
Executive Sponsors: You (or your designee) must approve scope changes. After all, scope
changes will definitely impact the projects quality, timeline or cost (remember the scope-
time-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


PAGE 126
According to Gary H.
Anthes in a
Computer world 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.

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

PAGE 127
CHAPTER 10
DEVELOP THE PROJECT TIMELINE

PAGE 129
Chapter 10:
Develop the Project Timeline

What
A mechanism to ensure the project is completed on time within the resources
available, and avoids delays and associated cost overruns.

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

Who
The Project Manager will set realistic schedules, as well as deliverable and milestone
deadlines.

When
Following scope planning.
Image of Scope-Time-Cost Triangle

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 weve 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 projects scope. In this chapter, well 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 will produce the various project deliverables,
determine their order and their dependence on one another, and how long
each activity will take. By analyzing the appropriate activities, order and dependence, you will be able


PAGE 130
to create an actual schedule and, finally, as we have reiterated in earlier chapters, a means
to control the schedule and any changes to it.

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 and deliverables that will be
captured in your project timeline. You will then have to logically sequence those activi-
ties. Thats easy to do when youre dealing with some of the initial planning and needs
assessment activities. It gets a little more complex when you get into systems implementation 
issues.

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.


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


PAGE 131
Tips Icon
Schedules should be
built from the bottom
up. Schedules built
by people other than
those who will be
doing the work wont
be accurate.
Obviously, appropriate
oversight and
management of this
task is necessary.

Executive Sponsors Icon
Executive Sponsors: It is tempting to want to impose a schedule on your
Project Team. DONT! 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.

 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
projects timeline up-to-date in order to track estimated versus actual timelines for use
in future projects.

 Assumptions and Constraints
Youll 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 wont be
complete until 2 months into the projected start date of your project. The County IT staff
availability will impact your deliverables schedule and youll want to plan accordingly.


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

Project Managers Icon
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.

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 should be comprised of these things:

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


PAGE 133
Tips Icon
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
projects activities and
their dependencies,
milestones and
timelines.

Image of Sample Timeline; Tasks are on the vertical axis and time on the horizontal axis.
Tasks:
1 Phase I: Project Orientation
2 Project Kick-Off, Interviews, Data Collection
3 Phase II: Develop the Project Plan
4 Deliver Conceptual Design
5 Phase III: Prepare Request for Proposal (RFP)
6 Prepare Document (Interviews, Review, Regular Meetings)
7 Vendors Respond to RFP 
8 Phase IV: Proposal Evaluation and Selection
9 Demonstrations, Site Visits, Identify Finalist Vendor
10 Phase V: Contract Negotiations
11 Negotiate Contract, Seek County Approval 
12 Phase VI: Implementation 
13 Project Initiation Session 
14 Requirements Validation/Finalize Hardware Requirements 
15 Develop Project Plan 
16 Hardware Off-site Installation
17 RMS Software Installation
18 RMS Subsystem Tailoring and Customization 
19 RMS Equipment On-site Installation
20 RMS Subsystem Interfaces
21 RMS Ancillary Systems Installation
22 Deliver RMS As-Built Specification Documents
23 RMS Functional Testing
24 Final RMS Equipment Installation
25 RMS Subsystem Performance Testing
26 RMS User Training
27 RMS Production Cutover/Final Certification
28 RMS Refresher Training
29 Program Evaluation
30 Conduct Redeployment Tracking Task Progress Milestone

Legends:
Estimated Project Schedule
Task Progress Milestone
Summary Rolled up Task Rolled up Milestone
Rolled up Progress Split External Tasks
Project Summary External Milestone Deadline


Page 134
Milestone Review. Taken together, milestones complete your entire project. Their
importance, and the quality with which they are met, are critical to the projects 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!

PAGE 135
CHAPTER 11
ESTIMATE COSTS AND DEVELOP A BUDGET

PAGE 137
Chapter 11:
Estimate Costs and Develop a Budget

What
Estimating initial and recurring costs in terms of people, materials, equipment and
services (both internal and external) to complete and maintain the entire project.

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

Who
Project Manager, your parent organizations finance representative and possibly your
grant writer (if your agency or jurisdiction has one).

When
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, well focus on the key elements for properly estimating initial and
recurring costs for a technology initiative.

Stop sign Icon
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.


PAGE 138
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 arent sure of what it will cost.
3.Our agency applied for and received a grant  so lets start spending because time
is running out!

The budget should
include estimates for:
Hardware
Software
Operating Costs
Staff Costs
Training
Skills Development
Maintenance
Consultants

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

Now, lets show you how ...

Preparing the projects 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
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.


PAGE 139
Gather Internal and External Cost Data

Q&A:
What are cost
recovery fees?
Some agencies must
transfer funds from
their budget to that of
their parent
organizations IT
management division
in order to pay for
technology support,
management, etc.

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 projects budget because they are considered in-
kind, or existing costs. Regardless of their pre-existing condition, you must identify
internal costs for two reasons:

1. Recurring Costs - Although we explore the calculation of recurring costs later in
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
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.

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.

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:

Tips Icon
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.


PAGE 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 Xs 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: These are the hourly costs that can be attributed to people doing something for
the project, including:
 project management,
 installation (if applicable, dont 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: 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.

Tips Icon
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.


PAGE 141
Identifying External Costs: Unfortunately, there are no hard and fast rules for identifying
the external costs of specific law enforcement technology components. For example, its
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 arent the first agency to enter into an IT initiative! So dont
reinvent the wheel. Consider the following sources for identifying your initial external
costs:

References (Networking): The least technical, and fastest, method for seeking basic
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 projects
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 Clerks 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.

Note:
See page 176
for more
information
on RFIs.

Request for Information (RFI): Prepare and issue a request for information, or RFI
document. Basically, its 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 projects 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 Teams objectivity.

Outsourcing: Not surprisingly, outsourcing the cost estimating portion of the project
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).

PAGE 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 
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:
Funding set aside for
unforeseen, and
generally
unbudgeted,
expenditure
requirements.

Contingency costs: Traditionally, contingencies are calculated at 10% of the hardware
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 agencys 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.

The Budget
Duration
Timeline:
Initial, one-time
costs occur between
project start date and
system acceptance.
Recurring costs
occur after system
implementation.

Bonding costs: Many governmental agencies require vendors to supply various forms
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
contract negotiations, but for budgetary purposes, assume that you will be responsible.)
Consulting costs: As a rule of thumb, full-service project consultants  those who
provide needs analysis, project planning, procurement assistance, contract negotiations
and implementation assistance  will receive an average of 15% of total project costs.

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

Image of Sample Initial Costs Budget
Sample Initial Costs
RMS/JMS-External
Item, Hardware; Description, Primary/Back-up Server, infrastructure, Desktops;
One-Time Low, $175,000.00; One-time High, $260,000.00
Item, Software; Description, RMS, JMS, 300 Concurrent, Minor Customization;
One-Time Low, $750,000.00; One-time High, $1,600,000.00
Item, Services; Description, Installation, Management. Interfaces, Modifications;
One-Time Low, $675,000.00; One-time High, $1,150,000.00
Item, Subtotal; One-Time Low, $1,600,000.00; One-Time High, $3,010,000.00

Item, Professional Services; Description, Consulting; 
One-Time Low, $350,000.00; One-time High, $400,000.00
Item, Contingency ; Description 10% of Hardware/Software; 
One-Time Low, $92,500,000.00; One-time High, $186,000.00
Item, Bonding; Description, Vendor Performance Bond; 
One-Time Low, $16,000,000.00; One-time High, $30,100,000.00
Item,Project Subtotal: One-time Low, $2,058,500.00; One-time High, $3,626,100.00

RMS/JMS-Internal
Item, Hardware; Description, None; One-Time Low,$0.00; One-time High $0.00
Item Software; Description, Existing City Oracle and Window License Fees; 
One-Time Low, $32,000.00; One-time High, $34,000,000.00
Item Services; Description Existing Project Manager, 1 Support Technician; 
One-Time Low, $140,000.00; One-time High, $150,000.00
Subtotal; One-Time Low, $172,000.00; One-Time High, $184,000.00
Item, Contingency; Description, 10% of Hardware/Software;
One-Time Low, 3,200.00; One-Time High, $3,400.00
Item, Project Subotal: One-Time Low,$175,200.00; One-Time High, $187,400.00

Project Totals:  One-Time Low, $2,233,700.00; One-Time High, $3,813,500.00


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 projects Risk Management Plan
(Chapter 12), as acceptable cost over-runs must be tracked using this document.


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

Very large
organizations may
need to track recurring
costs more frequently,
given the volume of
cashflow for internal
and external support
costs.

The recurring costs are based upon percentages shown below, and are generally determined 
by whether your agency will be purchasing a vendors 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

Image of Sample Recurring Costs Budget
Sample Recurring Costs
RMS/JMS-External
Item, Hardware; Description, Primary/Back-up Server, infrastructure, Desktops;
One-Time Low, $175,000.00; One-time High, $260,000.00
Recurring Low, $17,500.00; Recurring High, $26,000.00
Item, Software; Description, RMS, JMS, 300 Concurrent, Minor Customization;
One-Time Low, $750,000.00; One-time High, $1,600,000.00
Recurring Low, $93,750.00; Recurring High, $200,000.00
Item, Services; Description, Installation, Management. Interfaces, Modifications;
One-Time Low, $675,000.00; One-time High, $1,150,000.00
Recurring Low, $0.00; Recurring High, $0.00;
Item, Subtotal; One-Time Low, $0.00; One-Time High, $3,010,000.00;
Item Subtotal; Recurring Low, $111,250.00; Recurring High, $226,000.00.

Item, Professional Services; Description, Consulting; 
One-Time Low, $350,000.00; One-time High, $400,000.00
Recurring Low, $17,500.00; Recurring High, $20,000.00
Item, Contingency ; Description 10% of Hardware/Software; 
One-Time Low, $92,500,000.00; One-time High, $186,000.00
Recurring Low, $11,125.00; Recurring High, $22,600.00
Item, Bonding; Description, Vendor Performance Bond; 
One-Time Low, $16,000,000.00; One-time High, $30,100,000.00
Recurring Low, $0.00; Recurring High, $0.00;
Item, Project Subtotal: One-time Low, $2,058,500.00; One-time High, $3,626,100.00
Recurring Low, $139,875.00; Recurring High, $268,600.00

RMS/JMS-Internal
Item, Hardware; Description, None; One-Time Low,$0.00; One-time High $0.00;
Recurring Low; $0.00; Recurring High; $0.00;
Item Software; Description, Existing City Oracle and Window License Fees; 
One-Time Low, $32,000.00; One-time High, $34,000,000.00
Recurring Low; $34,000; Recurring High; $36,000
Item Services; Description Existing Project Manager, 1 Support Technician; 
One-Time Low, $140,000.00; One-time High, $150,000.00
Recurring Low, $150,000.00; Recurring High, $160,000.00
Item,Subtotal; One-Time Low, $172,000.00; One-Time High, $184,000.00
Item, Subtotal; Recurring Low, $184,000.00; Recurring High, $196,000.00  
Item, Contingency; Description, 10% of Hardware/Software;
One-Time Low, 3,200.00; One-Time High, $3,400.00
Recurring Low, $18,400.00; Recurring High, $19,600.00
Item, Project Subtotal: One-Time Low,$175,200.00; One-Time High, $187,400.00
Recurring Low, $202,400.00; Recurring High,$215,600.00

Project Totals: One-Time Low, $2,233,700.00; One-Time High, $3,813,500.00;
Recurring Low, $342,275.00, Recurring High, $484,200.00.


PAGE 145
Plan for Ongoing Updates to Project Budget
Once the one-time and recurring cost estimates have been developed, the only thing left
o 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.

You may also hear the
term Total Cost of
Ownership (TCO)
as you do research
and prepare you
budget. Like recurring
cost calculations, TCO
refers to the total costs
associated with
ownership, usage and
maintenance of the
system over time.

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

The extent to which cost overages are allowable will be determined by the Steering
Committees Risk Management Plan (Chapter 12) and available funding.


Final Advice
Before you embark upon preparing your project budget, consider the following tips:
Grant Requirements Icon

Supplanting: Okay, we said it  the S word. Supplanting occurs when agencies budget 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
should be a representative from your parent organizations 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.

PAGE 147
CHAPTER 12
CREATE A RISK MANAGEMENT PLAN

PAGE 149
Chapter 12:
Create a Risk Management Plan
What
Risk management is a planning process that prepares the agency for dealing with
potentially harmful events that could happen in a technology initiative.
Why
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 agencys response is planned, measured and
controlled.
Who
The Executive Sponsor, Project Manager and Steering, User and Technical Commit-
tees.
When
Risk management is conducted continuously throughout most projects, however,
formal risk management planning can only start once the scope of the project has
been identified. This is because it is difficult to identify risks until your project scope is
refined.

Executive Sponsors Icon
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 teams
insurance policy.

Most public employees correlate risk management with insurance, or perhaps the
City or Countys Risk Manager. While they both manage exposure, thats 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 initiatives prearrival contingency planning
Risk management is an essential component that project participants often sidestep
because it requires forward thinking about events that may be inconceivable at the
projects onset. Consequently, the vast majority of law enforcement technology initiatives
never take into account how the agency will handle events that can threaten the projects
quality, time or budget.

Based on our contact with hundreds of law enforcement agencies, weve learned that
most project managers simply dont know how to pull a Risk Management Plan together.
So, well start with the basics: How to create a Risk Management Plan.


PAGE 150
How to Create a Risk Management Plan

Identify the Risks
The initial step in preparing a Risk Management Plan is to convene the projects 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 reports 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 isnt always possible, but it is usually predictable and
manageable.

Products that involve
proven technology
will, all other things
being equal, involve
less risk than products
that require innovation
and invention.
 PMBOK
Step 1

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!

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 cant deliver the 
software on time 
The software we require uses a platform 
other than MS Windows NT 

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


PAGE 151
Remote: This risk will probably not occur.
Possible: This risk might occur.
Likely: This risk will probably occur.
2. Area of Impact: Next, the Project Team should determine which of the three critical
project areas (time, quality and/or budget) will be impacted by the risk. Some risks
may impact one or all of these areas.

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


3.Severity: The team must consider the severity of the consequences of a particular
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 Teams 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
project time, quality or budget.
Medium: The risk may be manageable through planning and action, although
the event will probably have a negative impact on the projects time, quality or
budget.
High: The risk will seriously impact project time, quality or budget. Planning or
action may not be capable of saving the initiative.

Using our examples gained during the risk identification process, weve categorized them
as illustrated in the graph on page 152:


PAGE 152
RISK: The City/County decides not to fund our project 
LIKELIHOOD: Remote
AREA OF IMPACT: Time, Quality, Budget 
SEVERITY: High

RISK: Our vendor goes out of business during implementation 
LIKELIHOOD: Possible
AREA OF IMPACT: Time, Quality, Budget 
SEVERITY: High

RISK: The vendor cant deliver the software on time 
LIKELIHOOD: Likely 
AREA OF IMPACT: Time
SEVERITY: Medium

RISK: Our Project Manager quits 
LIKELIHOOD: Likely
AREA OF IMPACT: Quality
SEVERITY: Low to Medium

RISK: The software we require uses a platform other than MS Windows NT 
LIKELIHOOD: Possible
AREA OF IMPACT:  Time, Budget
SEVERITY: 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
time is likely to be lost?
How much of the projects quality
quality would be sacrificed?
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:

PAGE 153
RISK: The City/County decides not to fund our project
LIKELIHOOD: Remote
AREA OF IMPACT: Time, Quality, Budget 
QUANTIFICATION: 2-5 Years, All Aspects, Total Budget 
SEVERITY: High
TOLERANCE: Avoid

RISK: Our vendor goes out of business during implementation 
LIKELIHOOD: Possible
AREA OF IMPACT: Time, Quality, Budget 
QUANTIFICATION: 2-3 Months, 20-30% Loss, 10% Cost Overrun 
SEVERITY: High
TOLERANCE: Avoid

RISK: The vendor cant deliver the software on time 
LIKELIHOOD: Likely 
AREA OF IMPACT: Time
QUANTIFICATION: 2-6 Months
SEVERITY: Medium
TOLERANCE: Mitigate

RISK: Our Project Manager quits 
LIKELIHOOD: Likely
AREA OF IMPACT: Quality
QUANTIFICATION: All Aspects
SEVERITY: Low to Medium
TOLERANCE: Mitigate

RISK: The software we require uses a platform other than MS Windows NT 
LIKELIHOOD: Possible
AREA OF IMPACT:  Time, Budget
QUANTIFICATION: 6 Months (Per IT), $400,000
SEVERITY: Low to Medium
TOLERANCE:  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

PAGE 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
impact the projects 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
risks that can be compensated or resolved through the development and execution of a
response plan.

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.

Accept: The Project Team will likely find some risks to be acceptable, not requiring the
development of a response plan. Generally, acceptable risks are either strategic in nature
or have minimal impact on the projects 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
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.

Holdbacks: A
contract provision that
allows the Sheriffs
office to keep a
percentage of a
vendors 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.

PAGE 155
Risk 
management 
helped make us 
successful and 
meet our 
deadlines." 
 Tom Hennig 
San Joaquin County 
(CA) Sheriffs 
Department 
 

For an impact on project quality: Attempt to verify the vendors full range of capabilities
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: In general, projects will cost more than original
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.
For an impact on project budget

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 projects 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 projects
management demonstrates control of the projects time, quality and budget.

PAGE 157
CHAPTER 13
PREPARE A COMPREHENSIVE
COMMUNICATIONS PLAN

PAGE 159
Chapter 13:
Prepare a Comprehensive
Communications Plan

What
Strategies for communicating project status and activities to key stakeholders, and
methods for developing historical project records and archives.
Why
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.
Who
Project Manager.
When
Begins at any time during the Build the Foundation or Project Planning phases and
continues through the life of the project.

Well talk about communications in this chapter on two tracks: First, disseminat-
ing information to groups of individuals through status reports, written documen-
tation, 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.

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

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


PAGE 160
Second, for each of these groups, you must determine the type of information they need,
the level of detail they need and how often they need it. For example, the Project Team
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 department wide 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.

Regional Icon

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 is the best method for communicating among the agencies.
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.

PAGE 161
Image of report details
Group: Steering Committe
Info Needed (Type): Project Status-Major accomplishments, problems or issues that need resolution
Detail: High-level
Frequency: Monthly or during regularly scheduled project-related meetings
Communication Method: Written status report and oral report by the Project Manager during the meeting

Group: Project Team Members
Info Needed (Type): Detailed information about project schedule, activities, deadlines, plans, issues, risks and problems
Detail: Very specific
Frequency: At least weekly
Communication Method: Variety-written memos, e-mail, oral reports during meeting, both scheduled and ad hoc 
(if reports are oral, all discussions must be captured in minutes)

Group: Users
Info Needed (Type): General updates about project activities, achievements and any variations in schedule
Detail: General
Frequency: Monthly
Communication Method: Monthly newsletter or Web site (big events, activities, achievements may warrant 
a special email alert)

Group: Public
Info Needed (Type): General update about project activities, achievements and status
Detail: General
Frequency: Monthly
Communication Method: Web site

Group: External Agencies
Info Needed (Type): General update about project activities, achievements and status
Detail: General
Frequency: Monthly
Communication Method: Web site or Intranet

Group: Funding Bodies
Info Needed (Type): Project activities, accomplishments, deadlines, funds expended to date and related budget issues
Detail: Detailed with regard to funding
Frequency: When reports are due or requested
Communication Method:  Formal, written documentation


PAGE 162
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
Its 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 theyve
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!

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. Thats
why all key players
must commit to
developing and
maintaining accurate
communication plans.

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. Any documentation regarding the project, including correspondence, 
reports, memos, grant applications and awards.
2.Performance Reports. Also known as status or project reports, these documents
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. As weve discussed in previous chapters, all changes (to scope,
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
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
in Part V, Chapter 17) and the signed acceptance itself.
6. Lessons Learned. This is an extremely useful document that will assist you in
future technology projects. Once your project is complete, take the time to
document things that worked, things that didnt work and the lessons you learned
from beginning to end. Dont think you will remember for the next time. Write it 

PAGE 163
down! And remember, someone else may need to refer to this document for a new
project they are planning.
down!
7. Project Archives. At some point, all project records will need to be archived.
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 isnt possible, consider the
use of a Microsoft SharePoint Web service, which provides a preformatted project
management Web environment.

Image of Kent (WA) Police Department Police Systems Replacement Project
Web Site Screenshot #1

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

 
PAGE 164
 Image of Marin County (CA) Integrated Law Enforcement Information System Project
Web Site Screenshot #2
 Image of Kent (WA) Police Department Police Systems Replacement Project
Web Site Screenshot #3

PAGE 165
 
PART III ASSIGNMENTS
EXECUTIVE SPONSOR
Role
1.Ultimate decisionmaker
2.Provide oversight and guidance

Project Planning Tasks
1.Commit to structured project planning; endorse and
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 Tasks
1.Endorse and sign Project Plan (Chapter 8)
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)

PAGE 166
PART III ASSIGNMENTS, CONTINUED
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 Tasks
1.Lead User and Technical Committees in detailed project
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)
 
PAGE 167
PART III ASSIGNMENTS, CONTINUED
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 Tasks
1.Assist in detailing project scope (Chapter 9, page 122)
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 Tasks
1.Assist in detailing project scope (Chapter 9, page 122)
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)

PAGE 168

Whats Next?
Procure the Technology....................................................................Chapter 14
Contract With a Vendor...................................................................Chapter 15

PAGE 169
Part IV:
Acquire the Technology

Obstacles are those frightful things you 
see when you take your eyes off the goal. 
 Henry Ford 


PAGE 170

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

Grant Requirements Icon
The full text of these regulations can be accessed online at
http://www.access.gpo.gov/nara/cfr/cfr-
retrieve.html#page1. For more information on other areas
of compliance, see Chapter 19, Grant Management and
Compliance.


PAGE 171
CHAPTER 14
THE ART OF PROCUREMENT

PAGE 173

Chapter 14:
The Art of Procurement

What: A structured method for determining the required hardware, software and services
needed to fulfill the project goals and objectives.

Why: In addition to meeting government mandates for purchasing, a well-planned procurement 
will (a) ensure that the chosen vendor can supply the agencys functional
requirements, (b) foster competitive vendor pricing and (c) offer the agency choices
with regard to products and services.

Who: Steering Committee, Project Manager, User and Technical Committees, and the
parent organizations finance and purchasing representatives.

When: 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 require-
ments 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-
ments should be well defined and the process should always be thoroughly followed.


PAGE 174
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).

Stop sign Icon
A bid protest occurs
when one or more
vendors object to an
element of the
procurement process,
usually caused by the
agencys failure to
follow the selection
process outlined in
the bid document.
When a bid protest
occurs, the vendors
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.

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 agencys
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
Citys purchasing department after the documents had been released.

Step 1
Research Your Jurisdictions Procurement
Requirements

You must start the procurement process by gathering the specific procurement require-
ments of the parent organization. Normally, the purchasing division or the City/County
attorneys office will be able to provide you with a list of these required elements, which
often include the following:

Procurement Thresholds: Most City or County governments have ordinances that
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: Per local, regional or State law, governments are often
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: Aside from the due date (which is usually set by the agency), there may
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.

PAGE 175

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

Pre-proposal Conferences: Many organizations require that a pre-proposal conference
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: There are rules that dictate how to open a vendors response
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 from your agency with the vendors. The procurement
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
Its 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 Teams 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 agencys needs.
Review the following five procurement tools to determine which is best suited to your
particular needs:


PAGE 176

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
agencys specific needs.

When to use an RFP: While an RFP delivers a complete proposal package, it requires a
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 46 months) and
resources to properly prepare and execute the RFP process.

Stop Sign Icon
Resist the full
disclosure
temptation. While it is
important to inform
vendors of the
projects purpose and
history, it is unwise to
inform them of the
projects 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!

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 pre-proposal conferences, etc.).

Sections of an RFP Document:
A. Project Background: Provides the projects history and outlines the major
applications being sought.
B. Rules of Preparation: Informs vendors of your agencys rules for conducting the
procurement.
C. Volumes: Describes various statistics that help the vendors to size their
proposal (e.g., number of workstations to be licensed).
D. Vendor Response: Provides questions that pertain to the vendors qualifications, 
experience, proposed solution and pricing.
E. Functional Response: Provides functionality questions that are specific to the
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: An agency that seeks general information about a vendors
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).


PAGE 177
Sections of an RFI Document:
A. Project Background: Defines the projects purpose and informs vendors of the
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
receive a response and any other general conditions of the RFI.
C. Volumes: This optional section provides information on your agencys particular 
environment.
D. Requested Information: In this section, your agency should define exactly what
it is interested in knowing about the vendors products and services (e.g.,
references, descriptions of products, normal implementation timeline, budgeting 
guidelines, key contact information, etc.).

Note: In addition to
the procurement tool
sections described in
this chapter, all of the
tools  whether RFP,
RFI, RFQ, ITB or Sole-
source  should
include an appendix
that contains agency-
specific information
(e.g., Application
Program Interface
information,
organizational charts,
glossary and
definition of terms,
etc.) that would be
useful for vendors in
preparing their
response

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 bidders list in
advance of conducting an actual procurement. The RFQ sets the bar for vendor
attributes and seeks to identify those vendors that will meet the agencys 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 agencys 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 vendors name must start with a Z, etc.). Such mistakes could
corrupt the bidders list and, ultimately, a future procurement.

Sections of an RFQ Document:
A. Project Background: Provides vendors with basic information about the history
and purpose of the project.
B. Rules of Preparation: Briefly informs vendors of when your agency expects to
receive a response and any other general conditions of the RFQ.
C. Qualifications Request: This section can assume two formats: It can either ask
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).


PAGE 178
4. Invitation to Bid (ITB)
The rarest of all procurement tools, an ITB defines the agencys 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 all of the
agencys 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:
A. Project Background: Provides the projects history and outlines the major
applications your agency is seeking.
B. Rules of Preparation: Informs vendors of your agencys rules for conducting the
procurement, including the contract that vendors must agree to, without
exception.
C. Volumes: Describes various statistics that help the vendors to size their
proposal (e.g., number of workstations to be licensed).
D. Vendor Response: Identifies your agencys requirements for vendor hardware,
software, service, performance and pricing.
E. Functional Response: Identifies your agencys functional requirements, asking
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
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.)


PAGE 179

Grant Requirements Icon

Sections of a Sole-source Justification: Agencies are required to use the U.S. Office of
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 (users) to
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 cant (or dont 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-
ing the wheel!

Borrowing another agencys functional specifications does come with some degree of risk.
After all, what if your needs dont exactly match up to theirs? To manage this, it will be
necessary for you (and your staff) to read and amend every single specification! Otherwise, 
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


PAGE 180
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:

a. Ability to set audible reminders for dispatchers
to check the status of a unit after a user-defined
period of time:

VENDOR RESPONSE OPTIONS
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

Upon receipt of the vendors 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 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 tightly-
focused specification. It might prevent vendors from accurately responding with a
single response code.


PAGE 181
Tips Icon
Remember: Failure
to follow local
procurement
requirements could
result in a failed
procurement!

Step 5
Create Evaluation and Selection Criteria
Most agencies must include the evaluation and selection criteria in the bid documents,
per governmental requirements. However, its a good idea to include the information
even if you dont 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:

Image of Sample Rankings



PAGE 182
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 systems 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 vendors 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 agencys 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
vendors specification responses to each category (CAD, RMS, etc.) and plot them side-
by-side, for an easy-to-view comparison.

Evaluation Team
-Review
-Summarize
-Evaluate
-Rank
-Clarify
-Choose semifinalists

Vendor Demos:
-Create an agenda
-Define scope
-Establish timeframe

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


PAGE 183
Tips Icon
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
agencys data.

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, multi-
application 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: Evaluation Team members should contact their peers at
the reference sites listed in the vendors proposal response, as well as any others who are
identified through the process, seeking to learn more about the vendors 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.

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


PAGE 184
Assess Vendor Fit: Following the telephone reference checks, the team should meet
again to determine whether to continue with the review of the finalist, or select the
runner-up vendor, as an alternative.

Site Visits: Assuming the vendor passes the reference checks, the next step is to
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.


After paying a site visit
to another agency,
your Executive
Sponsor should follow
up with a thank you
letter to the agencys
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.

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 agencys 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: Following the site visits, the Evaluation Team should meet again
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 youve identified the finalist, its on to contract negotiations!


PAGE 185
CHAPTER 15
CREATE THE CONTRACT


PAGE 187
Chapter 15: Create the Contract

What
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
this chapter and mean the same thing.

Why
Failure to negotiate a favorable agreement will leave the project exposed to tremendous 
risk and probable destruction.

Who
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 organizations legal counsel (City or County Attorney), should also
participate.

When
As soon as your agency identifies a finalist vendor.

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.

For most police agencies, the contract negotiation process is the most difficult and
foreign project task. Its 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 enforce-
ment 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, well also explore the
actual documents that should be included, adding advice along the way for
securing the most advantageous language. Finally, well 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 cant be done
without one, but you must realize that your agency is at a disadvantage when
inexperienced agency staff negotiate with a vendors experienced team of contract
negotiators and attorneys.

 
PAGE 188
Tips Icon
Agencies should
never use the
vendors base
agreement, as it
places the vendor in a
commanding position
over the contract
structure and,
ultimately, the entire

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

Tips Icon
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
projects budget.
Remember, it never
hurts your position to
ask for reduced
pricing or other
incentives (e.g.,
additional services or
software licenses).

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
agencys legal counsel will ordinarily supply the contracts 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 attorneys 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 vendors proposal response, usually in the form of exhibits to the
primary agreement.



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

Image of Umbrella Agreement
"on" umbrella  are:
"legalese",
 Defines Legal Obligations of the Parties, 
 City/County Required Terms/Conditions, and
 Numerous References to Exhibits.

"under" the umbrella are:
EXHIBITS
- Statement of Work
- Project Deliverables
- Project Timetable
- Payment Schedule
- More

Tips Icon
The most common
contract sticking
points usually relate
to indemnification and
penalties for failure to
perform (such as
liquidated damages,
defined in
Chapter 12).

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


PAGE 190

THE PRIMARY AGREEMENT

 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 devel-
oped, based upon the vendors proposal and as a consequence
of meeting with the vendor and agreeing as to what the vendor
will be providing throughout the project.


PAGE 191

Executive Sponsors Icon
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.

Exhibits
Normally, attorneys will not offer advice on the exhibit-related content, simply because
they dont 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, its 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: The blueprint for your implementation, this
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.


PAGE 192

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.

Stop Sign Icon
Remember: If its
not in the SOW, its
not going to happen!


Tips Icon
Many agencies have
found that video or
audio taping training
sessions is an
invaluable tool. The
tapes can be used as
refresher training for
existing employees or
to partially train new
employees.

Training Plan Exhibit: A critical, and often overlooked, section of the SOW is the
development of a comprehensive training plan. Agencies must carefully evaluate the
vendors 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
Direct Training. Direct training is often used when the pool of students is relatively
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. The most common training approach, this method provides
direct training to a small group of employees focused on both learning the
application, as well as how to train the balance of the organizations 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. About 6 weeks after going live with an application, many
agencies benefit from refresher training, wherein the vendors training staff
returns to the agency to revisit various training concepts and address questions
from users.

Mobile Patrol Training. For large agencies, herding the entire patrol staff into
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.



PAGE 193

Tips Icon
Dont 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 doesnt supply
a list of project
deliverables in a
spreadsheet format,
insist on it!

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
organizations facilities or outsourcing to a local private technology training center.

Training Costs
External: As you review the project budget, you will find that training is one of the
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: The financial impact of training employees on new technology is obviously 
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 agencys annual
budget.

Project Deliverables Exhibit: This section of the contract identifies everything that is
being supplied by the vendor that has a direct cost, including: hardware (description of
equipment), software (full description of modules, interfaces, licenses, etc.) and services 
(e.g., 100 hours of training at a rate of $500/hour, etc.).

Technical Experts Icon
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 projects Technical Committee must
review the document before contract signing.

Note: Make sure to stipulate that the vendor provide the 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).


PAGE 194
Payment Schedule Exhibit: A key component of the contract, this document serves to
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:

Stop Sign Icon
Remember:
Delivery does not
equal acceptance. See
Chapter 17, page 213,
to learn more.

Image of Payment Schedule

EXHIBIT X  SAMPLE PAYMENT SCHEDULE
SOW Task Number	Description		% of Total	Amount
1		Contract Signing	2%		$ 30,000
2		Hardware Delivery	8%		120,000
3		CAD Acceptance		15%		225,000
4		RMS Acceptance		25%		375,000
5		Training Completion	15%		225,000
6		Documentation Delivery	10%		150,000
7		Total System Acceptance	25%		375,000
		TOTAL			100%		$1,500,000

 Project Timeline Exhibit: The project timeline is a critical document because it defines
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, time-
triggered 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.

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



PAGE 195

Tips Icon
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).

Geofile Construction Document Exhibit: Agencies that are purchasing CAD applications 
must often convert their parent organizations base geographic information
systems (GIS) into the CAD vendors 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 vendors roles and responsibilities in the conversion, testing and
installation phases.

License Agreement Exhibit: Unless the attorneys have spelled out licensing agreement
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 vendors 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: Agencies that require the vendor to provide
continuous product support will need to prepare this exhibit. The document will identify
the type of service (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 10minutes 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 Vendors RFP Response Exhibit: Thats right! The vendors claims and assertions
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.



PAGE 196
Software Warranty Exhibit: Vendors generally offer a 1-year warranty on parts and
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: Occasionally, vendors will partner with subcontractors to fulfill
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 plans and criteria are a must for any
software project. See Chapter 17for information on creating portions of this document.

Interface Control Document (ICD) Exhibit: If the project includes interfaces, it must
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.
Interfaces that are concretely defined are less subject to delays and excuses! As a sample
ICD format, consider the following:



PAGE 197

Interface Name			Vendor X CAD data to Vendor Y RMS
Interface Summary		Transfer of Vendor X CAD data to Vendor Y RMS product.
Vendor X CAD Version		V 2002.1
Vendor Y RMS Version		V 3.45
Vendor Y System Interface	Custom software development for Anywhere PD to use message
				switch device to transfer data from CAD.
Data Elements to be Exchanged	List of specific fields that need to be transferred from CAD to
				RMS (i.e., call number, location, etc.).
External System Interface	TCP/IP
Protocols			TCP/IP
Vendor Y Hardware Interface	CAD server Ethernet adapter.
Vendor Y Tasks			Install and test internal communications software and connect to
				City-provided network hub or switch equipment.
City Tasks			Provide City message switch communications and associated
				equipment beyond hub.
API Locations			See Appendix B for CAD API.
Comments			None

Documentation Exhibit: This exhibit clearly defines the type of documentation to be
provided under the contract, specifying the medium (CD, paper, other) and whether the
documentation is site-specific. (Some agencies must have the vendors documentation
amended by technical writers to reflect customization  this is often called as-built
documentation.)

Other Exhibits: Remember, each contract is unique and requires site-specific documents 
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.



PAGE 198
Tips for Negotiating a Solid Contract
Single Points of Contact: Negotiating a contract of complexity requires clear and
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 vendors 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: Recently, some agencies have recorded or
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 agencys assertions are also captured in the recording and are equally useful to the
vendor.

Handling Disputes: During the course of contract negotiations, disputes will occur!
Handling them in a professional manner will convey a sense of authority and place the
agency in a more commanding position. First, lets 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 agencys 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 dont
hesitate to make a judgment that an issue should be temporarily suspended.



PAGE 199
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: During the process, hundreds of changes will be made to contract
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: Surprisingly, few agencies are aware that contracts are often
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.

........................................... 
Whats Next?
Plan for System Implementation....................................................Chapter 16
Conduct Quality Assurance Testing.................................................Chapter 17


PAGE 200
........................................... 
PART IV ASSIGNMENTS

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 Technology Tasks
1.Attend the pre-proposal conference and articulate the
agencys 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 Technology Tasks
1.Form the Evaluation Team to participate in procurement
 and contract negotiations; augment with parent
organizations 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 interviews, 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)



PAGE 201
........................................... 
PART IV ASSIGNMENTS, CONTINUED

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 Technology Tasks
1.Research jurisdictions procurement requirements
(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)


PAGE 202
........................................... 
PART IV ASSIGNMENTS, CONTINUED

USER COMMITTEE
Role
1.Provide input to the Project Manager and Evaluation Team
on procurement documents and vendor responses/
demonstrations

Acquire the Technology Tasks
1.Participate in focus groups and develop written
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 Technology Tasks
1.Participate in focus groups and develop written
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)


PAGE 203
Part V:
Implement the Technology

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


PAGE 205
CHAPTER 16
PREPARE AN IMPLEMENTATION PLAN


PAGE 207
Chapter 16:
Prepare an Implementation Plan

What
An Implementation Plan is the blueprint that enables project management to define
the rules that will guide the project toward completion.

Why
Failure to conduct implementation planning could lead to missed deadlines, vague
responsibilities and, almost certainly, costly change orders.

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

When
Implementation planning starts once the Statement of Work has been finalized. If the
project kick off is next week, youve 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 vendors obligations. This chapter defines the docu-
ments that need to be collected or prepared in order to develop the implementa-
tion 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!

Remember: The
vendor agreement is
also known as the
contract, and consists
of a primary
agreement and a
variety of exhibits. See
Chapter 15.

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, youll need to retrieve two documents: your
Project Plan and your vendor agreement.


PAGE 208

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.

CHAPTER 1: PROJECT SUMMARY
Overview - This is merely a one-paragraph summary of the projects general scope, timeline and budget.

Deliverables - Look to your contract for the Project Deliverables Exhibit (you do have one, dont you?).
Simply cut-and-paste it into this section, which defines what will be delivered and when.

Audit Trail - Use this section to record what has happened and when. Because this will
become a living document, it's very important to record something is scheduled to be 
complete and ultimately, when it is completed. Usually, a simple three column chart will
suffice (Who, What, When).

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


CHAPTER 2: PROJECT ORGANIZATION

Approval Process - In keeping with the concept of planning ahead, this section mimics the Project
Plans 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 youre not sure, have your attorney or consultant review the
language first.

Organizational Structure - Again, taking the project organizational chart from the Project Plan, modify it
to include the vendors staff.

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

Responsibilities - Refer to your vendor agreement for the specific responsibilities of the
contractor and the agency. Inserting those responsibilities into the Implemen-
tation Plan ensures that project participants without access to the agreement
documents clearly understand each partys obligation.



PAGE 209

CHAPTER 3: MANAGEMENT PROCESS
Project Objectives - Include the objectives from the Project Plan.

Assumptions/Constraints - 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.).

Risk Management Plan - The original Risk Management Plan from the Project Plan should be valid and
recent, so cut-and-paste it into this document.

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

CHAPTER 4: WORK, SCHEDULE AND BUDGET TOOLS
Select Contract Exhibits - 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

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 projects status and detail. We encourage agencies that have such
resources to take advantage of them (the more eyes the better!).


PAGE 211
CHAPTER 17
DEVELOP AND USE QUALITY ASSURANCE TESTS


PAGE 213
Chapter 17:
Develop and Use Quality Assurance Tests

What
Quality assurances are actually tests that ensure the vendors hardware and software
perform according to specification.

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

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

When
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 vendors 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 vendors 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 agencys 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.


PAGE 214

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 vendors software is
functioning as described in product literature and, possibly, in their response to
the agencys 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 vendors willingness to
agree to the agencys terms during contract negotiations.

Reliability: This testing is designed to determine the uptime of a vendors
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 vendors 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
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.


PAGE 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
vendors response to the RFP and the vendors 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 vendors product.


PAGE 216
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 agencys 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 agencys 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 agencys Project Manager that the
installation phase of the contract has been fully completed and all requirements have been met.


PAGE 217 

RELIABILITY TEST  SAMPLE LANGUAGE
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 vendors technical specifications and functional 
descriptions, which shall satisfy the requirements of this proposal at a 100% accuracy level:
As quoted in the vendors 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 vendors 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 condi-
tions 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.


PAGE 218

RELIABILITY TEST  SAMPLE LANGUAGE (CONTINUED)
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 perfor-
mance 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.


PAGE 219

PERFORMANCE TEST  SAMPLE LANGUAGE
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 Corporations 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.


PAGE 220

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

........................................... 
Whats Next?
Undertake Project Closeout and Recurring Tasks...........................Chapter 18
Manage, and Comply With, Your Grant Award................................Chapter 19


PAGE 221
........................................... 
PART V ASSIGNMENTS

EXECUTIVE SPONSOR
Role
1.Ultimate decisionmaker
2.Provide oversight and guidance

Implement the Technology Tasks
1.Approve Implementation Plan (Chapter 16, page 209)
2.Based on outcomes of Quality Assurance (QA) testing
and Steering Committees recommendation,
determine whether to accept/withhold acceptance
of technology (Chapter 17, page 220)

STEERING COMMITTEE
Role
1.Evaluate post-implementation vendor and product
performance
2.Provide knowledge and recommendations

Implement the Technology Tasks
1.Review and approve Implementation Plan and continual
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)


PAGE 222

........................................... 
PART V ASSIGNMENTS, CONTINUED

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 Technology Tasks
1.Organize an Implementation Team, comprised of staff
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)


PAGE 223
........................................... 
PART V ASSIGNMENTS, CONTINUED

IMPLEMENTATION TEAM (A SUBSET OF THE PROJECT TEAM)
Role
1.Create the Implementation Plan

Implement the Technology Tasks
1.Create the Implementation Plan document, modifying the
Project Plan to accommodate the vendors 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 Technology Tasks
1.Assist with QA functionality, reliability and performance
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 Technology Tasks
1.Assist with QA functionality and performance testing,
focusing particularly on exercising user-oriented functions
(Chapter 17)
2.Provide advice and expertise to staff and decisionmakers
(Chapter 17)


PAGE 225
Part VI:
Maintain the Technology

Technology makes it possible for people to 
gain control over everything, except over 
technology. 
 John Tudor 


PAGE 227
CHAPTER 18
ENSURE THE SUCCESS OF YOUR
TECHNOLOGY INITIATIVE: ONGOING TASKS


PAGE 229

Chapter 18:
Ensure the Success of Your
Technology Initiative:
Ongoing Tasks

What
A process to ensure that your agencys new technology is maintained, its upgrades and
enhancements are planned, and that your staff continues to get the most out of the
new system.

Why
Technology projects fail when a system is implemented, then neglected.

Who
The Project Manager is responsible for keeping the technology initiative and related
issues in front of the decisionmaking structure.

When
At the conclusion of the projects 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 imple-
mentation of a system does not signal the end of the planning process. Systems
implementation really signals the 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 systems live
date, and semiannually in the years that follow.



PAGE 230

Project Closeout Tasks

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)

Marking the conclusion of your technology projects implementation phase is a task
called Project Closeout, which is the appropriate time to undertake the following
retrospective tasks:

Reassignment: Reassign or release Project Team members to other projects (or
previous assignments) as their full-time tasks are completed.

Project Post-evaluation: A thorough review, spearheaded by the Project Manager,
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 agencys Project Team and
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
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 projects final
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 doesnt
stop there!


PAGE 231

Checklist of Recurring Tasks

Checklists Icon
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:

Checklists Icon
Keep the decisionmaking structure and committees intact. The main committees 
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.

Checklists Icon
Actively use the communications plan. Keep open lines of communication with
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.

Checklists Icon
Continuously monitor and document project activities, issues and user 
satisfaction. Continue to journal all project activities and issues (successes as
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).

Checklists Icon
Do not shelve the Project Plan. Too often Project Plans get relegated to the
library where they merely gather dust. The Project Plan really is a living
document and should be treated as such. Weve 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.

Checklists Icon
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 dont get done! There
have been too many instances where agencies have put awaythe 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


PAGE 232

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!


Checklists Icon
Revise your recurring costs budget and prepare for technology upgrade, 
replacements and enhancements. We talked about lifecycle planning throughout 
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.

Checklists Icon
Assess how your IT staff is handling support of the new system. Spend a good
deal of time with your agency and your parent organizations 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 projects 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).

Checklists Icon
Remember that training should not be a one-time activity! Plan and budget for
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.

Checklists Icon
Complete the lessons learned document. Youll want to make sure that you
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 didnt.

In summary:
Dont forget the
system lifecycle!
Image of System Lifecyle
Management, planning, procurement, Implementation, Integration (in circular design)


PAGE 233
CHAPTER 19
GRANT MANAGEMENT AND COMPLIANCE


PAGE 235

Chapter 19:
Grant Management and Compliance

What
Undertaking the proper steps to ensure that your agency is complying with the
conditions of a grant.

Why
Because the granting agency requires compliance and failing to do so may result in the
withdrawal of grant funds.

Who
Agency grant managers, finance employees and others, depending on the type of
grant received.

When
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! The majority of police agencies are thrilled upon notification that they
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! Accepting a grant award is rarely condition-free. Most grants are
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.


PAGE 236
 
Grant Requirements Icon
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/cfr-
retrieve.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

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 organizations 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 grants 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


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

Image of File Cabinet
File 1: Application and pre-award data
File 2: A journal of all correspondence (internal and external) related to the grant
File 3: Official award documents from the granting agency
File 4: All grant application corrections and adjustments
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: All supporting data related to the grant


PAGE 238

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.

Top 5 Grant-related Blunders

Stop Sign Icon
During our research for the Guide, we encountered MANY grant-related mistakes, but
the following warrant mention as the Top 5 Grant-related Blunders:

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

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

3.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. See Chapter 11, page 145.

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


PAGE 239

5.After getting the grant and beginning implementation, we changed our objectives,
altered our Project Plan and didnt 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.
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.

Grant Requirements Icon
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.


PAGE 240
........................................... 
PART VI ASSIGNMENTS

EXECUTIVE SPONSOR
Role
1.Ultimate decisionmaker
2.Provide oversight and guidance

Maintain the Technology Tasks
1.Attend Post-project meeting; recognize/reward team
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 Technology Tasks
1.Reassign/release Project Team members to other projects
(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)


PAGE 241
........................................... 
PART VI ASSIGNMENTS, CONTINUED

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 Technology Tasks
1.Organize and lead Project Post-evaluation, Vendor 
Transition Meeting and Post-project Meeting
(Chapter 18, page 230)
2.Prepare projects 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)


242
........................................... 
PART VI ASSIGNMENTS, CONTINUED

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 Technology Tasks
1.Attend/participate in project closeout meetings and 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 Technology Tasks
1.Attend/participate in project closeout meetings and 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)


PAGE 243
........................................... 
PART VI ASSIGNMENTS, CONTINUED

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 Technology Tasks
1.Follow the steps to assure grants are properly managed
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)


PAGE 245
Appendix 1:
Information Technology Descriptions


PAGE 247
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 capabili-
ties, such as data capture and entry; search, retrieval and display; messaging; and
forming complex linkages between data elements.

PAGE 248

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.

Image of Computer Bank

CAD fully automates the call-taking 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.


Effective handling of an
emergency CFS through a
geo-based CAD:

HOW IT WORKS
 A 911 CFS is received by a call-
taker.
 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 service, 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.


PAGE 249

Typical CAD Features*

Technology Components 
 Dual displays (with computer mapping)
 Enhanced 911 (E911)/telephony
 Integrated radio

Primary Modules 
 Incident entry (call-takers)
 Dispatching
 Status monitoring
 Administrative
 Training
 Statistics
 Alarm billing
 Permits
 Mapping

Inputs 
 E911ANI/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
 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 1/2 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.


PAGE 250

Mobile Data Computing and Automated Field Reporting

Mobile computing has become the catchall phrase for outfitting
an officers 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.

Image of stylus on computer

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, spell-
checking, prefilled fields, pre-population of
multiple forms, error correction and more.

Image of in-car computer

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


PAGE 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 paperwork. 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 
 Laptop computers
 Hand-held personal digital assistants
 Public or private radio systems

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 
 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 1/2 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. 


PAGE 252

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.

Image of computer room

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

Image of Mainframe computer


PAGE 253

 Strategic: Offering the organization critical
information that assists in tactical planning,
resource deployment, performance assessments 
(individuals and units), risk assessment 
and management, and accountability.

 Tactical: Providing officers and other
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
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 enterprise-wide access to the
status of property and evidence.

 Administrative: Providing information on
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 
 Workstations
 Networked PCs
 Wireless devices
 Displays
 Servers
 Optical storage
 Hand-held devices
 Bar coding (property and evidence)
 Printers

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


PAGE 254

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 
 Reports
 NCIC uploads
 Stolen vehicles
 Warrants
 CAD scheduling data
 Data for integrated justice
 Variable exports
 Jail
 Ticket processing
 Parent organization applications

Human Interface 
 Who uses it?
 Sworn personnel
 Records
 Command staff
 Detectives
 Supervisors
 Jailers
 Property/evidence clerks
 Crime analysts
 Dispatchers
 Who supports it?
 Small-medium agency: at least 1/2 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.


PAGE 255

Jail Management Systems

Image of booking computer, jail cell

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
inmates record.
 A bar code label is affixed to the
inmates property and/or
identification wristband for tracking purposes.


PAGE 256

Typical JMS Features*
Technology Components 
 Workstations
    Networked PCs
    Monitors
 Identix/Livescan
 AFIS
 Mugshot cameras/Workstations

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 
 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 Attorneys Office
    Public Defenders Office
    Courts
    Probation
    Parole
 Who supports it?
    Small-medium agency: at least 1/2 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.



PAGE 257

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.

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


Emergency Response To develop an effective police response to an incident or
emergency means that law enforcement agencies must have hotspots, trends and potential
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
community awareness and response.

Image of multi-layer GIS system
top layer: drug trafficking,
second layer: schools,
third layer: streets,
fourth layer: beat.

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 information about a location allows a GIS to view either discrete pieces or


PAGE 258

levels of information or to increase the complexity of an analysis by layering many 
levels of information together to create a detailed picture.

Image of City Map with information on traffic citations

Thus, GIS, working with computer-generated 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 
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

Image of Computer screenshot with city map and crime incidents displayed.



PAGE 259

taking place in a particular 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.

Image of Computer screenshot with city map and crime incidents displayed.

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 
 Server
 Displays
 Scanners

Inputs 
 Base maps
 Layers from governmental agencies
(assessor, tax records, building/safety, etc.)
 CAD
 RMS
 Users

Outputs 
 Maps
 World Wide Web
 RMS

Human Interface 
 Who uses it?
    Sworn personnel
    Crime analysts
    Detectives
    Command staff
    Supervisors
 Who supports it?
    1/2 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.

PAGE 261
Appendix 2:
Glossary


PAGE 263

Glossary

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 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 Chapter 1, pages 27, 31
Groups that are formed as a subset to the projects 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 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 service, 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 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 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 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 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 undertaking (such as planning, procurement,
implementation and management).

Bonding costs Chapter 11, page 142
Bonds required may include those dealing with performance, maintenance and payment.



PAGE 264

Business case Chapter 3, page 56
The projects 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 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 Chapter 4, page 72
A report created by the Project Manager that documents an organizations business processes. It is used
as a reference for understanding how the organization currently accomplishes its business objectives.

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 clientis a client designed to be especially small so that the bulk of data processing
occurs on the server.

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 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 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 Chapter 11, page 142
Funding that is set aside for unexpected and, therefore, often unbudgeted activities. On average,
contingencies range from 1015% of the hardware and software costs.

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


PAGE 265
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) 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 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 projects ultimate decisionmaking authority.

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 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 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 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 agencys
functional specifications.

Functionality testing Chapter 17, page 214
A type of acceptance testing designed to ensure that the vendors software is functioning as described in
product literature and, possibly, in their response to the agencys RFP.

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


PAGE 266
 
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 chart 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 Chapter 15, page 195
An exhibit included in the contract if an agency is purchasing a CAD application. Often the agencys base
geographic information systems (GIS) must be converted into the CAD vendors 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) 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 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 Chapter 12, page 154
A contract provision that allows an agency to keep a percentage of a vendors 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 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 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 organizations mission.

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


PAGE 267

Invitation to Bid (ITB) Chapter 14, page 178
A procurement tool used to define an agencys 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) Appendix 1, page 255
Assists with the full management of a jail or correctional facility, including tracking inmate and facility
data.

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

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 Chapter 12, page 154
A contract provision that compels the vendor to pay the agency if a contracted deadline is missed.

Milestone Chapter 10, page 130
A significant event in the project, usually completion of a major deliverable.

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 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 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 Chapter 1, page 37 and Chapter 11, page 141
The act of hiring an outside source to perform a service that is beyond the agencys existing resources,
usually a consultant.

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 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, performance reports should be provided on a weekly or
biweekly basis.


PAGE 268

Primary Agreement Chapter 15, page 189
The terms and conditions that govern the agencys relationship with the vendor. The agencys City or
County legal staff often prepare the primary agreement document.

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 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 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) Chapter 2, page 47
One of the best resources for tools and support for the Project Manager. Seewww.pmi.com.

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


PAGE 269
Quality assurances (QA) Chapter 17, page 213
Tests that ensure the vendors hardware and software perform according to specification.

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 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 Chapter 17, page 214
A type of acceptance testing designed to determine the uptime of a vendors 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) 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) Chapter 14, page 176
A procurement tool used to obtain actual hardware, software and services proposals from vendors.

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


PAGE 270

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 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 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 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 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) 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 Chapter 1, pages 27, 28
Members are generally high-level managers and/or supervisors 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 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 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) Seven Facts, page 13
A cyclical process regarding IT, with several stages, including planning, procurement, implementation
and management.

Technical Committee Chapter 1, pages 27, 31
Includes technical staff from the agency, as well as others from the agencys parent organization (e.g.,
City, County or State), if such support is provided. This committees role is to analyze the agencys existing
technical environment and to research and propose solutions to the agencys business needs and
problems.


PAGE  271

Technology Baseline Report Chapter 4, page 73
A report that documents an organizations 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) 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 Chapter 1, pages 27, 29
Includes subject matter and business process experts for the functions to be addressed. This committees
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 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) 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.


PAGE 273
Appendix 3:
Bibliography of Resources


PAGE 275
Appendix 3:
Bibliography of Resources

 Project Charter issues 
   Vision Statement 
	 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.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 
Offers this best-selling book: Project Planning, Scheduling & Control, 3rdEdition, 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.



PAGE 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 
Offers online article from the Gartner Group: What to look for in an IT strategic plan.


 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. Seehttp:// 
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 
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.



PAGE 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 Practitioners Guide to Managing Projects in the Information Age. Robert Ambrosino, Ph.D. Govern
ment Technology Press.
	 IT Professionals Guide to Project Management. Tech Republic. Seehttp://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.
	 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 
	 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 service 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.


PAGE 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 
	 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/ 
PMIs 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 
Article in CIO Magazine on risk management.
	 http://members.ozemail.com.au/~thomsett/form/index.htm 
Online risk assessment survey.


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


PAGE 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 
	 Websters New World Computer Dictionary.
	 Random House Websters 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 (issue briefs)
	 http://www.rms.net/lc_tutorial_series.htm (tutorials)
	 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 agencys 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) 
	 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.


PAGE 280

	 http://www.iacptechnology.org 
Website of the International Association of Chiefs of Polices 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.


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