Content Manangement Without A System
October 06, 2004 | 
26 Comments
Summary: It is quite possible, in fact could be preferable, to manage content and distributed authorship without the use of a content management system (CMS). Regardless, it’s very important to have a process in place before you choose a CMS.
A system cannot manage content on its own. It’s been said before, by myself and others, that content management is a process, not a technology. I think this is something anyone who is looking into implementing a CMS needs to acknowledge and address before they purchase or build anything.
Unfortunately many decision makers don’t understand what it takes to truly manage content. It takes process and it takes people. A system can only do so much, and more often than not, they just over complicate things and make the process of managing content that much more difficult.
Trying to manage content without the proper process and proper people in place is an exercise in utter futility. It’s destined to fail and almost always does.
So, what do we do? How can we better manage our content and attain the promise of a CMS? Well the first thing we need to do is forget, at least at the start, the “system.”
Why a system? Why not?
Well, let’s start with a story.
Sally is the manager of a large corporate intranet. She has a decent size budget, some support from her IT department and some big ideas. She also has numerous stakeholders to deal with and a ridiculous amount of content that needs to be updated, refreshed and maintained.
After quite a bit of research she decides to look to a content management system as an answer to all her content management problems. She purchases a CMS (at a ridiculous price) that promises to easily allow Sally and her horde of stakeholders to manage their intranet and dissolve their content management woes.
Then the problems start. She can’t customize it the way she wants and on top of that they’ve got to license SQL (again at a ridiculous price) and purchase a new server to even run the damn thing. She realizes most of the implementation is way over the head of her IT resources and decides to pony up for a support contract. Now she’s into a monthly fee.
The support is so-so, but she eventually gets things up and running. Whew. Oh wait, now the exceptions begin to roll in. The templates don’t fit with the forms that Mike in HR wants to add, and Ursula down in accounting wants her site organized differently than the rest of the departments.
Of course none of this custom work is covered in her support contract so she brings a consultant in to do it for her. Mo’ money, mo’ money, mo money.
She gets it all sorted out in time, after hiring the consultant on full time to manage the templates and exceptions and then, a few months down the road, she comes to find out that only four departments are actually using the damn thing and she is stuck making all the crucial and timely updates herself anyway.
The process is more important than the system
The above is a rather extreme example, but I’m sure it rings true for a few of you. I know it does for me. It might seem as if the problem here is the CMS she purchased, but the real problem is that she had no process in place to warrant even having a system in the first place.
Why, exactly, would she need a CMS that in essence:
- allowed her to make frequent updates to say the homepage, press releases and events calendar?
- provided distributed authorship to a few stakeholders so they could update their org charts once a year, thus putting her back to square one where she makes all the updates anyway?
The answer is she wouldn’t need a CMS in this case.
True, it’s a stretch, but I know of very expensive systems purchased to do less. In fact we’ve got one down at the hospital that runs our classified ads and nothing else. It comes down to Return on Investment (ROI). There isn’t any ROI in a CMS by itself. Not one red cent. There is ROI in a publishing process that perhaps uses a system to enhance that process.
The process is much more important than the system and should be put into place before a system is ever thought about.
A process means people
At the hospital we’re often slammed with updates to our external sites that, if we could get our stakeholders to use it and could easily manage the exceptions, we thought a CMS would probably help us out with. So, we tried this route, and had similar results to what Sally, from the example above, did.
But we learned from this mistake and tried a different solution that worked much, much better.
We established a publishing process for updates, put a person in place to oversee that process and hired a temp to maintain our now mostly static sites. Here is how we benefited by adding a process and putting people (as opposed to a system) in place to manage that process:
- It was cheaper. I’m often surprised at how much money goes into something that supposed to make life easier.
- Set up and training is much easier. Getting stakeholders to use even the most simple CMS can be a challenge.
- It was easier to manage the inevitable exceptions. A person can handle things the system couldn’t.
- Our stakeholders appreciate a “personal touch” and a single entry point for their updates.
- Freed up our development resources to concentrate on things that mattered.
- Were able to provide better, more timely and focused content to our users by having someone in place that knew the process and understood Web content.
So far it’s been great, and it’s the process and the people behind that process that made it a success.
I realize there are cases where this might not be an option. For example, if your demand for updates required you add numerous people just to handle the volume, a full-blown CMS might seem like the only way to give your stakeholders the control they demand as well as freeing your resources up.
This isn’t always the case. There are other options.
Distributed Authorship vs. Content Management
There are many cases where an organization might really benefit from a CMS, but as I’ve experienced myself, for many what they really need is distributed authorship. While a CMS can provide distributed authorship, it’s usually like hitting a thumbtack with a sledgehammer. Probably not the right tool for the job.
At the hospital we turned to Movable Type to provide our stakeholders with distributed authorship. Again, we initially tried the CMS route and found it too inflexible and hard to use for what we needed. And don’t get me started on the cost.
If you are looking into a CMS to provide distributed authorship my suggestion is that you really think about what it is you really need. There are many cheap, small scale solutions out there that may be able to give you what you want without going the traditional CMS route.
A few you might look at:
All of these can be leveraged to provide distributed authorship without going to a full blown CMS system.
CMS or no, the process is where it’s at!
Regardless of the technology you use to enable your content management, it’s important to have some kind of publishing process in place. Distributed authorship, for example, might provide a level of control to your stakeholder that they demand, but it that alone doesn’t the guarantee quality, frequently updated and informative content your visitors are looking for.
I see this quite a bit. Just because someone is enabled to make updates to a site themselves, that doesn’t mean they will or that those updates will add value to the site. It’s important to have some kind of process for content in place that every content provider understands and has bought into.
It’s here, in defining, putting into place and managing that process that a CMS will be of no help. Having the proper personnel in place (a content manager? doesn’t need to be a full time position) will insure the quality, smooth management and updated of content that most people look to a CMS for in the first place.
My advice, put you money and resources into your people and your process first. Then, if it makes sense, add a CMS (or better yet, an alternate technology for distributed authorship) if you need one.
Filed under: Web General
Comments
1. Brian Fox said:
You made some excellent points - I have done a few small scale projects where the client is so wrapped up in having a CMS and really it’s not what they need to get the job done. Oh well…
BTW… I’ve been waiting for this article since you talked about it a while ago ;-).
Posted on October 6, 2004 09:02 AM | #
2. Steven said:
Another issue (especially with regard to accessibility and standards compliance) is that if you don’t completely shoehorn the user into what they can do with the CMS, they tend to break your beautifully crafted templates anyway.
However, if you restrict them too much, they won’t bother using it as it’ll be too cumbersome.
I’ve seen people pasting Word documents into textareas and complaining that it “doesn’t work”. I’ve also seen people pasting multi-megabyte images into javascript wysiwyg editors and complaining that it is “too slow”. So often the answer is to provide decent training to staff who will end up using whatever system you put in place.
Posted on October 6, 2004 09:13 AM | #
3. Keith said:
Steven – Yeah, those kind of fall into the “exceptions” I was talking about. As far as maintaining standards compliance, that’s next to impossible with most CMS systems, for the very reason you describe. I’ve talked about that many times.
As far as training, I’m 100% with you in theory, but that is one of the challenges of implenting a CMS. Training can be hard to get into place and can have quite a cost. It is needed, but the actual doing of it is something people often don’t think about when thinking about putting a CMS in place.
Good points.
Posted on October 6, 2004 09:51 AM | #
4. Gabriel Mihalache said:
CMS, much like ERP and CRM, is an acronym that stands for nothing in particular. “CMS” is a concept implementable in hundreds of ways, therefore I wouldn’t make blanket statements regarding all software claiming to be a CMS.
Other than this small nitpicking, I think you’re spot on. Too many times management just want sites up as soon as possible, so no process is put into place, people’s responsibilities are overlapping and some damn fool ends up doing his part in FrontPage ‘97 so bye bye code semantics… and then they’re require streamlined updates even if their hurry made the team resort to tag soup.
Posted on October 6, 2004 09:52 AM | #
5. phnk said:
A very useful contribution to the growing debate about the use and abuse of CMS technology on the Web. Thumbs up !
Posted on October 6, 2004 10:04 AM | #
6. Keith said:
Gabriel – Very true on the CMS acronym, but in order to get my point across I’ve got to have a general starting place (my very basic definition of CMS) or I risk talking about all the different meanings of CMS. I guess I’m hoping my readers will be able to sort that definition out in context.
Posted on October 6, 2004 11:08 AM | #
7. Dave P said:
Great article Keith, definitely something I will be pondering in the coming months as I look into this for the company I work for.
As an aside, you touch briefly on people actually using (or not using) the CMS - process or system.
I’d like to see your observations in another article regarding this, specifically your hospital intranet. Do people use it? How do you promote and encourage use? How do you promote and encourage authorship?
Posted on October 6, 2004 11:17 AM | #
8. Gordon said:
I’ve been looking at similar issues in a professional capacity and can whole heartedly recommend “Managing Enterprise Content”
The theory behind the thinking is applicable over many different disciplines, with the cultural change required being a key issue identified and tackled through collaboration on reworking the processes behind a CMS.
Posted on October 6, 2004 11:41 AM | #
9. Keith said:
Dave P – I’ll keep that in mind and will do my best to share what I know, which isn’t a whole lot, except that people are resistant to change and to get them to use this stuff it has to be as easy as possible.
Many people are interested in using our MT stuff, and we have done training for that. I think the main reason is that it’s empowering to a certain extent, but not too empowering, if you know what I mean, and it’s easy. Many CMSs I’ve worked with are inflexible, hard to learn (some offer week long training, we did ours in one hour) and frankly over engineered to the point of being intimidating.
As well, I don’t think very many full blown systems have been built with the user in mind.
Vague I know, hopefully I can distill my expereinces into a post soon.
Gordon – Thanks for the tip. Sounds like a worthy read.
Posted on October 6, 2004 11:49 AM | #
10. Steven Woods said:
Regarding some CMSs being overengineered, I think that is a problem with at least two issues:
A lot of CMSs are packed to the extreme with features that are (for the most part) redundant and useless to the application the system is being applied to. This increase in features increases the level of complexity (or feeling of complexity to the user) which cause intimidation for those who are NOT tech-savvy, but which are ironicly the target userbase for the software. Its primarily a result of wanting to have (in big, flashy words) “1000’s of features!!!” in order to market the system.
At the end of the day, the software should integrate with the users working habits, instead of them having to restructure the way they work. Not only will this speed adoption, it’ll also pave the way for future system enhancements when people aren’t saying “no thanks” because they’re scared it’ll be too hard to use.
Posted on October 6, 2004 01:17 PM | #
11. Keith said:
Steven – True. As well there are times when existing processes should be left alone. All to often people look to technology to “improve” a process that is working just fine. It could be, in some cases, that manual updates by a Web author who edits html directly might actually make more sense then distributed authorship.
It depends, but often times existing processes aren’t compared with potential solutions.
Posted on October 6, 2004 01:21 PM | #
12. Douglas Arellanes said:
ROI for CMSes is drastically improved through the use of open source content management systems running on top of an open source platform. Licenses, after all, still form a large portion of the overall cost of a CMS.
The open source CMSes have made huge strides in the last couple of years, in both power and usability.
A great resource for open source content management systems is OSCOM (http://www.oscom.org), which seeks to provide resources for people interested in open source CMSes as well as for finding common ground between the various OS CMS projects.
There are a number of excellent OS CMSes, each with different features and strengths. Those seeking a blog-like user experience would be well served by Drupal, whereas those looking for an industrial-strength intranet CMS should look at MMBase, Midgard, or Zope/Plone. Those looking to get a publication online can check out the work my organization is doing with our Campsite CMS at http://www.campware.org.
Personally, I believe organizational processes such as workflow should be at the core of content management strategy. The software should match what the people do already, not the other way around.
Posted on October 6, 2004 01:32 PM | #
13. Steven Woods said:
Keith:
Exactly, and a point which is usually overlooked due to “ooh, shiny new computer system” attitudes. Sometimes you can’t improve a system - it already works, and sometimes yes, it doesn’t involve a computer!
*shock horror*
Most definitely true, I’ve seen countless people told to get a new system to fix a problem that isn’t there and its virtually always “because we can”.
I for one would be interested in seeing some statistics on the benefits of staying AWAY from computer based system, and utilising those systems already in place. I’d bet good money that the results would be jawdropping.
One of my previous employers had managers like that, who liked to surf the net, have a round of golf and suddenly decide that THEY needed a system exactly like their fellow managers’ company; even though they were seperate industries… there’s your thought/planning process right there :)
Posted on October 6, 2004 01:41 PM | #
14. Christian Watson said:
I work in the same web team and share Keith’s views on CMS’s. Too much stuff gets way over-engineered.
We purposefully redesigned our external site (now up to nearly 1000 pages) without a CMS as they are such a pain to use. We only have a small web team but have been able to maintain the site, add enhancements, and redesign some parts of it.
I actually believe that it has been easier to do redesigns and enhancements precisely because we are dealing with static pages. What’s wrong with keeping it simple?
We have experienced some updating pain with regards to updating regularly changing content such as news and events, so we implemented Movable Type in these areas, which works like a charm.
Unless you have a very large site, I have yet to see that appeal of using a CMS.
Posted on October 6, 2004 05:30 PM | #
15. Stephan Segraves said:
From my experience at work I have noticed that sitting down with a client and getting exactly how they do their work down is much more important than just throwing a CMS at them.
I completely agree it’s about the process. Low level management is the best example. When you are working in a factory accomplishing a task, if the process has too many steps or possibilities you run into problems completing the task in the end. Simplify the process, make it clear, and you’ll get much more work accomplished over a shorter amount of time.
CMSs should be along the same lines. Keep it simple by looking at what accomplishes the task quickly. Refine the process till it is smooth and fits the customers needs.
Great post Keith.
Posted on October 6, 2004 05:52 PM | #
16. Andrew said:
Often, purchase of a piece of software is an attempt to shift responsibility away from people and processes. It’s related to the “ooh, shiny new software” phenomenon someone mentioned, but it’s usually more insidious. Managers who can’t get their head around the vastness of really big content management problems feel safter paying someone to try to solve them with code.
These kind of decisions are often made in meetings where some VP says “we can’t afford to fail” in tones that make you think she’s talking about defending the free world. These managers would never admit that training, careful assignment of responsibility, and increased trust might solve most of the content management problems.
Posted on October 7, 2004 10:35 AM | #
17. Chris Vincent said:
Depending on your resources and needs, it’s often times better to do a quick custom “CMS”. This isn’t best for all situations, but sometimes it’s ideal.
Posted on October 7, 2004 11:37 AM | #
18. Vincent Grouls said:
Very nice post, Keith.
The local city council’s website also uses a CMS, and recently they advertised a vacancy for a Web Developer to help them convert to a new CMS that was more able to handle the +10000 pages their current site has. Currently they have 2 CMS instances in place – one for the intranet and one for the internet… blah!
Additionally they are required to conform with the DDA because they are an authority. As mentioned, standards-compliance and CMS are like antipodes…
I’ve applied for the job, but didn’t get an interview. Too bad in terms of getting money in, but on the other hand I won’t have to deal with the tag soup they are currently in (not to mention the design!).
Posted on October 7, 2004 03:42 PM | #
19. Philipp Keller said:
Hmm..
But what about all those small companies?
We are company that does the websites for quite a bunch of small companies where noone does know something about HTML or so..
So they would habe the option to have a contract with us that they send us their updates.. but then they pay for that a monthly fee or so.. And we bind us down on some “content management by hand” contracts.. that wouldn’t be that good, would it..?
btw: there are some quite good free (open source) CMS like typo3 with which it is quite easy to take an existing webpage into CMS.
Posted on October 7, 2004 10:45 PM | #
20. Steffen Glückselig said:
Interesting article. Inspiring.
I’ve put some WikiWikis in place for users that are not experienced in HTML.
I think that works quite well and even the uninitiated can handle such a ‘CMS’.
I’ve seen some larger sites that run wiki-engines as backends and wonder how a wiki-based CMS in the corporate world would scale? Are they practicable in larger businesses? Any experiences?
Posted on October 8, 2004 06:39 AM | #
21. Bronwyn said:
Wikis are all about distributed authorship, and many have version history so that you can undo your mistakes. I’d also like to find out how well they work for organizations as well as community sites.
I love running my personal site with a wiki. Creating pages and links is as simple as it can get, and PmWiki’s text markup syntax is good and getting better. Content is automatically poured into the correct template. Editing templates is no problem for anyone with HTML skills. Common customizations to the system are well documented, and if you have trouble, Pm himself will probably answer your question on the mailing list. I’m just hoping that he can satisfy my wishlist at I want a bliki in time for version 2 or an update for it.
Posted on October 8, 2004 09:28 AM | #
22. Bog said:
I have no idea what this means: “There isn�€™t any ROI in a CMS by itself. Not one red cent. There is ROI in a publishing process that perhaps uses a system to enhance that process.”
If a CMS lowers my cost, why isn’t that an ROI? I invest, I get lower overhead, and that’s not ROI? And don’t give some “well, I meant if the CMS doesn’t lower your costs” crap, because that’s what your article said.
Your article is trendy and new-wave-thinking-hypish.
Posted on October 9, 2004 09:11 AM | #
23. CM Harrington said:
Bog,
I think what was meant by the comment is that a CMS does not have a ROI in-and-of-itself. It’s the process that may or may not include a CMS that actually gives you a return on investment.
Posted on October 11, 2004 08:34 AM | #
24. Edgard Durand said:
I like to use a CMS as a backend for my website, it makes things a lot more easier.
And if you separate content from design, what else could be easier to update and manage.
Posted on October 14, 2004 06:58 PM | #
25. Demie anymous said:
First let me start by saying that I agree with the story above. It is always wise to first investigate and understand your workflow and work process before buying an expensive CMS. Although some companies offer evaluation versions to try, they will always try to sell you the damn CMS regardless if you need it or not.
I’ve participated on building a DotNet CMS for an Internet-service company. Believe me when I say that the amount of work without a proper workflow process will actually increase rather then diminish.
The example provided by the author in this case is a none-profit organisation, so expectations on Return of investment are false to start with. The only money it will generate is in the amount of time saved in managing and publishing content.
Its funny while reading the author his story I got this funny idea that it must have been written by a Dutch person. It is quite possible that this person is working at a hospital in Rotterdam.
SFG perhaps? In that case you shouldn’t have left so many clues.
Yours sincerely,
S.DEMI
By the way: En rooie cent in het Engels betekent one single penny en niet een RED CENT.
Posted on October 19, 2004 02:19 PM | #
26. Margaret said:
Hi, I realize that this is a few months old, but I just came across it as I was looking for a CMS for a website I’m planning. Your article reminds me of a project I was involved in a few years ago. The problem was that employees at the telephone company had to fill out a form to have their office phone service moved when they changed jobs (an infrequent occurance) The same form had been in use for 30 years (yes 30 years!) and several memos were floating around describing how to stroke out no longer relevant management titles and insert the proper titles, and so on, but still, employees were not filling out the forms correctly which delayed the process of getting the paperwork done, because the service reps had to make telephone calls to verify details.
After several lengthy brainstorming sessions with outside (and costly) consultants, it was decided - and approved - that a computer application be provided to every employee in the company so in the future when they changed jobs they could simply log on to the computer and enter the information there.
This was in 1988 - less than 10% of employees had direct access to a computer, but a purchase order was soon struck to provide the rest of them with desktop computers.
When I spoke up and timidly suggested that since this was the telephone company, and we were talking about moving telephones, it was safe to assume that the person with the problem already had a telephone, so why not just have them call somebody to have it moved, I was put on report of insubordination.
The project went ahead, cost several million dollars, was wildly celebrated upon it’s completion, in the end was used by one person one day a month to enter data that was never seen again.
I never did regain the respect of my peers and continued to be viewed as a “trouble maker”
The consultants were later hired on as permanent employees and one of them became my “supervisor”.
I managed to have a nervous breakdown and got a golden handshake out of the deal. Some things turn out good in the end.
M
Posted on April 28, 2005 06:32 AM | #
Comments are now closed