Mapping for a Single Service First

Mapping for a single service first means choosing one important service, mapping it thoroughly, and learning from that exercise before extending mapping to other services. The approach exists because mapping everything at once usually produces shallow maps, exhausted teams, and a programme that stalls before any service is properly understood. A single service, done well, proves the method, reveals the kinds of dependencies that matter, and creates a usable map that responders can actually follow. It also gives the firm a concrete example to show other service owners, which is more persuasive than a programme plan or a template.

Choose a service that matters to customers, that is well enough understood to map, and whose owner is willing to participate. A service that is both critical and completely mysterious is a poor first choice, because the exercise may stall on basic questions. A service that is important but familiar allows the team to focus on the mapping method itself: tracing dependencies, naming owners, and testing the result. It should also be a service whose disruption would be noticeable, so that the value of the map is clear to everyone involved. The first service is a pilot, and pilots should be chosen for learning, not for maximum difficulty.

It traces the service from its customer outcome through its processes, systems, data, people, and suppliers, in the order the service runs. It names an owner for each part, records workarounds and their limits, flags single points of failure, and notes where information is uncertain. It is detailed where failure would hurt most and lighter where it would not. Crucially, it is tested. A rehearsal that follows the map through a plausible disruption should confirm that responders can find the impact, the workaround, and the recovery sequence. A map that has not been tested is a draft, however complete it looks, and the pilot should not be declared finished until that test has happened.

The pilot teaches practical lessons that a programme document cannot. It shows how long mapping takes, which teams need to be involved, what information is hard to obtain, and where the template or method needs adjustment. It may reveal that supplier information is slower to gather than expected, that manual workarounds are more common than assumed, or that data stores are harder to trace than systems. Those lessons should be recorded and used to plan the next services, including realistic sequencing and support. A pilot that is treated as a one-off, with its lessons filed away, wastes the very learning that justifies starting small.

Expand when the first map is adopted, owned, and tested, and when the lessons from it have been built into the approach for the next service. Expansion does not need to wait for perfection, but it should wait for usability. If the first map is still a draft, if its owner is unclear, or if its rehearsal exposed gaps that have not been closed, adding more services will multiply unfinished work. Sequencing matters too. Services that share systems, suppliers, or teams with the first service are natural next choices, because their maps can reuse and refine what has already been learned, rather than starting from nothing each time.

Starting small can become staying small if the pilot is celebrated and then quietly forgotten. The firm should therefore agree, before the pilot begins, what success looks like and what happens next, including who will sponsor expansion and how the next services will be chosen. Another trap is over-polishing the first map while other services remain unmapped. A good pilot map is usable, not ornate, and its purpose is to enable the next maps, not to win admiration. Under DORA in the EU and under FCA and PRA policy in the UK, the expectation is a coherent understanding across important services, labelled separately in these guides, and a single excellent map is a step toward that, not a substitute for it.