Do Content Management Systems really work?
February 17, 2005 7:40 PM Subscribe
I work for a company of about 100 people whose product is information, but it manages information in a really crappy manner. Nobody knows what's going on elsewhere within the company; often crucial people are unaware of events staged by other departments. We are thinking of getting a CMS to fix this:
everything from stuff for our website, to our print publications, to the schedule of classes and events would be accessible there to most staff and editable/reviewable by some through a permissions system. Do these CMS things really work to fix information flow? Of course three aspects are key: a) the ease of use, power, configurability and flexibility of the software; b) the cultural and educational preparedness of the staff to adopt the software and use it to its best potential; and the effectiveness of training to bridge the gap between a and b.
I am interested in your own experiences with adopting CMS systems to manage information flow, as well as pointers to any rigorous studies on this matter. I'm tired of useless promotional "white papers" from various vendors. Assume we want to own licenses and that we can afford quality.
everything from stuff for our website, to our print publications, to the schedule of classes and events would be accessible there to most staff and editable/reviewable by some through a permissions system. Do these CMS things really work to fix information flow? Of course three aspects are key: a) the ease of use, power, configurability and flexibility of the software; b) the cultural and educational preparedness of the staff to adopt the software and use it to its best potential; and the effectiveness of training to bridge the gap between a and b.
I am interested in your own experiences with adopting CMS systems to manage information flow, as well as pointers to any rigorous studies on this matter. I'm tired of useless promotional "white papers" from various vendors. Assume we want to own licenses and that we can afford quality.
Best answer: On rereading your question, two other things come to mind.
1) Small changes can often work wonders, and people tend to follow in good habits when others are persistent in leading with them. If people don't know what's going on, it's because other people aren't diligent about telling them. Giving them a place to do so will help, but it won't fix things if there's a fundamental resistance to sharing. Make sure you address that.
2) You're somewhat asking about a knowledge sharing network, not just a CMS. You can get some of these features in a CMS, but you'll have to be specific about what you need. Again - step 1 is to identify the problems.
posted by Caviar at 9:00 PM on February 17, 2005
1) Small changes can often work wonders, and people tend to follow in good habits when others are persistent in leading with them. If people don't know what's going on, it's because other people aren't diligent about telling them. Giving them a place to do so will help, but it won't fix things if there's a fundamental resistance to sharing. Make sure you address that.
2) You're somewhat asking about a knowledge sharing network, not just a CMS. You can get some of these features in a CMS, but you'll have to be specific about what you need. Again - step 1 is to identify the problems.
posted by Caviar at 9:00 PM on February 17, 2005
Best answer: huy boy. When we had this problem at an information management company of about the same size, I wrote a document/task management system from scratch to solve the problems.
We had five problems.
1) No one could get a good list of what was on their plate due to a very crappy job order requisition system.
2) Time tracking worked pretty well, but it was difficult for management to generate reports. Managers spent hours every day writing SQL queries to drill down into the database.
3) It was difficult to impossible to pass tasks around like footballs, which often needed to happen. Helpdesk would get a jobreq from a user who had found something on a server that was broken. Upon investigation, it wasn't the server down, it was a broken script. The jobreq would go into a programmer's queue and may never see the light of day again, and there was no way to find that 'cept an aging report. If it needed to go onto another programmer due to either workload constraints or experience constraints, it might get lost in the process, and there was no way to find it 'cept for the ID number. Managers could only generate a report of a programmer's tasks manually, so they didn't manage their programmer's queues.
4) There was no logging. Once a jobreq was passed, you didn't know when it was passed from person to person.
5) There was no formal QA process before a jobreq was closed.. it either went back to the user or to an IT manager, but this had to be done manually. It might just silently get 'closed' when the programmer was done and disappear forever.
The IT department, and by extension the whole company, had been running on the old jobreq system since 1987 when I started there in 2001. I hated it so much that I wrote a complete replacement for it that solved every single problem, was web-based and could be accessed securely from off-site, and which was later updated to provide rudimentary sarbannes-oxley level auditability. Full SOX compliance was hacked into it after I left, and now the whole company uses it to manage internal department processes. Now, the payroll system for contractors and hourly employees pulls from the old system's logs, and the system provides all of the necessary audit reports ... the company's auditing firm comes in, glances over the reports, and leaves. Since auditors were paid on an hourly rate, the company ended up paying half what they did before on auditing. Department efficiency in departments that implemented it for internal operations (which, due to program design, could easily be sandboxed from other departments while still allowing other departments to 'peek' and see what a department or individual person's workload looked like) doubled or tripled according to internal management audits. Documents are managed from within the system and stored on the server, and can be attached to either projects or individual tickets or just held in a user or department's folder.
The reason you can't usually find a good off the shelf system for this kind of management is that most companies work differently from most other companies. Your internal processes are your competitive advantage, and if you try to implement systems that either don't reproduce existing and necessary processes fully, or radically change existing procedures and don't give a similar result ... well, let's just say that you'd be surprised at how creative rank & file administrative users can be at getting around or short-circuiting restrictive electronic processes.
Sure, you can buy systems that are frameworks and need to be programmed in their industry specific language for which you need to pay a consultant $150/hour, but ... there are much cheaper ways to get something that's much more closely customized to your company's needs.
Focus on your needs, not on the technology.
Oh, and it still runs on the original surplus dual P2-400 system with half 1/4 a gig of RAM that it started on. They added RAID later, but that was it. Development costed about $32,000 if I remember correctly ... mostly in my time. It's also offered as an add-on product to one of the company's existing information management products, and external contractors, partners or customers have restricted logins and their own 'department' so that they can communicate with the IT department or whoever they're working with.
My reward was that I was made redundant and laid off in 2003. My boss's reward for shoving the system down the company's throat so that SOX conversion was painless was to be forced into early retirement late last year. ;) (They want him back now, but he moved out of the country...)
But I'm not bitter, because now I write similar systems full time for small to medium companies. I've studied this whole concept pretty heavily, so I'm happy to answer any questions you may have, without the sales pitch if you so request. If you're interested in knowing more, my email is in my profile.
posted by SpecialK at 9:06 PM on February 17, 2005
We had five problems.
1) No one could get a good list of what was on their plate due to a very crappy job order requisition system.
2) Time tracking worked pretty well, but it was difficult for management to generate reports. Managers spent hours every day writing SQL queries to drill down into the database.
3) It was difficult to impossible to pass tasks around like footballs, which often needed to happen. Helpdesk would get a jobreq from a user who had found something on a server that was broken. Upon investigation, it wasn't the server down, it was a broken script. The jobreq would go into a programmer's queue and may never see the light of day again, and there was no way to find that 'cept an aging report. If it needed to go onto another programmer due to either workload constraints or experience constraints, it might get lost in the process, and there was no way to find it 'cept for the ID number. Managers could only generate a report of a programmer's tasks manually, so they didn't manage their programmer's queues.
4) There was no logging. Once a jobreq was passed, you didn't know when it was passed from person to person.
5) There was no formal QA process before a jobreq was closed.. it either went back to the user or to an IT manager, but this had to be done manually. It might just silently get 'closed' when the programmer was done and disappear forever.
The IT department, and by extension the whole company, had been running on the old jobreq system since 1987 when I started there in 2001. I hated it so much that I wrote a complete replacement for it that solved every single problem, was web-based and could be accessed securely from off-site, and which was later updated to provide rudimentary sarbannes-oxley level auditability. Full SOX compliance was hacked into it after I left, and now the whole company uses it to manage internal department processes. Now, the payroll system for contractors and hourly employees pulls from the old system's logs, and the system provides all of the necessary audit reports ... the company's auditing firm comes in, glances over the reports, and leaves. Since auditors were paid on an hourly rate, the company ended up paying half what they did before on auditing. Department efficiency in departments that implemented it for internal operations (which, due to program design, could easily be sandboxed from other departments while still allowing other departments to 'peek' and see what a department or individual person's workload looked like) doubled or tripled according to internal management audits. Documents are managed from within the system and stored on the server, and can be attached to either projects or individual tickets or just held in a user or department's folder.
The reason you can't usually find a good off the shelf system for this kind of management is that most companies work differently from most other companies. Your internal processes are your competitive advantage, and if you try to implement systems that either don't reproduce existing and necessary processes fully, or radically change existing procedures and don't give a similar result ... well, let's just say that you'd be surprised at how creative rank & file administrative users can be at getting around or short-circuiting restrictive electronic processes.
Sure, you can buy systems that are frameworks and need to be programmed in their industry specific language for which you need to pay a consultant $150/hour, but ... there are much cheaper ways to get something that's much more closely customized to your company's needs.
Focus on your needs, not on the technology.
Oh, and it still runs on the original surplus dual P2-400 system with half 1/4 a gig of RAM that it started on. They added RAID later, but that was it. Development costed about $32,000 if I remember correctly ... mostly in my time. It's also offered as an add-on product to one of the company's existing information management products, and external contractors, partners or customers have restricted logins and their own 'department' so that they can communicate with the IT department or whoever they're working with.
My reward was that I was made redundant and laid off in 2003. My boss's reward for shoving the system down the company's throat so that SOX conversion was painless was to be forced into early retirement late last year. ;) (They want him back now, but he moved out of the country...)
But I'm not bitter, because now I write similar systems full time for small to medium companies. I've studied this whole concept pretty heavily, so I'm happy to answer any questions you may have, without the sales pitch if you so request. If you're interested in knowing more, my email is in my profile.
posted by SpecialK at 9:06 PM on February 17, 2005
We are thinking of getting a CMS to fix this:
My advice is not to think of "getting" a CMS as the solution, but to think of "using" one as an answer. The extent to which people integrate it into their workflow makes all the difference, and you have to be able to reach cticial mass for adoption, as a group, in order for it to work.
By "worked", I mean - they fix problems, people use them on a day to day basis
That's exactly what I mean by "work," too. People using it. A lot of times, a new info management tool is expected to jump out of the screen and solve problems, especially for people who are technologically overwrought already. You sit them down in front of it for the first time, and they say "so what does this do for me? That's what you're up against. It depends a lot on your company culture, and it sounds like that is in a state of severe genetic disorganization. I think you'll find that your choice of product is not the biggest question.
posted by scarabic at 9:30 PM on February 17, 2005
My advice is not to think of "getting" a CMS as the solution, but to think of "using" one as an answer. The extent to which people integrate it into their workflow makes all the difference, and you have to be able to reach cticial mass for adoption, as a group, in order for it to work.
By "worked", I mean - they fix problems, people use them on a day to day basis
That's exactly what I mean by "work," too. People using it. A lot of times, a new info management tool is expected to jump out of the screen and solve problems, especially for people who are technologically overwrought already. You sit them down in front of it for the first time, and they say "so what does this do for me? That's what you're up against. It depends a lot on your company culture, and it sounds like that is in a state of severe genetic disorganization. I think you'll find that your choice of product is not the biggest question.
posted by scarabic at 9:30 PM on February 17, 2005
Just to illustrate: at one of my previous employers, there was a personal assistant so ingrained in the paper-memo ways of the 60s/70s/80s that she simply printed emails as they arrived and then read/filed them as paper documents, as if the "e" in "email" meant nothing more than a quick and fancy way of delivering memos.
posted by scarabic at 9:32 PM on February 17, 2005
posted by scarabic at 9:32 PM on February 17, 2005
I'm not sure a CMS system will solve your problem, it probably won't hurt though.
A company that size should pretty much know what's going on, so I would posit there's either an organizational or a roles and responsibility issue. I know pretty much everything my department is up to (around 60 people) without relying on a CMS system (but boy those budget reviews do come in handy for getting the low down).
posted by forforf at 10:25 PM on February 17, 2005
A company that size should pretty much know what's going on, so I would posit there's either an organizational or a roles and responsibility issue. I know pretty much everything my department is up to (around 60 people) without relying on a CMS system (but boy those budget reviews do come in handy for getting the low down).
posted by forforf at 10:25 PM on February 17, 2005
Have you considered trying a Wiki? In my experience, the more permissions / workflow / etc you have in a CMS the more likely it is that people won't use it. Wikis may be a little unconventional but the barrier to entry is fantastically low and they can work extremely well (I like MediaWiki or TaviWiki myself).
I'm very skeptical of the idea that the people who update an intranet should be limited. If you have an employee who can't be trusted to edit information on an intranet, why did you hire them in the first place? In my opinion the presence of a revision log should be enough to deter any abuse - if someone screws up, just revert their change and have a word with them about it.
posted by simonw at 10:28 PM on February 17, 2005
I'm very skeptical of the idea that the people who update an intranet should be limited. If you have an employee who can't be trusted to edit information on an intranet, why did you hire them in the first place? In my opinion the presence of a revision log should be enough to deter any abuse - if someone screws up, just revert their change and have a word with them about it.
posted by simonw at 10:28 PM on February 17, 2005
This thread is closed to new comments.
By "worked", I mean - they fix problems, people use them on a day to day basis, the tools support the work that those people have to do, and they use the system to do their work instead of looking for ways to bypass them.
It is absolutely critical that you first understand the problem. Most CMS installations "fail" because the problem they're addressing is poorly defined. If the system imposes constraints that don't map to the real world, it will make the users frustrated.
Secondly, you must get buy in. If people don't want to use a system, they won't. If it's not supported by management, it won't be used. Everyone must be convinced that this is an effort to make their jobs easier, which it should be.
Your a) item: "the ease of use, power, configurability and flexibility of the software" is a loaded term and very dangerous. Many systems can fulfill all of these, and yet still not solve your problems. Again - your first concern is to identify exactly what the problem is, and design a system to address that.
posted by Caviar at 8:54 PM on February 17, 2005