An “ingest sheet” (a single document that contains much of the key information on a project) is a great way to deliver key metadata fields to the people who will be performing the ingest and tagging in the DAM system.

ingest sheets

• An ingest sheet might be a stand-alone file that travels with a project while it’s in production or a form utilized within project management systems (such as Monday or Workfront).
• The key: data can be collected along the way, so you and your team don’t have to remember or track information down weeks or months after production wrapped.

Very often, we (DAM managers and librarians), want things to be a certain way because we think it makes more sense, organizationally, taxonomically, or just plain old logically. But… who cares what we think! No matter how (cough) “right” we might be, the users and stakeholders of a system must guide the broad strokes of its organization. For example, we might expect specific terms to be used in a picklist field, but they’ll be of little use if those terms aren’t in the company’s vernacular. It’s our job to find a balance between “best practices” and the customized reality of our client’s needs.

Your DAM shouldn’t function like a junk drawer. You might be tempted to save everything created as part of the project, but you’re really just using up storage, and probably creating work for yourself and your team, down the road. Instead, as you wrap a project, consider: are there assets, drafts, or grading that don’t need to be kept?

Standard Assets

• If you have standard assets that go into almost every project (e.g., logos, brand guides), these could be collected in their own section in the DAM, and removed from new project folders as they get ingested.
  
  
• Similarly, suppose you have a project that pulls from content already in the DAM (e.g., interviews or excellent evergreen b-roll). Instead of duplicating those files over and over again – in storage and in search results (a nightmare of version control) – many DAMs allow you to link older records to newer jobs. You free up space but still know exactly where all your source footage lives.

The DAM is meant to save time and effort for a wide range of users – not just a few “keyholders.” If something isn’t working well for someone, anyone, it’s important to address it. It may be solved with a simple training exercise, or an adjustment to a workflow, or it may require a more extensive review and strategy overhaul.

(At Aldis, we understand that what we configure the first time might not be the final version. We ask our clients to work with their system for a few months and make notes. Then we have feedback sessions so we can identify and implement solutions in a new version.)

REGULAR CHECK-INS WITH USERS

It’s important DAM users know whom and how to ask for help; on top of that, on a regular basis, DAM managers should reach out to users and ask:

• Are you able to find what you need—perhaps new fields or terms might be helpful?
  
  
• Are you able to navigate the system—maybe documentation, guides, or FAQs need to be created, updated, and made readily accessible.

What’s the difference between a metadata project and a metadata program?

METADATA PROJECT

A ‘metadata project’ is a short-term task with a finite amount of work or end-goal, such as a migration from one system to another, looping back to fix something, or tagging newly-created fields on older assets.

METADATA Program

The ‘metadata program,’ however, is on-going. It’s part of keeping your DAM healthy and includes regular check-ins with your business partners and stakeholders. Tasks here might be checking controlled vocabularies and picklists for typos or duplication, adapting to a change in company terminology, and assessing whether any useful metadata fields are missing or now feel redundant. As long as your DAM is active, the metadata program is, too.