What should survive after a project ends?

There is a familiar moment at the end of a project. The final presentation goes well. The files are approved. The folder is shared, the invoice is submitted, and everyone says they should keep in touch.

A few weeks later, someone needs to change a headline.

Which file is the final one? Who can edit it? Which typeface can the organisation use? Why was this audience selected? Where are the source photographs? Is the video supposed to have subtitles? What happens when the person who managed the campaign is on leave?

The original work may be excellent. Yet its usefulness begins to erode the moment it has to move beyond the team that created it.

That erosion is not inevitable. It is often a sign that the project delivered outputs but did not fully transfer the means of using them.

A good handover is not a ceremony at the end. It is part of the design of the work.

The file is not the capability

A logo file is an asset. A visual identity system is an asset plus rules for making decisions. A report is a document. A communications strategy is a report plus priorities, responsibilities and a way to decide what to do next.

There is nothing wrong with producing beautiful, finished objects. They are often precisely what a client has commissioned. But an organisation that needs to maintain a brand, publish content or manage communication after delivery also needs to know how those objects behave when conditions change.

Consider the difference between receiving thirty campaign graphics and receiving a small, coherent system from which a team can create the thirty-first without guessing.

The first package may be more immediately impressive. The second may be more useful over time.

That does not mean everything should be made into a template. An original documentary, a distinctive campaign photograph or a carefully made publication may be valuable precisely because it is finished and specific. What needs to transfer is the information required to use, protect, adapt or commission related work responsibly.

In practice, we think about a handover in four layers: assets, rules, reasons and people.

First: assets people can actually find and use

A project should leave behind its agreed deliverables in usable forms, not merely a collection of impressive previews.

This sounds obvious until a team inherits six folders called FINAL, FINAL-NEW and FINAL-APPROVED-2. The approved social graphic is flattened, while the editable file contains an older date. The only copy of the video master is on a former contractor’s computer. The font used in the design is licensed to someone else.

These are not glamorous problems. They can consume more attention than the original creative decision.

An asset handover should make it possible to answer, without detective work: What is approved? What is editable? Which format serves which purpose? Where are the sources? What are the restrictions? Who owns access?

That might mean final exports, editable master files where agreed, a clear version record, licensed asset information, agreed usage rights, text and caption files, and a simple map of the folder structure.

For websites, it also means being precise about domains, hosting, environments and who can maintain them. For campaigns, it includes distinguishing original production assets from platform exports. For identity work, it includes making files available in formats the actual team can use.

The goal is not a large archive. It is retrievability.

A folder that contains everything but cannot tell its next user what matters is not a complete handover.

Second: rules that make the next decision easier

The value of a design system is not that it prohibits variation. It is that it helps a team distinguish useful variation from accidental inconsistency.

A colour palette and a logo-clear-space diagram may be necessary. They are not sufficient to answer every real production question. How should a headline behave in another language? Which images belong to the brand and which do not? When does an institutional partner’s mark need to appear? How do formats change from a report cover to a mobile post?

Similarly, a communications framework should do more than say post consistently. It should clarify how topics are selected, how audiences are considered, how information is checked, who approves content and what happens when a planned story becomes unsuitable.

In our UNDP protected-areas work, the outputs included visual identities and identity guidance for protected-area clusters. The useful idea behind such deliverables is straightforward: an identity should be more than a one-off graphic. It should provide a coherent basis for future applications.

That establishes what the project delivered; it does not prove how often those tools were used later. Long-term adoption is a separate question.

The distinction is important. Delivering a manual is an output. Helping a team understand it is an activity. Demonstrating sustained use requires observation after handover.

We should not collapse the three simply because a complete story sounds better in a case study.

Third: the reasons behind the rules

A guideline tells someone what to do. The reasoning behind it helps them know what to do when the guideline no longer fits.

Suppose a campaign system has a rule about the size of its headline. Six months later, the organisation needs to adapt it for a language with longer words and a different line-breaking pattern. Should the headline be smaller? Should the composition change? Is the hierarchy more important than the exact point size?

If the handover contains only a specification, the next designer must guess. If it also communicates the principle, they can make an informed choice.

The same problem appears in strategy. A recommendation may make sense at the moment it is written, but circumstances shift. Audiences change, budgets tighten, a platform alters its behaviour, and an institution has a new priority.

A useful handover does not attempt to predict every possible future. It records the important choices, the evidence behind them and the assumptions on which they depend.

We find a small decision record more useful than pages of vague principles. For an important choice, note:

What did we decide? The practical rule or priority.

Why? The evidence, objective or constraint that made it sensible.

What would make us reconsider? The change in circumstances that should trigger review.

That third question is often missing. Yet it prevents a strategy from becoming an unquestioned rule simply because it was printed in a final report.

This is not an invitation to document every conversation. It is a way of preserving the decisions future teams are most likely to need.

Fourth: people who can use what remains

No amount of documentation can replace all the judgment involved in communication. A team still needs to make choices, interpret feedback and recognise when a template is no longer adequate.

This is where training, walkthroughs and shared practice matter.

An effective handover may involve a team trying to produce a real piece of content using the new system, rather than watching a demonstration. It may involve walking through a difficult approval decision or asking someone who did not participate in the project to find the correct assets without help.

Those are revealing exercises because they test the receiving organisation rather than the confidence of the people delivering the presentation.

Alongside a comprehensive digital ecosystem review for the OSCE Mission to Bosnia and Herzegovina, SO.. delivered staff training. The assessment and strategic recommendations addressed systems and decisions; the training brought the work into a practical learning setting.

That is a meaningful part of the engagement. It would be a different and unsupported claim to say that the training permanently changed every workflow or that the team subsequently operated without assistance. The distinction between training delivered and capability demonstrated over time matters.

A useful test for any training component is whether participants have an opportunity to apply the material, encounter uncertainty and get feedback, not just whether they attended.

An organisation should not have to remember a presentation perfectly to benefit from the work it paid for.

Handover begins earlier than the last week

If a project waits until the final week to consider maintenance, somebody will usually discover that the chosen system is harder to operate than anyone expected.

A better approach asks questions during the brief. Who will use this when we leave? What tools do they have? What can they realistically maintain? Which tasks must they be able to do independently? Which tasks should still require specialist support?

Not every organisation has the same capacity. A large institution may have several approval layers and specialised communications staff. A small cultural organisation may have one person juggling programming, fundraising, design and public enquiries.

The right handover for each will differ.

A highly configurable system might be appropriate for the former and a burden for the latter. Sometimes a carefully prepared small set of templates is better than a sprawling design library. Sometimes the client needs training; sometimes it needs an external maintenance arrangement; sometimes it needs a simpler product.

The sophistication of the handover is not measured by the number of files.

It is measured by whether the agreed work can be used under real conditions.

A practical test: can a new colleague do the next thing?

Here is a useful thought experiment for an organisation accepting a new brand or communications system.

A colleague joins three months after delivery. They did not attend the workshops. Their first task is ordinary: prepare a social post, update a project description, or brief a supplier to create a new item.

Could they work out what to do without calling the original agency?

If the answer is no, why not?

Maybe the files are hard to locate. Maybe the rules do not explain their purpose. Maybe they cannot access the accounts. Maybe someone must approve the work but no one knows who. Maybe the materials are so elaborate that a normal update requires specialist software nobody owns.

Each failure points to a different handover problem. Adding a longer PDF will not solve all of them.

A modest acceptance exercise can help. Choose one task the client will actually perform after the project. Let a new user attempt it with the delivered material. Watch where they hesitate. Fix the most consequential gaps.

It is a small investment compared with months of improvisation after the work is handed over.

Avoid the false promise of self-sufficiency

There is a slightly heroic version of the handover story: the agency arrives, diagnoses complexity, installs a perfect system, trains the client, then disappears because the organisation can do everything itself.

That narrative may flatter everyone, but it is rarely a useful standard.

Organisations are not static. New people arrive. Priorities and budgets change. Specialist production may still require specialists. Even the best framework needs interpretation, revision and sometimes replacement.

A good handover should make a client less dependent on undocumented agency knowledge. It does not have to make the client independent of every future professional service.

Nor does it mean the agency must give away proprietary working methods or promise unlimited support. The scope should distinguish project deliverables, agreed training, ongoing access, maintenance responsibilities and future changes.

Clarity about these boundaries is part of a respectful commercial relationship.

What to ask for before signing off

You don’t need a hundred-item checklist, but you do need answers that connect what was promised to what will actually be usable.

Can the organisation find the approved work? Can it lawfully use and adapt it within the agreed scope? Are the most important principles and decisions recorded? Does a designated person know who owns each recurring task? Has somebody on the receiving side tried a realistic task? Is there a sensible way to raise a correction, update a fact or revisit an assumption?

And, if the project aims to strengthen capability, what evidence would be needed later to know whether that happened?

That last question should be agreed honestly. A handover can be complete without a six-month evaluation. But a project should not advertise lasting transformation when nobody has measured it.

The most credible claim is sometimes the simplest: we delivered the system, documented the decisions and trained the people who needed to use it. Anything beyond that requires evidence.

Leave behind fewer mysteries

A strong ending to a project does not require a ceremonial presentation full of future-facing language. It requires something quieter: useful files, understandable rules, a record of important choices and people who have had a chance to practise.

Those things rarely make the most dramatic portfolio images. They may nevertheless be among the most important parts of the work.

The agency cannot guarantee what every client will do next. It can make the next useful action considerably easier.

That is what a handover is for.