The process of selecting an enterprise content management system (CMS) is a complex (and long) one. There a lots of important steps and stakeholders. However, there are also lots of roadblocks and FUD (Fear, Uncertainty & Doubt) you’ll need to navigate along the way.
From my (10 years of) experience working with enterprise CMS, here’s my two cents:
Gartner Magic Quadrant, and other analyst reports
Sure, use them to create a short list, but be careful. Just because a product is a leader does not mean it is not complex and potentially expensive to implement sucessfully (and even more expensive in the long term when implemented badly). This can also the case for challengers and visionaries.
You need to do your own preliminary homework, and talk to implementers, about which products might be the right fit for your business and requirements. A leader might be perfect for business A, but a challenger might be better suited to your specific needs.
What are your 'must haves'?
As you’re doing your research, collate a list of features you come across (in conjunction with features you already know that you need). Consider, do you need features like workflow and translation integrated into the product or do you already have solutions in place?
Ask different factions of the business to perform prioritization on the items, and use this to determine your organisation's 'must have' feature set.
For example, maybe simple translation is critical but WYSIWYG editing is a nice to have. Personalization might be number one on the marketing priorities, but all too often it is bottom of the priority list in development.
Developers might call out features business would not consider, like programming language limitations and application architecture desires. Maybe they only want to consider Java compatible platforms, and would strongly weight a system that can deliver content via a web services interface.
Look beyond features
Features are key, don’t get me wrong, but it is likely you’ll have several CMS options that tick all those high level boxes.
Next look beyond the features to items such as:
- Required skill set and knowledge gaps
- Availability of information, and the existence of an active online (and offline) community
- Product roadmap
- Implementation Partner network
- Estimated cost
Compiling a shortlist & RFI
Using the information gathered in the previous steps, it’s now time to generate a shortlist. These are the vendors you’re going to explore in more detail.
You’ll likely ask your shortlist to complete an RFI, but be smart about it. Asking “can your system deliver translated content?” will get a yes from everyone. Word your questions (and available answer options) to differentiate vendors. Specific questions with tiered answers, like:
Can your CMS deliver a contact us form out of the box?
- Yes, with no development
- Yes, with some development
- Yes, with third-party integration
Don’t expect too many number fours.
Overall, RFI’s are going to be answered with rose tinted glasses, so take them with a pinch of salt and fully validate your important use cases further.
Following RFI, and onto vendor demos, and this is where it gets fun.
If you can, provide the vendor with a list of use cases you’d like to see, that represent your key workflows and feature requirements. Otherwise, you’ll likely get (especially from the big players) a very well rehearsed walk through some specific use cases. This is where you need to be on the ball, and see through the smoke and mirrors. The best way to do that, is ask questions like:
Is that feature out of the box? How much development is required to develop that feature Is that feature an additional license fee? Is this a real environment, and where is it hosted? Is it all hosted on a single VM on the demo laptop/ What are the specification of the machine? Is it a supercomputer capable of powering NASA? Can we have access to the demo environment after the presentation, to have a play ourselves? Can you demonstrate in our context, to help us understand? How would I do A, B and C which are in our roadmap.
I’d also always suggest having a mixed audience (or several focused demo sessions) so business can probe on the marketing capabilities while technical check it is a product they can work with.
Don’t underestimate the personal
I mean this in both ways. Personal chemistry can be the difference between a project's success and failure. A vendor relationship, can get that extra bit of support right when you need it during a project.
Also be wary of the opposite. You might never see these people again. Vendors tend to send out the A team for sales demos.
Scalability, Maintenance & Future Proofing
Can the product grow with you, or do you need to buy everything up front. If you company doubles in size, acquires a competitor or decides to outsource content creation to the Philippines can the system handle it?
Proof of Concept (POC)
A proof of concept is vital in my opinion, and really lets you see what a product would be like to live with.
If you decide to perform a POC, make sure you set a level playing field and compare apples with apples
- Are vendors allowed to bring in pre-built solutions to be customized by your team or do you want to build it from scratch
- Set common objectives, like build a product landing page (talking to our product back-office) that can be deployed in 5 languages
- Include technical, business, Q&A and content creation as all roles need to give input
I’d highly recommend asking each vendor to involve one of their implementation partners at this stage. It doesn’t mean if you chose the product, that is the agency you’ll use, but it allows you to get a feel for the level of competency you can expect if/when you do partner selection.
Price & Package
If you’ve still got a real two horse race after all these steps, then you can let the vendors duke it out over the details like price, support agreements, included professional services hours or additional modules freebies.
The CMS selection process is by nature complex, but with a plan can be a productive one.
Having a clear, measurable, plan is critical before you start the process. This is what will allow you to compare CMS vendors on a level footing, and not be influenced by slick (pre-rehearsed) sales demos that will inevitabley be shown. After the WOW demo, you can refer back to the plan, and compare your predefined objectives, to see through the glitz.
In my opinion, there are 5 things any plan must include:
- The problems (or scenarios) that are the reason you're looking for a CMS in the first place
- Key decision makers, representing all aspects of the business
- Must have, Should have and Nice to have features
- Usecases that you'll request vendors to demo
- Functionality you'll proof out in each CMS, with clear measurable results identified
Stage Two has several members who've been through this process many times. We're well positioned to help as part of the decision process, lead the team in an SDL proof of concept or work without to utilize your investment.