Defining service and operational scope

When a manager says, “We need a continuity plan,” do not begin with a list of disasters. Ask which service must continue, for whom, and where the team's responsibility ends. A business continuity management system organizes preparation, response, recovery and improvement; ISO's public overview of ISO 22301 supports that broad description. This lesson does not establish conformity with a particular clause or certify a management system. The specialist drafts an operational scope that can be tested and puts it to the authorized service owner for approval. A useful scope describes the outcome, beneficiaries, channels, locations and dependencies. “All operations” is too broad to test. “The main server” is too narrow because it names a resource rather than an outcome received by a customer.

Begin with a result visible to a service user. In a fictional pharmacy delivery service, the result is delivery of a correct order after the professional checks required by that pharmacy's procedures. Trace an order from receipt through verification, packing, carrier handover and proof of delivery. These activities are not interchangeable. The app may work while a pharmacist cannot verify orders, leaving the service impaired. Conversely, a controlled paper log may allow a limited number of orders while the app is unavailable. Name the service before listing applications, then list the activities and resources that enable it. Do not transfer a fictional pharmacy's boundaries to a real organization without checking its actual procedures.

Define four dimensions. Beneficiary: are individual patients covered, contracted hospitals, or both? Output: does the scope end when an order is prepared or delivered? Channels and locations: does it include the phone, app and city branch, or every branch? External dependency: does the organization transport orders or hand them to an independent carrier? State exclusions with reasons. Excluding transport operations does not make carrier failure irrelevant; transport remains a dependency affecting delivery. A practical scope card records the service, beneficiary, start and end points, channels and locations, exclusions and reasons, then the owner's name and review date.

The specialist gathers evidence and identifies conflicts but cannot unilaterally change a customer promise or contractual coverage. If operations staff describe one boundary and a contract describes another, mark “owner decision required” and escalate it. A plan built on an unapproved promise can appear successful in an exercise and fail during disruption. Make the assumption visible rather than hiding it: scope is a decision record, not an exercise in producing the shortest resource list.

To make the card operational, walk one order from its first contact to the promised outcome. Mark each handoff between teams or systems and ask which record proves that it occurred. If handover to the carrier cannot be evidenced, do not state that the service ends there as though proof exists. Record the evidence gap and ask the owner for an interim decision: introduce a handover record or move the closure point to an observable event. This matters during disruption because the app and carrier may report different numbers of “completed” orders when they count different events. Tie the boundary to an observable event rather than a vague phrase such as “when work is done.”

Check how scope changes over time as well. A new branch, a messaging channel or a different carrier can leave yesterday's card historically accurate but operationally obsolete. A small change does not require rewriting every plan. Identify the changed field, its effect on activities and dependencies, and the person who approves it, then update the controlled version. If the change introduces a new service rather than another channel for the same service, seek a decision to include it instead of silently appending it. The resulting scope becomes a reliable input to later impact analysis rather than a memorized list of names.