The problem handover solves
On opening day, the people who built an exhibit know how it works. A few years later, many of them may have moved on: the designer has other clients, the developer has left the organization, and the staff member who set up the computer has retired. If nothing was written down, the next person faces a screen that has stopped working and no way to learn what it is running, where its files live or who has the passwords.
Good handover means leaving enough information that a competent person who was never involved can understand, operate and repair the exhibit. This is the core of project handover, and it is much easier to do while the project is still fresh than months afterward.
Start documentation before launch
Documentation written in the final week is usually rushed and incomplete. A better habit is to keep notes as decisions are made: why a display was chosen, what a setting does, what was tried and rejected. Assign one person to own the documentation, and include time for it in the schedule and the exhibit budget. Treat the handover package as a deliverable with a date, just like the software.
What a handover package typically contains
A plain overview
One or two pages describing what the exhibit is, what it is for, how visitors use it and how it is meant to behave. Include a simple diagram or photo of the setup. A reader should grasp the whole thing within ten minutes.
Equipment inventory
A list of every physical item: displays, computers or media players, speakers, sensors, cables, mounts, power supplies and any network equipment. For each item, note the make and model as printed on the device, where it was bought, when it was installed and any warranty details. Add where spares are stored. This inventory also supports later planning against technology obsolescence.
Software and versions
Record the operating system, the exhibit application, any supporting software and their version numbers, along with how the exhibit starts up and what happens after a power cut. Note any settings changed from defaults, such as disabled updates or screen sleep, and why.
Source files and content
Store the editable originals, not just the finished output. That means the project files for software, the original images and audio, the text in editable form and any scripts used to process content. Note where each lives, and keep a copy off the exhibit computer. Include records of rights and permissions for images and recordings, since a later team may need to know what can be reused. Metadata kept with the files, as described in the guidance on collection metadata, makes them much easier to find.
Access and accounts
List accounts, licenses and services the exhibit depends on, such as hosting, domain names, cloud storage or software subscriptions. Record who holds them. Passwords should not sit in a plain document; use the institution’s secure method for sharing credentials, and write down only where to find them and who can grant access.
Network and power details
Document how the exhibit connects to power and any network, including addresses, ports or firewall requirements if relevant. Planning notes for exhibit networks and exhibit cabling are useful to attach, along with labeled photographs of the wiring before it is hidden behind panels.
Operating instructions
A short guide for daily staff: how to turn the exhibit on and off, how to restart it, how to clean it and what to check each morning. Use plain language and numbered steps, with photos where they help. Include what visitors commonly do that causes problems.
Troubleshooting notes
A short table of known issues, likely causes and first things to try. Include who to contact when staff cannot solve it, and what information to have ready. If the exhibit supports remote monitoring, note how to use it.
Maintenance schedule
Link the records to the routine described in the maintenance plan: what is checked, how often, and by whom. Include replacement intervals if you know them.
Contacts and responsibilities
Name the roles responsible for content, technical support and the supplier relationship, and give current contact details. Roles last longer than individuals, so write the job title next to each name.
Evaluation and change history
Keep a record of testing results, known limitations and accessibility checks, along with a log of changes since opening. This helps explain why the exhibit behaves as it does, and informs any later remedial evaluation.
Make the handover a meeting, not just a folder
A folder of files is not the same as understanding. Hold a handover session with the people who will run the exhibit, ideally while the builders are still available. Walk through the startup, the shutdown, a simulated fault and a content update. Ask the receiving staff to perform the tasks themselves while the builders watch; gaps in the documentation usually show up quickly. Useful questions to ask are: what would you do if the screen went black, and where would you look for the original images?
This session also supports staff training, and it is worth noting who attended.
Keep it findable and current
Store the package somewhere the institution controls, such as a shared drive with backups, rather than on one person’s laptop. Use clear folder names and a short index file. Date every document, and decide who will update it when changes occur. A handover package that is never updated gradually becomes misleading, which can be worse than having none.
A simple test
Ask someone unfamiliar with the project to read the package and then restart the exhibit, change one text label and find the original source for one image. If they succeed without calling the builders, the documentation is probably adequate. If they get stuck, the places where they stalled show what to add.