How are you involved with Digital Asset Management?
How do you figure out the business value of Digital Asset Management for your organization?
What advice would you like to share with DAM Professionals and people aspiring to become DAM Professionals?
Henrik de Gyor: [0:01] This is Another DAM Podcast about Digital Asset
Management. I’m Henrik de Gyor. Today I’m speaking with John Dougherty.
John, how are you? John Dougherty: [0:09] Hi, Henrik. Nice to be with you today. Henrik: [0:11] You, too. John, how are you involved with Digital Asset
Management? John: [0:15] I’ve been involved for a number of years. I was part of the original
committee that our CEO convened to do a top bottom assessment of our technology.
Helped by an outside company, DPCI, we did that. We decided that
one of the things that we needed to do is to acquire an enterprise-wide DAM.
[0:33] Then I was put in charge of the workgroup task with choosing the DAM
technology. We ended up choosing North Plains TeleScope, which we then piloted
in 2006, and went ahead and implemented in 2007. I was in charge of the
implementation in change management teams, and finally in charge of ongoing
operations. This was also part of my responsibility for Content Management
Systems in general. Henrik: [0:55] How do you figure out the business value of Digital Asset
Management for your organization? John: [1:00] Henrik, I’m so glad that you put that in terms of business value and
not ROI , because I think a lot of organizations rush to the ROI , stepping over
qualitative advantages. In my opinion, you start with the qualitative advantages,
and then you conclude with the quantitative advantages. [1:17] You figure out
how a DAM can improve the organization. How it can strengthen it. How it can
add core competency. Eventually, what you end up with is lots of different avenues
for savings. But, I think if you lead with that, it makes a mistake, because
then the focus is, “How many jobs are we going to save?”
[1:36] The translation to the people you’re trying to implement DAM with is,
“How many people can we get rid of?” I think that’s not where you want to be
when you’re assessing the value of a DAM.
[1:45] In terms of discovering value, I’m a very big proponent of leading with use
cases. I think that working out with each business unit, and each part of each
business unit. A set of use cases, a story, if you want, on how this DAM is going
to be used.
[2:02] How are you, exactly, going to achieve something that that group wants
to achieve, whether it’s authentication opportunity, or greater flexibility in their
workflow. Whatever their goal is, how are you going to actually use the DAM
to do that?
[2:17] I think by leading with use cases, it really keeps you grounded in reality. It
keeps you focused on service to the people that you’re talking with. The beauty
of it is that half your implementation and half your change management is done
before you’ve even purchased the system.
[2:34] I think leading with use cases really help to uncover business value, to document
that well, and to make sure that you, in fact, are able to realize it. Henrik: [2:43] Once you have those business cases, is there some kind of way of
measuring that value? John: [2:48] Certainly. There’s a lot of different ways to measure value. One
way you can certainly do it is in terms of greater efficiency that you’ve achieved.
Operations that may have taken a long time, you’re able to quantify that you’re
post DAM or even in the middle of a pilot, that you’re able to achieve certain
savings in terms of efficiency. [3:11] I would argue also for getting the people
with whom you develop the use cases to assign a value, both quantitative and
qualitative, to the achievement of the use cases. How well you achieve the use
case then starts to have a monetary value and a quantitative value.
[3:29] Independently of that, I think you also need to have the active participation
of the finance team in having models that will satisfy them that are otherwise
being achieved. That may cut across the use cases in the sense that it
provides a reality check on the model that you use going into it. I think that for
each organization, how you do that independent analysis is going to be somewhat
different, but it’s going to be based certainly on measurable outputs. Henrik: [4:04] What advice would you like to share with DAM professionals and
people aspiring to become DAM professionals? John: [4:09] First of all, if you’re part of the team that’s choosing a DAM, I would
say one thing is focus on key features. Don’t just create a huge long laundry
list of 752 features that you think are going to be in there. Because you quickly
get lost among the forest even if you do a careful job of vetting those features,
weighing them, and giving them importance. Too large a list will just muddy
the waters in my opinion and certainly, in the use cases I talked about. [4:44]
I think for choosing, a really good thing to do is when you’ve concluded on a
system and you’ve worked out a deal with a vendor, possibly an implementation
partner and possibly others that will be involved in the process, draft a simple
statement. Have the team draft a simple statement that says, “This is what we
think we are buying. This is what the DAM that we are purchasing includes in
plain language.” Because that’s a reality check that the vendor can use and
everyone involved can use to basically say, “Is our understanding the correct
[5:27] What I’ve found is when you do that, what sometimes pops out of there
is that there are misunderstandings. Things that are optional that you’re assuming
that are not, and things that have not been accounted for in the plan that
people assume have been accounted for.
[5:41] Other advice I’d say, be honest with yourself. It’s very easy to delude
yourself with wishful thinking if you’re trying to sell something, if you’re trying to
make a case for something. If you’re relentlessly honest with yourself and let the
[5:59] So if you have a hunch, if you think you know something, try to find the
best available source, either qualitative or quantitative. That may be people
that really know that subject matter or a body of information that you can get
at that, will substantiate your hunch. Just don’t give into wishful thinking. Don’t
[6:19] I’d say respect the expertise of others. Often, DAM projects are led by
information technology, and properly so. But there’s going to be a lot of people
whose expertise is needed who may not know the right terms or the right
frameworks or think about it in the most sophisticated way. But you have to respect
their expertise because not only will their expertise be needed, but you’ll
miss things if you don’t make sure that you encompass that expertise.
[6:49] Something I wish I had done more in the implementation that I did is look
for bright spots. There’s going to be groups that just take to it really well, that
they’re off and running. You can really leverage those bright spots.
[7:04] When you get a bright spot, figure out why it’s a bright spot. Why does
that work? What is it particularly that is successful about that? Then use that to
bring up the success rate in the rest of the tasks that you’ve got.
[7:21] I think focusing steadily on what improves your colleagues’ lives, aesthetics
and convenience matter. You wouldn’t want to condemn someone to live in a
terrible apartment. The DAM that you’re putting in is going to be part of their
lives, and it needs to be a welcomed part of their lives. I think a steady focus on
what improves your colleagues’ lives is a great thing.
[7:49] Then, lastly, I would say be prepared to do a two-year overhaul. Almost
all DAMs have significant problems in their first implementation. Be ready to do
a top-down review. Then attack those faults and build that into your plan that
you’re going to need an overhaul in two years. Henrik: [8:10] Thanks, John. John: [8:11] All right, Henrik. Thank you. Henrik: [8:13] For more on Digital Asset Management, log onto AnotherDAMblog.com. Thanks again.