Building a DAM, one brick at a time
- 441 Downloads
Implementing a digital asset management (DAM) in a creative environment can be a tricky project. Through the telling of our DAM story from discovery to deployment, I share some of the learnings we discovered; learnings that can be put to use in your environment, whether highly structured or not.
Keywordsimplementation best practices discovery advertising creative
At GSD&M Idea City, we have been actively working on a digital asset management (DAM) platform for over 5 years. In that time I have spoken at several conferences regarding our solution. One question that comes up over and over again is this: What you do and who you work with is very creative and fluid? How do you incorporate something as structured as a DAM into that type of environment?
I would be lying if I told you that it was a piece of cake and that everything just fell into place. No, rather, it's taken the dedication of a great group of people, a lot of patience and a determination to know that what we are doing will ultimately help our clients and our business.
Our story is likely very similar to many other DAM implementations out there, and in the telling, I hope to highlight some of our learnings that will aid you in a successful implementation. Ultimately, it does not matter what type of environment you work in – highly systematic or highly chaotic – I think general best practices apply. I will break the story down into the following chapters so you can skip to your area of interest: Discovery, Selection, Implementation, Launch, Launch Again, Launch Yet Again and Momentum.
We began our journey about 7 years ago. Within the agency, there is a department dedicated to the procurement of images to use in advertisements. For many years, a system of hanging folders, worksheets and eventually spreadsheets of data were sufficient to keep our images organized and under control. As the industry moved into a world of digital assets, where thousands of images could be the result of a single photo shoot, we realized that we needed a better way of doing things. The search began for DAM software to help keep us in control. Once we started looking at our options, we realized there were a lot of potential partners and the software could do so much more than what we were looking for. Our problem: we did not know exactly what we needed.
So, we took a step back. It was decided that in order for us to get the most for our money (always a necessity) we needed to find out exactly what we needed and find the best solution for us, not just a solution. It was at this point that I was brought onto the team. I had worked at the agency for over 5 years and had most recently been working in our Account Service depart-ment. In this role, I was familiar with how an advertisement was created – from a client request to final delivery. I also happened to have my Masters in Library and Information Science. What a great fit. I joined the information technology (IT) department and became the lead on the project.
Working together with our Chief Technology Officer, Jerry Rios and our Director of Technology Services, Coan Dillahunty, we identified and held discovery meetings with key stake holders from each department that could potentially see a benefit from a proposed solution. From there a standard practice was followed of developing a request for protocal (RFP), sending it to 10 vendors, narrowing the responses down to a short list of 3 and then holding site visits/demos based on a script of our making. The scripts followed a typical print advertisement from start to finish and asked the vendors to show us how their system would work.
Learning 1: Surround yourself with the right people. Find people who know the business and have an understanding of technology. Let them know you do not want to change what they are doing, only make it easier for them to do it. Any change that needs to be made will need to be endorsed by people in a position to enforce those changes. Include them in your decisions and give them some ownership of the project.
During the selection process, each of the vendors visited and ran through a script completed with and approved by the people on our discovery team. We also made sure that each of the team members was present during the presentations. They were free to ask questions of the vendors and were solicited for their open and honest feedback.
The software decision was made by the team, not just by IT. For a long-term solution to work in our environment, it would need to be maintained by IT, but run by the users. Each team member got a vote. With the team's decision in mind, IT looked at our Enterprise needs and our choice was made.
Learning 2: Know what you need. Products abound in this arena. You cannot know what you really want without knowing what you really need. Will you find something that is enough, or will you find that you lack the functionality to get the job done? As we talked to various groups, we found that a system that extended beyond DAM into a more enterprise content management (ECM) category could be quite helpful to us.
Once the software was selected, it was time to get started, quickly. Our long-term goal was to administer, develop and maintain the software on our own. This is our general approach for technology solutions. We realized, though, that we needed help to get the ball rolling and to support us until we became familiar with the technology. Since a fair amount of time was spent on our discovery and selection, it was decided that it would be best to work with an integrator suggested by the software company as opposed to holding an additional selection process just for the integrator. The vendor recommended three integrators who were familiar with the rich media space. As an advertisement agency, we work with a lot of image, video and complex documents. The integrator would need to easily understand our industry so that time was not wasted explaining the ad world. We spoke with each of the companies by phone and made our decision.
From our discovery, the team knew what our goals were: break down the storage barriers that hindered collaboration across departments; develop a system that would incorporate a work in progress with an archive (thus getting rid of the archiving idea as a rule); and create a standard way to organize files so that each client was as similar as possible (enabling our workers to more easily switch to a different client team).
Internally, the same group of people from Discovery, worked on Implementation. This way we already had a group of people familiar with our goals and they also had a basic understanding of what the software could do. Our integration partner met with each of the groups and together, developed a plan. Because the team was aware of our goals, on-site time with the integrator was kept to a minimum. In the end, this helped us keep costs low and under budget.
The team's first task was to figure out how the system should be organized. We decided that we needed to look at how we do business. Is this working? Our current file share system was divided by department and access was granted only if you worked in that department. This often led to duplicate storage of files and people not being able to access the files they needed in a timely basis. Once people got hold of a file, they tended to hoard them on their hard drives. We knew that we wanted our DAM to be a system that was controlled by permissions, but accessible to all. There was a need to break down the barriers to sharing ideas in a timely manner (storage silos) and have people thinking about files from collaborative perspective. The decision was made to organize according to how we do business. For us, that meant changing our file structure to focus on the client work, and the jobs we create. Our teams are divided by client and then by job; let's structure our DAM that way. Permissions would be based on the work you need to do with the files. As this was primarily a space for our ‘creative’ files, the majority of our users needed read access to the files. The prevailing feeling was that there was a way we were supposed to be doing business and a way we were doing business. By using permissions, we could control who would be able to add/edit files in the system, therefore get back to the way we should be doing business.
As an additional goal, the system needed to be designed to function not only as a work in progress area, but also as an archive system. Our existing archive system involved saving items to CDs/DVDs with CD bank. We archived when the file shares were full. If you needed the file, finding it involved going to another work station and hopefully locating the item with a simple search. There was some metadata attached but not a whole lot that was useful. Often it was easier to re-create what we had rather than find what we had on our archive. As the system needed to act as a storage solution over a long period of time, we decided year designations would be needed as well. This would help from both usability and performance perspective.
The software we selected had a very strong workflow/task assignment component via a business process management tool. At first we had grandiose plans of automating the ad process. This is where we really hit the ‘logic versus chaos’ nature of the ad world. What we originally heard was that each client had a different way of doing things. As we spoke to our groups, though, we found that certain parts of the process could be standardized and from there, some very basic workflows could be put into practice. The beginning of the creative process (contact from the client, job number creation, strategic planning and assignment of duties) did follow a very standard, logical flow. The end of the process, production of the completed advertisement, also followed a very standard, logical process. It was the creative, brainstorming part in the middle that defied codification. Our efficiencies could be gained with the work at the beginning and the end. Why mess with the middle? We had only be told we did not understand the creative process and end up losing the game before it even began.
At this point, the oft-dreaded discussion of ‘What about the metadata?’ came up. As part of our discovery, metadata fields were determined to help locate the files that might need to be used again. There were about 50 fields that would be nice to know about a file. There was no way that we would ever get someone to fill out all of that information. Required fields were narrowed down to about five to seven depending on the object type selected.
The next logical question was, ‘Well, who is going to be responsible?’ As we needed to get back to the way we ought to do business, why not leave it to the subject matter experts who are keepers of the files to add the necessary information to the files. Where possible automation was used to pre-populate what data we could (from forms or from inheritance). As the DAM Librarian, my job was to help administer the program, not to enter all the information for the files. I can tell you about the agency and how we work, but the users know so much more about how they interact with the files, the terms to use, and the client's business, therefore they would make the metadata more relevant.
Learning 3: See what is already working in your organization and build on it. Do not reinvent the wheel. For most organizations, implementing a system like this will be traumatic enough. Give users some stability. You are likely to gain some wins early on using this method.
Learning 4: Keep your users in the loop during implementation. We find that a user-centric design model is very useful. When you share your ideas with users early on, you can find out what has the potential for working and what is doomed to fail, thus saving time in the long-run. User-centric design also increases the feeling of ownership in the process. In times of stress (‘We’re going to do WHAT?’), having some feeling of control will help aid in transition and give the users something to hold onto.
Learning 5: Keep it simple and hold the users responsible for information. They know it best.
There were two separate DAM tools that we launched with. One was a web browser that worked well on both MAC and PC clients. It gives a thumbnail representation of the file for users to browse through and export files. This was to be used by our consumers. The other tool installed a fat client on the user's machine and presented the repository as a standard file share. This was intended for our contributors (mainly our studio group). A lot of time had been spend setting up the system, getting permission sets in place, learning the software and generally getting ready for prime time.
Right before we went live with our install, we had some crushing news. The fat client tool would not work on our newest MAC machines, the ones the studio group needed to use. For a very long time, we only had the web client, not ideal. Our users had the same thoughts we did. They did not like the web application (it was too slow). We were pretty much dead in the water. Without our studio group adding files into the system, there was very little content. Images were stored, but finding them and pulling them out of the system took too much time.
Learning 6: You will hit roadblocks no matter how hard you try and no matter how good your plans are. The best thing to do is to keep your users in the know. Do not let them forget about the project. Update them even if there is nothing good to report. The idea that no news is good news is a fallacy. No news means your users will forget you.
Our studio group was very crucial to this system working. Not having a tool for them was very disappointing and limiting. The director of the studio group was part of our discovery and implementation team. As such, she understood our goals and saw the value in the new system. Before we even started loading the files into the DAM, she had her team begin organizing their file share in the same way we wanted to go live with the DAM. This was a huge benefit to a successful launch. Before going live with the DAM, they saw what standardization could do. They also helped us determine where changes could be made in our initial architecture. They could see what would work and what needed to be tweaked. The director became a huge proponent of the system. This helped especially because the group straddles the line between the ‘creative’ and the ‘logical’. They translate the creative ideas into digital layout files. They are able to work as interpreters between IT and Creative. What a huge advantage.
Going into our second launch phase, we felt a little more confident. The fat client worked on our studio machines. Working with the director of studio services, we identified a studio group who was technically very savvy and very willing to try new things. They worked with the tool and have been relatively satisfied. They are very big on telling people where and how to access the files. Our web application was still seen as slow and cumbersome. Ultimately, although there were many benefits and features within the application, these could not overcome the perceived defects of the system. Adoption of the web application was slow.
Learning 7: Find your allies. An IT department likely will not be able to push this sort of initiative on its own. You will need friends in your building pushing and selling your initiatives. Usually, when people hear that IT has something new, they cringe. Having a team evangelizing for you has its advantages.
Learning 8: Put it in words your users understand. If you do not know the language that is to be used, find someone who does. Our studio group was a perfect group to launch with. They could interpret what IT wants with what the agency needs. They speak the language of both sides of the building (logic and creative).
LAUNCH, YET AGAIN
Within the last couple of months, we actually entered into a third launch phase. The software company released a new interface for the consumers’ web application. It was built on a more responsive platform, and is not only more visually appealing to our users, but also incredibly faster than what was previously available. Knowing that there were ill feelings towards the previous web application, we changed the terminology associated with the newer application. Branding is our business. The system is now known as ‘Lightbox’ and not ‘DAM’.
The software continues to build on functionality. Some of the functionality is based on ideas that we have worked directly with the software company to bring to life. The response from users has been very positive. We are finally entering a day when both sides of the application (both consumer and contributor) are in a good place. We have seen increased momentum in adoption, especially from our Creatives and other consumer users. People can access files no matter what department they work in; they can get what they need when they need it.
Learning 9: Keep at it. Do not quit. Be a loud voice in your software user community (we are). Tell them what you need and ask them to help you. Volunteer to become beta testers and part of design groups. It takes time, but eventually your solution will be just what your users need.
With the new web interface, we feel incredible swells of momentum within our user base. We recently launched the application with one of our external clients and heard positive feedback from them. I love walking through our studio art department and hearing the users say to one another, ‘that file's in the DAM’ (it is okay that studio uses DAM; they are talking about the fat client.) We no longer archive items to a CD/DVD system. This has led to a decrease in time spent looking for items and more time using what we have already got. There has been a decrease in calls to the help desk screaming that the shared drive is full. Now studio artists can do what they were hired to do (build files) instead of looking for them. Our creative teams now have a faster way finding images and can get the necessary information about using them.
Learning 10: Success will not happen overnight (unless you are very lucky), but when it does, the feeling is very sweet!