Make the continuing software obligation understandable

A custom feature may have been justified when introduced and still need a fresh decision before an upgrade. I ask the business owner to explain the current requirement, the available standard behaviour and the consequence of retiring or changing the code. In our eighty-six-item review, thirty-one lacked a current justification that could be explained adequately. Nineteen were retired and twelve rewritten through a defined programme, with owners participating in acceptance. The other fifty-five were not described as permanently correct merely because they stayed outside that change scope. I had previously allowed familiar screens to be preserved to ease delivery, so the review included my own decisions. The capability is to make maintenance obligations discussable with business colleagues, rather than treat every inherited modification as essential or remove it solely because IT prefers fewer components.

An archive is useful only within the rights, instructions and dependencies that make it usable. In an authorised verification exercise, source materials existed for five business applications, but two initially built successfully in isolation. We examined dependency versions, build tools and instructions with the supplier and appropriate advisers. After ten weeks of funded work, four could be reproduced and one remained unresolved. A successful build did not by itself establish production readiness, complete functionality or unrestricted rights to maintain the software. I kept those questions separate in the executive account. My responsibility was to test the technical evidence behind a continuity claim and make the remaining dependency visible. The company needed to know what another team could actually do with the materials, not merely whether a receipt confirmed that something had been deposited.

A test environment can expose real details if its data has simply been copied from business systems. Our review found customer-contact information in nine of sixteen datasets. We replaced those nine with fabricated material designed for sixty-five defined scenarios, retaining fifty-eight within the replacement approach and identifying seven for separate controlled work. The result was not a claim that every possible behaviour had been tested or that renaming a dataset made it anonymous. Test owners had to state which conditions the new material represented and which it did not. Access and retention decisions for existing copies required appropriate review. I wanted development teams to preserve useful evidence without treating real customer identities as an automatic ingredient of a convenient test, and without hiding the coverage lost when the material changed.

A board or CEO needs to understand the business consequence of a technical limit without receiving a catalogue of every implementation detail. I describe which application cannot yet be rebuilt, which behaviour remains customised and which test scenario still needs another approach. The account includes the owner, cost and next decision, rather than a broad statement that the platform is future-proof. I also distinguish verification from operation: an isolated build is not a production release, and a fabricated dataset is not evidence of every real-world condition. This makes it possible to fund the remaining work or accept a defined limitation knowingly. I work with commercial, legal and operating colleagues where their authority is relevant, while retaining responsibility for the accuracy of the technology evidence I bring into the decision.