Going to an OpenSource ECM World....: How to choose a *CM solution ?

Hello everyone,

The topic of the day is devoted to an old problem:

How to choose *CM solution (Content Management)?

(* represents a letter of your choice, but commonly an E or W)

This question implies many issues, include many methodologies and is unique to each project context. In other words it is not easy (or impossible) to standardize a single approach to the problem. Nevertheless it is possible to avoid major pitfalls and use best pratices. This is what we'll try to see later through a series of rules.

Note: This rules are from different feedback which you can fin as references at the end of this post. It engages only me and can't be THE good road to choose its solution ...

Rule No. 1: What are my needs ?
Need : I remind you that this is the basis ... Without a LITERAL definition of need, without use cases DIAGRAM described by LITERAL explanations , without a HISTORY of functional requirements it is necessary to start a project that will result in inadequatechoice ?
This point is the famous WHAT for "What is the future scope of my work?"

In document management project, you must identify documents type that the system must manage. What are their format, their average size, frequency of creation or modification, deletion. Who is responsible for this data ...?

Rule No. 2: What are my technical requirements?

Following the recommendation of my Enterpise Architect I must be able to retrieve information from an application. Is there a connector with this application or what's the feature which can help to retrieve this information?
From my architects, my future solution must be based on an EJB3 architecture and must be installed on Ubuntu Linux.
The operating service needs to monitor the future application via JMX.

When such constraints is known, it is easier (for both client and supplier) to choose an appropriate solution. These constraints could create a list of MUST-HAVE. It can be useful to discriminate when comparing offers. It's up to you to place your cursor on the importance of criteria (don't forget of course that few solutions satisfying all criteria)

Rule No. 3: Small streams make large rivers (translation of french proverb.)
Based on this principle or the famous KISS (Keep It Simple Stupid), it's best to start simply, quickly and humbly then verify, validate and begin to see in a second time how to extend the functionality and features offered. With this methodology, you can have quick feedbacks from your operational and this is priceless!

In the area of development this is called Agile Development :o)

Rule No. 4: To choose a solution, the rating scale/matrix you must ban!
To have performed the exercise as a consultant and as user grids are useful in fact... for nothing... Except to prove and say what you want!

For those who had never seen, here's a little description:

This is usually an Excel file with a list of criteria grouped into families, which themselves are clustered in groups, which themselves are grouped by category. Each critera has a weighting. Sometimes it's also considered for families, groups and categories ... This list represents the Y axis (from top to bottom).
Then on the X axis (left to right), we'll add different solutions. They have to pass with success or not the treatment of the matrix.
The intersection of critera line and solution column must be filled by a combination of score between 0 and 5.
Finally, in the bottom of the Excel sheet, there is the final grade. Resulting in average weights between products and notes, this note is responsible for the choice of solution. This "scientific" approach allow to find right choice without doubt!

Simple isn't it ? :o)

The main criticism of this practice comes from the "subjectivity" in the criteria selection, weighting and rating.

Example:

My need
The technical staff (designer of our products) need to share their good practices in a collaborative way.

Possible criteria
Wiki Integration in my CM System

Possible responses

Response from a consultant: For the solution X, there's a possibility to integrate a Wiki solution via the API.
Response from an editor: In my solution, One of our features can manage a wiki.
Answer from an integrator: With a little code, you can create a simple wiki system that you can connect to the solution Z DM system.

Now It's your turn. Post a score from 0 to 4.

In fact, do you ask what is the syntax of the engine? Do your colleagues want to learned a new syntax ? or do they simply want a simple (or rich) text editor, with the integration of media such as images ...?
Then you have to think how these contents are stored? How they can be reused, shared and indexed? and so on ...

Now you would put the same note?

This essentially limits the Matrix system ...

Rule No. 5: In a RFP don't require a matrix list of critera !
Corollary to the previous point, if you do not want wrong and subjective answers, don't ask to complete a grid. Simple...

Rule No. 6: With whom I want to work?
It's a simple rule but it's not always applied. Is not it easier to work with people we know and with whom we have create trust link, respect, honesty and efficiency?

Do not hesitate to meet different people who are involved both in choice phase, design phase or production. Those are the people who are foremost guaranteeing the success of your project.

Rule No. 7: You know your budget? Then don't hide it !
I know that this choice may be considered as crazy, but it will save your time! On the one hand you will know which suppliers are really interested in the project and on the other hand, it allows you to choose the product range wich best match your needs.

Note: As a fervent open-source addict, I want to remember that Open Source Solution is NOT a synonym of FREE!

Rule No. 8: Open Source or Proprietary same fight or in other language there's no prejudice you should have!
Although I am a strong supporter of open source, you can't exclude the choice of a solution due to this Proprietary approach(and vice versa!). In choosing a solution only your needs should count (and your budget of course ^^...)!
If the need is well covered by a proprietary solution and you can buy licences with your budget, why deprive yourselves?

Rule No. 9: A prototype you have to test !
Sometimes in the selection criteria, we find the words: "2.0 user Experience", or "Enriched Usability and Experience". If you have never installed or used the product how can you trust a note or a description. It is in these times that we see the usefulness of a prototype.

Small reminder: A prototype is not the final solution. It's a few days work and not your several months project result.

Prototype goal is to demonstrate the strengths and weaknesses of a product on a particular use case. In addition, you will see solution degree of mastery by an integrator, or product degree of adaptability by an editor. This is not the Supplier(Integrator or Editor) to show what the product can do but the product to show what he can do in your context. And if the prototype crashes it does not matter, it shows instead what it should really do.

Rule No. 10: I don't understand ...
You have trouble understanding the principles of content management project. Simply, call for help !

That's all folks. Don't hesitate to post a comment.

This entire article wouldn't have been possible without precious post and articles on the subject. Here are some selections:

[FR] BPMBulletin :