When 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.
If you employ third party consultants, there can be a tendency to write an exhaustive RFP document with hundreds of questions covering every detail (necessary or otherwise). This might be to try to justify their involvement in the process or inadequate briefing to allow them to be more concise. Everyone on the client-side will print out the numerous pages and nod approvingly at each other about how thorough it is -- then fail to bother to read it and check what questions are being asked and why.
When vendors receive the RFP documents, there will be audible groaning from the sales staff at the work involved as well as a realization that it might all be a complete waste of time and effort -- which also impacts their motivation to submit a response.
The more detailed the RFP is, the longer it will take you to review the responses satisfactorily. While it's good to check products out comprehensively, you need to be realistic about how much time you have available to read responses properly.
The Round Robin RFP
This is where multiple stakeholders are asked to independently write up all the features they think they will need. When these are issued without having been reviewed (which is most times) there are often repeated questions, all separated from each other by a page or two and phrased in a slightly different way but still requiring a unique response. If you want to use this multi-author "round robin" technique, someone needs to get the final document and read through it.
There are various techniques for carrying out quantitative vendor assessments which are popular with procurement departments because they believe they can take the emotive elements out of the evaluation and reduce it to a more scientific method. This involves the vendor completing a checklist and being asked to say whether they fully, partly or don't offer a given feature.
I don't think these work that well because they tend to favour the disingenuous vendors over their more honest counterparts. What often happens is that the former will say "yes" to everything and if challenged, they will offer an interpretation of the question that suits the current capabilities of their product. These questionnaires can be effective for straightforward procurement information, but they are flawed for getting to the detail of whether or not product x really supports feature y in the precise way you need it to.
A Screenshot Is Worth A Thousand Words
When preparing RFPs and bid documents, asking prospective suppliers to provide screenshots of a given feature can be useful. These are a lot more difficult to fudge than questionnaires. A vendor who definitely has what you require should be able to generate them easily and they can get through the RFP faster. You can also see how much their interpretation concurs with your expectations.
The Follow-Up Demos - Scripted Scenarios
Follow-up demo sessions are important to do in-depth inspections. It is better to give some example scenarios that show common tasks you want to achieve and also address any points you want explained from the earlier sessions. These should be scripted scenarios that model how you plan to use their product for real once deployed.
Customization & Professional Services
The cost of making thousands of staff alter their working practices might be expensive compared with customising the software instead. You need to identify a) whether customization is possible and b) what the professional services process is.
With Cloud/SaaS products, this can be complicated as the vendor needs to provide the feature for everyone on the same platform, but also find ways of enabling / disabling it as required.
Even with non-SaaS dedicated installations, the vendor might be less willing to provide a separate edition as the maintenance task becomes more demanding for them if they have to keep many different editions maintained and port bug fixes or features between them. Where they are prepared to do this, you need to assess the impact on any maintenance and support costs also as they usually increase with COTS (Customized Off The Shelf) products.
Timeframe & DAM Projects
When vendors get asked to quote timeframes, they will often quote the pure time required for their work in isolation. This is where the fabled "4-6 weeks" number often originates from -- and the "correct" period DAM system vendor sales reps get taught to say in DAM system sales school.
Can it really take 4-6 weeks? Yes -- and quite possibly even less. However, the main cause of delays with implementations for larger organizations is all the associated tasks like contracts, specifications and assembling all the decision makers to sign off. It's wise to take that into account rather than relying solely on numbers the vendor might give you.
The rationale for extended purchasing exercises is to ensure that your organization gets best value. While you can criticize aspects of the process, you can't dispute the intent behind it. When purchasing DAM software, it is essential to be fully conscious of what you are doing and critically examine each stage of the process so you can be confident that you did everything possible to identify the most suitable product for your organization.
Image courtesy of Fer Gregory (Shutterstock)
Editor's Note: To read more by Ralph and his co-author Naresh Sarwan, check out The Digital Asset Management Value Chain