Last week I came accross an interesting situation: A potential client is looking for a new CMS solution and came up with quite a serious list of requirements which sounded much more like a CMS vendor's marketing material than requirements derived from a troubled content process. Digging a little deeper and doing some research I found that they'd probably been using step two's content management requirements toolkit to put together their list of needs.
The Requirements Toolkit contains 133 fully-developed CMS requirements, across five main categories. These are ready to be cut-and-pasted into your content management tender, saving days of effort and ensuring that nothing is missed.
On the one hand I would obviously suggest to go open source and in the FOSS space you don't get very far by wrinting a tender. On the other hand I belive that it is going to be difficult in both the open source and the commercial space to find a product by adding up all the potential solution's features to your list of requirements.
I suggest to go either for a package implementation or to assemble your application or even go for a platform based custom development.
Depending on your situation you will chose one of the two following approaches for implementing your CMS solution:
| |
Package Implementation |
Application Assembly |
Details |
- Implement solution as is
- Adapt processes and users, not the tool
- Scope follows tool
|
- Leverage components and build user and integration need specific solution
- Focus on reuse, not on development
|
When to apply? |
- Requirements are „standard“
- Having a solution to manage content is the focus rather than a specific CM process
- Selected solution is very close to the requirements
- Low budget
|
- Complex integration and/or adaptation needs
- End user productivity and application specific process are more important than project cost
|
A combination of the two can apply if your application assembly will be based on a package that can be easily extended and that covers a reasonable amount of requirements out of the box.
For the package implementation the grouping as defined by Seth in his white paper on OS CMS will probably be helpful. Going for the application assembly it is definitely the people involved to define the process. This is what you derive the requirements from. Lists of potential features should be used to identifying some nice to haves.
But I guess the most important question is: How do the different CMS solutions (package or custom app) do what they are supposed to do? Even in open source software, which tends to be more honest about feature lists (because it is easier to verify if a feature exists and because an admission of a weakness is an invitation for someone to contribute a solution), the existence of a feature does not necessarily mean that it is useful to you.
No tags for this post.
This years Open Source Summit "Open Source goes Mainstream" is co-located with with the Gartner Application Integration & Web Services Summit, 12-13 June 2006 at the Palau de Congressos de Catalunya in Barcelona. 
The guys from Alfresco have updated their Alfresco packages on 
