I enjoyed DAM EU – a Henry Stewart Event – last Friday and was particularly struck by the range of projects, the variety of approaches, and the diversity of industries represented. Sponsors included Capture, Kit Digital, and iBrams.
I will publish a series of posts over the next few days to cover the event, session by session. It has also been written up by Michael Wells.
The Art and Practice of Managing Digital Media
The conference was chaired and opened by David Lipsey, who has a distinguished career in Digital Asset Management (DAM). He introduced the day by talking about the need for “fungibility and liquidity” to make digital assets earn their keep. He pointed out that DAM is an emerging and maturing field. None of us thought of a career in DAM when we were at school, it is something that we have arrived at during our working lives. Now educational institutions are considering providing DAM courses to meet a growing need for DAM skills. DAM is also starting to become an enterprise-wide infrastructure layer, so “soft” skills, such as gaining cross-departmental buy-in to projects, are becoming increasingly important.
Getting More out of DAM: The Latest Technologies and What is Possible Now
It is always a pleasure to listen to the eminently sensible Theresa Regli of the Real Story Group. She observed that distribution channels are changing and there is now more focus not on gathering assets together, but on how you send out assets in the right format to customers – to all phone platforms, all PC and Mac platforms, etc. Mobile apps are very much in the limelight at the moment, but it is important to see them as just another channel. It is also worth remembering that you don’t need to build specialised apps for all devices, as cross-browser formats may well be adequate. The purpose of the Digital Asset Manager should be to get the right media to the right people in the right format.
To be successful, DAM projects need to handle change management and get people to work in different ways. Creative people want to work collaboratively and simultaneously, so DAM systems need to support this, rather than imposing rigid linear workflow processes.
When assessing DAM technologies, the differences are usually not in the functionality they offer, but in the way they provide that functionality. Too much emphasis is often put on technology to solve problems. Theresa said that she thought technology could solve about 20 per cent of business problems, and even that was probably a bit generous. The core problems are caused by metadata, collaboration, diligence, and governance.
Different people need different views of a DAM system at different times, so customisation and personalisation is useful – for example providing limited functionality on an iPad app that enables workers who are away from their desks to access specific aspects of a system. However, a danger to avoid is creating multiple versions of the same asset. It is much better to have a master version and transcode out to each device as necessary.
New developments in metadata include colour palette searching which is popular with creatives more interested in moods than particular things. Another development is AVID’s “layered metadata”, which offers the ability to annotate directly on to video, as well as have general metadata for the whole asset. Much work has been done to improve video handling tools, so automated scene detection and facial recognition software are now becoming available in products.
When buying a DAM system, it is worth remembering that the now dominant technologies are relatively new, and that what may be ideal at a workgroup level may not scale up to enterprise level.
How to be a Good DAM Customer
Sarah Saunders of Electric Lane spoke on an often overlooked, but vital, aspect of the DAM procurement process – how to be a good customer. She pointed out that you get to choose your DAM vendor, but they don’t get to choose you. Projects can be derailed by customers being unsure what they want, being poor project managers, or having unrealistic expectations of what they can get for their money. It is in no-one’s interests to drive the software vendor out of business.
For a project to be a success, it is important to have a project leader who is not part of any of the stakeholder departments and is empowered to make decisions and overrule any individual department if their focus on their own departmental needs threatens the entire project. Creative people and IT people tend to think very differently, to the extent that they can completely misunderstand each other. So, it is not enough just to get people to sign off a complex requirements document, they need to understand it on their own terms otherwise they are likely to be disappointed. Building a system that the creatives are happy using, even though their requirements may seem bizarre to the IT department, is just as important as keeping documentation in good order, something the creatives might not appreciate.
One of the hardest aspects is working out what you really want from the system, and where you are prepared to compromise in order to get something that can actually be built for the budget. In terms of functionality, it is important to think beyond what people ask for, as that is likely to just be what they are using already, to what they would like if they knew it existed.
It is also important to see any system working in practice, as demos may not be enough to know that it will work with your data and business processes. A small delay in keywording speed can have a huge impact on productivity.
An iterative build process good if needs are complex. It can be expensive, but may still be cheaper than ending up with an underperforming system.
Some customers expect the vendor to do all the thinking for them, but the vendors do not know the business needs and processes of every single business. It is not an easy job to be a software vendor, and a difficult, disorganised customer will always end up having a hard time.
Panel session: how we did our procurement
Net-a-Porter took a very user-centric approach, running lots of requirements gathering workshops and writing user stories rather than a requirements spreadsheet. They spent 6-8 months planning what they wanted the new system to do, with the help of external expert consultants.
At Shell the build process of their new DAM system took about 18 months and involved the migration of 50,000 assets. They selected Vyre, as a good cultural fit. Lisa stressed the importance of getting vendors to demo their products with your data and felt that details requirements documents and scoring systems were worthwhile. She argued for the “soft” value of a good cultural fit between the team and the vendor to be included in the scores, which the IT team did not agree with. She pointed out that the IT team have a very different perspective as they want the product that they will find easiest to integrate as their short-term project, but you are left to work with the system on a daily basis.
In terms of lessons learned, she felt that their initial requirements were not specific enough, and that this led to change requests and delays. This caused probpems wiht senior managers, who had not expected the project to take so long. However, once it was built, it was well received. Lisa pointed out that change management is really just talking to people and explaining what is going on. They had great success with the adoption of the new system as it was such a vast improvement on the system that had been built for them 10 years previously.