Case 01
Four failed conditions stayed in the recovery report
In 2021 we examined twelve disruption scenarios involving customer operations and their technology and supplier dependencies. The exercise had been scheduled, staffed and completed. That made it tempting to present completion itself as a positive result. Eight scenarios met the conditions agreed for the exercise; four did not. In those four, the relevant component could be available while a subsequent customer action remained blocked or required authority that the exercise team had not secured.
I asked for the four failures to remain prominent in the management account. The trade-off was practical and reputational inside the organisation. A simpler completion message would have supported confidence in the programme and allowed the team to move on. A more accurate account required additional work, expenditure and discussion with colleagues whose local recovery measures had appeared satisfactory. I owned the operating coordination, while the technology and risk leaders retained their separate responsibilities.
We assigned an operating owner to each failed condition, traced the unresolved handoff and agreed the evidence needed before a retest. Management funded AUD 780,000 in follow-up work, including process changes, additional rehearsal time and support arrangements. We did not aggregate unlike recovery times into one reassuring average. Each scenario retained its own starting assumptions and completion conditions, so a later result could be compared with the question the original exercise had actually asked.
The result was an accountable correction programme rather than a claim that the bank had become immune to disruption. The four scenarios were scheduled for retesting after their work was completed; they were not retrospectively marked successful. The enterprise gained a clearer distinction between an exercise that happened and a capability it had demonstrated. I would involve the customer-operations participants earlier in setting the exercise conditions next time. Waiting until the result discussion to expose the difference between a restarted component and a completed task created avoidable disagreement about what success was supposed to mean.