This is the final installment of our “CMS for the CMO” series. In part one, we reviewed what a CMS is and why it’s so important as the centerpiece of your marketing efforts. In part two, we dug a bit deeper into the history of CMSs and the common ways that CMS platforms are architected today.
At this point, you should have a pretty deep knowledge of why these systems matter and how the differences in architecture can affect your organization as it grows out its digital ecosystem.
In this final post, I’m going to get into more detail about the actual procurement of a CMS platform or product. By now, you hopefully have some idea of the role your CMS should play and the architecture that best serves your purposes. The idea this week is to help you procure the right system, ask the right questions, and find the right method of implementation.
We’ll accomplish this by digging into areas such as license agreements, defining the risk factors you will need to mitigate, creating a list of requirements, helping you finalize your choice, reviewing implementation costs, and even preparing you for common “gotchas” that no one ever seems to mention during the sales process.
Let’s begin by reviewing license agreements.
Explaining Licensing Models
The CMS space is littered with different players, and it’s also inundated with a ton of different license models. For the most part, they fall into three categories:
- Commercial
- Open-source
- Subscription or software-as-a-service (SaaS)
Commercial CMS platforms are those that are typically closed-source, commissioned by private companies and licensed to customers for use but not redistribution. Open-source licenses vary, but for the most part, open-source software is made available to be freely used and redistributed (more on that later). Finally, SaaS or Content-as-a-Service (CaaS) platforms will charge subscription fees for usage of the software and infrastructure, a model that is slowly gaining traction across the board.
One final note about CMS platforms in general: It’s important to know is the difference between on-premises and off-premises, which is often denoted as “on-prem” or “off-prem.”
On-prem software is software that you install on your own servers, hosted either in-house or via providers such as Amazon AWS, Rackspace, and the like. These platforms come as installable systems, usually requiring other software underneath to operate correctly. Most all commercial and open-source platforms work this way.
Off-prem services typically loop in infrastructure as part of their offerings. This reduces your liability for hosting, support, maintenance, and so on. Understanding the differences between on- and off-prem helps you when making a comparison between providers, as on-prem infrastructure has a cost in terms of both servers and manpower to maintain.
Commercial Licenses
Commercial licenses are those that are offered by the major CMS developers such as Sitecore, Adobe, and the like. There are literally hundreds of companies in this space offering commercial CMS packages. To make matters more confusing, commercial companies can play in both the closed- and open-source space.
To make it easy, let’s begin with closed-source code.
Companies that are producing CMS products end-to-end—which means producing the actual underlying code—are participating in what is known as a closed-source licensing model. This is much like any software you run on your computer in general, such as MS Word or Excel. You don’t have much (or any) ability to change the core functionality, but you may be able to extend the software via additional licenses or plugins. Commercial CMS providers will charge you license fees based on any number of scenarios, such as how many CPUs (loosely meaning servers) run the software, how many domains you serve, how many users utilize the administrative panel, how many pages you serve, or even based on usage such as pageviews or sessions. The financial licensing models for these products are literally all over the place.
In addition, commercial providers also count on other revenue streams to augment their bottom line. This includes support or maintenance services, which could mean nothing more than simply keeping the software updated. It also includes phone or email support with a guaranteed SLA. They may also upcharge for training or knowledge transfer to your staff.
Keep in mind that license fees, including any add-on packages, do not include implementation. That means for all of those fees being remitted to your provider, you will not be getting design or development assistance. Implementation fees are represented by what you either do in-house or hire an expert agency to assist with. Plan for implementation fees (including maintenance) to cost a multiple of your license fees for the first year. Some common figures are 2x to 5x. And plan on providing hosting, support, and all that goes along with maintaining your own infrastructure.
Within the commercial license world also exists providers that are extending open-source software. This is an interesting scenario where the core product is an open-sourced platform, but the provider is adding to the product with either services or features. If you are familiar with what WordPress VIP is up to and how Acquia works with Drupal, you have a sense of these particular offerings.
The commonality here is that these companies are working to provide enterprise features and support to open-source platforms. This means that their license fees can be based on the additional features that perhaps these platforms are missing or on actual support for their users as opposed to relying on the open-source community to help in a pinch. They too can offer training and knowledge transfer to their end users in a structured way.
Open-Source Licenses
Open-source software has been all the rage for many years now. The concept is that a community maintains a codebase in an organized way, making the software available to end users to modify, amend, and distribute (in most cases) any way they deem fit. Another model is when commercial developers simply open-source their code, making it freely available.
The legal aspects of open-source licensing are complex. Many enterprises are somewhat scared of code that is maintained by a community and available to everyone, thinking that it invites security issues as there is nothing proprietary about the codebase.
While, to an extent, I do agree that many of these off-the-shelf software packages are security nightmares, you also have to consider that many of the closed-source platforms are working on open-source back-end code or libraries anyway, which kind of negates the entire argument.
If you are truly scared about open- vs closed-source, you have to commit to a world of licensing fees not just for the CMS, but all the way down to the web server, backend scripting or programming framework, and database.
I’m not so worried about the safety of open-source on the back end of a server. Servers are highly secure and you can lock down many of their vulnerabilities relatively easily. As I mentioned, I do worry about open-source CMS platforms which have a host of security issues—especially those that don’t police their plugin libraries. We’ve posted a lot about that in the past, so I won’t harp on it too deeply here.
The one thing that you should consider when going open-source is the type of licenses available. The most popular that we see are the GPL and MIT licenses. You can read up about these and the many other license models at opensource.org.
Subscription-Based: Headless / SaaS
I hate to bunch these two together, especially since headless, API-driven CMS platforms are lightyears ahead of SaaS-based systems in terms of being enterprise-friendly. But they do have similar license models, so in the interest of time, I’ll loop them together in one section.
The shared crux of these services is that they charge you based on subscription fees or usage. Most headless providers are doing a mixture of subscription minimums and usage fees when the API or storage usage exceeds certain ceilings. The same goes for SaaS systems, which can get even more creative by charging per page, by traffic usage, etc. But either way, they all are ongoing commitments.
For the purposes of this series, I’m going to set aside SaaS-based products such as Wix and Squarespace—you shouldn’t even consider these. But with headless technology, you have an increasingly appealing product where the subscription fees add up to more than just a license—they also include infrastructure costs.
When you are considering what your total budget outlay is for your organization’s web initiatives, it’s often easy to overlook infrastructure. This means hosting, support and maintenance, uptime monitoring and response, backups, etc. Headless CMS providers have pooled all of that into a common service.
It’s important when you consider budgets that you plan for those costs in your comparison and also try to predict future usage. Some headless providers are not charging based on usage, but rather on flat subscription rates, which, for a scalable application, is a key advantage.
One final note: Headless providers are providing the CMS, the API for data transference, and the storage of files such as rich media. You do need to host your front end. But utilizing newer technologies such as Angular, Vue.js, or React means you can rely on frustration-free cloud hosting such as Amazon’s S3 services or similar to simplify your infrastructure.
Determining Your Requirements
The most important thing you can do during the CMS procurement process is understand specifically what you need. This is something you should bring to the table before talking to a vendor or an implementation specialist.
The best way to do this is to define your routine tasks, which is what you require from a day-to-day perspective, and then identify the edge cases that may be necessary.
Defining Edge Cases
The best way to define an edge case is to look at the Pareto Principle. Also known as the 80/20 rule, this observation (not a fixed law) says that 80% of the output is created by 20% of the input.
In the case of CMSs, I’d define it as 20% of the features handling 80% of the usage. Most of your day-to-day work is going to happen using 20% of the features that typically revolve around a common theme: adding, editing, and deleting content. Edge cases are those that live in the other 80%, and this is where you have to be very careful when looking at CMS platforms or products.
Commercial products need to satisfy as many use cases as possible. They want to say they can cover nearly 100% of the things a marketer would have to do. In reality, that isn’t anywhere close to feasible—no system can address 100% of all possible scenarios. And in the pursuit of that goal, while many commercial CMSs demo very well and do things you didn’t even think you needed them to do, they may not actually do any of those things particularly well.
Your job in terms of choosing a CMS is to focus on the platforms that do the 80% extremely well and have the ability to handle edge cases without much “hacking.” Hopefully, you can find a system that is configurable from the ground up, not from the top down. That means, instead of removing all the junk you don’t need, you can actually add onto the core features you require.
Must, Should, Could, Would
The best way to prepare for CMS demos and the implementation procurement process is to define your requirements in four distinct lists:
- Must Have: Things you can’t do without. Most of this is the 80% mentioned above.
- Should Have: Items you use or will use in the near future and want to have as part of your initial project.
- Could Have: Features that, while not mandatory, would be nice to have and that you can see yourself potentially using once in a while—not deal breakers.
- Would Have: Features that may be necessary in the future, though there are no plans right now for their usage.
Having an organized list of features like this makes whittling down your list of possibilities much easier. Don’t focus only on features and functionality when making this list. You can include anything! Must-have items can include budget ranges, mandatory security, or technical/platform requirements. This isn’t your time to write a specification, but rather to write a list of items that will qualify or disqualify certain platforms or providers.
Here is a sample list for a B2B informational, lead-generation website:
Must Have:
- Content management with approval workflows (multi-user administrative capabilities)
- Open-source platform – no closed-source or proprietary technology
- High level of security – SSL, no third-party plugins
- Integration to marketing automation and/or CRM software
- No license fees
- Implementation cost < $50,000
Should Have:
- X months follow-up support
- Hosted with implementation partner
- API data feed
- 24/7 uptime support
Could Have:
- Ability to personalize content
- A/B testing scenarios
Would Have:
- Login portal for customers to login for specific content
This is a simple list. Yours may have over a hundred items. But this gives you a sense of what would fall where.
It is mandatory in this scenario that there is an open-source platform that can be secured, has an administrative approval process, and has no ongoing costs. This fictional organization would like to have support provided by the implementation partner for X months with hosting included. It would be nice to be able to do personalized content and A/B testing. And someday, there could be a user portal for customers to log in, so planning for that would be nice, but not mandatory. In terms of those edge cases, place them where they fit in terms of importance.
So, how can you use this list? Utilize the same principle: Spend the majority of your time working on evaluating the items you need from the top down. Spend 80% of your time with each demo on the must-have items, 10% on the should-have, 4% on the could-have, and just a fraction of the time on the would-have capabilities. You wouldn’t want to demo in the reverse, which would be a waste of your time—and the time of whoever is giving the demo or presentation.
When you are in the midst of the demo or presentation, don’t be distracted by the depth and breadth of the features you are being shown. Remember, much of what you will see is fluff—features that are being built out in a complex or unnecessary way to attract a large audience. Focus on your unique needs, and focus on how the platform accomplishes your goals without getting overly bloated and inundated with items you don’t need.
When evaluating commercial software, ask how the functionality you don’t need can be excluded. With open-source, ask how you can build out those edge cases. If neither is doable, you may be going down the wrong road.
Evaluating Risk Factors & Unknowns
With a list of requirements assembled, now I want to shed some light on items you may have missed.
With every CMS project, there is a level of risk. Your job in procurement as a CMO is to mitigate that risk as much as is possible. We’ve assembled a list of items that you should focus on from a risk perspective. These items should be carefully considered as you shortlist vendors and platforms or products.
Security
I always list this as the biggest risk for a CMO. Most people don’t think of this as a risk until something bad happens. It’s one of those items that isn’t sexy enough to think about twice—until you need it, like insurance!
However, security should be your number one requirement. If something were to happen, there is always fallback and repercussions. And from the perspective of things that are avoidable, hacks and infiltrations are high on that list of things that don’t need to happen.
To understand how important security is, just think about the repercussions of your site suddenly distributing malware, the data of your users or subscribers being released to a malicious third party, or your site being defaced or vandalized. If the consequences would be severe, then security needs to be concern number one. Having tight security protocols in place will automatically knock out a decent number of CMS choices including open-source platforms such as WordPress and Joomla, which are notorious for security breaches.
Project Failure
This is more of an issue with the implementation partner than with the platform or product you choose, but worth mentioning here. Procuring design and development (AKA production) services is difficult. The CHAOS report says that 70% of development projects fail at some level. Therefore, mitigating risk when hiring a development team is essential.
We’ve written at length about this in the past, so we won’t go into detail here. But consider, when procuring a partner to aid in developing your site, whether cost savings increase or lower your risk profile. Oftentimes, the lowest bidder results in total loss.
The general rule is that the more you spend on your agency, the lower your chance of losing everything with zero usable output.
Updates / Upgrades
All too often overlooked, the upgrade cycle of a CMS must be considered. These updates or upgrades almost always result in some level of implementation help or oversight. If you are wary of being stuck with upgrades that may break your web presence, you should research how often the underlying platform you choose has been updated in the past.
If you are looking at weekly updates, you’re going to need maintenance help.
Also, look at when upgrades happen. Drupal 7 to Drupal 8 was a massive upgrade, requiring many to re-implement. Those who integrated to Drupal 7 near the end of its lifespan were unlucky in that they were outdated the minute they deployed. Get a sense of where you are in a platform’s upgrade cycle to avoid being shocked when you find out it’s already time to upgrade.
Handcuffing
This doesn’t mean you are being taken down to the station. Though, maybe in the future, to the cleaners…
One risk factor with proprietary or commercial CMSs in general—though also with open-source projects—is that your content will be stuck in formats that are not portable in the future. Future-proofing your content is essential for maintaining a level of independence and control over your future plans.
The key questions to ask during vendor or platform selection is how the content is stored as data, and how portable it is in the future.
As a CMS implementation firm, we see many situations where moving content from an old system to a new solution requires either development efforts or manual labor—a task in particular that must be avoided at all costs.
The biggest risk of data portability issues lives with commercial systems, as I stated before. Headless systems are the best, as they store the data in a much cleaner form. As for open-source platforms…well, it depends on how the platform was architected.
In terms of custom CMS systems, this is a mixed bag depending on the original developer and how much they cared about data portability. But the good news is that most all custom systems are based on some code framework, giving you the freedom to generate output as you see fit.
Migration
Migration is the area of effort that we see most clients overlook or end up completely unprepared for. This is a larger issue when you are handcuffed to a platform, as we mentioned above. But migration—even with the most portable content formats—always requires SOME level of intervention.
This isn’t a risk so much with acquiring a platform or a vendor to implement, but it is a risk to your stated timeframes in that if you are not prepared with a contingency plan in place with particular regard to your internal resources capable of accomplishing this task, you can run the risk of massive time overruns.
Best way to get ahead of this is to plan with your implementation partner during the initial discovery process and figure out what you will need to contribute versus what services they are providing. I often refer to this as the demarcation between in-house and vendor resources, because it must be something that is clearly defined early and agreed to by all parties.
Implementation: Finding a Vendor
As if you don’t have enough to think about, now you need help actually integrating your CMS to either an existing website design or to a new design. This begins an entirely new process of procurement. It also brings about the chicken-vs-egg situation.
What comes first: the CMS or the implementation partner (AKA the agency)?
The answer is, it depends. If you are already working with an agency of record, most likely they are going to try to funnel you in a certain direction. Most implementation agencies are already in strategic agreements with particular CMS vendors. This applies to most creative agencies as well. You may not even know it, but having a particular vendor already under contract could be limiting your possibilities.
It’s worth noting that a CMS implementation team can be different from your front-end design team. These are separate but complementary disciplines. So, if you have an agency already under contract, you should approach them with your list of requirements that was generated via the methods above, and discuss with them their approaches.
If you feel that they are really only giving you a single option, then it may make sense to speak to CMS implementation experts. While your agency may hate to give up any part of the business, they’d hate even more working with a CMS they don’t understand and causing the project to fall into a death spiral.
We’ve written many posts about agency procurement, which we’ll link to below. The one sticking point that we want to impress upon you here is the importance of pre-project discovery and architecture services. Any expert CMS agency or implementation specialist should offer you this service, as a means to diagnose a solution before they prescribe. If they automatically tell you on an introductory call that XYZ is the solution for you…well, it’s again that old cliché I love to use: When all you have is a hammer, everything looks like a nail.
The key to finding an implementation partner is to vet them thoroughly, paying special attention to a few key concepts:
- Are they truly thought leaders in the space with experience implementing CMSs in a way similar to your project?
- Do they focus on multiple technologies and offer technical options, or are they a one-trick pony?
- Do they have a set process for diagnostics, prescription, and implementation?
- Do they have a structure for ongoing support and maintenance, or are they simply interested in giant implementation or build-outs?
You can predict what answers you want to hear in response to these questions. Not all agencies are created equal, and it’s important to properly vet these potential partners. For more information, here are a few blog posts you can read about agency procurement:
- Top 10 Mistakes People Make When Hiring A Web Agency
- How To Pick The Right Agency For Enterprise Website Design
- How to Minimize Your Risk When Hiring a Web Development Team
Maintenance & Ongoing Support
One last note about implementation procurement, which I alluded to in the above list: Beware of agencies that are not equipped to help you in the future.
All CMSs require maintenance—it’s a fact that vendors want to hide and agencies like to ignore. Your implementation expert must either train your team by providing knowledge transfer so they can maintain and continuously improve your platform, or they should provide a systematic service that approaches ongoing support, even down to the 24/7 level. Your company deserves an insurance policy that you won’t be targeted for malicious attacks, or taken offline with no immediate response.
Finalizing Your Choice
Now, the moment of truth!
If you have planned ahead, determined the proper architecture for your needs, determined what licensing model works for you, and then compared your requirements including budget and technical considerations, choosing the final system should be relatively easy. Eventually, you will narrow down your possible selections to just a couple of candidates, and the choice will become easier.
From there, it’s up to you and your implementation partner or team to finalize the choice and begin moving forward.