Real Story Group. Make Better Technology Decisions.

Tony Byrne

Follow Tony on Twitter @TonyByrne

The challenge of change

29-Jun-2007

Tags: Document Management (ECM), Portals and Content Integration, Web Content Management, Implementation

The Spring 2007 content technology conference circuit finally wound down earlier this month. I really enjoy the interaction with technology customers and consultants, and had some wide-ranging conversations around various buffets. But the ghost at every conference banquet is "change management." Most technology investments pre-suppose organizational, process, and informational change to yield the intended return. Yet, almost no one welcomes change. So how do you do it?

I believe change management is 80% art and 20% science. The science part almost always begins with the classic consultants' response: "recruit an executive champion." Without it, you're dead in the water. And the way you get leadership on board is by aligning your project with the strategic direction and goals of your enterprise. That means, as Alan points out, avoiding faddish rationales and sticking to improving core capabilities. Unfortunately, in all too many enterprises, executives themselves are not aligned with the overall corporate strategy and may be focused totally on their nearest personal or tactical goals. If that's the case for you, and you want to spearhead a complex content management project, reconsider your bearings.

On a more promising note, a recent conference attendee shared with me her success in fostering change by engaging her human resources department early on in her document management project. They were obviously an enlightened HR team who saw change management as an important part of their job. Seems worth exploring.

In general, though, I'm rather suspicious of specific change management techniques. I've seen the same approach succeed in one project and backfire totally in another. Hence my conviction that change management is highly situational, and involves more localized artistry and improvisation than structured process. If you're a new project manager, find even a reasonably successful IT project in your enterprise and figure out why it worked.

In my experience, successful projects tend to revolve around a certain type of project manager or coordinator. Someone who really knows the organization, is respected, collects chits constantly, listens well, doesn't personalize disagreement, remains flexible, and generally wraps a friendly persona around a persistent pursuit of project objectives. In short, someone who is good at community-building. Ultimately, any project manager will need sticks as well as carrots, to bring recalcitrant non-adopters in line, and to pull this off she needs the collective authority of a team, rather than the power of an individual executive or department. Remember, even enterprise-dictated technology projects require genuine community adoption at the employee level to be successful. Good outside consultants can facilitate change, but real leadership starts from within.