Four Tips for Smoother Digital Asset Management Implementations

This feature article was written by Ralph Windsor, Editor of DAM News and Project Director for DAM Consultants, Daydream.

One of the less widely understood realities of Digital Asset Management implementations is that at least half of the factors that decide whether or not the initiative succeeds or fails does not relate to the product, but the planning (or rather the lack of it) carried out by the end user.  This is not to say that a poor choice of DAM system does not impact the ROI that can be obtained, but having been involved in well over 100 DAM implementations, most of the biggest challenges stemmed from organisational, communication or people-related issues rather than technical ones.

In this article, I present a few tips those who are tasked with implementing DAM can use to help guide their own project planning activities.

1. Start planning implementation well before you begin looking at product

Perhaps the most common mistake made by end-users with DAM implementations is starting the process by contacting a bunch of vendors and asking for product demos. This is not an ideal place to begin because you need to have a good idea of your requirements before you can accurately assess whether a given product is suitable for you or not.

There are some good reasons why DAM implementation ends up being so product-centric.  Partly this is because end-users can feel better about themselves without actually having to do very much actual work to progress a project.  The act of looking at product demos (if done without adequate prior planning) can end up being a passive ‘window shopping’ exercise.  The other reason is because the sell-side of the market is so technology and product-focussed, this is despite the fact that it is widely acknowledged that people are the most important element of DAM initiatives.

The other reason is because vendors spend a sizeable amount of money on content marketing initiatives, nearly all of which have some exhortation for prospective end-users to ‘book a demo’ etc.  You can’t blame them for doing this as their priority is selling their application and any associated supporting services, but you can blame yourself for allowing them to set the agenda when it should be driven by you and your stakeholders.  While looking at product can help prompt end-users to think more clearly about requirements, all of this activity should follow later when you have a clearer idea about what you want to achieve.

2. Acknowledge that others in your organisation will have travelled down this path before you

Nearly all clients I work with have already undertaken a DAM initiative before, although in quite a few cases a bit of investigation was required before that fact came to light.  In some scenarios the previous initiative might not have been called ‘Digital Asset Management’ and maybe there were metadata-only repositories of physical assets, but essentially the application was very much like a DAM system.  The same core problems have existed for decades (arguably centuries): the need to find something specific, organise collections of materials, view who has requested what and when etc.  DAM is not new, only your realisation that you require it.

Even if you think you are the first person to contemplate DAM in your organisation, the chances are that you are not.  The implication is that some other people (who may or may not still be your colleagues) have had to make many of the same decisions before.  That experience and knowledge represents an asset which has a financial value in terms of time not wasted finding out the same information or making the same set of mistakes multiple times.

This point has some relationship with the previous one.  It is in the interests of sell-side operators like consultants and vendors for you to not focus too much on what DAM-related activity has already taken place because it makes their job harder.  In the case of product, you have real-life case studies of what worked (and did not) as well as potential lists of features which a new vendor may lack, not to mention potential data migration challenges which could complicate implementation.  Similarly, you may not need as much consulting assistance as you think if there are earlier (or co-existing) DAM implementations.  There is likely to be internal expertise which you can draw upon to help with your own initiative.

The sell-side of the DAM industry is not as big as is frequently claimed, nor believes itself to be and depends on a considerable amount of cost duplication by end-users just to survive.  Somehow, DAM vendors and consultants will find a way to sustain themselves, but you don’t need to assist them in that endeavour.  Carry out some investigation into who may have carried out the kind of DAM-related activities you are interested in and whether there are any lessons you can learn from what they did (or did not) do.

3. Think about your entire digital asset supply chain

In very simplified terms, your digital asset supply chain is where your digital assets are coming from and going to.  It is the process by which value gets added to raw digital materials to transform them into digital assets which are then distributed down various channels and on to their ultimate destination(s).

Thinking about digital assets in supply chain terms is useful because not only is it a concept which many business managers are familiar with but it also encourages DAM end-users to think more clearly about the overall context of their DAM and how it will integrate with other technologies that the business may use.

When I carry out consulting exercises with clients, more or less the first thing we will do is to define their current and ideal digital asset supply chain.  This enables everyone to see what the limitations of the current approach are and how they should be optimised.  One point that often isn’t widely understood is that all organisations already have a digital asset supply chain, even if they do not have a DAM (which as explained in the previous point is fairly unlikely these days).  If you have ever had to find a digital file and send it to someone, you already have a digital asset supply chain.  The question is whether or not it is as efficient as it could be.

With a better grasp of what you want your ideal digital asset supply chain to look like, it becomes that much easier to write a brief describing the key requirements for any software products you plan to purchase to help automate your digital asset operations.

4. Define metadata schema and any taxonomies in-advance

This question of the order in which you define metadata schemas and taxonomies is one that quite frequently comes up in on-line discussions and at conferences etc.  In particular the issue relates to whether or not you do this before choosing a product.  I come down firmly in the ‘before’ camp.  If you don’t have any idea of what your metadata schema is and how you will need to manage your taxonomies, it is much more complex to assess whether a given product will be suitable for you or not.

Marketers, in particular, seem to find this subject quite a dry one and are not keen to dwell a lot on it, mainly because information science and information architecture tend not to be subjects they know (or care) a great deal about.  I can understand this (and it should be noted that some do indeed possess expertise and/or a willingness to learn about these topics) but in not acknowledging their significance, they potentially expose themselves to the risk of selecting unsuitable systems.

I have reviewed failed DAM implementations where product got bought based on some quite attractive interface design (or ‘user experience’ as it might be called).  It often transpires that the chosen platform lacked some essential metadata management functionality and very complex workarounds had to be developed to support it, which in-turn led to the solution not being fully adopted (despite looking very nice).  In many ways, this is the same folly that IT/technical personnel get into when product decisions are made based on massive ‘must have’ feature lists.  The buyers prefer to remain within their comfort zone and to stay away from topics that they don’t fully understand – even though to ignore them reduces the chances of their DAM initiative being successful.

Drawing up metadata schemas in advance forces all stakeholders to think quite carefully about what information they need to represent in digital asset records for their DAM to be useful to the business. In addition, when it does come to choosing DAMs, it is much easier to develop solution scenarios, briefs for proof of concept demos etc.  Rather than generic metadata management tools based on data the vendor has provided, devising a schema, up-front allows end-users to get a better idea of how a given system will behave when used for the management of their own digital assets.

Conclusion

Perhaps the key recommendation is the first one.  It is essential to realise that successful DAM implementations are about far more than just selecting products.  End users that obsess over finding ‘the best DAM’ are more likely to be disappointed with their DAM ROI performance than those who engage with topics like metadata, digital asset supply chains, adoption and governance.

The above are far from the only recommended techniques for operating a smooth running DAM initiative.  I plan to follow up with further articles that cover some of the other points I have not yet discussed.

Share this Article:

Leave a Reply

Your email address will not be published. Required fields are marked *