Readiness Assessments for New Services

A readiness assessment for a new service is a structured check, before launch, of whether the service is ready to operate and to withstand disruption. It examines the service's map, its tolerance, its dependencies including suppliers, its recovery arrangements, and its evidence trail, and it asks whether each one is in place and has been tested, or whether it is still an intention. A service should go live when its assessment shows that its critical arrangements operate, not when its launch date arrives or its design looks complete on paper.

The assessment matters because a new service enters operation with no incident history and no track record to reassure its users. Its first disruption will be its first real test, and if its map is incomplete, its tolerance is untested, or its recovery sequence has never been rehearsed, that disruption will reveal all three at once. A pre-launch assessment is the firm's chance to find those gaps while they can still be fixed without harm to users, and to launch with a trail that already shows how the service will be evidenced.

The assessment starts with the map because a new service cannot be judged without knowing what it depends on. The map should show the customer channels, the processing systems, the data stores, the facilities, and the suppliers that the service will use, and it should be built from the service as it will actually run, not from its design documents alone. Design documents describe intention; the map for readiness should describe the service that is about to go live, including any interim arrangements, manual workarounds, or supplier steps that the design did not emphasise.

A tolerance for a new service should be set from the harm its failure would cause to its users, not from what its technology can conveniently achieve. The firm should describe, in plain terms, who will use the service, what they will use it for, and what a stop, a delay, or a loss of data would mean for them, and then set a tolerance that reflects the point at which that harm becomes intolerable. That reasoning should be recorded, because it is what justifies the tolerance to a later reader, auditor, or supervisor.

The assessment should also ask whether the tolerance is testable. A tolerance expressed only in general terms, without a measure a disruption would produce, cannot be tested and therefore cannot be evidenced, and the service will launch with a standard nobody can show it meets. Where a tolerance cannot yet be tested in full, because the service has no operating history, the assessment should say so, set out the testing that will be done before and shortly after launch, and treat the tolerance as provisional until that testing provides evidence.

Before launch, testing should exercise the dependencies the map identifies, in a way that challenges the tolerance. That means rehearsing the recovery sequence with the people who will actually operate it, testing the supplier steps rather than assuming them, and trying the failure modes that the map suggests are most consequential, rather than only the failures that are easy to simulate. A test that rehearses only the easy path will produce a reassuring result and teach the firm very little.

The launch decision should be made on the basis of the assessment, by someone with the authority to delay launch if the assessment reveals a critical gap. That authority matters, because a launch date creates pressure to proceed, and without a clear decision maker empowered to pause, gaps will be carried into operation with a promise to fix them later. Promises made at launch, under deadline pressure, are frequently the actions that remain open longest, because the team moves on to the next launch.

After launch, the readiness assessment becomes the starting point for the service's evidence trail, not a document to be filed and forgotten. The first tests and the first incidents, however minor, should be read against the pre-launch assessment, to check whether the map was accurate, whether the tolerance was realistic, and whether the recovery arrangements worked as rehearsed. Differences should be recorded as updates to the map, tolerance, or plan, with their reasons, so that the trail shows the service learning from its early operation.

The firm should also complete the testing that was provisional at launch, within the period agreed in the assessment, and should not let early operational success substitute for it. A service that runs smoothly for its first period has not yet been tested by disruption, and its smooth running should not be mistaken for proven resilience. The assessment is closed only when its provisional items are tested and its launch actions are closed on evidence, at which point the new service joins the firm's established services, with a trail that began before it ever served a user.