Professional success in creative industries depends heavily on your confidence. With confidence, ideas take shape quickly, projects get delivered, clients are happy. Without confidence, creativity feels like a journey through a cloud of thick fog and produces results that lack clarity and direction.

Early in my career I worked with an experienced, outgoing and remarkably confident creative director Andy Hutchinson, who is now CEO of a brand and design digital agency called Incredible (Leeds, UK). Back then Andy asked me to make minor amends to the web design concept I developed, in response to client feedback. I made the changes, clicked ‘Save As’ and modified the filename to include ‘v2’ so that if we ever needed to go back to version 1, it would still be available. “We don’t do that here,” said Andy. “No need for confusion”. Sometimes, knowing what not to do is just as important as doing the right thing.  

In web content management, versioning presents similar challenges. How many versions of content should we store, how frequently and for how long? Is it really worth storing every comma added, every auto-save created by the system? Are some versions of the content more important than others? What media types should we keep? And just as importantly, why?

Historically, content versioning was one of the core, out-of-the-box features in web content management systems. It was just there, switched on by default, with minimal or no configuration settings. Organisations used, and continue to use, content versioning for the following reasons.

1. Legal and regulatory compliance.
   Records of published web content are important in the event of a dispute over misleading or inaccurate information. For industries such as financial services and healthcare ability to restore content published in the past is a legal and regulatory requirement.
2. Editorial ease of use.
   Rolling back to the previous version can be an easy way for content editors to remove the most recent edit. This can be useful for adding, and then removing, seasonal content or temporary announcements with a limited shelf-life.
3. Accountability.
   Content versioning allows easy tracking of who has made changes when. This can be particularly important in media industry where corrections and improvements to news stories happen frequently and may need to be checked for accuracy.

Despite all the benefits, content versioning also has its limitations.

• Storage limitations.
  The most obvious constraint is storage space. The volume of web content that organisations push out continues to grow at a staggering rate, so keeping multiple versions of each content asset comes at a price. If versioning and rollback is important for your organisation, do not expect these requirements to be met through out-of-the-box, default configuration. Modern web content management systems started to impose limits on how much old content you can store.
• Impact on performance.
  For coupled Web CMS platforms versioning can cause website performance issues. Coupled architecture means that the admin, back-end part of the CMS that content editors use in order to create, manage and store content (along with all its versions) resides on the same server as the front-end part, i.e. the website itself (as viewed by the end users). For this reason, WP Engine, one of the leading providers of managed WordPress hosting, has versioning disabled by default for its customers. Versioning (which is called ‘revisions’ in WordPress) can be switched on by WP Engine support team but even then it is limited to 5 revisions per post, with old revisions automatically deleted after 60 days. WP Engine recommends to use a separate tool for managing content versions prior to publishing. (Source: https://wpengine.co.uk/support/platform-settings/#Post_Revisions)
• Lack of context.
  Content versioning in most web content management systems (including for example Drupal, Episerver and Sitecore) is limited to storing and rolling back a single content asset. Whilst reverting one specific piece of content to an earlier state can be useful, it often falls short of reproducing a full snapshot of a webpage as it existed in the past. If other elements that make up the webpage such as the template, stylesheet, sidebar content, configuration settings and so on, also changed, then these will not be rolled back at the same time. Recreating what a webpage looked like in the past requires a lot more detective work than just using a content versioning feature.  

Conclusion

For better or worse, we live in the digital world where web content can be updated, improved or deleted every minute of every day. Content versioning capability in web content management systems allows organisations to keep track of these updates and to view or revert to content assets saved at an earlier date. Whilst this feature is useful, it has its limitations. Reproducing the webpage in it’s entirely rather than reverting a single content asset isn’t easy, and the number of versions stored by default by modern web content management systems is typically limited. For long-term, reliable ways of storing legally binding web content organisations should consider record management systems, document management systems or archival tools specifically built for this purpose.

There is no shortage of IT projects that ran over time, over budget or under-delivered on value. Managing web CMS projects is hard because it relies on using new unproven technologies, ambiguous terminology, and requires agility in order to accommodate changing requirements. 

Here are some tips that will help you to avoid common mistakes.

Engage with stakeholders and users early and often

In the rush to deliver the project on time, it can be tempting to jump straight into implementation. Whilst this can give a false sense of security early in the project, the risk of not involving the right people from the start can backfire further down the line. User research and stakeholder interviews are essential steps of the discovery phase and can reduce the overall time to reach a viable solution.

Ironically, too many consultations before any action is taken can stall progress. In large, complex organisations the key is to engage with different groups of stakeholders in a way that’s manageable. It may not be possible to meet with every user and every stakeholder face-to-face and satisfy everyone’s needs but it is possible to reach out to everyone who will be impacted by the project in some way – for example through blog, email newsletters and feedback forms.

Say no to poor requirements

There are three major types of bad requirements to watch out for:

1. Ambiguous, poorly defined requirements;
2. Over-ambitious requirements;
3. Unnecessary requirements.

An easy-to-use web content management system is an example of a poorly defined requirement. What kind of audience should find this system easy-to-use? What user scenarios should the system be tested against to ensure it is easy-to-use? Without this context the requirement is open to interpretation and can lead to costly misunderstandings.

Bug-free code and 100% availability are examples of over-ambitious requirements – challenge these unrealistic expectations and substitute them with achievable alternatives.

Have you ever come across a requirement for the new website to look and function exactly like the old website but running on a new CMS platform? This is a classic example of an unnecessary requirement, which is rooted in the organisation’s reluctance to change, rather than business goals. This ‘requirement’ solves a problem that doesn’t exist. Check rigorously that all requirements are linked to business objectives and allow as much flexibility as is necessary to achieve them.

If not addressed, poor requirements can lead to scope creep and ultimately project failure.

Address skills and competencies gaps

All digital projects rely on multidisciplinary teams. Core skills needed for a successful delivery of a Web CMS project span across multiple areas and include:

• user research, user experience;
• business strategy;
• business change;
• content strategy, content writing, content editing;
• analytics;
• technical skills (web development, servers, enterprise architecture);
• design.

Lack of competence or lack of resources in one or more of these areas can severely impact the overall success of the project. Consider hiring contractors or partnering with an agency, if some of these skills are not available in-house.

Do not underestimate technical complexity 

One of the reasons organisations invest in Web CMS projects is to make their operations more efficient. Standardised processes for web content production and consistency introduced through the use of templates result in reduced cost of running the company’s web presence. The more websites follow the same set of principles, the cheaper it is to run each website.

What organisations sometimes fail to acknowledge is that custom web development does not produce similar economies of scale. Introducing more and more custom features does not make them cheaper to develop or maintain – in fact, the opposite is true. A project 10 times as large in terms of features will take significantly more than 10 times effort to build.

Underestimating complexity introduced by customisations is a common issue in web content management. Be ruthless in critically evaluating the value of custom development required for your project.

Transition into business-as-usual gracefully

Web content management projects never deliver full value on the day the website goes live. Consider closing the project 3 to 6 months after the website is launched, to allow for bug fixes and smooth transition to business as usual. Make sure that the new processes are documented and appropriate training is in place for developers and content editors. In a way the day the new website goes live is just the beginning.

One of the reasons web CMS projects are so hard is that organizations don’t do them very often. Lessons learned are forgotten a year or so after the project is finished, people move on, and, by the time the web CMS is under review again, most of the previously acquired knowledge of the CMS marketplace is out-of-date.

Lack of experience in running web CMS projects often leads to sketchy planning. Not seeing clearly how the project will develop and what challenges each of the project stages brings makes accurate estimates difficult.

Here is a quick overview of the lifecycle stages of a typical web CMS project and some ideas to help you avoid pitfalls in order to put your project on a less stressful path to success.

Stage 1: The Business Case

A business case typically includes the following:

• Problem statement
• Options and recommended solution
• Benefits and impact
• Implementation approach, timeline, and resources
• Required investment

Building a business case for a new web CMS is hard because the project can be easily mistaken for a technology upgrade with no real sense of urgency attached to it. To avoid this fate, make sure that your business case is in line with the overall business strategy. Not only should it explain why the project is important in general, but it should also answer the question, “Why now?”

When writing an executive summary, and particularly when articulating the business case in person, enhance the credibility of your message by covering relevant aspects of the proposal: main point, breadth, depth, height, and sight (for more on this concept, see Allen Weiner’s book So Smart But…: How Intelligent People Lose Credibility—and How They Can Get it Back).

Your main point for a web CMS project business case will be the key strategically important outcome. If a university is migrating all faculty websites to a single central web CMS, the main point is the need to surface interdisciplinary content that doesn’t neatly belong to one faculty. To illustrate breadth, consider several specific examples of the problem (i.e., cite research centers that are not currently promoted on the central university website and are difficult for prospective students and researchers to find as a result of the current setup). Depth means more detail on one of these problematic instances—perhaps one of these research centers represents the area in which the university has gained a lot of publicity recently and is uniquely placed to attract large numbers of world-famous researchers. (Substantiate your claim with numbers if you can.) Height is about the big picture—the effect on the whole organization, such as an increased number of applicants—and sight is about the future. In the case of the university web CMS project, the sight aspect can be communicated as “all research opportunities and research centers will be easily findable using the central university website in 2 years’ time.”   

Stage 2: Business Analysis

Stakeholder interviews help to get a real sense of the project requirements, constraints, differences of opinion, and the severity of the internal politics in the organization. They inform the project, clarify issues and priorities, and prepare the business for change.

You should interview senior decision makers, support staffers (such as those at the service desk), CMS users (content editors), and website visitors. The optimum number of stakeholder interviews varies depending on the complexity of the project, but as a rough guide, 12–26 interviews typically provides sufficient insights. Further interviews don’t usually provide additional information, but they can continue to help to foster buy-in.

When gathering requirements for a web CMS project, prioritize vision over detail. CMS projects are chronically prone to over-engineered, overly complex functionality that is requested and rarely used. Workflow and form builders are prime examples—they are useful features, but they are used much less frequently than is anticipated by the business at the outset of the project.  

Stage 3: CMS and Implementation Partner Selection

Once the business case is approved, it’s time to start web CMS selection and procurement. It is not uncommon for web CMS selections in large, complex organizations to take 6–12 months. Here are some tips that can help you to speed up the selection process without compromising due diligence.

• Write CMS scenarios to shape the evaluation process. Scenarios help contenders to focus on requirements that are relevant and important to your organization.
• Engage with an industry analyst who is actively covering WCM market space.
• Organizations select a new web CMS once every 5–7 years; analysts do it every day. They will have information and insight that you don’t.
• Create a shortlist of three to five web CMS platforms.
• Select an implementation partner as an element of this process, rather than separately, as an afterthought. Look for partners that have experience of three or more completed projects using the CMS in question. Don’t be tempted to upskill your in-house team for the initial implementation—external expertise with significant platform-specific experience will offer you both better quality and better value for money.
• Organize meetings with shortlisted vendors before you finalize the RFP. This will give you an opportunity to clarify or even reconsider some of the requirements based on the initial feedback you get from the vendors. It will also reduce your chances of receiving canned proposals.

Make the decision-making group six people or fewer. Larger groups are not more effective and will cause delays.

Stage 4: Web Development, Content, Design, and User Experience

In an attempt to reduce risk, it can be tempting to separate the technology part of the project from the redesign, content edits, and content governance. This is a bad idea—technology, content, design, and governance are inextricably linked in a web CMS project. Technology alone cannot deliver great customer experience, elevate content quality, or improve content governance. Technology can facilitate these outcomes, but using the new web CMS in the same way as the old system was used will deliver marginal benefits at best. Successful web CMS projects are always multidisciplinary and require all departments to work together as a team.

Stage 5: Project Closure and Transition Into Business as Usual

Perfect is the enemy of good. No matter how much time and money are allocated to the project, new ideas will keep coming. A wishlist, a web CMS road map, and a business-as-usual service definition are important actions at the end of the project to ensure lasting success.  

The roles and skills required for a successful Web CMS project completion can be divided into three groups: business, content and technical. These groups often work in different departments with conflicting priorities. The first two (business and content) typically belong to marketing, and technical roles are staffed by IT.

When a web CMS project goes well, it’s because of the hard work of people behind the project, who are able to surface and deal with the challenges, not only individually, but also as a team that builds on each other’s expertise.

When a web CMS project goes wrong, it’s usually for the following reasons: 

• Underestimated technical complexity and implementation costs
• Excessive focus on technology and not enough focus on people and processes
• Poorly defined requirements
• Lack of support at the senior level
• Silos, internal politics, and a lack of trust

When a web CMS project goes well, it’s because of the hard work of people behind the project, who are able to surface and deal with the challenges mentioned above, not only individually, but also as a team that builds on each other’s expertise.

The roles and skills required for a successful web CMS project completion can be divided into three groups: business, content and user experience, and technical. These groups often work in different departments with conflicting priorities. The first two (business and content and user experience) typically belong to marketing, and technical roles are staffed by IT. 

• Project sponsor
• Business lead
• Project manager
• Business analyst
• Business change manager
• Industry analyst
• Web designer
• Usability specialist
• Content strategist
• SEO expert
• Analytics analyst
• Social media specialist
• Front-end developer
• Back-end developer
• Mobile developer
• Technical architect
• Product manager
• Tester

Let’s see what these roles involve in more detail.

Business

Project sponsor secures funding and provides executive-level support for the project. This position is the living proof that the project is recognized as strategic to the business.

Business lead ensures that the project aligns with the overall business strategy and is the voice of the business users (usually, content editors and marketing staffers).

Project manager is responsible for planning, monitoring, and closing the project. He or she ensures that what is delivered is right for the business and prevents the project from becoming a never-ending series of scope creep. Being able to afford a project manager on a small content management project can be a luxury, but large organizations with web CMS project teams of 10 people or more significantly improve the chances of successful delivery with a dedicated project manager on board.

Business analyst defines, analyzes, and documents requirements. Without a business analyst, WCM projects end up delivering against a laundry list of nice-to-haves that are poorly defined, poorly prioritized, or both.

Business change manager facilitates change to business processes, systems, and technology, often through modifying job roles and organizational structures. Change is hard; new systems and processes take time to learn. Unmanaged change can lead to the premature deconstruction of deliverables before they even start to bring business benefits.

Industry analyst is invaluable if the project includes a web CMS selection and procurement. Organizations tend to select new technology every 5–7 years, while industry analysts deal with web CMS selections every day, so it is wise to source this expertise externally.

Content and User Experience

Web designer—once the initial concept is designed and signed off on—works closely with front-end developers to build a design patterns library for a wide range of use cases and devices. The BBC’s Global Experience Language (GEL) is one great example of such a library.

Usability specialist is responsible for continuous data-driven improvements. A usability specialist can also help to prototype proposed solutions and evaluate them from the user experience angle.

Content strategist organizes content and manages content writers, recognizing content as a business asset. A good content strategist scrutinizes every webpage, asking, “What should this page make you think, feel, or do?” If it’s not working toward the business goals, it has to be rewritten or removed.

SEO expert minimizes the impact of the technology change and content migration on search engine visibility. Writing good content is always a good basic approach to SEO, but at the time of significant technical change, special attention is a must.

Analytics analyst informs some of the prioritization and decision making of the CMS project, as it is also  important for measuring the project’s success.

Social media specialist is involved in communicating change to the customers after the launch of the new site.

Technical

Front-end developer’s role is becoming increasingly challenging due to the constant evolution of technologies and proliferation of devices (including mobile). Maintaining a stable front-end codebase requires more than just the knowledge of HTML, CSS, and JavaScript. It also requires appreciation of software engineering principles in a broader sense.

Back-end developer for a web CMS project should have previous experience of working with the chosen system. In the absence of this, experience with similar enterprise-level CMSs can be sufficient.

Mobile developer is desirable for managing complexity that the responsive web design brings, and it’s a must for projects that include native mobile apps.

Technical architect or enterprise architect takes care of the bigger-picture technical implementation issues such as systems integrations, servers, security, hosting, and bandwidth.

Product manager is necessary when the need for the web CMS customizations is so high that the customized platform effectively becomes a software product in its own right. Some media and higher education organizations (such as the BBC, The Guardian, and the University of Edinburgh) go down this highly customized route. The product manager protects the system from the feature bloat and ensures long-term maintainability.

Tester in software development ensures higher standards and better user experience. For large-scale projects, a separate testing team is vital.

Team Size

In a small company with limited resources and budget, some of the roles can be combined. For example, a business lead could take on project management and business analysis tasks, as well as be responsible for driving business change. A web developer can be a full-stack developer responsible for front end, back end, mobile development, security, and testing. A web designer can take on usability as part of this role. A content editor can be responsible for content strategy, content writing, SEO, and social media.

Large organizations that can afford to hire individual staffers for each role benefit from high-quality, specialized expertise. At the same time, the larger the team, the more effort it takes to keep people organized and productive. Some web CMS projects go over time and over budget due to excessive time spent in committee-type meetings that lead the project nowhere. The core decision-making project team should never be dozens of people; it should be limited to six people or fewer and include key team members: a project sponsor, a business lead, a project manager, a technical lead, and a content lead.

Senior vs. Junior Roles

Completing a web CMS project requires a lot of knowledge and experience. That said, there is also a lot of tedious lifting and shifting along the way that would benefit from the energy and enthusiasm of junior-level staffers. Experienced CMS specialists are harder to find and easier to lose than junior colleagues. As with any other project, a mix of junior-level and experienced staffers is key to success.

Conclusion

Every WCM project requires business, content, and technical skills. If you break these broad categories of skills down into specialist roles, it may seem like a lot of people. However, not all roles require a separate dedicated resource, and many can be covered by someone already employed by your marketing, communications, or IT department. The gaps in skills can then be filled by recruiting permanent staff in-house, employing a contractor, or partnering with a digital agency.   

What content management systems (CMS) do Universities use? Here are some examples.

University of Aberdeen	OpenText
Abertay University	TERMINALFOUR, Umbraco
Aberystwyth University	TERMINALFOUR
Anglia Ruskin University Cambridge	Sitecore
University of the Arts London	TERMINALFOUR
Aston University	Easysite
University of Bath	Bespoke system, developed in-house
University of Birmingham	Contensis
University of Bolton	Contensis
Bournemouth University	Drupal
University of Bradford	TERMINALFOUR
University of Brighton	Contensis
University of Bristol	TERMINALFOUR
Brunel University London	Contensis
University of Buckingham	WordPress
University of Cambridge	Plone, Drupal
Canterbury Christ Church University	Contensis
Cardiff University	Squiz Matrix
Cranfield University	Sitecore
University of Cumbria	TERMINALFOUR
De Montfort University Leicester	Contensis
University of Derby	TERMINALFOUR
University of Dundee	TERMINALFOUR
Edge Hill University	WordPress
University of Edinburgh	EdWeb (Drupal)
University of Essex	Sitecore
University of Exeter	TERMINALFOUR
University of Glasgow	TERMINALFOUR
Glasgow Caledonian University	TERMINALFOUR
University of Hertfordshire	Squiz
University of the Highlands & Islands	TERMINALFOUR, Plone
University of Huddersfield	TERMINALFOUR
University of Hull	Contensis
Imperial College London	TERMINALFOUR
University of Keele	TERMINALFOUR
King’s College London	Contensis
Lancaster University	TERMINALFOUR
University of Leeds	Jadu, WordPress
Leeds Trinity	SharePoint (moving to TERMINALFOUR)
University of Leicester	Plone
University of Lincoln	TERMINALFOUR
University of Liverpool	TERMINALFOUR
Liverpool Hope University	TERMINALFOUR
Liverpool John Moores University	Sitecore
University of London Goldsmiths College	TERMINALFOUR
London Metropolitan University	TERMINALFOUR
London School of Economics and Political Science	Contensis
University of London School of Oriental and African Studies	Percussion
Loughborough University	TERMINALFOUR
University of Manchester	TERMINALFOUR
Newcastle University	TERMINALFOUR
Northampton University	WordPress
Nottingham Trent University	Squiz Matrix
Nottingham University	Contensis
Oxford University	Drupal, Plone
Plymouth Marjon University	TERMINALFOUR
Queen Mary University of London	TERMINALFOUR
Queen’s University Belfast	TERMINALFOUR
University of Reading	Activedition
Royal Holloway University of London	Contensis
Southampton Solent University	Contensis
St George’s, University of London	Drupal
Staffordshire University	Contensis
Stirling University	TERMINALFOUR
University of Strathclyde	TERMINALFOUR
University of Portsmouth	TERMINALFOUR
University of Sheffield	Polopoly / Drupal
University of Southampton	SitePublisher (previously TeamSite)
University of South Wales	Wagtail
University of St Andrews	TERMINALFOUR
University of Suffolk	Drupal
University of Sunderland	TERMINALFOUR
University of Swansea	TERMINALFOUR
University of Wales	Contensis
University of Wales Trinity St. David	TERMINALFOUR
University of West London	Drupal
University of Winchester	Contensis
University of York	TERMINALFOUR
York St John University	TERMINALFOUR

Having worked with Web CMSs for more than 15 years, I’ve seen a wide range of CMS products—including bespoke solutions built by digital agencies to suit the needs of their existing customers, open source platforms developed and supported by large communities, and proprietary commercial products developed by software houses serving a wide range of industries and use cases. I’ve worked with market-leading CMSs, as well as average, “good enough” CMS platforms. I’ve worked on selection and procurement to replace end-of-life, officially dead CMSs too.

Some of these WCMSs were better than others, but most of them proved frustrating to the developers as well as the editors using the system. There was always a feeling that something wasn’t quite right. If the platform was flexible, it required exorbitant amounts of configuration and developers’ time. If the platform was simple enough to run out of the box, it was lacking in some business-critical features. Almost universally, content editors had to suffer in silence, doing their jobs in counterintuitive, inefficient ways that were dictated by the quirks of the system.

The frustration with the system was at its worst for projects in which the implementation team—either the company’s in-house team or an external supplier—was not experienced enough with the chosen CMS (or sometimes
just incompetent). No matter how good or bad the actual system was, it was the quality of the implementation that made the biggest difference.

When does a homegrown CMS make sense?

Building a homegrown CMS solution to address this frustration is tempting. A bespoke solution removes the gap between the vendor (or the open source community) and the customer—the product development team and the implementation team are the same people.

Development of a bespoke CMS presents an opportunity to own a platform that not only meets customer needs and business requirements fully, but also suits developers and content editors within the organization.

What’s the problem with the bespoke approach? Well, there’s two. First, keeping a team of developers in-house is expensive. Second, more often than not, 80% of the requirements can be met with an off-the-shelf CMS product, in which case, the bespoke solution amounts to nothing
more than reinventing the wheel.

“Writing your own CMS is like keeping your own elephant — for most people, it’s just easier to visit a zoo,” argues Petr Palas, founder and CEO of Kentico, in his article How I Built a CMS, and Why You Shouldn’t. Keeping an elephant and running a zoo, however exciting, are not feasible for most organizations. Regardless, there is one industry in which the bespoke CMS approach is actually justified: media. For a publisher whose entire business depends on its CMS, having full control over how it’s done can bring competitive advantage. It’s a capital investment in its core offering.

In addition, there are a number of idiosyncratic requirements, specific to the media industry, which cannot be easily met by an off-the-shelf “horizontal” CMS, such as Adobe Experience Manager, Sitecore, or WordPress. For example:

• Digital advertising management
• Management of soft and hard subscriptions and a paywall
• Management of multiple drafts of the same article
• A track changes feature to allow a journalist and an editor to easily see each other’s corrections
• Automatic, intelligent inclusion of links, tags, and metadata
• A light, mobile-friendly version of the CMS for reporters on-the-go
• Extensive cards and card stacks for easy newspaper-like responsive layouts at low cost
• Social media integration: social sharing, plus customizable social media descriptions and images
• Advanced personalization
• Scalability, ability to cope with high traffic

Developing and supporting a homegrown CMS is a huge commitment. It requires a dedicated team of developers, supported by testers, user experience specialists, business analysts, and project managers. Even then,
getting it right and staying at the top of the game are a challenge. But in the media industry, in the absence of a common publishing platform that’s fit for purpose, this continues to be the strategic choice

When publishers become CMS developers

The Guardian runs on the homegrown, open source CMS Composer. The BBC uses a bespoke system called iSite. Some media companies went as far as licensing their systems as software products for other businesses
to use. Notably, Vox Media launched the Chorus CMS in 2008, and The Washington Post launched the Arc publishing platform in 2014.

There is an opportunity for the right CMS vendor to establish a leading platform tailored for the media industry. The reason this hasn’t happened yet is that digital journalism itself is still evolving. The relentless publishing
of articles written in an inverted pyramid style works to a point, but this is more of a product of a legacy format than customer preference. The BBC is exploring new formats by mixing evergreen and ephemeral content, as
well as offering swiping options and scrollable videos to update how we deliver and consume news.

The business model of digital journalism is also changing. Despite the initial pushback, paid subscriptions and paywalls are finally getting traction, so the goal of reducing or eliminating traditional advertising from the paid services is more achievable than ever. Technology needs to catch up with this trend and allow content editors to price the content, impose paywalls,
and apply discounts as required without having to contact IT.

The whole of the media industry is on the verge of a digital transformation. Netflix, Uber, and Spotify transformed the way we watch movies, get around town, and listen to music. The future of media is about to change too, and the technology behind it will play a central role in this transformation.

I grew up in Ukraine and studied English in school every day from age 7. Speaking English fluently was by far the most valuable skill I acquired during my school career. It provided access to better education and a wider range of career opportunities. It enabled professional development beyond what my own country and my native language could offer.

When I built my first website in 1995, it was in English and in Ukrainian. Back then, 80% of all online content was in English, and I was determined to fit in with this trend. I wanted my website to be accessible to anyone in the world, and going global meant writing in English.

Fast-forward 20 years, English is still the most-studied second language in the world and the most popular language online. More people speak and understand English today than ever before. This might give an impression that publishing useful, usable content in English is a good strategy to acquire new customers globally, but is this really the case? Let’s take a look at the numbers.

Only 25.3% of all internet users speak English, and the majority of online buyers (60%) won’t purchase from a website that’s not in their native language. By contrast, adding one of the top nine languages (Chinese, Spanish, Japanese, French, German, Arabic, Portuguese, Korean, and Italian) to English will increase your organization’s presence by 2.4% to 21%. A webpage in 23 languages will reach 90% of global web users.

“Global audiences need content in a language that it can understand, otherwise whatever you do is irrelevant to them and you will miss opportunities to expand your outreach,” says Yousef Elbes, multilingual communications manager at WHO (World Health Organization). Arabic, Chinese, English, French, Russian, and Spanish were established as official languages at WHO by a World Health Assembly resolution in 1978. Multilingualism at WHO is not a matter of choice; it’s a policy.

“Any organization that hopes to reach new customers needs to consider localization,” Seth Gottlieb, a content management analyst, points out. “New markets represent new opportunity. Conversely, incursions by competitors from other markets present new threats to your home territory. Given the time we spend obsessing over the smallest aspects of user experience, it makes no sense to force prospective customers to struggle with a language that they don’t feel comfortable using.”

Although the case for a multilingual digital presence is clear, adding languages multiplies the complexity and cost of maintaining a website. Delivering an effective international presence can be broken down into three broad categories:

• Global content—content translated to different languages and available in different regions
• Regional content—content adapted to accommodate regional preferences and specifics (such as currency and delivery information)
• Local content—content unique to a particular region

This categorization doesn’t reduce the amount of work involved, but it creates structure and emphasizes the need for a range of skills required for successful delivery.

“Audiences in different markets have different content needs and tastes,” says Gottlieb. “Translating all of your source language content not only clutters the experience for readers who have no use for it all, it is also expensive. For each piece of source language content, you need to decide whether it should be available for each market you support. Some content will need to be adapted beyond a direct translation. Some markets will need original content. Despite all these local variances, each site needs to appear cohesive, complete, and consistent. Effectively connecting with different markets requires levels of awareness, strategy, and organization that are far above what is required for monolingual publishing.”

At the end of the day, it’s companies that put the multilingual requirement at the heart of their strategy that reach the widest global audience. Google’s search page is available in more than 100 languages, Wikipedia has more than 300 language editions, and the most translated website in the world is Jehovah’s Witnesses, with extraordinary linguistic diversity of more than 900 languages and dialects. If you want to engage with people around the world, you need to speak their language. There is no shortcut.

Even when the content isn’t text and doesn’t need translating in the literal sense, the challenges still remain. Suitsupply is a fashion brand, with stores in 24 countries and localized websites in 14 languages. It is shipping to 180 countries across the globe. Its recent marketing campaign, “Find your perfect fit,” features gay men holding hands and kissing. Even though the photography and video at the core of this campaign don’t require translating per se, the fact that this content is perceived differently in different countries cannot be ignored. When Fokke de Jong, the founder and CEO of Suitsupply, was asked about the potential risks of running this campaign in countries where LGBT+ communities are not accepted, he admitted that “there is potential for negative impact, especially in countries where we have a significant presence, that are known for contrasting viewpoints.” The campaign ran in most countries where Suitsupply has a presence—with the exception of Russia and the United Arab Emirates—and generated strong reactions (both positive and negative) on social media.

Expanding into new markets and multilingual communication is no longer a choice; it’s the only way to remain relevant in today’s global world. Organizations that have been slow to adopt a multilingual approach increasingly miss out on the opportunities for growth.

An opportunity to make a business case can be a blessing and a curse. On the one hand, it’s an indication that the project is taken seriously. On the other hand, it formalizes the intentions, emphasizes responsibility, and implies approval by multiple stakeholders (smell internal politics, anyone?). Writing a good business case requires a pragmatic approach, strategic thinking, and persuasive language. Done well, it can convince the top management to invest in your project. Done poorly, it can cause delays or even stall the project entirely.

Web CMS implementations take time and cost money. The purpose of the business case is to justify the investment and to prove that you have reasonable chances of success. So how can you write an effective business case for a web CMS that helps the decision makers to recognize the value of the new platform?

BEFORE YOU BEGIN

Before you start working on the business case, think about your audience. Whom are you writing it for? What language do they speak? What metrics do they use? What’s their major pain? What’s the most exciting opportunity? What’s at the top of their list in terms of priorities?

A common mistake is to assume that the thorough approach required for a formal business case is all about the subject matter (in our case, WCM). It isn’t. The business case should emphasize the impact that the new web CMS has on the business, not the complexity of the software and its features.

STRATEGIC CONTEXT AND THE NEED FOR CHANGE

A good business case addresses a genuine business need, pain, or risk. Two decades ago, most business cases for web CMSs focused on efficiencies and resolved the pain associated with maintaining the increasing volumes of content. Today, the majority of the web CMS business cases focus on the business need, such as sales targets or customer engagement goals. A link to a strategically important business need provides the urgency that puts your business case at the top of the pile. A new web CMS might be useful and important, but why should the organization invest in it now?

OPTIONS AND THE RECOMMENDED SOLUTION

If a selection process has already taken place, recommend the web CMS platform that was chosen and briefly outline the reasons why. When recommending a solution, remember to include the implementation costs and timescales. However, recommending a specific web CMS platform in the business case is not always possible. In a large organization, a typical web CMS selection process includes requirements gathering, stakeholder interviews, an RFP, and vendor demonstrations. With so many web CMS platforms available, the selection process requires a significant investment of time. If you haven’t had an opportunity to conduct a thorough selection process, offer an estimate based on the current understanding of the situation. An obvious alternative to your recommended course of action is doing nothing. If no action is taken, what will happen? What impact on the business will this have? What opportunities will be lost? Think about this carefully. The stronger your argument, the more likely your business case will be given the priority it deserves.

HARD AND SOFT BENEFITS

When articulating the anticipated outcome of the project, consider describing it in terms of hard and soft benefits. Hard benefits are specific and measurable. For example, a 10% increase in online sales or a 10% reduction in headcount are hard benefits.

Soft benefits don’t have the obvious impact on the bottom line. Improved staff morale or improved customer experience are important outcomes, but their impact on the business is more difficult to quantify.

For many web CMS initiatives, estimating hard benefits is, well, hard. Replacing an existing web CMS with a better solution is similar to moving to a new house. If done for the right reasons, the benefits are there, but assigning a monetary value to it doesn’t always make sense. Things such as happiness, a less stressful commute, and better opportunities to exercise and make friends will likely lead to a better lifestyle, but the precise impact of these benefits is difficult to measure. Similarly, a new web CMS platform can improve customer experience and team morale, but the resulting increase in revenue or specific cost-savings are not easy to estimate.

If most of the benefits for your web CMS project are soft, you might want to drop the hard and soft benefits labels altogether. Instead, categorize benefits by high-impact, medium-impact, and low-impact, as determined by their alignment to the strategic goals.

FINANCIAL ANALYSIS

The problem with creating a credible ROI for a web CMS project is that the ROI calculations are only as good as the assumptions that underpin them, and implementing new technology is riddled with unknowns. Vendor demonstrations and proof of concept bring us closer to understanding whether the system is a good fit for the organization’s requirements, but it doesn’t accurately reflect the full complexity and scale of the project. One more, or one less, skilled content editor required for the duration of the web CMS implementation can swing the cost estimates by as much as $50,000.

If an ROI is seen as an important part of the business case in your organization, your best bet is to discuss the format of the ROI calculations with the person who will be evaluating it, usually a financial director. Ask what metrics and what terminology should be used and how the calculations are made. This will bring you closer to speaking the same language as your decision maker. Refer to specific and reputable sources when estimating your costs. For example, get a quote from an independent consultant, industry analyst, or an agency with significant experience in web CMS implementations.

RISKS AND DEPENDENCIES

For a certain period of time during the web CMS implementation, there will be two systems running: the old (with the up-to-date content) and the new (partway through content migration). Therefore, the timing of the web CMS implementation shouldn’t coincide with significant content updates, product launches, or mergers. Other risks might include the ability to deliver change management, overcoming organizational challenges, reallocating and training staffers, and elevating the quality of content.

PERSUASIVE LANGUAGE

You could argue that facts are facts, and when it comes to writing a business case, communication style shouldn’t come into it. But things that are not communicated well can be poorly understood and not given the attention they deserve. Persuasive language is specific, factual, and clear. It has many voices: Use quotes and research findings from thought leaders and experts in the field to support your message. Spend time cutting out information that doesn’t help to make a decision. Making a business case is similar to predicting the future—you can’t always be accurate, but you can be specific and clear.