I have some real, thoughtful, posts that I want to get out there. Okay, maybe only one. However, I don’t want to post them at the end of the week, so I am grabbing one of my rough draft articles to throw out for public ridicule and dissection.

This particular article is pretty raw, though I’ve smoothed a few rough edges. I’m posting it because one of the comments on my Preaching to the Content Management Choir post was from Steve Weisman who said,

I’ve said it for years and will say it again: the ECM industry’s greatest obstacle — never mind that it isn’t an “industry” at all — is psychology, not technology. Change management, organizational (mis)behavior, corporate culture etc. are all more in the way than the systems themselves, which all do work, more or less, pretty well. But only if you plan for and use them right — and therein lies the rub!

I think a lot of the reason that those are overlooked is because we lose time doing things that should be simple at this point. When schedules slip, the tasks aimed to deal with the psychological obstacles is cut.

So without further ado, the tech problem with a few inserted rants…

There has been a lot of talk of late in the great ether called the Content Management community about all of the different terms and systems. The focus has been both semantic and feature related. This debate is largely academic as a major challenge that a lot of companies are facing is the simplification of the operations and maintenance of a system.

Harder Than it Looks

I’ve spent the better part of the last few weeks working around issues in several different systems. The systems were fine until I either had to install a new component or upgrade various components.

What scares me is that I wasn’t performing any major changes to any of the systems. The even scarier fact is that I took it all in stride as just part of the process. I expected these tasks to be challenging. That is a problem that needs to be eliminated.

It is unrealistic to expect a vendor to not change their architecture over time. There are several valid reasons to do so:

• Design flaws that have risen to the surface as the product has matured and need to be addressed for growth. What works for 1,000,000 documents may not work for 1,000,000,000 documents.
• Changes in the IT world such as the move from 32-bit to 64-bit.
• New critical features that represent whole new ways of system interaction.
• Fill in your favorite reason here: ___________________.

When people begin using a new CMS, the process can be so painful that they don’t touch the system. This pain is in direct relation to the degree that the CMS is being pushed to its limits. People get confident, or desperate, and apply a service patch, but unless there is the risk of a major security breach, they will likely pass.

After all, why “fix” what doesn’t appear to be broken?

This often leads to postponement of significant upgrades. before anyone realizes what has happened, they are running an unsupported platform and it will take nothing less than a full migration to move to a system that works.

Not Making This Up

This isn’t just gathered from talking to potential clients needing to perform upgrades from hopelessly out-dated systems. I was taking part in the review of a large government system and they made the assumption that since the system was originally deployed over 3 years ago that the technology was out-dated. There was some very real surprise on several faces when it was learned that the system had been regularly updated as a matter of routine.

This is widespread. Maybe not universal, but this is a common phenomenon.

Organizational Change Management isn’t new. Neither is performing adequate training. What is rare is the project that has enough money to implement those from the start AND the ability to keep them on the schedule as things go wrong.

Give me more configuration and less code. Give me better documentation. Give intelligent installation packages.

Yes, install packages. How hard is it?

• If something is a dependency, INLUDE it in the package.
• Automate everything.
• If it isn’t a hot-fix straight from the development team, make it point-and-click.

I had one install complain that a security package wasn’t found. No clue as to what should have already installed that package. It is almost like putting together a puzzle blindfolded.

Maybe I’ll just hold out until a SaaS vendor provides the features that I need. I can let them deal with those headaches and I can get back to solving business problems.