• A couple of items that i’ve taken from travels is that truly ECM is becoming commodity.
• Service Business are suffering where there is no clear articulation of value.
• Emerging Technologies have a long road to haul if they can’t marry themselves with business value.

Over the next couple of posts, I’ll be exploring this commodity phenomena of Enterprise Content Management, and the impact that is having on ECM Companies.

For this morning it is nice to be taking some moments to think.

T

Perhaps it is the size, we all understand that small organizations can turn on a dime, can adopt new strategies faster, and generically understand how to leverage technology to meet their needs.  Perhaps it is out of necessity that small organizations can do this.

The only hope that large organizations have are:

1.  Leadership that is infused with visionaries.

2. Understanding what small changes can have appreciable impacts.

Sure the first is obvious, someone in any organization needs to make a decision that ECM or any software for that matter can make a difference.  Almost to the extent that it could be a game changer.  Second, well it is rare that sizable organization take on a fundamental change, implement new strategies, or entirely change direction.  More to the point it is about making subtle changes that have significant impact.  Thus implementing a cohesive strategy one little change at a time.

T

I’ve been traveling to a variety of clients and it amazes me the ones who demand a strategy and those who just want to rush straight into deployment.

Oh yes before you say it, there is the execution of the strategy…  but lets start small.

I had a client last week tell me that they need to get started, that they have to have something to show ASAP.  That users need to be using the system. They wanted quotes and timetables for the implementation.  Sometimes you can reign these clients in,  sometimes you can’t.

In this instance they wanted to implement a global solution, going across their organization deploying ECM, WCM, and integrations to SAP, and other software.  They had no concept of business process re-engineering.  They admitted that their existing solution suffered from a lack of preparation, and couldn’t see that they were repeating themselves.

After point that out, and asking them what would define success in three years, (of which they couldn’t answer) we got them to commit to doing some proper planning, and we are now laying out a strategy.  We got them to take a look at what defines success.  In this case how can they leverage their ECM solution to differentiate themselves from their competition, defining tangible ROI, and how it will position them to open new markets!  This is why I do this.

My other case and point was a government agency that came to us and said.  We have budget (who in government doesn’t??  i suppose California may not but I’ll leave that for another discussion)

This agency CIO and I met to discuss what they need and how to go about it.  During the meeting the CIO said, treat us like Neophytes we have no idea how to do this right, she was convinced that she could do it wrong.  We talked in depth about planning, and how this would transform the agency over the next several years.  We talked about how and what they would get out of our planning sessions.

Bad or No Plans = failure..

It isn’t rocket science  you must understand why you are undertaking the effort, you need to understand  how your going to define success in the long run.  Did  you know that CIO have an average lifespan at a company of only 18 months..   Think of how hard it will be to explain why your doing a multi-million dollar implementation to a new CIO with the goal of saving your job.

Think about your success, plan for it, then execute.  Failure to think and plan will end in failure.

Ready Aim Fire  = Think Plan Execute.   So many companies are getting it wrong.

On this occasion I had the opportunity to sit in with a bunch of executives as my colleagues articulated a  solution that was near and dear to my heart. It has been almost 5 years since I had deployed this solution, and for me it was sort of an awakening.  As the presentation progressed, a flood of memories came rushing back, almost as if I was transported back in time to some of my own integration meetings. 

It was also odd that the technology, while improving, hadn’t substantially changed all that much.  Fundamental concepts remained true, and the proverbial how wasn’t as important as to WHY they needed this.

The client team, conceptually got the message. Archiving off the transactional content, would save their ERP system from running out of space, help with performance etc.

It wasn’t untill I noncholatly articulated why we did it at my previous company and the value it brought. That the truly got it.  WHY does this add value?  WHY should you invest the time, energy and money. 

The challenges with companies like mine, is that everyone is so enthralled with how things work, with how the technology can make things easier and better, that they have a hard time translating that to business benefits.    To be fair, you need both, people like me that can articulate the business benefits, how the technology will improve bottom line performance, and those fantastic technologist that can make it work. 

Yes indeed it was a good week!

Tim

1. Focus on the solution: The moment you get the frustrated, irate, or irrational client on the other end of the phone, your primary mission is to get it resolved.  Don’t get into the blame game at that moment.  I can’t tell you how many times I have seen people go directly into blaming a 3rd party, the client, the consultant or whom ever, just to wash their hands of the problem. Fact is this figure out what the problem is, deal with the solution, and worry about laying the responsibility of it on someone, once you have the facts, and the crisis is over.  99.9% of the time there are mulitple responsible parties for the issue.

2.Facts, you must deal with facts: when a client is spewing venom at you for screwing up, missing a dead line, deleting a vital file, or taking his daughter to a rave.  you need to be clear on the facts. I personally like to develop a time line, it makes articulating the facts into an emotionaless event. It also helps to isolate the issues in questions, and the decisions that lead up to critical issue at hand.

3. Documentation: This is key, especially when there is generally a monetary settlement.  Detailed meeting minutes, and status reports, are critical for articulating the facts, it keeps the he said she said out of it.

The best advise I can give, is stay calm, don’t engage in harsh words, or even raise your voice.  If someone is screaming, frustrate and lashing out, be the punching bag, tell them your the guy to solve it, and that your going to bring ever resource to bear to the problem.

Once you’ve hung up the phone, don’t be a hero, get help.  Escalate to your management they are going to want to hear about the problem from you before they hear about it from the client.

Bring multiple heads together to get the solution.  Many people working on a problem can generally fix it faster than one person.

Keep your eye on the prize: I can’t tell you how many times that I see people trying to fix the wrong issue, or multiple issues.  Focus on the task at hand.  I had a team that was trying to fix an XML publish issue, and they decided to also fix some formatting issues.  NO! Fix the critical issue, you can always go back later to find other issues.

Prioritize: When a client comes to you with a list of issues, you need to prioritize them, determine the most critical issues, (with the client) and tackle  them first.

Communicate:  Establish a regular communication plan.  If it is impacting a production environment, you may have to give updates 2 to 3 or even 4 times a day.  In these instance you can’t communicate enough, not communicating is the fastest way to exacerbate a client.

Plan: Develop a plan of attack with your team,  It helps with the communication to the client, it shows structure and competence when you have a plan.  Even if you succeed, you can point to the action taken, and then if necessary you can move forward with a new plan.

Tim

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

Tim

I see this a lot, with companies  I work with have an established ECM platform, and are not getting any appreciable value out of it.  The question is simply why.

Many of the issues that they suffer from are:

• Finding their information
• Duplicate Copies
• Managing Records
• Low end user adoption

All of these concepts go back to the fundamentals.  How do you expect to gain value from your ECM deployment?  Many companies go forward without a strategy, heck they can’t even articulate what success is.  When you haven’t defined your success criteria, what happens is your ECM “program” becomes a cost center, and is extremely hard to justify its value.

This industry is full of technologist selling and marketing fantastic software.  They can hype the software to such heights, only to leave the company who just paid through the nose, to figure out how it dovetails into their business strategy.

I’ve stated before that the implementation of ECM is a program, it is not a project.  There needs to be a clearly articulated vision, there needs to be plans and road-maps that show the progression of the program, and can be used to measure the success of program along the journey.

Tim

Enjoy

Tim

Often when you look at large projects the first thing that gets cut is the project management costs, only to find out later that the project has come of the rails, the first thing they do is blame the poor sap who has 4 jobs plus 1/8th of his time dedicated to the project management responsibilities of the ECM project only to  fire him, and replace him with 1/8 of an new FTE, all in hopes that the project will magically be brought back on track.

What I find so darn interesting, is that companies will spend millions on ECM software, but won’t invest in the management to ensure its success. I mean if your going to spend that much on the software why cut corners on the implementation?

The follow table from Doculabs articulates this in the percentage of management spend vs. the percentage of failure.

Project Management Spend as a % of total Budget - Doculabs

Interesting that when a company spends 3% of the total project budget on management the failure rate is 50% but when you raise the investment in management to 10% the failure rate drops to 10%.

Executives, really need to ask themselves when embarking on the implementation of an ECM platform do I want to be successful.  (We will discuss success in later posts)

I’ve mentioned it before but the implementation of an ECM platform needs to be considered a Program.  There are far to many facets for an implementation to be handled like a single threaded development project.

When you deploy a solution for the enterprise, you will have more work than you will know what to do with.  As an example from my days at York International where I deployed Documentum across the enterprise, one of the factors that struck me was the number of project request I received in a given day.  One of the first things that had to be implemented was a demand planning solution to help prioritize and manage the expectations of the various business units whom were requesting projects.

Then there is the infrastructure management, the upgrade planning, the various system integrations, the unit testing and the support.

Also there was the actual requirements gathering for the various projects,  multiple work streams needed to be managed, development environments needed to be managed, along with staging and obviously production.

Case and Point:

How do you manage like project requests? This is always an interesting discussion. So let me tell you a little story.  I was consulting for a huge firm not so long ago where I was preparing a road-map vision for them.  During the interviews of the business units what i found was several of the business units had the same exact problem.  In this case it was the management of contracts and related collateral.  Sales needed them, Consulting needed them, Legal needed them, purchasing needed them, and on and on.  Now when you stand at arms length from the company you see that you can solve this with a single solution.  However when your up close and personal you realize that each of those business units was funding a project to manage contracts independently of the other departments.  In this case it would have meant 6 different projects, probably 3 different technology solutions, and none of them would have been to inter-operate between the other departments.

There are many things that this example illustrates, but for the sake of this post, had the customer not had the foresight to implement the proper program management and project planning events, this would have gone unnoticed and the company would have incurred a significant cost.

Fundamentally setting up a program management solution is paramount to the successful implementation of ECM.  Setting up a Center of Excellence (COE) or a dedicated PMO for these implementation vastly improves the odds of success.