Records Review, Pinellas Sheriff
Background: While employed at the Communications Maintenance dept. of the Pinellas
County Sheriff’s Office, I was tasked with bringing the list of Mobile Data Terminals up
to date. In doing so, I discovered a weak and potentially incapacitating approach to data
collection. Thus, the following report:
Subject: Communications Maintenance Work Requests; their quality, and improvement
thereof
I Overview
II Project Number Field
III Short Description Field
IV Detail Description Field
V Sub-Libraries
VI Instructions Field
VII Summary
I Overview
In the process of updating the Mobile Data Terminal (MDT) list, three bodies of records
were pored over and collated: the Personnel Management System; the Fleet Management
Equipment Inquiry, and the Communications Maintenance Work Requests. As the
process continued, one particular fact became clear: the body of records with the highest
level of inaccuracy was the Communications Maintenance (CMD) Work Requests.
This inaccuracy manifested in several ways: for example, an MDT known to be in a
particular vehicle would be shown in its most-recent Work Request (WR) only to have
been “removed for repair” from a different vehicle; or be shown to have been installed in
a vehicle other than its current location. In several cases, no WRs were found.
Another great problem lies in a simple lack of detail. In many instances neither the ‘Short
Description’ field nor the ‘Detail Description’ field, for example, contained sufficient
data, and often merely re-stated information entered in dedicated fields within the
document.
Of course, a portion of the blame for this must be placed on Comm Maint personnel’s
attitude towards the Work Request application which, unfortunately, seems to be one of,
“This program is a dinosaur, so I’m not going to put much effort into dealing with it.”
Granted, the Work Request application is cumbersome and inflexible, to say the least. In
fact, what is needed is a single application that can manage Personnel, CMD and Fleet
Management information in interuseable databases, rather than using three incompatible
stand-alone apps. But such an application is not soon in coming, so it behooves us to try
to make better use of the existing application.
II Project Number Field
The place to start is the document header; this is the information first seen when the user
navigates to the “Work Request Maintenance” screen. In its default setting — documents
sorted by Work Request number — we notice two things: 1) the “Facility ID” field
contains CMD asset numbers; and 2) the “Project Number” field is empty. CMD uses the
first field — which normally would contain identifiers for factories, plants or other
‘facilities’ — to hold what is the single most important piece of data, the equipment asset
number. The second field is empty because there are no data in the “Project Number”
sub-library which relate to CMD activities. However, if CMD were to make use of this
field as it does with the “Facility ID”, this would be a first step towards making better use
of the WR application.
The sub-library for “Project Number” contains entries in this format: a six-digit number
(in some cases, alphanumeric) accompanied by a brief text description (e.g., SO9802 –
Courthouse Security). For CMD, the six-character identifier would be a simple
description of equipment type — ‘portbl’ (for portable radios), ‘radar’, ‘siren’, etc. (If all
six spaces must be used, either pluralizing or filler characters will suffice.) Having such
information in a dedicated field would make identifying either a particular work order or
an activity trend easier, as that field is both sortable and filterable.
A particular drawback in using this field is that, unlike most of the other sub-libraries, no
direct modification option is available for this field’s sub-library at user-level; therefore
Computer Services would have to make the modification.
III Short Description Field
The “Short Description” field, the only truly flexible field in the header, probably suffers
from the least-effective use in the creation of a Work Request. In fact, since this field
often contains nothing more than redundancies of data from dedicated fields, it is
therefore the greatest weakness in a typical CMD Work Request, when because of its
flexibility it could in fact be the strongest point. The Short Description field can contain a
maximum of fifty characters, enough to form a well-detailed sentence fragment. Further,
fully thirty of these fifty characters are displayed in the header, meaning that a fairly
complex set of data may be entered into the Short Description field with the assurance
that this information will be immediately available upon the User’s arrival at the Work
Request Maintenance screen. What must be determined is just what information would be
entered to best make use of this field. Consider the following:
During the research for the MDT list update project, it became apparent that aside
from the asset number of a given MDT, the data most needed were vehicle
number, officer name and payroll number, and cost center.
At the Jail sub-office, it is common practice for the technicians to note a
portable’s model, serial number and from which section it originated.
Radar units are tracked by their serial numbers and unit numbers moreso than by
their asset numbers.
The following examples are taken from actual CMD Work Requests, and demonstrate
typical data entry habits:
Note that none of the arguably more-pertinent data described in the preceding bullet list is
included here. Moreover, such information often is not entered into a WR at all, whereas
the data in the Short Description field is again either merely redundant or insufficiently
informative. In fact, WF…473 offers no immediate clue as to what type of equipment it
concerns.
Here’s a model of how these same work orders might look using specialized data
formats:
In these examples, the data in the Short Description field more readily identify the
different equipment items and make them easier to track. For example, Work Requests
could be filtered to show only those concerning portables, or even more specifically,
Visar portables; or perhaps only those concerning MDTs under Cost Center 5100.
Further, since the Project Number field is both sortable and filterable, it could be used in
conjunction with Short Description filtering to create either highly customized or
extremely isolated document listings.
As can be seen, the modified entries are not identical in format; however, neither are they
terribly dissimilar. Both the radar and portable entries contain an originating location and
a serial number. The format used in the MDT entry would be the same for any piece of
equipment installed into a vehicle.
A significant benefit of the modified data examples above is that for tracking purposes
each such entry need only be done once per item per assignment. For the duration of that
assignment, this data need not be entered again until the item is either re-assigned,
removed and shelved, or disposed of; then the extended data would be entered reflecting
the changes, and not entered again until another such change. For example, if WR~462
actually contained the modified data shown above, that would be the only such entry
necessary until, seven months from now let’s say, MDT #12439 is moved to a different
car. The WR concerning the move would contain the new vehicle, employee and cost
center numbers; this would be the only time the new data need be entered, any reports
generated in-between, during which time the MDT did not “change hands”, would simply
not need the extended data. For equipment tracking purposes, a single such entry is quite
sufficient.
IV Detail Description Field
The Detail Description field also suffers from poor use. More often than not it’s merely
left blank; or it contains ‘information’ barely more informative than that entered in the
Short Description field. This field is also fifty characters wide, but can be several pages
long, offering more than enough room for the User to explain both the fault and various
repair steps taken. Unlike some of the dedicated fields, this field remains unlocked for the
duration of the WR’s open status, allowing the User to continually add to it as work
progresses.
The only significant drawback of the Detail Description field is that it offers no wordprocessing capability aside from basic insertion, deletion and type-over. Each line is a
unique field, separate and distinct from the rest. This can make editing a lengthy report
tedious.
Just as useful, but even moreso overlooked is the Result Comments field, which functions
in the exact manner of the Detail Description field. It is made available upon the closing
of a Job Order or Work Request, but is rarely and poorly used.
V Dedicated Fields
This concerns not so much the habits of Users as it does planning. The strength or
weakness of the various Dedicated Fields lies in their related sub-libraries. For each entry
field that offers the ‘prompt’ (F4) function, there is a sub-library of pre-defined entries
from which one may be selected. As both technology and the operations of CMD have
changed, the sub-libraries have grown inadequate due to lack of upkeep.
For example, virtually none of the existing entries accurately covered Jail sub-office
operations. With the aid of the Office Manager, the Jail technicians added or re-defined
many entries to better suit their WRs. However, this was done several years ago; with the
addition of Video Visitation, as well as other changes in operations, the sub-libraries for
Jail WRs have again fallen behind.
The Maintenance function for these libraries can be accessed at user-level (providing the
User has proper authorization attached to his/her AS400 identity), so upkeep on them can
readily be accomplished. On a regular basis, perhaps annually or bi-annually, all the sublibraries should be reviewed to determine if they need maintenance.
VI Instructions Field
In the Job Order attached to a Work Request, there is a dedicated field named “Standard
Task Code”; this field is unique in that along with its own sub-library, it also has a sublibrary for the Instructions field. When a Standard Task Code selection is defined in the
sub-library, the User may then also define a custom Instructions field layout; this layout
then automatically gets loaded into the Instructions field when a Standard Task Code
selection is made.
Here, the concern for accuracy is two-fold: the maintenance of the pre-defined layouts,
and the efficient use of these layouts by the User. Regarding maintenance, the concern is
the same as that of the sub-libraries as mentioned in Sec. V, Dedicated Fields
The concern for efficient use of the Instructions field is at least equal to that already
mentioned, and in fact may be greater. For, while much of the data in a Work Request or
Job Order are selected from sub-libraries, entry of the Instructions field data is manual
entirely. Moreover, since the Technicians use printed WRs and JOs, rather than filling
them in online, the generated data often are not then entered into the online forms. Thus,
the majority of CMD’s data lies not in a convenient online history but in a massive
collection of hard-copy printouts. Should a particular document get lost or damaged, or
too worn to remain useable, the recourse of simply re-printing it very well may not exist.
The simple fact is that many of the online documents do not contain the very information
for which their hard-copy versions were originally printed.
VII Summary
The usefulness of any given tool lies not only in the function or functions designed into
the tool, but also in how well and how appropriately the User uses the tool. While the
Work Request application is far from user-friendly, it can more effectively serve as CMD
prefers to use if better use were made of the capabilities it does have. Often, CMD hears
from the personnel and sections it supports complaints about the equipment for which it
is responsible; yet when CMD tries to introduce new, often computer-based,
technologies, it is met with great resistance to change from the current equipment.
Ironically, in a sense this also happens within CMD. The general opinion of the Work
Request application held by CMD personnel is fairly low; yet when a different and
arguably better way of using the application or configuring the data is presented, CMD
personnel balk at the notion of changing from the current methodology. Unfortunately,
this has led to a general lack of overall accuracy in the Work Requests, inconsistency in
the collection of data and a great absence of much of the very information for which a
given Work Request is created. The quality of CMD’s own records shall certainly remain
sub-standard unless and until a significant change is made in the way these records are
generated and maintained.
Original document written in 1999; portfolio (online) version © 2016 Stephen Petruff