Another DAM Blog

Blog about Digital Asset Management

Tag Archives: change management


by 1 Comment

How do I address user error?

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 explain how nor why something works nor even IF it actually works. People are just supposed to know this simply by osmosis or being born with this information.
  • 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.
  • Never take any vacation nor breaks. It will not catch up with you in any way.

I only wish these were all so ridiculous that these did not ever happen nor were even thought of. Sadly, they actually do. Too often.

How do you address user error?


by 1 Comment

Top 40 blog posts from 2009 through 2012

After four years of blogging about Digital Asset Management (DAM), I keep reporting what are the most popular blog posts based on the number of times people have clicked to read a blog post. The top 40 most read blog posts from Another DAM blog for the past four years (2009-2012) are…

      1. Why do I need a Digital Asset Manager?
      2. Where can I find some DAM jobs?
      3. What is the best DAM solution?
      4. Why do I need a DAM?
      5. Where can I find metadata standards?
      6. Have I heard all the DAM jokes yet?
      7. How do I avoid duplicate assets in a DAM?
      8. Why do I need metadata?
      9. How do I plan for a career in DAM?
      10. How do I read this DAM documentation?
      11. How do I enforce a file naming convention?
      12. How can I measure DAM progress?
      13. What are the levels of DAM experience?
      14. How do I create use cases for DAM?
      15. How do I explain what I do for a living with DAM?
      16. How much do Digital Asset Management professionals earn?
      17. What specific skills should Digital Asset Management professionals have today?
      18. How can I bring more ROI to our DAM?
      19. Why should we keep our assets in a DAM?
      20. What higher education courses are available about DAM?
      21. What does DAM have to do with change management?
      22. How can I use DAM to assist with preliminary research?
      23. Who can do my keywording and scanning?
      24. Where can I find a DAM mentor?
      25. Can a DAM handle Rights Managed assets?
      26. Who should be on a DAM project team?
      27. What is a DAM Award?
      28. Top ten most listened to DAM podcasts of 2010
      29. Why does a DAM need an API?
      30. How many DAM metadata fields do you have?
      31. What do you know about your integrator?
      32. Top 10 podcasts about Digital Asset Management: Another DAM podcast from 2011
      33. How long does it take to get a DAM working within an organization?
      34. DAM predictions for 2011
      35. What is the DAM Foundation?
      36. What is Digital Asset Management (DAM)?
      37. What is a DAM Conference?
      38. What does a Digital Asset Manager need to know?
      39. Why do I need unique logins per DAM user?
      40. How do people talk about DAM within an organization?

While I was posting far less often in 2012 (new supply few times a month), the readership (demand) has only increased year over year. This is yet another sign that Digital Asset Management is still growing. Some say the DAM market will surpass the billion dollar mark in 2013. Most of the blog posts listed above are still very relevant to people’s need for more DAM information today.

A few people and even some companies (whom I have not worked with) actually asked me to stop blogging because I am “…giving too much away…” so I simply keep posting more. Why? Because this is not true. For those who have read my blog posts, I list the questions you should be asking within your organization about Digital Asset Management.

Now I have listed the top 40 most read blog posts from the past four years out of over 155 blog posts to date. I still have over 95 drafted blog posts yet to finish and release when I have free time. I know who my audience is because they communicate with me directly and they suggest ideas for posts. DAM is not about sharing less, otherwise you are missing the point about sharing with your:

  • Users
  • Groups
  • Departments
  • Organization
  • Community
  • Audience

I am not the only DAM blogger. In fact, I am Another DAM blogger and there are thousands of DAM blog readers out there just like you. What are your favorite blog posts from Another DAM blog?

Let us know when you are ready for some vendor neutral consulting on Digital Asset Management.

Related Articles

 


by 2 Comments

What does DAM have to do with change management?

While I could blog about change management on the asset level, I will reserve that for a future blog post. I want to take a more global perspective of the change management involved with the implementation and operation of a Digital Asset Management (DAM) solution….within an organization.

Just like many projects today, as soon as we begin implementing and operating a DAM within an organization, we often need to deal with people, process, and technology changes.

So let us say we want a DAM within an organization. Now what?

• Install, declare “we have a DAM” and walk away?
• Someone else will volunteer to do this, right?
• Buy a DAM, upload some stuff, expect people to use it (somehow) and that’s it, ain’t it?

No. Back up unless you want another solution to collect dust (aka shelf baby)

There is a fundamental shift which needs to occur within the organization as soon as we realize we need to implement a DAM, where we will need to deal with changes to:

  1. People
  2. Process
  3. Technology

This involves turning a DAM system into a real DAM solution. If we don’t have all three involved and working together, this will not work properly.

  • If the people don’t use it, the system becomes a ‘shelf baby’.
  • If there is no process (established and documented in writing), how are people supposed know what to do with the system? People are not born with this knowledge.
  • If there is no DAM system, the people do not have the technology to manage digital assets throughout an organization. There is no sense pretending you have DAM process if you have no established DAM solution, unless you have a fantasy organization. One would hope we treat our organizations like a business rather than a playground.

Implementing a DAM solution can help resolve many of the bad habits (as described in the twenty point of my first post) when it comes to dealing with the organization’s digital assets.

Digital assets are not going away anytime soon.

Change management can also involve expectation management.

Status quo is no longer an acceptable way of business, regardless of the economy.  No sense in sitting on our laurels because we did something a while ago. What have you done lately? Many organizations lose control (and market share) by resisting change and failing to adapt.

It is your choice to adapt in one of three ways:

  • a proactive manner
  • a reactive manner
  • Ignore it and hope it will go away…like mobile phones and computers (this is the best way to become a dinosaur)

What could this change with a DAM solution look like?

For people, this may involve…

Before Change• Closed environments

• Isolated

• Lacking communication

• Slow delivery

• Localized thinking and action

• Coveting “MY” assets

• “MY” budget

• Endless meetings

• Fear of loosing control

• Already ‘know it all’

 After Change• Open environment

• Collaborative

• Easier communication

• Rapid delivery

• Globalized thinking and action

• Sharing OUR assets

• Chargeback for use across organization

• Fewer meetings using DAM light boxes

• Empowering by engaging and sharing

• Willing to learn new things regularly

For those of us actively using social media, this may already sound familiar. The mindset of “my” assets vs. “our” assets is similar to sharing. After all, if we work for an organization, what we create (e.g. digital assets) while working for the organization is often owned by the organization, so those are in fact “OUR” assets, not “MY” assets. Sharing is good. Otherwise, no one knows these assets exist, even within an organization.

As for process, this may involve…

Before Change

• Pick the cheapest technology available, then find out how to we can conform to the technology’s needs

• Fragmented training with inadequate  documentation presented once

• Individualized view of workflow

• Difficult to budget projects

• Difficult and time-consuming to find assets

• “I don’t know where it is”

• Liability to reuse

• Rights and permissions unknown

• Subjective process

 After Change

• Pick technology which meets our business needs first, then budget for it

• Training with supporting documentation available online

• Standardized and documented workflow based on roles

• Easily report projections for budget per project

• Easily and quickly found assets

• Quickly know what we have available

• Easier to reuse, due to documentation on a per asset level

• Rights and permissions easily accessible and legible

• Objective process

As for technology, this may involve…

Before Change

• We conform to technology

• Unknown duplication of assets

• Different applications and versions of software per employee

• Limited threshold

• Obsolete=time to update

• Coveted technology within a department

 After Change

• Technology conforms to our business needs

• Reduce duplication of assets (via check sums)

• Uniformed sets of applications and versions of software per role

• Scalable threshold

• Regularly scheduled updates

• Technology used across departments throughout organization

How do we manage change?

To paraphase Peter Drucker, we can not manage change if we do not measure the change, find out what is improving and what still needs improvement.  When you have a DAM (and use it), run reports from the DAM regularly (yearly, quarterly, monthly, weekly or more enough if needed). Filter reports and analyze for same factors regularly, measuring the results for each factor. Establish metrics or common measures to use as reference. If results are not steadily improving on a regular basis, analyze why. The reports are black and white (purely objective), but the analysis may be gray (subjective) if you do not establish documented metrics.

  • How many users are using the DAM? How often?
  • How many assets are in DAM?
  • How many assets get uploaded to the DAM (per week/month/year)?
  • How many assets are being used (per week/month/year)?
  • How many asset are being reused? How many times?

What about management issues?

  • We can evaluate employee competencies by running reports and analyzing each individual users’ results as well as group results on a regular basis in order for them to have an objective measure of exactly what can be improved.
  • Technical competencies are a must within each role and function, but training is often needed to keep up-to-date with new software versions, so budget the time for employee training. Train with written documentation for workflows. What is different from before? Be clear where questions can be directed to.
  • Weigh the option of a weekly report over a weekly meeting with management. Live 360 degree feedback and candor can be very valuable during times of change (which are more frequent nowadays). Some of the best feedback may come on a individual basis rather than as a group, depending on personalities and comfort level.
  • Not everyone will embrace nor accept changes overnight. Recognize the issues by listening and find a resolution in order to increase user adoption.
  • Sometimes, individuals may not be suited for this type of work and may need to reassigned (or sometimes even shown the door), if:
    • They are unwilling to change with the organization
    • They demonstrate being a hindrance to results
    • Regularly fail to meet the objectives in a timely manner when given adequate support
  • If needed, find the links between the DAM reported results per user,
    measure their individual ROI and add it as another objective factor in the performance reviews for every DAM user.
  • Management as well as stakeholders should be proponents and be model examples to changes.

How do we apply change management?

  • Awareness – why is the change needed (document issues and feedback)
  • Desire – to support and participate in the change (involvement and leadership is needed)
  • Knowledge – of how to change (plan, document, train and share)
  • Ability – to implement new skills and behaviors along with time and budget needed (provide training with documentation and have continued support available)
  • Reinforcement – to sustain the change (provide support, reports and governance)
  • Acknowledgement – recognize top performers within their roles regularly. Point out their key successes and results as goals for others

Charles Darwin said, “In the struggle for survival, the fittest win out at the expense of their rivals because they succeed in adapting themselves best to their environment.” In this context, it is not the strongest who survive, but rather ones who best adapt to change.

Let us know when you are ready for some vendor neutral consulting on Digital Asset Management.

How do you manage change and DAM in your organization?