Planning for Change in Public Safety – Part 2

This article is one of a 5 part series on Planning for Change in Public Safety. To read the series, please start with the Introduction and Part 1.

“What if?”

The words anyone in charge of implementing change both loves and dreads. They can indicate an openness to new ideas and the potential for change. They can also create a never-ending list of changes that can drag a project out beyond its time, resources, and financial limits.  

The previous post discussed the need to identify the agency team members who will be managing the impending change. One of the first responsibilities of that team is to identify the change (or more likely changes) that will be taking place. This is referred to as ‘defining the scope’ of the project, or in other words, identifying the project’s goals and the work that needs to be done to accomplish those goals.

A well-defined project scope is crucial to both the agency and the vendor. It is only through a well-defined scope that a list of required project work such as task assignment, project scheduling, timeline management, and final acceptance can be completed. If the scope is too narrow, the necessary work may not be completed. If the scope is too vague, confusion can result in what needs to be done. Final scope definition is completed as a joint-venture between the agency and the selected vendor.

A high-level identification of existing functionality and workflow paths begins long before vendor identification, however. In fact, it will be part of preparing for the RFP process as required functionality should be included in any technical or functional requirements included for vendor review. One way to approach initial scope definition is to identify and prioritize the goals of the project. In our example of replacing an agency’s records management system (RMS), there are two aspects to remember. The RMS will replace not only existing functionality, it will replace existing workflows.  

What’s the difference between “functionality” and “workflow”?  “Functionality” is what gets done. “Workflow” is how it gets done. Functionality is taking incident reports for the purpose of investigation and reporting IBRS crime statistics. Workflow is the path a report takes from the patrol officer entering data into the report, forwarding it through the chain of command for approval, and both Records and Investigative personnel receiving the information required to do their respective jobs.

The highest priority of our RMS project is to ensure that all existing mission-critical functionality is accounted for and replaced. These are the must-haves. This includes all data currently gathered, all output currently produced, and all data-sharing interfaces currently in operation. It will also include any new data reporting requirements, such as NIBRS, that the agency needs to meet, but is unable to do with the existing system. An agency should not lose existing functionality.

Workflow, on the other hand, is something that may change a great deal. In general, the workflows currently in place were dictated by the technology available when they were developed. If the agency’s current RMS is based on outdated technology, the workflows in place are most likely outdated as well. Replacing the technology will replace the workflows.

Replacing functionality is easy. Replacing workflow is the hard part. Think back to the introduction of one-way aisles in the local grocery store. Going to a store to buy food – the functionality – didn’t change. The way shoppers navigated the store  – the workflow – did. We all had to make adjustments, but in the end, we are still able to accomplish our goals of buying fresh food and produce. 

Many times change navigators will hear people say, “But that’s not how we do it.”, or “We’ve always done it like this.” That is resistance to changing the workflow. The highest priority of the project is to identify and replace existing functionality. Fully identifying existing workflow is important as it pinpoints all data input points and what happens to the data after it is entered. Allow for flexibility in workflows using the new technologies the agency will now have access to.

The below table illustrates some differences between functionality and workflow in a simplistic report path:

As shown above, the functional steps could be much easier to identify than the workflow path taken to get them done. However, this is a crucial step in defining the scope. Each function performed in the current RMS and its corresponding workflow must be fully identified. This may include Incident Reports, Accident Reports, Field Interviews, Criminal Citations, and more. If there are third-party applications (a third-party eCitation solution for example) include each data interface as a function.  

Remember, agencies do three things with data: they gather it, they use it and they share it. For each function, identify all the ways data is gathered: forms, data portals, interfaces, data entry personnel. Identify all the ways the data is used: analytic/statistical reporting, workload/managerial reporting, case investigations, property/evidence management, etc. Identify all the ways the data is shared: printed forms, NIBRS reporting, court case preparation, third-party data interfaces, intra- and inter-agency data-sharing initiatives, etc. The more granular the documentation of functionality and workflow is, the more prepared the team will be to work with the selected vendor in final scope preparation.

What if?

The next post will look at the ‘other side’ of this question. Identifying current functionality may not be the whole story. What about expanding functionality? Can the agency take advantage of new features not previously available? How does the agency’s team begin planning for what happens before and after go-live?