Why schedules slip
Most exhibit schedules begin with a fixed point: an opening date announced for a season, an anniversary or a funding deadline. Work is then squeezed backward from that date. If the squeeze ignores how long tasks really take, the project runs into trouble in the final weeks, and testing and polish are the first things sacrificed.
A realistic schedule starts from the tasks, estimates how long each takes, notes what depends on what, and only then compares the result with the desired opening date. If they do not match, it is better to know early, while scope or date can still be changed.
The main phases and their order
Phases overlap in practice, but their order matters.
- Discovery and brief. Agree the purpose, audience, goals and limits. This stage benefits from front end evaluation with likely visitors.
- Design. Develop concepts, flows and layouts, and test cheap versions such as paper prototypes. Decide the hardware approach so orders can be placed.
- Content production. Research, write, photograph, record, translate and clear rights. This usually runs alongside design and into the build.
- Build. Develop the software, fabricate enclosures and set up hardware offsite where possible.
- Integration and installation. Bring software, hardware and furniture together in the gallery.
- Testing and fixes. Test with staff and visitors, correct problems and check accessibility.
- Documentation, training and launch. Prepare records, train staff and open.
- Post-opening review. Observe, fix issues and learn.
Where delays tend to arise
- Content. Late approvals, rights questions and translation often hold up everything that depends on final text and media.
- Approvals. Waiting for sign-offs from busy people. Unclear decision paths make this worse.
- Hardware lead times. Equipment may be backordered or custom-built. Ordering late is a common cause of last-minute stress.
- Site readiness. Building works, power and network connections may not be ready when the installers arrive.
- Testing discovered late. Problems found only after installation are more expensive and slower to fix.
- Changes in scope. Added features and revised content push dates back.
- People’s availability. Holidays, other projects and staff turnover affect small teams in particular.
The project risk process described elsewhere is a good companion to the schedule, since each of these delays is a risk that can be watched.
Estimating realistically
Some suggestions to make estimates more reliable:
- Break tasks down. “Build the interface” is too vague. “Build the home screen, the object detail view and the language menu” is easier to estimate.
- Ask the people who will do the work. Estimates by someone not doing the task tend to be optimistic.
- Add review time. Every deliverable that needs approval needs time for feedback and for fixing that feedback.
- Remember that people work on more than one thing. A part-time contributor delivers fewer hours than the calendar suggests.
- Use past projects. If your institution has built exhibits before, compare their planned and actual durations.
A hypothetical example
The following is invented to illustrate the arithmetic, not as a recommended duration. Suppose a team plans a small touch exhibit with the following sequential blocks:
| Block | Weeks |
|---|---|
| Discovery and brief | 4 |
| Design and early testing | 8 |
| Build | 12 |
| Installation | 3 |
| Testing and fixes | 5 |
| Buffer | 4 |
| Total | 36 |
Check: 4 + 8 + 12 + 3 + 5 + 4 = 36 weeks.
Content production is assumed to run in parallel across the design and build blocks, but it has its own deadline, set a few weeks before the build ends. If the content arrives three weeks late, that delay might be absorbed by the 4-week buffer. If it arrives six weeks late, the buffer is exhausted and the opening date moves, unless scope is cut. Seeing this in advance allows the team to decide what to do rather than react.
If a team wanted a 28-week schedule for the same work, it would need to remove 8 weeks (36 minus 28). That could mean dropping the buffer (4 weeks) and compressing testing, which carries real risk. The example shows why working through the numbers before promising a date is useful.
Use milestones and dependencies
Mark key milestones such as brief approved, design approved, content locked, hardware delivered, software ready for site and testing complete. For each, note what must be finished first. Content lock is especially valuable: after that date, only critical corrections are accepted, which protects the build.
Show dependencies visibly, in a simple chart or list. The longest chain of dependent tasks determines the earliest finish, so watch that chain closely.
Build in buffer, and protect it
A buffer is time deliberately left unassigned. Put some at the end, and consider small ones after major phases. Protect it by not treating it as spare time for extras. Share with stakeholders that the buffer exists, so they understand why the schedule looks cautious.
Plan the end as carefully as the start
Final stages are often squeezed. Leave real time for documentation and handover, for staff training and for opening-day checks. Plan a soft launch or preview period when possible, so staff and a small number of visitors can reveal problems before a public event. After opening, schedule a period for fixes and for remedial evaluation of anything that does not work as expected.
Keep the schedule alive
A schedule is a living tool. Update it at least every few weeks, record actual dates against planned ones, and hold a short review whenever a milestone is missed. Be honest with stakeholders about slippage. Telling people early that a date is at risk gives them time to adjust, which is nearly always better than a surprise.