RFP Advice Roundup from the Web

Here’s a decent list of articles and templates from around the web here in one handy spot!

How to Write an RFP for a Digital Asset Management System: A 10-Step Guide

How to write an RFP for a DAM and Web-to-Print system: A 10- step guide

7 Tips to Improve Your Marketing Technology ‘Request For Proposals’ (RFP)

Gartner’s Top 19 Enterprise Digital Asset Management Solutions

THE DIGITAL ASSET MANAGEMENT RFP CONUNDRUM

Digital Asset Management RFP Questions

A $499 “Report Package” called Develop Your Own In-House DAM Vendor Selection Expertise

Develop Your Own In-House DAM Vendor Selection Expertise

This is an interesting one, not sure what their angle is, yet: Smartsheet’s

Expert Advice on Choosing the Digital Asset Management System That’s Right for Your Company

Vendor templates:

Widen’s Considerations and questions for your DAM request for proposal
and
Understanding RFI’s and RFP’s:

Understanding RFI’s and RFP’s

Bynder’s Download the free Digital Asset Management RFP Template (Download w/ Registration)

MediaBeacon’s Digital Asset Management RFP Template

NorthPlain’s RFP Template for Digital Asset Management

RFP Template for Digital Asset Management

THE Digital Asset

In my previous post “It’s Basic, Man” – I pointed out that often exciting and shiny new features try to steal the show. Actually, it’s usually the case that the department of smoke and mirrors, aka Sales and Marketing, that needs and easy conversation starter.

I’ve seen very few people in DAM sales and marketing that actually know the basic requirements and capabilities up to the point that they can actually use those to differentiate their product from any shiny new contestant.

What should be basic in an Enterprise DAM then?

Basic – let’s first agree on what a Digital Asset Management actually manages.
Some systems start with a file being the nucleus of an asset. File type determines the asset type, metadata gets extracted – searchable, sprinkle some access control over it – done!

I would consider these systems file management systems – as they are file centric and will fail one way or the other when workflows and integrations start to become file-less.
Even the job of managing slides, videos or non-digitizable items can’t be handled adequately.

I understand the file centric approach is historically grown. Start with a simple job: manage digital media files – more files, more functions. In the context of a sustainable, flexible and integrated enterprise DAM, I consider a digital asset a combination of six aspects in a defined state at a point in time:

  • Metadata
  • Paradata
  • Access Control Properties
  • Relations
  • Bytes (one or many files)
  • Domain Specific Representations of associated Bytes (e.g. derivatives)

Not every asset will have all six facets. Not every asset will have history of different versions.

None of these six facets is THE digital asset – only the combination of at least two brings the asset into life, while it gets enriched by adding more and more facets or changing any of the facets thus creating different newer versions.

To be continued…

Kai Strieder

It’s Basic, Man!

When the time comes to select a new product – either to replace your current solution or augment your landscape to a new level – features get uttermost of attention. Every vendor knows that of course – and to dress up the bride just common sense before you go on the pitch.

And, of course, every vendor communicates the unique and revolutionary new features of their product as bold, loud and aggressively as possible… .hat’s marketing 101. In product development, this also follows a specific pattern which is described in the Kano Model.

Kano knows three classes of product features: excitement, performance and basic.

Excitement features are usually perceived as the innovation differentiator – which is not a correct attribution. As the name indicates, these features create excitement but might not be directly applicable to a practical problem domain or business challenge. However, they are shiny, new, exciting, super cool, and nobody else has them.

See, that’s the point. Some features are so cool, that nobody else will ever have them – and that’s not a problem of innovation, code quality or a “blockchain based cloud AI in the augmented reality deep learning quantum computer.”

Of course, the 2% of excitement features mature, prove useful and applicable, and will move to performance features. Performance features aren’t exciting any more – they are not unique. But they can be either fast or cheap, or have a better user interface – they differentiate one product from the other. Both have the capability – but on the same level. Excitement features are not on your requirements list, but a vendor answering your RFP will put them there.

Performance features are more likely to be on your requirements list, and that’s where you rate it with points.

What doesn’t get enough attention are basic features. It is often assumed that every solution in a specific domain has them – that’s why a product is in a specific domain. See, for example, a new phone – nobody would put the requirement “can it actually dial a phone number and connect me to any other user of a public phone system?” which may call to mind the unreliability of the first voice-over-ip phones. There’s a disclaimer stating that you might not use them for emergency calls, right? But that’s pretty basic…

In a product space, new vendors tend to give basic features or requirements less attention, and concentrate on excitement and performance features. Mature vendors are in a slightly better position. Basic features are their legacy, performance features have once been excitement features and excitement features live in the roadmap. When selecting a product, make sure that you put your shortlisted potential solution providers to a test on basic domain specific capabilities. I will continue with a drill down on basic domain specific capability sets for enterprise class DAM systems in the next days and weeks – stay tuned.

Kai Strieder

Why DAM Implementation and Run is Not a Project

John Horodyski, an Executive with Optimity Advisors, has written a thoughtful article for CMSWire on why DAM implementation and run is an ongoing process, not a project. He states cogently:

One of the most common questions I receive is how to manage a digital asset management system. This details everything from how to create the business case, to securing executive buy-in and financial support, to building the right team, deployment, roadmap and more. There is much to do, and it takes time. Many foundational layers will clamor for your attention as you prepare the roadmap of work.

More importantly, most of these structures need to be reviewed and discussed well before any technology has been purchased, let alone considered.

Technology should never lead the decision-making process for DAM demands — the business sets the foundation for the strategy first. Technology is incredibly important, and the vendor review and selection process are a critical step in all this, but that step must follow the business requirements and digital strategy. You need to know what you want to do: the purpose.

Once you know what you want to do, then everything else is spent working towards that goal because you know what you want to achieve. Never lose sight of that goal.

Well worth reading, at: https://www.cmswire.com/digital-asset-management/how-do-you-manage-your-dam/

“Navigating the DAM Divide” by Real Story Group

Way back on Oct. 29, Real Story Group, a vendor evaluations company, published an interesting article and graphic on the various DAM landscape forms, dividing vendors up into four categories;

Complex, Legacy Complex, Mid-Range and Simpler.

Real Story Group Vendor Logo Landscape

It is a useful framework for input on which DAM vendors might be most suitable for consideration in your initial DAM discovery process for your enterprise.  More at:

https://www.realstorygroup.com/Blog/3287-Navigating-the-DAM-Divide