How to buy an enterprise level Web CMS

Web Content Management Systems come in all shapes and sizes, from simple blogging platforms to enterprise systems, requiring different levels of expertise, resource, budget and time to successfully specify and install.    Broadly speaking enterprise level refers to business systems that are designed and built to specifically fit the needs of a ‘large’ organisation. They often involve a longer sales cycle (6-9 months), pre sales technical support, demonstrations and multiple stakeholders on both client and vendor teams.    Typically the solution will be:

• Flexible - providing an easily customisable framework that can meet any custom business or user requirements, rather than just an ‘out of the box’ solution
• Scalable and reliable - capable of handling peaks in website traffic and increasing volumes of content assets without any adverse impact on performance
• Capable of integrating with other internal systems - such as ERP’s, CRM’s and also other web services and SaaS products
• Secure - CMS platforms can be high profile hacking targets, so solid security certifications are a must
• Requiring ongoing technical support - usually provided by either the vendor or the service provider delivering the implementation
• Licenced - Ongoing annual licence fees (typically 20-30% of the initial investment) will ensure that upgrades, fixes and new features are made available
• Capable of delivering advanced mature features - such as marketing automation, multilingual, eCommerce, advanced workflows 

The following 10 points cover key areas for consideration when embarking on selecting the best enterprise CMS for your organisation. 

1. Get organisational buy-in 

To do this you need a team of stakeholders who will support you and jointly decide on the best CMS. It’s important that they are fully immersed in the process and feel empowered and accountable for the ultimate outcome.    Depending on the scale of the project the team may include:

• Marketing Manager/Director
• Digital Manager/Director
• IT Manager/Director
• Inhouse designers
• CMS end users - marketing executives and content administrators
• Financial Accountant
• A board member

It’s essential to ensure they feel fully involved in the project and that they understand the aims and selection criteria you are setting. Only by doing this will they take ownership of the project and become a supportive stakeholder that is on your side.

  2. Introduce rules of governance  

Depending on the size of your project team you may need to consider introducing some clear lines of governance that set out the levels of involvement of the various team members. For example senior stakeholders may only be required for sign off at key milestones such as specification sign off, budget sign off and the later stages of supplier selection. Conversely, administrators may only be required to sit in on CMS demo’s.

  3. What business problems are you wanting to solve? 

Be explicit about what business problems or challenges you want to solve then gather evidence to support this. From specific end user needs to improving marketing and sales lead generation and business processes that can be improved or delivered more efficiently online. This involves a broad remit across the business and understanding how different divisions of your organisation work.      Once you have a better understanding of the high level challenges you want to tackle then this will enable you to broadly define the scope of the project and which technology partners you should be considering. 

  4. Identify the true cost of ownership

This relates to 3 potential areas of cost:

• Licensing
• Training
• Ongoing support

At an enterprise level it is likely that the software vendor will charge a licence cost, though we should also consider the potential cost implications of non licensed ‘open source’ software.   There are two licensing models to be aware of: Perpetual and SaaS - each has a different approach to pricing and ownership.   Perpetual Installed into your own hosted environment and managed in house or by your agency.

Benefits:

• Flexibility of deployment
• Ownership and direct control
• No constraints on administrative customisations

Downsides:

• Bigger up front cost
• Upgrades can be complex
• Regular internal support more likely  

SaaS Generally a more agile solution that doesn’t have the initial setup complexities and costs of the Perpetual licence approach. 

Benefits:

• No burden of installation
• No high server costs - ease of setup and entry
• Less IT support required ongoing
• Ongoing upgrades taken care of

Downsides:

• Generally not suitable for larger enterprise level projects
• Less functionality made available
• Potential security issues from not having direct control over the hosting provision

While ‘open source’ software is perceived as being free this is often not the case as costs can quickly be applied, for example through using the support desk, adding additional users, adding extra features.   The costs of training can vary dramatically from system to system but the fact is that it’s necessary. Typically training enables tasks to be carried out 20% faster. So over time the cost savings can be significant. Make sure you ask vendors what training packages they offer, how they are delivered and the cost. For more information view this article prepared by our inhouse CMS trainer http://www.quba.co.uk/blog/march-2017/the-value-of-investing-in-web-cms-training   It’s likely that support will be delivered either direct by the software vendor or via the service provider, who may escalate some issues to the software vendor. Either way like training, support costs can vary dramatically and be clear at the outset on how support is delivered, response times and how all this is charged for can avoid some nasty surprises later on.

5. Know your Minimum Viable Product (MVP) and stick to it

 Try not to view your website CMS build as a one off project with a huge specification that delivers everything possible in a big launch.   It’s much better to work out what is an acceptable MVP to go live with and stick to it. For most websites feature are likely to change in function or maturity every 18 months. So it is ridiculous to try and deliver an enterprise project in one go. If you're taking a year to 18 months to release the initial product you will almost certainly be rebuilding some of the system very soon after launch.   Work iteratively and fast. Releasing feature by feature. Build a backlog based on user feedback and organisational drivers.   Your web platform should enable you to change direction easily. Using an agile approach carrying out changes and tweaks based on insights and data measured against KPIs will ultimately ensure your business problems get solved. 

6. What integration challenges do you need to meet?  

With enterprise level web projects, integration with other systems is likely to be required if significant business efficiencies and benefits are going to be realised.    For example:

• Your internal business systems:         Stock, accounting, CRM, ERP
• Other SaaS systems:                 CRM, accounting
• Other web services:                 Email, analytics, social media, payment gateways

  The CMS platform you use will need to be capable of integrating with external APIs (Application Programming Interface) using interfaces such as REST and SOAP, which will enable the external systems to communicate with your CMS.

7. Do you really need to control every aspect of your website?

Be honest about how much content you will ‘actually’ need to change.   There’s no point creating a fully content managed website and only changing certain areas of content once a year. Consider a hybrid approach with some static designed pages and others CMS. Keeping to a maximum 70:30 of static to dynamic content is a good rule of thumb, otherwise the platform can become unstable, you will avoid spending a large amount of budget/time scoping and building unnecessary CMS managed pages that can often be too  complicated for users to learn to use.

8. Content migration

If you have a significant volume of content/data (for example a large product database or a document repository) that has to be migrated across make sure that the proposed CMS is compatible and won’t require huge amounts of technical input to ensure this happens. Migration can be very costly though often more preferable to re inputting the data.

9. Avoid over specifying your needs

It’s easy to over buy enterprise CMS software especially if you do not have a defined specification or requirements that can set some clear boundaries. CMS demo’s are notorious for selling in seductive features and functionality that are perceived as being necessary as they reduce the risk of failure by adding in more (often unnecessary) capability.   This is a double edged sword as not only is it adding on costly, unnecessary functionality but it also adds additional scale and complexity to the project and delivers a solution that is overly complex and more challenging for CMS administrators to manage.   It’s wise to reel the specification in for your phase 1 MVP launch then assess what additional functionality may be beneficial to incorporate at a later date once you have had chance to assess the overall CMS performance.

10. Customisation capabilities

Most CMS platforms will have features that are ‘out of the box’. However it’s likely that they will not all be specific to your needs so a level of customisation may be required. Being able to customise aspects of the core system will reduce the need to adapt your internal workflow and processes to fit within the rigid framework of a system.   By selecting a CMS that from a technical developer perspective is easy and flexible to work with will pay dividends over time as there will undoubtedly be situations in the future where the system needs to evolve to meet specific requirements.