Beyond the Bound Report: Taking Ownership of a Consultancy Project’s Working Assets

A consultancy project usually ends with a document. It may be a strategy paper, a diagnostic report or a set of recommendations. The document is important, but it is rarely the part of the work that keeps the business running. The working files behind it — the model, the assumptions, the decision log, the source data and the version history — are what allow a client team to update, challenge and reuse the advice. If those files stay with the adviser, the client owns a conclusion but not the means to revise it.

That is not a reason to treat every engagement as adversarial. It is a reason to be specific early. The following guide sets out what UK clients should ask for, how to write it into the contract and how to test it at handover.

The report is a summary; the working files are the machinery

Most reports compress months of work into twenty or thirty pages. They present the findings and the recommended route, but they cannot show every assumption, every discarded option or every adjustment to the source data. The working files do that. They include the spreadsheet or model used to test scenarios, the register of assumptions with sources and dates, the log of decisions taken during the project, the data extracts that fed the analysis and a record of versions.

Without them, a simple update becomes a new commission. A change in input costs, a revised forecast or a new regulatory point can leave the client unable to rerun the analysis. The business may also struggle to explain why a recommendation was made if the reasoning sits only in the adviser’s notes.

What to specify in the schedule

UK clients should define working files in the statement of work rather than rely on a general promise to hand over project materials. A useful schedule names the items and the format. It should cover:

• calculation models in their native format, not only PDF printouts;
• an assumptions register showing the source, owner and date of each key input;
• a decision log recording the options considered and the reasons for the chosen route;
• source data or extracts, with enough provenance to show where figures came from;
• a version history or change log for the main files;
• a short readme explaining how the model or analysis is structured and how to update it;
• any scripts, queries or configuration needed to reproduce the work.

Native format matters. A PDF of a spreadsheet is a picture, not a working tool. The same applies to dashboards and data visualisations: the client may need the underlying data and calculation logic, not just the final view.

Contract terms that avoid an awkward handover

The contract should make handover a defined milestone, not an afterthought. It can state that final payment is due once the working files have been delivered and accepted against the schedule. That is not an aggressive position; it is a sensible completion test.

Ownership and licensing need care. The client should own, or have a broad licence to use, the bespoke materials created for the engagement. The adviser may retain ownership of generic tools, templates or third-party software. Where a proprietary model is used, the contract should say what the client will receive: a licence, a data export, a documented set of outputs or a right to have the model maintained for a period.

Data protection also belongs in the schedule. Working files can contain personal data, commercial secrets or information received from third parties. The contract should set out what will be transferred, on what lawful basis, how long it will be kept and how it will be deleted or returned. UK GDPR obligations do not disappear because a project has ended.

The handover test

A handover meeting is more useful when the client team operates the files and the adviser observes. The aim is not a demonstration by the adviser but a test of whether the client can use the work without calling them.

Choose a small but meaningful test. Change one assumption in the model and see whether the outputs update correctly. Trace a figure from the final report back to the source data and the calculation. Ask a member of the client team who did not work on the project to explain the model’s structure from the readme. Check that formulas are visible rather than hardcoded, and that the version history matches the final report.

Record the test. Note what worked, what was missing and what the adviser agreed to supply. A short acceptance note, signed by both sides, is enough. It protects the client and gives the adviser a clean close.

After the handover

Working files need a home. Put them in a controlled folder with an owner, a naming convention and a review date. A shared drive that nobody maintains is little better than an adviser’s inbox. The client team should know who can edit the model, who can approve changes and where the assumptions register is kept.

A thirty-day review is a practical habit. It gives the client time to use the files on a live question while the adviser is still available for clarification. After that, the relationship can move to a maintenance or support arrangement if needed, but it should be a choice rather than a dependency.

When not everything can be transferred

Some files should not be handed over in full. Third-party data may be licensed restrictively. Personal data should be minimised. An adviser’s generic methodology may be commercially sensitive. The answer is not to abandon the request but to agree the substitute: a data extract instead of a full database, a documented output instead of a proprietary model, or a licence instead of ownership.

The test is practical. Can the client’s own team operate, update and explain the work after the engagement? If not, the contract and the handover need revisiting.

A final report records what was advised. The working files determine whether that advice can live in the business. Specify them early, test them at handover and give them an owner. The result is a cleaner ending and a more capable client.