10 Pitfalls of the DAM'd
4. False expectations about operation of the system. The software vendor got the deal by promising that their product has certain capabilities. It is still perfectly possible that the end-user's ideas on how the system should work are radically different from how it actually works. Thoroughly assess your requirements, and evaluate the product before you spend the money.
5. Too much software customization. Remember that customization goes beyond development. You will also need to pay for software requirements definition, documentation, testing, and revisions.
6. Failing to get a balanced view of project requirements. If the IT department leads the project, a frequent complaint among users is that IT tries to force creative users into a technology straitjacket. Conversely, a line-of-business led project might 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 buy a system that meets only that immediate need, and lacks scalability. 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 non-proprietary standards.
8. Forgetting about the metadata. Someone has to get information about the digital assets into the system—a monumental task. New workflows will have to be devised, so that metadata is routinely captured. 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 embrace it. Your users need training and documentation beyond the manual. Publish use policies, tips, and best practices for each user role.