Kas Thomas of CMS Watch sat in on the Henry Stewart Digital Asset Management & Marketing Operations Symposium in New York, and noted this timely advice.
DAM isn’t a system; it’s a workflow.” Don’t think statically about a DAM system. It’s not some cryogenic tank that you dump bits into for longterm storage. There are processes associated with every asset in the system.
“Allow six months for initial research.” Don’t even think you’re going to initiate any kind of discussion with a DAM vendor within the first six months. You need to spend that time doing basic DAM research; identifying and talking to stakeholders; getting buy-in from sponsors; assessing your current situation with regard to assets, metadata, and IT resources; and so on. (“Take whatever time you’ve budgeted for initial research,” said a panel member in an earlier session, “and just triple it.”)
“Identify all of the different types of users you’ll have.” You need a taxonomy of users. Why? Because you can’t begin to know your requirements until you understand who all the actors are that might use your system, and in what capacity they are going to use it. (Note that more than one speaker emphasized the need to write “user narratives” instead of, or in addition to, formal system requirements.)
“Interview users of all the different types you’ve identified.” Develop personas. Capture them as user narratives.
“Metadata should contain information about the asset’s chain of custody back to the beginning.” For every asset, you want to be able to find out: Who created it? Who has owned it? Who owns it now?
“Granulate your metadata.” Most metadata isn’t fine-grained enough. You want to be able to run reports quickly and easily, without spending a lot of time parsing the metadata just to get at certain bits.
“Allow for the idea that you may need to restrict edit rights on metadata at the field level.” This is difficult to do with most systems. But the key intuition is, you don’t want someone who rightfully needs “write access” to one or two fields of the metadata to be able to overwrite all fields.
“Insist on owning any code produced by anybody who helped implement your system.” Ditto for any documentation associated with the project.