U.S. Department of Justice Office of Community Oriented Policing Services DOJ Seal COPS Logo Policing Smarter Through IT: Learning from Chicago’s 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 Chicago’s 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 CPD’s 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 warehouse’s 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 Chicago’s 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 Chicago’s 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 Department’s 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 CPD’s 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 CPD’s 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 CPD’s 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 project’s scope, depth and time line have grown exponentially. The Department’s 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 Department’s 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 city’s automated dispatch system (PCAD) and, in turn, feed data into subsequent stages of the Department’s 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 city’s 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 AIRA’s launch was the modifications required by the city’s 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 Chicago’s 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 city’s 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 CPD’s 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 Department’s 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 arrestee’s 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 Department’s training burden. In addition to the equipment procurement hurdles that must be overcome, circumventing infrastructure problems in the city’s 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 Department’s 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 department’s 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 report’s 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 Personnel’s segment of the Personnel Suite are approaching the pilot testing stage. The Star Management application manages and tracks the Department’s 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 Department’s 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 Department’s 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 department’s legacy inventory application. eTrack’s third phase will incorporate upgrades that enhance functionality. The Gang Arrest application, to be developed in several distinct stages, is intended enhance the department’s 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 state’s 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 state’s 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. Chicago’s 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 CPD’s 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 city’s 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. CLEAR’s 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 CPD’s 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 Department’s 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 organization’s 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 Chicago’s 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 CPD’s 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 CPD’s 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 City’s 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 CLEAR’s potential market value and reasons why Oracle would be the CPD’s 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 Chicago’s police superintendent and the chief of Washington, DC’s 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 Oracle’s 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 project’s ideas and its proposed role. A second meeting took place between the CPD and Oracle’s first vice president. The negotiation began with Oracle’s offer of 90,000 consulting hours for CLEAR project development. After ensuing discussion about the project’s 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 Hall’s 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 CLEAR’s 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 reader’s 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 CPD’s 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 unit’s business operations. After each session, the Oracle team produces a process flow document. Flow documents are based on procedural information gleaned from the day’s 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 division’s key personnel. After the unit or division management team carefully reviews and accepts the document, it becomes the foundation for the application’s development. A number of applications under development require subcontracting with outside vendors to create or supply hardware or software for the various systems. The city’s 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 contract’s language. And, occasionally vendors realize that they cannot deliver the promised product, and the CPD must begin anew, further delaying the module’s 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 Department’s 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 project’s scope, depth and timeline have increased almost exponentially. In March 2000 a lieutenant in the Department’s 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 application’s 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 Department’s 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 Department’s 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 city’s automated dispatch system (PCAD) and, in the future, feed data into subsequent branches of the Department’s 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 Department’s portable data terminals (PDTs); complex adaptations would need to be made to the city’s 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 city’s 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 vendor’s 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 application’s behavior in the city’s 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 Department’s PDTs are available, but their drawback is that they do not work in temperatures below 15F, making them an impractical choice for Chicago’s 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 AIRA’s platform from active server pages (ASP) to extensible markup language (XML), an operating system that became an industry standard during the course of AIRA’s 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 district’s PDTs were out of service. Before AIRA is launched, the unavailability of PDTs is an inconvenience; afterward, it cripples the application’s 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 Area’s 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 city’s legal department prevented changes to the city’s 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 district’s 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 district’s 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 city’s 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 user’s 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 Department’s inability to get the mobile pilot test started before late November 2003. Instead, the major impediment to mobile AIRA’s launch had to do with completion of PCAD programming changes. These changes were handled by the vendor that created the city’s 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 AIRA’s 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 district’s 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 we’re 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 Department’s limited bandwidth, and the AIRA team has been trying to set up a pilot test in one of the CPD’s 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, driver’s 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 Chicago’s. Consequently, the vendor agreed to set up a test site in the city, but at the time of this report’s writing, full scale testing had not gotten underway, because the contract is still awaiting City Council approval. Successful results with Greenhouse technology in Chicago’s 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 Department’s 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 IWIN’s 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 AIRA’s 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 CPD’s 25 district stations roughly fall into three categories: new, modern and very old. Accommodating needed wiring and workstations is not a problem for the Department’s newest stations, and the modern facilities generally pose no major challenge. However, approximately one-third of the city’s 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 CPD’s 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 Department’s 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 arrestee’s 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 Department’s 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 day’s 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 CLEAR’s executive administrator – was a very complicated one, allowing the application’s 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 day’s 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 application’s 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 you’ve 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 application’s 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 city’s 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 Department’s version. ICAM reports provide many invalid addresses—20 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 team’s 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 ICAM’s geographical data. ICAM’s 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 application’s 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 application’s 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 query’s 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 application’s 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 application’s 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 application’s 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 system’s 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 suspect’s 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 Department’s 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 Department’s 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 company’s bid was somewhat higher than that of other vendors, the Department decided to contract with this company because it met all of the CPD’s 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 CPD’s 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 Department’s 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 Department’s two main hardware needs for the new mugshot system were digital cameras and new servers. The vendor’s first camera recommendation was rejected by the CPD, so a search began anew for a digital camera that would meet the Department’s specifications: high mega-pixel count for clear, crisp pictures; zoom features; and automatic picture downloads to the CPD’s data warehouse. By April 2002, the vendor identified a camera with the required specifications. However, a three-month pilot test revealed some of the camera’s 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 Department’s 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 Department’s 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 camera’s 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 district’s 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 prisoner’s mugshot without needing to reenter all of the arrest information. The Detective’s 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 offender’s name, CB number, criminal history, demographics and mugshot image. By clicking “add to line-up” (available only to detectives) the offender’s 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 offender’s 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 CPD’s 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 vendor’s 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 vendor’s 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 group’s 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 system’s 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 system’s 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 Department’s Help Desk. Initially Help Desk personnel contacted the vendor’s rep or the CPD’s 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 CPD’s 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 CPD’s expert. Lockup keepers and detention aides with computer experience have had little problem with the mugshot system’s 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 System’s 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 suspect’s 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 prisoner’s 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 CPD’s mugshot expert is in the process of making changes to the look and feel of the mugshot system so that it will conform to CLEAR’s 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 CPD’s 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 Department’s legacy inventory application. eTrack’s 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 Oracle’s 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 city’s 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 user’s 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 courier’s 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 application’s 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 application’s 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 – eTrack’s 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, eTrack’s 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 CPD’s 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, eTrack’s advantages are almost incalculable. Gang Arrest By the mid-1990s it was internally apparent that the Department’s 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 Department’s 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 Department’s first step in identifying an arrestee’s 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 Department’s 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 application’s 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 application’s 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 CPD’s 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 application’s 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 application’s 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 application’s 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 city’s 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 Department’s 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 gang’s 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 CPD’s 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 state’s 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 CPD’s 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 juvenile’s 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 juvenile’s 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 state’s attorney approval (though the CPD’s 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 CPD’s main goal for the enhanced Juvenile Arrest system was to track and assess the conditions and outcomes of juveniles as they move through Chicago’s Juvenile Arrest system. The new system allows officers to check a juvenile’s 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 CPD’s 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 Department’s original intention was to launch a system that would meet or come close to the state’s 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 Department’s 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 juvenile’s 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 investigator’s 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 shift’s 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 won’t lie about is their mothers,” so having an easily accessed search capability for accurate parent information was key. Unfortunately, the Juvenile Arrest system’s 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 driver’s 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 system’s 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 district’s front desk. However, upon further reflection that solution was deemed problematic because during a busy time it would be unlikely that the district’s 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 CPD’s Juvenile Arrest system. Currently, all CPD youth employees are prevented from seeing the Juvenile Court’s disposition of youth offenses. If the two systems could be linked, the CPD’s Juvenile Arrest system could display Juvenile Court disposition information in the Juvenile History section of the CPD’s 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 System’s 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 Department’s 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 division’s functions are currently automated through CHIPPS, which is a stand-alone system used by City Hall’s Department of Personnel, but tracking of time and attendance – one of the Finance Division’s 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 unit’s myriad functions related to medical leave and injured-onduty (IOD) status are now directed by the Personnel Suite. The CPD’s 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 unit’s 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 CPD’s performance monitoring system is not the result of a consent decree; however, U.S. Department of Justice recommendations for jurisdictions so mandated will anchor Chicago’s program. Development and Implementation Much progress has been made on the Personnel Suite in this evaluation period. At the time of this report’s 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: Finance’s 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 suite’s third developmental stage. OPS and IAD’s 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 Personnel’s segment of the Personnel Suite are approaching the pilot testing stage. The Star Management application manages and tracks the Department’s 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 PERF’s 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 application’s 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 facility’s 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 organization’s 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 CPD’s 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 Department’s law enforcement partners. In late 2002, the CPD began to overhaul the design and programming format of its rap sheet. The Department’s 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 one’s 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 CPD’s 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 XML’s unique properties, the agencies’ customized databases would not need to be sacrificed. The CPD’s 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 CPD’s Instant Update Unit (IUU), which is contacted by officers who need the most updated version of an offender’s rap sheet to help make decisions on charges. IUU manually reviews the dispositions of all of the offender’s previous felonies using Cook County Clerk’s system, ISP rap sheets, the CPD’s 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 arrestee’s 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 sheet’s 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 CPD’s data warehouse and the ISP’s 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 IUU’s 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 CPD’s CLEAR systems and IDOC’s 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 sheet’s 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 CPD’s 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 case’s 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 CPD’s 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 CPD’s 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 CPD’s 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 Department’s 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 Department’s 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. Chicago’s 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 Sheriff’s 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 Sheriff’s Office and the Chicago Police Department. About three-and-a-half years ago the Sheriff’s 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 Chicago’s 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 Sheriff’s 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 person’s 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 Division’s 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. Chicago’s 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 Attorney’s 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 suspect’s 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 Department’s 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 organization’s 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 CPD’s 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 department’s 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 city’s 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 chief’s 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 agency’s 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 chief’s 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 organization’s 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 city’s 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 CPD’s 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 public’s 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 CPD’s 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 agency’s 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 CPD’s 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 application’s 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 CPD’s 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 CPD’s Auto Theft Application. The only known fix for this situation is to merge the two agency’s auto- theft recordkeeping databases into one system for the entire state. As of November 2003, discussion of this solution “isn’t even on the table.” Another significant setback was the bankruptcy of the CPD’s procurement contractor, which caused a major delay in purchasing the Auto Theft application’s 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 Chicago’s complicated vendor/contract approval process has brought development to a halt. An additional matter that may have an impact on the Auto Theft application’s development timeline is that some CPD administrators have expressed the concern that the application’s data transmission pipeline “would be open all the time,” potentially presenting security problems. However, the application’s 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 CPD’s 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 CPD’s 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 Department’s 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 system’s use. The efficiency of ICRRS is expected to reduce insurance company report requests by 50 percent, consequently reducing the CPD’s 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 CPD’s labor cost. Development The CPD’s 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 CPD’s 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 Chicago’s website, follow the link to the CPD’s 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 manger’s design for ICRRS development included providing office space for the vendor at CPD headquarters and delegating one CPD administrator to oversee the project’s 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 CPD’s funding request. By late February, the delay in funding became more complicated as the CPD’s 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 Chicago’s 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 CPD’s Internet security. There are security concerns related to the way ICRRS delivers information to various users via the CPD’s 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 system’s 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 Clerk’s 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 county’s 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 Division’s 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 CLEAR’s 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. CLEAR’s 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 CPD’s 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 Department’s 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 Department’s 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: Practitioner’s 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.