The receiving business inherits the unanswered question

## Ask what the recipient must be able to explain

The transfer list contained 420 product-history records. All could be identified as files or entries in a system, but thirty-seven had unresolved provenance questions. That distinction became the central issue in the handover. The receiving business did not only need possession of the material. It needed to understand which history could support an intended operating use and which parts still required investigation. A technically successful copy would have moved the uncertainty along with the records, without necessarily giving the recipient a useful account of it.

In a separation programme, the deadline has considerable force. Different teams depend on the same milestone, and an exception in one workstream can extend support arrangements elsewhere. I understand why programme leaders want a crisp completion statement. My concern begins when that statement is asked to carry more meaning than the work supports. A transfer can be complete as a technical event while the business acceptance remains qualified. If the two are collapsed, the recipient may discover the qualification only when somebody later asks a question the inherited history cannot answer.

I asked our team to describe the record from the receiving business's point of view. What decision would rely on it? Who would explain the supporting history? Which person could authorise a use that remained uncertain? Those questions were more useful than another discussion of the percentage copied. They also helped distinguish a missing technical link from a missing business judgement. IT could restore an association between records where the evidence existed. It could not invent the evidence or decide that a doubtful history should be accepted simply because the programme needed to finish.

Operations leader Sanjay Belqathi supported a narrower acceptance account. The programme office preferred to transfer the whole group on schedule and resolve the exceptions after handover. That proposal was not careless by definition. In some circumstances a qualified transfer with strong continuing ownership may be workable. We examined whether that ownership and the permitted use would remain clear in our case. I was not satisfied that the scheduled handover would preserve the distinction well enough. The problem was the recipient's ability to understand and manage the exception, not the physical possibility of moving the record.

## Pay for the interval before acceptance

We funded sixty-four lakh rupees and delayed the defined transfer by six weeks. Specialist review and the continued separation support were real costs. I kept them in the proposal because a decision to wait can sound inexpensive when described only as caution. It consumes people, arrangements and time that the business expected to release. The alternative was to accept the transfer schedule and carry a different risk into the receiving organisation. The board needed to see those choices together, without a suggestion that one route avoided every cost.

The work resolved thirty-one of the thirty-seven exceptions through the agreed process. Six remained restricted. I did not treat the remaining six as evidence that the review had failed, nor did I allow the thirty-one resolved items to erase them from the account. The two results describe different groups. Business and technical owners retained authority over the use of the restricted records. Our systems work preserved their status and the evidence available, so that later users would not encounter an apparently ordinary record whose qualification existed only in somebody's memory.

This is where handover design becomes a continuing management issue. A project team often has unusually detailed knowledge of exceptions because it has spent months discussing them. The receiving organisation may not share that knowledge, especially after staff change or support contracts end. A qualification should therefore be understandable without recreating the original programme meeting. It needs a responsible owner, a reason and a clear account of the permitted use. That is different from leaving an unexplained warning on a screen and assuming a future user will know what to do with it.

The six-week delay did not establish a universal rule that transfers should wait until every question is resolved. Our own result still contained restricted records. The useful decision was about the quality of the acceptance account and the work needed to make it credible. Another business could have different obligations, evidence and support arrangements. I would examine those conditions before recommending the same response. The transferable lesson is the question about what the recipient can responsibly rely on. The specific duration and expenditure belong to this fictional case and should not become a standard prescription.

## Keep the restriction after the project closes

Closing a programme changes the incentives around its exceptions. The remaining list can look like an obstacle to declaring success, and responsibility may shift from a temporary team to a business function with many other demands. I wanted the six restricted records to remain visible in the operating account after closure. They were part of what the organisation had received. Removing them from the presentation would not improve their provenance; it would only make the next person less likely to understand the limitation before relying on the material.

A director reviewing such a programme can ask for the distinction between transferred, accepted and restricted records. The board need not assess individual product histories. It should understand whether management has defined acceptance in a way that fits the business obligation and whether the unresolved group has a credible owner. It can also ask what support ends at the milestone and what must continue. Those questions test the completeness of the enterprise decision without turning directors into the migration team or asking them to substitute their judgement for qualified technical acceptance.

The same distinction matters when a subsequent investment paper cites a completed separation as its starting point. Completion should not silently convert a qualified history into a fully supported one. The new proposal needs to know which assumptions it inherits. If it relies on the restricted records becoming usable, that dependence belongs in the paper as future work, with cost and authority attached. Otherwise an earlier exception can become an invisible premise in a later project, making the new business case look more certain than the organisation's actual evidence allows.

Our account ended with 420 reviewed records, thirty-seven provenance exceptions, thirty-one resolved and six restricted after sixty-four lakh rupees and six weeks of additional work. Those figures describe an imperfect but intelligible handover. I prefer that account to a completion percentage that leaves the recipient to discover what it means. A CIO's role is not only to make the transfer happen. It is to help the business preserve the meaning and responsibility that travel with it, so that a later user can distinguish an established history from a question the organisation still owes an answer.