A Discussion about Content

This week I had an opportunity to visit one of my favorite customers.  Not because they are easy to deal with, not because they are nice guys,  but because they are fair, willing to work through issues, and it is still a place where a handshake means something.

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

In the midst of the a client crisis the best thing to do is keep your cool.  One of my many roles has been the escalation point for my clients.  Perhaps it is the fact that i just don’t get emotional and can deal with the facts.  Perhaps it is my experience having been a client for so many years that the empathy comes naturally.  What ever the reason, let me give some tips on how to deal with an escalation.

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

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

Unfortunately the twitter account enterprisecm, is not working properly. It wasn’t working with hash tags ‘#’ and no one could find it.  So I’ve switched to my original account known as “timfives”  please feel free to follow me using that account.

Tim

There is a myth among IT leadership that goes something like this.  We’ve spent millions on software, and we have an enterprise solution.  Only to find out that what they’ve done is to build silo’s around their information, and yes their million+ dollar investment has only replaced organizations shared drives.

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

This is a great discussion regarding the evolution of media.

Enjoy

Tim

Program Management. Its utterance often brings disdain from those who just don’t comprehend what it means.

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.

Best Practices is there such a thing?  At the end of the day there is, but it isn’t always what you want them to be.   Many of my clients look at Best Practices as the silver bullet.  They expect a plethora of best practices to be immedatly implementable, and for us to come and go in a flash.  Is this reality or a far flung dance with the devil?

When implementing ECM there are best practices, there are repeatable processes  and frameworks from which to start.  However these what I am seeing is that most of the time the Best Practices or (BP’s) as i’ll refer to the them are abondonded in favor of rapid deployments.  Of these many fail outright or at a minumum fail to achive the goals set out at the onset of the project.

When I look at any ECM deployment I am looking at a program not a project.  When you make that differenation you realize that to successfully implement Enterprise Content Management across an organization, there are many facets to consider to ensure success.  A typical list would include, but is not limited to the following area’s to consider when defining an ECM program:

• Program Management
• Change Management
• Anayltics and Design
• Taxonomy and Metadata
• Development / Configuration
• Testing
• Deployment
• Support

The point is simple, ECM deployments are multi-faceted.  There are far more criteria to invovle than the implementation of a simple application development project.

This series will drive into the deapth of these areas showing examples of where I have see programs succeed, and where I have seen them fail.

TF

What is the ROI for implementing enterprise content management?   I can’t tell you how many times I get that question when discussing ECM.  ” is there really that much that can be saved by implementing an Enterprise ECM solution?”  Personally if your still searching for why is it important, then perhaps you should go pick up a FORTRAN book and figure out how to leverage that language to write web pages, but i digress.

Lets make the assumption, the you intrinsicly understand the value of ECM,  but are struggling to figure out how to quantify the value.

There really are two camps to this thought, 1.  those that want to quantify an ROI that addresses current problems and 2. those that like to understand how ECM can differentiate them from their competition.

1.

To measure the effects of any implementation albeit ECM, CRM  or ERP  there are tangible ways to measure the value found by that implementation.  To do this, all you need to do, is tie the improved business processes to a desired output, and then measure to see if that output improves. I know sounds simple, but most companies don’t do it properly.  Further they generally tie broad goals to implementations, and when those goals don’t get met, then some executive is out looking for work.  (I’m sure you’ve seen this)

With any ROI exercise, it is about setting the right expectations, being able to track and communicate, and most importantly adopting and changing to ensure a return.

Since this topic is so near and dear to me, tune in for future posts regarding how to measure ROI in this parigdim.

2.

Using ECM as a game changer.  Done correctly ECM is by far and away a great tool for leap frogging your competition.  The problem is that most companies haven’t figured that out yet, but they still struggle with the same problems.  It is like chronic back pain, they can never seem to get relief, thus they have become numb to the pain.

Broad items like compliance, and file system storage, or email retention, all point to that chronic pain.  Most vendors focus on the technology to fix these issues in isolation, but very few have a cohesive plan that solves Enterprise Content Management.  Thus it is left up to the company to define the problems, identify the solutions, and execute on them.

When asking yourself the question how can I leverage a Document / Content management tool to its fullest extent?  I suggest you look forward, look at where you want to be in 2-5 years, and start to see how unifying your unstructured information across your enterprise will get you there.

While many great blogs and experts, focus on the tools, and the technology I am intent to focus on the big picture.  How do you go and solve these large problems?  ECM is a game changer for your company. I’ve personally witnessed this, and continue to work to this end.  This blog will continue to establish best practices in an industry where they are few are far between, and help people establish how to get the most out of their ECM deployments.

TF

In an effort to ensure success you always need to be looking forward, or at least someone does. Failure often creeps in when the strategic vision becomes stale, or out-dated.

“It is true that it takes energy and enthusiasm to continue to be a visionary, to look forward, and continue to be successful.” TF

I’ve seen many people do good things, only to rest on their laurels and skate for a couple of years. The one day they wake up and say “i’m in a whole world of hurt, how did this happen,??”

Vision includes looking at not just potential solutions and pie in the sky ideas, but more to the point of problem avoidance.

You should also be careful on how you define success, generally it is tied to / when the vision has been accomplished, but this can often be hollow, as your vision should continue to evolve.