In May 2013, the Midwest Digital Asset Managers meetup group was launched in Chicago (IL) as “…a group intended for anyone interested in the various aspect of Digital Asset Management.”
I would imagine DAM professionals and people interested in Digital Asset Management (DAM) from all over Chicago area could meet together with like-minded people about DAM. Regardless of market sector, they are likely are faced with similar challenges around people, process, technology, information, budgets and other issues. There are solutions to all of these issues a
Then again, maybe Chicago has more rainbows than everyone else in the world and they may not have to face any issues with Digital Asset Management. Otherwise, Chicago can join their regional DAM community just like New York, Southern California and London has to discuss their successes and challenges with all aspects of DAM.
Speaking as one of the co-organizers of NYC Digital Asset Managers, our membership have grown by over 20% between January 2013 and May 2013 by having 7 meetups in 5 months. Meetups are possible with good content, discussion, marketing, networking and organization. The interest in DAM does exist and it is a matter of people with that interest wanting to get together.
We wish the Midwest Digital Asset Managers all the best.
I launched the first Kickstarter project related to Digital Asset Management (DAM).
The Project
We need to fund Transcribing Another DAM podcast. Over 120 episodes of this podcast series including 80 interviews with different professionals from various organizations. The goal is to transcribe these podcast episodes from audio to searchable text.
How?
Kickstarter is a crowd funding site for projects. Someone posts a project with a defined end result. People back the projects they believe in. In this case, project involves transcribing the audio podcast episodes into text.
No, we are not going to ask you to transcribe the audio for us.
A Transcription service will do all the transcribing of these podcast episodes and they charge for every minute of audio. There are hours of audio to be transcribed. This is why we need financial backing to pay for this work to be done and that is why I started this project to fund this effort.
Why?
Why do this? What is in it for you as a project backer? If you back this project with your funds and help make this project happen, you can get a reward depending on the amount you pledge. Aside from the rewards, you will be helping yourself and anyone interested in Digital Asset Management to have a full text version of most podcasts episodes, especially the 80 different interviews. These transcripts will be indexed and fully searchable so you can easily reference these podcasts and not have to take notes on what someone said. This also makes this more accessible to everyone for learning and enrichment of Digital Asset Management.
Rewards
If the project gets fully funded and we reach the goal of $3000, every backer who pledges at least US$20 to this project will get an ebook of all the transcriptions. The ebook will not be available to people who do not back this project. The ebook is a Kickstarter exclusive offer.
If the project is not fully funded, does reach its goal, then nothing happens with the project. No transcriptions. No ebook. No rewards. All the money is reimbursed to backers. Move on to the next project.
I have taken in consideration that transcripts will need to be reviewed and that will take some time. There should be enough time to avoid delays in the timeline of delivering these transcripts and rewards by sometime in August. This will not be a rush job.
Am I done?
I am not finished creating more content and improving the site for users. Another DAM blog and Another DAM podcast will continue to exist. These will continue to be free of charge to access and reference for everyone.
I will continue creating more original content regularly since there is still plenty to talk about in the field of Digital Asset Management. There is plenty more to contribute and share. Some people who want this to go away, but I keep sharing more.
Are you ready to support these efforts of sharing more through this crowd funding effort?
Recently, a company came out with their list of Top DAM Influencers and I am honored to be listed as one of them. Maybe the blog and podcast had something to do with it.
Then, during a recent Digital Asset Management (DAM) event, the same company introduced their first set of DAM trading cards based on their list of Top DAM Influencers. I see your DAM trading cards and raise you some DAM voodoo dolls.
What I am wondering is where are all the DAM voodoo dolls? Someone has to have these somewhere. Really. Think about it. A voodoo doll of each DAM professional could come ‘complete with a large set of pins.’ Every pin could be listing each of the common DAM challenges, issues and pitfalls. I would be curious to know who has these dolls and who is inserting the pins into each doll. If you are a DAM professional, how many of these pins have been inserted into your own voodoo doll? (I am not going to ask where these pins were inserted though)
Just imagine that large list of pins (challenges) to choose from. (Come on. We could either cry about it, ignore these issues or we can laugh about them and do something about it, right?)
All DAM professionals have experienced some or all of these challenges. Maybe more. These pins in our side are some of the challenges we face and these become opportunities to overcome and succeed. DAM professionals have experience in resolving these issues.
Now, where did this metadata pin come from?
Where is your DAM voodoo doll? By the way, Happy April Fools Day.
What pins (challenges) are you feeling with Digital Asset Management?
Note that the author does not practice any voodoo. The author has been found to have a sense of humour. Insert another pin.
Let us know when you are ready for some vendor neutral consulting on Digital Asset Management.
Many people do not read instructions. They may enjoy reading what they want to read, but instructions are not one of those preferred works of non-fiction that come to mind. When was the last time you read instructions? Why? There is often the assumption and expectation things will be easy to understand and easy to use. When we download a new software application to one of our devices, do you see piles of instructions, guides, or manuals? Not likely.
And are we expecting other people to read instructions as well? Newsflash: many do not read instructions even if their lives depend on it. Some manufacturers in certain sectors include instructions to supply warnings, notices and legal documentation attempting to limit their liability in the case their product or service is (was) used incorrectly and disaster occurs. An example of this was a product mailed to homes as a free sample. This sample came in a small packet and included an image of a lemon on it. People instantly assumed it was lemonade mix, so they mixed it with water and drank it without ever reading what it said on the packet. The organization received countless calls and complaints from potential consumers who got sick. Most of them did not read the fact that this was dishwasher soap with a new lemon scent and an added citric acid cleaning agent. Reading is either clearly overrated for the masses or a means of separating the people who want to be informed from those who are too lazy/busy to bother.
Some manufacturers do not even include instructions anymore. Why? The product or service should be easy enough and users should just want to use it. They expect user adoption magically happen with some high hopes. Maybe that works with some mobile devices and some of their respective apps through simple, smart design. Never mind the precautions, warnings or issues that could arise. What could possibly go wrong? Users are smart enough to just know how to use it, right? Well, if you add some humans to any equation, you will get some inconsistencies, variables, and yes… errors. Sure, we can blame the:
poorly designed user interface (usability testing can help identify these issues)
lack of forethought in the system implementation, so everyone must think like the person who created it (user testing can help identify these issues as long as they walk through all the processes and note what/where is a miss)
the whoops on the real world which avoids the end-to-end walk-through of a solution to be sure it works
One organization had a lot of user errors, so they started focusing on the tasks that caused the user errors and tracked them. This could identify system flaws needing correction. Here is how to start on the path of accountability. Every instance an error happened:
the user was tracked by name (who)
the type of error was tracked (what)
the frequency of the error was tracked (when)
where the issue was occurring in the system was tracked (where)
what the user did incorrectly to cause the error was tracked (why)
the recommended changes to the process were communicated and documented (how)
Every time an error happened, a template email was sent to that individual user and their supervisor which included:
their specific error
the impact of this error to other users and the system (there often was one)
a recommended fix (for the user to complete)
a set time frame to fix the error properly (one to two business days)
a follow-up to be sure it was completed and the error log to close out that particular instance of that error.
Before implementing this error correction, the policy was fully documented and shared openly. As soon as this process started, error rates dropped significantly. That is the effect of accountability. Prior to this, accountability was not visible. Note that errors do not completely disappear because “perfection” is not a realistic goal for any organization. There is room for improvement for users, processes, and likely the system.
How to have MORE errors
There are the counterpoints to all this…
Assume too much or just assume everything will work the way you expect it to (just like the world will continue to revolve around you)
Ignore all issues you encounter. Do not verbally mention nor document in writing the issues for anyone to know about.
Do not test thoroughly or just ignore all testing completely (The testing fairy is coming soon. Just don’t wake up from that dream)
Do not verify any information down the exact character. In fact, just do not check on anything at all
Do not follow specific instructions. Do not have clear, up to date instructions. In fact, do not have any instructions at all (see assumptions for similar results).
Do not have a simple, easy to use GUI. If you really try, you could skip having a GUI completely.
Ignore all usability experts and their literature. Why would you want anyone to actually use the system your company paid for?
Believe everyone works and thinks like you (revisit assumptions again)
Be sure to have extra slow processors to make people believe the system is frozen or non-functional. It might be acceptable in some people’s mind if a simple process with a few bits of data take a half-hour to two hours to yield the results requested.
Be sure to blame the end-user when the system is not working, but it is best if the results are inconsistent just for that added bonus.
Confusion is always welcome. With open arms.
Do not document anything. When working with other companies, trust everyone freely and believe that they will document everything for you, understand it all your way, and do not share this documentation openly.
Believe everything (including coding) is really easy and it will automagically be completed overnight flawlessly. Every day. With no documentation nor specifications. Nor testing.
Every IT department can read minds. They have an app for that.
Eventually, everyone can read your mind.
Trust everyone. What could possibly go wrong? You do not need any verification either.
Do not plan ahead.
Do not train users. Ok, maybe once and believe they will remember it all.
Do not supply any ongoing support for your user community. They will figure it out.
Errors go away if you ignore them enough. Errors do not multiply when you do this. Errors are so much fun. Dream of getting more over time and it will happen in reality.
Another DAM Blog 