10 Steps To Writing An RFP For DAM

Jens Lundgaard, Founder of DAM vendor Brandworkz, has recently published an article that aims to tackle a number of issues that can arise from the inherent limitations of form-based RFPs and the often intentionally ambiguous responses they garner from prospective DAM vendors.  In his post, entitled ‘How to write an RFP for a DAM and Web-to-Print system: A 10- step guide’, Jens kicks off with an imaginary scenario between client and vendor and a series of typical events that ultimately end in the customer’s dissatisfaction with an inflexible or unsuitable DAM solution, that on paper, appeared to tick all the right boxes.

“Vendor: Yes, we have received your 150-row spreadsheet with all of your team’s functional requirements. We will get cracking on that straight away. By the way, we have already had a first pass at it and the good news is that we can cover around 90% of your requirements.

Then three to six months later…

Client: Is that tech support? Yes hello, our agency has uploaded lots of large CMYK Photoshop PSD files with layers and transparency. But the previews are all wrong and the low-res downloads aren’t usable as the colours are off and the transparency is missing. We really need that fixed now as otherwise our creatives will get fed up with the system.

Client:  Hi again tech support, it’s me. We would like to change the names of the top navigation entries because many of our business users don’t understand where to find stuff, can we do that? No, why not? Surely that’s an easy thing to do, we can do that on our WordPress site in 5 minutes.”  [Read More]

Jens goes on to explain that it’s often the very nature of checkbox-style RFPs that is the root of the problem .  It’s not that vendors weren’t telling the truth when they completed the RFP, but rather that the format of the RFP only allowed limited ‘yes/no’ responses (or at best multiple choice), and many vendors presented with such an option might be tempted to err on the side of saying “yes, we can do that” due to the competitive nature of the DAM landscape.

This is not the first time the DAM RFP has been called into question.  In her recent article, Robin Parisse echoes Jen’s sentiments by concluding that the RFP model is ‘seriously broken’, yet duly notes that it’s only a small part of the whole procurement process, and by itself, is simply not capable of the ‘technical and functional deep dives’ into vendors and their solutions.  You wouldn’t recommend a restaurant based solely on its menu, but by actually eating there, soaking up the ambience and experiencing the service first hand.

“Considering the importance of continuous improvement and capabilities, it is crucial that the vendor and professional services team you select aligns with your company culture. This is a long­-term marriage. You don’t want to break­up and find yourself scrambling to find new vendors…My advice is to shorten the written RFP and spend more time with the Vendor’s engineers and subject matter experts delving into how their solution solves your workflows and use cases.”  [Read More]

Along similar lines, my co-contributor, Ralph Windsor, wrote an article for CMSWire back in 2013 where he recommends carrying out vendor demonstrations prior to the RFP stage.

Jen’s article goes on to list the ten items that should be included in an RFP:

1. Describe your most important scenarios
2. Functionality checklist
3. Provide vendors with representative file samples
4. Supply worst-case examples of artwork for Web-to-Publish templates
5. Describe scalability requirements and potential challenges in detail
6. Get vendor to demonstrate flexibility with potential future configurations
7. Investigate integration options and provide real-life scenarios
8. Give vendor a good overview of migration needs
9. Ensure that vendor has an adequate level of security in place
10. Don’t keep vendors too much at arm’s length from the DAM users

The essence of Jens’ advice is to not rely on a series of binary or multiple-choice responses, however comprehensive they might seem.  Instead, prospective DAM users should augment their RFP with real-world scenarios, providing as much information as possible about the kind of tasks that the DAM will be required to perform.  Where possible, a broad range of user-centric case studies should be collated, along with any potential workflow and usability issues that might result.  Prospective vendors should then be invited to describe how they might resolve them.  Those who are able to clearly elucidate how to apply their systems and technology to these problems (i.e. deliver a solution) should be favoured over those who simply want to list features and leave their users with the challenge of getting DAM technology to generate ROI.

The more opportunities you have to test drive a system, kick its tyres and stress-test it by throwing complex and  unconventional problems during the procurement process, the fewer surprises you may have to deal with later, after the contract has been signed.  Prospective DAM users should not be afraid of breaking a system: by preparing a list of complex test routes you can more easily highlight any latent faults, workarounds and shortcuts taken by the vendor that might be lurking under the hood.

Share this Article: