Category — Articles

Here is the story!

Excellent! The Group Logic Team has released its best ever version of ExtremeZ-IP 5! Check it out at www.grouplogic.com Read about it here.

10 PITFALLS OF THE DAM’D
Ten Ways Your Digital Asset Management Project Can Go Wrong
By
Greg Hammen & Chris Lynn

Digital Asset Management projects do not figure in the long and inglorious history of failed Information Technology projects as often as ERP and CRM initiatives - they are typically smaller in scale. But failures exist. There are many ways to get a DAM project wrong, and only one way to get it right. By “getting it right” we mean that the organization enjoys a reasonable return on its investment within a year of going live.

Here are some of the pitfalls we have run into in our work with corporate IT and marketing departments, publications, and creative agencies over the past decade:

1. Project Scope Too Broad. The secret to success is to choose a high-value and well-bounded problem, in which a ‘win’ will have good visibility within the organization. This will ensure that management will support the next phase, and the project team will have an internal ‘reference customer’ to help sell the changes in workflow to new users. The first phase of any DAM project should be to build a repository of useful asset files and roll them out to the users who need them most, creating a model of “self service access”.

2. Poor Leadership. All major projects need two kinds of leaders: a senior management champion whose commitment of energy, political capital and resources provides ‘air cover’ for the project team; and a project manager whose job it is to orchestrate the project resources to ensure goals are met. Without a senior champion, there is the danger that the project manager will find his work blocked by entrenched interests. Without a strong hands-on manager to lead it, a DAM project can degenerate into expensive over-reliance on the software vendor.

3. False expectations about benefits. There are typically 4 constituencies with expectations about what the DAM project will achieve:

a. Senior management - will be looking for financial returns and strategic advantage.
b. Middle management - will be looking for operational improvements, satisfied external customers and financial returns.
c. Internal users of the system - will be looking for greater autonomy and more satisfying work.
d. External customers - will want better, faster, cheaper service.

Be sure to solicit input from all stakeholders, communicate the value of the system for them and keep them informed of progress towards the project’s goals as you go.

4. False expectations about operation of the system. The software vendor got the deal by promising that their product has certain capabilities. Assuming that the sales rep didn’t actually lie, it is still perfectly possible that the end-user’s ideas on how the system should work are radically different from how it actually does work. Be sure to do a thorough assessment of your requirements and do a product evaluation before you spend the money.

5. Too much software customization. Customize your vendor’s product if you must - but too much custom code can make maintenance a nightmare. Remember that customization goes beyond development - you will also need to pay for software requirements definition, documentation, testing and revisions. Customization also slows the pace of a project and extends the time to rollout.

6. Failing to get a balanced view of project requirements. If the IT department leads the project, a frequent complaint among users is that the tech guys try to force creative users into a technology straitjacket. Conversely, a line-of-business led project may ignore the legitimate needs of the corporate IT group for platform standards, vendor qualification, security etc.

7. Picking the wrong system architecture. Usually, the demand for a DAM system arises from a specific departmental need. Sometimes companies make the mistake of buying a system that is capable of meeting only that immediate need, and lacking scalability. You should also look carefully at the different types of repository technology. For example, if you need to support heavy-duty graphics production users, you will need the ability for project content to be indexed and linked to the project master file. And be sure to stick to ’standard platforms’ wherever possible.

8. Forgetting about the meta-data. Someone has to get all of the information about the digital assets into the system. This can be a mountainous task, at least at the outset - and new workflows will have to be devised so that meta-data is captured as a matter of routine when the system is in use. This must not be an afterthought!

9. Inadequate user training and documentation. There are plenty of examples of expensive ’shelfware’ - software that does not get used because the users failed to adopt it. Your users need training and documentation beyond the manual. Be sure to publish use policies, tips and best practices for each user role.

10. Lack of success criteria. If the goals of the project are not clearly set out from the start, it will be impossible to define success. Ideal success criteria will be quantifiable, and capable of justifying the planned ROI. Examples include: reducing cycle time by X%, increasing pages/day by Y%, eliminating CD distribution of brand images to the field.

But do not be deterred from adopting Digital Asset Management technology - there are plenty of success stories in publishing, brand management and beyond. Plan well, research diligently, tread carefully around these pitfalls - and be sure to celebrate when you are done so users know its time to make the new system part of their daily routines
_________________
~Greg Hammen~