Portal/CMS selection, some alternative criteria

When selecting a portal/CMS, there are business standard ways to select one:

• Formal RFI, RFP processes
• Formal reports from the likes of Butler and Garter
• Mesh requirements to features
• Cost
• Installation consultancy, on-going support provisions
• Top level Company/IT strategy considerations:
• In-house versus outsource
• Open-source vs commercial vs hybrid
• Technology stack (production support) and language (development)

What is one key flaw with the above list?

You don't actually know if the solution will *work for you*.

The above approach is primarily business oriented and only superficially technology oriented. It is sales and marketing information used by non-technical decision makers. It is information contrived to make a sale. I really believe this is one key reason why so many IT projects fail. Products such as CMS software is selected with only light technology considerations.

And when I write "work", it's more than just the pure technology itself. It's also about integration into your existing environment, IT team adoption, bugs specific to your use of the product, and fit for purpose with respect to your requirements. It's about de-risking the technical side in parallel with the business side.

Don't get me wrong. The above list is important. It primarily provides information to help you sell the proposal with non-technical bosses, stakeholders, and downstream customers. It helps you learn about the partner and your requirements. But if you want to enable a successful project, you should be de-risking deeper technical aspects as well.

It's also important to maintain a commercial view, for example:

• TTM (Time To Market) requirements
• Off-paper requirements (e.g., common shareholders between your and the other business; individual relationships)
• Forecasted revenue benefit to project (i.e., how much can you afford to vet)

Given all this, there is a lighter (higher risk, less work) and heavier (lower risk, more work) investment approaches to software selection.

Light weight investments that can be done relatively quickly (in a week or so) and at lower cost:

• Check in with colleagues that have been involved with portal/CMS creation, selection, and deployment. Similarly, if you can, determine what your competition is using.
• Research forums. This is particularly useful for open source or mixed open/commercial source solutions. Look for use of the product that mirrors your intended use - what issues are people reporting? How do the issues change over time?
• If available, review product case studies. Do the case studies reflect your intended use of the application? For example with portal/CMS, are you trying to build a b2c customer facing website and the case studies are all about ECMs (Enterprise (Intranet) Content Management)?
• Where is the company based? What is their primary language and how does that compare to the project's primary language? Cross-cultural issues to consider?
• Use google to look for your proposed CMS - how many pages come up?
• Go to a recruitment/jobs site like jobserve - can you hire developers and systems administrators that have experience with the CMS?
• Use google to look for consultancies - on-shore, offshore, outsource - that specialize in the software you're considering
• Similarly, talk to recruitment agency contacts and ask them what CMS experience they have on CVs and job placements they're working on
• Perform a more detailed analysis of the system architecture and compare to your own competencies

Let's consider a practical example of the lightweight approach. We are considering two possible portal/CMS/website technologies, Day Communique CQ5 and Alfresco. From a non-technical perspective, we're favoring CQ5.

Checking in with colleagues and in the industry:

• Most sites have a hand made portal and CMS for their core customer system. This isn't surprising for igaming as most sites are transactional/functional (not content) oriented.
• Some PHP portal/CMSs are in use. Again, not surprising as PHP was and continues to be the techies choice of underpinning CMS language.

Forums: TBD

Case Studies:

• Communique/CQ5 had eleven case studies, one of which looked like what we need to do
• Alfresco had 24 case studies, not yet reviewed.

(Aside: note how Alfresco uses "case studies" in the URL and Day does not. I'm might think that Alfresco has people involved that understand SEO and Day does not. Or it could be a language thing.)

Location and Language:

• Alfresco is UK/English
• Day is Swiss/German

Google basic search results:

• "CMS Communique" yields 323,000
• "CMS CQ5" yields 11,800
• "CMS Alfresco" yields 961,000

(Aside: Day has made search/SEO particularly hard on themselves as they appear to be moving from "Communique" to just "CQ5" and also sometimes including the "Day" company name prefix rather than just a name. Compare that to Alfresco which goes by... Alfresco.)

Jobserve results:

• Communique or CQ5 yields 2 job postings
• Alfresco yields 10 job postings

Google results for consultancy: TBD

Google results looking for outsourcing and offshoring:

• "CMS alfresco outsource" yields 17,600
• "CMS alfresco offshore" yields 5,130
• "CMS communique outsource" yields 6,470 (CQ5 is 384)
• "CMS communique offshore" yields 12,900 (CQ5 is 2,040)

I also had one colleague report pain dealing with Alfresco consultancy and support.

System architecture review: TBD

(NB: the TBDs here are due to a time limited review and some prior knowledge of both systems.)

I'll let you draw your own conclusion for the lightweight approach.

Heavier cost and lower risk approach is to do two or more Proof of Concepts (POCs). Create an end to end working system that demonstrates some difficult (high risk) functionality. Determine if the system actually works to the hardest bits of your unique requirements. This can be done independently (cheaper, higher risk) or in collaboration with a vendor or consultancy (more expensive, lower risk).

A practical example of the heavier approach? As you might guess, it's TBD!

In conclusion, you'll have some variable amount of time to evaluate portal/CMS choices. Be very wary of a selection driven only by business and not technical reasons. While it might be a commercial reality that you're forced to not technically qualify a choice, you can now at least quantify what should be done and some consequences if you don't do it.