The CMS Implementation

I have two teenage daughters. They’re obsessed with their future weddings. They’ve both planned out the perfect day dozens of times. When they ask why I don’t get nearly as excited about it as they do, I always respond the same way: “I’m less concerned with your wedding day than I am with the 50 years that come after it.”

In the process of building a content-managed website, organizations often get obsessed with finding the right CMS for their needs. They’re dazzled by sales demos and starry-eyed over the things they’ll do once it’s implemented. Emboldened by finding what they consider a flawless piece of technology, they rush into the implementation, then don’t understand why the reality of what they wake up with every day doesn’t live up to their dreams.

Identifying and acquiring a CMS is only the first part of building a content-managed website. It’s like spending hours and hours at the building materials store, identifying and purchasing everything you need to build a house, and having those things delivered to an empty lot. It doesn’t matter how many materials you have, or whether or not they are high quality – someone still has to build a house with them .

Clearly, you’re ideally looking for both: a solid CMS coupled with a solid implementation. Even a simple understanding and acceptance of the fact that the implementation is just as important as the CMS itself will put you in the right frame of mind.

Principle Construction Versus Everything Else

An old adage of project management says if you want to know how long a project will take, “Add up the time you think it will take to complete all the tasks, then double it.” While clearly a joke, it’s often not far from the truth.

The amount of time required to implement a content management system is always more than the sum of its parts. Planning out every idiosyncrasy of an implementation before you start is not a straightforward process. During the project there will be bumps in the road that will lengthen the required time considerably: changes, hidden requirements, misunderstandings, staff turnover, bugs, and rework.

We tend to underestimate the time required by concentrating on the activities we consider “principle construction,” which are, by nature, development-centric. We look through the functionality required to finish the build, add up the implementation time, and think that’s everything that needs to be done.

Along the way, we forget things that fall outside the mainstream path. Things like:

• Environment setup, such as development, test, and integration environments, not to mention source control repositories and build servers
• Testing and QA, including the inevitable “fine-tuning” period in the days or weeks directly prior to launch when bug fixes consume the development team
• Content migration (a subject so chronically overlooked that I’ll devote an entire chapter to it)
• Editorial and administrator training – the initial editorial team, future team members, and ad hoc training on specific tasks
• Production environment infrastructure planning
• Deployment planning and execution, including initial launch and post-launch changes
• Documentation, either of the implementation itself or of the project process
• Project management, including progress reporting
• Internal marketing to affected staff and stakeholders
• User transition management, including moving user accounts, ensuring users are notified of changes, and password resets
• Load and security testing
• Transition of SSL certificates
• DNS changes and propagation
• URL redirection

These are all activities outside of principle construction, and they often get left out of estimates as a result. In some projects, the actual development becomes a minority of the work when compared to all the non-development work surrounding it.

That adage of doubling the initial effort estimate perhaps isn’t unreasonable after all.

Types of Implementations

At the most general level, CMS implementations can be grouped into three types, based on their relationship with the current website:

• CMS only, or “forklift” In this case, the goal is for nothing on the website to change – the design, the content, and the information architecture will carry over identically, but the CMS powering the website will be swapped for another (or, less commonly, a statically managed website will have a CMS introduced). In this type of implementation, the current website is the model for the new website.

• CMS plus reskin or reorganization: This is an extension to the forklift implementation where the organization decides to do some light housekeeping, as they’re going to the trouble of implementing the CMS. New designs are often applied since templating has to be redone anyway, and a content migration often means that content can be cleaned up or reorganized without considerable extra work. Some things will change, but the changes are limited to styling and editorial, which means the current website is still somewhat relevant as a model.

• Complete rebuild: In these cases, the entire website is reenvisioned. The new CMS might be only one part of a larger digital turnover. The website will get a new design, new content, new information architecture, and new functionality – little or nothing of the old site will remain. The CMS implementation often comes after a large content strategy and UX planning phase. Clearly, the existing website is irrelevant as a model for the new website.

While the first type, the forklift implementation, might seem the most simple, it can be deceptively complex because you’re now faced with wrapping an existing base of historic functionality around a new CMS. The new system will invariably do things differently than the old CMS, and the website likely have adapted over time to fit how the old CMS worked. Implementation teams have often found themselves trying to backport existing functionality into a new system to replicate how a website evolved around an old system.

The edge case adage discussed earlier holds true here as well. Given a sufficient amount of time, editors will have found every nook and cranny of a CMS. As mentioned in Other Features, any given editor might only use 25% of the total functionality, but every editor might be using a different 25%, meaning the editorial team collectively expects all of the old functionality to work in the new system, sometimes in the same manner, even if that’s an inefficient way of accomplishing some goal.

On the other end of the extreme, a complete rebuild at least gives you flexibility to weigh new functionality against the new CMS that will power it. Weighing new design and functionality requirements against technical feasibility is an expected dynamic to a rebuild project, which gives an implementation team the opportunity to influence plans toward functionality the new CMS will support.

Preimplementation

Before you implement, you need to take stock of what you have to work with, then use that to develop a plan.

Discovery and Preimplementation Artifacts

The amount of preimplementation documentation depends highly on the level of change planned from the existing website.

For a forklift implementation, there’s a possibility of using the current website as a de facto requirements document. When simply swapping the CMS out from under an existing website, a project mandate might simply be to make things function the same as they have in the past. So long as the development team sufficiently understands the inner workings of the current site and someone from the editorial team is available for questions, this might be enough to suffice.

If the website is being reskinned or reorganized, some consideration needs to be paid to how the changes will affect the CMS. If the changes are limited to the design and content alone – and none of these changes require modification to the content model itself – then they might not be relevant to the development effort. For example, the developer doesn’t care if the design calls for a serif or sans-serif font, or if the content is written in the first- or third-person perspective. The development effort is the same.

Be careful here – design and content changes need to be thoroughly investigated for potential content model changes. Seemingly simple design and content changes might require significant underlying model changes to support, and these changes have an uncanny way of snowballing. Changing thing A suddenly forces changes to thing B and thing C. Changes beget more changes, until, two weeks later, you’re changing thing Z and realizing the initial change went much deeper than you thought.

For a complete rebuild, significant site documentation is required for an effective implementation. at a minimum, the development team will need the following:

• A set of wireframes that displays the layout of each major content type, including all relevant content elements.
• A set of functional requirements (or equivalent annotations to the wireframes) that explains how nonvisual functionality should work, especially navigation and contextual functionality in the surround
• A sitemap showing an overhead view of how all the content fits together and is organized

Depending on the scope of the integrator’s responsibilities, they might also need:

• A fully rendered design with all supporting art files
• Frontend HTML/CSS of the implemented design

Over the last half-decade, frontend development has become its own discipline. Implementations used to be achievable with a single set of development skills, but with the advent of responsive design and increased use of client-side technologies, the frontend development is now often assigned its own team. Additionally, many projects will have the frontend development completed before the CMS implementation begins.

The discovery phase of a CMS project is normally handled by a team of content strategists or UX/IA specialists who work with the organization to determine needs. A key point is whether this team needs to work with the knowledge of the intended CMS or not, if that information is even knowable at the time.

Some say that sites should be planned to be CMS-agnostic and that the focus should be on giving the organization the best possible website. However, a more practical school of thought says that if the intended CMS is known, then plans and designs need to be vetted for what can actually be implemented, which means filtering out idealistic and grandiose plans that can’t be brought to fruition. Planning a comprehensive personalization strategy, for example, is an expensive waste of time if your CMS doesn’t support personalization and you can’t integrate the necessary functionality from an external service.

If the intended CMS is known, it’s generally wise to have the implementation team review plans and designs for feasibility as they become available. Early discussions about hypothetical functionality can help ground the design team in a firm understanding of which ideas can actually work.

Developing the Technical Plan

There’s an old saying among trial lawyers: “Never ask a question you don’t already know the answer to.” Something similar can be said of implementations: “Don’t ever start implementing a wireframe that you don’t already have a plan for.”

At some point, the implementation team needs to review the preimplementation artifacts and come up with technical plans for everything in them. While it’s tempting to try to plan a site from the top down, it’s best to start from the bottom up. This means paging through the set of wireframes and asking a lot of questions about each.

These questions need to be answered in some form prior to development. In some cases, the developer will write a formal technical implementation plan (TIP). In other cases, the wireframes are simply reviewed in a “build meeting” to ensure understanding and to make sure there’s nothing present that isn’t implementable.

For each wireframe, consider the following questions:

• Is there an operative content object present? What type is it? What attributes does it need to support?
• Can a clear line be drawn around the operative content object and the surround? What content will be handled by the object’s template, and what content is in the surround?
• Of the content in the surround, what is contextually dependent on the operative content object?
• Of this contextual information, what will be derived from context or geographic position, and what is based on the discrete content present in the object?
• What aggregations are present? Can they be powered through geography alone, or will there need to be secondary structures created to support them?
• What non-content functionality is present? How will this execute alongside the CMS?
• How repeatable do the elements in this wireframe need to be? Are they just for this one page, or do they occur again and again?
• Is this wireframe literal, or simply suggestive of a wide range of possible manifestations? What areas on this wireframe might be swappable by editors?
• How often will this particular content need to be modified? Is this something editors will manage every day, or will this be set on launch and never touched again?
• How much relation is there to future functionality? Should this wireframe be interpreted narrowly as an exact, literal representation of what the site planner wants, or is it indicative or suggestive of other things?

These are all visual questions, driven by what’s actually on the wireframe. However, lurking below the surface are several questions about the content represented in the wireframe, which have nothing to do with the wireframe itself:

• What are the URL requirements for this content?
• What are the editorial workflow requirements? Will an editor create this content directly in the CMS interface, or is it coming from somewhere else? What approvals need to be in place for this content?
• Who should have permissions to this content? Who can create it, edit it, or delete it?
• Does the content have to be localized? Into how many languages? What non-text elements (images, for example) will also need to be localized?
• Does this content need to be versioned? Will it need to be archived at some point? In the context of this project and this content, what does that mean?
• What other channels does this content need to be published into? Will this happen on the same schedule? Does it need to happen at any time? Who can initiate this?
• Does this content exist now? If so, where is it, and how can we get access to it for migration? What is the current velocity of this content – how fast does it change or turn over?

To this end, the most valuable question the developer can ask might simply be: “Where does this come from?”

For any element on the wireframe, the site planners, owners, or editors need to explain where it comes from. Is it managed content? Is it from the operative content object? Is it from another content object? Is it from an external data source? Is it contextual logic, like related content or sidebar navigation? If so, on what data is this logic based?

They do not need to have complete technical understanding (this is the developer’s job), but they need to have at least some logical idea of where the content sources from. If they don’t, the developer can back up and ask more general questions about the nature of the information:

• Is it specific to this page?
• Is it global?
• Is it based on the content type?
• Can everyone see it?
• Is it from someplace outside the CMS?

From the answers, the developer might be able to extrapolate some content model or method of populating the information. This should be repeated for every single element on the wireframe: every menu, every sidebar element, every snippet of text.

It’s easy to short-circuit this process. It can get tedious, and there’s a temptation to think, “Well, I’m sure someone has a plan for that.” Resist this temptation. The process of answering these questions is vital, both for the developer’s understanding and also for the editors and site planners. Many times, the provided answers will be in conflict, and you’ll uncover misunderstandings and incorrect assumptions.

Equally important as the actual answers, the directions these conversations go in will often reveal underlying motivations and goals. The answer to where something comes from will often lead to a discussion about why it’s there and what goal the site planner was trying to achieve with it. These discussions help provide context and background, which the developers can use later in the project when they need to make more intricate implementation decisions.

By starting at the bottom and proceeding through the wireframes one by one, larger top-down questions will slowly begin to fill in. Once every interface has been reviewed, the team can back up and look at larger questions such as:

• What is the shape of this content? What content geography is needed to support it?
• What does the aggregate content model look like? Can types be abstracted to base types from which other types might inherit? Can type composition be used to simplify the model?
• What content appears to be global to the installation, and where will that content be stored?
• What larger, nongeographic aggregation structures are needed? Is there a global tagging, categorization, or menuing strategy that ties the content together?
• What is the overall need for page composition? How much of the site is templated, and how much is artisanal?
• What do the aggregate localization requirements look like? How many languages will need to be supported, and how should language preferences and fallbacks be managed?
• What does the user model look like? How many different user groups will need to be created, and what reach will each of them have?
• What external systems need to be integrated with? What APIs are available, and what access is allowed? Can this information be retrieved in real time, or does an import strategy need to be defined?
• What does our overall migration strategy look like?
• If the target CMS is known, how well does the revealed functionality overlay on what’s available out of the box? How much customization will be needed to complete the implementation?
• If the target CMS is not known, what CMS might be a good fit?

The end goals of a project will also exert an influence on implementation decisions. Consider these two projects:

• A temporary promotional microsite to support a single conference event with content that won’t change. This site needs to be launched very quickly, and will stay up for six months at most.
• The main website for the organization. There will be thousands of pages of content, authored by dozens of editors of varying skill levels turning over content multiple times per day. This implementation needs to be functional and relevant for at least the next five years.

These two scenarios will likely result in drastically different implementation decisions. For the temporary microsite, corners might be justifiably cut for the sake of budget, time, and the fact that more complex implementation won’t provide much return on investment. However, the main site of the organization has a much longer time span and a larger, distributed editorial base. For this project, a more measured implementation is required. Deeper investments in usability and flexibility will have the breadth and time required to provide value to justify their expense.

The urge to generalize

Developers love to generalize. Specificity gives us a lingering unease, like we’re building something too tight around a set of requirements, and what if there’s more functionality to be gained by loosening up a bit?

Additionally, developers love to deal in abstractions. Yes, this particular content object is of the type Article, but it could also be considered of the type Web Page, and even more abstractly, it’s an instance of some root, generic type like Content Object.

This manifests itself as a desire to interpret wireframes and site plans, and generalize them in such a way as to handle situations that aren’t explicitly called for. Developers have mental conversations like this all the time:

Well, a News Article is really just a Page with a Date and Author. If we add a date field to the Page type, then we can collapse those two types into one. And then, in the future, they can create mixed lists of Pages and News Articles. For that matter, I wonder if we shouldn’t just make Help Topic a Page too. We could make just the Subject attribute a category assignment, and now we have one less type and those can be added to lists too. Plus, they could add Subjects to other types of content too. You know, the home page wireframe didn’t call for it, but I could see them wanting to add these lists in the sidebars in the future.

Some of this might be interpreted as laziness, but it’s mostly a genuine attempt to enlarge the solution to encompass scenarios which the developer is projecting onto the users. If a user wants to do thing X, then the developer naturally thinks ahead that he might want to do thing Y in the future, and the developer can address that need in advance.

There’s truly nothing a developer likes more than hearing an editor say, “We’re thinking about maybe doing thing Y – “ and cutting them off, leaning back in her chair, and saying, “No problem. I figured you would want that so I already handled it for you…” [insert exaggerated, magician-like hand flourish here].

Some of this is healthy, but sometimes developers can be a little too clever. We’ve discussed previously how developers are used to thinking about complex information problems and dealing in abstractions. Occasionally they can be convinced that editors will share in that enjoyment and skill. But usually, editors like concreteness to the same extent that developers like abstraction.

Developers and site planners need to have productive conversations about whether the site plan is suggestive or literal, and those need to be followed by conversations with editors about things they might want to do in the future, and then those need to be followed by conversations with project managers about how these things might affect budget and timeline, both for the immediate project and potentially for follow-on projects as well.

In some cases, developers might need to be reminded that they’re not building a framework or an abstraction. They are, in fact, building an actual website with a finite set of problems to be solved.

When content modeling is complete, the basic content structure should be available, and it should be resilient, which means protected from careless (or even malicious) usage. Types should be validated correctly, any hierarchies or relationships should be enforced, and the editorial interface should be intuitive and safe for editors.

Early Content Migration

While the entire next chapter is devoted to content migration, it’s important to note that it should begin in some form as soon as a valid content model is available. Many implementations have run off the rails at the end when “real” content is migrated, revealing multiple problems.

Content migrated at this stage doesn’t have to be complete or perfect, but it needs to be pushed into the system regardless. There is just no substitute for having real content in a CMS while it’s being developed.

Early content migration can be considered “extended content rough-in.” Much like the continuous integration philosophy in development seeks to fully integrate code early and often, a “continuous migration” philosophy seeks to integrate content early and often.

The risk of not doing this is that the development team only works with a theoretical body of content. Sure, they’ve roughed some in to the extent they need to continue development, but it’s not actual content – it was contrived simply so they could keep developing, and it was created by someone with intimate knowledge of how the system works. Consciously or subconsciously, the roughed-in content was designed to avoid delay, not to accurately represent the real world.

Real content has warts. It frequently has bumps and bruises and doesn’t quite match up with what you envision. You need to account for missing data, varying formats, problems with length, missing relationships, etc.

The prior warning about developing in an “administrator bubble” holds just as true for content. Don’t develop in a “contrived content bubble.” Unless the development team occasionally have to stop and deal with content that is representative of what the site will eventually have to manage, they’re going to take liberties and ignore edge cases that will cause problems down the road.

Templating

By this point, the environment is set up, the CMS is installed, the content model is created, and roughed-in content is available.

Finally, it is time for templating. This is the moment you’ve been waiting for, when you actually get to generate some presentations of the content you’re implementing this system to manage.

Templating comes in two forms:

• The surround, which is the outer shell of each page
• The object, which is the specific object you’re presenting

Remember, the output of the object template is “injected” into the surround. Your object is templated, then this output is nested inside the shell of the surround.

Surround templating

In most cases, the surround has to work for all content. While having multiple surround templates can happen, it’s uncommon. In most cases, the template architecture has a single surround that is flexible enough to adapt to all content types. In some cases, surrounds can even nest inside one another, but this is also uncommon.

Templating the surround is unique in that it doesn’t execute in a vacuum. The surround is dependent on the object being rendered for information. The information can be of two types:

• Discrete: Information drawn from the value of one or more attributes
• Relational: Information drawn from the position of the content object in relation to other content

Additionally, the surround will often retrieve other content objects and data structures in addition to the object being rendered, to provide data for other sections of the page.

The primary navigation, for instance, is often explicit, meaning there is a specific content aggregation that drives it. Systems with a content tree might depend on the top-level pages for this, while other systems might have a specific menu structure of some kind that lists these pages.

Again, the “tyranny of the tree” can be a problem here – if the top-level pages are in that position for reasons other than being the primary navigation options, then how do you depart from this? It’s not uncommon to see explicit menuing for primary navigation, even in systems that otherwise depend on their tree for navigation.

For example, the surround often depends on determining the correct navigation logic. A crumbtrail, clearly, only makes sense in relation to the content object being rendered. Where that object is located in the geography will dictate what appears in the crumbtrail.

Additionally, many sites have a left sidebar menu. How do you know what appears there? Is it dependent on the current content object in some way? For instance, does it render all the items in the same section or group of content as the primary item? Is the menu hierarchical – does it “open”? How do we determine where and how it opens? Based on what criteria?

Despite this emphasis on global and relational information, some items in the surround are more directly contextual to the content being rendered. For example, a common element in the sidebar (the ubiquitous Related Content, for example) is dependent on the actual content item being rendered. It will extract information from that object to render itself. Do all objects have this information, or does the element in the surround have to account for varying information, and even hide itself if the primary object being rendered is not of a compatible type?

A question often becomes: do elements like this get templated in the surround, or do we template them as part of the content object itself and then inject the results into the surround? Content object templates can often be divided into “sections,” some of which can be mapped to places in the surround. Thus, if the related content element only appears for one type, then perhaps the more appropriate place for it is with the object templating, rather than the surround templating. If this surround element is required in more than one template, however, this is an inefficient duplication of code, meaning it should be abstracted to an include or moved to the surround template .

A full discussion of application hosting is beyond the scope of this book, and thankfully it doesn’t differ remarkably from hosting other types of applications. When discussing hosting, major points to consider and discuss with your infrastructure team include:

• Fault tolerance and redundancy: How redundant is the environment, and how protected is it from architecture failures? Perfect, seamless redundancy is clearly the ideal situation, but it’s rarely fully realized and is often expensive.
• Failover and disaster recovery: If something does go wrong, what’s the process to recover? Will you restore from backup in a new environment, or will you maintain a second environment with a version of your content that you can cut away to?
• Performance: How much traffic can the website handle? How is it load-tested? How fast can it scale to increased load? Can scaling be scheduled in anticipation of increased load? (For example, can you plan a temporary or “burst” scaling of the environment for 72 hours in anticipation of increased traffic after a major product release?)
• Security and access: Who has access to the server? How is new code deployed to the website? Who can approve those deployments?

Regardless of the model and technical features of the environment, the environment needs to be available far enough in advance of launch to be load-tested, have backup and failover procedures established and tested, and have enough test deployments to ensure the process is free from error. What you clearly don’t want is an environment made available the night before launch.

Once the production environment is available, ensure that code deployments have been pushed all the way through and the development team has verified the site is functional in the environment. Many launch plans have been scrapped at the last minute due to unforeseen problems caused by a production deployment happening for the first time.

Training and Support Planning

Editors and administrators will need to be trained in the operation of the new CMS. Two different types of training exist:

• CMS training: This is generic training on the CMS at its defaults, which means training on Concrete5 or Sitecore or BrightSpot or whatever system your website was implemented in. This is usually provided by the vendor.
• Implementation training: This is training on your specific website, which means understanding how the generic CMS was wrapped around your requirements, and understanding concepts and structures that might exist in your website and no other. This can only be provided by a trainer familiar with the implementation, since the vendor has no knowledge or understanding of how its product was implemented.

Both are valuable, though the latter is more important for most editors. Understanding how the underlying CMS works is not without merit, but editors will primarily need to understand how the features of their particular site were implemented. Relevant aspects of the underlying architecture can be worked into that training as necessary, but it’s common to have a select few “product champions” in the organization who know the basic system inside and out, and for the rest of the editing team to simply have specific knowledge of the work within their professional jurisdiction.

Beyond the initial training, a plan should be put together for training future editors. In larger, more distributed organizations (e.g., a university), new staff might be hired each month who will need training on how to add and edit content in the CMS.

In addition to formal training hours, an ad hoc training and support process needs to be considered. What happens when an editor has a problem, or needs more in-depth help with a content initiative? Who is available to walk editors through the system on short notice? And how will the CMS fit into the organization’s existing IT support infrastructure? Is the IT help desk aware of the new CMS? Do they know how to use it? How do problems get escalated?

Sadly, training is seldom given much attention, and many organizations do as little as possible in the hopes that it will all “just work out.” Remember that training is a direct foundation for user adoption. When users understand and are comfortable with the system, they are more likely to embrace it and use it to its fullest capabilities. More than one project has failed due to tepid user response that grew out of a lack of understanding and training .