Every technical project goes through a few standard phases—design, build, and test are common examples. Digital Asset Management projects typically include a precursor phase that is often referred to as “interminable waiting.”
So maybe that phase doesn’t get included in the formal software development life cycle, but it is quite common for organizations to get stuck somewhere between the point where everyone recognizes the desperate need for a DAM and the point where budget and resources are available for a DAM.
Proactive organizations often want to know what steps they can take during this delay to best prepare for their eventual DAM. This blog post is intended to provide a few Dos and Don’ts for organizations that wish to prepare during this period.
DO Locate Repositories
Companies without a DAM almost inevitably spread relevant assets *everywhere*. Extreme cases involve a closet full of hard drives from every photo shoot since the Cretaceous Period, but even companies with strong governance can find themselves with several different servers storing different types of assets or serving different business units.
Developing a list of these repositories can be very helpful to the eventual asset ingestion process. As a rule of thumb, any repository with less than 1000 unique assets is almost certainly not a candidate for an automated ingestion. The same goes for assets stored on designers’ workstations. These small repositories can be included in the repository list, but assets stored in these repositories will either be consolidated to a larger repository before automated ingestion or ingested manually.
DO Analyze Repositories
Once the list of repositories has been finalized, a level of analysis can be helpful to prepare for eventual ingestion. If folder structure or file naming conventions have been defined and moderately well enforced, then even a brief articulation of those rules can help with the eventual ingestion. These rules about naming convention and folder structure can be thought of as embryonic metadata. As creative teams organize their repositories in the absence of a DAM, they almost always find a way to include the most important information about those assets within the folder structure or file name. For some companies, this can be the inclusion of a product hierarchy in a folder structure or a SKU in a file name. For other companies, it might be a job number, asset type abbreviation, or language code. If this information was important enough to capture and standardize in rudimentary ways within filename and folder structure pre-DAM, that information is almost certainly important to map into more advanced metadata structures post-DAM. A sophisticated automated asset ingestion process should be able to map this information from folder and filename to metadata.
The devil is in the details of this type of analysis, so here are a couple of additional pointers:
If these rules have changed over time, it can be helpful to document earlier conventions.
If these rules vary by repository or by folder, be sure to document each such set of rules.
If there is a standard convention for obsolete or non-current versions, this information should be captured.
Even an imperfectly followed convention can be helpful. As long as some folders and filenames conform, some level of automated extraction of metadata should be possible.
In some cases, the embryonic pre-DAM metadata is actually metadata captured on asset XMP wrappers via Bridge or Capture One. If that is the case, certainly include this information in the analysis as this XMP metadata should be able to be mapped to DAM metadata during ingestion.
If you’re new to an organization and want to quickly review a large repository for patterns, there are simple steps to export all the assets within a repository to a spreadsheet for quicker analysis. Please contact us to request these steps—just let us know if you’re working on a Mac or Windows machine and we should be able to share some simple instructions.
DON’T Reorganize Repositories
One effort that is definitely NOT recommended is a massive manual reorganization of historical assets to retroactively create or implement a standard folder structure or naming convention.
Credit: Beth Scupham
Even attempting this task is a surefire way to stall the DAM project forever. As soon as a handful of unlucky souls are allocated to this task, everyone will start to view the manual reorganization as a necessary precursor to implementing a DAM. But such efforts will never be finished. The assigned team members will spend a few days working diligently before being pulled away to a higher priority fire. Really dedicated staff might keep plugging away on occasional slow days for a few weeks. But eventually, it will become clear that the reorganization will never finish and even the most diligent team member will let the task languish in a permanent backlog status.
Even if it were possible to complete this work manually, it is a poor use of resources. A sophisticated asset ingestion process should be able to automate the renaming and reorganization of files in a much more efficient process.
For companies that are in an extended waiting period for their eventual DAM system, it may be worth the effort to start defining or enforcing more standard folder structure and file naming conventions going forward to simplify the ingestion of assets created during the pre-DAM interim.
DO Find Taxonomies
Any DAM implementation project will need to define or refine taxonomy; however, most large organizations have some form of taxonomy in place already, although it may be called by a different name.
A common example for some types of organizations is product master data. This information may be stored in a Product Information Management (PIM) system or an Enterprise Resource Planning (ERP) system or even just in a spreadsheet, but most companies that sell products have some formal master data taxonomy about those products. Not every element of that product master data will be relevant to the eventual DAM project, but any product metadata that is captured in the DAM should definitely leverage the existing product taxonomy to avoid recreating the wheel (or worse, recreating the “round rolling disk” and ending up with two terms for the same concept).
Another common example of existing taxonomy is website information architecture. For organizations with a deep set of content or commerce options online, the structure of the website likely reflects some of the most important externally-facing taxonomical concepts for an eventual DAM system. However, it is worth keeping in mind that the nature of this taxonomy as an externally-facing structure may create some complexity when mapping to a DAM taxonomy. It is a perfectly valid marketing strategy to sell the same product under different brands in different geographies, but it is less clear that marketing segmentation of this nature will add value to internal DAM audiences. That caveat stated, it is still helpful to capture a web information architecture as a taxonomical input to a DAM project during the pre-project phase.
Other examples of pre-DAM taxonomy include lists of relevant languages, geographies, asset types, asset sources, or asset statuses.
DO Think about Integrating Systems
One of the hardest things to plan from a systems implementation perspective is integrations. Organizations often have a vague notion that DAM should integrate with a handful of systems, but the detail starts to get fuzzy on the first clarifying questions (i.e. “Why should these two systems interact? What are we trying to accomplish?”). Even if the higher-level questions are answered, the lower-level questions around volume of data, scheduled frequency, or technical protocols are almost impossible to answer before the project is well underway. But organizations can certainly help clarify project scope by at least thinking through the purpose for and prioritization of an integration wish list.
Another pre-project planning step organizations can take for integrations is to classify the connection as an out-of-the-box connection, a custom integration, or somewhere in-between. To give a specific example, consider a company that wants to integrate their DAM with creative tools (i.e. Photoshop and InDesign), eCommerce, and Product Information Management (PIM). The planned DAM software has an out-of-the-box connection to creative tools, a connector for the PIM system that is provided by a third-party, and few customers who have built bespoke integrations with the eCommerce platform. The level of pre-project thought will vary based on these scenarios. An organization should get a demo of existing connectors and determine whether the existing functionality meets their anticipated needs or will require additional customization. For a bespoke integration, companies should really dig into their own use cases to help provide scoping guidance for the eventual DAM project.
DO Find People
Most organizations recognize the need for people allocated during a DAM implementation project, but far too many overlook the need for ongoing care and feeding of the system after launch. This is more often a mistake by business stakeholders than IT leadership—technical teams are used to planning for ongoing system maintenance. The primary business owner of a DAM is often an organization’s creative director, a role which rarely oversees the business ownership of enterprise technology. A common mistake for these owners is to think of DAM like Photoshop—a complicated enough piece of software with a learning curve, but not one that requires ongoing business ownership. But enterprise DAM systems are configurable and customizable and do require ongoing decisions about how best to use the tool. Even if no full-time resources can be added to a creative or marketing team to support a DAM, there should still be clear assignment of business ownership to a trusted member of the team. DAM Manager may just be one hat that this individual wears among many, but the team should know who to seek out for questions, concerns, complaints, or suggestions.
Without this allocation, team members will not have an outlet to suggest missing taxonomy terms after launch or an adjustment to the policy on when assets are added to the DAM. In the best case, such escalations will roll back up to the team manager or original senior stakeholder for DAM. But that individual is often too busy to engage and manage detailed DAM questions for very long, so post-DAM processes and policies often start to regress into the same messy practicality that existed pre-DAM. Monitoring, addressing, and escalating such backsliding is another key role of this business owner to ensure that the DAM continues to be a valuable tool for the organization.
Conclusion
Hopefully, this blog posts energizes some readers who find themselves in the painful waiting phase for their DAM project. Unfortunately, none of these preparations will help allocate budget, resources, executive sponsorship, or time required for a successful DAM project. Winning those battles is a different challenge that is hard to cover in couple of paragraphs under a header of “DO Get Organizational Buy In.” But if you find yourself stuck on your DAM initiative and don’t plan to be stuck forever, taking these preparations can ensure that your project—whenever it is approved—is well poised for success.