Do Organisations Need A Dedicated Digital Asset Management Department?

Romney Whitehead wrote an article One giant leap for DAM last week on her Borrowed Insight blog.  In the piece, she talks about the need for a dedicated Digital Asset Management department, following the discussion of it at last month’s London DAM Meetup:

“More often than not the starting place for the DAM team will be within the department who initiated the requirements to get a DAM in the first place, most commonly this is IT, marketing, or editorial. However there were tales of DAM sitting within finance, or syndication teams, and even more tales of teams being moved about the business as their remit changed or the company grew, or having their DAM initiative labelled as ‘project’ status for years after the initial project stage.  This can prove both demoralising for the team members, and disruptive for a business, leading to not only a greater turn over of staff, but also a disrupted technical and business roadmap for the DAM system, and a reduction of business value.” [Read More]

Firstly, it is refreshing to see the word ‘disruptive’ being used in its conventional sense (i.e. not a good thing and to be avoided) as I have grown weary of its recent misappropriation as a management consulting term to suggest ‘change’.  But getting on to the serious point, I have to agree with this suggestion and the implications of it extend out to other DAM special interest areas too.  There are some potential downsides that do need to be considered, but I think they can be mitigated or avoided entirely if everyone involved is conscious of the risks.

I was at the London Meetup where Romney bought this topic up and the opinions expressed struck a chord with all those present – I don’t recall anyone not in agreement with the idea.  Last week I talked about the fragmentation of DAM and why so many different kinds of solutions end up being implemented.  Part of the reason is that they are often acquired by multiple departments who all have their own priorities and expectations.  One of the other factors is that Digital Asset Management has only recently begun to gain widespread recognition.  There are people who have worked in this sector for decades and I would suggest that you can point the origin of the recent rapid growth to a period from around 2004 onwards, but a lot of users entered the fray far more recently in the last 4-5 years.  Some used existing conventions and developed upon them (both in the technical and design sense) others decided to start from scratch and devised their own.  Which was the better option is hard to say without reference to each case, but the net result is a highly diverse range of approaches to solving the problem of rich media management.  This contains the seeds of both an opportunity and a risk for dedicated DAM departments, as well as the software solutions they plan to use.

The basis of the argument in favour of a dedicated DAM department is that many of the functions carried out by Digital Asset Managers do not neatly slot into the realm of just one division and a large ROI opportunity to re-apply the expertise acquired is being missed.  In respect of general skills about how to manage significant collections of assets, that is reasonable.  Anyone who has worked on DAM initiatives will be aware that a major aspect is educating users about basic topics like metadata and findability.  Until the arrival of DAM, these were generally considered esoteric skills that you would only find in preservation or academia, but they are now in demand from a far wider range of clientele – a quick look over the jobs board for services like DAM Guru provides ample evidence of that fact.

I think I would favour the role of this department being about education rather than just a place to dump all the cataloguing jobs that DAM users don’t fancy taking on themselves, but equally if there isn’t an element of helping with that activity, the department might become detached from the rest of the organisation and then questions will get asked about why it needs to exist any longer.  So a careful balance is needed between taking on the cataloguing delivery but not getting saddled with the whole task (or ‘quietly getting on with improving the working lives of our users’, to borrow Romney’s own insight).   Another major trade off which isn’t properly acknowledged is the conflict between users who want more relevant and useful search results versus the cataloguers who want to get the task out of the way as quickly as possible.  The role of a DAM department would be to help to defuse that by enabling users to appreciate what is involved and encouraging greater participation in optimising cataloguing data.

Romney appears to suggest a single DAM system would be a goal of a DAM department, but later she acknowledges the need for a more pluralistic approach:

“Lack of the holistic view – Most departments will solely focus on their own requirements and needs, often leading to multiple DAM systems being purchased and used with a single company. However by having a central team and system assessing all business areas then it will allow both purchase of a system suitable for the majority as well as allowing the creation of a long term roadmap that adds the greatest value to the most people. Priorities can then be set to this roadmap for the wider company roadmap, and areas that require a specialist system for their assets can still be free to procure those systems.” [Read More]

I’m going to widen the definition of ‘system’ to view this as a ‘DAM infrastructure service’ rather than a specific product that everyone gets obliged to use because the DAM department told them they have to use it, as that is getting a bit close to the ‘we know best about all software, ever’ approach employed by less progressive IT departments (which many reading this will have seen as having been tried and failed in the past).  The User Interface (UI) in DAM solutions makes a massive difference to ROI.  It’s not just as simple as having front-ends that are easy for DAM beginners to use (although that certainly can’t be ignored either) it’s about fitness of purpose and relevance to the tasks users need to carry out.  If you read specs for DAM systems offered by vendors, they all sound highly similar, you do get occasional arguments between them about whether product x fully support feature y, but if you didn’t look at any of them in actual, live use, you could be forgiven for wondering how the market supports the 100+ operators who consider DAM to be their home turf.  The reason is because they all have a slightly different take on DAM to each other, some of which appeals more or less than others.

I don’t think this is a problem that will ever get properly solved.  What I would see with a DAM department is that a central rich media services facility is established (the major part of which probably will be bought from a small range of vendors – perhaps even just one).  Running on top of that are applications where the providers are able to focus on the business issues faced by a particular group of users.  The rich media delivery infrastructure provides and enforces the interoperability protocols needed to make assets widely accessible and the DAM department can stipulate minimum requirements for the storage of all assets that are transported within it.  In this sense, the DAM department is as much about digital asset logistics as other activities like cataloguing (and you could reasonably suggest that the two are not mutually exclusive).

I think the key argument in favour of a dedicated DAM department comes when you realise that the use of digital assets now extends across an entire organisation.  As was discussed during the CMSWire Tweet Jam last week, it’s well understood that an email service, for example, needs to be utilised by everyone, even though certain departments might have a greater interest in the operational management of it.  Looking at wider trends in the growth of digital asset volumes, it does make sense that not only do you need individuals (and software to help them) but that they may also need to be grouped into cross-functional departments so that lessons learnt in one part of an organisation can be more easily re-applied to another similar requirement.  The key risk factor that needs to be avoided is that the DAM department doesn’t fall victim to some of the same self-serving introspection that other specialist departments can sometimes suffer from, IT obviously get singled out for this kind of behaviour, but not all are like it and it might be more of an outdated cliché than a fact these days.  One of the reasons why IT departments are perceived as being unresponsive or disinterested is because they are frequently heavily over-worked and have to prioritise problems according to severity.  I could see these quickly becoming issues for busy DAM department also over time.

It will be interesting to see if this idea acquires momentum in the future.  If it does, you might expect DAM departments to become quite sizeable in terms of headcount and budget just to cope with the demand they are going to be placed under, but I would also anticipate a lot of resistance to the idea of having one at all also on the basis that all kinds of special interests within organisations think they should have a dedicated team.  The argument for DAM is more justified than most other specialist areas I can think of though.

Share this Article: