I’ve been involved in many transformation projects over the years, and a step that is essential in each is the procurement of a CMS platform. These projects have been both large and small, and typically followed the same process. First, you need to identify the requirements. Secondly, you must narrow down a slew of platforms into a list of a few feasible options. Finally, developing a features matrix to help guide the decision helps by making comparisons simple.
In most cases, however, it isn’t the feature set of a CMS platform that leads the way in making a decision. Dare I say it, but by now most CMS systems frequently in contention are quite good. The licensed, commercial options are by all intents and purposes powerfully equipped, which they must be to have stayed in business, and the open-source offerings are foundationally very compelling from a feature perspective. In reality, no one is deciding between a bad CMS and a good one these days. They are choosing between a variety of dependable, competitive options. I’d go so far as to say that almost all of these platforms are capable of handling probably 90% of projects – and the ones that don’t are typically just because the architecture isn’t appropriate for the use case. IE, headless, as an example.
So, if all of these platforms are good, then what is driving the decision-making process? Well, here are a few factors which clients will (typically) never admit guided them in making their decisions, but nevertheless weigh over every procurement process.
This is the one factor detailed in this post that clients legitimately can use as a determining ranking factor. The thing is, clients don’t want to onboard a system that lives in a different environment than they are used to. And by “environment”, I really mean two things. First, it’s the technology ecosystem and infrastructure that is already in place. A company that is experienced in open-source won’t be installing a Microsoft-based platform anytime soon. It isn’t worth generating a second tech stack to simply power a website and a CMS.
Secondly, it’s about license terms, too. Companies used to licensing software will not entertain the idea of something open-source for a project as mission-critical as a website. Their organizations may have requirements about what terms they can or cannot license software under, and this may define the parameters they can work within. So, while this isn’t a *hidden* factor in deciding, it’s vital as it is an area that can block a system from being considered. Whenever I’m involved in a project during procurement, I try to define these particular variables early to avoid a surprise later on in the process. And, it also helps to know in advance what the non-starters are, so you can only focus on evaluating appropriate options.
I’ve seen companies that did a massive re-platform just because of the preference of their new CMO or CTO, despite the platform of choice being shall I say less than desirable given the circumstances. Personal preference is a variable which can eliminate platforms from contention, even though they deserve to be considered given the required use cases. Of course, no one ever just chooses a platform and says “because I said so” – usually there are some reasons for doing so. And of course, preference is definitely a valid reason to go a certain way. I guess the remedy here is to try to maintain impartiality when choosing a CMS platform. Preference should always play a part, especially if that preference is based on past success, but when choosing a new CMS, you have a lot of considerations that should be taken in to account given the rarity of the task at hand. To just write-off this part of the process without carefully considering all the options would be a disservice to the company and yourself, so I encourage clients always to undertake these projects with an open mind. Preferences aren’t wrong, but preferences that blind careful due diligence can be dangerous.
I could easily have called this vendor support, but in reality, it’s risk aversion that is a determining factor for so many website operators. Support is really just a part of a variety of variables that give website operators a feeling of assurance. When clients are looking at licensed CMS solutions, they typically are interested in reducing risk. Let’s face it, open-source software carries a bit of uncertainty in that the systems are maintained by communities, not companies. Private companies have policies and governance, and that is something you see less of in the open-source world. This means that with open-source tools, the responsibility for the software falls on the folks who have chosen it and subsequently are charged with maintaining. So it stands to reason that licensing commercial CMS platforms is an excellent choice for those who are risk-averse. First, you are passing on the brunt of the upkeep and stress to a vendor. Whether you acquire a maintenance plan or not, the vendor is taking the burden of ensuring that the platform is secure from day one. That reassures clients who typically don’t have the wherewithal to manage a software platform, and it’s upkeep.
Secondly, let’s be blunt – no one gets fired for choosing Sitecore. If a project goes haywire or a site experiences technical issues later – vendors are the perfect scapegoat. You can’t blame someone for choosing a leading player in the space, right? I’d wager to say that this factor alone drives sales for the largest players more than most other factors. No one wants to take a risk on a platform which is an “up and comer” in the industry – that’s just too far to stick one’s neck out. Safe software choices are good for job security, and whether they admit it or not, frequently minds are made up before a feature comparison matrix is even presented.
Sales / Onboarding Process
Another point which applies to commercial platforms is the quality of the sales process. I’ve seen large CMS players totally blow deals because their business development process is a disaster. The nature of business development is that sales guys often neglect individual leads to pursue others. In the CMS world, the rule is no different. I’ve seen projects that were good fits for one platform switch to another because the sales process was such a disaster. But, we see this in all sorts of industries, don’t we? The best player doesn’t always win – and do they deserve to in that case? Probably not. As I said, most of these CMS platforms are great, so why stay with someone who doesn’t take you seriously anyway?
Ironically, this is the complete opposite of the risk-aversion point I detailed above. Sometimes, people choose technology purely based on what is fashionable or talked about the most in technology circles. I had a potential client as us about a Node.js powered CMS. Why? There aren't any that compete on the scale of systems available for .net or LAMP stacks. The reason was that it was something they had heard about from a friend who made an argument that it was the best framework for coding web applications.
Well, Node.js does a lot of things really well. And for custom building an application, sure, there are arguments to be made for why it may be a better choice than say, a PHP-based framework. But it isn't the basis of any CMS that would be a competitive choice in comparison to the other platforms available. Trendy software is just that, it's temporarily fashionable. However, history suggests that very few platforms stick around long enough to become significant players. This is a risky way to choose software packages and should not be a reason to choose a CMS platform for an enterprise-scale project.
I'm sure there are many other less-than-legitimate reasons people choose particular platforms over another - I've pretty much seen it all after almost 20 years in the business. The point of my post this week, however, is that you shouldn't let some silly consideration factor affect your decision-making process. Instead, you should proceed with CMS procurement in an open-minded way to land on the best choice for your company. Eliminate the non-starter issues first, and from there, hone into a couple of feasible options. From there, you'll be able to narrow down to a single choice which was based on a thorough, specification-based procurement process.