The word recovery can make unlike results sound comparable. One team may mean that an application responds. Another may mean that colleagues can reach the current documents and records needed for a defined task. In an energy enterprise, a listener may infer something broader about the continuity of physical generation. Those meanings should not be allowed to drift together. Before I accept a recovery measure, I want to know what work the examination concerns, who needs to perform it and what conditions the test has actually reproduced. The usefulness of the number depends on that description.
Define the activity before timing the return
Our fictional July 2025 rehearsal covered an enterprise workspace at nine sites. The specified material supported maintenance coordination and management reporting. The exercise simulated a communications interruption affecting that workspace. It did not test plant-control systems, alter safety procedures or reproduce every condition of a real operating disruption. Stating those boundaries made the test more valuable, because participants knew what they were being asked to establish. It also helped prevent a successful application result from being interpreted as a claim about keeping the whole generating fleet in operation.
A useful scope describes the user's work with enough precision to test it. Access to an empty application would not establish access to the required material. Equally, the workspace did not need to become a copy of every system at the site to support the defined exercise. We agreed the activities and evidence with operating colleagues so the technical team did not set the measure alone. That conversation exposed dependencies that would have been easy to overlook if the only question had been whether a server or application could be reached from a convenient test location.
I do not regard this as a reason to make every rehearsal as broad as possible. A bounded exercise can be more informative than a large one whose purpose is unclear. The critical requirement is that its conclusion preserves the boundary. A test of a particular workspace should be reported as such. If management needs evidence about another activity, that need should lead to a suitable examination with the right participants. Expanding the wording of an existing success is not a substitute for doing the additional work. The distinction protects the value of the evidence already gathered.
Time also needs an agreed meaning. Participants should understand the starting condition and what counts as the activity being restored. Otherwise, different sites may stop the clock at different stages while their figures appear in the same table. I want the discussion to settle those matters before results are compared. The intention is not to design a score that makes the programme look slow or fast. It is to produce an account that lets the enterprise decide what remains necessary. A common number is useful only if the underlying activity is sufficiently common to justify comparison.
The late sites belong in the main result
Seven of our nine sites restored the defined workspace within forty-five minutes. The other two required eighty and ninety-five minutes. The programme manager wanted to emphasise the successful majority when discussing wider adoption. That was understandable after substantial work, but the two late sites were not incidental. They revealed where the common arrangement did not yet meet the agreed condition. I kept them in the main decision on the JPY310 million programme and asked for a site-level explanation of the remaining dependencies. The review needed to learn from the variation rather than smooth it away.
An average would not have answered the question we faced. A colleague at the slower site does not experience the average recovery across the fleet. Nor does success at seven locations establish the same result at an untested tenth. Aggregates may help describe a programme, but they should not conceal the obligations that require further action. I wanted each site to retain a clear disposition: the named activity restored within the window, restored later, or not yet established. That gave management a better basis for deciding where work and resources should remain attached.
We did not claim that identifying the two late recoveries had already fixed them. The immediate outcome was a clearer account and a conditional plan. A later exercise would be needed to establish whether the additional work changed the result. This distinction can feel frustrating when a programme is close to completion, but it is essential. An explanation of failure is evidence of understanding; it is not the same evidence as a successful repeat. The enterprise should be able to recognise progress without losing track of the test that still needs to be passed.
The site-level account also changed the discussion with operating colleagues. Instead of a broad assurance that the platform was recoverable, they could examine the activity they needed and the conditions under which access returned. That made the remaining work easier to assign. Technology owned some dependencies, while other decisions required the people responsible for the workspace's use and material. The CIO's role was to make that division coherent. It was not to claim control over every operating responsibility merely because the test involved a digital service.
Completion is a decision about the remaining obligation
A programme can reach an important milestone without reaching the end of its obligation. In this case, seven sites supplied useful evidence, while two required more work and another examination. The question was how to proceed responsibly with that uneven result. We chose to preserve the conditions for wider adoption and keep the slower sites visible. That postponed a simple completion announcement. It also prevented the programme from transferring an unexplained dependency to the people who would have to manage it during a real interruption. A clear remaining obligation is better than an ambiguous declaration of readiness.
For a board or investment committee, I would therefore present the scope, the site distribution, the unresolved work and the proposed next evidence together. Directors do not need to manage the restoration sequence. They do need to understand what management's assurance covers and what it leaves open. If the business requires a broader continuity claim, the plan should show how that claim will be examined. A narrow test can still be valuable within that larger programme, provided the language does not ask it to carry more weight than its design permits.
The lesson I carry into later reviews is simple enough to state but demanding to practise: name the work before naming the recovery. Doing so changes the test from a technical event into a useful management account. It gives the slower sites a place in the result, keeps physical operations distinct from enterprise access and makes the next obligation visible. I want our colleagues to know what they can resume, what they still cannot and who is working on the difference. That is the practical confidence a continuity investment should help the enterprise earn.