Choosing a CMS Your Organisation will Love

he internet doesn’t exactly lack for advice on how to pick a CMS platform. Go for the one with the most impressive feature set, advises one expert. Consider the costs of ownership, charges back another. Make sure it produces SEO-optimized pages, warns every SEO consultant everywhere. Unfortunately, picking the right CMS by consulting generic criteria is as effective as studying census data to improve your writing skills.

Experts often readily admit the importance of considering organizational needs in the CMS selection process, but they’re rarely willing to talk about those needs specifically. Understanding the varied departmental interests, psychological trade-offs, and political realities of your organization, however, is key—your CMS selection criteria should emphasize factors that will directly impact the success of the people who will use it. In other words, stop worrying about having a CMS and start worrying about having a usable CMS.

The curse of enterprise software

A 2012 executive survey revealed that CMS projects are seven times more likely to fail because of internal politics and lack of cultural fit than from a lack of features. Anecdotal evidence further suggests that even projects that seem successful initially can quickly go off the rails if the CMS can’t accommodate how the organization works.

As Jason Fried and Karen McGrane have famously pointed out, these problems stem from the fact that the people who buy enterprise software aren’t the people who use it. Changing the sales process isn’t enough to truly overcome this problem, however; one also has to understand who will be using the CMS and what their key needs are.

Those users typically fall into three categories: developers customizing and running the software, editors producing actual content, and managers using online content to achieve specific business goals. To choose a CMS that can serve the organization, you need to understand how the CMS impacts their daily work and what challenges they have to contend with.

Tools maketh the developer

All developers know that no two CMSes are created equal. On one end of the spectrum, you will find publishing platforms that carefully separate application data, presentation, and business logic, making them easy to extend and customize. On the other (more crowded) end, you will bump into CMSes whose innards consist of spaghetti code—unnecessarily intricate and poorly structured. What hides under the hood of a CMS matters a great deal, because poorly architected code slows down, frustrates, and demoralizes even the most accomplished developers, turning any promising new initiative into an endless grind.

Unfortunately, the difference between properly designed and haphazardly thrown-together software might be obvious in hindsight, but there is no way of telling them apart when you are still shopping. Businesses often hedge this risk by betting on CMS vendors boasting a big developer community. Indeed, a vibrant community addresses many of the shortcomings of a slapdash architecture: technical mysteries are solved with a quick googling session; there is a smorgasbord of themes, plugins, and extensions to supplement the standard functionality; and one never runs out of experienced technical contractors to recruit.

But the rise of API-centric services and the new approaches to publishing they spawn—from headless CMS and content-as-a-service to mobile backends and static site generators—has added a new twist to the old story. Rather than requiring developers to slog through the quirks of internal architecture or master a hodgepodge of tools and frameworks, the new breed of CMSes hides the complexity behind an API layer. All a developer has to do to fetch the content is issue an API call, and, milliseconds later, a neatly formatted response is returned. As long as a developer is working in one of the popular programming languages, the costs of integrating content delivered this way are trivial.

This means that technical stakeholders have to make a strategic architectural decision in addition to thinking about security, deployment, and performance. Traditional vendors offer complex software that takes months to master, but has a large developer community to turn to. New upstarts provide lightweight services with no programming overhead, but it will take years before they catch up in terms of social proof.

Here are some questions to help weigh the pros and cons of these options:

The editor’s fear of manuals

Developers usually find detailed software documentation a sign of quality. Busy editors take just the opposite view: the best publishing tools come free of manuals and are intuitive to use. Unfortunately, the generic interfaces they have to contend with today more often feel like a product of a violent database eruption rather than painstaking design. Some vendors have tried to address the problem by improving styles and layouts, adding descriptive labels, and tweaking interactions to take the friction out of using a CMS. But better interfaces alone won’t make a CMS intuitive—we need better authoring experiences (AX).

Getting AX right requires that software developers design the CMS around the way editors and content authors perform their tasks—for example, preparing and uploading responsive images, identifying stale content in need of refreshing, customizing field labels, or updating help text. A good AX comes from actively and carefully designing for those everyday workflows, so that editorial teams can define their content model and customize the authoring interfaces without touching the code.

This focus on AX dovetails with concerns about how to structure content inside the CMS. Traditional, page-centric tools store information in big blobs of data, where actual content is mixed with formatting styles and layout elements. The antidote to the majority of these problems is to disassemble undifferentiated content blobs into small, reusable chunks of data and keep this data strictly separate from the visual presentation.

The organization of content has a dramatic impact on the productivity of the team, because it provides editors with very distinct tools. Page-centric CMSes allow authors to assume the role of a designer and tinker with how things look in a desktop browser. Structured-content CMSes help authors act like architects, assembling individual pieces to fit the constraints of a specific medium. Editorial teams obsessing over the look of their content would feel sabotaged without a WYSIWYG editor, while teams working in multiple mediums expect content to come in LEGO-like chunks. The real question is, which use case is critical for your business?

When selecting a CMS, examine your use cases and editorial process, then consider these questions:

Helping managers see the big picture

Managers are rarely mentioned in the context of CMS selection; when they are, it is usually to tell a cautionary tale about the dire consequences of listening to the HiPPO. This line of thinking tends to ignore very valid concerns that decision-makers like senior editors, marketing VPs, or product managers have.

Managers orchestrate individual contributors to produce content serving an organization’s needs. It’s a tricky process that requires strong planning skills, lots of empathy, and attention to details. While a CMS is a poor substitute for empathy, it gets its chance to shine by helping busy managers see the big picture: what content is live, which pieces are scheduled for publishing, and who on the team has fallen behind. Contextual information also comes in handy when working with individual pieces, where the ability to visualize recent changes, enforce validations, and track down whoever deleted the cover image helps streamline internal discussions.

Juggling roles and permissions is another source of managers’ anxiety, largely because access management is often the last item in a CMS vendor backlog. Organizational culture dictates very different needs in this area: managers charged with coordinating a constantly evolving network of contributors want a one-click approach to onboarding new contributors and waving goodbye to old ones. By contrast, those working with stable teams are more interested in capturing in-depth author info.

The same goes for workflows: flat organizations can get by without elaborate checks and balances, while those in regulated industries might look for a way to enforce triple sign-off before new material hits the homepage. All this just goes to show that the goals a team pursues profoundly shape their expectations about how different parts of CMS will work. Even when CMS vendors reassure you that their tool comes packaged with roles and permissions, remember to investigate whether the way access control works really fits your needs or requires a computer wiz to operate it on a daily basis.

The human bottleneck

CMS projects succeed or fail largely due to human factors. The CMS plays a different day-to-day role in different departments, necessitating strategic trade-offs. Some trade-offs are interrelated: an API-powered CMS is easy to combine with cloud-based analytics and A/B testing services; focusing on AX makes it a breeze for managers to set up custom workflows. But it is just as likely that in some situations, your organization will find itself at a crossroads, with key stakeholders opting for competing CMS vendors. How does one handle these sensitive situations?

In the past, a common way of resolving these differences of opinions was to defer to the IT department or gracefully accept the backroom deal engineered by the higher echelons of management. This approach incurs a lot of costs, with poor usability being the most obvious one.

Instead, it’s best to approach this problem by looking at your production process. Think of the steps performed by your different teams: developers doing custom development and providing daily support; editors creating, updating, and maintaining content; and managers overseeing processes and measuring how published content impacts the business.

Identify the weak links in the process, where risks abound and schedules get routinely delayed. These are your bottlenecks: they hold back organizational plans, drag down the bottom line, and put people under pressure.

The bottleneck is a relative concept: it always depends on a configuration of individual factors in a given situation. For a newly established business, it’s often the size of the IT bill that determines limitations; for a university department, the constraints may come down to the available time and technical savvy of the faculty members; and in a media company with evergreen content, the biggest productivity jump might come from removing the obstacles in the way of the marketing team.

Selecting a CMS with these obstacles in mind improves user productivity in a number of distinct ways—from eliminating mistakes and speeding up content creation to simplifying user onboarding and ensuring more enthusiastic reception. Helping the weakest teams unlock their potential goes far beyond eliminating the immediate bottlenecks—it also makes the entire organization more agile and resilient.

Setting up for success

For a long time, selecting a CMS platform was treated as a technical problem, to be solved by an IT department or a trusted technical advisor. Resist this view. As a tool that defines your online presence, imposes idiosyncratic editorial processes, and affects the productivity of your team, the choice of a CMS platform is too important to be decided on technical criteria or imposed by a single stakeholder.

Approaching the CMS selection as an organizational problem, on the other hand, yields many benefits: selection criteria that flow from functional requirements, work patterns, and cultural expectations of future users ensure focus on the job-to-be-done, not features-to-be-shipped. Visualizing content creation as an organization-wide process helps avoid internal turf wars and prioritizes high-impact solutions.

Start by identifying who in your organization will be impacted by the CMS: we talked about developers, editors, and managers, but the stakeholder list can include other roles too. Next, understand the big trade-offs involved: is the size of a developer community a deal-breaker? How should your content be structured? What is the role of managers? Working through these questions should help you articulate the needs and expectations of future users, which can then be translated into a checklist of technical requirements.

Equipped with this knowledge, you can now reengineer the vendor selection to put the true needs of your organization at the center of all discussions. And once you do, adopting new software will no longer breed uncertainty, risk, and anxiety, but—on the contrary—help your organization become more agile, focused, and resilient. Just like those sales folks have always promised you.

Author Artas Bartas.