A DAM Vendor Selection Project,
Part 1: Where not to begin


I recently had the good fortune to lead a great consulting project, and since I’m currently between projects I decided to share what I learned during this last one. As the title notes, the project scope was straightforward - recommend the best DAM vendor for the client.

The client was the internal marketing and communications department for a mid-sized international manufacturer. A few key details about the client: the marketing department is decentralized across several regions, their marketing processes are flexible (sometimes to a fault) yet lack consistency, there is very little existing technology in place, and finally the relationship between marketing and IT is good, but at arms length.

Another important detail, the project schedule was 30 days from ink on paper to my DAM vendor recommendation. I originally balked at compressed timeline, but then decided to use it to the projects advantage. It gave every meeting, email, and document urgency - something that is typically lacking when you’re the external consultant.

The first document the client shared with me was a list of requirements for the DAM. The list was not the result of a months-long IT project, nor a quick cut/paste from a vendors website. The list of requirements had been collaboratively gathered by the client lead (a smart creative operations leader with some systems experience) and was actually a good place to start. But I didn’t start there.

As Tony Byrne and Jarrod Gingras point out in The right Way to Select Technology , I started with several meetings to learn the details about how the marketing operation really works. I have supported marketing and creative operations teams my whole career, so I prepared to lead the discussions. I included as many participants as plausible for a conference call (the entire project was remote), and we moved through the each of their processes from start to finish. Two key points on the calls: first I try to be as efficient as possible without leading the answer or making assumptions, and second I was keen to understand the exceptions.

From these discussions the team and I distilled a group of Business Scenarios that I could share with the prospective vendors. Each scenario included details such as user roles, relevant data or assets, and how each scenario related to an individual marketing tasks and the overall workflow. At this point I returned to the original list of requirements, expanded these to cover gaps and then mapped each requirement to a corresponding Business Scenario.

Now you may think we’re finally ready to begin vetting vendors, but I lead the team through one additional exercise where we weight each requirement according to its impact on operational efficiency, ease of use, and support of change. By adding this to the grid the client and I are able to look at each vendors product by different axis or lenses – not just the final score.

That was the final step in developing our Vetting Grid, and in the next post I’ll share how I developed a short list of vendors, and used my Vetting Grid to make sense of their offerings.​