Change Management – (Best Practices)

June 19th, 2009 | Categories: Best Practices, ECM, Management, communication, leadership | Tags:

In this best practice segment I’d like to discuss the importance of a robust change management plan.  As I’ve mentioned in previous posts that the implementation of an ECM platform needs to be treated as program.   I may also have to correct myself in that earlier  post I felt that project management is the first thing to be cut in the implementation of an Enterprise Content Management solution.  In thinking about it even more, that was true, because generally no one takes Change Management into consideration, thus if it isn’t budgeted for it can’t be cut.

Concept: If your investing in a software platform, you need to ask yourself why?  In general terms its because you want to find some efficiency someplace in your organization.  If your going to improve the efficiency of a process, that means you will need to change that process.  If you change that process that means your going to change how people work.

It is a fact that humans are creatures of habit. Even if a process they use today, is inefficient, cumbersome, and plan out stupid.  They will fight you if you try and force them to change.

Reasons people resist change:

  • Ownership
  • Pride
  • Scared
  • Security

Bottom line is that if a person or a group of people know a certain process there is a sense of security in knowing that, 99% of the time when they get told a new system is being implemented, they fear for their jobs.  This is especially true now given our current economic situation.

Also don’t forget that someone created the existing process, if you barge in with a new one, they again are more than likely have a negative emotional reaction.  They will think your attacking them, putting them down, and again threatening them.  The reality is, that the process your effecting was put in place with antiquated tools, and its inefficiencies are due to other environmental factors.  Meaning that the did the best they could with what they had to work with.

Case and Point:

When I was deploying documentum for a large fortune 500 company, I was in charge of their entire ECM program.  In the early days of the program I was so focused on the deployment and the development that I too made the critical mistake of ignoring change management.  Sure we collected requirements, fields for the forms, people for the workflows, and defined a robust security model.  When we got done everyone was proud of themselves, right up until we took it to the business, where they flat out rejected it.

Sure at the time the technology wasn’t elegant, so usability was a concern, but the reaction I got from the users was volatile.

Mistake 1.  Didn’t involve them in prototyping: Had we involved them in the design and development stage they would have understood how the new process would have worked, and could have provided us feedback along the way, as to why some of the design elements wouldn’t work.  It would have cultivated the relationship, they would have felt ownership, and would have gone along way to lead them through the change.

Mistake 2. Failed to convey the value of leveraging the solution: This was something that I thought they would just get. “Is the why we are doing this?”  I thought the value to the organization would be obvious, but it wasn’t. Once we started to explain the value, not only for their group, but for the other groups leveraging the content downstream (i.e. via our integration to SAP), only then did they get a sense for the importance of this implementation.

Mistake 3. Didn’t assuage FTE Reduction fears: This was something we worked with their management, to show just how these improvements would allow them to work on far more value add tasks within their department.

The key to turning this around was a rapid adaptation to the situation,  We worked with them and immediately got them involved in the rework, which  turned out to be a minor revision of the system, I worked with the management team to communicate that their jobs were safe, and that they could now focus on other important items within their department, and while doing both of those we started to reinforce the overall importance of the solution.

This example represent just one business process.  You can get an idea of just how important it is to have a change management plan in place if your effecting several groups simultaneously.

The deployment of ECM is truly where the Business and IT intersect.  Be sure to have a plan to include them during the design,  articulate the value, and most of all communicate!

Tim

  • Matt
    I worked in publishing as an editor for 19 years, and was involved in a number of ECM implementations. The trick with publishing was that content was the lifeblood of the organization, but most of the tech vendors just did not GET this. They treated our content just like any other content in any other business: healthcare, accounting, legal. They didn't realize our content was a living, breathing thing that needed to be handled as such. They just looked at our content as various files.

    My point here is that tech vendors fall down because they fail to involve end users at the very inception of change management. If, as a tech vendor, you are making a presentation to a prospect and your only talking to the IT execs, stop the meeting and ask for end users in the business group to be involved. Get their input immediately and up front. I cannot tell you how many times I went into a meeting with a tech vendor and asked them to automate a certain process only to be told, "We can't do that. Your tech guys purchased the X version of our software, which doesn't have that capability. Maybe in the next rev, or for a fee we can customize it for you in 8 weeks." Argh.
  • timfives
    Matt,

    Welcome to the blog. Your insight is exactly the problem, This is not a focus of technology, it is the application of that technology to solve a business problem, improve a business process or the like.

    Without representation from the business during the analysis phase, I have yet seen one of these projects be successful. It is also when the change management starts, you can not start the change management process after the project is completed.

    Great insights! Thanks!

    Tim
blog comments powered by Disqus