Real Story Group. Make Better Technology Decisions.

Alan Pelz-Sharpe

Follow Alan on Twitter @alanpelzsharpe

Christening your ECM project

10-Mar-2009

Tags: Document Management (ECM), Building Business Case, Implementation, Selecting Technology, Documentum , Documentum, Documentum Digital Asset Manager, Documentum Technical Publishing Solution, Documentum Web Content Management, ECM Suite, EmailXtender, iManage WorkSite, Livelink ECM - Email Management, Universal Content Management

It has always surprised me how many firms name their internal ECM applications and systems after the product that it runs on. For example, I have come across many organizations over the years that tell me things like-

"Well when I go into LiveLink I...."

" I update the Documentum "

" I logged my information into Oracle "

"We put our documents into WorkSite"

It might sound like the ultimate in pedantry (making me the ultimate pedant - though that in itself is probably a little pedantic to point out), but in my experience, naming your application after the technology it runs on usually delivers unexpected consequences.

First off, any moans and groans about "the system" are focused on its namesake and over time it becomes easy to believe that "the system" is to blame for all your ills, whether in fact it is or not. Ultimately when it comes to upgrading or refreshing the platform at some future date, there is little chance the incumbent vendor will be considered. This can short-change you the buyer -- as in many cases "system issues" post-deployment are not down to the vendor's technology, but rather the way you are using and maintaining the technology. Common areas of failure come from poor filing structures, clumsy (or sometimes non-existent) document types, a rank failure to manage lifecycles, alongside (most typically) ineffective policies and procedures.

If you simply blame the technology and fail to address these issues, then in time you simply end up staggering from one clunky system to another -- basking in the fun of something new, til it too fails. Failure owes in large part to your inability to acknowledge the responsibility to build, maintain, and run things in accordance with agreed upon and actionable policies and procedures.

I am mentioning all this, as recently I have seen a couple of instances whereby simply upgrading to a newer version of the incumbent's technology would have been the right choice on so many levels -- yet the buyer has told me that the incumbent's name is (to quote) "dirt around here." Although the vendor had delivered everything they promised and more,  their name had become something of a scapegoat for all things wrong when it came to electronic information management.

I worked for many years in the North Sea Oil and Gas sector, and we gave our projects names such as Kittiwake, Cormorant, and Tern - names that evoke something of the locale (in these cases sea birds). We never called these offshore cities things like SkoFlo Valves II or AutoCad North, so why call your system LiveLink or Documetum? In truth the naming of engineered eco horrors after pretty seabirds had more to do with PR than anything else, but the principal remains: separate your business concerns and working applications from the underlying nuts and bolts and you will have a greater separation of concerns when it comes to understanding what works and what does not.