8 Things You Need to Know to Build an ECM Strategy

Without commitment, there’s no point in moving forward.

In my opinion, the single most critical element in building an Enterprise Content Management (ECM) strategy is commitment. I’m talking about the type of commitment you make when you jump out of a plane. Not that I’m suggesting ECM is like skydiving; if skydiving goes wrong, the pain doesn’t last.

Commitment can’t be limited to a select few within the organization. For sure, the senior leadership team needs to demonstrate its commitment, but commitment needs to be present throughout the organization. Consider this: regardless of how committed the senior leadership team is, if the rank and file don’t buy in failure is guaranteed.

So how do you get commitment? Find out what resonates and build from there. Is the motivator risk mitigation, environmental responsibility, competitive advantage, or access to information? The likely scenario is that the motivator changes depending on whom you’re talking to. Your job is to sell the program to your stakeholders on their terms, not yours.

Plan strategically, execute tactically.

You can’t eat an elephant in one bite; start at the trunk and work your way to the other end. And no, you cannot avoid the nasty bits.

Since you can’t implement everything in one shot, you must plan the execution logically. When defining the plan, aim to reduce rework, reduce risk, leverage previous successes, and minimize dead time. Break your implementation into short, medium, and long-term time boxes. Adopt an iterative approach that incrementally builds out more and more of the strategy. Choose iterations that make sense in your organization: by business unit, by process, by location, and by function.

Accept that the tactics you employ will likely change over time. That’s okay as long as you’re always moving toward meeting the strategic objectives.

Communicate, communicate, communicate. Then communicate some more.

Some surprises are good – like finding $20 in your jacket pocket. Showing up at the office one day to find that you now have to get with an ECM program – not so much.

Communication needs to start when the implementation of an ECM Strategy is at the concept change. This does not mean that you tell everyone everything all the time -- you don’t. As the implementation progresses, the audience expands, the frequency of communication increases, you add more channels to the mix, and the story becomes more compelling. It’s kind of like announcing a pregnancy – initially, only a small number of the affected stakeholders are in the loop. As the delivery approaches, more and more people are informed (how else do you ensure all those gifts?).

One day far into the future, you will have implemented your Enterprise Content Management strategy, but you still have to communicate! The nature of the communication will change. It won’t be about what’s coming; it will be about how to nurture what you have and continually improve upon it.

It’s a marathon, not a sprint.

Developing an ECM strategy is like renovating your house; it seems like a good idea when you start, but 11 years later, you’re not so sure (‘cause if you’re like me, you still haven’t finished). However, unlike my house renovations, I’m certain that an ECM strategy is a good idea.

This is really about getting folks to adopt a “program” mindset. Unlike a project (sprint) -- which has an end -- an ECM program (marathon) has no end until your organization “operationalizes” ECM. By that, I mean that the core habits of how business is conducted have changed to the degree that Enterprise Content Management practices are simply a part of your Standard Operating Procedures.

Of course, there are sprints within the marathon. These would be the numerous projects that occur to develop the strategy, develop governance models, inventory the content, deploy the solution, and on, and on. Just like a good general contractor engages the tradespeople to hasten progress, a good ECM program manager engages the right resources at the correct times.

Define KPIs, then measure them.

When you’re developing your overall ECM program and strategy, define the KPIs you’ll be using to determine if you’re meeting objectives. Properly defined metrics prove success, indicate danger, and help identify adjustments; they’re essential when you need to respond to the question “how are we doing?” Keep three things in mind when developing KPIs: 1) they must be directly related to, or supportive of, organizational objectives; 2) they must be realistic, and 3) they must be actionable.

Great! We’ve got a bunch of KPIs defined. Now what? Uhm, measure them. KPIs are like any other tool; if you don’t use them, they’re no good to anyone. Put a plan in place to measure KPIs on a regular schedule. Think of it as a maintenance schedule for a really, really expensive car.

Allow ramp up time. Rome wasn’t built in a day; neither did we reduce internal email volume by 50% in the first quarter after go-live.

Stakeholder engagement is critical.

A stakeholder is any person, group, organization, or system that affects or can be affected by your efforts. Within the context of an implementation, stakeholders break down into participants (active role) and non-participants (passive role).

Stakeholder participation is not optional. This does not mean that all stakeholders have an active, hands-on role. It means that you need to find appropriate avenues of engagement, such as focus groups, newsletters, lunch and learns, etc.

Identify stakeholders early and engage them appropriately. Don’t assign a customer or vendor to a security or taxonomy working group – this just doesn’t make sense.

When assigning people to ECM projects, don’t expect them to be able to meet their project and operational responsibilities as if nothing has changed. It’s not realistic. Project work requires a different mindset than daily operational work.

“Suck it up, buttercup” is not a change management plan.

While “suck it up, buttercup” may be my mantra in terms of change management, it’s probably not the best approach to take (though I’ve seen it work in a couple of private sector organizations). Change management is critically important when you’re implementing an Enterprise Content Management strategy. Remember that the way that people do their jobs is going to undergo fundamental change. There are two basic streams of change management: 1) People change, and 2) Process change.

People change deals with the human element of change. People in the organization are going to be asked to take on new roles and responsibilities. In some cases, people are going to take on entirely new jobs or -- it’s harsh, but it happens -- they are going to lose their jobs. Understandably they are going to be resentful, reluctant, resistant, and afraid.

Address these issues by using the Four Cornerstones of Change (there are also Four Horsemen of the Apocalypse, but that’s probably just a coincidence):

1. Communication – see #3
2. Education – training is great, but it’s mechanical and doesn’t inform people of why they’re being asked to do something. Real education engages the individual by articulating why they’re doing something, how they impact their colleagues, and how they contribute to personal and organizational success. Education, properly executed, provides a sense of teamwork and ownership.
3. Participation – see #6
4. Support – it’s more than just a 1-800-HOLY-COW hotline. Support means being aware that people are going to need time to get up to speed. Support means putting expert assistance in place at the local level – Centres of Excellence. Support means encouragement from program sponsors.

Process change deals with how an organization conducts its business. Process change involves minutely examining end-to-end business processes, eliminating inefficiency, and monitoring for performance. Internal and external factors are the genesis of change. Take advantage of these opportunities to make your organization smarter, faster, leaner, and more profitable.

It’s not all about the technology.

Most of the ECM products in Gartner’s Magic Quadrant do pretty much the same thing. The differences are in how they do what they do and what type of infrastructure you need to run them. Are you a .NET shop or a java shop? Windows or Unix? It’s been my experience that the technology decision is typically the easiest to make; therefore, it’s made far too early in the timeline.

Long before you start thinking about making a technology decision, you need to have a governance framework in place; you need to have new business processes ready to go; you need to be managing change; you need to be communicating. Put simply, your strategy roadmap needs to be in place, and you need to be executing much of it. Think of it like this: before the pizza goes in the oven, the ingredients have been gathered and assembled in the correct order. Who makes a pizza with the cheese on the bottom and the sauce on top?

Back in the day, an instructor of mine provided what I think is an excellent definition of a system: a system is the people, processes, and tools that work together to achieve objectives. If you accept this definition, then it follows that technology, while not unimportant, is the last variable to be addressed -- sort out the people and processes first.