Thursday, January 30, 2014

Let it rip, Chief

As I've mentioned on a few past occasions, I participate in one and only one web forum, the International Association of Crime Analysts. Once or twice a week, I peruse the posts, and occasionally weigh in with a thought. Yesterday, a thread opened up when a South Carolina crime analyst sought some advice.

She was dealing with the problem of police reports being delayed by the supervisory review process. Here's how it generally works in police departments from Sidney, Nebraska to Sydney, Australia: an officer completes a report, and drops it in the inbox. His or her supervisor picks it up, notes any obvious errors, makes a determination about any needed follow-up work, initials the report, then forwards it to the Records Unit where it is ultimately filed. This process hasn't changed much in over a century.

These days, in many departments this process is entirely electronic: the report is created online, goes into a virtual inbox, is reviewed and signed online by the approving supervisor, and then goes into a database record in the primary police database (the Records Management System, or RMS), instead of a manila folder in a file cabinet. The electronic process completely mimics the paper process of the horse-and-buggy era.

Here's the rub: the review and approval process is dependent on the supervisor's schedule. If she's busy and doesn't get around to it until late in her shift, or the next day, or after her days off, the data can languish in limbo for hours or days, just as it did in 1884 or 1994. The fact that the report is now a .pdf, an .htm, or a blob,  instead of the pink copy of a three-part self-carbonated form (is that dating me?) doesn't change a thing it this regard. This is exactly what was bugging my warm-weather colleague: she was frustrated that she couldn't work with the data until the supervisor had given it the final stamp of approval.

I suggested to her that the solution might be to rethink the status quo, so that the data from the police report would go directly into the RMS as soon as it was created, rather than mirroring the paper process it replaced. The on-screen review and electronic sign-off by the supervisor could occur later, so the data would be available for anyone to access, read, and work with even though it was still subject to supervisory review and approval ex post facto.

This is exactly what we did in Lincoln several years ago. Despite a lot of hand-wringing and tooth-gnashing at first, predictions of Chaos and Doom never materialized. The reports were still reviewed by the duty commander, occasional errors were still corrected, follow-up work was still assigned, and the sun continued to rise in the east. If you tried to switch it back now, there would be a minor revolt by staff who have become accustomed to instant access to the gory details of the Incident Report narrative as soon as the originating officer has mashed to submit button.

The problem my colleague below the grits line faces will be to convince the management staff at her agency that a streamlined work flow need not be constrained by the oft-heard phrase, "Because that's the way we've always done it." To that end, I offered my good offices to speak to anyone in her department about our experience confronting the very same issue, to offer comfort that flipping the process on its head would need not portend the end of civilization, and would yield some nice benefits by speeding the information flow. Let it rip, Chief, it will be fine.

The grits line, by the way is the latitude below which the waiter or waitress no longer asks whether you want grits or hash browns with your eggs.

5 comments:

Steve said...

Sounds like a good idea. I wonder though, now that there is less impetus for the supervisor to approve the reports, if there is even a longer lag between submission and approval. Could that possibly delay followup actions that need to be taken?

Steve said...

I think there is a similar sweet tea line, but I couldn't say exactly where it lies.

Anonymous said...

Doesn't hurt to have a cop as your programmer either. Thanks Clair!

Anonymous said...

Just to clarify, Records doesn't just file that report. They get said report and read it to determine the UCR code (which is very important to the crime analyst), verify the incident code was entered correctly, fix the GEO location that dispatch put in (which is usually not in the correct format needed), decipher a method from a half page to full page narrative provided by officer into a one liner that the public can read, enter the contacts, and send error notifications on things such as damage amount missing or wrong dob given. Then a tech works to make sure the case is cleared in the system correctly based on an officer's ACI later.
Just my two cents to those on people at the bottom of the totem pole who work diligently at making sure those stats are right:)

Tom Casady said...

Anonymous 1:06,

You forgot about making any required updates to the names in the Master Name Index. ;-)

I'm well aware of the post-processing of IRs by the Records Unit, and probably more than most it's critical importance to the accuracy of our data.

I hope you did not take umbrage that this was not really the point of my blog post: rather, I am trying to suggest to my crime analyst readers that we sometimes shoot ourselves in the foot by injecting unnecessary delay into our processes.

In our case, I can read the IR even while it's being written, most of the fields are already available in the RMS, and the post-processing steps are accomplished much more quickly.

Kudos to LPD's Records Unit! I will never, ever ask you to transcribe a statement I took from a mumbling defendant in my backseat without turning down my radio!