The bulk of my career was spent rescuing failing or failed mission-critical technology projects. From inside agencies and from inside vendors, I have watched CAD modernization programs unravel, taken inventory of what went wrong, and rebuilt them.
The pattern is remarkably consistent. CAD modernization programs do not fail in deployment. They fail in scoping. The decisions that determine success or failure are made before the RFP is written, and most agencies do not know it until year three when the system that was supposed to transform operations is the system that operators work around.
Process and framework must be tight. Deployment teams must adhere to strict standards in documentation of requirements and information exchange. None of that matters if the work that should have happened before the RFP was never done. If vendors are answering the wrong questions or designing the wrong solution, the system will never become what the users need.
This Insight is for the agency that has a CAD, RMS, JMS, or related mission-critical program on the horizon. The most important decisions you will make on that program are decisions you will make before you ever issue a solicitation.
The Pre-RFP Investment Most Agencies Skip
There is real work that has to happen inside an organization before any major technology procurement begins.
The organization has to invest human capital, time, money, and energy into properly assessing the current state, mapping requirements, and fully understanding what problems actually need to be solved. A full operational analysis has to surface what new process could be introduced to streamline operations and what process should change with the investment of new technology. Pain points have to be captured. Key individuals have to be identified who will later play vital roles in deployment or in championing the change. Stakeholders have to be aligned across dispatch, patrol, command, records, IT, and the city attorney. Organizational change management should begin during this discovery process, not after contract signature.
Agencies that skip this work end up with RFPs that ask the wrong questions. Vendors respond to those wrong questions and the agency selects a solution that was built for a problem the agency did not actually have. The misalignment becomes visible in year two, sometimes year three, when the system is in production and the gaps between what the agency needed and what the agency bought become the lived experience of the operators using the software.
The agencies that get this right invest meaningfully on the front end. Industry research bears this out clearly. Civic IQ’s 2026 analysis of public safety software procurement found that agencies hiring independent consultants before vendor selection consistently produce better outcomes. The data point that matters: a $200,000 to $235,000 consulting investment in pre-RFP discovery and requirements work typically prevents $500,000 or more in change orders and scope creep during implementation. The agencies that documented this pattern most clearly include Fontana, Grapevine, and Staunton. The pattern is now widely observable across the public safety procurement market.
The math is straightforward. Two-to-one return, minimum, on the consulting investment. And that ratio understates the actual value because it does not capture the downstream costs that change orders and scope creep produce. Schedule slippage. Operator frustration. Council credibility damage. Vendor relationship strain. Stakeholder fatigue. The agency that runs the pre-RFP work properly does not just save money. The agency saves the integrity of the entire program.
The time investment is also smaller than agencies fear. Euna Solutions’ analysis of more than 6,000 public sector RFPs found that the average public sector RFP takes 57 days from posting to award, and 78 percent of RFPs wrap up within one to two months. The pre-RFP discovery work that produces a meaningful RFP typically adds 60 to 120 days on the front end. That is a four to six month total investment before the contract is signed. For a CAD program that will define the agency’s operational backbone for the next 10 to 15 years, four to six months of disciplined upfront work is not a delay. It is the cornerstone.
The Law Enforcement Information Technology Standards Council, the Bureau of Justice Assistance, and the IJIS Institute have published standardized CAD and RMS functional requirements precisely to reduce the cost of this pre-RFP work. Agencies that begin with those standardized requirements as a baseline and then customize against their own operational discovery produce stronger RFPs faster than agencies starting from scratch or, worse, copying another agency’s RFP.
Stakeholder alignment is the second pre-RFP component that gets undervalued. Pre-RFP is when stakeholders are most likely to want to work together. People who use a piece of software every day, who know their world is about to change, will resist that change. But if they feel involved, if they feel their opinion matters, they will be more inclined to champion the change, share information that will be helpful for the RFP, and become key players during the project. The agency that aligns stakeholders early gets an RFP that asks all the right questions. The agency that skips alignment gets an RFP that asks generic questions and produces generic answers.
This is the work that gets compressed, postponed, or skipped at most agencies. It is also the work that determines whether the program will succeed.
The Requirements Trap
I have read hundreds of CAD and RMS RFPs. I have managed many programs where the requirements matrix from the RFP becomes the backbone of the deployment plan. I have also seen the requirements process executed in every conceivable wrong way.
The most common failure mode is the copy-paste RFP. An agency pulls an RFP that another agency published, copies it into their own document, and sends it out. This wastes the agency’s most important opportunity to define what they actually want the new system to do. Meaningless requirements get sent out and meaningless responses come back. The evaluation committee then tries to score those responses against criteria that were never tuned to the agency’s actual operations. Selection decisions get made on the basis of fundamentally weak data.
The second failure mode is the “yes, with configuration” response. Most vendors have someone on staff who has never used the software walk through hundreds of pages of administrative and user manuals to answer requirements. Nine times out of ten, the response is “yes, with configuration.” A loosely written RFP allows this. A thoroughly crafted RFP, at least in the areas that matter, requires the vendor to put real thought into the response. The vendor may even have to put a person on the answer who has actually used the software at scale. That is the level of vendor effort the agency should be solicting.
I once managed a program at an agency that required the vendor to demonstrate every single requirement in a live sandbox in front of the stakeholders, who had to sign off that the functionality existed and was working to their satisfaction before the vendor could begin go-live planning. The review took nearly a week of ten-hour days. The intent was thorough. The execution was problematic, because the vendor had one of the most configurable systems on the market. There were nine ways to do everything. The demonstration revealed the configurability, which is a strength, but the volume of options added to the confusion. The lesson is not that requirements demonstrations are wrong. The lesson is that requirements have to be written with the specificity that allows a real evaluation, and demonstrations have to be structured around the requirements that matter most, not every requirement in the matrix.
The third failure mode is requirements that describe only current state. A good RFP captures the business processes the agency uses today AND the things the agency wants to do with the software that it cannot do today. The future-state requirements are where the agency stretches into what is genuinely possible with modern CAD architecture, integration capabilities, and analytics. Stakeholders should spend extensive research, review, and refinement on future-state requirements before the RFP is built. The more specific the requirement, the more meaningful the response from the vendor. This is the opportunity to find the best software available, not the software that most closely resembles what the agency already runs.
Vendor Demo Theater
The vendor demo is the most over-weighted input in CAD selection. Vendors bring their best people. The demo is rehearsed. The system has been primed for optimal performance with perfect data that will show well. It is Hollywood at its finest.
A demonstration is a great thing for stakeholders to see. It is often not very valuable for actually evaluating the vendor and the software.
What is better is a live data sandbox. The agency should require the vendor to provide a sandbox environment and software specialists to staff a lab where they will work side by side with the agency to conduct basic provisioning and configuration, and then begin using the system. This is the fastest way to surface real pain points. Software should be intuitive. Picking up an iPhone or using a new app on an iPhone does not require reading a thousand-page manual. One thing flows to the next. User intuition guides. If sitting down to a provisioning console requires reading a thousand pages and sitting through two weeks of training before the user can do basic work, the system is likely not intuitive and may not be a fit.
The agency should also demand operational pressure data. Before selection, the agency should determine what matters most operationally, create metrics for measurement, and ask the vendor to provide real results from one of their customers who most closely matches the agency’s profile. Some agencies request operational pressure test results from the vendor directly. Those are highly valuable, but vendors will often say they cannot access them. Push anyway.
Reference site shadowing is the third leg of a proper vendor evaluation. The agency should pressure the vendor to provide three to five references of similar size and operating profile. The agency should then invest time sending people from the various stakeholder branches to shadow at those agencies. Do not send people in to build their own opinion. Send them in with a script of questions, a scorecard, and instructions to document positive and negative observations equally. Even agencies that love their system will have something to say about the negative components. Listen for both.
Collectively, a reference site shadow, a sandbox with vendor support, and real operational pressure data create a much more well-rounded picture of the product than a rehearsed demonstration. Keep the demonstration. Get the stakeholders excited about what is coming. Then put the demo team on the spot. Ask hard questions. Require lab hours after each day of demo so stakeholders can put hands on the computers, review parking-lot questions, and work with the demo specialists to actually test the system. Make the vendor earn the business. If something does not look right, ask about it. Ask about it again. Ask about it until it feels right.
Integration Is Where Projects Die
I do not think there is a vendor in the public safety market who loves interfaces.
Over the years, as interfaces have become higher in demand, I have watched vendors actively limit what they will do in terms of interface development. The cost is high. The work is custom. The matrix-staffing model most large vendors use does not handle custom integration work well. Vendors try to sell “standard” interfaces that, in practice, do not exist. Other than a handful of true industry standards, the vast majority of interfaces require tailoring and specifics unique to the agency. The same interface name may appear at two different agencies, but the underlying configuration and the way the software is used at each will differ enough that the interfaces cannot be cloned. Vendors do not want to invest the manpower necessary to properly understand, scope, develop, test, and deliver custom interfaces. They will try to talk the agency out of needing them.
The current industry trend is large vendors acquiring smaller companies that fill out their portfolio. Changing the name on the product and bolting it onto the existing system does not necessarily mean it will work well as an integrated system. The industry buzzword of the moment is “ecosystem.” For many vendors, that means a bunch of products from acquisitions bolted together into a complex web of functionality that rarely works smoothly. CentralSquare, for example, markets a “fully integrated, one-stop cloud solution” connecting 911, CAD, RMS, Mobile, and Jail systems. The marketing is accurate as far as it goes. Whether the underlying integration is engineered as a single architecture or assembled from acquired products is a question the agency has to ask explicitly.
My advice to any agency evaluating a major vendor: ask which components of the proposed system came from an acquisition and when the acquisition occurred. Then carefully evaluate the user experience across the seams. A bolt-on is not integration. It is rare to find a vendor with a system that was truly engineered from the ground up as a suite. Those vendors are largely gone. That is acceptable as long as the products that have been assembled are properly connected and the necessary code has been rewritten to allow smooth integration and user experience. This is one of the things that will show well during the vendor demo, that will even look passable while green users from the agency are configuring and testing. A year into use, the issues surface.
The cloud transformation in public safety has accelerated this dynamic. Open APIs are now standard in vendor marketing. Cloud connectors are positioned as the answer to integration complexity. In practice, the API exists. The connector exists. The integration work between them still requires custom development, custom testing, and custom certification against the agency’s specific use cases. Cloud architecture has not eliminated interface engineering. It has shifted where the engineering happens and made the boilerplate scoping easier to disguise as completed work.
The single most important thing an agency can demand during pre-sales is a Principal Systems Engineer or Senior Pre-Sales Engineer assigned to the engagement specifically for interface scoping. The engineer has to conduct real discovery, real requirements gathering, real construction planning. It is virtually impossible for a vendor to tell a customer that they have properly scoped an interface without ever having looked under the hood. Most vendors will produce a rough order of magnitude estimate, a boilerplate scope document, and call the work scoped. Then during deployment, when real discovery is conducted and requirements gathering happens correctly, the scope triples. The change orders begin to flow.
Vagueness is the vendor’s friend. The dirty details live in the gray area. The agency has to hold the vendor accountable for requirements gathering and signature on the recipe card before the cooking begins. The successful CAD deployments I have seen have all done this. The failed ones almost universally did not.
The integration scope drives 30 to 40 percent of the project timeline. Civic IQ’s analysis of CAD/RMS implementations recommends allocating that percentage specifically for data validation, conversion testing, and parallel operation of old and new systems. Agencies that compress this percentage to meet a deadline pay for it during cutover.
The Change Management Dimension
I am consistently surprised by how many agencies undervalue organizational change management.
I cannot think of a single valid reason this happens. I think most organizations do not actually understand change management and how essential it is to the program. Investment in OCM is the best investment the agency will make. It reduces user fatigue. It aligns stakeholders. It establishes change champions. It helps the organization embrace the change in a positive manner, collectively, over a reasonable period of time. It shows ROI at go-live and continues to show ROI for years afterward.
The research on this is decisive. Prosci’s two-decade body of research, drawn from more than 10,800 change management practitioners, has produced clear findings. 88 percent of projects with excellent change management achieve their objectives. Only 13 percent achieve their objectives when change management is poor or absent. That is not a marginal effect. That is the single largest predictor of whether the technology investment will deliver.
The structure of the change management approach matters as well. Prosci’s research shows that 59 percent of projects applying a defined change management methodology achieve good or excellent levels of change management effectiveness, while only 26 percent achieve the same outcomes with unstructured approaches. Structure produces predictable success.
Executive sponsorship is the third lever. Prosci’s research has consistently identified active and visible executive sponsorship as the top single contributor to change success. The inverse holds with equal force. Ineffective sponsorship correlates with a 27 percent project success rate. The sponsor who is named but absent is a sponsor who is functionally not there.
Microsoft’s adoption of the Prosci methodology produced a 450 percent increase in adoption rates across their portfolio. McKinsey’s transformation research has independently confirmed that transformation success rises sharply with structured change management. The data does not point in different directions on this question. It points in one direction.
This is the level of rigor that has to be applied to a CAD deployment. The problem is that change management designed for an ERP implementation at a bank does not transfer cleanly to a dispatch floor. The users are different. They are programmed differently. They respond to change differently because their daily environment is adrenaline, multi-tasking, and high-performance work. They see their systems differently. If the system misses a beat, someone’s life could be in danger. The communication required to solicit usable information from public safety users is different from the communication that works in a corporate setting.
Sentinel offers SRM, the Sentinel Readiness Method™, as our proprietary change management framework. While any change management is better than none, SRM is built specifically on the recognition that mission-critical and consequence environments require a different approach. SRM is built around the nuances of the industry we serve. That is what produces the strongest possible change management plan and minimizes the deployment risks that generic OCM cannot address.
The Signs of a Program That Will Succeed
When I look at a CAD modernization program in early stages and I know it is going to land well, the signs are consistent. The agency is doing things that other agencies are not.
The first sign is a defined governance structure. There is a steering committee. There is an executive sponsor who is actually engaged, not just named. There is a clear escalation path. There is a documented decision-making framework. The agency is not relying on goodwill to resolve conflicts.
The second sign is a solid organizational change management plan that started during initial discovery, not after contract signature. Stakeholders are informed and engaged. They were involved in discovery and requirements gathering before the RFP. They will be involved in deployment. The same people who run the procurement are the same people who own the program through go-live. The continuity matters.
The third sign is strong documentation discipline. The agency has decided how decisions get documented, how interface requirements get captured, how change orders get evaluated, how risks get logged and tracked. The vendor knows what is expected. The agency knows what it is producing.
The fourth sign is the vendor’s pre-sales posture. The vendor is providing more than a skeleton crew for discovery, requirements gathering, and scoping. The vendor commits the right engagement up front so the scope of work and the contract are thorough enough to minimize scope creep and risk during deployment. The agency holds firm on this. Vendors who are not willing to dedicate the time or staff to a real evaluation get cut from the short list. That is a strength signal, not a weakness signal.
The fifth sign is the quality of vendor evaluation. The agency demands a real software trial. Almost any software you use today allows for a free trial. There is no reason a $10 million CAD purchase should not include something equivalent at scale. The complexity of the software requires the vendor to provide staff during that trial. The trial cannot end at a rehearsed demo in a perfect environment with perfect data. It has to include a sandbox the agency has had a hand in configuring, with vendor support during testing.
The sixth sign is reference engagement. Real conversations with existing customers. Reference shadowing at agencies of similar size and profile. A few calls to agencies the vendor did not recommend as references. Most public safety and government agencies operate under mutual aid principles. They will talk. Go to APCO. Go to NENA. Hang around the vendor booths the agency is considering. Watch who walks in. Strike up conversations. Existing customers will surface, and many of them will be more candid than the references the vendor selected.
The seventh sign is the discipline of the agency’s own team. The same people in the seats from RFP through go-live. A rock-solid group of stakeholders who own the procurement and the evaluation. People with the time to actually dedicate to building a strong RFP and conducting a thorough evaluation that is led by the agency, not the vendor. No sidebar discussions with the vendor. No closed-door conversations where leak risk is highest. Vendors work hard to find soft spots on the customer team and to extract intelligence from them. The team that stays small, close-knit, and dedicated to the cause is the team that comes through procurement with leverage intact.
The eighth sign is the willingness to invest in pre-RFP discovery, requirements gathering, operational assessment, and business process review before the RFP is written. The agency that does this work produces a procurement document that asks the right questions and an evaluation framework that evaluates the right things. Everything downstream gets easier.
These are not exotic practices. They are the documented best practices that the IACP, ICMA, IJIS Institute, APCO, NENA, the Bureau of Justice Assistance, and the Office of Justice Programs have all published on. The reason most agencies do not run them is not that the practices are unknown. The reason is that the practices require time, discipline, and a willingness to slow down on the front end in order to speed up everywhere else. The agencies that do the work win the program. The agencies that skip the work pay for the program for a decade.
The Sentinel Delivery Framework™
The Sentinel Delivery Framework™ is near and dear to me.
SDF has been the saving grace on complex deployments that were near failure when I arrived. It has helped me pick up the pieces, change the course, and begin delivering results almost immediately. It is a distinctly different methodology from what is typically used on public safety technology programs, and it impresses even the stakeholders who are the most challenging to impress.
The framework rests on a few core components. The right mix of regular engagements with the right participants. Strict documentation requirements shared in a manner that creates transparency among stakeholders and project resources. A clean, organized hub where engagements are tracked, decisions are documented, discussions are viewable and sharable, and resources from the agency and vendor work closely. The framework is designed to work on the most complex programs in the public safety market. It scales down to any size project without losing its core discipline.
The master schedule is the connective tissue. The schedule is updated through a series of disciplined engagements with the vendor and customer resources. It is governed by thresholds that require specific approvals when certain conditions occur in the schedule. The schedule is one of the most neglected components of most projects I have seen, and it is one of the easiest things to maintain when the engagement discipline is in place. No other tool in the project will tell the team when a resource is overloaded, when a deadline is at risk, and what failing to deliver one task will do to subtasks and the entire program. The discussions with the scheduler are often about what work will need to slip or be reprioritized. Those conversations inevitably surface timeline, budget, and resource constraints before they become crises.
The information exchange discipline is the second pillar. How deliverables are committed to. How interface documents, provisioning and configuration decision documents, and the dozens of other documents exchanged on a program are delivered, confirmed as reviewed, red-lined, updated, and executed. The framework treats documentation as the program’s audit trail, not as bureaucratic overhead. Decisions get captured. Stakeholders stay informed. Resources are held accountable.
SDF holds the core components of PMI methodology. It is far more advanced and more thorough in the ways that matter for the caliber of programs we deploy. It is specifically designed for the deployment of high-profile, high-consequence technology programs that require a level of detail and documentation most software deliveries do not need. It is built to withstand public scrutiny, inspector general review, and the forensic review of the technology team that inherits the system after go-live. It produces a blueprint of the entire deployment, every decision that was made, every design that was delivered. It includes a mechanism and process to collect product issues and risks during deployment that must be remedied before go-live. Things that were missed during the RFP. Things that surfaced during configuration and testing. The framework captures them, prioritizes them, and drives them to resolution.
The credential behind SDF is the credential behind Sentinel itself. We have done the work and watched it fail from both sides. This framework was not designed by people who have never used the software. It was not designed by people who have never worn the headset, used the records system, or booked someone into jail. It was not designed by people who have never managed the project, conducted the discovery work, created the business process redesign plan, or carried out the agency assessment. We have done all of these things. We have sat in the operator seat. We have deployed projects from the vendor side. We have watched programs fail from both seats and rigorously documented the failure and the forensic evaluation that followed.
We are the ones who built failed programs back up, course-corrected, and delivered. SDF was designed to account for what we saw go wrong. It creates transparency among stakeholders. It demands accountability from the vendor. It requires commitment from project resources. It surfaces deficiencies, immediately and non-confrontationally, before those deficiencies become issues that impact timeline or budget.
The Infinite Game of Public Safety Technology
Simon Sinek drew the distinction between finite games and infinite games. Finite games have known players, fixed rules, and a defined endpoint. Infinite games have changing players, evolving rules, and no endpoint. The mistake leaders make is playing infinite games with a finite mindset.
Public safety technology is the most consequential infinite game in local government.
A CAD modernization program is not a finite game. The contract is signed, the system goes live, and the work continues. Operators continue to dispatch. Records continue to be created. Integrations continue to evolve. New vendors enter the market. New federal mandates take effect. New community expectations emerge. The system the agency selects today is the system the agency will live with through political administrations, leadership transitions, and operational pivots.
The agencies that play this game well are the agencies that maintain a long-game discipline. They invest in pre-RFP work because they understand that the cost of skipping it compounds. They write thorough requirements because they understand that the cost of vague requirements gets paid for years. They run real vendor evaluations because they understand that the time saved by Hollywood demos gets spent ten times over during deployment. They demand interface discipline up front because they understand that scope creep during deployment is the single largest predictor of program failure. They invest in change management because they understand that the technology is only as effective as the operators who use it.
They do not optimize for the speed of contract signature. They optimize for the success of the program over the decade that follows.
The Decision in Front of You
If you are a public safety agency facing a CAD modernization, RMS replacement, JMS upgrade, or any related mission-critical program in the next 12 to 18 months, the most important decision in front of you is not which vendor to choose. The most important decision is how you will run the program before the vendor selection is ever made.
The how determines the who. The how also determines whether the program will survive the political administration that authorized it, the leadership transition that may occur during deployment, and the operational stress test that go-live will represent.
Sentinel built SDF and SRM for exactly this caliber of program. We govern the deployment. We never sell the platforms. We have done the work in the operator seat, in the vendor seat, and in the program management seat. We have rescued programs that were failing. We have run programs that succeeded because the pre-RFP work was done correctly. We know what separates the two.
Independent. Practitioner-led. Vendor-neutral. Built for the audit file and the council briefing. Designed for mission-critical and consequence environments where the cost of getting it wrong is paid by the operators on shift, the community calling 911, and the leader whose name is on the contract.
The agency that does the work on the front end produces a different result. The agency that does not will spend years explaining why.