Another DAM Blog

Blog about Digital Asset Management


Leave a comment

What do you know about your integrator?

Recently, some people asked me to look into software integrators because they were having issues with their present one. Sadly, this is far too common. A client saw the integrator at a conference. They had a good relationship with their preferred vendor. Integration and implementation of a solution like Digital Asset Management (DAM) was not the clients’ core competency. Why not leave it up to experts to do this work? Hear this story before?

The integrator said they were experts in the integration and implementation for this specific DAM system. They would not lie for the business, would they? Salespeople lie? Misrepresentation? Say it ain’t true.  Hear this one before?

Turns out the “experts” in question had not completed a single implementation nor integration with this DAM system. Ever. Guinea pig client number one getting billed for the integrator to learn about that DAM system on the client’s dime. Sadly, the client learned this after the most basic of all DAM implementations was running late. A project running late is not a new story for most people either, but remember to ask why.

A DAM is a DAM is a DAM, right? Wrong. The DAM concepts are the same. The DAM systems are different. There are many subtle difference in how different DAM systems are architected, how they handle assets with  metadata and how they integrate with other systems. Or not.

Here is what you need to look for in a DAM integrator:

  • How many solutions have they completed for other clients? With these systems? Be specific.
  • What kind of assets did they work with? Does that match the asset types you work with? DAM is not just about photography.
  • How did they handle use cases for their client?  What about metadata? workflow? Rights and permissions? Whose eyes are glazing over now?
  • Is there an SDK along with a clear set of updated documentation provided by the vendor for the integrator(s) in order to work with their tool? Is there a certification process by the DAM vendor for integrators? Are the integrators certified for this solution or are they partners with vendors? Or do we need to reverse engineer a solution to figure out how it works?
  • Can you see real case studies of real organizations with real people’s names stating satisfaction with that integrator and vendor combination? Why is that page blank on their website? If there isn’t anything posted, you might know why. “We have not had time to post it yet” is a very poor excuse for the often more truthful “we do not have anything to post yet.” Care to guess why?
  • If this is too much for you to handle, hire a DAM consultant that is truly independent of all vendors and integrators. Not one that just recommends the same one or two vendors each time. Those are the ones that often do the “recommendation” for a nice, fat hidden commission from the vendor and/or integrator. Then, they collect from the client as well. Impartiality is not part of the available vocabulary when it needs to be.
  • Word of mouth by the user community. Anyone heard of them?
  • Just because the vendor recommends an integrator or they hang out with the vendor means…nothing. Someone is expecting a check someday though.
  • Do the Project Managers have a clue? Can they keep the project on budget, on schedule and within specifications in a phased approach?
  • Will you have weekly meetings with the parties to discuss clarifications,  decisions, expectations, issues and progress? This is called staying informed. Are you?

If you need vendor neutral assistance or advice on integrators with Digital Asset Management, let us know.

What do you know about your integrator?


1 Comment

How do I create use cases for DAM?

A blog reader asked about how to create use cases for DAM.  I gave a presentation about this topic during a DAM conference.

What use cases did you have before DAM was part of the equation? Before you had a DAM, were your workflows documented?

All too often, use cases are not documented. In fact, they may be locked in multiple silos where each person (even within the same group ) do things differently.  Therefore, migrating to a workflow with DAM becomes a mystery. Without use cases, the user adoption of the DAM is often lower if users do not know why nor how nor when to use the DAM.   Where does DAM fit in the users’ daily workflow? Use cases can also affect the choice of a DAM solution.

Use cases need to be documented and shared.

Another reason for having use cases is training for new people. How do newly hired people find out how to do their job? Are they born with this knowledge? Should an employer expect everyone to know how to use all the tools and policies of the organization to get their job done?  Not likely.

Enter a new person (new hire) to the organization. What are they supposed to do? What tools are involved? When do they use the DAM and for what purposes?  Should new people operate differently than people doing the same tasks for years within the same organization? Not likely, but they often do. Does each person who coaches a new person give their own version of how to do things (plus or minus a few steps)? Is this standardized? This is often not only due to a particular level of experience, but lack of documentation and poor training. And we expect consistency. Somehow. Maybe by mind reading? That is not likely going to happen.

When you start researching a DAM for your organization, instead of looking at shiny features, see if it would work well with your use cases by presenting them to the vendor during a demo. Have real assets you would likely be working with along with real use cases. Ask the vendor to demo their solution for your use cases with your assets with metadata from start to finish in front of you.

Start building use cases with what you have and how you do things today.

  • What do you do today?
  • How do you do it?
  • Who does what?
  • When does it happen?
  • Why is it done that way?
  • What is the process?
  • What tools are used?
  • How could this improve?
  • How can this be done more consistently?

Be sure to consider the people, process and technology (in that order) which are involved from start to finish. Not sure who/how/what is involved? Ask by using…

  • Surveys
    • Online or paper form, with long answer questions, not simply ratings
    • All roles (don’t expect 100% return, even with a prize)
    • Send to everyone including decision makers and potential DAM users doing the daily work
  • Group workshops
    • Be aware of who is talking and who is not
    • Include all group members
    • In case extroverts have all the say while introverts remain quiet in the corner getting frustrated, have people take turns talking so everyone contributes
  • Individual interviews of:
    • Not just senior staff, but junior staff for a varying perspective
    • Both computer literate and those who prefer analog
    • All roles

When reviewing who is working, consider their role in the organization, not just their name so you can build and scale these job functions as needed.

Who makes the initial request? Who/What takes the request? Who handles/processes the request? Where does the request go after that? and after that? and after that? (note a pattern to fill the gaps)

How many other people do the same task(s)? Is this redundancy to handle volume or act as a backup? Can this scale up or down today based on the amount of work to do?

What is the volume of requests? Where do the requests get filled/completed? Who does this? Who/What delivers the end product/service?

Consider the whole life cycle of typical project from idea to delivery. And walk through all the steps.

How much communication is involved in all this? Likely not enough.  It is not enough to lock decision makers in a room. As discussed earlier, there are different points of view to keep in mind.

Keep the communication channels open among all differing points of view.

Stay positive. When negative points need focusing, laugh about it, then find a resolution.

Create roles. Envision the end result. Have a goal. Make it clear. Try even mind mapping. Simplify when in doubt. Follow through. Measure the results.

Avoid jargon and acronyms (so anyone can understand it). Be open to feedback, but have a schedule with deadlines and accountability.

However you create use cases, write them down and share it within your organization.

Let us know when you are ready for vendor neutral consulting on Digital Asset Management. We can also help you create your use cases.

How do you create use cases for DAM?