Syndicated News

What Decisions Do You Need to Make Before Choosing a CMS?

Have you ever watched a sports team huddle over a big play? With the game on the line they make a decision in minutes and everyone runs out to do their part. Or at least that’s how it seems. In reality, dozens of pre-game decisions have to happen. Before they step on the field, coaches have already discussed their team’s abilities, mapped out possible plays and decided who makes the final call.

Contrast that to the last CMS selection meeting I attended. Stakeholders were all over the field with different priorities, design preferences and scope. The vendor was left trying to guess whose priorities took precedence and the end result was a painful implementation process that never really got us what we wanted.

What went wrong? We didn’t take the time to make the decisions you need to make before choosing a CMS. Instead of focusing on the decision at hand (which vendor was the best fit), we were focused on winning internal debates. To be frank, it cost us the game.

So before you even start your short list of vendors, I beg you to gather your stakeholders together for some pre-game decisions.

What is your timeline?

This one might sound easy, but it’s critical that everyone understands any non-negotiable deadlines. There is no 30-day grace period for a retailer who misses Black Friday. One way to approach this is by asking yourself what happens if you miss the proposed launch date. Will it mean suffering through a few months on an old CMS, delaying a product launch or could it lead to longer delays if resources are needed elsewhere? Stakeholders should disclose any conflicting priorities or busy times of the year that could affect resource availability.

What are the dealbreakers?

Security regulations, technical limitations, preferred vendors and pre-existing technology investments will factor into the final CMS decision. Decide which ones are deal breakers so you don’t waste time falling in love with a CMS that you can never have.

On the technical side, these can include preferred infrastructure (Saas vs on premise, cloud-based, etc.), the languages your developers use, security requirements (PCI DSS compliance, ISO 27001 compliance, 99.99 SLA) and ability to integrate with an existing tech stack.

For practitioners, deal breakers are often use cases (ecommerce site, personalization, localization, digital signage, interactive content, etc.). Practitioners should also consider preferences around the user interface, workflows and compatibility with the tools they use.

Whose needs do you prioritize?

The CMS can be a bone of contention between developers and editors as greater functionality can impact usability for less technical users. These debates can get heated when you’re looking at vendors and making trade-offs. Understanding the reason behind different needs can help stakeholders better weigh the importance of each team’s preferences and prioritize them.

For example, you might prioritize ease of use for people who will use the CMS daily because that can save more time than automating a function that is performed monthly. Or you might be willing to trade some ease of use to get a CMS that empowers developers to build and ship faster.

What’s your vision?

Imagine asking a potential customer what they want their website to look like and getting five different answers. In my experience, the vendor either makes their best guess at who will win or presents a mishmash that doesn’t work for anyone. Stakeholders should talk about how the digital experience will look as well as what they expect the CMS to do.

Think about how many digital channels or projects you expect the CMS to support. If it’s replacing an old CMS, how different do you expect it to be? Are you looking for an out-of-the-box solution or do you plan to push the limits of a traditional CMS? Will it support one team or do you want a solution that can scale enterprise-wide? Do you want to unify content management across different products and channels?

This might not be in scope for the current project, but if unifying content is a long-term goal then choosing a CMS with that potential can avoid replatforming in a few years. Using a headless CMS for a smaller project can serve as a proof of concept to eventually pull content into a single hub capable of multi-channel content delivery. This breaks down content silos and streamlines content operations for long-term value.

Set expectations around implementation and onboarding

CMS selection often focuses on how a CMS will help you meet specific requirements or achieve certain goals. Vendors tend to gloss over the details of implementation and onboarding until later in the process. When those details are unpacked it can feel like a lot of surprises that have an impact on the time and resources needed to go from selection to production.

Key areas to consider are:

Development resources: Headless CMSes separate content from the front-end presentation layer (e.g. website, app, etc.). This gives developers more flexibility in what they build with the content, but it can be a barrier for companies without developer resources. On the other hand, monolithic suites can require developers with specific skill sets that can be hard to recruit and retain.
Integrations: Customizations and integrations tend to require developer resources as well and can extend the implementation timeline. Too often, I see an expected integration sidelined because it will take too long. Making these sacrifices during implementation sets businesses up for technical debt.
Content operations and strategy: Every CMS change I’ve been a part of has involved a conversation about “cleaning up” the content and reassessing content strategy and operations moving forward. Evolving strategy and operations to take advantage of the new CMS’s capabilities and features helps maximize the value. Discuss current pain points and future goals before meeting with vendors and set expectations around the time and resources you will allocate to content during implementation.
Onboarding and support: A new CMS can come with a steep learning curve. Think about who will be using the CMS, what their skill levels are and what type of training and support they prefer. Support can vary from self-service to a dedicated success team that is with you for the long haul.

How will success be measured?

This gets to the heart of what you want to accomplish — launching a new digital product/experience, faster shipping speed, fewer content bottlenecks, happier editors and developers, etc. Agreeing on measures of success can help guide your CMS decision, but it is equally important to talk about failure. What are your biggest issues you want to avoid? For example if the CMS delivers the customer experience you want now, but can’t scale on the backend is that really a success? Stakeholders should agree on what success looks like, how it will be measured and what additional benefits would be the icing on the cake.

Once you have all your pregame decisions made — or at least get them out on the table — you’re ready to start looking at CMSes and making your shortlist. And hopefully when you’re sitting at those vendor meetings your team will be aligned and ready to make a game changing decision. Good luck!

View original content here