7 bodies in the DAM graveyard

In 9 shocks waiting for DAM rookies one of the shocks I listed was what can emerge especially during a migration. I likened it to going digging in an unmarked graveyard. But what was the cause of death? Negligence? Murder? Avada Kedavra? Why should there even be any bodies waiting for us when we dig into DAM? Surely a DAM system requires assets to meet certain standards to even get on the system. Yes and no. Let’s dig through the grisly remains.

A graveyard from HarryPotterFandom

1. Ancient assets / if the system we’re migrating to is the company’s third DAM system, then that inevitably means that the company will retain assets that were uploaded to the first system. That means that the metadata of those assets is unlikely to align with DAM v3 or even v2 standards. The result can be that you can have swathes of missing metadata which may not exist or be discoverable: there’s no reason to believe that anyone would have captured data that would only be considered mandatory 10 years or more later. This means digging to try fill in the blanks, but the probability is that it’s going to be difficut to source a lot of it in time for migration. That difficulty will be compounded by each passing year as people leave, depleting company knowledge, and by the age of the assets which can result in metadata issues being compounded over time. Addressing the issue for a migration is painful, but we can’t get bogged down here. As much as we may hate the idea, and we should, we’ll likely have to leave fields blank or insert variations of ‘no data available’. There’s so much to do in a migration and the wheels have to keep turning. Save these assets in collections or galleries as you find them and return to the issue post-migration if it can’t resolved now. If the missing data is particularly egregious for regulatory or legal reasons, however, then archive them and consult with your manager or legal on the best approach here.

2. Rights / yes, rights data can be thought of as part of 1. but it’s worth distinguishing it because there can be financial penalties for using assets beyond their license terms. These assets can often be relatively easy to isolate because metadata may have been embedded in the asset or the filename may reveal the name of the company it was licensed from. If the original rights weren’t captured in DAM v2 or v1, then users will inevitably treat such assets as ones they can use without restriction, so you need to nail this down. If you know that licensed images can only ever be licensed by one department, then you can turn to them. However, if multiple departments can do this or if your company has content created by external creative agencies, then this becomes more difficult to resolve. If in doubt, archive the assets while you search for more information. It’s less painful to release an asset from archive than to pay a financial penalty for using it in an unlicensed way.

3. System changes / which assets were uploaded, their format, the level of metadata captured etc. can all be artefacts of the technical or practical limitations of DAM v1 which no longer exists. Such limitations can create ugly workarounds to processes which are retained in the present. The more these workarounds were created to resolve edge cases, the more disarticulated these bodies will be because the situation arises so infrequently that it never attracted real analysis. This is amplified if the process is undocumented because it could have become critical in some situations, but for reasons no-one understands. This then becomes a change management issue.

4. Process change / as systems change, processes also change. Worse, any process analysis done will inevitably be incomplete because users frequently don’t understand how they work or why they follow certain processes. They may also gloss over certain steps or minimise its impact just because they want to get out of speaking to you. Never underestimate the capability of users to weasel in the face of change. They may complain about the amount of consultation over process now and complain that they weren’t consulted later. They may complain about DAM v2, but then complain even more about v3 when it launches even though it’s an objectively better system. Again, this is a change management point because people can get used to anything, no matter how horrible it is, so they can certainly get used to a bad DAM or process.

5. Poor training / if users weren’t trained on DAM v2, then it’s likely that they will have a poor understanding of the system and DAM in general. They won’t understand or care about capturing metadata and there’s no quick way to resolve this. You have to advocate now not merely for your system, but for the best standards in DAM and train people to those standards. If you want to know why users may not have been trained…

6. Poor or no staffing for the DAM / companies frequently go through boom and bust phases of inventment in DAM. At worst, the system wasn’t maintained at all. At best, it was maintained by people who don’t understand or really care about DAM. This group then becomes the de-facto source of knowledge about DAM in the company which means that even if users are trained, it’s going to be by people who don’t truly understand the system or how to manage assets in it. This also becomes a change management issue because while that department may not have cared about DAM v2 or v1, if their capability to gatekeep access is removed for DAM v3 because you’ve been hired, they may still act out because it’s a loss of power. This kind of politics is easier to resolve if you have high levels of backing in the company. If you don’t, then your authority will be limited and that department could be a continual thorn in your side. If you can work with that department to make their experience of using the DAM better then, if they’re not weasels, you may find that they gradually admit that they’re relieved things have got better. They may even come to appreciate not having to bear the weight of the DAM now so that they can focus on their real jobs.

7. Sub-optimal decisions / in a migration you may come under pressure from the implementors to make snap decisions. Quick! Make a decision! Unblock us! You have until EOD tomorrow! Don’t you understand how important this is? This kind of pressure induces anxiety and fear, neither of which are conducive to good decision making, especially on a Friday afternoon when everyone’s drained. And if that’s happening now, you can be sure it happened with previous migrations. Your responsibility now to to not make the same mistakes as your predecessors: hold the line! Implementors are not going to be the ones who feel any negative impacts from poor decisions. You’ll be answerable for the assets that didn’t get migrated or lost metadata.

If there’s anything that can be said to bind all of these points together into one it’s having a high personal standard for what DAM is and should be in your company. Yes, you’ll inevitably have to compromise or return to certain topics later when you have more time, especially if the topic is complex, but you should always be shooting for the moon. It’s now up to you to rearticulate the bodies and reinter them.

But don't forget that you’re not going to be able to move an entire company or transform its culture by yourself. DAM is hard to understand and there may come a point where if you can't move enough people in your company, then you may have to consider moving on. There can be too much organisational authority and stasis lined up against you. Learn what you can, but then get your CV and LinkedIn profile cleaned up, and move on.

What bodies have you been unfortunate enough to dig up in a migration and how did you respond? Migrations are painful at best, excruciating at worst, so let’s take this opportunity to share what we’ve learned.

Courtesy of Jess