What is a common operational picture, and how do you build one that works?

A common operational picture is a single, shared display of the information that matters for an operation: where your people and resources are, what is happening, what has been asked of whom, and what the conditions are. Everyone with a role in the operation sees the same picture, filtered by what they are allowed to see, and decisions are made against it.

The term comes from military command and control, where it describes an identical display shared by more than one command so that planning and situational awareness line up across echelons. Civilian emergency management adopted it too. The US National Incident Management System (NIMS) describes a common operating picture as an overview of an incident, compiled from many sources, that gives the incident commander and every supporting agency the same understanding of the incident’s status so they can make consistent, timely decisions.

Three words carry the meaning. Common: the fire and rescue service, the council and the volunteer team are not looking at three different versions. Operational: it serves the people running the job right now; the report comes later. Picture: it is usually a map, because most field questions start with “where”.

Situational awareness happens in a person’s head: noticing what is going on, understanding what it means and anticipating what comes next. A COP is the shared input to that process. A good picture makes awareness easier for everyone at once; it cannot replace the judgement of the people reading it.

This matters in practice. A picture packed with every sensor, feed and track can lower awareness, because the one thing that matters is buried. The goal is the smallest picture that answers the questions the operation actually has to answer.

The content depends on the operation, but most working pictures contain the same building blocks:

• Own resources: people, teams, vehicles and equipment, with where they are and what state they are in (available, en route, on scene).
• Events: incidents and observations reported from the field, each with a time, a place, a source and a severity.
• Tasks: who has been asked to do what, where, and whether they have acknowledged it.
• Areas and features: search sectors, cordons, closed roads, assembly points, hazards, staging areas.
• Context: weather and official warnings, water levels, traffic, sensor readings, camera or drone feeds where they exist.
• Time: when each item happened, when it became known, and how old it is now, so a position from forty minutes ago is never drawn like a live one.

Most failed COP projects look fine in a demo and fall apart on the day, usually for ordinary reasons:

• Nobody owns a layer. If no one is responsible for keeping the closed-roads layer right, it will be wrong by noon.
• Stale data looks fresh. Without timestamps and an obvious age on every item, people act on old positions.
• It needs a signal. Field teams lose coverage in valleys, cellars and at the edge of a disaster area. A picture that only works online goes blank exactly when it is needed. See offline maps for field teams.
• Reports are not verified. An unconfirmed rumour and a confirmed observation drawn the same way erode trust in the whole picture.
• Symbols nobody agreed on. Agencies that work together need agreed symbols. Military partners use APP-6 symbology; civilian teams often have their own sets.
• Only the coordinator can read it. Then it is one person’s picture, however many screens show it.

Sinkaos is built around one shared operational picture: people, incidents, tasks, messages and live data on one map, with offline mission packs on every phone and a timeline that keeps when something happened apart from when it became known. Reports made without signal are queued and placed on the timeline correctly when they arrive. See how it works.