The implementation of CMS / Portal software is not least critical for a client than the product itself. Actually it is even much more as what matters to the client is the final implementation. Strangely, it seems to me that this topic is not so much discussed maybe because not a matter of technology but mainly a matter of management and business. I can nevertheless recommend reading the great blog CMS Myth.

Also rather rarely discussed is the relationship between the software vendor and its partners.

Basically it is well known that one will find two models: vendors making themselves the implementation and those relying on their partners’ network. The first is the so-called “direct model” and the second one the “indirect model”. Things are not so Black and White on Earth and much more Yin and Yang, so usually vendors are using both modes depending on their strategy, their management, spring or autumn and… opportunities even if, as usual, they might pretend the opposite.

That said, every vendor should clarify its intention and assume the Pro and Cons of each model. Every business person will try to leverage benefits of both, but, and that’s what I like in business, at the end of the day every vendor will need to assume its choice. Actually the twitter mania / blog & other social networking are helping a lot making things clearer. Choose any side you want, but you will be known for your decision: direct or indirect or a mix of both with clear rules you actually apply or no rules but the vendor’s short term interest.

Any rule works. If *no rules but vendor’s short term interest* won’t prevent the vendor getting new partners and new clients, it will certainly not help the vendor building a network of skilled partners, able to be successful at integrating the product.

That’s why clients should be aware of the vendor’s policy about the integration model direct / indirect.

The choice of Jahia has been for long to rely on its network of partners. It does not prevent us for knowing somewhere how making an implementation:

1) To support actively clients who don’t want to have integrators and want to make the integration work themselves,

2) To do the implementation ourselves when the client demands it (yes it happens…),

3) To train the new partners of Jahia and let them integrating the software for their clients successfully.

We have written this policy in our (public) business partner program.

So it means for our clients that we can help in different ways them but will not compete with our partners. We can do a part of the implementation ourselves if they want – especially if we have no partners in a given location – but we don’t try to be a fine young cannibal because the strategy is to transfer the knowledge (about our software) to our recurrent partners and – we don’t hide that point, to take benefits from the strong commercial network of our partners. We like to work with the same partners and we welcome new partners who convinced us they should become recurrent partners, whatever the reason may be. But we are quite realistic on their real motivations, so no reason to hide the real intentions.

Why? We just prefer to focus at the product development and supporting our clients and partners rather than diversify into complex services somewhere quite far from our product core business – we won’t get any strategic value for becoming an expert in “MySQL –in-cluster integration” (for example)!

In conclusion, I believe any policy works, but it should be clarified for clients’ and partners’ benefit and should be consistent with the vendor global strategy.

That’s a quote I have heard so many times…

I have never been convinced by the market segmentation between so called “Content Management Systems” and “Portal Products”. I understand it (well at least hopefully, I am CMS/Portal Vendor). I understand very well why it remains so, but don’t see where it really complies with end-users requirements. In a forum on LinkedIn, I replied to this fantastic question:

What is the ideal CMS for a large enterprise intranet portal?

(Not surprisingly, he is asking for a CMS ... for an intranet... which he calls guess what... a portal). Here is a copy of my answer, basically some thoughts about intranets, CMS and portals:

 “Vendors rarely focus – or even market - their offer specifically for global intranets because they usually believe, sometimes wrongly, there is nothing specific there. From a pure technical point of view, it is not that wrong, but conversely, global intranets may have neither the same priorities, nor the same constraints than other web projects. So I would recommend focusing at those strong at what matters the most for your project, like the others explained you already.

But let me try to be more specific:

One of the classic specificity of intranets is how critical the adoption by the contributors is. And there are often A LOT of contributors for global intranets (if not potentially all the employees in a web 2.0 likely to be company). You don’t get the support of the contributors, it is a failure, as usual but getting it is tougher (usually) for intranets. So you should focus at products extremely strong when it comes to massive contribution by many non technical people, fine rights/roles management (more than that, easily customizable) and of course some nice personalization features. The contribution process & workflow should fit perfectly to the culture of your company and to its organization.

To me, a POC (proof of concept - small project developed in a few weeks maximum but really used for production purpose – e.g. departmental intranet pilot of the big one(s) to follow) is much better than just a demo. Vendors can be extremely skilled to show in a 2 hours demo how their products fits to your requirements even when it fits “just a little bit” (believe me, I am a CMS/Portal Vendor ;) ). Intranets projects can easily fail, POC is helping a lot preventing such failures…

You also have to know that for vendors, intranets can be extremely complex web projects and extremely specific to your own project (of course they will argue the opposite), so it looks essential to chose one able to scale, to modify or customize its product or able to be integrated with others (or conversely). Flexibility (technically and commercially speaking) of the vendor is therefore a strong asset for the success according to my experience.

The fact that you are using two classic words “CMS” and “portal” for one single project looks very interesting to me and obviously is disturbing for all... Indeed, the split between the two categories is becoming more and more obsolete (well, my personal opinion) even if – for different reasons – the community like to keep it alive and kicking. Your association of words is not surprising because intranets require personalization, embedding business application like portals do, but also managing a lot of editorial content like CMS like to. And you may add some – or a lot – of web 2.0 things which belong to both more and more.

I will not give names of products I believe to fit with global intranets, I can be objective on that as myself a CMS/Portal vendor, but I would recommend choosing your product carefully maybe with the support of consultants NOT involved into any company able to provide you services around a few products (real neutral vendor consultants), it would be tough for them to avoid rather pushing for their “preferred” product rather than for the one which fits the most to your projects. Should the consultant not be “Vendor Neutral”, the conflict of interest would be obvious.

In conclusion you asked the good questions despite any specifications. Intranets are often both a CMS and a portal, and rarely simple projects and rarely easy to be adopted by the organization. So the right product for the project is more important than ever, and product not only means “features” and “technology” but also “people”.