The hidden costs of CMS projectsHow could we make decisions to implement cost-effective CMS projects?
When redesigning a website, many clients believe that the business problem that a content management system (CMS) integration should solve is the elusive “we can update content on the site on our own."
Why elusive? Surely, it is reasonable for me to update paragraphs of text on my website without development support. Or, to bold some words, add some links and maybe, add a image or two? Or really, to meet some new business requirement that may sound like…
- “According to our analytics, we need to add a call-to-action on our banners."
- “We need to add a new data attribute to links for our SEO partners to track using Google Tag Manager."
- “We engaged a design agency to design our new product’s marketing micro-site, let’s put it on our CMS."
After all, CMS integrations do not come cheap and it can be difficult for businesses to acknowledge that some content cannot be updated and additional costs have to be incurred to accommodate the business requirement changes.
Well then, how can clients like you effectively make decisions that will help you to respond to changes on a long-term basis? To know the answer, we must first understand what makes CMS projects costly. We have for you a shortlist of dos and don’ts to aid your understanding.
Don’t: Pick a CMS with more features and functionalities than what you really require
In layman terms, CMS can be described as a technology stack that includes:
- The database that stores the content.
- The frontend that your customers interact with.
- The backend that your team manages and controls the different aspects of your frontend.
The backend is where we see the vast difference in both features and costs among different CMS. Over the years, CMS has become a catch-all term to include web content management (WCM) platforms like WordPress and digital experience platforms (DXP) like SiteCore and Adobe Experience Manager.
CMS with more DXP features tend to come with a higher price-point and implementation timeline, with an average license costs for Adobe Experience Manager Sites (version 6.3) at USD$350,000 and for Sitecore Experience Platform at USD$200,000. These tend to be suited for businesses with a higher budget to implement and who are able to train their employees to take advantage of these features.
Therefore, instead of being awestruck and blindsided by fancy and sometimes unnecessary features, you should always sit down and carefully consider the necessary and important features that your business needs. Otherwise, you may end up buying features that will never be used or would not be used correctly.
Do: Prioritise CMS usability for your editors
The usability of the CMS matters. It matters to both customers using the website and to your editors who are managing the website’s content. Editors who are not involved in the project until the later phases of the project (such as testing or training etc) tend to be shocked at how content creation would become such a chore.
To add more cards, switch to the HTML mode, copy and paste this snippet of code, and change the text accordingly.
Some CMS comes with out-of-the-box usability issues, while others tend to be created by half-baked project requirements like…
(In a WordPress project) We can update most of the homepage content using the admin interface, but here’s the SQL statements we run to update the rest of the content.
End-user training is not a magical solution to usability. Can you imagine having to undergo a 3-day training course just to use your new iPhone? This is not only time consuming but also highly inefficient.
Therefore, you should always prioritise usability for your customers and editors to ensure that your website would achieve the most flawless experience for your customers and the most time-efficient operations for your business, which would help to reduce costs in the long run.
Do: Consider the CMS’s ease of customisation and ecosystem
Traditional CMS combines its own code and the front-end presentation in a single monolith.
No matter what the CMS vendors claim, there is no single platform that offers everything, which is why development is usually necessary to customise the CMS to your project needs.
Most, if not all, CMS usually have a set opinion on a right way to do something, which is referred to colloquially as “opinionated”. Being opinionated is not necessarily a bad thing, but it does have an impact on the cost of customisation. If the project requirements for a specific feature goes against what the vendor considers as best practice, the workaround can be more difficult than it should be.
The opinionated nature of CMS also creates its ecosystem of partners and developers - the people who will support your CMS over time. Because these CMS demands its own best practices, developers have to be fluent in both the language and the framework to extend the capabilities of the platform.
Depending on the choice of CMS, the simplest tweaks have the potential to turn into costly and complex integrations.
What else should I do?
Just like how you will evaluate an app on the app store, the fundamentals are fairly similar: have a thorough understanding of what you (and your team) needs and research the product and its ecosystem thoroughly.
As vendor demos are usually orchestrated and rehearsed, nothing beats trying out the out-of-the-box CMS for yourself. If a small-scale demo does not inspire confidence, chances are that a full-scale deployment will not perform any better. You have to be confident and comfortable of your experience before you can expect your team and your customers to feel the same.
When it comes to implementation partners, ask for references and ask the right questions instead of staring at a selection of “websites built on our platform”. You could consider these questions: how much were they built for? How long did it take? How does the content authoring experience feel like? How was the project experience?
You could, perhaps, even look at alternatives or a combination of smaller technologies.
Did you know…
The PSYKHE website was initially built on WordPress ($0) and hosted on AWS LightSail ($5 per month). Our site has since gone static, built using Hugo ($0), a static site generator and using forestry.io ($0) for content updates.
We understand that selecting the right technology stack to meet your business requirements is not easy given the ever-changing technology landscape, but fret not, for we are here to help you figure this out.
At PSYKHE, we are focused on:
- Putting user needs and goals first.
- Ensuring that we can respond to changing user needs.
- Designing for the people in your organisation who will help to meet the objectives above.