Introduction
Public safety software saves lives. Public safety agencies the world over depend on software to deliver services. Computer Aided Dispatch, Records Management, Jail Management, Courts Management, Human Resources, Resource Tracking, Common Operating Picture, Emergency Management, Communications, and other software applications help public safety agencies achieve their operational mission every day. Software applications form the building blocks to deliver services better, faster, and cheaper. Well, sometimes they do. The 2009 CHAOS study found that 68% of government IT projects fail to be delivered on time, on budget, and with the required features and functions. That is dismal considering the current economic pressures. No public safety agency can afford to fail in their effort to find and implement the right software solution.
If you have ever been anywhere near the process of purchasing software, you have heard the horror stories. They go something like this:
• After X months/years of study and
• After paying consultants X thousands/hundred-thousand dollars and
• After X months/years of an RFP process and
• After X months/years of implementation effort and
• After spending X thousand/hundred-thousand/million dollars
• The We-Thought-It-Was-A-Good-Idea-At-The-Time software is scrapped
Not a happy ending. No matter the amount of time or money, that ending hurts. So what happened? It all starts out with the best of intentions and then something goes horribly wrong. Even if it does not end in a Techno-Mulligan (a do-over for you non-golfers) or an IT equivalent of the French Revolution (Off with their heads!), there are other levels of semi-failure available depending on how poorly the solution meets user needs, or how little it gets used, or how much extra time and money it costs. The best way to make sure your project is a success in the end is to avoid the most common mistakes in the software acquisition process.
After four months of gathering research and conducting numerous interviews with public safety leaders and software company executives, I found the following five mistakes to be the most common:
Mistake #1 - Poorly Defined Goals and Operational Outcomes
The number one mistake is not starting out with clearly defined goals and desired operational outcomes that can be measured or at least described clearly.
Goals and operational outcomes define the value the software solution will bring to your agency and the public you serve. You need to clearly define the operational need and the impact the solution is expected to provide. Clear and complete answers to the following questions should help you define these:
1. What is the problem we want to solve?
2. How much is the problem costing us now?
3. What are the operational needs?
4. What is the expected impact?
5. Why is that important?
6. What will the new software allow you to do that you cannot do now?
7. Who will benefit most and how will they benefit?
8. How will it benefit your agency?
9. How will it benefit the public you serve?
10. Where will it be used?
11. Who will use it?
12. When will it be used?
13. What are the measurements of success?
14. Who will pay for this?
15. What is the expected return on this investment in terms of time, efficiencies, or money?
16. What happens if we don’t buy any new software?
Mistake #2 – Trying to Solve the Wrong Problem
Software applications operate in a system. In public safety, the system includes processes, procedures, people, and resources. What software applications do well is facilitate the flow of information in the system. A software application, by itself, will never completely solve a problem. The other parts of the system also need to be operating well for software to help them. So a shortage of resources can’t be solved with software, but tracking those resources and maybe explaining to the budget people why you need more resources can be facilitated through software. Poor leadership in the field is a people and operational problem. Software can help you solve that problem but cannot do it by itself. It must operate in a system that includes interactions among people. You can’t solve a policy, procedure, or training issue with software alone.
To make sure you solve the right problem ask:
1. How much of the problem can software really solve?
2. How much of the problem is related to policies, procedures, or training?
3. If you could not buy any new software how would you try to solve the problem?
Mistake #3 - Poor Requirements/RFP Document
This is a corollary to mistake #1. If you do not have clear goals and outcomes you end up with poorly defined and poorly worded requirements definitions which lead to a poorly written RFP. A poorly written RFP makes it difficult for vendors to respond appropriately.
Most software requirements are either Functional or Technical. Functional/Operational requirements should be described in terms of operational needs. Describe what it is you want to be able to do. One requirement on a recent RFP was one word “Accidents”. That is not helpful. What do you want to know about accidents? What do you want people to do with that information? Try to give specific examples of what you want to do.
Technical requirements are usually easier to write but make the effort to describe them in terms and language that are clear and precise. Too many technical requirements use abstract terms and language that require too much interpretation.
In general, put requirements in context and explain them in detail. Tell a story. The requirements definitions and RFP process usually focus too much on the quantitative and not enough on the qualitative aspects.
Mistake #4 – Lack of Coordination, Cooperation, Communication
The software selection process usually involves a lot of people. You might have an Executive Team, a Project team, Stakeholders, and field operators who all need information to make decisions. Make sure each team members role is defined and clarified and that you have a system in place to share information as needed, when needed. Key components include:
1. Provide Strong Leadership
2. Provide Clear Governance
3. Create a Charter Document
4. Radiate Information Regularly
5. Communicate the Right Amount of Information to the Right People
6. Listen to Others
7. Meet Regularly (in person or on the phone) to Discuss Progress and Issues
8. Document Important Information and Decisions
Mistake #5 – Not Getting Peer Reviews
The most important way to find out how a software solution works is to ask the software providers customers - ask your peers and colleagues who are using it now. While this is one of the most important efforts you can make, it may also be one of the most difficult. Searching the web can be frustrating since it will usually bring up all kinds of unrelated and tangential links.
You could ask a software provider for references but they are going to refer you to their happiest clients. Those references may be able to provide good information, but you also want to talk to other clients who might have had a tougher time implementing the software solution. You need to talk to as many clients as you can to get a realistic picture of what the solution can really do, what it is like to work with the provider, and what issues or problems they had along the way. Here are some suggestions to help you find other public safety organization using the software you are looking at.
1. Search www.PSTechReview.com for reviews of the software on your short list.
2. Search www.PSTechReview.com for keywords relevant to what you are looking for (ex: CAD, Situational Awareness, etc).
3. Ask other agencies or departments like yours if they have had the same problem and what software they used to solve the problem.
4. Search Linked-In Groups or ask if anyone has used the software solution you are considering.
5. Ask some the software companies you have worked with ion the past if any of their business partners might have a solution (ex: ask your CAD vendor if they know any companies who provide the kind of software you need).
Once you have talked to as many actual users as you can, make a list of the positive and negative reports from users. Share this with the various teams and see what they think about the results. You might also take this information back to the software provider and discuss the major issues.
Conclusion
Finding and selecting the right software can be done. Avoiding these top five mistakes should help.
