What you’re probably not doing to de-risk your CMS investment

A recent conversation with a client about the pitfalls of enterprise-level CMS implementations got me thinking: are pitfalls just a delivery issue? Or are they a symptom of something missing in the entire procurement and build cycle? There are endless thought pieces on technology selection, and even more widespread marketing literature on silver-bullet features. What gets way less coverage is how thinking about content as a function across the enterprise can help budget holders navigate a packed and very confusing market that often promises the world - right out of the box.

What does content look like in an enterprise?

The complexity is best represented with visuals, so let’s take a company that produces and sells physical goods, and has a fairly developed digital estate to support the customer lifecycle (hopefully the alt text does a decent job of capturing the interconnection of systems and processes):

If you ask a single team or function, you’ll likely end up thinking content is only a consideration for them and their tools, but the reality is that in parallel there are loads of content types stored on other systems that are still “content” as far as the end user experience is concerned, and a load of official and unofficial processes and handoffs, sometimes between systems, more often than not between humans, to get that content live.

Besides, content is not only stored in an official system but is often handled through what we call a “shadow CMS”: if you’re lucky it will be a CSV file hosted on a secure server, or in a ticketing system, but often we’re talking about Figma files created on an unlicensed version, or an email sent via a personal account. This is the operational space filled with third-party widgets and personal initiatives or technology patches that won’t scale. It’s also known as whitespace, and it can put your investment at risk: most companies have unacknowledged, unsupported content operations, and a new CMS, especially a headless solution, is going to bring more instability into the mix.

So, in this complex context, what active steps can you take at each stage to make sure your technology investment is solid, and, as much as possible, future-proof? Read on for our take.

Ahead of procuring your enterprise CMS

Before engaging with vendors you need to have clarity on the business processes that your new content technology will support and a detailed understanding of the pain points that need solving. We’ve championed the use of service design to get that in-depth understanding: we recently wrote about how we applied it to martech, but we’ve successfully used a similar approach to uncover the hidden content operations within a global ecommerce ecosystem.

If we’re talking about composable and MACH architectures, there’s an added pressure: having a working hypothesis on where orchestration (the assembly of data, content and assets needed for the experience) and composition (the front-end management of the experience) will happen, and what kind of technology will support that, given its tight interconnection with the CMS. This becomes crucial in settings like omnichannel or personalisation, where experience is a responsibility shared by different teams.

These are the active steps you can take at this stage to set your CMS implementation project on the right track: 

• Create an inventory and perform an audit of all existing content assets. The audit should give an idea of the volume of assets that need to be migrated, the ones that can be archived, the type, granularity and level of structuring of the assets, and the systems currently involved when it comes to content storage and front-end integration.

• Create a service map of the as-is operations across the different teams and business units, including all the official systems and any shadow CMS, detailing all the agents involved, the handoffs and the pain points. Use a mix of techniques and maps, to get a layered view of the content ecosystem.

• Based on the strengths and weaknesses of today’s operations, develop a shared vision of what the future operations should look like. Ask questions like: what kind of content management do we want to have in place? How do we want to manage the experience? How do we want to manage rules for the dynamic assembly of products, content, audience and customer data, and other business rules that might apply? What is the testing approach, and what regulatory checks need to be considered?

• Identify specific use cases for procurement: pain points, integrations (or the lack of) with other systems. Don’t forget to create examples of the desired experience you’re looking to achieve, and when you’d like to get there.

Before you implement your enterprise CMS

With the steps above, and a thorough exercise in requirement gathering undertaken, you’ve now defined the solution you need. You might be in an official tender process already, or just talking to a system integrator: what follows will help you scope out the implementation work, and avoid last minute surprises. 

At this point having a broad organisational agreement on the to-be content and experience operations is critical. There needs to be a well-formed idea of how content and technology will be managed as part of business-as-usual activities, from marcomms to support, and for product and service development (optimisation, new features like personalisation, etc), but also clarity on what will and what won’t be supported, and what won’t be supported immediately, but might be implemented at a later stage.

At this stage it’s worth spending some time in analysis mode, engaging a specialist firm, especially if procurement depends on a structured process like an RFP.

Activities to consider at this stage to reduce the overall risks of the implementation:

• Identify the specific needs of the people responsible for content management and those who rely on it: what are the requirements for modularisation and reusability? What are the requirements for findability and observability? What are the use cases for automation? What use cases could benefit from any AI-based features/technologies?

• Identify semantic-driven content entities and presentation-driven structures. The former will form the backbone of your “reusable content”, the latter will define channel-specific formats, and together they’ll form the basis of your content architecture.

• Define user models for the business-as-usual operations and the super-admin tasks.

• Align on a strategic approach to metadata with owners of other metadata-heavy systems: which lists are we using? Where are they stored? What’s the governance behind them? How will we support data standardisation and normalisation?

During the implementation of your enterprise CMS

Now it’s the time to implement the decisions taken in the previous phases. This is when the risks mentioned earlier could create delays, or even long-lasting impact. Fortunately if you’ve been taking the steps listed before, you should have already reduced the number of pitfalls. There are still some risks, and lots has been written about them, so I will just recap the actions that are most likely to reduce risk, and benefit your cross-enterprise content operations:

• Aligning UX and UI design to the work done on content structures and workflows.

• For DXP/headful CMS: designing for, and testing content management edge cases early in the project.

• For all, but especially headless/composable solutions: avoid the development of content models based on UI components and design system structures – this can hamper automation and the reusability of content.

• For headless/composable: taking an incremental approach to build and migration.

After the implementation 

At this stage the CMS is finally running - we’re positive that the due diligence applied so far has avoided scope creeps and massive delays. With a solid governance framework in place, all business-as-usual processes should now be supported by the new system.

However, companies frequently fail to identify who’s in charge of the content architecture going forward, leaving an important organisational design element unaddressed. The remit here is not just to ensure the system is running, but also to make decisions on new templates, components and workflows: in short, who decides what content management looks like across the organisation. Making this clear and understood will help to keep the integrity, scalability and extensibility of the platform in check. In the past we’ve made the case for a centralised content architecture to run content as a platform: our recipe contains other information that could be useful to run the platform at scale. 

Don’t be afraid of the hard thinking

This list is by no means exhaustive, and it has been written from an architectural and technology-agnostic perspective unless otherwise noted. You still need to do your due diligence in terms of both technical and security requirements and individual teams’ wishes, striking the balance to get everyone in agreement.

Too much content just “happens”. Buying new content technology gives us an opportunity to bring more rigour and reliability to processes that often create risks. Much of the due diligence we recommend connects back to the context of use, and the desired future outcomes. However, without clearly documenting employee needs, business expectations and operating models these efforts and investments can very easily fall short.