I think he's missed the boat, especially for smaller nonprofit agencies - they face TWO challenges:

1. They can't edit their content - they don't have a CMS, or html skills, or may not even know who hosts their website.
2. They can't afford an editing team. The author is right about the first part, but wrong about the recommendation. Nonprofits staff need to be taught how to create effective content, how to manage a process for marketing and branding their key messages and so on - and taught how to do so when they are an editing team of one!

I would say that I am generally satisfied with the CMS strategy that we’ve had in place for over four years now. Since the CMS doesn’t require any HTML or advance web programming skills, staff members have been successful in taking on the responsibilities of updating content on our web site. This of course, allows IT to focus on IT tasks rather than publishing content related material to the site.

I think the author was right on the money with most of his assessments and recommendations. Having an editorial process in place for publishing content to the web site is definitely an area my organization could improve upon. Decentralization is great because it allows us to provide a unified image, feel and consistency and keep fresh content. However, without one true overseer of the process, we have occasionally ended up with out-dated and/or inaccurate content that have managed to “slip by” and remain on the site.

While I agree with most of the writer’s assessments for why CMS projects fail, I dislike and disagree with the “Stupid User” term and theory that’s used to explain staff adoption of new software and applications. It’s so easy for us IT folks to give users what we believe will help them to do their jobs better. But, before we blame the users, we should consider blaming ourselves for such project failures. Perhaps we got it wrong in the requirements or when writing the specs. Without a complete understanding of the business rules and end-user requirements, we can implement solutions all day long. But if it’s not what the user needed in the first place, then they will NOT use it.

Getting the staff to use the software isn't an issue for my organization because 1) – We have user buy-in and full upper management support. 2) – We provide training. However, once users see how easy it is to use (with tools such as WYSIWYG editors), they take to using the software like fish to water. 3) – Using the CMS became part of the standard operating procedures. Users don't have a choice to use the application (or not), Using the software is simply a part of how they are able to do their jobs.

I agree with you are site needs to be more up to date we need and editor, we need help. Can you please give me someone that is willing to work with our organization on going we can pay a small fee. please email us @ Gniners@aol.com

Thank You,
Regina

Sure thing. I'm more than happy to share that information. We implemented our solution about four years ago. Since then, I know that there are applications and vendors that offer the same type of functionality for a much lesser fee than we currently pay. We have decided to stick with our solution, although it's more expensive because the vendor offers so much more and we feel that it's worth paying the extra dollars.

The application that we use is called CommonSpot, which is managed by a company called Fusion productions. I will email the contact information to you.
Kind Regards,
Stephanie

We have a large (10,000+ pages including dynamically rendere) public-facing site. Our Team of 6 (plus add-ons when needed) has managed the content of the site for years without using a system other than our editorial process.

We were all "born" as editors and editorial assitants and have grown up in our organization (I'm in my 30th year). I started with typesetting on resin-coated paper that had to be developed in a photographic-like process and then manually "stripped up" onto premarked flats into multiple-column layouts by a draftsman with an Xacto knife and a waxer. We moved on to desktop publishing, WYSIWYG software and laser printers. Now, we consume very little paper, and our Team feeds a miniscule amount of work into our Digital Imaging group (yes, they were printers).

Our primary focuses are the corporate Web site and intranet site. So much has changed in the 30 years I have been in electronic publishing (btw BA, English, MA, Communications) except for one thing, our editorial process. Movements are quickly planned, prototyped, and executed within the same process in which we "typeset-stripped-up published" the document that won a contract for our nonprofit research organization that remains in place today, spawning one our largest divisions.

Not everyone on the Team knows everything about the site, but we keep in close contact, as much of our site is connected on the backend with custom applications that we spec'd out to the programmers. Changes ripple across the site, so our process includes mailing lists to alert other Team member of an alteration WE KNOW affects other areas of the site. Team members in the other areas respond with both action and confirmation of their action back to the other Team members.

It's not perfect (proofread this note and you'll see just how imperfect we are), but it works so well that the lure of turning our content over to a system that is touted to automate our process is overridden by the fact that we know the human part of the equation is the most important part. Our human-centered process, Team approach, and refusal to put the responsibility of content quality and currency on the backs of our researchers keeps us tightly controlled (in the most pleasant and relaxed atmosphere). Our responsibilities extend past the static XHTML page or the dynamically generated page to the protection of our corporate image, "legal," organic search-engine optimization, and a cohesive public presentation.

We, a media group that includes the Web site, the intranet site, editing, writing, graphic design, technical illustration, digital imaging (today's printshop), photography, videography, multimedia, digital document archiving, digital retouching, and Web-delivered corporate image database, are under the auspices of our Communications Department. We are deeply seated in PUBLISHING and its accommpanying processes that evolved in a time when it was not so easy to recover from a bad decision or poor practice of the in-place processes as booting your WYSIWYG Web editor and making a worldwide change in an instant.

We are finding it challenging to pass the torch with such intensity as we "old schoolers" hold in our hearts, but pass it we must. We're trying. We're starting as early as we felt like admitting we would not "be there" for our clients forever. The process is being reinforced by a Team attitude and by recovering from our mistakes. We don't blame (though you may never live down dropping an element into a sitewide container that take 45 minutes to process and the same 45 minutes to undo - we've all done it); we fix it as a Team.

I won't "dis" CMS, but we have found that it is quite exciting and relatively easy to maintain a large site with an old school editorial process without support from a "system" apart from the one we have - our Team and our "procedures" (currently being put down on paper for those who follow to do with as they see fit).

Welcome to TechSoup! Thanks so much for sharing your experience and perspective on content management strategy. You raise a good point about the need to keep your strategy human-centered and user-centered, whether you're using "old school" or newer technologies.

Hope to catch you more around the forums.

Best,

Megan