One of the most critical steps involved in a content management system (CMS) implementation effort is determining what content you want your CMS package to collect, manage, and publish.
To provide some insight into determining content requirements, I interviewed Jason Meugniot, managing director and CMS Practice Leader at Guidance, an application development and systems integration firm in Marina del Rey, CA. Guidance has helped companies including Foot Locker, The Right Start, and Universal improve the return on investment of customer-facing Web initiatives that include content management, commerce, and CRM.
In this article, Meugniot explores the basic content and technical requirements needed to ensure that a chosen CMS solution meets an enterprise’s business needs. He also offers some tips to help you make sure you're asking the right people the right questions so you'll uncover all pertinent content requirements and issues.
Mapping out content requirements
TechRepublic: What content requirements does an enterprise need to define?
Meugniot: Most second-generation content management customers will tell you that there are far more content requirements than one might initially imagine. That said, every content management system is unique. I usually try to focus on these different categories of content requirements:
- Content worth managing: In many cases, not all content requires entry, modification, workflow, publishing, or archiving. The trick is to identify the content that does and to define it accordingly.
- Entry format: Content, often described as "structured" (as in the case of data in a relational database) or "unstructured" (as in the case of a Word document), comes in many forms. Images and text come first to mind, especially on the Web. However, there are many others, including video & audio, XML, PDFs, faxes, HTML, spreadsheets, etc.
- Purpose: Defining the purpose of your content is just as important as defining the content itself. For example, understanding how an online magazine article will be used electronically will help you define its structure: headline, title, body, byline, and so on. I also find that understanding the relationship between different content elements (or types) upfront can help when addressing system performance and usability, especially in the context of content entry.
- Life cycle: I find it extremely important to understand the “life cycle” of content early in the requirements-gathering process. Headlines, press releases, live events, and media archives can all behave differently across print and electronic channels. Content life cycles are also likely to play a role in sizing your architecture and determining support requirements.
- Audience: Many clients have a pretty good understanding of their target audiences these days. Building consensus around audiences can provide a structure and framework for technology and business decisions down the road, especially if your initiative involves several stakeholders, as they often do.
- Actors: No, I’m not talking about Hollywood movie stars here, but all the different participants, users, support personnel, and other “actors” that will engage the system. Typical CMS actors include content contributors, editors (or approvers), publishers, archivists, and support persons. Remember, actors can also be other systems or technologies. Understanding these will help you to identify your integration points during your technical design.
CMS series: Part 3
This is the third in a series of five articles focusing on implementing a content management system (CMS). The first article in the series, "CMS strategy: Don't put the cart before the horse," examined how to identify the need for a CMS, and the second, "Consider these factors when determining ROI on a CMS," discussed mapping out a CMS strategy and getting corporate buy-in for the project. The final two articles will cover the technical requirements involved in a CMS project and why teamwork is the key to a successful CMS implementation.
TechRepublic: How does Guidance capture the content requirements from your clients?
Meugniot: Guidance’s approach to capturing content requirements involves several activities individually tailored to specific situations or needs. In all cases, we start with a sound understanding of business goals and objectives, followed by a detailed understanding of functional and feature requirements. Once defined and documented, we develop a rapid prototype of the user experience. At this point, we determine the different content elements that are applicable to each page (Web) or screen (wireless, etc.). This is an iterative process that can involve offline storyboarding or visual compositions. However, the final goal is always the same. We find that our clients are consistently more successful at deploying content management solutions after building visual representations of their content and features first.
TechRepublic: Whom do you talk to concerning content requirements?
Meugniot: Typically, I try to talk to every stakeholder—and more than once. Defining content can be tricky the first time around. Without specific facilitation, it’s not uncommon for stakeholders to unknowingly omit suggestions, requirements, or meaningful information. I usually find that a business perspective on content requires a special “translation” to define or uncover the sometimes-elusive technical significance. Stakeholders can include:
- Merchandisers (in a commerce context)
- IT development and support staff
- Sales and marketing teams, which often create and distribute content
- Graphic designers, photographers, or media optimizers
- Customer service representatives, who field calls about existing inadequate or confusing content
- CFOs or economic supervisors (a must)
- Business partners and advertisers, who often provide compelling perspectives
- And, of course, customers, as you will get your most enlightening and valuable insight from them.
|According to a recent poll, CIOs' interest in CMS' split almost evenly.|
TechRepublic: What questions do you ask them?
Meugniot: We ask these types of questions:
- How often will your content contributors update this content?
- Will this content be exported from an existing system for import directly into the new system?
- Does this (image) content require optimization prior to publishing?
- How do multiple content contributors produce aggregated content? For example, a news article might include a picture, a story, and links to related news articles. Does the news story or title need to be entered before the image can be inserted? Is workflow important?
- Does the featured product on the home page vary based on the user’s preference or behavior (viewing or buying habits)?
More to come
Now that we’ve examined how to determine content requirements, it’s time to focus on defining the technical requirements, which will be the subject of the fourth article in my series on CMS projects.