As I mentioned in my previous blog, whenever you start down the path of trying to manage the assets of one department or project, you will quickly discover that there are a bunch of workflow problems that can potentially solved by tying data together. Yet even when your technological systems communicate flawlessly, in all likelihood, the human beings involved haven’t.
In any organization, there are many more individuals using various parts of the data you are attempting to manage than you expected – and those uses will be hugely varied. You will discover people “copying and pasting” data from spreadsheet to spreadsheet, email to Power Point, website text to Photoshop file, and on and on. Every time you think you have simplified even the smallest workflow, you will have people come out of the woodwork hollering, “What happened to the web page/spreadsheet X? I’ve been using that for 2 years to get Y done!”
And – prepare to take a deep breath yourself before you panic when that person in another department calls you up and says, “Hey, we would like to host our new department events calendar on the company network. Who do I talk to?” two weeks before you launch a company-wide event calendar system.
DAM-implementation survivors all say, “Start small.” They are absolutely right. Find a department or project level workflow that can benefit with the implementation of centrally stored data, and then go from there. This isn’t because you are incapable of organizing and carrying out a large an intricate project, but because of the simple fact that your organization is full of people who have adapted to the structure of data that exists today, without communicating the details of how or where their data is coming from. They are just getting their job done, and you need to respect that.
No matter how much research you do, meetings you have, emails you send, there will be important, not communicated uses of that data that will be left out of your plan.
The best thing you can do to make your DAM succeed is to EXPECT people to panic as soon as the DAM is put in place. Be ready in your budget and in your implementation timeline to make adjustments to code – specifically, expect to modify how your system defines User Roles, Search and User Interfaces. I’ve found that up to 15% of a project’s budget should be earmarked for necessary revisions after launch. That can be a big number for the check-signers to swallow at first, but it is far better to ask for that extra 15% in the initial budget request, rather than explain to the powers-that-be why no one is using the system (or endlessly complaining about it) a year later.
The bottom line: When roadmapping any DAM project, include time and money to adjust for unexpected data communication needs at the end of each new development effort. You will end up with much less pushback to the changes you put in place; and your DAM will ultimately be able to serve more individuals more efficiently.
Do you have questions or observations you would like to share about your (current or potential) DAM development? Use the comments section below or email your question to ckingDAM(at)hotmail.com and I will address those questions here in coming blog articles.