Emergency Management Software Problems: The 7 That Surface During Activation, and How to Avoid Them

Why does the first release keep expanding into rebuilding the whole ICS suite?

Every section chief in the building has a board they hate, and the scoping meeting collects all of them. Planning wants situation reports drafted. Logistics wants resource requests. Operations wants a common operating picture. Finance wants cost capture. Someone raises damage assessment, someone else raises staffing notifications, and the scope becomes a replacement for six systems at once.

That platform runs $150,000 to $400,000 phased across 6 to 12 months, and it is achievable. What is not achievable is delivering it as one release for a system used hard maybe six days a year. Emergency management software has an unusual property: it gets almost no daily use, so defects do not surface in the ordinary way. They surface at 02:14 on the second night of a flood, in front of people who will route around anything that fights them and never come back.

Ship the one board that hurts. In this category that is nearly always the resource request lifecycle plus structured cost capture, which is where the money leaks, at $60,000 to $130,000 in 12 to 16 weeks. Prove it in a functional exercise, then in a real activation, then add the next thing. An emergency operations centre tool that has never been activated is a prototype regardless of how complete the feature list looks.

What goes wrong when you migrate ten years of boards and rosters?

The instinct is to bring everything across. Ten years of incident logs, every board, every attachment. It is the wrong instinct, and it is expensive in a way that produces nothing.

Old board entries are free text written under pressure by people who are no longer employed. Forcing them into a structured model means writing mapping rules for entries that never had structure, and the rules multiply until the migration becomes the project. Closed incidents need to stay searchable and retrievable for records requests. They do not need to be modelled. Export the boards to flat files, keep them queryable, and stop.

What genuinely has to migrate is reference data, and it gets skipped because it is unglamorous. Facilities with identifiers, jurisdictions, mutual aid agreements, rosters, credentials, resource catalogues and cost codes. Those are the keys everything else joins on, and their quality determines whether the new system works. The defect nobody expects is that facility identifiers differ between your geographic information system, your shelter list and your computer aided dispatch extract, so the same shelter exists three times. Resolve that deliberately before go live, because resolving it during an activation is not possible.

Credentials carry a second trap. A training record showing a course completed in 2019 does not tell you whether the qualification is current under your own currency rule. Migrate the completion date and compute currency, rather than migrating a status somebody typed.

Why do the CAD, payroll, Esri and notification integrations break after launch?

Each integration here breaks in a way specific to its owner, and none of them are yours.

Computer aided dispatch breaks on access and on version. A read replica is the right pattern, and the vendor upgrade that changes a schema is scheduled by a different department. Read defensively, assert on record counts, and never build logic that assumes a field will always be populated the way it is today.

Payroll breaks on identity and on timing. Time from Munis, Workday or Kronos has to reconcile against your assignment roster, and a person who exists in payroll as an employee number and in the incident as a name is two people until you map them. Do the nightly reconciliation from day three of an activation rather than at closeout, because a mismatch discovered on day three is a phone call and a mismatch discovered at closeout is an appeal.

Esri breaks least often and most visibly. A feature service moves or gets republished with different field names during an unrelated project, and your incident view loses a layer at the worst possible time. Pin what you consume and monitor it.

Notification through Everbridge or Rave breaks on assumptions rather than on the interface. Sending is the easy part. Knowing that a person acknowledged, is already scheduled on the day shift, and holds a current qualification for the position you are trying to fill is your data, not theirs. Keep the delivery infrastructure and your alerting authority where it is, and build the staffing logic on your side.

What happens when cost documentation and offline capture are not covered?

Capture at the source or reconstruct later. There is no third option, and reconstruction is where the money goes.

Structured at the moment it happens means every activity log entry carries a person, a position, a cost centre, a site with coordinates, an asset, hours, a Public Assistance category and a project. Field photographs carry a geotag and a timestamp bound to a damage site identifier that becomes a project worksheet line. Every change writes to an immutable audit log. None of that is difficult. All of it is impossible to add afterwards, which is the entire point.

Procurement documentation is the gap that surprises agencies. Federal cost principles for procurement under 2 CFR 200 apply to anything federally reimbursed, and a contract awarded during an activation without a competitive trail is a finding waiting two years to happen. Flag it while it can still be fixed, in the week the contract is signed, rather than during an audit.

Offline capture is the other uncovered gap and it is a design constraint rather than a feature. A field damage assessment app that must work with no connectivity and sync cleanly touches storage, conflict handling, photo queuing and identity, so it cannot be added late. Ask any developer to demonstrate the app with the network disconnected before you sign, because retrofitting offline behaviour into a connected application is close to a rewrite.

Where document extraction earns its place is narrow and useful: reading vendor invoices, contracts and paper timesheets to pull vendor, date, equipment class and hours, matching to the applicable rate, and putting mismatches in front of a human to confirm. That turns weeks of package assembly into days without any model making a decision on its own.

Should you build custom or configure what you already own?

Buy, and keep buying, if you are a single jurisdiction with two or three activations a year that needs a log, some boards and mass notification, and your state provides the WebEOC licence at no cost to the county. Take it. Do not spend six figures building a worse version of software you are not paying for.

Configure before you build, but be honest about how many times you have already tried. Veoci and Knowledge Center boards are configurable, and vendors will sell you a configuration engagement to prove it. If you have paid for a custom board configuration twice and your staff still export to Excel, configuration is not the answer and a third engagement will not change that. Crisis Track handles damage assessment and debris well and is worth keeping for that even in a build scenario.

Build the layer underneath when these show up. You are burning more than roughly half a full time equivalent per quarter reconciling between systems. Your Public Assistance claims get delayed or deobligated for documentation reasons rather than eligibility. You operate across jurisdictions or agencies with different cost share rules and no vendor's tenant model fits. Or your resource types simply do not exist in anyone's catalogue, which is the reality for ports, utilities, health systems, large campuses and regional authorities.

How do hidden costs get into the quote?

Integration count is the first, so insist on counting it. Each real integration, whether computer aided dispatch from Tyler, Motorola or CentralSquare, payroll from Munis or Workday, an Esri enterprise deployment, Everbridge or Rave, or a state system such as EMResource or EM Constellation, adds roughly two to four weeks. A quote listing integrations as a single line has not been estimated.

Offline and degraded operation is the second, for the reasons above.

Security review is the third, and it is calendar rather than engineering hours. A StateRAMP posture, CJIS handling if dispatch data touches the system, and single sign on against county directory services all take time from people who do not report to your project.

Multi jurisdiction tenancy with different cost share rules is the single largest multiplier, because it is not a permissions problem, it is a modelling problem that reaches into every calculation.

Procurement is the fifth and it is entirely your calendar. Whether you go to a request for proposals, a sole source justification or a cooperative contract, it can add months before engineering starts. Begin it in parallel with scoping rather than after it.

What separates a build that works from one that fails here?

Make a prospective developer model the domain before any contract. Ask them to whiteboard a resource request lifecycle across two jurisdictions with different cost share and a demobilisation that triggers on operational period rollover. If the word ticket comes out of their mouth, they will build you a helpdesk with an incident command skin, because a request carries a lifecycle, a resource type, a jurisdiction of origin, a mutual aid agreement, an equipment rate code and a work and rest cycle, and a board knows only a text field.

Demand integration proof rather than integration claims. Ask which systems, in which direction, and what authentication model they used on each.

Treat audit and compliance as design questions in the first workshop: the immutable log, the retention schedule, the public records export, and how the system produces procurement documentation without anyone remembering to.

Then insist on the two proofs that matter. Demonstrate the field application with the network cable pulled. And run the system in a functional exercise before go live, with the people who will use it at two in the morning. Ownership follows the same logic: source in your repository, infrastructure as code, no per seat trap, and a written runbook, so any competent developer can stand the system up from the repository alone.