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

DOJ Seal

COPS Logo

Policing Smarter Through IT: 
Learning from Chicagos Citizen and Law Enforcement 
Analysis and Reporting (CLEAR) System 

Office of Community Oriented Policing Services
www.cops.usdoj.gov

Prepared by The Institute for Policy Research
Northwestern University

Northwestern University Logo


Policing Smarter Through IT: 
Learning from Chicagos Citizen and Law Enforcement 
Analysis and Reporting (CLEAR) System 


Prepared by


Northwestern University


Wesley G. Skogan
Susan M. Hartnett 
Jill DuBois
Jason Bennis
So Young Kim


University of Illinois at Chicago


Dennis Rosenbaum
Lisa Graziano
Cody Stephens


with assistance from 

Chelsea Brown 
Sarah Rosenbaum 
Katherine Casper 
Stephen Ryan 
Kimberly Lacker 
Barbara Seiden 
Gail Musial 
Eric Thompson 
Aaron Petty 

December 2003 

This report was prepared by Northwestern University, supported by Cooperative Agreement 
#2002CKWXK003, awarded by the Office of Community Oriented Policing Services (COPS), 
U.S. Department of Justice. The opinions, findings, and conclusions or recommendations 
expressed in this document are those of the authors and do not necessarily represent the official 
position or policies of the U.S. Department of Justice. 


Acknowledgments 

We would like to thank Chicago Police Superintendents Philip Cline and Terry Hillard for their 
cooperation and encouragement of this evaluation. Similar support came from Deputy 
Superintendent Barbara McDonald, Assistant Deputy Superintendent Ron Huberman and 
Information Services Director Charles Padgurskis. Their receptivity allowed us ongoing access 
to the police department and its partnering agencies in the Chicago metropolitan area. We also 
appreciate the cooperation of Oracle Corp., whose CLEAR project staffers have freely interacted 
with our research staff. 

Also generous with their time and expertise were personnel in CPDs Information and Strategic 
Services Division, who granted us extensive time for interviews and ample access to meetings. 
Of tremendous benefit to this project were the many officers and civilian employees throughout 
the Department who completed several questionnaires regarding CLEAR technology and its 
impact upon their jobs; suburban Chicago police agencies that afforded us time to interview their 
personnel about the CLEAR data warehouses impact on their organizations; the Illinois 
State Police for allowing us to interview key people in the criminal justice integration project; 
and the Illinois Criminal Justice Information Authority for permitting us to interview its staff 
about Chicagos criminal justice integration project. 

In addition, we would like to express our appreciation to The University of Illinois at Chicago 
for partnering with us in this evaluation and conducting formative research in the area of 
enhancing citizen involvement with their local police through the development of web surveys. 


Northwestern University Logo
COPS Logo

Foreword 

We are pleased to present this report on the CLEAR system. CLEAR, the Citizen and 
Law Enforcement Analysis and Reporting system was developed by the Chicago 
Police Department in partnership with the Oracle Corporation. Its focus on criminal 
justice data integration evolved out of the need to streamline and improve the utility 
of law enforcement data. The COPS Office has provided approximately $9 million for 
the CLEAR project in funding through MORE technology grants to the Chicago Police 
Department and other innovative grant programs. COPS also provided funding to 
Northwestern University to conduct a formal evaluation of the project, the results of 
which are contained within this report. 

The CLEAR system is currently used regionally, but it will soon be adopted by the 
entire state of Illinois, seamlessly integrating a broad range of police and criminal 
justice functions electronically. CLEAR uses a variety of cutting-edge technologies 
and is credited with saving officer time, reducing overtime costs, significantly 
reducing the need for clerical staff, helping to solve cases through its relational 
database, and increasing crime clearance rates in Chicago. It is being described as a 
national model for the future of police information systems and is currently being 
studied in Washington, D.C. and Los Angeles, California. 

Just this year, the Chicago Police Department won CIO Magazine's Grand Enterprise 
Value Award for this forward-thinking technological undertaking. This award 
represents the hard work of creative police officers and benefits multiple 
components within the criminal justice system, including law enforcement, courts, 
and corrections, thus enabling them to work together towards the same goal. We 
hope you will find the recommendations of this report helpful to you and the 
members of your own agency as you keep your communities safe. 

Carl R. Peed
Director
Office of Community Oriented Policing Services (COPS)

Philip Cline
Superintendent
City of Chicago Police Department



Contents


Executive Summary...........................................................i


Information Technology and the Police.......................................1


Origins of CLEAR ...........................................................3


Description of CLEAR .......................................................4


CLEAR Applications and the Development Process .............................5


Police Management Applications .............................................9
Automated Incident Reporting Application....................................9
Automated Arrest System Phase II ..........................................17
Crime Mapping .............................................................22
Digital Mugshot ...........................................................25
eTrack ....................................................................31
Gang Arrest ...............................................................35
Juvenile Arrest ...........................................................40
Personnel Suite ...........................................................47
Rap Sheet .................................................................52


Integration of Criminal Justice Information Systems .......................56
Chicagos Criminal Justice Information Systems Integration Project.........58
The Criminal Justice Integration Study ....................................60
Methodological Appendix ...................................................70
Community/Business Partnership ............................................77
Automated Pawnshop ........................................................79
Auto Theft ................................................................79
Internet Crash Report Routing System ......................................81


Applications Slated for Future Development/Implementation .................84
Enhanced Hot Desk .........................................................84
Organized Crime ...........................................................84
Probation and Parole ......................................................85


Conclusions and CLEAR in the Coming Year ..................................85



Figures

Figure 1 CLEAR Module Status................................................6
Figure 2 Automated Arrest Menu.............................................18
Figure 3 Vehicle Thefts Map................................................23
Figure 4 Digital Mugshot.................................................. 25
Figure 5 Inventory Label...................................................34
Figure 6 Personnel Suite Overview......................................... 47
Figure 7 Create Medical Absence Report Screen............................. 50
Figure 8 Medical Progress Notes Screen.....................................50
Figure 9 Criminal Justice Information Sharing............................. 56
Figure 10 Agency Menu..................................................... 59
Figure 11 Suburban Police CLEAR Users..................................... 61
Figure 12 Participation in CLEAR, All Agencies 2002-2003...................63

Tables 

Table 1 Assignments of Officers Sent for Training..........................63
Table 2 Average Monthly Data Warehouse Use by Type of Agency.............. 64
Table 3 Current Uses of the Data Warehouse.................................66
Table 4 Issues in Using the Data Warehouse................................ 67
Table 5 Reasons for Participating in the Data Warehouse....................68
Table 6 Local Attention to CLEAR.......................................... 69

Table A-1 Survey Response Rates............................................73
Table A-2 Survey Reliability: Agency Characteristics.......................74
Table A-3 Survey Reliability: Data Warehouse Issues........................75




Executive Summary 

This is a report on the Chicago Police Departments Citizen Law Enforcement Analysis 
and Reporting (CLEAR) system through the end of November 2003. CLEAR is to become an 
integrated, state-of-the-art criminal justice information system supporting the work of criminal 
justice agencies in Chicago and the State of Illinois. While it is being developed to serve the 
needs of Chicago and its surrounding communities, the system is adaptable for other agencies. 
This report examines the launch procedures that are underway, highlighting the first findings 
of an evaluation of CLEAR being conducted by Northwestern University in partnership with the 
University of Illinois at Chicago. The report describes the major components of CLEAR, and 
identifies aspects of the development process that have affected their progress toward 
completion. It concludes with a review of lessons learned, intended to assist law enforcement 
agencies when they embark on implementing enterprise-level IT systems. 

The primary goal of the CPDs technology initiative is to design and build an all-
encompassing enterprise information system that is intended to fundamentally change the way 
it and related criminal justice agencies conduct their business. CLEAR applications will impact 
three major functional aspects: police management, criminal justice integration and 
community/business partnership. The goals of the system include: 

Police management: Promote effective resource allocation; officer management and 
accountability; risk management and early warning; tactical and strategic planning; and fiscal 
accountability. The departmentwide management accountability process will make use of the 
new system to address crime and disorder problems; react to emerging crime; optimize 
community involvement; and manage available human and material resources. 

Criminal justice integration: Enable unified strategies to reduce crime; eliminate criminal 
justice bottlenecks; increase accountability between criminal justice agencies; and provide a 
comprehensive picture of offender activity. Information sharing already involves other law 
enforcement agencies, prosecutors, courts, the corrections system and other criminal justice 
agencies, and there are plans to support police-community partnerships. The CPDs hope is that 
the criminal justice integration component of CLEAR will give police the capacity to police 
smarter; enhance partnerships with surrounding suburbs and cities; improve the quality of 
criminal justice information; improve employee morale; and reduce costs. 

Community/business partnership: Strengthen problem-solving capacity, conduct 
community-needs assessment; and allow for easy and convenient information sharing and 
intelligence gathering from the community. Currently the CPD partners with citizens through 
monthly beat community meetings and through District Advisory Committees in each of the 25 
districts. There will be increased effort to reach people currently not participating in these 
activities as well as an increased focus on meaningful problem-solving and citizen involvement 
at beat community meetings. 

CLEAR provides for predictive resource allocation to deploy officers when and where 
needed; unprecedented availability of information for management analysis and officer 
accountability; shared problem-solving information for community policing partners; 


prepackaged information to support decision making at all levels of the Department; and 
provision of information integration to manage offender flow through the criminal justice 
system. When CLEAR is fully deployed, the CPD expects to enjoy reduced crime and safer 
communities; proactive community involvement; proactive resource allocation; decreased 
redundancy in administrative functions; and increased management and officer accountability. 
The various CLEAR applications will be available through the intranet at the CPD, the internet 
for the public and the extranet for other government agencies. 

CLEAR applications can pass through seven developmental stages before being 
launched: 1) conceptual, 2) joint application development (JAD) sessions, 3) subcontracting, 4) 
design/build, 5) pilot-testing, 6) training, and 7) implementation. 

Police Management Applications 

Automated Incident Reporting Application. The front end of the CPDs case reporting 
system is a CLEAR module known as AIRA (Automated Incident Reporting Application). AIRA 
enables Patrol Division officers  the backbone of the organization  to complete case reports via 
portable data terminals (PDTs) in their cars or at LAN-based work stations in any CPD facility. 
AIRA is a very ambitious project with roots dating back several years, and over its gestation 
period, the projects scope, depth and time line have grown exponentially. 

The Departments goals for automated case reporting are well-defined. AIRA is expected 
to simplify the reporting process; improve reporting accuracy, quality and completeness; free 
supervisory personnel from reviewing report minutiae; provide follow-up investigators with 
complete and timely information to improve case solveability; reduce the number of hours tied to 
report processing; and ensure compliance with federal NIBRS data standards. 

AIRA will interface with the Departments other key information applications and 
systems. Because AIRA is the front-line information collection system  the on ramp to 
CLEAR  it must successfully receive information from the citys automated dispatch system 
(PCAD) and, in turn, feed data into subsequent stages of the Departments crime investigation 
process. These include a digital mugshot system, an arrest database, and investigative followup 
modules used principally by the detective division.. All of this data is held in a central data 
warehouse. 

Because AIRA must interface many different modules, various types of interfaces and 
middleware needed to be developed, and complex adaptations must be made to accommodate the 
citys automated dispatch system. Time consuming equipment modifications were also required, 
and new procedures related to automated incident reporting had to be formalized in written 
orders. While all of these steps were complicated and time-consuming, modifications to the 
dispatch system proved so lengthy that development of the automated incident reporting 
application, originally conceived as a single application used for mobile and onsite incident 
reporting, became two distinct projects  LAN-based and mobile AIRA  in late 2003. 

LAN-based AIRA was piloted on one watch in a single police district in summer 2003, 
and by early December 2003, more than 100 officers were trained and using the application 


around the clock. Mobile AIRA is dependent on other developments and faces several significant 
challenges, including over-the-air bandwidth capacity, battery life, facilities limitations, and the 
magnitude of the training requirements in a large police department. A major impediment to 
mobile AIRAs launch was the modifications required by the citys PCAD system. These 
changes were completed by the end of 2003 and pilot testing got underway. However, a question 
that may be unanswerable until citywide implementation gets underway is whether the narrowband 
spectrum assigned to public safety agencies can adequately accommodate such a large-
scale wireless communication system. New battery technologies had to be identified to power 
the PDTs, and they had to work in Chicagos cold winters. Training for the entire Patrol Division 
on a totally new system is a herculean feat; nearly 10,000 people must learn to use this new 
computer system without disrupting daily operations  without overtime. Though it is not yet 
determined how many officers will trained at one time, the process will be underway for an 
extended period. As is the case with deployment of any CPD program requiring new equipment 
or workstations for district personnel, facility limitations must be overcome. Infrastructure 
surveys were conducted during July 2002 revealed that the citys oldest stations would need a 
considerable amount of rewiring, data port installation and minor remodeling for housing new 
hardware. In addition, each facility, old or new, needs additional computers. 

With LAN-based AIRA running smoothly and pilot testing of the mobile portion 
underway, the foundational blocks of this groundbreaking application have been laid. However, 
the remaining challenges  bandwidth, battery life, stationhouse infrastructure and training 
logistics  loom large. 

Automated Arrest System Phase II. The first phase of the CPDs Automated Arrest 
System, launched in 1998, was a client-server application used by lockup personnel to enter 
prisoner intake information during processing. Phase II shifts this function to arresting officers, 
allowing them to process the arrest via bolted-down ruggedized laptop computers in station 
interview rooms. Data entered by arresting officers interfaces with the Departments digital 
mugshot application and automated fingerprint identification system (AFIS), allowing lockup 
keepers to photograph arrestees as soon as they enter the lockup, resulting in real-time records. 
In addition, after lockup keepers post bookings, desk sergeants and watch commanders can 
approve the bookings or subsequent releases online. The Automated Arrest system produces a 
two-part arrest report: the first contains the data entered by the arresting officer, while the second 
compiles information inputted by the lockup keeper, desk sergeant and watch commander as the 
arrest processing progresses. Information relating to the arrestees identity is also added to this 
part of the report. These two reports constitute a complete arrest processing package. 

Automated Arrest Phase II also has electronic arrestee-detainment-tracking capability 
and can provide various reports for command staff on an immediate and on-request basis. 
History reports can be generated by a host of parameters, and numerous customized reports will 
be obtainable using available data captured through this process as well. 

In late July 2003, pilot testing of the web-enabled Automated Arrest application began in 
one Chicago police district. A facilities assessment revealed that furniture and computer 
equipment would need to be ordered. Everything added to these rooms needed to be bolted down 
 furniture and computer hardware  for the safety of interview room occupants. 


Though the application experienced a minimum of technical problems, those that did 
arise often necessitated convening policy-decision-makers to determine the best way to resolve 
them. Network connectivity problems with the laptop computers also cropped up, and the vendor 
had to rectify them. When this report was written, Automated Arrest was expected to be 
implemented in the next district in early January 2004. Like with AIRA, in-depth training is 
required for Phase II of the Automated Arrest application, magnifying the Departments training 
burden. In addition to the equipment procurement hurdles that must be overcome, circumventing 
infrastructure problems in the citys older facilities will take some very creative thinking. For the 
present, the application itself is considered fully developed, though enhancements and upgrades 
will certainly come about as needed. The next Automated Arrest development push will be 
criminal justice integration-related (see below). Changes will have to be made to the program to 
accommodate numerous criminal justice agencies that have expressed interest in using the 
Automated Arrest system. 

Personnel Suite. The Chicago Police Department is automating human resource 
functions in five of the Departments units: Finance, Internal Affairs, Office of Professional 
Standards, Medical and Personnel. The Department has three main goals for the Personnel Suite: 
to maintain comprehensive personnel files and eliminate redundant data entry; enable employees 
to initiate and complete many of their own personnel-related tasks; and provide managers with 
rich personnel-related data to help in performance review and behavior monitoring. The 
Department is also institutionalizing accountability by developing a module known as the 
Personnel Performance System (PPS), which will identify problem behavior before it results in 
an unfavorable outcome. The availability of this type of real-time performance-related data 
promises to usher in a new era of meaningful and effective personnel management at the CPD. 

The Personnel Suite will: 

 automate time and attendance tracking, and give the Department real-time information 
about its staffing situation 
 provide information for complaint investigations and eliminate redundant processes to 
ensure that duplicate complaints are not filed 
 automate the laborious manual process for tracking and regulating medical leave and 
injured-on- duty (IOD) data and providing real-time force-level numbers 
 computerize the departments star inventory system, tuition reimbursement policies, 
applicant background checks 
 provide a repository for all data related to officer behavior and performance and interpret 
information to identify officers whose performance indicates potential problems and 
provide them with intervention (counseling or training) designed to correct problematic 
behavior 


Much progress was made on the Personnel Suite in this evaluation period. At the time of 
this reports writing, applications were being developed for all of the above-mentioned units 
except Finance, and three applications had been launched. 


Citizen complaints about the police frequently involve two distinct parts of the 
department, so systems designed to capture and process their data were developed in tandem. 
Data entry and reporting screens have been designed and users have had opportunities to see the 
product and offer input. A related application that has been developed and pilot tested is an 
automated tactical response report (TRR), which documents incidents in which force is used or 
resistance encountered by officers. Two Medical Section applications were launched in July 
2003: the Medical Absence Reporting system used by district personnel at all levels. General 
users can create a medical absence report for co-workers calling in to report an illness-related 
day off, while lieutenants have approval and return-to-duty information access. In addition, 
command staff can view officers work status, create furlough requests and view information 
about officers medical absence history. Another facet of the application is used by Medical 
Services Section staff to schedule appointments, record progress notes and capture all 
information needed for medical records. As in many departments, medical-related personnel 
issues loom large in Chicago, and this suite of applications promises to increase accountability 
within the agency with regard to them. 

Two portions of Personnels segment of the Personnel Suite are approaching the pilot 
testing stage. The Star Management application manages and tracks the Departments inventory 
of stars, badges and shields. The Tuition Reimbursement system automates requests for tuition 
reimbursement, and facilitates supervisory review and approval of those requests. In addition, it 
allows for entry of financial aid information and grades earned. Two other Personnel modules 
are under development; one automates the process of nominating officers for awards and 
generates notifications to recipients, and the other enables all personnel to update records on the 
individuals they identify to be contacted in an emergency. The focus of 2004 Personnel Suite 
development will be on automating personnel-related functions such as hiring, drug testing, 
leave of absence, and position openings. 

The Personnel Performance System module will interpret information to identify officers 
whose performance indicates potential problems as a result of recurrent citizen complaints, 
pursuits and traffic accidents, firearm-discharge incidents and the like. Officers so identified are 
provided with intervention (counseling or training) designed to correct the problematic behavior. 
While this is currently done on a manual basis, the Personnel Suite will widen the scope of the 
data employed and systematize the problem-identification process. This component remains in 
the conceptual stage, mainly because the other applications from which essential personnel data 
are extracted must be developed first. The Police Executive Research Forum (PERF) has been 
helping the CPD identify best personnel practices and policies from the public and private 
sectors nationwide in the human resources areas the suite will encompass. 

Other modules. Several other applications at various stages of development and 
implementation round out the police management category of CLEAR systems: 

Crime Mapping, available through the data warehouse, replaces the Departments legacy 
program and, eventually be accessible on portable data terminals. The new crime mapping 
application will also include an upgrade of the version that is available to the public via the 


Internet. The Departments Digital Mugshot system enables detectives to create virtual lineups 
for victims and witnesses, creates an interface to keep sex offenders mugshots up-to-date 
and upgrades mugshot data capture in the lockups. The multi-phased deployment of eTrack 
automates evidence and recovered property inventory and tracking. The first phase, launched in 
summer 2002, provides electronic data capture. The second phase, implemented in June 2003, 
replaced the Criminal Evidence Recovered Tracking System (CERTS), the departments legacy 
inventory application. eTracks third phase will incorporate upgrades that enhance functionality. 

The Gang Arrest application, to be developed in several distinct stages, is intended 
enhance the departments ability to record gang information, reduce system redundancies and 
create a database that will enable officers to engage in predictive analysis. Stage one, which has 
been implemented, provides member and organization profiles, gang activity analysis and 
administrative reports. Subsequent stages involve creation of data entry capabilities, automated 
exchange of parolee status/conditions of release with the states department of corrections, and a 
major case operations file. 

To ensure more accurate record keeping and gain greater analytical capabilities, as well 
as to comply with the states juvenile justice rules, CLEAR includes an expanded Juvenile Arrest 
system. The new system captures data about station adjustments  the immediate resolution of a 
juvenile offense with conditions imposed on the offender by a youth investigator  without 
officers having to request a check of the paper records. 

The Automated Rap Sheet system produces reformatted records that are efficiently 
transmitted, validated and interpreted between organizations. Rap sheet redesign, the first stage 
of this project, was completed during this reporting period. The second development segment 
will create a linkage with the Illinois State Police and merge CPD and state data to improve the 
quality of both agencies records. Also planned is a data feed to the Illinois Department of 
Corrections that will provide a direct link between the CPD and their inmate information 
database. 

Integration of Criminal Justice Information Systems 

A central component of the strategic plan underlying CLEAR is the extension of its 
capabilities beyond Chicago. CLEAR is designed to support coordinated strategies to reduce 
crime by increasing the capacity of law enforcement agencies to police smarter. CLEAR also 
has the potential to help eliminate bottlenecks in the criminal justice system through the 
frictionless flow of information between its elements as well as agency partnerships that can 
develop around creating and using the information. CLEAR also potentially increases the 
accountability of criminal justice agencies, because of the easy availability of integrated data. 
Everyone involved understands that these goals and the issues that underlie them are not 
confined to the boundaries of any city. 

In practice, the partnership is being formed by opening access to the CLEAR data 
warehouse to other agencies. This involves ensuring that they have the technical capacity to 
access the system and training representatives of newly participating agencies. Behind the 


scenes, the Chicago Police Department created mechanisms for auditing use of the system by 
outsiders and put in place procedures to ensure responsible use. 

Chicagos data warehouse is an information repository that can produce a variety of 
relational reports using modern, flexible database query software. The data warehouse includes a 
list of data elements that expands almost daily. There is data on the criminal history of arrestees, 
outstanding warrants, the arrest status of juveniles, mug shots, and digitized fingerprints. 
Participating agencies also have access to CPD directives, streaming digital training videos, 
email addresses and directories, to name a few early offerings. 

Part of our evaluation encompassed the CPDs criminal justice integration efforts. This 
included a study of data warehouse users outside the Chicago Police Department. The criminal 
justice integration study examined the spread of data warehouse use during its first year. The 
integration effort began with a pilot test in six suburban police departments. The next group of 
outside users of the data warehouse were trained on the system in October 2002. This report 
traces use of the system by outside agencies of all types over a 13-month period ending in 
October 2003. 

The study has two purposes. The first is to describe the scope of agency utilization of the 
data warehouse. This report examines the number of agencies involved, and how agency 
representatives were initially trained. It describes the utilization of the system based on the 
results of a user survey and accounting statistics generated by the data warehouse itself. There is 
a description of trends in the use of the system over time. A user survey gathered reports of the 
obstacles that agencies had to overcome to get involved, and measures of their satisfaction with 
the system and its administration by the city. The second purpose of the study is to explain 
variations in the timing and extent of data warehouse use. To do this we developed measures of 
organizational and community factors that past research suggested could either facilitate or 
discourage agency utilization of the data warehouse. 

The study found that use of the CLEAR data warehouse has spread widely and rapidly. 
In just over a year it was adopted by almost all Cook County police departments and county 
agencies, units in many surrounding counties and important federal agencies. The Illinois State 
Police are particularly heavy users of the system. Almost every month brings a new record for 
system use, and the longer agencies participate, the more they use it and the more uses they find 
for the data. Our user survey found an almost unanimous thumbs up response to the data 
warehouse and its administration. Among the specifics, we found that detectives currently are 
the biggest and most creative users of the warehouse, and that mug shots and criminal histories 
are among the most popular products it offers. We also learned that suburban police agencies are 
using the system to solve very serious crimes, ranging from homicide to robbery to carjackings. 
Virtually all agencies are comfortable with the Chicago Police Department taking the lead on 
this project. To date, the CPD has borne the cost of creating and maintaining the system, and the 
user survey found this was an important factor encouraging participation. One issue that bares 
close watching is whether the administrative safeguards put in place by its many new 
participants prevent substantial misuse of the data. Another is how governance of the network of 
cooperation that has grown around the data warehouse will look as adoption of the system 


spreads even further. As new entities begin to contribute to its funding there will be calls for 
changes in the system to accommodate their priorities. 

Community/Business Partnership 

The proposed Community/Business Partnership component of the CLEAR initiative is to: 
1) enhance the citys problem-solving capacity, 2) improve community needs assessment, 3) 
make information sharing easier and more convenient, and 4) gather more intelligence through 
community sources. The creation of a sophisticated Web-based system for communicating with 
the public also has the potential to help the CPD achieve several management objectives under 
CLEAR, especially in the areas of accountability and strategic planning. In theory, the 
systematic collection, analysis, utilization and dissemination of new community-based data, 
reported via the Internet, holds the promise of empowering both police officers and local 
residents involved in the process of proactive problem-solving and community crime prevention. 

At present, the Community/Business Partnership component is in the conceptual stage. 
The CPD has expressed a commitment to move ahead with the planning phase, and the 
evaluation team at the University of Illinois at Chicago (UIC) is providing research assistance. 
The CPD and the research team engaged in several tasks. First, they developed a model for Web-
based communication with the public. Second, UIC engaged in a formative assessment of a 
prototype web-based survey by exploring community interest and readiness for Internet 
communication with the CPD. This included gathering information about residents access to the 
Internet, usage of the current CPD Web page and reactions to the prototype online survey. Third, 
the CPD and UIC proposed a demonstration and evaluation plan for field-testing this new 
initiative. 

Currently, three other CLEAR applications that fall under the Community/Business 
Partnership umbrella are under development: Automated Pawnshop, which is in the conceptual 
stage; Auto Theft Recovery, which is developed, but awaiting contract approvals; and Internet 
Crash Report Routing System, which is partially implemented, but awaiting more funding. 
Automated Pawnshop would provide a mechanism for pawnshops to provide online inventory 
reports, which would then be cross-checked against case reports and Evidence and Recovered 
Property Section (ERPS) inventories. Auto Theft Recovery will provide law enforcement 
agencies in Illinois with a geographical analysis tool for examining patterns of automobile theft 
and recovery. It is also envisioned that the general public will be able to find recovery 
information pertaining to their automobiles. The CPD is developing a comprehensive Traffic 
Crash report-related application composed of three modules. One module will automate the 
traffic crash reporting process and wirelessly transmit reports from officers PDTs directly to 
appropriate Department units and the data warehouse. A second module will feed traffic crash 
report information to the Major Accident Incident Section (MAIS) for follow up investigations. 
An application that automates traffic crash report retrieval and the online fulfillment of requests 
for report copies by citizens and insurance companies is the third module of this system. 


Conclusions: CLEAR in the Coming Year 

The CPD has overcome many obstacles to implementing information technology that 
were identified in earlier studies of IT implementation in police agencies. They initially secured 
considerable funding and talent for CLEAR, and they have continued to be successful in 
obtaining financial support for new applications. CLEARs architects have a solid understanding 
of IT and have engaged in several processes to ensure good product outcomes. They have kept at 
the forefront the importance of officer buy-in, through customized training, comprehensive 
testing and pilot-testing, and inclusion of stakeholders in the development and implementation of 
CLEAR applications. In terms of the criminal justice integration effort, neighboring law 
enforcement agencies have been singing its praises because of the utility of the data that the 
CPD is sharing through its data warehouse. There is ongoing discussion in Illinois about a 
broader partnership between Chicago and the state police. Their partnership would support web-
enabled case management statewide, as CLEAR application became available. This would 
standardize incident, arrest and follow-up investigation reports statewide, and create one 
criminal records system. 

Some impediments facing the Department include securing the continued flow of funding 
for many of the applications, station infrastructure challenges and the continuing balancing act of 
time management. Progress has been stalled on many applications due to contract and vendor 
complications. Working with the bureaucracy in the City of Chicago on vendor negotiations and 
securing contracts has been, and continues to be, a daunting task. Development of each 
application requires tremendous time and effort, and progress or completion of each component 
is often dependent on progress or completion of another. Launch dates for some applications 
have been postponed due to other applications unsigned contracts resulting in a vital server or 
some other piece of hardware not being delivered. Thus the CPDs information highway 
functions like all other roads: when one vehicle slams on the brakes; the others screech to a halt 
as well. 

Projects are also susceptible to scope creep, causing applications to grow ever larger 
and more complex than originally planned when developers tack on just one more simple 
enhancement  numerous times. These well-intentioned additions, often implemented in 
response to requests by users groups, push completion dates later and later. 

New department directives have been created that are at cross-purposes with CLEAR 
development. Faced with the very formidable task of addressing the high homicide rate and open 
air drug markets, the CPD has redeployed officers who are central to driving this multi-year 
project to completion to street assignments. Shifting assignments runs counter to the timely 
completion of CLEAR. Training officers to use the applications is a sequential process because 
the agency is very large and only a few can stand down from duty at a particular time. When 
officers and supervisors work assignments are in flux, carefully crafted planning and training 
schedules can be toppled or stalled. This also applies to deadline-bound application developers 
who are often called on to regroup and address more immediate and pressing problems within 
the Department. 


Another problem, again linked to the sheer size of the CPD, is that system development is 
not shared in a consistent and informative manner departmentwide. Thus, we found systems 
developed within the traditional silos that divide the Department bureaucratically, leading to 
redundancies, inefficiencies and potential turf battles. Internal communication and information 
sharing is also a very difficult challenge within large organizations. It appears that there are no 
set mechanisms or management structures in place to facilitate the even flow of information 
either vertically or horizontally in the Department. For example, it is noticeable that one of the 
major constituencies for CLEAR  the Departments Office of Crime Strategy and Management 
Accountability  has been left out of the planning and development process. Some of the most 
important CLEAR applications, including the personnel suite that promises to transform 
management processes within the Department, are vital to their mission of improving 
management, yet staff members in this unit know virtually nothing about CLEAR or 
development plans. 

Measuring impact is a step beyond listing the individual successes and impediments in 
the creation of an IT enterprise. The Chicago Police Department has had a very sizeable impact 
on criminal justice agencies that are data warehouse users. However, in terms of the many 
CLEAR applications that are promised to help reduce crime, assist in strategic manpower 
redeployment and increase accountability, there has been little emphasis within the Department 
on measuring the impact of their new systems. There is strong consensus about when an 
application is not working, and great effort is put forth to create a solution, but almost no effort is 
being expended to understand whether the new system has made the Department a better 
organization. The emphasis is on doing the work, but not measuring whether the work has made 
any difference in terms of the organizations goals and objectives. When impact questions are 
raised within the CPD, they are usually raised only by senior management within the context of 
accountability meetings, and only responded to in the context of the specific situation as opposed 
to a unit or departmentwide review. 

Factoring in time and resources available, the size of the department and the enormous 
scope of CLEAR, self appraisal is a difficult task. However, to create a truly innovative and 
successful enterprise, actually measuring the impact of the new systems is a crucial and 
necessary piece of the work. We look forward to the next year of evaluating CLEAR and the 
possibility of seeing impact data coming from the Department as applications  many still in 
their infancy  have had time to mature and produce such data. 


Policing Smarter through IT: 
Learning from Chicagos Citizen and Law Enforcement 
Analysis and Reporting (CLEAR) System 


The Chicago Police Department (CPD), in partnership with Oracle Corporation and the 
Police Executive Research Forum, is developing a state-of-the-art integrated criminal justice 
information system. This system  Citizen Law Enforcement Analysis and Reporting (CLEAR) 
 is a natural progression in the CPDs ongoing quest to police smarter. In its strategic vision 
for the future, Together We Can, the Department named the use of technology as a component of 
change. In the document, the CPD set forth its commitment to integrating new technology to 
support the broader goals of CAPS  enhancing our crime-fighting capacity, improving the 
quality of neighborhood life and developing a strong partnership with the community. This 
report describes the initiative and examines some of the launch procedures that lie behind it. 
Development of the CLEAR enterprise system is an ongoing process; the report covers progress 
and activities through the end of November 2003. 

Information Technology and the Police 

We begin by noting the national context in which CLEAR is being launched. The 
information technology (IT) revolution, although it started a half century ago, is just beginning to 
explode in the criminal justice world (see Coldren, 1996; Dunworth, 2000, for reviews). Police 
departments, in particular, are ripe for change, as they are positioned to utilize information 
technology to guide daily operations, analyze the effectiveness of tactics and enhance 
management accountability. The CompStat system in New York (McDonald, 2000), as well as 
data-driven law enforcement programs such as the Strategic Approaches to Community Safety 
Initiative (SACSI) (Coldren, et al, 2000), have given police a taste of what is possible. 
Unfortunately, as Dunworth (2000) notes, the present reality is that too few police departments 
are utilizing that capability effectively (p. 371). Police agencies the size of Chicago are awash 
with data. Each day they receive thousands of 911 calls, complete more than a thousand crime 
reports and arrest hundreds of people. However, although they enter thousands of data elements 
into their databases each day, it has been of little value because it cannot be extracted for reports 
and analyses. 

Today, data-driven policing is the buzz in law enforcement circles. Interest is driven in 
part by external demands for accountability, cost-effectiveness, staff right-sizing, performance 
measurement, and audits of their probity and procedural regularity (Chan, 2001). Police have 
also observed the impact of IT on internal business processes in the private sector  lower 
record keeping costs, greater flexibility and speed in decision making, better management 
control over product quality and more individualized relations with customers. They have also 
observed that the required computer hardware and software has become less expensive and more 
user- friendly. Many police agencies want to get involved and showcase new mission 
statements, business and marketing plans, and training programs that focus on information 
technology. However, too often there has been more talk than progress in implementing 
integrated data systems, the National Incident-Based Reporting System (NIBRS), partnerships 
with researchers, and crime analysis and forecasting. 


The CPD has a large-scale plan for harnessing the power of information technology. 
Beginning in June 2001, the CPD, with more than $35 million in support from Oracle 
Corporation and other funding sources, began an intense program of software development and 
testing. Oracle, a major business software designer, wants to demonstrate that recent advances in 
information systems can be tailored to help foster greater accountability, efficiency and 
effectiveness in the public sector arena. Oracle assigned more than 20 software developers to 
work on this project. The CPDs superintendent and deputies have made CLEAR a top 
organizational priority. Given this level of commitment and expertise from the participants, CPD 
management anticipates that IT will have a substantial impact on the Department, and ultimately 
on the community it serves. 

A review of the recent (25-year) history of automation projects in law enforcement 
reveals a glaring paucity of research examining the impact of these interventions on police 
organizations, bureaus or units and line officers. Despite the absence of good research on many 
topics, it is clear that automation in law enforcement has traveled a rocky road. Whether we look 
at records management systems, criminal histories, computer-aided dispatch, emergency 
response systems, crime analysis, Uniform Crime Reports (UCR) and NIBRS, the Internet, or 
systems integration and networking, most police departments have not yet adequately utilized the 
capability inherent in information technology. The list of reasons for this is long. With crime 
analysis, for example, obstacles to success include: the use of isolated individuals (usually 
civilians with limited knowledge of officer needs) to provide statistics to district personnel rather 
than encouraging widespread data analysis among supervisors and line officers; hardware and 
software problems; poor quality police data (missing or inaccurate information); insufficient 
funding for completing projects; inadequate training; and the attitude among police personnel 
that crime analysis is not needed for their job (Dunworth, 2000; Reuland, 1997). Often crime 
analysis is a special project that does not involve line officers in examining data and pays little 
attention to whether the product is actually used in the field. 

In general, our experience tells us that good ideas, good people and good technology are 
critical to making automation projects work effectively, but they are not sufficient to ensure 
success. Agencies consistently underestimate the human factors (individual, social and 
organizational influences) involved in implementing new initiatives  especially technology. 
Real people are involved, and they must interface with the equipment and software. These 
individuals must understand 1) what is expected of them; 2) how changing their behavior will 
benefit them personally and make their jobs easier; 3) how easy it will be to change their 
behavior with proper training, user-friendly programs, technical assistance, etc.; and 4) how these 
new systems will change the way their performance is evaluated. Instilling positive attitudes and 
expectations is important, but IT can be structured to produce results among the most reluctant 
employees. As Chan (2001) notes, systems with required fields, drop-down option lists and other 
quality-assurance mechanisms make it difficult for officers to bypass data fields, thus producing 
more frequent and thorough reporting. 

The CPD is well aware of the many obstacles confronting previous data systems projects, 
and has plans to overcome them. Department managers plan to introduce new systems and 
processes that will impact everyone in the organization  from the way officers do their jobs 


daily, to the administration and management of the agency as a whole. CLEAR will go well 
beyond New York Citys CompStat in providing accountability and monitoring of productivity at 
the unit and district levels. Equally important, CLEAR intends to reach beyond the organization 
to involve the community. As police organizations continue to redefine themselves in the era of 
community policing, understanding the consequences of new police capabilities for community 
residents becomes vitally important. 

Origins of CLEAR 

It is useful to understand the context under which the CLEAR project evolved. Oracle had 
been working with the CPD since 1996 on development of the Criminal History Record 
Inventory System (CHRIS), as well as on other information technology projects. CHRIS, in its 
initial release, had many limitations and was not well received by users. One complaint was 
typical of the reception of IT applications in many police agencies  that officers labored to input 
information, but they were unable to query the data to use it to their strategic advantage. It was a 
system that provided information to the bureaucrats rather than to field personnel. Detectives 
in particular complained that they were spending a great deal of time inputting data while not 
getting anything useful. CHRIS needed reworking, and the CPD believed the best way to 
accomplish this was to develop a menu-driven web-enabled system. 

When the CPD decided to roll up its sleeves and overhaul its information technology 
systems, it approached Oracle Corporation to present the concepts behind what would become 
known as CLEAR. At a spring 2001 Oracle/CPD meeting, the Department described CLEARs 
potential market value and reasons why Oracle would be the CPDs best partner for developing 
an enterprise system for law enforcement. Among the several points presented by the CPD were: 
1) Oracle would have full access to CPD operations; 2) the CPD would have ownership of its 
proprietary version; 3) Oracle would have ownership over the generic version, which could be 
marketed to other law enforcement agencies; and 4) the Department would support the 
partnership with in-kind services such as development staff, command staff and overhead. 
Additionally, both Chicagos police superintendent and the chief of Washington, DCs 
Metropolitan Police Department were present to show that there was multi-city interest in such 
a project. 

Within a week of the meeting, the CPD and Oracle were engaged in continuing dialog 
about CLEAR development. Underscoring Oracles enthusiasm about the project was its offer of 
funds for development purposes. However, the offer came with one stipulation: the project had to 
be contracted out by May 31, 2001  a date fast approaching. At the same time, a CPD deputy 
superintendent contacted the Police Executive Research Forum (PERF) to gauge its interest in 
partnering with the CPD to assemble a portrait of best practices in the IT field and to educate 
other law enforcement agencies about CLEAR and IT. PERF showed immediate interest in the 
CLEAR projects ideas and its proposed role. 

A second meeting took place between the CPD and Oracles first vice president. The 
negotiation began with Oracles offer of 90,000 consulting hours for CLEAR project 
development. After ensuing discussion about the projects need to be capacity building, Oracle 


added 500 hours of Oracle University training for CPD staff. The CPD reciprocated with an offer 
of $9 million from the Office of Community Oriented Policing Services (COPS) funding that had 
been allocated for technology. As the project approached the $40 million mark, a law firm was 
hired to handle the contract negotiation process. With City Halls help in the contract process, the 
agreement was completed in seven days, including several sleepless nights for CPD and Oracle 
staff. 

Description of CLEAR 

It is important to note that CLEAR is not a static system, but rather an evolving one that 
is open to feedback, refinement and redefinition when necessary. Each application within 
CLEAR undergoes a multi-stage development process involving conceptualization, joint 
application development (JAD) sessions between developers and police, subcontract negotiation 
when necessary, design/build, pilot testing and training. Applications are implemented only after 
focus groups have offered feedback about their usefulness; after internal marketing has taken 
place to elicit user interest and buy-in; and after field testing has determined that the application 
will work properly. If there are difficulties at any of these stages, the application team works out 
the problem before the application is made available in the field. Target implementation dates are 
set for the various CLEAR applications, but they are often adjusted when unanticipated issues 
arise. A major goal of CLEAR is to help users understand that the automation process has the 
potential to enhance their jobs, as opposed to viewing new procedures as another set of tasks 
being added to their already long list of things to do. 

The primary goal of CLEAR, in partnership with Oracle and PERF, is to design and build 
an enterprise information system  customized for the CPD, but adaptable for others  to 
fundamentally change the way criminal justice agencies conduct business. CLEAR applications 
will impact three major functional aspects: police management, criminal justice integration and 
community/business partnership. The goals for each include: 

Police management: Promote effective resource allocation; officer management and 
accountability; risk management and early warning; tactical and strategic planning; and fiscal 
accountability. The departmentwide management accountability process will make use of the 
new systems to address crime and disorder problems; react to emerging crime; optimize 
community involvement; and manage available human and material resources. 

Criminal justice integration: Enable unified strategies to reduce crime; eliminate 
criminal justice bottlenecks; increase accountability between criminal justice agencies; and 
provide a comprehensive picture of offender activity. Information sharing will involve other law 
enforcement agencies, prosecutors, the court system, the corrections system and other 
interventions, perhaps including non-criminal justice partnerships. The CPD has stated that it 
hopes the criminal justice integration component will give the CPD the capacity to police 
smarter; enhance partnerships with surrounding suburbs and cities; improve the quality of 
criminal justice information; improve employee morale; and reduce liability costs. 


Community/business partnership: Strengthen problem-solving capacity, conduct 
community-needs assessment; and allow for easy and convenient information sharing and 
intelligence gathering from the community. Currently the CPD partners with citizens through 
monthly beat community meetings and through District Advisory Committees in each of the 25 
districts. There will be increased effort to reach people currently not participating in these 
activities as well as an increased focus on meaningful problem solving and citizen involvement 
at beat community meetings. 

In sum, CLEAR provides for predictive resource allocation to deploy officers when and 
where needed; unprecedented availability of information for management analysis and officer 
accountability; shared problem-solving information for community policing partners; prepackaged 
information to support decision making at all levels of the Department; and provision 
of information integration to manage offender flow through the criminal justice system. When 
CLEAR is fully deployed, the CPD expects to enjoy reduced crime and safer communities; 
proactive community involvement; proactive resource allocation; decreased redundancy in 
administrative functions; and increased management and officer accountability. The various 
CLEAR applications will be available through the intranet at the CPD, the internet for the public 
and the extranet for other government agencies. 

CLEAR Applications and the Development Process 

Figure 1 shows the status of active CLEAR applications as well as the criminal justice 
integration project, the development and execution of which is integral to CLEARs mission. 
The following subsections of this report provide an overview of active CLEAR applications and 
the criminal justice integration project. Also briefly described are applications slated for future 
development. 

Information in this section was derived from 77 in-depth face-to-face interviews with 
application developers, trainers, implementors and users; from observations of focus groups and 
joint application development (JAD) sessions (13), training sessions and pilot tests (10) , 
meetings and application launches (78); and 275 telephone interviews with law enforcement 
officials. In addition, we also collected 251 officer surveys in the pilot-district prior to the launch 
of any new applications. Our data collection began in November 2001 and continued through 
November 2003. This report represents the most up-to-date information at the close of our data 
collection period. Funding for the continued study of CLEAR has been secured; and those 
findings will appear in a later report. 

For the readers clarity, listed below are applications comprising the CLEAR enterprise 
system. More detailed descriptions of each application and the criminal justice integration 
project are found in later portions of this section. 


Figure 1
CLEAR Module Status

Bar Graph Showing CLEAR Module Status 


CLEAR applications that impact police management: 

 Automated Incident Reporting Application (AIRA) 
 Automated Arrest Phase II 
 Crime Mapping 
 Digital Mug Shot 
 eTrack 
 Gang Arrest 
 Juvenile Arrest 
 Personnel Suite 
 Emergency Notification 
 IAD/OPS 
 Medical 
 Star Management 
 Tactical Response Report 
 Tuition Reimbursement 
 Rap Sheet 

CLEAR-related project 
 Integration of Criminal Justice Information Systems 

CLEAR applications that impact the CPDs working relationship with residents and the 
business community: 
 Community/Business Partnership 
 Automated Pawn Shop 
 Auto Theft Recovery 
 Traffic Crash Report Routing 

Applications slated for future development/implementation: 
 Enhanced Hot Desk 
 Organized Crime 
 Probation/Parole Information Integration 

The Development Process 

An application can pass through seven stages before being launched: 1) conceptual, 2) 
joint application development (JAD) sessions, 3) subcontracting, 4) design/build, 5) pilot-testing, 
6) training, and 7) implementation. 

At the conceptual stage, a module exists only as an idea that either allows for a more 
efficient and cost-effective means for accomplishing a CPD core function or enables the 
Department to use data to engage in a wider scope of law enforcement strategies. 


Each system being developed undergoes a series of day-long joint application 
development (JAD) sessions, often held over a period of several months and consisting of high-, 
mid- and low-level meetings. At these working sessions, people from the division for which the 
application is being developed  the eventual users  provide their knowledge of their units 
business operations. After each session, the Oracle team produces a process flow document. 
Flow documents are based on procedural information gleaned from the days activities, and they 
are reviewed at the next meeting. After three or four JAD sessions, a process model is drawn by 
the Oracle team and given to the divisions key personnel. After the unit or division management 
team carefully reviews and accepts the document, it becomes the foundation for the applications 
development. 

A number of applications under development require subcontracting with outside 
vendors to create or supply hardware or software for the various systems. The citys bidding 
process must be followed, usually necessitating proposals from several vendors. This process can 
hold up the development of an application, particularly if there are protracted negotiations about 
a contracts language. And, occasionally vendors realize that they cannot deliver the promised 
product, and the CPD must begin anew, further delaying the modules development. 

Applications in the design/build stage have progressed from a concept, with appropriate 
input, and are nearing a ready for testing mode. Usually Oracle development team members 
and CPD members have worked together on different aspects of the application to get to this 
stage. A significant outcome of this stage is the identification and detection of flaws and 
unexpected outcomes. Solutions are undertaken by the developers and additional input may be 
sought from potential users. At this stage role-based security set-up is developed; this determines 
who has access to the application. 

The pilot-testing stage is next and is conducted in a number of ways. Pilot-testing can be 
conducted at CPD headquarters, at a select stationhouse site, in a particular unit of the 
Department, or at the district-level involving many officers and their supervisors. The type of 
pilot-testing used depends upon the complexity of the application and the targeted user of the 
application. Pilot-testing may be completed in one day or over the span of a longer period. The 
test period is generally based on the complexity of the application and the number of users 
impacted by its implementation. At this stage, unanticipated problems or user-acceptance-test 
results can send developers back for fine-tuning of the application. 

Training also takes numerous forms, depending upon the complexity of the application 
and the number of potential users. Applications that are simply enhancements of existing systems 
may require nothing more than widely distributed explanatory memos or brief explanations and 
streaming video presentations at roll call. (Streaming videos are on-demand presentations stored 
on a network and can be viewed at any time in multiple locations.) Applications that are 
replacements of outdated and antiquated systems or that are entirely new modules require more 
intensive training and continued technical support. For such applications, trainers may spend 
several days out in the stationhouse providing individualized instruction to field officers. A 
training method known as train the trainers is often used at the CPD for large-scale instruction. 
For this, designated district officers receive training on use of an application, and they 


subsequently return to their units to train fellow officers. The CPD has created a special training 
team whose primary responsibility is to make sure that users of each CLEAR application are 
adequately familiarized with the module either prior to or at the time it is implemented. 

When an application reaches the implementation stage, just about all the bugs have been 
worked out, and it should be technically unflawed. The challenge at this stage is to create 
excitement and motivation among potential users in the environment where the application will 
be accepted. Users must be convinced that the new application will help them do their job more 
expeditiously. Support must be in place to work through early resistance and to get users through 
the technical learning curve. We know the least about this stage, as most applications are not yet 
fully operational. During 2004, many of the applications will reach this stage, and we will later 
report on their impact on the organization and users. 

Police Management Applications 

Automated Incident Reporting Application 

The first part of the Chicago Police Departments case reporting system is becoming 
computerized by a CLEAR module known as AIRA (Automated Incident Reporting 
Application). AIRA enables Patrol Division officers  the backbone of the organization  to 
complete case reports via portable data terminals (PDTs) or LAN-based work stations in any 
CPD facility. AIRA development is a very ambitious project with roots dating back several 
years, and over its gestation period, the projects scope, depth and timeline have increased 
almost exponentially. 

In March 2000 a lieutenant in the Departments Research and Development unit was 
charged with creating a basic, user friendly data entry system to be used by patrol officers to 
complete incident reports. The project manager recruited five police officers to work over a five-
month period to develop the business logic for such an application to the point where it could be 
handed over to a vendor for actual development of the application. A few months into the effort, 
a promotion for the project manager and a number of manpower shifts left only one of the five 
officers  a sergeant  to develop the applications logic single-handedly. As the new project 
manager, it became quite clear to the sergeant that the project had been put on the back burner, 
evidenced by the fact that the only support staff available to him consisted of interns from a 
nearby university and that he was continually being given assignments that took him away from 
the automation project. Development of the incident report system limped along for several more 
months, when an administrator was brought in to see the development of CLEAR to fruition. 

Goals for AIRA 

The Departments goals for automated case reporting are several and well-defined. AIRA 
is expected to simplify the reporting process; improve reporting accuracy, quality and 
completeness; free supervisory personnel from reviewing report minutiae; provide follow-up 
investigators with complete and timely information to improve case solvability; reduce the 
number of hours tied to report processing; and attain NIBRS compliance. 


The above goals are what the CPD expects from the automated case reporting 
application, but as part of CLEAR, AIRA is also expected to eventually interface with the 
Departments other key information applications and systems. Because AIRA is the first-line 
information collection system  the on ramp to CLEAR  it must successfully receive 
information from the citys automated dispatch system (PCAD) and, in the future, feed data into 
subsequent branches of the Departments case reporting system (digital mugshots, automated 
arrest and investigative followup), and transmit data to the data warehouse. 

Development 

Development of this CLEAR module differed from that of the others. As mentioned 
previously, the development team originally worked on the business logic aspect of the 
application with the idea of eventually turning the project over to a technical team to realize it. 
However, when the project was resurrected in summer 2001, despite the fact that Oracle 
developers were already beginning to work on several CLEAR modules, AIRA remained an inhouse 
project. Two officers with programming expertise joined the project manager, and AIRA 
began to take shape. Soon thereafter, another officer was brought on, chosen for her knowledge 
and experience with process mapping. Flow charts were created to make sure that screens were 
developed for every type of incident  screens that captured the rich data needed for crime 
analysis. Over the ensuing weeks, five officers from the district where AIRA pilot testing was 
eventually to take place were brought in to work with the AIRA team to provide insight and 
input of officers with current field experience. 

Because AIRA was not being developed by Oracle, formal JAD sessions were not held, 
but focus groups regularly provided feedback. In 2002, randomly selected tactical, wagon, beat, 
lock up and rapid response officers were brought together in three different groups to meet twice 
monthly for three months. In addition, four groups of captains and lieutenants were convened to 
offer suggestions about the application after seeing a demonstration. According to the 
development team, many members of each group were skeptical at the start of the process, but 
most left with positive attitudes about the application. These groups were also encouraged to 
complete a survey eliciting opinions, suggestions and concerns about AIRA implementation and 
were directed to an intranet site to do so. Other sources of input included officers from the 
Missing Persons Unit to ensure that appropriate information for these types of cases is included 
on AIRA; assistant states attorneys, who provided their opinions about the printed case report 
produced by AIRA; and CPD management, who attended periodic demonstrations of the 
automated case reporting module. 

During this process, a member of the team reviewed the various general orders that 
would be affected by AIRA and worked with individuals in R&D responsible for rewriting them. 
The officer also proposed the elimination of various procedures that, in practice, are not carried 
out despite being specified in the orders. More than 30 department general orders are affected by 
the advent of automated case reporting. 

Generally, reaching this point in the development of a CLEAR application would mean 
that after a period of programming, pilot testing and training, the application would be ready to 


launch. However, such is not the case for AIRA, because it must interface many different 
systems. A new operating system would need to be installed in each of the Departments portable 
data terminals (PDTs); complex adaptations would need to be made to the citys automated 
dispatch system; and message-oriented middleware would need to be designed to serve as an 
interface between AIRA and CLEAR. Vendors were sought for these projects, and though it was 
eventually decided that the original PCAD vendor would make the changes, much wrangling 
ensued between the vendor and the citys legal department over contract language. After looking 
for a vendor to design the message-oriented middleware and realizing that an outside firm might 
take up to a year to complete it, the recently- hired-but-soon-to-be-leaving Information Systems 
director of development decided to develop the middleware in-house. The middleware was 
eventually created by an outside vendors programmers working in conjunction with the AIRA 
team. While this was underway, an Information Systems project manager was working with an 
AIRA team member on a massive mapping project to document CLEAR structural changes 
needed to accommodate AIRA data. 

Field testing of the automated case reporting application was underway by early February 
2002 to see what problems emerged in practice and to find flaws in the logic. At first, several 
cars with AIRA-equipped PDTs answered calls in the district where the application was to be 
rolled out first. After a few weeks, a group of 10 to 12 officers, composed of AIRA team 
members and Data Systems trainers, began testing the application in a different district each 
week to observe the applications behavior in the citys various radio dispatch zones. 

Various problems were encountered in the initial field testing. Software and system 
problems included screens that did not appear during the report-taking process, occasional 
crashes and scattered dead spots  areas within a radio zone where dispatches are not 
received. Perhaps most troublesome was the limited battery life of the PDTs. Despite numerous 
promises from various vendors that their product would offer lengthier usage periods between 
charges, none offered substantial improvement. Batteries that hold the charge longer than those 
currently in the Departments PDTs are available, but their drawback is that they do not work in 
temperatures below 15F, making them an impractical choice for Chicagos climate. Also vexing 
are some PDT issues. In addition to being particularly bulky to carry around, the placement of the 
PDTs in the squad cars is problematic; screens are difficult to see in daylight and, at all times, the 
PDTs are inconveniently situated for ease of data input. Battery and PDT issues persist. Though a 
lithium battery that provides a longer usage period has been identified, the decision was made to 
switch to the new battery when new PDTs are purchased. And the mount problem remains a 
challenge, because the apparatus can not be moved due to air bag compliance issues. 

The complexity and sophistication of the AIRA project continued to increase, and the 
decision was made to bring in professional programmers, who were onsite by mid-April 2002. 
Within a month, another key decision was made  to change AIRAs platform from active server 
pages (ASP) to extensible markup language (XML), an operating system that became an industry 
standard during the course of AIRAs development. XML provides the CPD with greater ease 
with which to make future programming modifications. This platform change, however, delayed 
pilot testing in the test district once more. While the XML conversion was underway, Oracle 


programmers began working on the AIRA/CLEAR interface. During this period, the decision 
was made to change the site of the pilot test, and field testing stopped for several months. 

An equipment problem that was also addressed during this time was the fact that at any 
given time, 20 to 25 percent of each districts PDTs were out of service. Before AIRA is 
launched, the unavailability of PDTs is an inconvenience; afterward, it cripples the applications 
chances of succeeding. Contributing to the problem was the fact that there was no formal 
procedure for documenting what was malfunctioning on the unit nor was there one for tracking 
the status of units sent out for service. Members of the AIRA team met with representatives of 
the Motor Maintenance Division and the Office of Emergency Management and Communication 
(OEMC) and a repair protocol was devised. The new process included use of a newly created 
service request form and the establishment of a triage area in each Areas motor maintenance 
garage where technicians would diagnose the problem and either make repairs or send the units 
to the manufacturer. The new procedures were formalized in a general order. 

As it turned out, the delay caused by conversion to XML was immaterial; disagreements 
over contract details between the vendor and the citys legal department prevented changes to the 
citys automated dispatch system from beginning when expected, and then the vendor continually 
revised its timeline. When our 2002 report was released, completion of the dispatch system work 
was scheduled for January 2003, with pilot district testing in the field planned for the following 
March. The vendor actually completed the dispatch system changes in November 2003. This 
delay virtually split development of the automated incident reporting application into two distinct 
projects  LAN-based AIRA and mobile AIRA. The split was formalized in November 2003 
when a new project manager was named for the LAN-based application. The long-standing 
AIRA project manager was then able to focus his attentions on implementation of mobile AIRA. 

Implementation of LAN-based AIRA 

The original intention was to launch AIRA in the pilot district as a single application that 
would be used for mobile and onsite incident reporting. However, when the program was finally 
web-enabled and performing reliably  and a completion date for PCAD upgrades was nowhere 
in sight  the decision was made to roll out AIRA at the pilot districts front desk, thereby 
capturing data reported by people who came to the station to register an incident. 

LAN-based AIRA became operational on the second watch only at the end of July 2003. 
Two members of the training team were onsite during the second watch throughout the first two 
weeks as a resource to already trained users as well as to observe circumstances during glitches. 
Front desk personnel attended a two-day hands-on training session at the academy before they 
were given log-in access. 

During the first week of the pilot, officers filled out a form entitled Incident Report 
Evaluation after filing each AIRA report to document the experience. As time progressed and 
the application was found to be working reliably, they were only required to fill out such a form 
if there were some sort of problem to report. Two new paper forms were created for AIRA  a 


victim complainant signature form and a victim information notice. The first was created because 
there is currently no way to capture incident report signatures electronically; the other form takes 
the place of a tear-off section of the paper incident report that provides follow-up information to 
victims. 

While several needed fixes or enhancements were identified in the first weeks of the 
pilot, no significant difficulties arose. There was, however, a somewhat awkward consequence 
caused by the stalled PCAD system upgrades: officers had to log on to a stand-alone PCAD 
terminal to access an Records Division (RD) number; write the number on a piece of scrap paper 
and then return to the AIRA screen to input the RD number. Timely completion of the PCAD 
upgrades would have automatically assigned RD numbers to the incident report. 

By October 2003, AIRA was rolled out to the third watch in the pilot district, and by 
November, first watch desk personnel were using the application as well. Training was held for 
desk and relief personnel, again at the academy, and district gang and tactical team officers, who 
routinely complete incident reports in the station, later received training and joined districts 
users group. By early December 2003, 137 officers (51 patrol officers, 21 sergeants, four 
lieutenants, three captains and 52 gang/tactical officers) had been trained and were using the 
application. In addition, 20 civilian Help Desk employees received instruction on the system. A 
total of 23 two-day sessions were held, each held during the trainees regular watch. 

LAN-based AIRA will eventually be used in the citys Alternate Response (311) facility 
as well. Pilot testing is expected to get underway in 2004. The pilot will involve only a few call-
takers, but if the application works well in this environment, rollout to the remainder of the group 
is expected to occur quickly. 

Pilot District Training. As mentioned above, each training class was held over a two-
day period. Classes were limited to 20 participants. Each sat at a computer and trainers had a 
workstation in the center of the room that simulated the supervisors PC; when incident reports 
were completed and submitted, the trainers would receive and review them. A take-away users 
guide was placed at each workstation. Trainees log-on IDs become enabled to use the system at 
the training session, and use of the application is mandatory from the time they gain access to it. 
Another crucial detail that is handled at training is having trainees sign an affidavit that allows 
for their PC numbers to serve as an electronic signature. 

The first segment of training began with a video overview of the application, followed by 
a PowerPoint presentation that illustrated AIRA report routing and functionality, and provided 
background on NIBRS. A brief lecture on incident-based reporting followed, and then scenarios 
were presented, with officers being asked how to classify incidents occurring in them in terms of 
NIBRS rather than via the customary UCR hierarchy rule. New paper forms were discussed, as 
were aspects of Mobile AIRA, such as dispatch dead spots, squad car docking stations, battery 
life and the search for new PDTs. The remaining three segments of the two-day training involved 
hands-on AIRA practice. The beginning of the hands-on portion had officers working screen-by
screen while trainers observed over their shoulders to provide assistance or answer questions. 


After the first run-through, participants were given paragraph-long incident scenarios, and with 
these they were to create an incident report. The scenarios became increasingly complex as the 
training progressed. As officers completed their reports, they submitted them to the trainers for 
approval (as they would to their supervisors in actual practice). Trainers reviewed the reports and 
either accepted them or returned them to the officers for corrections. 

After the first two-day training session concluded, the AIRA training team, made up of 
eight officers, convened to review their impressions of its strengths and weaknesses. They 
considered not only the curriculum, but the pace of the presentation, the materials, room setup 
and the like. Adjustments were made prior to the next session, and they continually tweaked and 
upgraded the curriculum based on their observations and experiences. Scenarios were upgraded, 
and eventually one was presented in video form. 

Implementation of Mobile AIRA 

Unlike the other CLEAR applications that are launched when the program has been 
developed and tested, the launch of mobile AIRA is dependent on a range of additional factors, 
technical and otherwise, that must align before it can be fully implemented. In our report last 
year*, we mentioned that the implementation of automated incident reporting in Chicago still 
faced several significant challenges  bandwidth capacity, the magnitude of training and 
facilities limitations  but none of these had a direct impact on the Departments inability to get 
the mobile pilot test started before late November 2003. Instead, the major impediment to mobile 
AIRAs launch had to do with completion of PCAD programming changes. These changes were 
handled by the vendor that created the citys automated dispatch system, and in spite of ongoing 
efforts, the vendor continued to miss self-imposed deadlines, mainly caused by programming 
complications. Initial reports are that the dispatch system is working well, and incident reports 
are being completed and transmitted without problem via PDT. With PCAD pilot testing 
underway, the AIRA development team is able to focus its attentions on the above-mentioned 
challenges. 

* accessible at http://www.northwestern.edu/ipr/publications/policing_papers/years8&9.pdf 
beginning on page 90. 

The new PCAD software not only interfaces with AIRA, but it provides new screens and 
functionality for field officers. The new version is much more user-friendly and its Windows-
type graphical-user-interface (GUI) screens are easier to view than the outdated black and green 
no-frills version currently used. The new PCAD application will prevent work-in-progress from 
disappearing from the screen when event updates appear (correcting a long-standing vexing 
situation) as well as allow officers to move back and forth between applications via a tool bar 
that remains visible at all times. Among the other new features are touch-screen technology for 
easy access to common functions formerly requiring typing of lengthy command lines; storage 
capacity for up to 100 sent and received messages; automatic 90-day event histories for 
dispatched addresses; and e-mail and enhanced car-to-car messaging. 

Mobile AIRAs pilot testing will lead to a soft rollout, meaning that the automated 
incident reporting application will be first introduced on one watch in the pilot district. When 
AIRA is determined to be operating effectively under those circumstances, additional watches 



will begin using AIRA. Once all officers in an entire district are successfully completing 
automated case reports, another district  probably one sharing the pilot districts radio zone  
will begin the step-by-step deployment process. In addition to ensuring that sufficient attention is 
given to training and equipment issues, this paradigm will allow the AIRA team to precisely 
identify the point at which the bandwidth  a persistent concern  is overwhelmed, should that 
happen. 

Officers will be able to use the new PCAD with a minimum of training. Two members of 
the AIRA training team will go out to the pilot district to present train-the-trainer instruction. 
Three officers per watch will be prepared to teach others in their districts to use the new PDT 
dispatch screens, and they will be the go-to people for questions. A PowerPoint presentation 
that provides an overview of the new system will be shown to officers at roll call. 

Bandwidth. A question that may be unanswerable until citywide implementation gets 
underway is whether the narrow-band spectrum assigned to public safety agencies can adequately 
accommodate a large-scale wireless communication system such as AIRA. One AIRA team 
member explained the problem in very understandable terms: home dial-up modems are 56K. 
What were dealing with is only 9K, and the pipe is small. The development team is doing what 
it can to hold to a minimum the amount of data the system will be handling at any given time  
for example, much planning has gone into determining the least amount of time that a report can 
effectively remain available via the PDTs before being transmitted to CLEAR. 

An experimental wideband communications system exists that might be a solution to the 
Departments limited bandwidth, and the AIRA team has been trying to set up a pilot test in one 
of the CPDs 25 districts. Known as Greenhouse, this technology would increase bandwidth from 
9.6K bit/sec to 460K bit/sec, ample for transmitting incident report data but also allowing for 
wireless transmission of mug shots, live audio and video, drivers license photos and other data 
that would be of assistance to officers in the field. Greenhouse has performed successfully for a 
Florida jurisdiction whose force size and topography are not comparable to Chicagos. 
Consequently, the vendor agreed to set up a test site in the city, but at the time of this reports 
writing, full scale testing had not gotten underway, because the contract is still awaiting City 
Council approval. 

Successful results with Greenhouse technology in Chicagos urban setting will not 
provide a quick solution to the bandwidth problem, however. The FCC, which regulates and 
licenses radio spectrum use, has not issued a permanent license for Greenhouse, nor has it 
announced any intention to allocate this wideband spectrum for use by wireless communication 
systems, making it unwise for the CPD to invest in such technology. The Department must 
proceed as though Greenhouse may never happen. 

Another potential solution to the Departments bandwidth limitations could come as a 
part of a soon-to-be announced broadened partnership between the CPD and the Illinois State 
Police that will combine ISP and CPD systems into one database, resulting in statewide 
uniformity in incident, arrest and follow-up investigation reports. When this partnership begins, 


the ISP will be making available to the CPD 10 Illinois Wireless Information Network (IWIN)
equipped patrol cars, widening the AIRA pilot and testing IWINs capacity to transmit incident-
report-size packets of information. 

Systemwide training. Large-scale training for the entire Patrol Division on a totally new 
system is a herculean feat. Nearly 10,000 people must learn to manipulate a new computer 
program to perform key functions with as little disruption as possible to the districts daily 
operations  without overtime. Two days of training is anticipated for use of AIRA because of 
the importance of accurate case reporting, combined with the expanded data collection and new 
technology associated with the new application. It is as yet undetermined how many officers will 
trained at one time, simple multiplication indicates that training will be underway for quite an 
extended period. 

Because training is key to AIRAs success, a sergeant was brought on to the development 
team to devise AIRA modules for in-service and new recruit training. In addition the sergeant 
worked with the Information Systems training team to identify the most effective instruction-
delivery option for field training. A committee composed of representatives of the training 
academy, Information Systems trainers and the AIRA team met on an ongoing basis to share 
ideas and coordinate efforts. The sergeant also worked with interns from a nearby university to 
create an AIRA user guide, and the AIRA training team has been updating and enhancing it as 
needed. During this reporting year, the sergeant was promoted to lieutenant and left the AIRA 
team, and the officer who then headed up the training group ably guided curriculum development 
and delivery thereafter. 

Facilities. As is the case with deployment of any CPD program requiring new equipment 
or workstations for district personnel, facility limitations must be overcome. The CPDs 25 
district stations roughly fall into three categories: new, modern and very old. Accommodating 
needed wiring and workstations is not a problem for the Departments newest stations, and the 
modern facilities generally pose no major challenge. However, approximately one-third of the 
citys district stationhouses are antiquated  some even unable to accommodate new wiring for 
additional fax lines. 

There are plans to replace many of these old facilities; however some potentially will not 
be ready when it would be logical to launch AIRA at that site. There are both old and new 
stations in each Area, and undoubtedly at least a few old and new stations share radio zones. 

Infrastructure surveys were conducted during July 2002 to gauge the preparedness of each 
facility for the upcoming roll outs. Members of the AIRA team visited each district station, 
looking room by room to assess its needs, checking for ample space for additional computers and 
to verify whether the stationhouse has adequate wiring and data port terminals (internet 
conductivity ports). Not surprisingly, this effort revealed that the oldest stations would need a 
considerable amount of rewiring, data port installation and minor remodeling for housing new 
hardware. Each facility, old or new, needs additional computers. 



The Future of AIRA 

With LAN-based AIRA running smoothly and pilot testing of the mobile portion 
underway, the foundational blocks of this groundbreaking application have been laid. However, 
the remaining challenges  bandwidth, battery life, stationhouse infrastructure and training 
logistics  loom large. 

However, if these matters are systematically and satisfactorily resolved, the CPD will 
perhaps be in position to eventually provide its field personnel with the ability to relay pictures 
and sketches to other cars in the field; transmit fingerprints; access crime analysis information at 
a crime scene; and attend roll call remotely while patrolling the beat. 

Automated Arrest System Phase II 

The first phase of the CPDs Automated Arrest System, launched in 1998, was a client-
server application used by lockup personnel to enter prisoner intake information during 
processing. Phase II, which is currently being piloted in one district, shifts this function to 
arresting officers, allowing them to process the arrest via bolted-down ruggedized laptop 
computers in station interview rooms. Data entered by arresting officers interfaces with the 
Departments digital mugshot application (described in a later section) and automated fingerprint 
identification system (AFIS), allowing lockup keepers to photograph arrestees as soon as they 
enter the lockup, resulting in real-time records. In addition, after lockup keepers post bookings, 
desk sergeants and watch commanders can approve the bookings or subsequent releases online. 
The Automated Arrest system produces a two-part arrest report: the first contains the data 
entered by the arresting officer, while the second compiles information inputted by the lockup 
keeper, desk sergeant and watch commander as the arrest processing progresses. Information 
relating to the arrestees positive identification is also added to this part of the report. These two 
reports constitute a complete arrest processing package. 

Automated Arrest Phase II is web-enabled and provides a variety of functions, as seen on 
the menu shown in Figure 2. The application has electronic arrestee-detainment-tracking 
capability and can provide various reports for command staff on an immediate and per-request 
basis, such as listings of arrestees on hold at the time of the report generation. History reports 
can be generated by a host of parameters, including date ranges; officers requesting detainments; 
and number of detainees by detention facility for a given time period, to name a few. Numerous 
customized reports will be obtainable using available data captured through this process as well. 


Figure 2
Automated Arrest Menu
Image of Automated Arrest Menu

Development 

Development of this application predates the creation of the first phase of Automated 
Arrest, the conceptual base of this system. More than 11 formal JAD sessions composed of 
representatives from 10 internal CPD units and several outside agencies were held from July 
through December 2002. Ongoing input was provided by assistant states attorneys and members 
of the Departments Legal Affairs Unit. 

Some of the functions that resulted from these sessions are as follows: 

 arrest reports and rap sheets include arrestee mugshots 
 an executive criminal history report can be created showing all previous convictions, bond 
forfeitures, and arrests with open court dispositions helps watch commanders and state's 
attorneys make decisions about upgrading or downgrading arrestee charges 
 watch commanders can upgrade or downgrade charges on-line prior to final approval 
 desk sergeants can add court or bond information directly to arrestees record when an 
arrestee is bonding out or is being sent to court. 
 lockup keepers can add booking information to arrest reports before posting the booking 
 detectives can to request arrestee holds electronically. 
 arrestee interviews, arrestee visitors, and arrestee movement between CPD facilities and 
outside agencies can be logged electronically. 
 notations can be made about decisions to release arrestees without charges 
 spell check is available for checking narratives 



Throughout 2003, policy-making sessions were held at least monthly to deal with issues 
affecting general orders and procedures that emerged as testing progressed. 

Implementation 

In late July 2003, pilot testing of the web-enabled Automated Arrest application began in 
one Chicago police district. A considerable amount of preparation was needed prior to the 
rollout. A facilities assessment was done to ensure that all infrastructure upgrades would be 
completed by the rollout date. Furniture and computer equipment would need to be ordered, as 
interview rooms have historically been quite barren. Everything added to these rooms needed to 
be bolted down  furniture and computer hardware  for the safety of interview room occupants. 
Contractual matters even entered into the rollout date equation: officers working the midnight 
shift must have seven days notice before their hours can be changed; accommodating such a 
change for third watch officers to attend training ended up being a final determinant of the go 
live date. 

With so many disparate factors needing to come together at the same time, the pilot 
district rollout date was pushed back several times. Rewiring was completed in sufficient time, 
but furniture and hardware procurement delays were suffered. However, as each problem arose, it 
was addressed and resolved. One unanticipated difficulty is that the mounts did not meet the 
order specifications. Retrofitting took place onsite, and the vendor was asked to make permanent 
adjustments for upcoming roll-outs. When it was finally launched, the Automated Arrest 
application worked remarkably smoothly. Members of the training team were at the station 24 
hours a day from the moment the application was implemented, and they remained there for 
several weeks. Interestingly, the first arrest processed  characterized as historic by CLEARs 
executive administrator  was a very complicated one, allowing the applications manager and 
developers to observe the program processing a high number of variables. A glitch that emerged 
at the watch-commander-approval level was easily amended once its cause was identified. The 
next problem that surfaced in a later arrest was found to be caused by operator error, and the 
importance of clicking on apply rather than save before inputting warrant information 
became a training point. 

Though the application experienced a minimum of technical problems, those that did 
arise often necessitated convening policy-decision-makers to determine the best way to 
circumvent the difficulty. For example, transmittal of court packages (paperwork related to a 
case) went smoothly, however states attorneys were a little put out when they realized that the 
new computer-generated forms necessitated a signature on each sheet, while the manual 
multipart forms required that they sign only once. At a subsequent meeting administrators agreed 
that photocopies of a signed original would suffice. Network connectivity problems with the 
laptop computers also cropped up, and the vendor was contacted to rectify them. 

As district personnel became increasingly knowledgeable and comfortable, training 
support staff gradually cut back their onsite presence and eventually turned the responsibility 


over to the recently trained Help Desk. When Automated Arrest Phase II had been in use in the 
pilot district for nearly a month, a debriefing meeting was held with key users of the system, the 
Automated Arrest project team, representatives of Patrol Administration and the pilot district 
commander. A small delegation from the Illinois State Police sat in to gain insights as potential 
future users. At this meeting a few aspects of the application that needed enhancing or further 
development were suggested by the commander, based on user feedback. The tone of the meeting 
was quite positive, with the pilot district commander giving a B+ to the application itself and an 
A to training and support. The commander also had a concern after observing district personnel 
actually processing arrests via the laptops in the interview rooms: officers  especially those with 
large hands  had a tendency to use ball point pens on the computers touch screens. This 
practice would predictably puncture the laptop screens in short order. The decision was then 
made to order a healthy supply of plastic styluses. 

Ongoing meetings such as those discussed above and others that identified highly desired 
enhancements resulted in an upgraded version that provided new functionality. This version was 
launched in November 2003. Additional hardware needs also became apparent during the initial 
pilot period, and by November a new server was brought in to speed up printing of lengthy arrest 
reports, which were taking up to 35 minutes to produce. 

Two months after the Automated Arrest pilot launch, the application was deemed to be 
functioning sufficiently well to get the wheels in motion for rolling it out to a nearby district. 
Tasks were assigned to meet the various infrastructure, furniture and hardware requirements. 
Though the application was amply tested for implementation in the next district, procurement 
delays and complications routinely postponed the launch date. When this report was written, 
Automated Arrest was expected to be implemented in the next district in early January 2004. 

Pilot District Training. Mandatory in-depth training is required for Phase II of the 
Automated Arrest application. Because supervisors must learn the arrest process as well as the 
approval procedures that pertain to their position, they undergo two days of training, while 
officers require only one. For each training session, the first days instruction is composed of 
both groups. Supervisors return the following day to complete their curriculum. 

Approximately 15 people comprise a training class, which is held in a computer lab at the 
academy. The room has two sections of four rows of tables, with three PCs on each table. A 
screen at the front of the room displays the various Automated Arrest screens, and trainers use a 
laser pointer to clarify certain concepts. The session begins with basics, including how to log on. 
A Quick Guide and another cheat-sheet packet are distributed to trainees to aid them when 
using the system back at the station. 

Officers at training are introduced to a new paper arrest form that must be used if the 
Automated Arrest application becomes unavailable because of maintenance or a system shutdown. 
This is followed by a review of the applications screens. Particulars, such as the need for 
officers to save work as they go along is stressed. Trainees learn how to go about re-accessing 


their work when they unexpectedly get called away from the computer for more than 25-minutes 
(at which time the system times out), and they learn about how the various records numbers 
are electronically assigned. As screens are reviewed field by field, trainers explain the fact that 
the application requests more descriptive information than did the old paper report, which leads 
into a NIBRS overview. To stave off complaints about increased data inputting, trainers point 
out that the application populates fields with information that is repeated throughout the report. 
One trainer explained it succinctly: if youve entered something twice, you missed a shortcut. 
After the lecture portion of the training, officers were provided with scenarios, and they began 
gaining hands-on experience with the new application. 

At the first few sessions of Automated Arrest training, participants were warned that 
because the application was newly implemented, they might encounter something that the system 
could not handle when they began entering their own scenarios. One trainer presented it as a 
challenge, suggesting that they try to trip up the system. That way, according to him, bugs would 
surface and be quickly remedied. 

The second half of the first day of training was focused on users gaining experience on 
every one of the applications screens. Participants were presented with pre-conceived scenarios, 
and they also were given ample opportunity to experiment with the most complex set of 
circumstances they could imagine. At the end of the first day, those who completed their training 
were told that support staff would be available onsite 24/7 until the application was stabilized 
and users reached an acceptable comfort level. The day-two curriculum for supervisors was 
delivered in a similar manner. 

The Future of Automated Arrest Phase II 

The focus for Automated Arrest Phase II is to roll the program out to the remainder of the 
city. In addition to the equipment procurement hurdles that must be overcome, circumventing 
infrastructure problems in the citys older facilities will take some very creative thinking. For the 
present, the application itself is considered fully developed, though enhancements and upgrades 
will certainly come about as needed. 

The next Automated Arrest development push will be criminal justice integration-related. 
Numerous changes will have to be made to the program to accommodate smaller Cook County 
agencies now participating in the criminal apprehension and booking system (CABS) that have 
expressed interest in using the Automated Arrest system. The majority of the changes center 
around approval procedures and screens, because in small agencies the entire arrest and booking 
process is often handled by one individual, requiring no supervisory approval. A funding source 
for such changes will need to be located before development can begin. And, if I-CLEAR 
(discussed elsewhere in this report) becomes a reality, this portion of the project might take a 
new direction or become unnecessary. 


Crime Mapping 

The CPD has had crime mapping capability since 1994 when it launched its Information 
Collection for Automated Mapping (ICAM) system. A public version, known as Citizen ICAM, 
became available in 2000. ICAM relies on a geographic information system (GIS) to represent 
data in the form of a map, enabling officers to perform crime mapping and analysis, while 
Citizen ICAM provides the public with graphical representations of crime in specified areas. 
Both versions allow users to view crime activity in map, chart or table form and to search crime 
activity by beat, school, intersection, address or type of crime. Exact addresses of incidents and 
information pertaining to victims or potential suspects do not appear on Citizen ICAM; such 
information is provided, however, on the Departments version. 

ICAM reports provide many invalid addresses20 percent or more, according to a CPD 
informant. These inaccuracies exist because, historically, officers filling out case reports have 
had difficulty identifying actual addresses at incident locations (vacant lots, for example) and 
have resorted to guessing. The cumulative effect of this conjecture has resulted in a system with 
many erroneous incident locations. To provide more accurate mapping, the CPD is retiring the 
police version of ICAM and developing a new crime mapping application that will have a Map 
It feature via the data warehouse and will eventually be available on the portable data terminals. 
The new crime mapping application will also include an upgrade of Citizen ICAM. 

Development 

In September 2001 the Department hired a civilian with 18 years of GIS experience to 
manage the development of its new mapping system. The manager subsequently hired a senior 
programmer, and a CPD officer joined the team to help with ICAM maintenance and repair. The 
teams primary goal was to create a functionality within the data warehouse  to be known as 
Map It  that provides officers with a graphical method of searching for criminal patterns. 
Development involved three distinct activities. The first consisted of updating and correcting 
ICAMs geographical data. ICAMs operating system did not allow modifications to be made to 
its base information, so an automated extraction program performed the laborious process of 
removing inaccurate data from the existing ICAM application, correcting it and translating it into 
the new mapping application. By early March 2003 the automatic extraction program had 
completed geocoding 17 million records and the development team began testing the records in 
the data warehouse. The second important development activity entailed locating a geocoding 
application that validates geographical information as it is entered to ensure that officers in the 
field could only enter accurate addresses. An outside vendor developed such an application for 
the CPD. Adding enhancements and functionality to the new mapping application was the third 
development activity. However, this portion of the applications development has been put on 
hold and may never be fully developed. 

By the end of April 2003 the Map It functionality via the data warehouse was 90 
percent developed and the fixing of inaccurate addresses and geocoding of older records was 



concluded even though some addresses were irreconcilable. Map It functionality allows CPD 
users to run arrest, case, gang contact card and property searches by such parameters as years, 
months, days, hours, beats, districts, type of crime, etc. Returned records are displayed by central 
booking (CB) number and can be selected for mapping on a base map (similar to a Mapquest 
representation) or an aerial photo map. With this application 50 locations can be mapped in 
approximately five to10 seconds. Erroneous addresses are not represented graphically, but they 
are noted in the search results so users can see what fields are missing and why the address was 
invalid. The new mapping applications data dates back only to 1999, and all query requests are 
displayed on a 2002 street map of the city of Chicago. Though the street map is refreshed 
regularly, building updates, which come from a department outside of the CPD, are not updated 
as routinely. 

A zooming tool for gathering more detail on specific buildings and intersections is 
available, as is as a display tool that shows 500 foot boundaries around certain types of buildings 
(CTA facilities, schools, hospitals) for analysis purposes. Vanity addresses or high profile 
buildings (Sears Tower, Daley Center, Shedd Aquarium, etc.) can be quickly located via a drop-
down menu entitled vanity buildings. This function allows users to find a specific location 
graphically without needing to know the exact address. Up to sixteen distinct icons can be 
displayed on a map, depending on the querys results. For example, car thefts have a different 
map icon than do home burglaries or assaults, and there is a legend that explains all the new 
symbols, as shown in Figure 3. The final 10 percent of the Map It development, completed in 
early fall 2003, involved finalizing these icons. Icons are interactive, and when users scroll over 
an icon with the mouse, a mug shot of the arrestee appears in the upper right hand corner of the 
screen. Additional user options include a graph function that displays simple bar graphs of the 
selected results and an export function that allows query results to be downloaded into an Excel 
spreadsheet for further graphing/chart analysis. 

Figure 3
Vehicle Thefts Map
Image of Vehicle Thefts Map



Implementation 

The original target date for the deployment of the new mapping system was revised from 
March 2003 to May 2003. However, this May deadline was not met because the roll out of the 
mapping application became dependent on the move of the data warehouse to a new server. 
Originally the move of the data warehouse was scheduled to be completed in May 2003, but has 
been put on indefinite hold. An unintended consequence of this delay has been the postponement 
of development/enhancement of Citizen ICAM. Eventually Citizen ICAM will be updated/linked 
to the new data warehouse mapping program using similar software, but it will be separated by a 
firewall for security reasons. 

These delays have been quite frustrating for those working on the crime mapping 
application. A Band-Aid solution  implementing the small portion of the mapping 
applications capabilities that are not dependent on the data warehouse server move  was met 
with little enthusiasm, because there would be no icons and no mapping capability of property 
and auto thefts, gang contact cards or suspect data by beat. Some CLEAR developers are 
concerned that the server will not be moved any time in the near future, which would effectively 
stop the implementation of both the mapping and auto theft application (discussed elsewhere in 
this report), each of which has data linked to the tables that will be moved with the data 
warehouse. In November 2003 the mapping application team proposed taking responsibility for 
the data warehouse server to enable them to go forward with the mapping applications rollout. 
However, at the writing of this report, CPD administrators had yet to decide on a course of 
action. Some feel that without a strong push from the assistant deputy superintendent or the 
deputy superintendent, the data warehouse server move will continue to be delayed. 

Another problem stemming from the long delay is that ICAM is still being used by CPD 
officers. ICAM relies on Unified Crime Reporting (UCR) tables that are not in sync with data 
warehouse information, and as a result are inaccurate and not up to date. Officers have been 
instructed to only use the data warehouse for arrest and processing decisions, but some are 
ignoring these instructions and using ICAM, which could result in cases being based on incorrect 
information. ICAM is not scheduled to be retired until the new data warehouse mapping 
application goes live, thus this problem may persist. 

Pilot Testing. Testing is expected to take place in a technology-savvy district over the 
course of a month to allow for extensive testing and to gather feedback for final edits and fixes. 
However, due to the lengthy delay it is possible that the mapping application will go live 
without any pilot testing, and enhancements and improvements to the active application will be 
made at a later date. 

Training. The academy will be the likely site for retraining of current officers, while new 
officers will learn to use the application as part of their curriculum. Originally it was thought that 
the training would be a part of the Automated Arrest application training; however, because of 
the delays to the mapping program the coordination of training for the two applications sessions 
seems unlikely. 


The Future of Crime Mapping 

At the time this report was written, the mapping applications future was completely 
dependent on the data warehouse server move. When this is accomplished, the application will 
be available to all sworn members of the CPD. Significant resistance to the new application is 
not expected. The system will be accessible via the data warehouse, so optimal network speed is 
critical for the success of the new system; slow retrieval times will definitely discourage users. 

Digital Mugshot 

As recently as 1994, the CPD relied on Polaroid cameras to capture mugshot photographs 
of offenders. In 1995 the CPD updated its mugshot system with digital cameras at a cost of $3 
million. The system required large steel stands to house the cameras, jumbo flashes, storage 
boxes for each camera-dedicated PC and elaborate data storage techniques. The system provided 
quality photos but only captured minimal data for reporting. The 1995 system also required 
mugshots from individual districts to be captured on an area server that handled four other 
districts mugshots, eventually routing them all to a central server at CPD headquarters. The 
systems intended life span was approximately four years, and by late 2000 it had become very 
unstable, resulting in frequent crashes and time-consuming searches. Other problems generated 
by the system included omitted mugshots, Central Booking (CB) numbers not matching the 
correct suspects mugshot and lockup keepers making too many processing mistakes. According 
to a CPD insider, the 1995 system was barely getting by  limping along. In 2001 it was 
determined that the 1995 system had outlived its usefulness and was beyond repair, requiring the 
CPD to begin the process of looking for a new mugshot system. 

The Departments Digital Mugshot system enables detectives to create virtual line-ups, 
creates an interface to keep sex offenders mugshots up-to-date and upgrades mugshot data 
capture processes in the Departments lockups. A digital mugshot, as seen by lockup keepers, is 
shown in Figure 4. 

Figure 4
Digital Mugshot
Image of Digital Mugshot



Development and Implementation 

In March 2001, after much deliberation, a local company was selected by the CPD to 
conceptualize and create the new mugshot system. While this companys bid was somewhat 
higher than that of other vendors, the Department decided to contract with this company because 
it met all of the CPDs hardware, software and technical support requirements. Initial project 
management by both the CPD and the vendor was not very strong and, as a result, the project 
progressed slowly for the first six months. A change in management resulted in new life and 
direction for the digital mugshot system. The vendor conducted interviews to determine the 
CPDs needs and to identify units within the CPD that would benefit from access to the new 
Digital Mugshot system. In addition, a civilian chief database analyst from the Departments 
Information Systems Division was appointed to head up development of the new system. The 
new mugshot manager assembled a four-person support team and joined the vendor in finalizing 
the development plan and testing new hardware. 

The Departments two main hardware needs for the new mugshot system were digital 
cameras and new servers. The vendors first camera recommendation was rejected by the CPD, 
so a search began anew for a digital camera that would meet the Departments specifications: 
high mega-pixel count for clear, crisp pictures; zoom features; and automatic picture downloads 
to the CPDs data warehouse. By April 2002, the vendor identified a camera with the required 
specifications. However, a three-month pilot test revealed some of the cameras drawbacks  it 
required the lockup keeper to look through a viewfinder, snap the picture and then check picture 
quality via the attached computer. The CPD wanted a camera that provided a pre-shot image on 
the computer screen so all picture-taking steps could be completed from the computer stand. By 
July 2002, the vendor was close to endorsing a camera that could provide a live image and be 
controlled from the computer workstation. The other hardware requirement  a server system 
capable of handling a large volume of pictures  was met by the Departments purchase of two 
servers. These servers have eliminated the need for area servers and allow each lockup to send 
mugshots directly to CPD headquarters. 

Pilot testing of the digital mugshot system continued with a live-image camera through 
spring and summer 2002. By the end of that year, the CPD decided to go with the following 
hardware package for each lockup: a computer to run the new mugshot system, a digital camera 
with a zoom lens and a swivel head to hold the camera unit on the existing camera stand. The 
final setup allowed for nearly instantaneous live image feed and capture. 

While lockup personnel are the primary users of the new Digital Mugshot System, the 
system also has separate functionality for various users including the Detective Division, the 
Identification and Graphic Arts Sections, Administration, and the Sex Offender Registration Unit. 

Mugshot System Users. Main users of the digital mugshot system are the Departments 
lockup keepers, though all officers have been given photo capture roles that allow them to 
substitute for lockup keepers and process offenders as needed. After arrest report data is entered, 
a central booking (CB) number is generated and the data is sent to the mugshot system computer. 


Lockup keepers can capture up to six mugshots with a few clicks of the mouse. Images 
are captured in the following order: front, side and up to four closeups of tattoos or scars. The 
cameras zoom and focus capabilities are especially helpful for photos of tattoos and other 
identifying features. Acceptable images are saved and attached to offenders permanent record. 
Copies of the mugshot are then printed out at the districts front desk. One copy can be attached 
to the arrest report and another can be kept in the lockup as a quick visual reference. The print 
copy was an important upgrade requested by lockup keepers to ensure that the correct prisoner 
was being released or bonded out. 

Several safeguards were designed to increase the likelihood that mugshots will be taken 
and processed correctly. An active arrests pending screen shows the order of prisoners waiting 
to be photographed; pictures must be taken in this order. To deviate from this, lockup keepers 
must obtain an override from a supervisor. For example, an unruly prisoner might prevent a 
lockup keeper from taking a mugshot and the lockup keeper will need move on to process other 
prisoners. In this case, the lockup keeper, having gotten the override or bypass  from a 
supervisor, can skip over the problem prisoner. When the problem prisoner is ready to have a 
mugshot taken, the supervisor must approve an un-bypass which allows the lockup keeper to 
take the prisoners mugshot without needing to reenter all of the arrest information. 

The Detectives main menu presents query and line-up options. The query function 
allows detectives to search for offenders by CB and identification record (IR) number, sex 
offender registration and social security number. It also can query by demographic information, 
personal features (hair color, height, weight) or date of offense occurrence. Successful queries 
yield the offenders name, CB number, criminal history, demographics and mugshot image. By 
clicking add to line-up (available only to detectives) the offenders mugshot is added to a 
virtual line-up. A query to find similar-looking offenders fills out the rest of the line-up. The 
system can find mugshots of hundreds of offenders in the CPD database who closely match the 
offenders gender, race, hair color, height and weight, and can insert up to nine photos in a 
lineup. When detectives are satisfied with the line-up, they can print up to nine mugshots entirely on 
one page. Once saved, the line-up is date- and time-stamped. If the line-up remains unchanged, it 
will forever be saved with this time stamp. The line-up can be recalled and changed, but any 
saved changes generate a new time stamp. 

Authorized employees of the Identification Section (Ident) have the ability to query 
photos and delete them if necessary. If, for example, a lockup keeper takes a mugshot of a 
prisoner with an incorrect CB number, the record is fixed by Ident personnel. Graphic Arts is 
responsible for all field mugshots; usually this entails personnel going to hospitals, taking 
mugshots of wounded prisoners and scanning them into system. 

Convicted sex offenders in the city are required by law to register with the CPDs Sex 
Offender Registration Unit. The Department, in turn, is required by law to keep mugshots and 
addresses up-to-date and available for the public. The new digital mugshot system provides the 
interface for the CPD to maintain sex offender mugshots. 


Installation. A mugshot system installation team went to each of the 25 district stations 
and the Sex Offender Registry (at CPD headquarters) to set up the hardware (computer, camera, 
lens and mount) and train lockup keepers, detention aides, front desk supervisors and Sex 
Offender Registry personnel. The carefully assembled installation team consisted of the vendors 
representative and technical expert, a seasoned CPD lockup keeper who had been involved with 
the new digital mugshot system since the beginning of the pilot, and three members of the 
Information Systems training crew. The vendors rep and technical expert handled all the 
technical programing issues while the lockup keeper worked with his fellow lockup keepers to 
build acceptance for the new mugshot system. The training officers handled the installation of the 
mugshot equipment as well as all the training. Each installation took approximately a half day, 
and training officers returned later in the day to train subsequent watches. When users were fully 
trained at one site and the live version of the Digital Mugshot System was functioning properly, 
trainers moved on to the next lockup site. 

Another part of the mugshot system installation was furnishing the district lockups with 
new track lighting and painting mugshot background walls a standard color for lineup purposes. 
While the lighting was installed in almost all of the lockups, its placement on the ceiling directly 
above the mugshot photo washed out the mugshots. As a result, in many of the district lockups 
the track lighting is unused, and lighting from the standard overhead lights provides the 
illumination for the mugshot photos. As for the painting of the background walls, many of the 
district lockups already had the required background wall color; however, for the most part those 
that did not conform are still awaiting the paint job. 

Training. Training for lockup keepers was originally scheduled for November 2001. 
However, prior to that it was learned that some of the older district stations needed electrical 
upgrades. The rewiring process was delayed, as was obtaining the correct equipment setup, so it 
was decided that the training for lockup keepers (all watches) would coincide with the rollout of 
the Digital Mugshot system in each district. Thus, onsite, hands-on training took place between 
January and March 2003. 

The remaining users groups received instruction on the Digital Mugshot system between 
February and May 2002. Instruction focused on each groups specific use of the system, and the 
various functionalities for each were reviewed and tested. Participants were informed that the 
Help Desk would be available for technical questions. Sessions were not lengthy, and entire user 
groups were trained over the course of a few days. As each group completed its training, screens 
pertaining to their functions became accessible. 

User reactions. The majority of respondents have indicated that they like the new 
mugshot system because it is efficient, accurate, and photo retakes can be done simply and as 
often as necessary. That being said, lockup keepers biggest complaint is their lack of bypass 
authority. According to one CPD informant, this restriction was designed to compel lockup 
keepers to follow correct procedures when processing offenders. However, the final bypass 
authorization method has had some unforeseen impacts. Some lockup keepers report that 
supervisors do not know how to perform the bypass/un-bypass functions, and that during busy 
times, finding a supervisor with by-pass/un-bypass know-how can be difficult. The wait for a 


supervisor creates processing bottlenecks that can cause significant delays in prisoner processing 
time. In one case, to avoid such delays, desk sergeants resorted to providing their PC Login 
numbers to the lockup keepers so they could handle their own bypasses and un-bypasses without 
having to physically locate a sergeant. 

The Digital Mugshot systems help function has garnered mixed reviews. The design of 
the help feature and the creation of external help protocols went through many revisions. 
Originally, a printed manual was created with the intention of converting it to hypertext markup 
language (HTML) format for online availability. However, the officer in charge of mugshot 
installations did not believe that an active help option was necessary because of the systems ease 
of use. Instead, the officer opted for a printed top 10 troubleshooting list developed from user 
issues during early district roll outs. A printed copy of the top 10 list was distributed to all 
districts during the rollout or shortly thereafter. Assistance was also available through the 
Departments Help Desk. Initially Help Desk personnel contacted the vendors rep or the CPDs 
mugshot system expert whenever  nights and weekends included  help was needed to diagnose 
and fix problems. However, the vendor separated from the project by January 2003 and the CPD 
mugshot expert did not have the time to continue to be contacted by the Help Desk. An 
additional help feature called Bug Reporting was made available on every mugshot system 
screen, allowing users to send error reports directly to the CPDs mugshot system expert. 
However, this feature was never publicized, and most users either do not know about it or know 
what information must be included when sending a bug report to the CPDs expert. 

Lockup keepers and detention aides with computer experience have had little problem 
with the mugshot systems help options (top 10 list, Help Desk, Bug-Reporting). However, less 
proficient computer users initially said they hoped there would be a help manual with the 
mugshot system, and after using the system, they commented that the top 10 list was not 
adequate. Many still say that they would have preferred receiving a help manual or something, 
especially for the guys that sub in for us...and for the times when the Help Desk is too busy. 

Impact. Early statistical indicators seem to show that the new digital mugshot system is 
having a significant positive effect even after less than a year of operation. After seven months of 
use, when compared to their previous five year averages, total mugshot photographs were up 13 
percent and CB numbers linked to a CPD mugshot photograph were up over 50 percent. 
While some of this increase is attributable to the contributions of Criminal Apprehension and 
Booking System (CABS) agencies, it is likely that most of the increase stems from the accuracy 
of the new Digital Mugshot system. Instead of losing mugshots during data transmission or 
allowing unchecked lockup keeper by-passes of prisoners, as was common with the old system, 
the new Mugshot system was designed to ensure much higher data capture/retention rates as well 
as higher compliance from lockup keepers via strict by-pass controls. Another area of significant 
increase (up almost 150 percent )has been photo capture of tattoos and identifying marks. This is 
most likely an attribute of the new Digital Mugshot Systems state-of-the-art equipment and its 
relative ease of use. A broad conclusion could be drawn that most users enjoy using the new 
mugshot system and are generating more quality mugshots than in the past. However, what these 
positive increases in numbers do not seem to show is that poor quality mugshots may still be 
slipping through the system. 


Quality control. During the early stages of the systems implementation CPD insiders 
were seeing a disturbing number of processing mistakes  CB numbers not matching the correct 
suspects mugshot and poor quality mugshot photos. Some insiders concluded that lock-up 
keepers are not the aggressive type when it comes to quality control. To address this, mugshot 
installation team members audited mugshot photo quality. They randomly checked photos from 
each district lockup from all watches, determined who was taking inferior mugshots, and 
contacted supervisors in the appropriate districts. However, this practice quickly became 
overwhelming, so in February 2003 the CPD mugshot expert created an auditing function for 
watch commanders so that they would have the ability to query all photos from their lockup 
keepers or detention aides during a specified time frame. 

Even with these auditing/quality control capabilities in place, poor mugshots may still be 
entering CPD records. Sometimes awareness of poor-quality mugshots arose because of their 
impact on high profile cases. For example, in one mugshot a lockup keeper captured only half of 
a prisoners head in the photo and did not correct the problem. This proved to be costly because 
the prisoner was allegedly involved in some high profile thefts, and the lack of a good mugshot 
significantly stalled further investigation. In a more blatant challenge of mugshot quality control, 
a district lockup keeper submitted a batch of shoddy mugshot photos as a test to see to whether 
someone or something in the system would catch the purposeful mistakes and inform district 
supervisors or the lockup keeper directly. No one was ever contacted. The consensus from lockup 
keepers and detention aides is that someone downtown might be looking at mugshot quality, 
but no one at the district level is monitoring quality because they never hear anything from their 
immediate supervisors, even when they know they have taken poor quality mugshots. 

The Future of the Digital Mugshot System 

The digital mugshot system is largely functioning as intended, and the majority of users 
are content with it in their daily working environment. There are still some isolated bugs to work 
out, but that is to be expected with any new system. The CPDs mugshot expert is in the process 
of making changes to the look and feel of the mugshot system so that it will conform to 
CLEARs look and feel. 

Future maintenance of the mugshot system is of some concern. There is no maintenance 
contract with the vendor, so the CPD relies solely on the mugshot expert to perform all system 
maintenance and repair. At the time this report was written, there was no backup plan for a 
situation wherein the mugshot expert becomes unavailable. Also, the CPDs hardware reserves 
are quite low  only a few mugshot computers, custom-made lens-control boxes and other 
miscellaneous mugshot equipment are currently available. If a brawl occurred in a lockup and 
damaged some of the mugshot system hardware, it is possible that the district lockup would be 
without the necessary mugshot system hardware for quite some time. 

Finally, there is some concern that while mugshot quantity may be increasing, routine 
audits are not being done to ensure that mugshot quality is also improving at the same rate. The 
new mugshot system does give CPD administrators the ability to track trends in mugshot use to 


determine where performance is satisfactory and where it is lacking. Unfortunately, this feature is 
not being taken full advantage of by CPD administrators, as represented by the seeming lack of 
routine automated quantification and analysis of mugshot statistics. The need exists for 
standardized quality control procedures that can guide future enhancements and adjustments to 
the mugshot system as well as provide a consistently accurate measure of mugshot quality. 
Without such procedures, the true quality of mugshots as captured by the new mugshot system is 
likely to remain unknown. 

eTrack 

The Chicago Police Department has automated evidence and recovered property 
inventory and tracking, one of its core functions, with the multi-phased deployment of eTrack. 
The first phase, launched in summer 2002, provides electronic data capture. The second phase, 
implemented in June 2003, replaced the Criminal Evidence Recovered Tracking System 
(CERTS), the Departments legacy inventory application. eTracks third phase will incorporate 
upgrades that enhance functionality. 

Phase I 

Phase I enables officers and evidence technicians to record new inventories and specify 
their destination. The application is available via any computer with access to the CPD intranet. 
After logging on, officers input the same information on evidence or property that was captured 
on the previously used five-part handwritten form. Supervisors approve the inventory 
electronically after the officer submits it electronically, and a bar-coded label is printed and 
attached to the package. eTrack also enables electronic manifesting, with couriers scanning the 
bar-coded label of each package to be transported. In addition to creating a manifest document, 
this process provides a cross-check that ensures that all evidence or property approved for 
transport is picked up. When the evidence or property arrives at the Forensics Services Section 
(crime lab) or the Evidence and Recovered Property Section, the receiving officer rescans the 
package to acknowledge its arrival. Thus, with the completion of phase I, all handwriting has 
been eliminated from the inventorying process. In addition, inventories can be queried by any 
number of variables. 

Though to date only phase I of eTrack has been launched, its impact on the CPD has been 
substantial on many dimensions. From a sheer breadth standpoint, eTrack impacts every 
individual who might need to inventory evidence  essentially every sworn member of the 
Department. In addition, electronic inventorying offers improvements in officer time-
management, legibility and integrity of data, accuracy of disposition and courier accountability. 

As officers have become quite familiar with eTrack, and they are able to quickly input 
inventories in less time than it took to fill out the old written form. Additionally, prior to the 
launch of eTrack, each intake unit had only one inventory collection book. Therefore, officers 
needing to record a piece of evidence or recovered property often would spend a considerable 
amount of time in the station either tracking down the inventory book or waiting until other 


officers completed their work and supervisors approved it. In addition, correcting and 
inventorying electronically is likewise more efficient. Rather than having to white out changes 
on a five-part written form, officers need only log on to an edit page, and the correction is 
quickly and neatly accomplished. What all of this means is that officers should be able to return 
to their street assignments more quickly than in the past. 

Legibility issues no longer exist, because nothing is handwritten. Before eTrack, a copy 
of the inventory form was sent to data entry clerks who were responsible for deciphering the 
writing of the officers and keying data into CERTS. This step was first eliminated with Oracles 
development of an interface that migrates data collected via eTrack to the CERTS database. 
The advent of electronically entering evidence data enhanced accuracy because all data fields 
must be filled before the report can be submitted to a supervisor; incident numbers are validated 
against 911 calls; and addresses correspond to the citys geocode file. 

The disposition of evidence and recovered property is accurately recorded and traceable 
with eTrack, because all inventories require that an action field be filled. Officers must specify 
what will be done with the property and how it will be transported to the appropriate destination 
(crime lab, Evidence and Recovered Property Section). The location of the property or evidence 
can be determined at any time by querying the system. 

Development and Implementation 

eTrack development began in July 2001 and an Oracle project manager was assigned to 
co-develop the evidence tracking application within weeks of that. Weekly JAD sessions were 
held for stakeholders over a four-month period, and Oracle submitted a scope, objectives and 
approach document by early December of that year. 

After the document was accepted, development of the application began in July 2001 and 
was essentially completed by mid-February 2002. During this period, the CPD project manager 
conducted site surveys to determine hardware resources and their accessibility in district stations 
and other facilities where evidence and recovered property are inventoried. This survey revealed 
that additional work stations were needed and that various facilities adaptations would make 
implementation more likely a success. Also during that time, vendors were located and contracts 
finalized for supplying bar code scanners and printers for each site. Because this process went so 
smoothly, hardware installation and implementation of this aspect of eTrack, originally planned 
to be part of phase II, was realized in late September 2002. 

Pilot testing of eTrack Phase I was carried out by the CLEAR training team to not only 
ensure that the application worked as expected, but also to sufficiently familiarize them with 
eTrack to carry out the large-scale training operation before them. Because every sworn member 
at each evidence intake facility would need to be trained, the decision was made to have trainers 
onsite, around the clock at first, in each facility as eTrack was introduced. So, when eTrack 
went live at the pilot site in early June 2002, members of the development team and trainers 
were at the station from midnight on to address roll calls and give demonstrations, followed by 


individualized hands-on training for all sworn personnel. After it was determined that everything 
was working smoothly, the development team turned everything over to the trainers, who stayed 
at the pilot station for two weeks. Once eTrack went live at the pilot station, it became the only 
method for inventorying evidence or property at that site. The development team returned to the 
pilot test station several nights later to observe how the application functioned under high volume 
circumstances  during a mission resulting in many arrests. After an essentially problem-free 
launch at the pilot site, an aggressive roll out scheduled was followed, with trainers staying at 
each site for two days. By early September 2002, eTrack became the standard means for 
inventorying evidence and recovered property in the Chicago Police Department. 

Training. Onsite training began with a member of the training team addressing roll call 
and giving a presentation of how to inventory a piece of evidence, eliciting suggestions from 
participants on hypothetical information with which to fill the data fields. Officers were 
encouraged to ask questions throughout the demonstration, which was visible on large monitors 
in the roll call room. At the conclusion of roll call demonstrations, officers were called in by car 
to sit with a trainer for one-on-one training. Test cases were used for training unless officers 
happened to bring in evidence after an arrest. (In that case, officers received training as they 
inventoried the evidence on eTrack.) Test-case training took place on a portion of the intranet 
known as the sand box  a place where officers are encouraged to play around with the new 
application. Those receiving individualized training signed in to ensure that officers not on 
furlough were trained before the team left the facility and to acknowledge that they had received 
a 25-page users guide. Those not trained by the team were instructed later by district officers 
designated as trainers. The CPD Help Desk also received training from the CLEAR training team 
and was available for questions from the time the application went live at the pilot site. 

Training team members were also onsite as the new eTrack hardware (barcode printers 
and scanners) was introduced at the various evidence intake facilities throughout the city. Printers 
were installed by the vendor and scanner installation was handled by the training team. Training 
at evidence intake sites was virtually unnecessary because the only new change associated with 
this upgrade was for sergeants  one screen had been removed and a new box appeared on an 
existing screen that denoted their approval for a couriers removal of evidence or property from 
the site. However, approximately 20 couriers based at CPD headquarters as well as 100 evidence 
and recovered property receivers based at one facility would need some elementary instruction on 
use of the bar code scanners. This was accomplished in a two-week period prior to roll out. 

Implementation and Impact. Phase I of eTrack was implemented with no significant 
obstacles on the front end data capture side and has been well received by users. However, this 
represents only part of Phase I of eTrack. The receivers of data captured by eTrack  the 
Forensics Services Section and Evidence and Recovered Property Section  represent the other. 
Interviews with receivers produced somewhat mixed reviews. 

On the whole, there was enthusiasm for the application. However, there were occasional 
problems with the interface between eTrack and CERTS. Once in a while, automatic data 
transmission from eTrack to CERTS was not smooth, resulting in a situation in which evidence 


arrives at its destination, but the corresponding eTrack information is not accessible. Because a 
printed list was generated for all such transmission difficulties, there was no loss of data. The 
degree to which this was troublesome seemed related to informants technical expertise: those 
with more sophisticated computer backgrounds viewed interface problems as something 
requiring extra troubleshooting to resolve, but nothing that diminished the applications value. 
Others with more basic knowledge indicated that considerable effort goes into the resolution, 
opining that creating the eTrack system in phases was ill-advised. However, the applications 
harshest critic admitted that eTrack Phase I solved several problems even though it created a few 
new ones. 

The eTrack project managers acknowledged the interface problems, explaining that the 
difficulties were anticipated because CERTS is such an old system. Despite this, the decision 
was made to roll out eTrack in phases for a few reasons. First, knowing that the rank and file  
eTracks users  is always a difficult group to sell on a new application, they decided to get the 
front end developed and launched as quickly as possible. The benefit of doing so, in their 
estimation, outweighed the problem of occasional difficulties with the interface. They also firmly 
believe that they could establish credibility by rolling out the first phase rather than taking extra 
time to develop the entire module, which would contribute to the officers thinking that the 
application would never become a reality. 

One facet of the eTrack system that was originally planned as a part of Phase II was 
implemented ahead of schedule  electronic manifesting  which required additional hardware at 
district and Area facilities. Intake units at each were supplied with a label printer and bar code 
scanner. When property or evidence is inventoried, a label (shown in Figure 5) prints out and is 
attached to the evidence/property bag. Once the label has been scanned, the property or evidence 
becomes trackable; at any given time, the system can be queried to see the whereabouts of 
evidence or a property package. 

Figure 5 
Inventory Label 
Image of Inventory Label



Phase II 

As mentioned earlier, eTrack Phase II was launched in June 2003. Phase II is completely 
invisible to all of the CPD except those who work in the Evidence and Recovered Property or 
Forensics Services Sections. Replacing CERTS, ETrack II enables ERPS and Forensics 
personnel to easily locate property within the facility, track its movement from one individual to 
another and provide an accurate and complete snapshot of evidence in custody at any time. 

In addition to replacing the CERTS system, Phase II will provide a data feed to the 
Illinois State Police Forensics lab, where all evidence is eventually sent. Data from eTrack will 
reside within the CLEAR database, and all evidence-related data will be queriable through the 
data warehouse. 

The Future of eTrack 

As mentioned above, eTracks third phase will incorporate upgrades that enhance 
functionality. However, eTrack-related discussion must address the potential benefits that it 
offers. First, in keeping with the CPDs increasing focus on accountability, the application 
imposes answerability on personnel at many levels, including couriers, because pickups are time-
stamped. Supervisors can, if necessary, ascertain whether couriers are managing their time 
appropriately. 

Going beyond that, however, eTrack Phase I provides for cleaner, trackable chain of 
custody, while Phase II impacts inventory issues. Because misplaced, stolen or lost evidence, as 
well as mistakenly discarded or destroyed evidence, can prevent successful prosecution of 
criminal cases and to lead to charges of mismanagement, eTracks advantages are almost 
incalculable. 

Gang Arrest 

By the mid-1990s it was internally apparent that the Departments system for collecting 
and analyzing gang information was disorganized and ineffective. It was a paper-driven process 
that isolated operational units and made interdepartmental sharing of critical gang information 
very difficult. Recognizing the need for a central database that would allow identification and 
tracking of Chicago area gangs, in 1998 the CPD began development of a Gangs application that 
would interface with CHRIS. The goal of the Gang application, to be developed in several 
distinct stages, is to enhance the Departments ability to record gang information, reduce system 
redundancies and create a database that will enable officers to engage in predictive analysis. 

Five principal phases of the Gang application were developed in stage one, which was 
completed in approximately two years: 

 Member profiles  a fully automated gang arrest database that functions as the 
Departments first step in identifying an arrestees gang affiliation. This was 90 percent 
complete at the end of stage one. 



 Organization profiles  an online source of gang profiles including descriptors such as 
gang type; history; factions; rivals; symbols and signs; and documents and photos. At the 
end of the first stage, about 50 percent of this area was completed. 
 Gang incident review  enables citywide or beat-specific analysis of criminal gang 
activity. This section is linked to member and organization profiles as well as to the 
Departments crime-mapping system for identifying and mapping criminal gang activity. 
Gang incident review was 35 percent completed at the end of stage one. 
 Administrative reports  generates detailed gang-activity reports for field and command 
personnel. Approximately one-third was completed at the end of stage one. 
 Major case operation file  provides narcotics investigators and gang specialists with the 
ability to conduct comprehensive long-term investigations more efficiently by providing 
all available information that may be associated with the case. No work was done in this 
area. 

A plan for second-stage development of the Gang application was drafted as a grant 
proposal in 1999. The second stage initially had four main phases: 


 Completing gang incident review  considered the focus of stage two work, the system 
would be customized to identify, track and analyze narcotics gangs, as well as to link 
narcotics tip information with the criminal gang database. In addition it would automate 
the processing of new arrest data and the interpretation of arrest and case data. 
 Enhancing compliance and data security  ensuring the Gang applications compliance 
with regulations guiding federally funded multiagency criminal intelligence systems. This 
entailed establishing and maintaining acceptable standards for submission and entry of 
criminal intelligence information, its dissemination to other agencies, and the review and 
purge process. 
 Enhancing the Police Patrol Task Force program  developing an application that would 
enable sharing of gang parolee information between the CPD and the Illinois Department 
of Corrections (IDOC), aimed at identifying high-risk parolees who may return to 
ongoing criminal activity. 
 Development of the Major Case Operation File  initial creation of case objectives, 
confidential links to targeted gang members and surveillance investigative notes. 


The grant proposal for second-stage development of the Gang application received 
preliminary approval. However, questions about the applications compliance with federal 
regulations delayed disbursal of funds. Nearly two years later, the CPD received federal 
notification that the Gang application would not violate privacy statutes. Unfortunately, the grant 
specified that funding was to be used by September 2002, which proved to be an impossible 


timetable because of the CPDs commitment to developing other CLEAR applications. Thus, the 
Department opted to delay second-stage development until the following year and seek new 
funding. As a result of the long delay, the Gang applications project manager was reassigned. 

The CPD used the first quarter of 2003 to negotiate details of its grant proposal. After 
many revisions and some small changes, an $867,000 grant was awarded. The grant specified 
that all funds were to be used for first-year development of the Gang applications second stage 
and completely exhausted by September 2003. In October 2003, an additional $892,000 would be 
made available for second-year development and implementation of the Gang applications 
second stage. 

Development and Implementation 

In early May 2003, a newly appointed Gang application project manager held the first of 
five Gang JAD sessions. Each JAD session had approximately 10 to 20 attendees, including CPD 
managers, Oracle consultants/developers, gang detectives, Narcotic and Gang Investigations 
Section (NAGIS) gang specialists, police officers and sergeants, Deployment Operations Center 
(DOC) staff, and Crime Strategy and Accountability (formerly known as Office of Management 
Accountability) representatives. Through these sessions, the main goal of the Gang application 
was eventually defined: to construct a gang repository capable of electronic capture of all gang 
related information generated by the Department. 

JAD sessions concluded in late July 2003. From them a few new and interesting 
development pieces emerged. It was discovered that the Cook County Jail is actually a better 
source for gang information than is the Illinois Department of Corrections (IDOC), because the 
County Jail holds most of the citys gang members (including high-ranking gang members) and 
because gang members tell intake officers their gang affiliations as well as their actual rank/role, 
so as not to be put next to rival gang prisoners. As a result, an electronic link between the CPD 
and the County Jail is being sought. The JAD sessions also revealed the Departments district 
gang books (manila folders of gang hierarchy charts and mug shots of known gang members) 
were an effective tool for organizing the complex hierarchies of Chicago gangs. Gang books 
would become a significant component of the application. 

Second-stage development of the Gang application was a very intense process that took 
place mostly in the summer 2003. The project manager realized that first-stage work on the Gang 
application was so outdated  by then five years old  that she decided that the best approach 
would be to salvage what little they could and start over. The gang incident review phase was 
replaced with a phase that would develop a process for entry of information by field personnel 
and enhance the efficiency of attacks on criminal gangs. Thus the amended second stage phases 
were as follows: 

 Phase one: Web-enable the application and ensure compliance with federal privacy 
statutes 


 Phase two: Develop a process for entry of information by field personnel and enhance the 
efficiency of attacks on criminal gangs 
 Phase three: Automate exchange of parolee status/conditions of release with IDOC 
 Phase four: Complete analysis and design phases of the major case operations file. 


As second stage phases were developed, gang application features became available via a 
link on the CLEAR homepage. One new feature was gang profile, through which users select 
from an extensive list of gang names and receive information about the gangs factions, aliases, 
status, type, classification, identifiers, and important anniversary dates. Users are also shown who 
created the information about a specific gang and when the information was entered. 

The gang contact card and gang arrest card are two important aspects of the Gang 
application. Gang contact and gang arrest cards  paper forms  are completed by officers under 
different circumstances. Data from contact cards and arrest cards are input into separate 
databases for later queries by CPD officers via a link in the main CLEAR menu. Officers in the 
field complete the gang contact card to capture data in non-arrest situations in which the 
individual is a self-admitted gang member. The paper contact cards are processed, approved and 
entered into the gang contact card database by district Review Office personnel. Once entered, 
gang contact card information can be then accessed online via queries by name, nickname and all 
other identifying information captured on gang contact cards. Development of the gang contact 
card was an eleventh-hour inclusion to the application, developed in less than three weeks time. 

The gang arrest card captures data in situations where an arrest has been made of a self-
admitted gang member. Arresting officers complete the gang arrest card online. No approval is 
needed to submit an electronic gang arrest card because the watch commander initially approves 
the arrest. Once the arresting officer finishes inputting gang arrest card information, it is 
considered a locked record and cannot be changed. However, the arresting officer that created the 
gang arrest card does have an eight-hour window to edit the gang arrest card. Officers assisting in 
the arrest are the only others who have gang arrest card data-entry privileges. If the CLEAR 
system is down and the arresting officer cannot access the gang arrest card, they are instructed to 
fill out a paper gang arrest card and enter it into the gang arrest card database when the system is 
back online. 

Gang arrest card data is available to all officers. The search feature allows queries by a 
variety of dimensions: central booking number, incident report number, arrest date, beat of arrest, 
offender name, star number of arresting/assisting officers, gang name/faction, created date, and 
status of (verified or unverified). All officers have access to these search parameters with the 
exception of the unlisted gang name search, which is available only to Deployment Operations 
Center senior staff. 

Another feature within the Gangs application link is gang listing reports. This allows 
users to do a side-by-side contact card and arrest card search for information about a gang 
suspect. Searches are limited to user-determined periods of time (i.e., Jan. 1- Feb. 20). Gang 
listing reports offer the only official print out capability. Other searches in gang profile, gang 


contact card and gang arrest card are designed primarily for online viewing, so they allow only 
rudimentary screen shot printing. 

The first year of second-stage Gang application development yielded major 
accomplishments, but some disappointing roadblocks emerged as well. Web-enabling a federally 
compliant application and developing a gangs-related data collection method were achieved. 
However, the planned development of an automated exchange of parolee status and conditions of 
release with IDOC ran into a significant obstacle. The CPD met with IDOC numerous times and 
created a development plan for an XML-based IDOC interface, but IDOC could not commit to 
anything because of a lack of resources/technology. Finally, CPD administrators were concerned 
that the planned major case operation file  originally conceived in stage one  could 
compromise informants, undercover officers, and CPD surveillance if made available in an 
automated environment. Development was halted, and major case operation file was replaced by 
the automated District Gang Book project. 

Implementation/Training 

On September 30, 2003 the newly developed features in the Gang application were 
launched. No training was held; rather, a Patrol division memo distributed departmentwide 
detailed the particulars of new Gang application functionality (Gang Profile, gang contact card, 
gang arrest card, Gang Listing Reports). In addition, a 14-page gang arrest card user guide 
(printable PDF file) was made available through a help link. 

At the time this report was written, the Gang application was functioning as expected, but 
there had been some problems with officer acceptance of both the gang contact and gang arrest 
cards. During the first week after rollout, the gang arrest card portion of the application was 
barely used. In fact, citywide only seven gang arrest cards were submitted electronically, 
indicating a lack of compliance by officers. In response, the chief of patrol sent out a memo 
indicating that gang arrest cards would need to be electronically filed for each gang-affiliated 
offender arrest. The memo stressed that the gang arrest card process was entirely automated with 
no more paper forms. Concerning the gang contact cards, district review officers were unhappy 
that they were given responsibility of inputting the thousands of gang contact cards submitted by 
district officers every month. District review officers were thought to be disposing of the contact 
cards as a sign of protest. 

Another implementation problem that emerged was that a number of users were getting 
error messages whenever they attempted to use the Gangs application. It was quickly realized 
these error messages were appearing only on computers that were using an earlier version of the 
Internet Explorer web browser. All CLEAR applications require Internet Explorer 6.0 or newer 
to run correctly. Fixing this problem would have been a relatively easy process, but browser 
upgrades are handled one computer at a time, and due to the sheer size of the department, what 
seems like a small detail continues to cause problems for CLEAR application users. 


Preliminary indicators suggest that officer attitudes about the Gangs application are 
improving as small glitches are resolved and use increases. In addition, the contact and arrest 
card data inputting numbers are now a subject of consideration at district accountability sessions, 
a development that is likely to bring about increased compliance. 

The Future of the Gang Application 

In October 2003, the second year of funding for stage two development of the Gang 
application was approved, with a September 2004 deadline for its use. Significant funding 
(approximately $1.2 million) for a third stage of development was approved in late November 
2003. While third stage development plans have not been determined, the project manager has a 
plan for development in 2004, including: 

 Enhancements to the gang arrest and gang contact card process to allow records to be 
purged to comply with court orders, as well as security enhancements to accurately track 
users entering and accessing data in the two systems. 
 Updating gang profiles to include organization information, gang characteristics, history 
of gangs, rival/alliance information, and symbol (tattoos, colors, etc.) information. 
 Automating District Gang Books to provide real-time gang activity reports. 
 Creating Gang Member Profiles from information collected via gang contact cards and 
gang arrest cards to help differentiate between various gangs and their hierarchies and 
create individual active gang member profiles. 
 Proceed with efforts to automate parolee status and conditions of release information 
exchange with IDOC. 


There will be one significant change in the Gang application development process  the 
discontinuation of Gang JAD sessions. CPD administrators felt that the JAD sessions were not 
producing substantial results. The Deployment Operations Center commander, the Gang 
application project manager and staff, and Oracle developers will provide input for remaining 
pieces of the application. 

At the time this report was written, the Gangs application project manager was optimistic 
that the next phase of stage two development may be completed as early as May 2004, at which 
time Stage II development would begin. 

Juvenile Arrest 

Prior to 2002, the CPDs juvenile arrests were processed primarily by means of a rather 
cumbersome paper-based system. To ensure more accurate record keeping and gain greater 
analytical capabilities, as well as to comply with the states 1998 Juvenile Justice Reform 
Provisions, the Department implemented an expanded Juvenile Arrest system. The provisions 
recognized that in order to effectively rehabilitate delinquent juveniles, law enforcement agencies 
would need to improve their capture of juvenile arrest information so that baselines of juvenile 
criminal history could be created. This information would then serve as an accurate guide for 
decisions concerning the referral of juvenile offenders to the appropriate service providers. The 
CPDs Juvenile Arrest system was designed with these goals in mind. 


Prior to launching the enhanced Juvenile Arrest system, the CPD stored in its criminal 
history database basic information about juvenile cases handled through the court system. Data 
entry clerks would input information from paper reports filled out at the time of the juveniles 
arrest. In addition to being inefficient and redundant, this process also did not capture data about 
station adjustments  the immediate resolution of a juvenile offense with conditions imposed on 
the offender by a youth investigator. This is a frequent outcome of juvenile arrests and a focus of 
the 1998 amendment. Station adjustment paperwork was kept in a file at the station where the 
juvenile was processed. To access information about station adjustments, officers needed to call 
the appropriate district to request a check of the paper records. With 30,000 juvenile arrests and 
thousands of station adjustments each year, this method proved to be very ineffective and left the 
CPD with no real means to accurately track a juveniles compliance with station adjustment 
stipulations. This method also made it very difficult to maintain station adjustment records as 
mandated by the 1998 amendment. It specified that no more than nine station adjustments could 
be granted to an offender without states attorney approval (though the CPDs threshold is three; 
and that station adjustments must be reported to the State Police for offenses that would be 
felonies if committed by adults. 

To comply with these requirements, the CPD decided to expand its youth processing 
system by designing Web-based, interactive juvenile-arrest data entry screens that would capture 
the mandated information and whatever additional data were permissible within the constraints 
of juvenile rights legislation. The CPDs main goal for the enhanced Juvenile Arrest system was 
to track and assess the conditions and outcomes of juveniles as they move through Chicagos 
Juvenile Arrest system. The new system allows officers to check a juveniles record for 
outstanding warrants, missing reports, demographic information and criminal history, including 
summary of arrests, arrest charges, court charges and mug shots. However, only youth 
investigators, supervisors and detectives cross-trained in youth arrest procedures can access the 
data entry screens to process a juvenile offender. A feature of the enhanced system is that youth 
investigators now are able to save their work-in-progress, allowing officers to resume working or 
update case reports at any computer connected to the CPD intranet. 

Development 

Development of the enhanced Juvenile Arrest system evolved over a four year time span 
and involved many participants, each with distinct responsibilities. The CPDs Information 
Systems director of development oversaw the project, while Oracle programmers created the 
actual juvenile arrest screens. The commanding officer of Youth Investigations Administration 
headed a five to 10 person team responsible for many facets of Juvenile Arrest system 
development including: design review, testing and evaluation, recommendations for change and 
user training. 

The Departments original intention was to launch a system that would meet or come 
close to the states amendment compliance date of January 1999. In November 1998, the CPD 
expected to be compliant by March 1999. This deadline was not met and was revised numerous 


times due to CPD and the Oracle team personnel changes, funding shortages and other 
Information Systems matters (such as Y2K security) that took precedence. According to a key 
insider, there were no repercussions for missing the compliance deadline; the State of Illinois 
decided to turn a blind eye to the deadline because jurisdictions statewide were similarly unable 
to meet it. However, the CPD did its best to comply with the new requirements through its 
existing paper-based system, but without an automated system, the attempt fell short of satisfying 
the true intent of the law. 

Over time, 16 joint application development (JAD) sessions were held with 
representatives from Information Systems, Oracle and the Youth Investigations team. The 
sessions took place between August and December 2000, resulting in a process model that 
mapped out the paper-driven juvenile arrest process in its entirety. The process model, an 
elaborate flow chart showing possible decision points and associated procedures in the arrest 
process, served as the foundation for development of the application. However, as 2001 began, 
development of the expanded juvenile system was put on indefinite hold for many of the same 
reasons that led to its previous delay. In April 2002, the development of the juvenile arrest 
screens began anew, with both the commander and commanding officer of Youth Investigations 
brainstorming to determine the best way to get development of the expanded Juvenile Arrest 
system back on track. They decided to create a six-person focus group comprising youth 
investigators from the various Chicago Police Department Areas. Over the course of the next five 
months, five focus-group sessions were held, at which participants recommended changes and 
improvements to the juvenile arrest screens. Their recommendations were subsequently passed 
on to Information Systems developers and Oracle programmers for implementation. A working 
model of the enhanced juvenile system was made available for testing by users in two Area 
headquarters, CPD headquarters and the Special Investigations Unit, with the intention of 
eliciting user feedback. Unfortunately, due to their heavy workload, investigators in the field 
never used the test model and, therefore, no feedback was generated. The Youth Investigations 
team nonetheless felt very confidant of the final product, and despite having no user feedback, 
they decided to progress with the training and implementation of the enhanced juvenile arrest 
application. 

Training. A six-person team made up of youth investigators conducted training for the 
enhanced Juvenile Arrest system in September 2002. Training consisted of a three-hour class for 
the Departments 250 field youth investigators, 60 headquarters Youth Investigation staffers, and 
supervisors and detectives who have been cross-trained in juvenile arrest procedures. Sessions 
were held at CPD headquarters on each watch, with a maximum capacity of 18 participants per 
session to ensure that each officer had a terminal on which to work. Early training sessions were 
well-attended, averaging eight to 10 officers per session for the first two weeks. However, 
attendance dropped off considerably by the end of the second week. 

Training sessions were held in the Information Systems computer lab at headquarters. 
Participants were instructed via two large monitor screens that mirrored the training screens 
being used by participants. The three most frequently used functions were covered in-depth, 
while a few others were briefly examined. Each attendee received an extensive training packet as 
well as a Juvenile Arrest Menu cheat sheet and a small packet of printouts from the system. 


Instruction concluded two days before the system was launched citywide, and according 
to CPD insiders, most Juvenile Arrest system users attended a session. Youth officers who had 
served as trainers returned to their districts, where they were expected to train those who were 
unable to attend formal training at headquarters. The Information Systems Help Desk was trained 
in the technical aspects of the enhanced Juvenile Arrest system and is available for users who 
have technical questions about the new arrest screens. However, all juvenile arrest processing 
questions must be handled by Central Youth Activities at CPD headquarters, which is staffed 
around the clock and can help guide officers through the processing of youth offenders. 

Implementation 

The citywide launch of the enhanced Juvenile Arrest system occurred in September 2002, 
at which time it became the primary method for processing juvenile offenders. Some immediate 
bugs surfaced; most were basic (could not print; button did not work) that were remedied by 
calling the Help Desk or the juvenile arrest liaison (a Youth Investigations officer at CPD 
headquarters), who contacted Information Systems programmers to coordinate problem-solving 
efforts. 

However, a significant system malfunction  inability to track a juveniles compliance 
with station adjustment conditions  appeared during the launch of the Juvenile Arrest system. 
Fixing that problem and determining a course of action for noncompliance with station 
adjustments was a lengthy process. By March 2003, it was possible to electronically track 
conditions of station house adjustments, but only under certain conditions. During re-arrests, 
savvy youth investigators were able to use the Juvenile Arrest system to access the conditions set 
by a previous station adjustment but could only determine the level of compliance when 
juveniles cooperated by providing information. However, if a juvenile did not cooperate or was 
not re-detained, there was no way for youth investigators to do so. Furthermore, if a youth 
investigator was able to determine that a juvenile had not complied with a station adjustment, 
there were no Department-sanctioned repercussions in place. Eventually, by fall 2003, the 
necessary corrections were put in place to make station adjustments trackable. As originally 
envisioned, youth investigators would submit an extra copy of their juvenile arrest reports to a 
district network officer who entered station-adjustment details into the Juvenile Arrest system. 
Once entered, the network officer was required to follow up with the agency responsible for 
administering the station adjustment; determine compliance or non-compliance; and enter station 
adjustment details into the Juvenile Arrest system. When the procedure is followed properly, the 
juvenile summary section in the Juvenile Arrest system displays the number of station 
adjustments juveniles have accumulated, conditions of the station adjustments and whether the 
juvenile complied. Youth investigators have been instructed to automatically issue a court 
referral to juveniles who have not complied with a station adjustment and bar them from 
receiving future station adjustments. However, there is nothing in the current Juvenile Arrest 
system that prompts a youth investigator to follow this course of action when processing juvenile 
offenders. CPD developers have been asked to create the programming that will make the 
Juvenile Arrest system automatically flag any station adjustment that was not complied with as 
a reminder for youth investigators. The time frame for developing these flags was 
undetermined when this report was written. 


The CPD encountered no obstacles when implementing the Juvenile Arrest system and 
little complaint was expected from those most impacted by the new system. In fact, CPD insiders 
thought the response to the application would be mostly positive, believing that users would not 
view it as a completely new system, but rather an enhancement and expansion of their current 
system. Supervisor dissatisfaction was anticipated, because the scope of their report review and 
approval responsibilities was expanded under the enhanced system. Some officers close to the 
development of the Juvenile Arrest system voiced concern that the new system might be more 
time-consuming under certain circumstances. Having to complete all required fields when 
processing several juvenile offenders at the same time, or trying to gain access to a working 
computer in a district with limited computing resources are examples of such circumstances. 

User Reactions. To elicit user feedback, five youth investigators and two youth 
administrators were interviewed. While small, this sample represents all five CPD Areas as well 
as headquarters, and those interviewed were very knowledgeable about the Juvenile Arrest 
system. These informants, reported reaction to the new system was mixed during training. After 
implementation, their opinions improved, with only a few (mostly senior officers with limited 
computer experience) not liking it. The others were more amenable to the new Juvenile Arrest 
system, though they were not always comfortable using it. Only a few were sufficiently 
competent with computers to be able to learn the intricacies of the Juvenile Arrest system and 
teach or troubleshoot for their other less-comfortable coworkers. Most of our informants opined 
that the application creates more work because of its capture redundancies and increased data 
fields, however they did admit that it improves accuracy and efficiency. The old method required 
youth investigators to phone juvenile headquarters for a name check, and under the new system 
youth investigators conduct their own name checks and get real-time answers, thereby increasing 
efficiency. But the old method also relied on paper forms, and while the new system still requires 
youth investigators to first capture the arrest information on paper and then input that information 
into the enhanced Juvenile Arrest system. Eventually only electronic storage will be required, and 
no paper copy will be needed. Another perceived benefit of the new Juvenile Arrest system is 
that suburban CABS agencies juvenile data is being inputted into it as well; CPD youth 
investigators are able view up-to-date juvenile rap sheets from the suburbs and surrounding 
areas. Finally, the new system was designed to alert youth investigators that a juvenile had 
previously been convicted as an adult. 

Some early concerns voiced by youth investigators did materialized as actual problems. 
For example, processing multiple juveniles via the enhanced Juvenile Arrest system proved to be 
cumbersome for some. Significant amounts of information need to be collected from youth 
offenders, and they tend to be quite disruptive while waiting to be discharged (the holding area 
for juveniles is often in the same room where they are processed). Supervisors had their own 
complaints: they objected to needing to inspect both the paper and electronic copy of the juvenile 
arrest reports. Some investigators reported that their supervisors had problems remembering to 
make sure the hard copy information was the same as the electronic version. Others reported that 
their supervisors only read the hard copy of the juvenile arrest report, and if it was satisfactory, 
the supervisors approved the electronic version without examination. In one particularly bad 
situation a youth investigators two supervisors were either not able or not willing to use the new 
Juvenile Arrest system. One left stacks of juvenile arrest reports for the next shifts supervisor to 


complete and the other rejected all juvenile arrest reports to eliminate having to deal with the 
new application entirely. 

Investigators concerns about gaining access to a functioning computer to process 
juveniles was well-founded. Each district was to have a computer reserved for youth 
investigators only. However, they would often arrive at a station only to find their youth 
office/computer being used by district personnel for other work. In addition, youth investigators 
complained about a lack of consistently functioning computers and hardware. They reported 
printers routinely broke down and computers routinely malfunctioned due to their age and 
condition as well as to district officers tinkering and meddling with equipment when youth 
investigators were not present. 

Other user concerns surfaced during the interview of youth investigators. Some users 
were disappointed that the new Juvenile Arrest system did not provide a method to verify the 
accuracy of information provided by first time juvenile offenders. Currently investigators are 
dependent on juveniles to be truthful about their identity the first time they are arrested. If the 
youths choose to lie, there is little an investigator can do to determine whether the information is 
accurate. According to one investigator, the one thing kids wont lie about is their mothers, so 
having an easily accessed search capability for accurate parent information was key. 
Unfortunately, the Juvenile Arrest systems only method to search for this is neither easily 
accessible nor apparent to most youth investigators. Youth administrators have no plans to 
create a first time offender verification functionality within the Juvenile Arrest system. They 
consider most first time offender verification options to be fraught with problems: determining 
the legitimacy of birth certificates is difficult, electronically checking drivers licenses is 
considered a waste because it would only pertain to juveniles aged 15 and older, and cross 
referencing school information has too many variables (not all juveniles have social security 
numbers, not all are enrolled in school, etc.). 

Users were also disappointed that new system did not provide access to an interactive 
juvenile minutes section known as a 101s. In the old system, the 101s provided youth 
investigators with some shortcuts, including the ability to type one narrative and use it for linked 
arrests. Under the new Juvenile Arrest system, investigators are given few shortcuts and are 
locked into immediately completing the lengthy and time-consuming paperwork for each 
individual juvenile arrest. Some districts created their own stand alone 101s that youth 
investigators use to complete case narratives. However, these applications are not part of the new 
Juvenile Arrest system and, as such, they cannot be saved in the system and finished at a later 
time. CPD administrators made the decision not to support the 101s, as they considered them 
court forms that only collect information for court purposes rather than those of the CPD. Seeing 
little internal benefit, they were not added to the Juvenile Arrest system functionality. 

Youth investigators had a mediocre response to the systems user support and help 
options. Soon after implementation, many youth investigators relied on computer savvy officers 
in the various districts to help troubleshoot/fix problems within the new Juvenile Arrest system. 
Unfortunately, many of those knowledgeable officers retired, and the youth investigators were 
left without onsite help. As a result, investigators turned to the CPD Help Desk for support 


which, for some, has been adequate, but for others the Help Desk experience has been quite poor. 
Complaints include bad staff attitudes, being transferred from one representative to another and 
being put on hold for long periods of time. Youth investigators also complained that the Help 
Desk call-back system is inadequate. They leave a message with a description of the problem and 
a phone number, and a couple of days later a Help Desk representative will call back, but 
investigators are invariably unreachable because they are mostly out in the field. The end result is 
that investigators rarely hear back from the Help Desk with a satisfactory answer. As of fall 
2003, not all youth administrators were aware of the Help Desk problem and some were 
interpreting the lack of Juvenile Arrest system Help Desk tickets as a sign that the system was 
functioning properly for most users. One youth supervisor suggested that investigators could 
increase the likelihood of a Help Desk call back by leaving the phone number to their districts 
front desk. However, upon further reflection that solution was deemed problematic because 
during a busy time it would be unlikely that the districts front desk would accurately record and 
relay a message to the requesting investigator. 

The Future of the Juvenile Arrest Application 

Currently the enhanced juvenile arrest application is only being used within the CPD, 
though developing an interface with other Juvenile Arrest systems within Illinois is being 
considered. There is a push to make some Juvenile Court information available via the CPDs 
Juvenile Arrest system. Currently, all CPD youth employees are prevented from seeing the 
Juvenile Courts disposition of youth offenses. If the two systems could be linked, the CPDs 
Juvenile Arrest system could display Juvenile Court disposition information in the Juvenile 
History section of the CPDs Juvenile Arrest system. 

Youth administrators believe that the Juvenile Arrest system is approximately two years 
away from solely relying on electronic storage for juvenile arrest reports. That time line is 
strongly influenced by how long it will take for the Automated Arrest system to become available 
citywide. When juvenile arrest reports are only captured electronically, the 11 data entry 
operators who are responsible for editing and filing hard copy juvenile arrest reports could be 
reassigned to deliver a variety of other needed services. Other electronic issues that will need to 
be addressed in the future include the slowness of data retrieval and the need to use both the 
CHRIS and CLEAR systems. Youth investigators have found the CHRIS-linked Juvenile Arrest 
system to be very slow in its name check/arrest history searches and limited because searches can 
only be done by incident report number, youth number or name. However, CHRIS provides the 
most complete information on juvenile arrests and warrants. In comparison CLEAR data 
recovery is quite fast and allows searches by many different search parameters (name, address, 
incident report number, central booking number, nickname, etc.). However, CLEAR searches do 
not include warrant or youth number information. Thus youth investigators are forced to use both 
CLEAR and CHRIS to accurately and efficiently process juveniles. Youth Administrators expect 
both the speed and duplicate search problems to be resolved when the Juvenile Arrest system is 
web-enabled and absorbed into CLEAR. Unfortunately this conversion seems to be rather low on 
the Information Systems priority list. In addition, given the difficulty youth administrators have 
had in getting Information Systems programmers to work on the upgrades to the juvenile 
system, they are not optimistic about the Juvenile Arrest system being fully converted into 
CLEAR any time soon. 


One other future development piece is the creation of Crystal Reports. Eventually, all 
juvenile processing information will be able to be put into a Crystal Report format. This will 
allow data analysis of juvenile arrest information by area, district, beat, watch, and/or time 
variables. It will also allow for measuring of youth investigator productivity as well as 
monitoring station adjustment compliance rates. Currently the only data capture ability youth 
administrators have is a 24-hour report that provides aggregate juvenile-arrest information by 
district for each 24-hour period. This information is hand counted to produce measurable data. 
The original hope was for Juvenile Crystal Reports to be available by the end of 2003, but that 
looked very unlikely at the time this report was written. Development of Juvenile Crystal Reports 
is an essential tool that should give Youth Administrators the ability to truly assess the quantity 
and quality of work that youth investigators are producing using the enhanced Juvenile Arrest 
system. Crystal Reports should also give the CPD the ability to track juvenile arrest trends and 
determine where performance is satisfactory and where it is lacking. 

Personnel Suite 

The Chicago Police Department is automating human resource functions in five of the 
Departments units: Finance, Internal Affairs, Office of Professional Standards, Medical and 
Personnel. The Department has three main goals for the Personnel Suite: 

 to maintain comprehensive personnel files while eliminating redundant data entry 
 to enable employees to initiate and complete many of their own personnel-related tasks  
requesting days off and furlough, tuition reimbursement requests, and the like 
 to provide managers with rich personnel-related data to help them review performance 
and monitor behavior 


The Department is also institutionalizing accountability by developing a module known 
as the Personnel Performance System (PPS), which will identify problem behavior before it 
results in an unfavorable outcome. Data pertaining to behavior monitoring and performance will 
be collected in the Personnel Performance System, as shown in Figure 6. 

Figure 6
Personnel Suite Overview
Graph Showing Personnel Suite Overview



The availability of this type of real-time performance-related data promises to usher in a 
new era of meaningful and effective personnel management at the CPD. When PPS is fully 
operational, the Department expects to systematically reward high achievers as well as provide 
early intervention to help problem employees improve their job performance when possible, or 
terminate them when it is not. Implementing such a system would represent a major cultural shift 
in a Department that historically does not terminate officers for anything but egregious 
behavior. 

Automating the Units 

Finance Division. A few of this divisions functions are currently automated through 
CHIPPS, which is a stand-alone system used by City Halls Department of Personnel, but 
tracking of time and attendance  one of the Finance Divisions core functions  is not. The 
Personnel Suite will computerize the tracking of time and attendance, which is now maintained 
individually by unit. Currently, time and attendance records are transferred to the Finance 
Division, with data eventually ending up at City Hall for payroll functions. Because this 
information is not automated, the Department is unable to obtain real-time information about 
manpower strength which, under any circumstance, is essential. In the present climate of ongoing 
terrorism threats, real-time information that is immediately accessible is absolutely necessary to 
ensure effective deployment in the event of an incident. In addition, the system will automate 
basic timekeeping tasks, such as transmitting time slips electronically. Managers will benefit by 
having data available to help them approve vacation and time-off requests based on anticipated 
manpower levels, and officers will be able to track their vacation, furlough, sick time and 
overtime allotments. 

Internal Affairs Division (IAD) and Office of Professional Standards (OPS). The 
Personnel Suite will enable these units to easily access information for complaint investigations. 
At this time, both IAD and OPS have their own investigation assignment and tracking system. 
Personnel Suite will eliminate redundant processes of these two units and ensure that duplicate 
complaints are not filed. In addition, the application will provide access to time and attendance 
records, which are essential for determining whether an officer was on duty at the time of the 
incident, as well as provide access to arrest and case reports relevant to the consequent 
investigations. 

Medical Section. This units myriad functions related to medical leave and injured-onduty (IOD) 
status are now directed by the Personnel Suite. The CPDs once complex and 
laborious manual process for tracking and regulating this massive set of procedures is now 
automated, providing real-time force-level numbers. 

Personnel Division. Some of this units functions are handled through the Chicago 
Integrated Personnel and Payroll System (CHIPPS). CHIPPS will continue to handle its current 
CPD functions, such as generating payroll, and will not become a part of CLEAR. However, 
other Personnel Division systems such as Star Management, Tuition Reimbursement, Applicant 
Investigations (background checks) and numerous hiring functions will be automated and 
managed within the Personnel Suite. 


Personnel Performance System (PPS). This portion of the Personnel Suite will be a 
repository for all data related to officer behavior and performance. It will interpret information to 
identify officers whose performance indicates potential problems as a result of recurrent citizen 
complaints, pursuits and traffic accidents, firearm-discharge incidents and the like. Officers so 
identified are provided with intervention (counseling or training) designed to correct the 
problematic behavior. While this is currently done on a manual basis, the Personnel Suite will 
widen the scope of the data employed and systematize the problem-identification process. 
Development of the CPDs performance monitoring system is not the result of a consent decree; 
however, U.S. Department of Justice recommendations for jurisdictions so mandated will anchor 
Chicagos program. 

Development and Implementation 

Much progress has been made on the Personnel Suite in this evaluation period. At the 
time of this reports writing, applications were being developed for all of the above-mentioned 
units except Finance, and three applications had been launched. In addition, work began on web-
enabling recordkeeping applications known as Office Automation, used by district personnel. 
Progress on Personnel Suite applications is as follows: 

Finances JAD sessions got underway in early autumn 2002, and the process description 
document was completed at the end of October 2002. This segment of the Personnel Suite is not 
expected to be as complex as some of the others; further work will be done in the suites third 
developmental stage. 

OPS and IADs portions of the Personnel Suite have been developed in tandem, as many 
of their processes share a number of similarities. Screens have been designed and users have had 
opportunities to see the product and offer ongoing input. A related application that was 
developed and built is the automated Tactical Response Report (TRR). This report documents 
incidents in which force is used or resistance encountered. While this report is not part of the 
OPS/IAD portion of the Personnel Suite, TRR was developed in conjunction with it because 
sworn personnel will use this application to create, review, approve and track TRRs. Data 
relating to use-of-force events will be available in PPS. This application is currently being pilot-
tested. 

Medical Section applications were the first Personnel Suite modules to be developed 
because automating manual processes (as all Medical Section procedures had been) is less 
complicated than replacing legacy systems. Two such systems were launched in July 2003: the 
Medical Absence Reporting system, which is a role-based system for tasks performed by district 
personnel at all levels. General users, such as those working at the district front desk, can create a 
medical absence report (shown in Figure 7) for co-workers calling in to report an illness-related 
day off, while lieutenants have approval and return-to-duty information access. In addition, 
through this system lieutenants and watch commanders can view officers work status, create 
furlough requests and view information about officers medical absence history. Also automated 
is the supervisors request for a supervisor to make a home visit to check that an officer is home 
when unable to work due to illness. 


Figure 7
Create Medical Absence Report Screen
Image of Medical Absence Report Screen

Another facet of the application is used by Medical Services Section staff to schedule 
appointments, record progress notes (shown in Figure 8) and capture all information needed for 
medical records. Some data inputted by Medical Services staff, such as information about when 
officers are able to return to duty, is available to unit supervisors. Sworn users at all levels also 
use the Medical Services application to acknowledge a status change (i.e., returning to duty or 
going from medical leave to light duty) before they leave the Medical Services unit. Non
medical-condition-related information that is gathered via these systems can be tracked for 
managers by the Personnel Performance System. 

Figure 8
Medical Progress Notes Screen
Image of Medical Progress Notes Screen



As mentioned above, the Medical Absence Report system was launched in July as a pilot-
test in two districts. The speed with which the system was rolled out citywide was constrained 
only by the limited training staff available  one officer. The application was in use in all CPD 
facilities by November 2003. The Medical Services Section is the only unit using its portion of 
the application; that launch was accomplished in one day. 

The decision to make the Medical Absence Reporting system the flagship Personnel Suite 
launch was fortuitous. Recent local news coverage publicized the exceedingly generous allotment 
of CPD officers paid sick days as well as the apparent abuse of the policy by a small percentage 
of officers. Having this newly available, on-demand analytical data will not only be a powerful 
tool in current and future contract negotiations, but it also sends a clear message to the taxpayers 
and police officers that such excess and abuse will no longer be tolerated. 

Two portions of Personnels segment of the Personnel Suite are approaching the pilot 
testing stage. The Star Management application manages and tracks the Departments inventory 
of stars, badges and shields. The Tuition Reimbursement system automates requests for tuition 
reimbursement, supervisory review and approval of tuition reimbursement requests. In addition, 
it allows for entry of financial aid information and grades earned. Star Management is expected 
to be launched in early February 2004 and Tuition Reimbursement in early spring. 

Two other Personnel modules are actively under development. The first is an Awards 
application that automates the process of nominating officers for honorable mentions and awards, 
and generates notifications to winners. Also under development is the Emergency Notification 
application, which will enable all personnel to update records on individuals they name as 
needing to be contacted in an emergency. The focus of 2004 Personnel Suite development will be 
on automating personnel-related functions such as hiring, drug testing, leave of absence, position 
openings, etc. 

The Personnel Performance System remains in the conceptual stage, mainly because the 
other applications from which essential personnel data are extracted must be developed first. The 
Police Executive Research Forum (PERF) has been helping the CPD identify best personnel 
practices and policies from the public and private sectors nationwide in the human resources 
areas the suite will encompass. 

Because of the widespread impact of Personnel Performance System and the sensitivity of 
the information it will manage, an oversight committee meets on a regular basis to make 
recommendations and help guide the direction and development of the Personnel Suite. 
Composed of 11 key administrators and chaired by the CLEAR project manager, the committee 
has reviewed and evaluated PERFs findings for applicability and appropriateness within the 
CPD and will guide the institutionalization of new personnel-related policies and procedures. As 
part of their duties, committee members conducted three site visits at agencies where 
performance monitoring systems have been implemented. 


Though development costs for this multi-dimensional system will be substantial, funding 
has not been a problem for the Personnel Suite thus far. The project manager engages in ongoing 
grant-seeking to augment the money already earmarked by the Department for the applications 
development. And, because there will be no hardware expenses associated with the Personnel 
Suite, there will be no bottlenecks related to identifying vendors, seeking proposals and 
engaging in the bidding process. 

Training. Training for the four Personnel Suite applications currently in operation was 
conducted in largely similar ways. Instruction for using each was carried out at the various 
facilities where it was being introduced. The officer who comprised the then one-man training 
team guided administrative managers in using the Medical Absence Report application, and they 
went on to instruct their districts supervisors. Streaming videos (starring the training officer) 
provided instruction to general users, whose online tasks are quite simple. Medical Services 
Section staffers received one-on-one training when their application rolled out, and the trainer 
was available for ongoing support during the first few weeks of use. Training on the Tactical 
Response Report module began prior to its launch, because it is such a large-scale effort (each 
sworn member of the Department must be able to use the system). Two officers are handling this 
training effort, which will be held in each facilitys roll call room in several rotating sessions 
after the last roll call on each watch. 

The Future of the Personnel Suite 

The Personnel Suite can almost be considered the future of the CPD. While it is only a 
part of CLEAR, it is a vital system that will help the Department strategically deploy personnel; 
create accountability standards; identify problems within the ranks and offer early intervention; 
and remain poised to effectively address terrorism threats. 

A byproduct of automating the organizations human resource functions will be the 
ongoing need to address policy issues related to the collection, use and dissemination of data. 
The demanding task of developing and establishing sensitive, ethical policies is providing the 
Department with the opportunity to incorporate its best practices findings and policy-making 
experiences into a document that can serve as a model for other jurisdictions planning to 
implement automated personnel systems and performance monitoring programs. 

Rap Sheet 

In 1998, the Records Division production of CPDs handwritten or typed rap sheets was 
computerized. The automated rap sheet was an improvement, however it did have some 
deficiencies. Specifically, rap sheets often contained repetitive and unnecessary information 
displayed in a poorly designed format that made content difficult to read/interpret by both CPD 
officers and the Departments law enforcement partners. In late 2002, the CPD began to overhaul 
the design and programming format of its rap sheet. 

The Departments intent was to produce rap sheets that would be a useful tool for its law 
enforcement partners. The main challenge was that data transmission between the various 


agencies databases is usually impossible because each ones database is customized and reads 
information in a distinct and incompatible manner. To transfer rap sheet information without any 
problems and still allow police departments to maintain their own customized databases, the 
CPDs new rap sheet application would need to be programmed in Extensible Markup Language 
(XML), which enables efficient transmission, validation, and interpretation of data between 
applications and between organizations. Then, if partnering police departments had XML 
databases, data could be shared by each, and because of XMLs unique properties, the agencies 
customized databases would not need to be sacrificed. 

The CPDs overhaul design called for three development segments, the first of which was 
realized during this reporting period. The three segments are rap sheet redesign, establishment of 
an Illinois State Police (ISP) data feed and the similar establishment of an Illinois Department of 
Corrections (IDOC) data feed. 

Rap sheet redesign. The scope of rap sheet redesign was quite ambitious. It addressed 
the needed formatting changes to the printed report itself, enhancing the rap sheet system 
automation and reprogramming it in XML. The poorly designed layout was confusing and 
needed significant formatting and content changes to reduce wasted space and make the rap sheet 
more user friendly. Automation improvements largely affected the CPDs Instant Update Unit 
(IUU), which is contacted by officers who need the most updated version of an offenders rap 
sheet to help make decisions on charges. IUU manually reviews the dispositions of all of the 
offenders previous felonies using Cook County Clerks system, ISP rap sheets, the CPDs hot 
desk, Law Enforcement Automated Data System (LEADS) records and IDOC, FBI and other 
criminal justice agencies databases. After doing so, IUU officers manually wet ink stamp the 
paper copy of the updated arrestees rap sheet with one or more of its various stamps to indicate 
what their research determined. Once stamped, the updated rap sheet is faxed to the requesting 
officer. Because IUU stampings were not be generated electronically, updated rap sheet 
information was not captured in any permanent repository. Finally, the CPD recognized that 
while the much-needed cosmetic changes would improve its rap sheets readability, data 
transmission problems between police departments would remain. To address this, the CPD 
decided to incorporate XML transmission standards recommended in the Interstate Criminal 
History Transmission Specification, issued in 1998 by a Department of Justice-sponsored joint 
task force charged with creating a transmission format for criminal information sharing. 

The successful rap sheet redesign would make the document more user friendly, enable 
IUU officers to add computer-generated stamps; feed updated, queriable information into 
CLEAR; and transmit an updated copy to other agencies that were Interstate Criminal History 
Transmission Specification compliant. 

Illinois State Police Data Feed. The goal for this second development segment of the 
Rap Sheet application was to create a linkage with the ISP and merge CPD and ISP data to 
improve the quality of both agencies records. The ISP data feed would establish a real time 
direct link between the CPDs data warehouse and the ISPs Computerized Criminal History 
Database (CCH). This database link would automatically populate CPD rap sheet fields with 
updated ISP data. Thus, IUU would no longer need to perform exhaustive manual searches for 


information in the ISP database. This was considered a major streamlining of the process that 
would reduce IUUs workload and free up some of the units officers to return to street duty. In 
return, the CPD would provide the ISP with access to the CLEAR data warehouse for use in ISP 
investigations. 

Illinois Department of Corrections (IDOC) Data Feed. This data feed would be very 
similar to the one the established with the ISP, providing a direct link between the CPDs 
CLEAR systems and IDOCs inmate information database. From it the CPD would access would 
admission, sentencing, custody, gang and parole data. This link would also populate CPD rap 
sheets with prisoners updated release dates, terms of parole, new tattoos or marks and new mug 
shot, when appropriate. IDOC would similarly be given CLEAR data warehouse access to 
augment their internal investigations. 

Development 

In December 2002, a CPD project manager with technical expertise was brought on to the 
project to work on the new rap sheets conceptualization/design and begin development of the 
application. At the same time, the grant request process was underway. The grant went through 
many rounds of revision and resultant delays, but by early July 2003 a $1.2 million grant was 
awarded. Monies earmarked for the redesign would expire in September 2003, and the remainder 
of the money  to be used for development of the ISP and IDOC data feeds  would expire in 
June 2004. The CPD project manager originally believed the rap sheet redesign to be a four- to 
six-month project. So, with a newly imposed two-month window in which to complete the 
redesign, the project manager bypassed some standard CLEAR application development steps. 

Rather than holding JAD sessions and undergoing a lengthy conceptualization and design 
process, the project manager met with the CPDs Records Division and IUU for several days and 
used what was learned in those meetings to storyboard the needed graphical changes for the 
Oracle developers. The project manager brought sufficient manpower to the development team to 
meet the fast-approaching deadline. The development staff was composed of two full-time 
Oracle developers, an Oracle project manager, and a Information Systems analyst assigned to 
work on the rap sheet project part time. 

The rap sheet redesign was completed in the two-month timeframe. The three main goals 
were met  format reconfiguration, enhanced automation and XML programming. Layout 
improvements eliminated wasted space, added a central space for electronic IUU stamps, and 
aligned the columns more effectively. These changes made the rap sheet easier to use and 
significantly reduced the length of many rap sheets. Automation enhancements for the newly 
redesigned rap sheet enabled IUU to add stamps electronically via a web-enabled interface. In 
addition, the new application allows officers to receive rap sheets electronically. (While most 
officers currently still receive a faxed IUU rap sheet, the CLEAR Automated Arrest application, 
currently being piloted in one district, eventually will allow officers to request updated PDF rap 
sheets from IUU by clicking a Rap Sheet Report link.) The final automation enhancement 
allowed for electronic capture of IUU rap sheet updates and provides a mechanism for retrieval. 


This enables CPD Information Systems administrators to recreate IUU rap sheet updates for 
supervisors or others who review the cases charges. 

The final area of development  programming the new rap sheet in XML  was also 
completed by the target date. Oracle created a customized automated extraction program to pull 
information from the data warehouse and the digital mug shot application when rap sheet 
requests were made. The results are displayed in two formats  one in raw XML code for 
external agencies that are set up to handle XML tables, and the other in Hypertext Markup 
Language (HTML) format for easy viewing by most users. The XML code meets above-
mentioned standard set forth by the Joint Task Force on RAP Sheet Standardization, but as yet 
most agencies do not have the technological infrastructure in place to receive XML rap sheets. 
Because HTML rap sheets are not in raw XML format, they cannot be automatically incorporated 
into the receiving agencies criminal history record database. 

The Future of the Rap Sheet Application 

The new XML Rap Sheet application is functioning, but it is currently only usable by a 
few Information Systems employees and Oracle developers. The project manager is trying to 
convince partner agencies to become XML-enabled for requesting and receiving rap sheets. 
However, when this report was written there were very few XML-enabled law enforcement 
agencies and, therefore, few that will be requesting XML rap sheets. Until more demand exists, 
making the XML rap sheet available externally is not a priority for the CPD. Nonetheless, a goal 
for 2004 is to replace the PDF rap sheet reports (available via CLEAR) with the XML rap sheet. 
However, this will require the CPD to create another version of the XML rap sheet that will be 
tailored specifically to CPD users and partnering law enforcement agencies. 

The next development step for the Rap Sheet application focuses on the development of 
the ISP and IDOC data feeds, work on which has already begun. It is worth noting that by late 
2003, the CPD had been given a commitment from IDOC to include all CPD requested 
information  mug shots as well as gang, warrant and parole information  in its data feed. After 
the data feeds are established, the CPDs next most important step will be getting the ISP to 
agree to send its 4 million criminal history records to the CPD. Without those records, ISP arrest 
information predating the June 2004 implementation of the ISP data feed will not be reflected in 
the CPDs updated rap sheets. 

The XML rap sheet project will need to overcome some hurdles. First, the CPD does not 
know exactly what information they will be receiving from the ISP and IDOC; thus there is the 
possibility that the CPD will need to redesign its own rap sheet once again to successfully 
interface with ISP and IDOC. Also of concern is that CPD and ISP rap sheet records for the same 
individual/same arrest do not always match. An in-depth audit will need to be performed to 
determine the reason for this and correct it so the final rap sheet product reflects the most 
accurate rap sheet information from all sources. 


Lastly, the CPD is aware of software dependencies that must be corrected. Unlike XML, 
which was designed to facilitate the smooth transmission, validation, and interpretation of data 
between applications and between organizations, PDF can experience data transmission 
problems when different versions are used. And Oracle reports, like the ones used with the XML 
rap sheet, are also proprietary and do not have the look and feel of other CLEAR applications. 
Furthermore, the custom Oracle XML program cannot be used for any other user requested 
systems. This means that future CPD XML applications, even if they function exactly like the rap 
sheet application, will need customized Oracle XML programming. While there are third-party 
companies that create efficient and cost-effective XML programs that can handle multiple system 
tasks, the CPDs complicated contracting/vendor approval process makes pursing third-party 
solutions less than optimal. 

Integration of Criminal Justice Information Systems 

This aspect of CLEAR calls for developing a system that provides for a flow of data 
between the CPD and agencies in the Chicago area, including law enforcement, prosecution, 
courts, corrections and other interventions (presumably not criminal justice agencies) yet to be 
specified (see Figure 9). The main goals for Integration of Criminal Justice Information Systems 
are stated as: enable unified strategies to reduce crime, eliminate criminal justice system 
bottlenecks, increase accountability among criminal justice agencies and provide a complete 
picture of offender activity. The CPD believes that an integrated system would add value in 
terms of reducing crime and labor, as well as increasing the number of cases solved. Specifically, 
an integrated system would improve the capacity to police smart, share development costs, 
allow for single-system maintenance, reduce administrative labor costs, improve employee 
morale, strengthen relationships with the community, reduce liability costs and enhance the 
Chicago Police Departments reputation as a technology leader. 

Figure 9
Criminal Justice Information Sharing
Graph of Criminal Justice Information Sharing


The CPD conducted an 18-month impact analysis for one of its divisions within an 
integrated criminal justice model and found that its clerical work force could be reduced by 227 
and its technical work force by seven, thus producing an annual savings of $8.7 million. The 
analysis also concluded that 90 officers could be redeployed to the streets of Chicago. These 
findings, along with the Departments enthusiasm for a truly integrated criminal justice system, 
are moving this CLEAR project forward. 

Research on the Implementation of Integrated Criminal Justice Information Systems 

A great deal has been written about the benefits of implementing an integrated criminal 
justice system, providing reasons why such a system would be advantageous to many. It is 
claimed that faster data sharing among agencies would lead to quicker arrests, facilitate faster 
processing of criminals, expedite court cases and prevent crime. Such a system also would be of 
invaluable assistance in the case of a disaster, be it natural or manmade. 

However, many complications that can impede development of such a system have 
likewise been identified. For example, for agencies to share data, they must systematically collect 
and enter identical data elements and use compatible computer systems to ensure smooth data 
transmission. Historically, agencies have set up stand-alone systems and collected data useful 
solely to them. Because data entered into individual systems can also be incomplete or 
inaccurate, linking such systems can be highly problematic. And many lack a governance 
structure and function as individual agencies. 

Governance boards provide project review, implement initiatives, set policy, recommend 
funding, set standards, prioritize system changes and authorize software changes. However, the 
development of a governance board is often fraught with agency turf issues or dissolves in a 
political tug of war. The development of a governance structure needs the stewardship of 
someone who can champion and market the need for an Integration of Criminal Justice 
Information Systems effort; garner unconditional support from county, city and elected officials; 
and motivate others to jointly conduct strategic planning and consensus building. This can be 
challenging when there is scant natural consensus-building among jurisdictions or the politicians 
who serve them. Furthermore, if all stakeholders are not brought to the table during development 
of a governance board, there is likely to be diminished cooperation, buy in by participating 
agencies and, ultimately, trust among them. Eliciting agency participation in the development 
stage is a critical part of governance board evolution. Agencies not involved at this stage 
historically have strong concerns about changes that might result from having a governance 
structure and are less likely to support establishment of such. 

Funding constraints also contribute to agencies reluctance to get involved in data 
sharing. Smaller agencies often lack the resources or funding to purchase adequate computing 
systems, and may not be able to employ the technical support needed to run and maintain them. 
Other agencies cite privacy issues and data misuse as reasons for not participating in a fully 
integrated data-sharing program. While federal funding is available to alleviate smaller agencies 


resource problems, many of those jurisdictions use the funding to further develop and improve 
systems specific to their agency and, therefore, make no progress in the data-sharing arena. 

Among the larger questions in the creation of a integrated criminal justice system are: 
Who decides what data are important? Who controls the data? Who ensures that adequate 
quality-control mechanisms and safeguards against data misuse are in place? While the reasons 
for developing an integrated criminal justice system are highly convincing, the reality of doing so 
can be highly discouraging. 

Chicagos Criminal Justice Information Systems Integration Project 

The CPD has launched an Integration of Criminal Justice Information Systems 
recruitment effort headed by a retired lieutenant who now serves in a civilian capacity. The 
primary thrust of this project is to make arrest data from Cook County suburbs and the CPD 
available to any criminal justice agency in Illinois having a need for this information. Currently 
participating are 176 agencies including police departments, both in and outside of Cook County, 
the Cook County Sheriffs Office, the Illinois State Police (ISP), university police, and several 
federal agencies, all providing ongoing data, the earliest dating back three-and-a-half years. 

The head of the Integration of Criminal Justice Information Systems project spends 
considerable time visiting nonparticipating agencies to give presentations demonstrating the 
capabilities of the data warehouse. Though the CPD believes that criminal justice information 
integration and the formation of a governance board should be spearheaded by the State of 
Illinois, to date such efforts have not progressed beyond the discussion stage. The CPD was not 
willing to wait for that to come about, so it has moved ahead with criminal justice information 
integration activities with its current resources. 

There has been, however, an inter-governmental agreement entered into between the 
Cook County Sheriffs Office and the Chicago Police Department. About three-and-a-half years 
ago the Sheriffs Office obtained funding from the Office of Community Oriented Policing 
Services to help Cook County suburban and city police departments acquire Livescan fingerprint 
equipment, which enables them to scan fingerprints, as they are captured, into the Automated 
Fingerprint Identification System (AFIS). 

Additionally, during the summer of 2003, the governor of Illinois signed an executive 
order to form the Illinois Integrated Justice Information System (IIJIS) board. The board serves as 
the oversight of criminal justice integration efforts in Illinois and has met several times, though 
their relationship to Chicagos CLEAR system is unclear at this point in time. There has been 
recent discussion about the governor announcing a new system entitled I-CLEAR. The system 
would create a partnership between the Illinois State Police and the Chicago Police Department. 
Under I-CLEAR, there would be a federal investment of funds to push forward a web-enabled 
case management system for both partners, make the application available to all state agencies, 
and provide a mobile data terminal system for case management. As a result, statewide there 
would be one incident report, one arrest report, one follow-up investigation report and one 


criminal records system. The target date to have this system up and running is December 2004. A 
governance board would need to be formed and further legislation developed to bring the two 
agencies together. 

Currently, participating law enforcement agencies can tap into the CPD extranet to get 
online reports, detective information and streaming video training. The data warehouse contains 
13 years of Chicago Police Department data and, as mentioned previously, three-and-a-half years 
of data from the Cook County Sheriffs Office, the Illinois State Police and the participating law 
enforcement agencies. Figure 10 shows the offerings available to agencies. 

Each of the users has a unique ID, based on the National Crime Information Center 
(NCIC) numbering system. Participating agencies log on through the CABS or ISP network and 
key in the identification number, which is specific enough to check the integrity of users by 
agency and by person. If problems arise from one particular agency, more training or technical 
assistance will be provided. The CPD is currently providing training to interested agencies both 
in and outside of Cook County. Inquiries and training appear to be moving beyond state boarders 
to Indiana and to federal agencies. Each police agency determines who within its organization 
will use the system as well as who will receive training. Some agencies only want specific 
individuals to have access to the system, while others want it available to the entire department. 

Image of Agency Menu


In terms of criminal justice agency integration, the CPD is only involved with other law 
enforcement agencies or institutional police forces, such as those at universities. This is due to 
the fact that the data currently being shared are related strictly to arrest reporting. 

One of the impediments that the Department has come up against with this system, 
according to one key persons experience, is that all roads lead to firewalls, meaning that a 
central pipeline needs to be created for universal participation. Other obstacles to full 
implementation of agency integration include problems related to limited transmission bandwidth 
as well as the Data Systems Divisions current heavy workload. 

The Criminal Justice Integration Study 

As noted earlier, a central component of the strategic plan underlying CLEAR is the 
extension of its capabilities beyond Chicago. CLEAR is designed to support coordinated 
strategies to reduce crime by increasing the capacity of law enforcement agencies to police 
smarter. CLEAR also has the potential to help eliminate bottlenecks in the criminal justice 
system, through the frictionless flow of information between its elements as well as agency 
partnerships that can develop around creating and using that information. CLEAR also 
potentially increases the accountability of criminal justice agencies, because of the easy 
availability of integrated data. Everyone involved understands that these goals and the issues that 
underlie them are not confined to the boundaries of any city. 

In practice, the partnership is being formed by opening access to the CLEAR data 
warehouse to other agencies. This involves ensuring that they have the technical capacity to 
access the system and training representatives of newly participating agencies. Behind the scenes, 
Chicago had to create mechanisms to audit use of the system by outsiders and put in place 
procedures to ensure responsible use. 

Chicagos data warehouse is an information repository that can produce a variety of 
relational reports using modern, flexible database query software. The data warehouse includes a 
list of data elements that expands almost daily. There is data on the criminal history of arrestees, 
outstanding warrants, the arrest status of juveniles, mug shots, and digitized fingerprints. 
Participating agencies also have access to CPD directives, streaming digital training videos, 
email addresses and directories, to name a few early offerings. 

The criminal justice integration study examined the spread of data warehouse use during 
its first year. After a pilot test in six suburban police departments, the next outside users of the 
data warehouse were trained to use the system in October 2002. This report traces use of the 
system by outside agencies of all types over a 13-month period ending in October 2003. 

The study has two purposes. The first is to describe the scope of agency utilization of the 
data warehouse. This report examines the number of agencies involved, and how agency 
representatives were initially trained. It describes the utilization of the system, using the results of 
a user survey and accounting statistics generated by the data warehouse itself. There is a 
description of trends in the use of the system over time. A user survey gathered reports of the 
obstacles that agencies had to overcome to get involved, and measures of their satisfaction with 
the system and its administration by the city. 


The second purpose of the study is to explain variations in the timing and extent of data 
warehouse use. To do this we developed measures of organizational and community factors that 
past research suggested could either facilitate or discourage agency utilization of the data 
warehouse. This part of the study focuses exclusively on municipal police departments in Cook 
County. They were all offered access to the system, and the study investigated the factors 
associated with the extent to which they have done so in the first year. This study of the use of 
the data warehouse falls into a category of research that examines the adoption of innovation. 
Researchers have explored the acceptance of innovations ranging from hybrid seed corn to digital 
television. Compared to studies of producers or consumers of products in the private sector, there 
has not been as much research on the adoption of innovation by municipal government, and 
much less is known about why police departments choose to stray from the tried and true 
(Skogan and Frydl, 2003). 

The Data 

Information on the actual use of the data warehouse was extracted from the system itself. 
When access opened to outside agencies, the system was configured to log the agency of origin 
of each database query. In November 2003, CPD technical staff generated a report listing system 
use counts, by month, for each external agency. Not all were other municipal police departments. 
In addition to 145 municipal departments, use of the data warehouse had by then spread to 
federal investigating agencies such as the FBI (10 agencies), prosecutors offices (2), specialized 
policing units such as high school security offices and university campus police (6), county 
sheriffs (10), and probation and parole agencies (2). Another big user of the system is the Illinois 
State Police. Descriptions of data warehouse use include all of these organizations. In addition, 
some analysis focuses just on suburban municipal police departments. Figure 11 illustrates the 
location of the suburban departments using the data warehouse as of the end of October 2003. 

Map of Suburban Police CLEAR Users


Agency-level data were drawn from a number of sources. Some were located in official 
archives. This includes municipal crime reports (from the Illinois State Police), information on 
agency personnel (from the FBI), information on city populations in 2000 (from the Census 
Bureau), and agency participation in professional associations (from organization membership 
lists). Questions about other agency characteristics were included in the fall 2003 user survey. 

The other significant source of agency data was collected by a survey of users and 
potential users of the data warehouse. The survey was conducted to assess why agencies decided 
to get involved, to describe how they are using the data warehouse and to identify the obstacles 
that participating agencies faced. Agencies that had not signed up to use the system responded 
only to the first part of the questionnaire, which focused on their organizational capabilities and 
technological savvy. Those who had sent representatives for training answered additional 
questions that focused on use of the data warehouse. The first targeted respondent was the police 
chief. During their interview chiefs were asked to identify another agency member with more 
hands-on familiarity with using the data warehouse, and those nominees were also surveyed 
using essentially the same questionnaire. All of the interviews were conducted by telephone 
during autumn 2003. An advance letter to each chief described the project, and it included a list 
of some specific questions we were going to ask about agency staffing and budgets so they could 
prepare in advance. In the end, 141 chiefs or their designated replacements were interviewed, 
along with 134 secondary respondents. One or more respondents were interviewed in 142 
agencies. Because most agencies were represented by two survey respondents, their responses to 
the questions were combined to produce agency-level information. The agency-level response 
rate was 98 percent; the primary-respondent response rate was 97 percent, and the secondary-
respondent response rate was 92 percent. Details about this and other methodological aspects of 
the study are presented in a methodological appendix to the report. The questionnaires and other 
methodological details are available at our website: www.northwestern.edu/IPR/publications/policing.html 

Using the Data Warehouse 

Beginning in October 2002, the Chicago Police Department trained agency 
representatives to use the data warehouse. The training sessions were conducted at police 
headquarters in a room equipped with computers, and they took about three hours to complete. 
During the first 13 months, Chicago police trained about 245 representatives of suburban police 
departments alone. The average police department sent two people to be trained, and as many as 
five appeared from a single department. Table 1, which is based on the user survey, summarizes 
who the municipal police agencies sent for training. Most sent detectives or patrol officers, with a 
smattering of computer specialists. The actual number of system users in these suburban 
departments is much greater than 245, however. Outside access to CLEAR follows a train the 
trainers model. That is, agencies were encouraged to send just a few key personnel to be trained 
at Chicago police headquarters. They were expected, in turn, to take responsibility for training 
other users in their own departments. In the survey, 92 percent of police departments indicated 
that they had already done so, greatly multiplying the number of individual users of the data 
warehouse. 




Table 1
Assignments of Officers Sent for Training by Suburban Police Departments


Assignments of officers 	Percent 					Percent 
sent for training 		of Agencies 					of Agencies 

Patrol 				36 		computer specialists 		18 
Detectives 			64 		community policing 		2 
Narcotics, gang and 
tactical 			6 		Crime analysts or planners 	7 



Trends in Data Warehouse Use 

Participation in the CLEAR data warehouse is open to a broad range of criminal justice 
agencies at the federal, state and local level. Of the 176 users registered and participating by 
October 2003, 82 percent were municipal police departments, 6 percent (10) were federal 
agencies such as the FBI and the DEA, 6 percent were county sheriffs, 3 percent were specialized 
agencies such as university police, and the remainder were prosecutors and probation and parole 
agencies. A small other category included one heavy system user, the Illinois State Police. 

Figure 12 presents two views of the expansion of CLEAR to these agencies. The left 
panel illustrates how many agencies of all types were using the data warehouse by the end of 
October 2003. Monthly sign-on figures and the cumulative total number of agencies involved are 
presented there. A total of 28 agencies had been trained and were using the system within three 
months of the beginning of the initiative, and 64 agencies were involved within six months. In its 
peak months, such as June 2003, as many as 18 agencies gained access to CLEAR, and an 
average of about 13 new individual users were added per month. By October 2003, 176 different 
agencies had signed on. 

Figure 12 
Participation in CLEAR, All Agencies 2002-2003 
Line Graphs Showing Participation in CLEAR


The right panel of Figure 12 measures CLEAR participation by the volume of system 
usage. System usage is measured by database queries. For example, a user might start an 
investigation by typing in the nickname of a possible suspect. The user could then request a mug 
shot by clicking on one of the people identified by the data warehouse as using that name. This 
would be counted as two queries by the system. Figure 12 combines usage statistics for all 
partner agencies. Again, monthly system usage and the cumulative total use of the system by 
partner agencies of all kinds are presented there. In the first three months the relatively small 
number of new users had hit the system a total of almost 8,000 times, and the 87 agencies that 
were using it at the nine month mark passed 100,000. The peak month of use was the last one, 
October 2003. In that month the system was accessed nearly 42,000 times, and the total volume 
of system use had grown to more than 265,000 inquiries. 

Table 2 presents another look at data warehouse use. It divides system users into 
categories, and summarizes the average number of months each has been using the system and 
their average system use per month. This table excludes nine agencies that were trained quite 
recently and had not really begun to use the system. In an average month the heaviest users have 
been county prosecution, probation and patrol agencies and county sheriffs. Municipal and 
specialized police departments have been making an average of 160 to175 queries per month. 
The high levels of system use recorded by sheriffs is driven by Cook County, which uses the 
system more than 2,000 times each month. The Cook County States Attorneys Office is another 
heavy user, at more than 1,600 inquiries per month. The police department using the system most 
frequently ranked number three, averaging 1,220 inquiries per month. The two lightest users 
averaged fewer than nine queries per month. 

Table 2
Average Monthly Data Warehouse Use by Type of Agency

type of agency 		number of 	average months 	queries per 
			agencies 	using system 	month 
municipal police 	137 		6.6 		162 
specialized police 	6 		4.2 		175 
county sheriffs 	8 		3.8 		336 
federal agencies 	10 		6.5 		254 
prosecutors, probation 	4 		3 		440 
and parole 
state police 		1 		8 		3633 
other 			1 		12 		105 
total 			167 		6.3 		203 


Who Uses the System? 

Who are the heavy users? To learn what kinds of agencies are making the most use of the 
system we focused on a relatively uniform set of potential users  suburban police departments. 
Our study sample included all of the suburban municipal departments in Cook County, a total of 
122 agencies. These were the agencies included in the telephone survey of potential CLEAR 
users. Of the 122 suburban departments, 107 (or 88 percent) had sent officers to be trained and 
were able to access the system by October 2003. Once signed on, the departments varied widely 
in how intensively they were using the data warehouse. While the average agency was making 
about 160 queries per month, the maximum was more than 1,200 times per month, by an agency 
with 13 months of experience using the data warehouse. The lightest user was accessing the 
system fewer than 7 times per month. The average Cook County suburb had been using the data 
warehouse for 6.5 months by October 2003. 

The heaviest users were departments shortest on resources, measured by expenditures per 
capita. Heavy users also reported having limited computer-related funding. On the other hand, 
departments who reported that they signed up because access to the data warehouse was available 
without cost actually tended to use it less than others. Getting involved because people on staff 
were enthusiastic about doing so was related to heavier system use. Among suburban agencies, 
use per month increases with experience in using the data warehouse. Departments with a longer 
history of data warehouse access use it more, and places that do more varied kinds of things with 
warehouse data use it more (uses that agencies report making of warehouse data is discussed in 
the next section). CALEA-rated departments use the data warehouse more frequently, as do 
places where more officers have college degrees. 

Uses of the System 

What uses are being made of the data warehouse? To examine this, the user survey 
presented respondents with a check list of potential uses. Table 3 presents the percentage of 
agencies that reported using various features of the data warehouse. The most frequent use is to 
check mug shots (83 percent of agencies) and to do name and address checks (81 percent) or 
check suspects criminal histories (79 percent). Many fewer agencies report using the system to 
analyze crime patterns. 

The length of time that they have been using the system influences the variety of ways in 
which agencies find it useful. The more recently agencies have sent someone for data warehouse 
training, the fewer different kinds of uses they are making of the system. Early adopters use the 
system more every month. One reason is that early adopters have had more time to conduct local 
training on the use of the system, and having done more local training is related to broader use of 
the data warehouse. Agencies with a higher percentage of officers with college degrees also use 
the system in more varied ways. In addition, agencies that sent detectives for training found more 
ways to make use of it afterward. 



Table 3
Current Uses of the Data Warehouse

Current uses of the data warehouse 	Percent 		
					of Agencies 
Checking names or addresses? 		81 
Checking criminal history 
of an arrestee or suspect? 		79 
Checking for outstanding warrants? 	68 
Checking fingerprints? 			40 
Checking juvenile arrest status? 	49 
Analyzing a crime pattern? 		27 
Checking mug shots? 			83 

Near the end of the survey we asked respondents if they had a specific success story 
related to their involvement in CLEAR. The examples we gave them were to solve a particular 
crime patten or make an important arrest. Twenty-three percent indicated that they did. 
Interviewers gathered a sketchy report of the incident when they could, plus follow-up contact 
information. The stories frequently referred to using the data warehouse to identify otherwise 
unknown suspects using their nicknames or street names, or aliases they had already employed. 
Mug shots downloaded from the data warehouse were used in almost every investigation they 
described. One chief told of having pictures of a suspect circulating among his officers within an 
hour of the crime; another related to taking mug shots to a victim as he lay in the hospital. Many 
investigations involved using the photo lineup feature of the data warehouse, so that victims or 
witnesses could verify suspect identifications. Other departments began their search through the 
data warehouse with just a license plate number. This quickly led them to suspects names, 
addresses, mug shots, and nicknames, all of which were poured into the investigative mix. There 
were reports of crime clearances that began with fingerprints and tattoos stored in offender 
records, and arrestees with outstanding arrest warrants in their name. The types of cases solved 
were of a serious nature. There were many homicides, an occasional car-jacking, a kidnaping, an 
auto-theft ring, some drug-related crimes, and one previously closed cold case homicide was 
reopened. 

Issues in Using the Data Warehouse 

The survey also included questions about problems users may have had in accessing and 
using the system. The best news reflects the increasing ease of use of the internet and computer 
networks. A decade ago these would have been daunting challenges for most police departments, 
but in 2003 fewer than 20 percent indicated they had any problems initially connecting with the 
Chicago Police Departments data warehouse, and only 13 percent found they had to make any 
substantial changes to the hardware they already had. Somewhat more found they had to 
purchase some new software. The Chicago Police Department maintains a telephone Help Desk 
to assist its own CLEAR users, and suburban users can call it for support. In the survey, 57 
percent of agencies reported using the Help Desk to resolve problems they were having using the 
data warehouse. The Help Desk won wide praise; 92 percent indicated that their problems were 
resolved over the phone with Help Desk staff. 


Adjusting their organizations policies and procedures affected a quarter of all 
departments. This would have included issues (as seen in Table 4) about who has direct access to 
the data warehouse and how widely the information found there can be disseminated. 

The survey also asked whether agencies had any concern about misuse of the system by 
their own staff. Only eight percent did. Virtually all of the concern about misuse turned out to 
involve the unauthorized release or private use of information available through the data 
warehouse. When asked for details, respondents reporting a concern indicated that they were 
worried information might leak out, or be used for a personal reason, or be disseminated 
beyond the agency. Some noted that this is always a concern, and that it is nothing new 
except that the information comes from a computer. A few agencies volunteered that they have 
had bad experiences like this in the past, and one limited access to the data warehouse to only 
unit commanders because of an earlier problem. 

Table 4
Issues in Using the Data Warehouse

Issues in using the data warehouse 		Percent 
						of Agencies 
Problems in connection to the CPDs network? 	18 
Substantial changes to internal networks or 
internet connection? 				13 
Required to purchase new hardware or 
software to access the CPD network? 		22 
Required to change agency policies or 
procedures to use the data warehouse? 		25 
Concern about misuse of the system by their 
personnel? 					8 

Why Did They Sign On? 

The user survey asked about the perceived advantages of getting involved with the data 
warehouse. Respondents were presented with a list of possible reasons for gaining access to 
CLEAR, and were asked how influential each was in making the decision to do so. Table 5 
presents the results. Looking at the very influential category, the most important reason cited is 
that it is available with little or no cost. Fully 80 percent of agencies cited this as very influential. 
Other important influences were the perception that the system would help identify offenders 
coming from Chicago (74 percent), the opportunity to improve their officers skills (68 percent), 
and enthusiasm among the staff about participating (66 percent). Reading about this kind of 
technology in publications (8 percent) or hearing about at professional meetings (36 percent) 
were among the least important factors influencing the decision to get involved in CLEAR. 



One advantage for agencies participating in the system is that their access to the system 
should greatly reduce the frequency with which they have to request mug shots, arrest reports, or 
other information from Chicago, and subsequently send someone downtown to pick it up. Asked 
how difficult it was to get information from the Chicago police prior to the data warehouse, only 
18 percent of agencies rated it not very difficult. Another 59 percent rated it somewhat 
difficult and 23 percent very difficult. 

Table 5
Reasons for Participating in the Data Warehouse

Reasons for participating in the data warehouse 	Percent of 	Agencies 	Rating This: 
							Very 		Somewhat 	Not Very 
							Influential 	Influential 	Influential 

It was available with little or no extra cost? 		88 		8 		4 
Your agency heard favorable things about it from 
other suburban agencies? 				52 		16 		32 
Your agency expected to make fewer calls or 
visits to other jurisdictions in order to get 
information? 						46 		42 		12 
Your agency expected to identify offenders from 
the City committing crimes in your community? 		74 		24 		2 
Someone at your agency had read about this kind 
of technology in professional publications? 		8 		22 		70 
There was enthusiasm among your staff about 
participating? 						66 		22 		12 
Someone at your agency had heard about it at a 
professional meeting? 					36 		28 		36 
Using technology seemed to be the thing to do 
these days? 						59 		26 		15 
It was an opportunity to improve your officers 
skills? 						68 		28 		3 
It was an opportunity to improve your 
departments standing among other agencies? 		34 		30 		36 

In the beginning, an emerging issue in the interagency CLEAR partnership was 
governance. The Chicago Police Department moved ahead on its own, simply opening access to 
other agencies. Agencies could sign on without any out-of-pocket cost, but they had to accept the 
system as it was offered. Now other actors in the criminal justice system are pressing for 
oversight of this information-sharing process by some formal governing body. Some of them 
actually have resources to contribute, but they want a voice in how the system evolves.) To 


assess the current views of users, the survey asked, Are you comfortable with the Chicago 
Police Department spearheading ths integrated criminal justice information project, rather than 
the county or the State of Illinois? In total, 97 percent of agencies indicated that they were 
comfortable. 

Local Attention to CLEAR 

Another section of the questionnaire focused on the visibility of CLEAR in these 
suburban communities. Respondents were asked if they had brought their involvement in the 
system to the attention of their local community. Table 6 presents four examples that they were 
given, and the percentage of departments that had disseminated information about the data 
warehouse locally. The most common was to report about it to the citys elected officials and 
managers, and almost 20 percent indicated that they had brought the data warehouse to the 
attention of citizen advisory committees. 

Table 6
Local Attention to CLEAR

Since you began using the data 			Percent 
warehouse, have you . . . 			of Agencies 

Brought it to the attention of the mayor, 
manager or city council? 			53 
Issued a press release or described it to a 
local community newspaper? 			9 
Brought it to the attention of any citizen 
committees or advisory boards? 			18 
Reported about it in a newsletter for the 
public? 					9 

Conclusion 

Use of the CLEAR data warehouse has spread widely and rapidly. In just over a year it 
was adopted by almost all Cook County police departments and county agencies, units in many 
surrounding counties and important federal agencies. The Illinois State Police are particularly 
heavy users of the system. Almost every month brings a new record for system use, and the 
longer agencies participate, the more they use it and the more uses they find for the data. Our user 
survey found an almost unanimous thumbs up response to the data warehouse and its 
administration. Among the specifics, we found that detectives currently are the biggest and most 
creative users of the warehouse, and that mug shots and criminal histories are among the most 
popular products it offers. We have also learned that suburban police agencies are using the 
system to solve very serious crimes, ranging from homicide to robbery to car-jackings. Virtually 
everyone is comfortable with the Chicago Police Department taking the lead on this project. To 
date, Chicago police have borne the cost of creating and maintaining the system, and the user 


survey found this was an important factor encouraging participation. One issue that bares close 
watching is whether the administrative safeguards put in place by its many new participants 
prevent substantial misuse of the data. Another is how governance of the network of cooperation 
that has grown up around the data warehouse will look as adoption of the system spreads even 
further. As new entities begin to contribute to its funding there will be calls for changes in the 
system to accommodate their priorities. 

Methodological Appendix 

This appendix presents more details on the 2003 criminal justice agency survey. 

Questionnaire Development 

The questionnaire was designed to handle both of the studies described above. General 
questions that were to be asked of all agencies were grouped in the first half of the questionnaire. 
These questions focused on their organizational capabilities and technological savvy, factors that 
were hypothesized to have contributed to their decisions regarding participation in the data 
warehouse. Midway through the interview respondents skipped to the end of the questionnaire if 
they were not a participating agency. Participating agencies were presented with questions about 
their decision to get involved; who was sent for training; obstacles they had to overcome to 
become users of the data warehouse; and their experiences using the system. 

The questionnaire development process began with interviews with agency 
representatives and Chicago Police Department personnel involved in the data warehouse. Even 
before the survey was planned, our technology evaluation had included meetings and one-on-one 
sessions with senior police executives, project managers, and technical personnel working on 
data warehouse projects. The survey development process then added personal interviews with 
selected suburban police chiefs and technical personnel, to gather impressions of their 
experiences with the data warehouse. These interviews were conducted in the northern and 
northwestern suburbs, and represented municipal agencies that had been using the system for at 
least several months. Later in the process, a draft questionnaire was administered by telephone to 
an experienced retired police chief. One of our staff members conducted the interview, while 
another sat behind him and took notes during the process. They then held a debriefing session 
that examined each item in the questionnaire. The pilot test gave us a final check on the length of 
the interview and identified questions that could be eliminated or changed. 

Our discussion with the former chief also led to the inclusion of additional materials in 
our advance letter. The letter ultimately included more detail about what the survey would cover, 
so respondents could think in advance about the many organization-specific questions we would 
be asking. We also included a list of 17 specific operational statistics or budget figures that 
would be covered, and asked respondents to have the figures complied in advance of our call. 

The literature on adoption of innovation and experts in the field were tapped for 
suggestions for questionnaire content. The questionnaire included several questions about 
information technology in the department, including whether the department was NIBRS 


compliant. We asked about a list of specific equipment, as well as about who uses it. There was a 
section on budgets, grants, number of personnel, types and characteristics of personnel, as well as 
crime and arrest figures that are not available from the Illinois State Police. The questionnaire 
also probed about interagency contact and policy. 

The second section focused on use of the data warehouse by agencies that had sent their 
staff to Chicago police headquarters for training. This section probed about who had been to 
training, who had been trained at their department, what features of the warehouse were being 
used, problems they might be experiencing, and their most important reasons for deciding to get 
involved with the data warehouse. A short section of the questionnaire addressed those who had 
not signed on to the data-sharing project, asking why they chose not to participate. The secondary 
questionnaire was identical to the primary questionnaire, except for the questions on budgets and 
operational statistics, and on the chiefs participation in professional conferences. 

Interviewer Recruitment, Training and Supervision 

Five experienced interviewers were hired to conduct the study. Their efforts were 
supplemented by three full-time members of the evaluation staff, who also served as supervisors. 
The survey was conducted in the building where the project is housed. Interviewers worked at a 
desks which were in close proximity to the staff members serving as supervisors. Two of the 
interviewers had worked with us on earlier surveys projects, and three had telephone 
interviewing experience in other professional settings. Training took place in late September 
2003. At training, all materials were explained, pilot-test experiences shared, and role playing 
conducted. Supervisors were able to work one-on-one with the interviewers during the role 
playing session. Materials handed out included introduction respondent selection sheets, 
responses to frequently asked questions, sample call sheets and questionnaires, and a copy of the 
letter sent out in advance of the interviewing. Interviewers were monitored each time they 
worked to insure thorough and consistent data collection. Supervisors were always on hand to 
handle questions as they came up. 

Our survey methodology involved sending an advance letter to the chief of police for 
each agency in our sample. The letter explained the nature of the survey, underscored its 
importance in law enforcement, sited the support by the Chicago Police Department for our 
evaluation efforts, and gave a name and number for any questions the police chief might have. 
Also included was a page of questions that we believed would take some amount of checking or 
research on the part of the agency. The questions included items like the agencys budget, the 
number of officers with college degrees, and a number of inquires about crime statistics for the 
prior year. The letter was sent one week prior to the start of our interviewing. Interviewing began 
on October 1, 2003 and ended on November 7, 2003. After interviewing for several weeks we 
found a number of agencies for whom we had not been able to speak with the designated primary 
respondent. We sent out a second letter and the additional page of questions to that 20 percent to 
stress the importance of their participation and timely response. This yielded many completions 
from those agencies. One thing we did not anticipate was the number of times we would need to 
fax the additional page of questions to these agencies. Often the respondent had not seen this 


page and could not answer the items off the top of his or her head. Thus, we had many 
questionnaires in various stages of completion, waiting for answers to the budgetary and crime-
statistic questions. This became a very task-intensive part of the survey process, for each agency 
had slightly different ways in which they would handle how the information got to us. While 
many promised they would fax it, we often found ourselves following up via the telephone after a 
fax did not arrive. Another task-intensive activity was the fielding of calls themselves. While we 
had a staff of interviewers that were in both mornings and afternoons, interviews still needed to 
be scheduled for times when interviewers did not work, which were handled by the supervisory 
staff. These calls were often conducted in the late evenings or early mornings to accommodate 
the 24-hour nature of police schedules. 

As the sample was dwindling and fewer interviewer hours were required to work through 
it, we still had a core of agencies for whom we had not contacted the designated respondent. Our 
last effort involved sending a third letter and the full questionnaire via overnight courier to that 6 
percent of the agencies in our sample. This time we also gave out a telephone number 
respondents could call to reach us and be interviewed at their convenience. A stamped self-
addressed envelope was provided to them to return our questionnaire. Again this proved to be 
somewhat task intensive on the supervisory staff because interviewer hours were not as extensive 
at this point and the phone had to be monitored during working hours. For off-hour calls, the 
telephone was equipped with voice mail. This again proved to be successful in that it jump 
started many of those agencies to either call in to our office or mail in the completed 
questionnaire. 

The Sample and Survey Completion Rates 

The survey had two purposes. One was to gather descriptive information concerning the 
use of the data warehouse by police departments. For this study the universe was the 129 
municipal police departments that were registered to use the system on September 1, 2003, 
regardless of their location. This was a sufficiently small enough number that we included all of 
them in the survey sample. The second purpose of the survey was to gather data to explain the 
extent of use of the system and why some agencies had chosen not to participate at all. To 
examine non-use requires a sample that includes both users and non-users. For this study the 
universe was all 122 suburban municipal police departments in Cook County, Illinois. Again, this 
was a small enough number that we included all of them in the survey sample. The two studies 
overlapped, so a total of 145 municipal police agencies were included in the sample. 

To represent these agencies, our primary respondent was the chief of police. The primary 
respondent was asked to identify another agency member with more hands-on familiarity with 
using the data warehouse, and they were also interviewed using essentially the same questionnaire. 
All of the interviews were conducted by telephone. 

Field work was conducted from October 1 until November 7, 2003. The primary 
questionnaire took approximately 17 minutes to administer, while the secondary took 
approximately 12 minutes. At the end, two completion rates are appropriate for the study: the 


percentage of sample agencies who were represented by at least one interview, and the 
percentage of all designated primary and secondary respondents who were successfully 
interviewed. We began with a list of 146 agencies, but found during interviewing that one was 
ineligible for inclusion in the study universe because all of their operations are handled by the 
Cook County Sheriff. This reduced our agency sample by one and the total number of possible 
interviews by two. During the course of interviewing, two agencies refused participation, one 
because it was moving the location of their office and the other simply stated that it declined to 
get involved. We were unable to conduct interviews with anyone at three more agencies, despite 
never getting a clear refusal. The primary respondents for eight agencies denied that there was 
anyone else who was suitable for a second interview. One agency is represented by a secondary 
respondent nominated by the chief, but we were unable to complete the chiefs interview. 

Table A-1 summarizes the calculation of response rates for the survey. Of the 145 sample 
agencies eligible for interviewing, we completed one or more interviews with 142, for a 98 
percent completion rate. Of the 145 potential primary interviews, we conducted 141, a 97 percent 
response rate. The 134 secondary respondent interviews yielded a response rate of 92 percent. 

Table A-1
Survey Response Rates

					Agency 		Personal Interview 
					Rate* 		Rate 
					agency 		primary		secondary
					level  		interviews  	interviews 
a. eligible sample list 		145		145		145
b. Minus non-completions 		21		22		821
denied other respondents 		
refused to participate 
never completed interview 
c. Completed cases 			142		141		134
d. Response rate (c/a) 			98		97		92

* One or more interviews in an agency. 

Data Organization and Reliability 

An important feature of the survey was that many agencies were represented by two 
respondents rather than one. The data was collected in order to characterize agencies, To turn the 
survey findings into agency-level data, survey responses for two-respondent agencies (94 percent 
of the agencies) were combined. For many questions, the responses of the primary respondent  
almost always the chief of police  were used to represent the agency. This was especially true 
for the first part of the questionnaire, which focused on policy issues and agency-level matters. 
For these questions, answers from the secondary respondent were used if the chief did not know 
the answer but the follow-up respondent did. The responses of many other questions could be 
combined directly, for they were designed to use each of two respondents as independent 


reporters. Because the two respondents saw their department from different vantage points, they 
each had unique information to supply. A good example was presented earlier. Each respondent 
was asked about the uses their officers were making of the data warehouse. The list included 
such uses as checking for outstanding warrants and checking mug shots. For this question, 
information from either respondent that officers were using the data warehouse for a particular 
purpose was recorded. In the end, 142 agencies were represented by at least one survey 
respondent, and the data are used here to describe agency reactions to the data warehouse. 

In addition to minimizing missing data at the agency level and maximizing the 
information that can be gleaned from respondents who are somewhat differentially positioned in 
the organization, the paired character of responses to the survey enables us to evaluate the 
reliability of the survey. Data reliability can be examined by comparing the stories provided by 
pairs of respondents who are describing the same organization. If they generally agree when they 
describe their organizations features and activities, we have confidence that the survey 
accurately represents reality. Technically, this is an inter-observer agreement approach to 
reliability estimation. 

Table A-2 presents estimates of the reliability of responses to 17 questions included in the 
first half of the questionnaire. Figures given there are the percentage of responses to each group 
of questions that were in agreement. These questions were presented to all respondents, 
regardless of their involvement in CLEAR. Respondents who reported they did not know the 
answer to a question were omitted from each paired comparison. For the two questions regarding 
how frequently agencies were in contact with one another seeking information, five-category 
responses were dichotomized into once a month or less often versus more than monthly. 

Table A-2
Survey Reliability: Agency Characteristics

Paired survey questions; all agencies 			Percent 
(133 agencies) 						Agreement 

Availability of computer equipment, computerized 
dispatching, and crime mapping (4 questions, 523 
responses) 						82 

NIBRS compliance, Internet, e-mail, training and 
systems management 
(5 questions, 710 responses) 				80 

Agency newsletters, advisory boards, written policies, 
dispatching analysis, voice mail for officers 		82 
(6 questions, 759 responses) 

Frequency (dichotomized) with which agency contacts 
other agencies for information, and frequency with 	83 
which agency is contacted by other agencies 
(2 questions, 250 responses) 


Levels of agreement between pairs of respondents were acceptably high. In the computer 
equipment category there was less agreement about the availability of handheld or portable 
computers than about whether agencies had computer terminals in their cars, a computer aided-
dispatch system and computerized crime mapping capabilities. There was a great deal of 
agreement on whether agencies had access to a skilled systems manager (85 percent) and e-mail 
(81 percent), but not over whether their agency was NIBRS compliant (67 percent). Agreement 
was very high about having written policies for vehicle pursuits and firearms use (96 percent), 
but not over whether their department has a newsletter for community members (64 percent). 

Table A-3 presents a comparable table that tracks agreement between respondents 
concerning data warehouse issues. These were asked only of participating agencies, 117 of which 
were represented by two respondents. In the case of the check list of 10 questions regarding the 
reasons agencies chose to participate in CLEAR, the three-category responses were dichotomized 
into no influence versus somewhat or very influential. 

Levels of agreement were not as high for these issues as they were for general agency 
characteristics. They were lowest for the uses that officers were making of the data warehouse. 
This is perhaps expected in agencies in which chiefs are fairly removed from day-to-day 
operations. There was more disagreement over whether officers were checking warrants (58 
percent) than there was over mug shots (96 percent) or name checks (92 percent). In terms of the 
reasons for participating in the data warehouse, there was most agreement over the importance of 
identifying Chicago offenders, cost issues, and its impact on officer skills (all over 90 percent 
agreement). There was less over the importance of professional meetings and reading about 
technology in publications (both in the 50 percent range). Among the questions about problems 
in making use of the system, there was the most disagreement over whether agency policies and 
procedures had to be changed as a result (69 percent), and the least disagreement over hardware 
and internet access issues (all over 80 percent). 

Table A-3
Survey Reliability: Data Warehouse Issues

Paired survey questions; participating agencies 	Percent 
(117 agencies) 						Agreement 

Potential problems in accessing and using the data 
warehouse (5 questions, 410 responses) 			76 

Uses officers are making of the data warehouse 
(8 questions, 622 responses) 				72 

Factors influencing (dichotomized) the decision to 
participate in CLEAR (10 questions, 891 responses) 	75 

Local interest in the data warehouse (4 questions, 
319 responses) 						76 


Experiences in the Field 

There are several considerations when conducting an in-house survey of this nature. The 
interviewing staff must have experience with interviewing professional respondents. Many of the 
chiefs in our sample had an army of gatekeepers to protect them from unwanted calls, and ours 
often were in that category. Our interviewers often faced frustrating and unusual circumstances, 
and they needed to maintain a professional demeanor and accommodate many different 
respondent styles. One respondent yelled out to others in the office for help during the interview. 
Other respondents insisted upon looking up the answers to many questions while we waited on 
the telephone. 

A dose of persistence and creativity was also necessary when dealing with those who 
were resistant to responding to the survey. Our interviewers had to be flexible as they 
approached each agency, for they had many unique ways of handling non-emergency incoming 
calls. One example was when interviewers were confronted with the nobody knows anything 
about this issue response when requesting an interview. With careful coaxing and probing, we 
were almost always able to conduct interviews, and we found respondents in fact had ample 
knowledge of the subject matter. While their initial response may have been an attempt to avoid 
the survey, most respondents reacted positively to the questionnaire once they were engaged in 
the process. That said, in eight agencies where we did complete an interview, the chief indicated 
that there was no one else in the organization who could answer our questions and refused to 
nominate a secondary respondent. Some respondents were called back as many as 20 times. 
However, our experience was that once we did get the respondent on the telephone, they were 
highly cooperative and pleasant; they were often just very difficult to nail down. This was true of 
secondary respondents as well, because many of them worked as street supervisors. They 
sometimes had to be called at odd hours, and they frequently were not in the office. We 
interviewed respondents as early as 5 a.m. and as late as 11:30 p.m. Some were helpful and 
provided cell phone numbers, allowing us to contact them even while they were out of the office. 
In a few instances we tried to interview officers who had attended training at Chicago Police 
headquarters as substitutes for unavailable secondary respondents suggested by the chief. 
However, they proved to know little about the organizational and policy issues that were the 
focus of the survey. In two cases we were unable to carry out an interview by telephone, but we 
did receive completed questionnaires after we express mailed them to the agency. 

Flexibility and team work was of the utmost importance due to the individualized 
treatment required to handle each responding agency. And because this was an in-house project, 
our regular project staff had to allow for ample time for the survey, which intruded on their other 
duties. We found ourselves faxing specific questions to agencies multiple times, because the 
paperwork got lost or was passed on to people who had no knowledge about our project. Calling 
one person did not necessarily get us to the person that was compiling the information that we 
requested in advance. We needed to make adjustments when speaking with agencies that were 
small and structured quite differently than the larger agencies. In those, one person often takes 
on many roles, such as when the chief is also the chief computer technician, or when outside 
consultants serve as the agencies computer expert. In those cases we needed to make calls 
outside the department to get some of our technical questions answered. 


Community/Business Partnership 

The Chicago Police Department proposed the Community/Business Partnership as a 
component of the CLEAR initiative in order to: 1) enhance problem-solving capacity, 2) improve 
community needs assessment, 3) make information sharing easier and more convenient, and 4) 
gather more intelligence through community sources. The creation of a sophisticated Web-based 
system for communicating with the public also has the potential to help the CPD achieve several 
management objectives under CLEAR, especially in the areas of accountability and strategic 
planning. Strategic management in the 21st century covers a broad range of proactive functions, 
including crime control, order maintenance, fear reduction, public satisfaction and accountability. 
In theory, the systematic collection, analysis, utilization and dissemination of new community-
based data, reported via the Internet, holds the promise of empowering both police officers and 
local residents involved in the process of proactive problem solving and community crime 
prevention. 

At present, the Community/Business Partnership component is in the conceptual stage. 
The Department expressed a commitment to move ahead with the planning phase, and the 
evaluation team at the University of Illinois at Chicago (UIC) provided the CPD with research 
assistance. The CPD and the research team engaged in several tasks. First, they conceptualized 
some key information components of Web-based communication with the public. Second, UIC 
engaged in a formative assessment of a web-based survey component by exploring community 
interest and readiness for Internet communication with the CPD. This included gathering 
information about residents access to the Internet, usage of the current CPD Web page and 
reactions to a preliminary Web-based survey. Third, the CPD and UIC proposed a 
demonstration and evaluation plan for field-testing this new initiative. Each of these research 
activities and corresponding results is discussed below. 

Significant progress has been made on a plan for expanding the Internet link between the 
CPD and Chicago communities. Regular meetings have been held among CPD and UIC 
representatives. As a byproduct of this dialogue, a working committee was created to continue 
this process and to develop an overall plan for this part of CLEAR. To assist in this process, UIC 
prepared a PowerPoint presentation for the CPD. A concept paper was also prepared 
(Rosenbaum, 2004), describing the value of a comprehensive Web page that would include at 
least five key components: 

Problem reporting. This component would afford Chicago residents the opportunity to 
formally report crime and disorder incidents to the CPD over the Internet. Citizens participating 
in monitoring could be invited to: 

 Submit and obtain traffic crash reports 
 Make initial reports of minor criminal activity 
 Report persistent disorder problems 
 Report suspicious activity 





Citizen monitoring. Through Web-based surveys, this unique feature could provide the 
CPD with a mechanism to enhance the police-community partnership initiated with CAPS and to 
institutionalize past efforts to measure what matters in 21st century policing. Citizen reporting 
could supplement Citizen ICAM, beat meetings and district advisory committees as a method for 
collecting information about a wide variety of issues that are of concern to both the police and 
community. A citizen monitoring program, using random samples of citizens selected to monitor 
and report conditions in their police beat on a monthly or bi-monthly basis, could be designed to 
achieve the following objectives: 


 Assess neighborhood conditions and emerging threats 
 Assess citizen performance in community activities 
 Assess police performance on a range of dimensions 
 Evaluate anti-crime interventions 
 Offer public safety recommendations 

Neighborhood profile report. To further the dialogue between police and residents, the 
CPD could provide analysis and feedback based on the information that they accumulate from all 
sources, creating a two-way flow of information between the parties. The Citizen ICAM 
component of the citys Web site is one step in this direction. A neighborhood profile report 
could provide the community with: 


 Crime information on incidents and arrests with geographic location (e.g. ICAM) 
 Citizen monitoring results such as neighborhood and beat profiles, performance 
indicators and community survey results 
CAPS Online. This potential feature, designed specifically to enhance community 
policing in Chicago and to facilitate direct communication between police and community 
members, could have several features: 


 Provide CAPS information such as meeting times, locations, agendas and guest speakers 
 Host chatrooms, listservs and message boards 
 Provide an automated problem-solving module for Problem Oriented Policing (POP) 
projects (including a training tutorial to strengthen the integrity of the CPDs five-step 
problem-solving model). 


Public service links. This component would allow the CPD to link residents to other 
public safety services online and assist them in finding help with other problems. Links would 
include sites with information about social, educational, health, employment, legal and public 
safety services to help build individual and community competencies. 

At this point the CPD does not have funding to move forward with the full 
Community/Business Partnership. Funding is currently being sought from local foundations, with 
the hope that it might be in place by late 2004. However, under the leadership of a deputy 
superintendent, the CPD will move ahead and test the feasibility of a comprehensive web-based 
survey in three beats. If this demonstration is successful and this knowledge is transferred to large


scale implementation, Chicago will become the first police department in the nation to begin 
systematically measuring, on a geographic basis, the publics perception of crime and disorder, 
anti-crime programs, citizen responses to crime and police performance. This web-based data-
sharing project, in combination with other educational and technical assistance strategies, is 
expected to enhance joint police-citizen problem-solving, crime-fighting and crime prevention 
activities at CAPS meetings during 2004. In turn, this process is expected to result in greater 
organizational transparency and accountability, as well as greater mutual trust and respect. 

The CPD is also testing the notion that this data-driven strategy will help build 
community capacity and sustain recent gains achieved by aggressive police action. Thus, the 
expectation is that new information, when combined with technical support and public education, 
will help mobilize and sustain community involvement after swift police tactics reduce crime hot 
spots in specific neighborhoods. Hence, this demonstration will occur within the existing CAPS 
infrastructure and the comprehensive CAPS model, with the potential to increase the 
effectiveness of CAPS and the CPD in general. The research team will monitor the 
implementation and impact of this demonstration project. 

Currently there are three other CLEAR applications  at varying stages of development  
that fall under the Community/Business Partnership umbrella: Automated Pawnshop, which is in 
the conceptual stage; Auto Theft Recovery, which is developed, but awaiting contract approvals; 
and Traffic Crash Report, which is partially implemented, but awaiting more funding. Each is 
described below. 

Automated Pawnshop 

This application, currently in the conceptual stage, would develop a mechanism for 
pawnshops to provide online inventory reports, which would then be cross-checked against case 
reports and Evidence and Recovered Property Section (ERPS) inventories. 

Auto Theft 

The Auto Theft application will provide law enforcement agencies in Illinois with a 
geographical analysis tool for examining patterns of automobile theft and recovery. Officers will 
be able to use the application to graph all auto thefts in a specific area during a specific time 
frame. It is envisioned that the Auto Theft application will enhance the CPDs Citizen ICAM 
(discussed elsewhere in this report), by allowing the general public to find recovery information 
pertaining to their automobiles. 

Each time an auto theft is documented in Chicago, a report is filed with the CPD and the 
ISP. The two agencies have different methods of capturing auto theft data, thus auto theft/recovery 
data for the same incident can differ substantially in each agencys records. For example, under 
the current system if a car stolen in Chicago is later recovered by the ISP in another jurisdiction, 
there is no guarantee that the CPDs records will reflect that the car has been recovered. To 
provide users with meaningful functionality, the Auto Theft application must be able to accurately 
record where and when a vehicle was stolen as well as where and when it was recovered. 


Recognizing the need for an accurate stolen automobile accounting system, the applications 
project manager requested an audit in April 2003 to determine why the CPD and ISP had different 
data, and to try to determine if there was a remedy. Getting the answers to this audit as well as the 
necessary hardware and software was the first step toward developing the application. 

Development 

In early 2003 the CPDs geographic information system (GIS) manager was given 
responsibility to oversee development of the Auto Theft application. Prior to that, the project had 
been conceptualized, but development had not begun. 

Over the course of the next six months there were many setbacks to the development of 
the Auto Theft Application. The audit, which was delayed numerous times, eventually 
determined that ISP and CPD data capture methods for recovered automobiles was not 
reconcilable and that it would not be cost-effective to correct the two data sets for comparison. 
Without reconciled data, a car that is labeled stolen in Chicago by the CPD and later recovered 
by the ISP (or vice versa) would most likely not be accurately recorded/displayed by the CPDs 
Auto Theft Application. The only known fix for this situation is to merge the two agencys auto-
theft recordkeeping databases into one system for the entire state. As of November 2003, 
discussion of this solution isnt even on the table. Another significant setback was the 
bankruptcy of the CPDs procurement contractor, which caused a major delay in purchasing the 
Auto Theft applications servers and software. The servers were eventually purchased through a 
new vendor, but due to a contractual hitch, that vendor could not supply the software required to 
develop and run the application. The CPD has funds to purchase the software but the City of 
Chicagos complicated vendor/contract approval process has brought development to a halt. 

An additional matter that may have an impact on the Auto Theft applications 
development timeline is that some CPD administrators have expressed the concern that the 
applications data transmission pipeline would be open all the time, potentially presenting 
security problems. However, the applications project manager does not share their view, because 
the same data transmission pipeline that would be used for the Auto Theft Application is already 
successfully being used by outside agencies to securely access the CPDs data warehouse. 

The Future of the Auto Theft Application 

At the time this report was written, data reconciliation problems, software ordering 
difficulties, and security concerns present formidable obstacles to the completion of the Auto 
Theft Application. It is possible that these hurdles may not be overcome in the near future. If 
these issues are resolved, the application will provide a new tool for examining patterns of 
automobile theft and recovery. In addition, if the Auto Theft application is completed as 
envisioned, the general public should be able to use Citizen ICAM to find recovery information 
pertaining to their stolen automobiles. 


Internet Crash Report Routing System 

The CPD is developing a comprehensive traffic crash report-related application 
composed of three modules. One module will automate the traffic crash reporting process and 
wirelessly transmit reports from officers PDTs directly to appropriate Department units and the 
data warehouse. A second module will feed traffic crash report information to the Major 
Accident Incident Section (MAIS) for follow up investigations. An application that automates 
traffic crash report retrieval and fulfillment of requests for report copies is the third module of 
this system. Initial-stage development of this application, the Internet Crash Report Retrieval 
System (ICRRS), is underway. 

On average 500 to 700 traffic accidents occur each day in Chicago, with each accident 
usually producing multiple report requests. The majority (60 to 70 percent) of the requests come 
from insurance companies, and the remainder are from internal units within the CPD, city 
agencies, private citizens and other law enforcement agencies. Under the CPDs current process, 
labor costs for report processing and retrieval are very high: the Department employs 
approximately 36 workers to process, read, code and make 62 million photocopies per year. To 
offset this expense, the Department charges a $5 fee per traffic crash report copy. 

Three years ago the CPD began electronically scanning traffic crash reports and storing 
them in tagged image file format (TIFF). These files  essentially photographs of accident 
reports  are stored electronically, but function as copies rather than queriable documents. 

The CPD intends to use ICRRS to make traffic crash report retrieval more efficient, 
economical and customer-friendly. The Departments three goals for this new system: get out of 
the printing business; reduce the number of individual requests from the three main stakeholders, 
particularly insurance companies; and eliminate the need to retrieve reports for city agencies. 

The benefit of developing ICRRS, in addition to providing customers with a more user-
friendly system, is an approximate 158 percent return on investment over the first five years of 
the systems use. The efficiency of ICRRS is expected to reduce insurance company report 
requests by 50 percent, consequently reducing the CPDs personnel needs by 25 to 35 percent. In 
essence, ICRRS has the potential to automate a substantial portion of the report-retrieval process 
and drastically reduce the CPDs labor cost. 

Development 

The CPDs Information and Strategic Services team filled the ICRRS project manager 
position with a former CPD officer that had been working as a civilian traffic analyst. The 
program manager began to conceptually redesign the traffic crash reporting system in early 2002 
by meeting with representatives from insurance companies to elicit their suggestions for a new 
report retrieval system. The analyst also met with the CPDs Records Division director and 
processing staff; network managers were also interviewed to discuss security issues surrounding 
a new crash-report-retrieval system. 


In March 2002, after extensively reviewing the current crash report process, the project 
manager recommended the ICRRS solution to the executive administrator of Information and 
Strategic Services. ICRRS required only minimal changes in Records Division procedures, with 
personnel needing to sort traffic crash reports into categories based on the type of incoming 
report and organize them by number of pages (one-page reports together; two-page reports 
together, etc.). Reports would then be scanned as electronic files (TIFF images), updated with 
any extra data or graphics and stored on a server. Finally, the reports would be coded with a letter 
to indicate which city department or agency should get the report (W for Department of Water, 
for example), copied and distributed. The system would also attempt to make the new crash 
report and retrieval process user-friendly for business clients (insurance companies) and the man 
on the street by being accessible online. 

The online portion of ICRRS requires major upgrades to the current system but will allow 
a report-seeker to go to the City of Chicagos website, follow the link to the CPDs Web site and, 
once there, click on the ICRRS link. After users identify themselves either as having been 
involved in an accident, as insurance company representatives or as City of Chicago agency 
employees, they will input the crash incident number and the system will search for the scanned 
reports. Once found, the system will display a portable document format (PDF) file link on users 
computers. After paying the $5 fee by credit card, report-seekers can view, download or print 
reports. The single-report method is for customers seeking one crash report; insurance companies 
requesting hundreds of reports at a time will get their reports in batches of 100. 

By late 2002 the executive administrator of Information and Strategic Services approved 
the ICRRS project design, as it had been conceptualized by the project manager, and authorized 
the funding necessary to secure a software vendor to create ICCRS for the CPD. In January 2003, 
the project manger evaluated five vendors and selected one who, in addition to providing a very 
attractive bid, had previously done smaller projects for the CPD and could finish ICRRS in three 
months. In an effort to protect against scope creep, the project manager gave the vendor a one-
hour presentation to explain in detail the specifics of what the CPD wanted (type of software, 
business model needs, HTML prototype, etc). This contract did not provide for the needed 
hardware, which will need to come from a separate part of the CPD budget. 

The project mangers design for ICRRS development included providing office space for 
the vendor at CPD headquarters and delegating one CPD administrator to oversee the projects 
day-to-day management, while the project manager handled the time, cost and big picture aspects 
associated with the development of ICRRS. The project manager expected that by having the 
CPD administrator involved in the project from the beginning it would prevent the CPD from 
needing to rely on the vendor or consultants to maintain ICRRS after it was up and running. The 
project manager was so optimistic about this plan that the contract with the vendor purposefully 
does not include maintenance or troubleshooting after the three-month development period is 
completed. 

A kickoff meeting was set for late January 2003 and development of ICRRS was set to 
commence thereafter. However, the meeting and start of development were canceled when the 


budgeting unit at City Hall had not yet approved the CPDs funding request. By late February, 
the delay in funding became more complicated as the CPDs technology procurement contractor 
filed for bankruptcy protection. Without a procurement contractor, the CPD became unable to 
pay the ICRRS vendor due to the City of Chicagos arduous vendor/contract approval process, 
and the project officially came to a halt. At the time this report was written, City Hall had not 
approved the ICRRS funding and a new procurement contractor had not been identified. As a 
result, ICRRS is on indefinite hold. 

Training/Pilot Testing. Training will not be needed for ICRRS, because the program 
manager believes that proposed changes to the Records Division website are self-explanatory, 
and only select CPD employees will need instruction. 

Pilot-testing of ICRRS is also not an issue at this point, but the current thinking is that the 
first step will entail running the application on the CPD intranet and making attempts to breach 
its security. It is also likely that the pilot model of the application would be made available to 
insurance companies for user-friendliness testing. 

Impact. If ICRRS is implemented it should save the CPD money and improve their 
efficiency and at the same time greatly streamline the insurance companies report retrieval 
process. It is estimated that when ICRRS is functioning it will take less than a month for the 
customer center staff responsible for making the manual crash report copies to be reassigned to 
other CPD areas. This reallocation of personnel could help fill in vacancies in the Records 
Division that were a result of the many rounds of personnel cut backs. Another area of ICRRS 
impact will be on the CPDs Internet security. There are security concerns related to the way 
ICRRS delivers information to various users via the CPDs web server, and those concerns 
would need to be addressed when ICRRS is developed. The project manager is keenly aware that 
there are no unhackable systems, but thinks the use of a highly secure component object model 
will allow the CPD to control the flow of data and greatly reduce the risk of tampering in ICRRS. 

The systems impact on insurance companies could also be significant. According to a 
CPD informant, insurance companies will mostly likely be able to eliminate their need for 
outside retrieval services. These retrieval companies charge a fee to insurers to handle the 
laborious process of picking up batches of accident reports and delivering them to the insurance 
companies. Once ICRRS is available, insurance companies will be required to make all traffic 
report requests online and will be prohibited from coming to CPD headquarters to request traffic 
crash report copies. Early indications were that this would actually be a problem for some 
insurers because they do not have corporate credit cards and thus would not have a way to pay for 
the online ICRRS reports. 

The Future of the Internet Crash Report Retrieval System 

At the time this report was written, the future of ICRRS did not look promising. The CPD 
seems no closer to finding a procurement contractor than they were almost a year ago, and 
funding for the system is not guaranteed. According to a CPD informant, only the criminal 
justice components of CLEAR have funding for development. ICRRS is a community-business 


partnership component, which are considered of secondary importance. It remains to be seen 
whether and when funding will be available. 

Looking toward the future, the CPD has been approached by the Cook County Clerk of 
Courts about data exchange. The Clerks office would like to send every traffic incident report to 
the CPD, giving CPD officers access to all traffic tickets written in Cook County. Having access 
to all of the countys automobile-related records could be helpful for investigators having 
difficulty tracking down a person and for those wishing to access up-to-date information on 
countywide DUI arrests. 

Applications Slated for Future Development/Implementation 

Enhanced Hot Desk 

This module will make accessing Hot Desk information (open warrants, stolen cars, etc.) 
faster and easier for the CPD. Currently, officers have to use a dial-up connection to get into the 
Illinois State Police mainframe; the enhanced module will be Web-based. 

Organized Crime 

The Organized Crime application is a part of the case reporting system. Organized Crime 
units will use this application to capture vice-related incident data and to create supplemental reports. 

Development 

Data entry screens were developed more than a two years ago for this application, and last 
year the combined Oracle/CPD development team worked toward implementation. The screens 
were demonstrated for Organized Crime Division (OCD) personnel at a meeting in late October 
2002. Needed modifications that identified then were in the area of narcotics property screens and 
the supervisors in box. The narcotics property modification deals with money that is used for 
the purpose of buys by OCD. The division wants to identify each unit of currency that is taken 
out for buys by serial number, a function that could not be accomplished with the screens 
developed to that point. Additionally, the supervisors in box needs to offer a greater range of 
options to make it useful for the various units within the division, such as narcotics, vice and 
prostitution. The screens, as developed at that point, provided only one way for supervisors to 
enter data, which does not allow supervisors from each of the OCD units to complete their tasks. 

The early intention was to implement the screens as soon as possible, but the actual 
timeline was dependent on approval of the modifications identified at the October 2002 meeting. 
The CLEAR team did not move forward with the modifications because the screens proposed in 
2002 were client-server based, and all CLEAR applications are to be web-enabled. So, rather than 
training more than 300 personnel on a format ultimately to be replaced, the division will wait until 
the Patrol Divisions automated incident reporting application (AIRA), described earlier, is 
completely operational, then move the OCD module web-enable format. 


The Future of the Organized Crime Application 

The goal of the Organized Crime Division application is to establish a natural flow of data 
into the case reporting system and, eventually, into the data warehouse. What was once 
accomplished manually by OCD officers will be automated through the OCD data entry screens. 
Data entry will eventually be conducted via PDTs or any workstation with access to the CPD 
intranet. While this application had no activity during 2003, JAD sessions are scheduled to begin 
in January 2004. 

Probation and Parole 

This application will provide a data feed between the Illinois Department of Corrections 
(IDOC) and the CPD, providing information on releases as well as on conditions of probations 
and paroles. To date, proposals have been submitted for grant funding, and the Oracle agreement 
has been amended to include this. The CPD is currently in contact with IDOC and they have 
agreed to provide all of its information to the CPD. 

Conclusions and CLEAR in the Coming Year 

In our first report on CLEAR we presented a descriptive summary of progress made on 
CLEAR applications being developed and implemented at the Chicago Police Department. We 
were able, even in the early stages, to identify both successes and impediments. This past year we 
continued to conduct a process evaluation on CLEAR and began collecting impact data where 
possible. This report has already described each application individually and documented 
successes, impediments and impact, when possible. While CLEARs ultimate goals address 
reducing crime as well as increasing accountability and efficiency by means of using information 
in new and creative ways, we found it useful to break down such goals into smaller more tangible 
successes or impediments for the purpose of learning what works. 

The CPD has overcome many of the obstacles to implementing information technology as 
identified in earlier studies. The Department initially secured considerable funding and talent for 
CLEAR. During this past year, it was successful in securing additional funding for some of its 
applications. CLEARs architects have a solid understanding of IT and have engaged in several 
processes to ensure good product outcomes. They have kept at the forefront the importance of 
officer buy-in, through customized training, comprehensive testing and pilot-testing, and 
inclusion of stakeholders in development and implementation of the various applications. In terms 
of the criminal justice integration work, neighboring law enforcement agencies have been 
singing its praises because of the generous amounts of data that the Department is currently 
sharing through its data warehouse. There has been recent discussion about a broader partnership 
 to be known as I-CLEAR  between the Illinois State Police and the Chicago Police Department 
that is expected to be announced in the coming weeks by the Illinois governor. Federally funded 
I-CLEAR will provide a web-enabled case management system to both partners as well as a 
mobile data terminal system for case management. CLEAR applications will thereby become 
available to all state agencies, standardizing incident, arrest and follow-up investigation reports 
statewide and creating one criminal records system. 


The Department has made progress toward becoming a paperless organization through 
automation, which has, in some areas, enhanced communication between divisions and begun to 
produce more complete records and reduce redundancy. When the CLEAR system is more fully 
realized, the Chicago Police Department will be the only agency of its size to have an automated 
incident reporting system. It has also made giant strides toward becoming a data-driven 
department by launching its Deployment Operations Center, which draws current information 
from the data warehouse to guide strategic deployment decision-making based on where violent 
crime is taking place. 

Some impediments facing the Department include securing the continued flow of funding 
for many of the applications, station infrastructure challenges and the continuing balancing act of 
time management. Progress has been stalled on many applications due to contract and vendor 
complications. Working with the bureaucracy in the City of Chicago on vendor negotiations and 
securing contracts has been, and continues to be, a daunting task. Development of each 
application requires tremendous time and effort, and progress or completion of each component is 
often dependent on progress or completion of another. Launch dates for some applications have 
been postponed due to other applications unsigned contracts resulting in a vital server or some 
other piece of hardware not being delivered. Thus the CPDs information highway functions like 
all other roads: when one vehicle slams on the brakes; the others screech to a halt as well. 

Projects are also susceptible to something the Department refers to as scope creep, 
causing applications to grow ever larger and more complex than originally planned when 
developers tack on just one more simple enhancement  numerous times. These well-
intentioned additions, often done in response to requests by users groups, push completion dates 
later and later. 

We have also seen the creation of new department directives that are at cross-purposes 
with CLEAR development. The Department, faced with the very formidable task of addressing 
the high homicide rate and open air drug markets, has redeployed officers who are central to 
driving this multi-year project to completion to street assignments. Shifting assignments runs 
counter to the timely completion of CLEAR. Training officers to use the applications is a 
sequential process because the Department is large and only a few can stand down from duty at a 
particular time. When officers and supervisors work assignments are in flux, carefully crafted 
planning and training schedules can be toppled or stalled. This also applies to deadline-bound 
application developers who are often called on to regroup and address more immediate and 
pressing problems within the Department. 

Another problem, again linked to the sheer size of the CPD, is that system development is 
not shared in a consistent and informative manner departmentwide. Thus, we found systems 
developed within the traditional silos that divide the Department bureaucratically, leading to 
redundancies, inefficiencies and potential turf battles. Internal communication and information 
sharing is also a very difficult challenge within large organizations. We found that there are no 
set mechanisms or management structures in place to facilitate the even flow of information 
either vertically or horizontally in the Department. For example, it is noticeable that one of the 


major constituencies for CLEAR  the Departments Office of Crime Strategy and Management 
Accountability  has been left out of the planning and development process. Some of the most 
important CLEAR applications, including the personnel suite that promises to transform 
management processes within the Department, are vital to their mission of improving 
Department management, yet staff members in this unit know virtually nothing about CLEAR or 
development plans. 

A significant issue looms over the Departments criminal justice information sharing 
venture: the protection and privacy of the data to be manipulated and shared. While data sharing 
holds tremendous promise in terms of problem solving, predictive analysis and cost-
effectiveness, inherent in it is the ongoing threat of revealing data inappropriately or violating 
Chicagoans civil rights. The protection of individual privacy will be an ongoing issue in all IT 
projects. Another hurdle the Department must clear is the way in which it will involve the 
community and local business in a meaningful and mutually beneficial partnership. A true 
partnership will be forged when the community is no longer regarded merely as the eyes and 
ears for the police, but rather as a resource for feedback on neighborhood conditions and the 
officers who serve them. Community input should be an important part of the accountability 
equation. Little progress has been made on any application that will potentially involve and serve 
the community. 

Measuring impact is a step beyond listing the individual successes and impediments in 
the creation of an IT enterprise. By our measurements, the Chicago Police Department has had a 
very sizeable impact on criminal justice agencies that are data warehouse users. In just over a 
year it was adopted by almost all Cook County police departments and county agencies, units in 
many surrounding counties and important federal agencies. These agencies are accessing data 
almost instantaneously and are using it to solve very serious crimes. However, in terms of the 
many CLEAR applications that are promised to help reduce crime, assist in strategic manpower 
redeployment and increase accountability, there has been little to no emphasis on the part of the 
Department to measure the impact of their new systems. There is strong consensus when a 
system is not working, and great effort is put forth to create a new system, but almost no effort is 
expended to understand whether the new system has made the Department a better organization. 
The emphasis seems to be on doing the work, but not measuring whether the work has made any 
difference in terms of Department goals and objectives. When impact questions are raised within 
the CPD, they are usually raised only by senior management within the context of accountability 
meetings, and only responded to in the context of the specific situation as opposed to a unit or 
departmentwide review. 

Factoring in time and resources available, the size of the department and the enormous 
scope of CLEAR, self appraisal becomes a difficult task. However, to create a truly innovative 
and successful enterprise, actually measuring the impact of the new systems is a crucial and 
necessary piece of the work. We look forward to the next year of evaluating CLEAR and the 
possibility of seeing impact data coming from the Department as applications  many still in their 
infancy  have had time to mature and produce such data. 


Citations 

Chan, Janet B. L. (2001). The Technology Game: How Information Technology is 
Transforming Police Practice.: Criminal Justice, 1 (2): 139-159. 

Coldren, J. David (1996). Changes at the Speed of Light: Doing Justice in the Information 
Age. In Richard Scherpenzeel (ed.). Computerization in the management of the criminal justice 
system. Proceedings of the Workshop and the Symposium on the Computerization of Criminal 
Justice Information at the Ninth United Nations Congress on the Prevention of Crime and the 
Treatment of Offenders. HEUNI Publication series no. 30, Helsinki/The Hague: European 
Institute for Crime Prevention and Control. 

Coldren, James, et al. (2000). National Assessment of the Strategic Approaches to Community 
Safety Initiative: Cross-Site Themes in the Process Evaluation. Paper presented at the annual 
meeting of the American Society of Criminology, San Francisco, November, 2000. 

Dunworth, Terence (2000). Criminal Justice and the IT Revolution. In Julie Horney, John 
Martin, Doris L. MacKenzie, Ruth Peterson & Dennis Rosenbaum (eds.). Policies, processes, 
and decisions of the criminal justice system. Vol. 3, pp. 371-426, Criminal Justice 2000 series. 
Washington, DC: U.S. Department of Justice, National Institute of Justice. 

McDonald, Phyllis (2000). COP, COMPSTAT, and the New Professionalism: Mutual Support 
or Counter Productivity? In Geoffrey P. Alpert & Alex R. Piquero (eds.). Community Policing: 
Contemporary Readings, 2nd edition, pp. 233-255. 

Reuland, M. M. (1997). Information management and crime analysis: Practitioners recipes for 
success. Washington, DC: Police Executive Research Forum. 

Rosenbaum, D. P. (2004). "Community Policing and Web-Based Communication: Addressing 
the New Information Imperative" In Fridell, Lorie A. and Mary Ann Wycoff (Eds.) Future of 
Community Policing. Washington, DC: Police Executive Research Forum. 

Skogan, Wesley G. And Kathleen Frydl (2003). Fairness and effectiveness in policing: the 
evidence. Washington, DC: The National Academies Press.