A few days ago a colleague of mine referred me to this Slashdot posting about the state of Open Source Content Management Systems. One thing I was reminded of is that the term CMS, means such different things to different people: blog, wiki, message boards, file repository, what I would call a "traditional" web CMS (clear distinction between readers and authors, editorial process, workflow, etc.) and everything in between. "Content" is a very vague term - people to take it to mean whatever is inside the system. So that makes a CMS anything that manages the stuff that it manages. Now it sounds like we are talking about information systems in general. The wikipedia definition does little to narrow the field: "A. content management system (or CMS) is a system used to organize and facilitate collaborative content creation." Still, I like it better than "Knowledge Management" but that is another post ;).
So I started thinking about categorizing the broad spectrum of CMS and was thinking that a good way to break down the space is along three axes related to the kinds of business problems they are trying to solve:
1) The proportion of contributors to readers. Or, similarly, the level of differentiation between contributors and readers
2) The level of editorial control. This could be measured by the number of stakeholders that need to review content before publishing or the amount of refining that needs to be done before the asset is approved.
3) What type of content. On one extreme, there are documents such as MS Word documents, video files, static PDFs. On the other side is textual content that can be rendered into web
If this model works for you, you might start thinking of CMS implementations that you are familiar with and mentally plot them along these three axes. For example, a company marketing site might have few authors to the number of readers, high degree of editorial control, and mostly textual content.
Where I think this model adds value is that it would allow an organization trying to select a CMS to quickly winnow down that vast universe of products to a subset designed to solve the specific set of problems.
I know that a lot of effort has been made to compare features of CMS (CMS Matrix does a really nice job on a subset of CMS products). But maintaining comprehensive feature lists is very difficult and the binary scoring of features (has it/does not have it) may not be helpful because the way each feature is implemented determines the utility to the user. Stepping back to the business problem might lead to a more direct path to the solution than to focus on individual features.
Once the field is narrowed down the features can be compared in a more qualitative fashion through demonstrations and prototypes.