Receive
the Free CMSWire NewsletterWhen you are looking for advice on purchasing digital asset management systems, there is a lot of information about essential features and more technical elements, but information on how to manage the purchasing process is often harder to find.
Until relatively recently, my employer participated in a number of vendor evaluations as a prospective supplier. We also still continue to offer DAM consulting and integration services where evaluating potential vendors for clients is part of our remit.
In this article I will try to summarise some of the tips I have gathered from my own experiences. This article is by no means a comprehensive guide but it may offer some pointers you might find useful.
Use The Right Words
When preparing documentation to buy a DAM system, ensure your use terminology is consistent with market conventions. For example, if you say you want a "Media Asset Management" application, that is usually considered to have more of a video focus — "Brand Asset Management" implies more brand / marketing oriented assets.
A safer bet is to refer to the requirement using the canonical "Digital Asset Management" term. You still need to be clear in your briefing materials about the intended usage. Avoid fashioning your own terminology as this could confuse vendors and you may get unsuitable candidates responding.
Avoid the Kitchen Sink
DAM systems encourage end users to think about how they can re-use their assets and get more value from them. While that is a positive benefit, the side effect is that they then begin to contemplate all the other requirements they have involving assets in a DAM system.
When vendors meet buyers, they are eager to emphasise how flexible and advanced their products are by showing demonstrations and examples of all the different features. The scope of the requirement begins to expand, sucking even more stakeholders into the mix. This generates arguments and lengthy discussions about who or what should get priority.
You should avoid trying to implement a "kitchen sink" DAM system that tries to answer numerous different needs simultaneously and instead define clear boundaries between different groups of users with priority based on the highest potential ROI.
| Editor's Note: A longer report that goes into more detail on each of the stages of the DAM system evaluation and procurement process is available as a whitepaper on the DAM News website |
Decide the Order of Play
Where possible, arrange an initial vendor lead walk-through demonstration before anything else. Seeing the product and getting a good idea of its look and feel, metaphors employed etc., provides more information to your end users about whether it is going to work for them. If you have a candidate product that "ticks all the right boxes" but is difficult to use, then it probably won't — staff will abandon it and return to whatever worked for them in the past.
Doing a demo up-front lets you see what you're likely to get so you can discount any unsuitable options without much of anyone's time being wasted.
Review It On Your Kit
The other important requirement of any demonstration is to see it at your place of work on a typical PC.
If you are meeting the prospective DAM system suppliers in-person at your offices, provide the PC and internet connection. Viewing it off the sales guy's brand new laptop running the latest browser probably isn't how the candidate DAM will be used for real when it is deployed on end user PCs.
If the vendor is delivering a demo remotely there are limits to how you can assess the product within your environment. After a the initial demo, request a sandbox (a test edition). If your DAM is installed then a trial licence is another option. Test the product on a wide range of different environments.
Preparing Purchasing Documentation
Ideally the software procurement documentation should be structured in a pyramid formation where you get the "need to know" detail at the top and then you go down into more depth only with those candidates who look like they might be serious contenders.
The Dreaded RFP
I've heard these referred to as "Requests For Pain" or "Really Flipping Pointless" (with further variations on that one which I will leave to the reader's imagination). With a technical item like software, they are probably a necessary evil, but I have never found writing nor issuing responses to them to be a particularly satisfying experience.
Continue reading this article:
Email It
RSS
We take your privacy seriously