What you will learn
- What a common operating picture contains, and what it deliberately leaves out
- How resource requests move from need to fulfilment across agencies
- How tasks are assigned without two agencies doing the same job
- What situation reports need to be useful to a decision-maker
- How coordination works when connectivity and staffing are degraded
What the project is
A disaster involves many organisations: fire, medical, police, utilities, shelters, food distribution, and volunteers, each with its own radios, systems, and procedures. Coordination software provides a shared workspace: incidents and needs are logged once, visible to all participating agencies, and assigned to one owner. Resource requests, such as pumps, generators, or shelter beds, move through a visible pipeline from requested to assigned to delivered, so nobody promises the same generator twice.
The platform's discipline is ownership. Every need has one owner, every task has one assignee, and every resource has one status. Without that discipline, a shared board becomes a shared confusion, where five agencies see the same need and each assumes another is handling it. The software enforces ownership by design: a need cannot sit unassigned without being visible as unassigned, and a task cannot be claimed by two agencies without the conflict being obvious.
Core features
Ownership visibility is the feature. A coordination board that hides unassigned needs is worse than no board, because it creates false confidence.
- Shared incident and needs log, visible to all participating agencies, with one owner per item.
- Resource request pipeline: requested, approved, assigned, in transit, and delivered, with the requester able to see progress.
- Task assignment across agencies, with conflict alerts when two agencies claim the same task.
- Situation reports generated from the live log, so decision-makers read current facts rather than yesterday's summary.
- Map view of incidents, shelters, road closures, and resource locations, shared across agencies.
- Role-based access per agency, so sensitive information is shared with those who need it and not published broadly.
- Offline-tolerant field updates, because coordination must continue when connectivity degrades.
How it is built
Build with the agencies that will use it, in a joint exercise, before a real disaster. A coordination platform first tested during a disaster will fail during that disaster.
- Agency study: map the agencies, their roles, and their existing systems, and agree what the shared picture will contain.
- Core build: shared log, ownership, resource pipeline, and task assignment, with role-based access per agency.
- Exercise testing: run a tabletop and then a field exercise, and fix every coordination failure the exercise reveals.
- Situation reporting: generate decision-maker reports from the live log, and test them with real emergency managers.
- Readiness routine: regular exercises and data hygiene, because a coordination system unused for a year will be forgotten when it is needed.
Tech considerations
The technical priorities are availability under load, simple interfaces for stressed users, and access control that agencies trust.
- High-availability hosting with load handling for the surge that accompanies a major incident.
- Simple, fast interfaces that work on a phone and on a slow connection, because coordination users are stressed and often mobile.
- Offline-tolerant updates with sync, so field reports are not lost when connectivity drops.
- Role-based access per agency and per incident, with audit trails on every change.
- APIs or imports from agency systems where they exist, so the shared log does not require double entry for every item.
Challenges to plan for
Coordination platforms fail on trust and on exercise gaps. Agencies that do not trust the shared picture will keep their own, and the duplication the platform was meant to fix returns.
- Agency trust: an agency that fears its data will be misused or its performance judged will withhold information, and the picture becomes partial.
- Information overload: a shared log with thousands of entries buries the decisions that matter, unless filtering and prioritisation work.
- Exercise scarcity: a system used only in disasters is unfamiliar in disasters, so regular exercises are part of the product, not an extra.
- Access during outages: power and network failures hit coordination centres too, and the platform needs a degraded-mode plan.
Who it is for, and honest limits
This fits emergency management agencies, county and regional coordination centres, and multi-agency response partnerships. It fits less well for a single-agency response, where an incident command tool may be a better fit than a multi-agency platform.
It does not command agencies or replace their authority. It gives them a shared picture and a shared task list. Command decisions still sit with the agencies and their legal authority, and the platform should make those decisions visible, not make them itself.
Frequently asked questions
What is a common operating picture?
A shared, current view of an incident: what has happened, what is needed, who is doing what, and what is still unassigned. It is the coordination product that every participating agency reads, so decisions are made from the same facts.
How are resource requests tracked?
Through a visible pipeline from request to delivery, with one owner at each stage. The requester can see progress, and the coordinator can see which requests are stalled and why.
Can agencies keep sensitive information private?
Yes, through role-based access: information is shared with participating agencies by default, but sensitive items can be restricted to named roles. The access rules should be agreed before a disaster, not negotiated during one.
What if connectivity fails?
Field updates are stored offline and synced when connectivity returns, and the coordination centre needs a degraded-mode plan, such as radio reporting into a single scribe. The plan should be exercised, not just written.
How is it different from an incident command tool?
Incident command tools manage one agency's response to one incident. Coordination platforms manage many agencies across many incidents in a disaster, with shared needs, resources, and tasks. The two connect, but they solve different problems.