Procurement and Choosing Outside Suppliers

When outside suppliers make sense

Few institutions can design, build and install a digital exhibit entirely in-house. They may lack developers, fabrication skills or time. Outside suppliers can fill those gaps, whether they are design studios, software developers, audiovisual integrators, fabricators or hardware resellers. The decision is not whether outsourcing is good or bad, but which parts of the work are best bought and which are best kept internal.

This article describes general principles. Rules for public bodies and funded projects differ by country and organization, so check your institution’s own policies and, where needed, seek advice from your procurement or legal staff. Nothing here is legal advice.

Know what you are buying

Before approaching anyone, be clear about what you need. A well-written exhibit brief is the foundation. It tells suppliers the audience, goals, constraints and timeline, and it helps you judge whether their responses fit.

Decide how you will divide the work. Options include:

• one supplier for the whole project, which simplifies coordination but concentrates risk;
• separate suppliers for design, software and hardware, which allows specialist choices but needs more management by your team;
• a mix, with in-house content and outside technical work.

Write requirements in general terms

Requirements describe what the exhibit must do and be, not exactly how to build it. Over-specifying solutions can exclude good ideas; under-specifying invites proposals you cannot compare. A useful document often includes:

• Background and purpose, drawn from the brief.
• Functional needs: what visitors should be able to do, the number of users, the languages, and the expected session length.
• Quality needs: accessibility commitments, reliability expectations (for example, running all opening hours each day) and any requirement to meet published guidelines in general terms.
• Constraints: space, power, network, conservation limits, timeline and budget range.
• Deliverables: software, source files, documentation, training, installation and testing.
• Support after opening: the period of support you expect, response times in general terms and who handles faults.
• Ownership and rights: who owns the code, designs and content, and what you may reuse.
• Process: how and when proposals are due, how questions are handled and how decisions will be made.

Distinguish “must have” from “nice to have”, so suppliers know where flexibility exists.

Sharing a budget range

Some institutions hide their budget, hoping to get lower prices. This often produces proposals that are not comparable, since each supplier guesses a different scale. Sharing a range or ceiling usually leads to proposals designed for what you can afford. Many teams find that is more useful than a surprise at the end.

Inviting and comparing proposals

Ask each supplier to respond to the same questions in a similar structure. That makes comparison fairer. Typical items to request are:

1. Their understanding of the project and the approach they propose.
2. Relevant past work, with the ability to speak to a reference.
3. The team, with roles and how much time each will give.
4. A schedule with milestones and the points where your input is needed.
5. A price broken into parts rather than a single figure, so you can see what is included.
6. How they handle testing with visitors, accessibility and changes during the project.
7. What support, warranties and documentation come after launch.
8. Assumptions and exclusions, which show what the price does not cover.

Scoring in a fair way

A simple scoring grid keeps discussion focused. List your criteria, such as understanding of the brief, relevant experience, quality of approach, realism of schedule, value for cost and support after launch, and agree their relative weights before opening the proposals. Have several people score independently, then discuss differences. Avoid letting price alone decide: the lowest bid may leave out items or rely on optimistic assumptions. Equally, the highest price is not proof of quality.

Check references by asking previous clients about reliability, communication and how problems were handled. Visiting a past installation, if practical, is more informative than a brochure.

Questions that reveal risk

• Who will actually do the work, and what happens if they are unavailable?
• What parts of the solution depend on third-party products or subscriptions?
• What will we receive at the end: source files, editable content, documentation?
• What happens if the supplier closes or stops supporting the product?
• How will you handle late content on our side? This links to the broader issue of project risk.
• How does the proposal address technology obsolescence?

Contracts and agreements

Put the agreed scope, schedule, payments, ownership and support terms in writing. Tie payments to milestones that you can verify, such as an approved design or a successful test on site. Include how changes are requested and priced. Specify what must be handed over, including the items listed under documentation and handover. Have your institution’s contracts or legal staff review the agreement.

Managing the relationship

Choosing a supplier is the beginning, not the end. Assign one point of contact on your side, set regular check-ins, and give timely feedback and approvals, since delays on your side also cause schedule slips. Share early prototypes with real visitors and staff and respond to what they show. Keep the exhibit budget and project schedule visible to both parties.

Keeping it proportionate

A small purchase does not need a heavy process. For a modest project, a clear one-page request, two or three quotes and a reference call may be enough. For a large installation, a more formal process is usually justified. Match the effort to the size and risk of the purchase, and keep a written record of why you chose as you did.