Blogs

I’ll be speaking at AIIM 2012 (San Francisco. March 20-22.) Part of what I’ll be talking about during my session has to do with changing behavior. Below is a little insight into that session; “Expand, Unlearn, and Ignore” on Wednesday, March 21 at 11:30 a.m.

Like what you see? Check out my presentation (and the others) at www.aiimconference.com; and register today, I hope to meet you in San Francisco.

Long ago, I wrote about the fact that my boss expects me to be an agent of change. It’s a challenging demand, and it certainly isn’t one I am comfortable with. I prefer building solutions in response to user requests; I do that in my systems development role. ECM is like Bizzaro World development, we are often building solutions and then trying to convince people that they should see the requirements being met by those solutions. I’m no expert, but I have compiled a list of things to consider if you’re trying to change behavior:

What Behavior Are You Changing – That seems obvious, but it’s easy to focus on conditions rather than behavior. In a recent project of ours, we wanted to change the destination for reports from a shared network drive to a document library in SharePoint. That’s a result, not behavior. The reason documents were in that folder is because it was department policy. That folder was identified in procedures, and it was part of the department training for new employees. You can’t “convince” people to change their behavior when they see their actions as being in compliance with policy.

Why Is the Behavior You Want to Change Accepted by Others – This is the question you need to ask, when the question in your head is “why can’t they see the benefit to this solution?” For example, we saw that people were using old documents to begin new reports, but we want them to start new reports from a current template. The benefits of using the new template are clear and include being assured of having the correct contact information for our company, having our correct logo, positioned properly and having the document prepared in the style we now accept as standard. Nobody disagrees with these benefits, but by using an old document, they gain access to a cache of information about the report recipient. Knowing why they want to start with the old document, gives us a new requirement to focus on.

Is Your Solution Balanced – In meeting your requirements, are you asking Person-A to do additional work that seemingly only benefits Person-B? This disparity often occurs with the collection of metadata. We ask a subject matter expert to set multiple required metadata columns that he/she will never need to find the report they wrote. Ask yourself if you need all that metadata; perhaps some of it could be generated by a workflow, or gleaned from another context. Ask yourself what benefit you are giving that SME in return.

Changing behavior starts with understanding that requirements belong to the company, but the behavior you want to change is personal. That’s a critical difference that was pointed out to me a long time ago, and one that I try not to forget.