Training times with our DAMS

Royal Pavilion and MuseumsGuest blogger Kevin Bacon continues his series tracking the upgrade of the digital asset management system for the Royal Pavilion & Museums (RPM), Brighton & Hove. The work is taking place as the museums consider moving to charitable trust and in response to changes in the way they do business.

We welcome your comments and advice on this work-in-progress and you can contact Kevin directly by email kevin.bacon@brighton-hove.gov.uk or twitter @fauxtoegrafik.

 


Since my last post about our revised metadata schema, we have been concentrating on training RPM staff and volunteers in using our DAMS. This is hardly the first time we’ve trained staff in using this, but this time we’ve taken a different approach.

As the digital team at RPM manage several different systems, training and staff support is a large part of what we do. But much of that training tends to be delivered on a one to one basis, with trainer and trainee hunched around a single computer. In part, that’s a result of our working spaces, which are small offices in historic buildings, and don’t lend themselves to temporary transformation into an IT training suite.

Since WiFi was installed in our museums last year, we have been able to change our approach. As our DAMS is web-based, we’ve purchased some fairly cheap Chromebooks and set up temporary training areas in our meeting rooms. This means we can train up to about eight people at a time. That obviously makes the process more efficient, in so much as we can train more people in one go, but there are other advantages too. One surprising bonus is how group training provides a richer and more productive experience for everyone.

Training times with our DAMS

My surprise may simply reflect that I’m a largely untutored trainer, but I had never anticipated that training people to use an IT system could be so conversational. A DAMS is a rule based system with inputs and outputs – what’s there to discuss?

A lot of the discussion has been around the themes and ideas discussed in my previous two posts, and particularly how digital asset management as a practice relates to collection management. But it’s also provided a safe and open space for sharing  and testing ideas. Happily, the metadata schema we’ve put in place seems to make sense; I was concerned that we’d expanded to too many fields, but with some explanation, the groupings seem to work.

The best outcome is that we’ve been able to refine the system in response to our colleagues’ needs. Indeed, this has inspired a fundamental change to the most longstanding data element in our schema. Called ‘Asset Type’, this was the basic field that answered the question ‘what sort of digital asset is this?’ Yet in practice this could be filled with inconsistent and irregular data ranging from ‘Archive Image’, ‘PDF’, to ‘chair’. It was clear our users were really struggling with this, and after initially reviewing and testing whether a drop-down of pre-set choices would work better, we came to the conclusion that the information that would be required for this field is now captured elsewhere. So we simply scrapped it.

Information management systems don’t usually lend themselves to iterative development, largely because they are driven by pre-determined standards.  But this was a rare and successful area in which we have been able to reshape an active product in response to user needs.

However, there is still work to be done. We are just about to embark on another roll-out of training, and we still need to improve the workflow processes through which digital asset management is factored into other activities, such as digitisation. It’s also become apparent that we need to do further work on communicating the role our DAMS plays – a common question is still why this is not simply an extension of our collection management system. While some DAMS do work in this way, for me this diminishes the opportunity to make our collection images a flexible asset across the whole of RPM. Plus, a DAMS that is solely used for collection related assets opens the problem of where to store images and other digital material relating to marketing, learning and other business activities. Refining the DAMS for one set of museum business activities will have a negative impact on others.

The one really huge problem that still lurks on the horizon is retention. Storing more digital assets comes with increased costs at a time of declining resources. It’s clear that we can’t keep every digital asset forever, and we have a metadata structure that can support a time managed approach to disposal. So how do we decide what to throw out?

That will be the topic of my fourth and last post in the not too distant future.

Read Kevin’s previous posts:

Case study: Digital Asset Management at Royal Pavilion Museums

Case study: Royal Pavilion & Museums Digital Asset Management system upgrade