You’re implementing Drupal, SharePoint or something else that’s a “content management system”, and you’re getting the client involved in creating the content. One problem — getting them to use the content management system is impossible.

Seriously, I’m all for putting power in the client’s hands, but they have to be prepared for that power, and most of the time the person “given” that power has many more things to do than edit content in a website or extranet.

Here’s a few more truths about content management system and how they affect clients.

Sometimes what you wish for is what you get

All clients love the idea of editing their own site, but have no idea what it takes to create content. It means sitting down, opening up Microsoft Word and actually putting thought into the words that you are going to write. And that’s a lot of work, and they usually have no one on staff to do that task. I can’t tell you how many times I’ve had clients wanting to edit their sites because it’s been sitting for months, and they’ve forgotten the password.

Once they get in, they usually get out as quickly as possible, and ask you to add the photo or make the change.

Having that power and using that power are two different things, and many a time the client just throws up their hands and expects the company that implements the CMS to add the content.

What to avoid? Write in the contract that you aren’t responsible for content until you are responsible for it when the client is footing the bill.

The client has no one adept enough to use the CMS technically

Some CMSes, like SharePoint and SilverStripe, are straightfoward to use and for the most part don’t require extensive training to get the ball moving; within five minutes of each, I can train someone on how to add a page, how to edit content, and how to upload files.

Some of the other CMSes? I would never want my mom opening up Joomla.

Ever.

The reason they’ve brought you in for the project is not only for your design skills, but for your technical skills. The reality is that most companies small enough to want to go open source are also too small to maintain a site if it gets much further than changing out some text because their staff isn’t technical enough. Open source doesn’t mean free, and that free sometimes comes with technical overhead.

What to avoid? Put in time for training. A lot of it.

Open source is still open source — buggy and sometimes hard to use

When you use “free software”, you sometimes get what you pay for, and the client will never understand why you’re using it, other than, “you’re billing me for this, why doesn’t it work?”

The open source CMSes are what they are: developed by programmers that have a love of developing software, but sometimes do things their own ways or they aren’t thoroughly tested. Some clients don’t understand this, and figure the CMS should be bug free right from the get go.

Whatever system you select, explain to the client there’s going to be an upgrade path, and associated costs with it. This may mean some kind of maintenance deal in the future that’s like dependent on the upgrades coming out.

What to avoid? Have a very real conversation with the client about what open source means, and explain to them all software is buggy. Seriously.

CMS sites don’t plan themselves, and a bad information architecture can set you back years

The client is fully engaged, learns how to use tool in a way cavemen learned how to use fire, then “burns” themselves the first way through.

Bob down the hall in accounting can barely spell information architecture, much less construct one, and a single workshop over an hour isn’t going to give someone enough training when some of us have been honing our craft for years. It’s about planning, and poor planning for some CMS implementations can be death for user adoption. Or, how’s your company intranet holding up?

What to avoid? Book an information architect all the way through the project. If they are engaged, they can give the guidance needed for the site, and it will save time and money in the long run.

The answer is no.

They’re looking for something that saves them time, backs up their data, makes it easier to share information with their co-workers, and that will work. They don’t necessarily care about the name of it, all they really want it to do is work, and for it to make their life easier.

That’s one of the points information technology departments miss in dealing with end users: the users at the end don’t really care what the name of the software is, because whatever they get, it’s imposed on them. From the email software they use to the word processing software they write up reports in, almost every piece of software is selected and standardized on across departments. Very few end users get to pick what their software is, and if they do get to pick, the information technology departments don’t support it.

So what’s my point?

To the information technology departments, specifically: whatever you do, make sure it doesn’t impose extra restrictions or demands on the end users. Whatever you build into SharePoint, take in consideration that the easier to use it is, the more users that will use it. Imposing extra governance and workflows to it doesn’t make sense.

For example, Groove is a great tool when paired with SharePoint, because you can have files on your local system sync with SharePoint document libraries automatically and seamlessly. What that meant for me is I lost a bunch of files in a system crash, but all of the files were backed up to SharePoint. I didn’t lose anything.

And it was so easy to use, I didn’t even know I was using it.

Can you say the same about your SharePoint implementation?

I like FaceBook. I’ve hired people off of FaceBook, and find it more useful from a profile standpoint (but less entertaining) than MySpace, but not as useful as LinkedIn. However, I had to do some housecleaning the other day, and I deleted over 100 applications.

Part of the problem is how most of these application developers design the applications, and nothing is a better illustration than what my online budy Andy Sternberg pointed out using an application on my own profile — that since I’ve installed an application, there’s this implicit “wow, Patrick must really like it.”

No, I don’t like it. My friends are selling me, and I’m not getting any of the profits.

A lot of these applications and even some websites, like Reunion.com (I’m not just bringing them up because I interviewed there years ago, but because I know the CEO knows better, and the David Lazarus of the Los Angeles Times also brought it up) are using shady ways to promote themselves, like harvesting friend lists and so on.

Note to application developers — if the applications are usable, engaging, and cool, people will use it in droves. They’ll tell your friends. They won’t worry about being forced to tell 10, or 12, or 20 friends. Facebook probably doesn’t know how it’s damaging their reputation, or if they do know, how to fix it.

That Scrabbulous application is engaging.

Texas No-Hold ‘Em Poker is engaging.

FriendFeed is engaging.

Selling friends is not.

Long story short, one of the people had an interesting paradox: how do you get people to use SharePoint when they are using the voice mail system for everything?

He works for a local restaurant chain, and most of the users are restaurant managers that are too busy managing their restaurant to report on issues. They are supposed to log the going’s on in MOSS, and now instead of using a diary, they use the voice mail system, because it records all the messages.

He’s talking about some of the issues, and there are some very interesting patterns, most of which are cultural because of the nature of the users he’s dealing with.

I suggested that instead of trying to force them onto SharePoint, do the opposite and let technology do all the work — there’s some voice mail software that will transcribe the message to text, and save the audio message. You can probably hook that up to MOSS, and thus save the messages and the voice mails themselves for archival. Sure, there’s a loss of potential meta data, but that could be cured other ways.

But it brings up an interesting point: how many of us have run into an environment where user adoption issues are so severe, the technology just doesn’t get used? Square hole, round peg, right? That’s why we write personas, so we can understand the culture of the people that we work with.

In this case, the restaurant managers are not computer users — if you studied their usage patterns, they are probably recording their voice mails on the way home after a long day on their feet (and they would drive home and record the message instead of sitting in front of a computer). So sitting them in front a blog probably wouldn’t happen.

Any suggestions?