The deployment specification, which I describe in this section, you actually want to develop along with the other specifications during implementation. It details the process that you undertake to roll out your system. The deployment specification includes the following parts:

• The power-up schedule: This schedule details the plan that you devise for powering up the system. Especially during the earlier stages of development, it's critical so that each team knows your expectations for when you need its deliverables to continue building out the production system.
• The CMS system architecture: This architecture includes all the parts that I mention in the section " The production installation," earlier in this chapter The system architecture should include system diagrams as well as hardware and software requirements for the generic and production installations.
• Integration plans: These plans include schedules and techniques to use to connect the CMS to all third-party products and enterprise systems.
• Staff rollout plans: These plans detail how and when you deploy the collection system to different contribution groups (author groups and acquisition groups).
• Publication rollout plans: These plans describe the order and timing in which CMS-produced publications replace the current publications. This plan shows exactly when the old ones stop and the new ones begin. If you're planning a period during which the old and new publication productions overlap, the plan needs to show how you're handling staffing and synchronization.
• The beta plan: This plan describes the timing and participation that you expect in a beta release. If you're including certain audience groups, the plan needs to state how you plan to ask for or notify them of their participation.
• Expected and allowed volumes: The deployment plan needs to set the expected range and the maximum values for the page views and other transactions that occur in the CMS at release. It should include contingency plans for how to bring more hardware or bandwidth to bear if the actual volumes (of page requests, database queries, or other publication pages, for example) exceed the maximum.
• The distributed system plan: If the CMS system or databases is spread over various locations, the specification should provide a schedule and staffing plan for how the deployment spreads through the set of locations.
• A deployment staffing plan: This plan shows how many and what types of people you need to power up and roll out the system.
• Setup and configuration data: You need this data for all the end-user tools that you must deploy to contributors and other CMS staff.

The deployment specification dovetails with the implementation specs. Whereas each implementation specification shows how to build a particular part of the CMS, the deployment specification shows how all the parts come together as you build them to form the production system and how you intend to progressively release that production system to staff and audiences.

***

Excerpted from Chapter 18, "Rolling Out the System," in the section titled "The deployment specification."

If you own the CM Bible, click here to go to this section in the Web version of the book.

For each acquisition source, ask yourself the following questions to help you understand and design for the constraints that the source owner puts on your process:

• Owner: Who owns or is responsible for this source of content? If it has multiple owners, do they all subscribe to the same rules or procedures? If not, consider creating multiple sources. To consider sources the same, multiple owners need to behave similarly.
• Influence: What influence do you have over the timing, structure, or format of this source?
• Agreement: Can you form a binding agreement with the owner? If so, what form does it take - a formal contract, a memo, an e-mail message? In any case, seek to form the contract in writing so that you're sure that even an informally arranged agreement is specific. If forming a binding agreement isn't possible, how do you ensure that the content is delivered consistently enough to enable you to adequately plan for it?
• Source units: In what sorts of units does this source arrive (for example, individual files, database tables, or CD-ROMs full of content)? How many and what types of components are in each unit. PLAN, for example, may receive a file each week containing news stories from an international distributor. Each file may contain between 50 and 100 stories that give rise to three or four press-release components (stories that PLAN wants to modify and redistribute) and 30 to 40 news components.
• Delivery: In what format or formats does the source arrive? How does it arrive (via direct connection, FTP, and so on)?
• Escalation: Who do you contact if the content doesn't arrive in the way that you expect? To whom do you escalate the issue if it isn't quickly resolved?
• Start-up quantity: How much of this source do you need to process before the CMS launches? When does it need to arrive for you to make it ready for launch?
• Run quantity: How much of this source do you expect to receive on an ongoing basis? How far in advance of a publish date do you need it delivered?
• Changes: How can you make sure that the content that you receive is the latest or master version of the source? What provision can you make for parts that arrive late or change after they're officially passed off to you?
• Feedback: What provisions can you make for feeding back information from the CMS team to the content owners for improving the delivery process?

***

Excerpted from Chapter 25, "Accounting for Acquisition Sources," in the section titled "Source Relationship."

If you own the CM Bible, click here to go to this section in the Web version of the book.

The steering committee is the ongoing remnant of the mandate and requirements processes. They are the people in the organization that have a continuing interest in the system and enough authority, expertise, or both, to determine the direction of the CMS. The steering committee can have representatives from the CMS project sponsors, members of significant contribution and publication groups, and CMS analysts and other project team members with continuing knowledge and responsibility for the system. The steering committee can do the following:

• Set CMS standards, including content modeling trade-offs, when to make a custom collection or publishing process into a standard process, and when and how to extend current standards to include new groups.
• Work with new teams to determine whether they should become part of the CMS initiative, and, if so, when and how to integrate them into the current process.
• Resolve content-sharing conflicts between groups with competing needs.
• Serve as the ultimate supervisors of the CMS and repository teams.

***

Excerpted from Chapter 12, "Working Within the Organization," in the section titled "The CMS steering committee."

If you own the CM Bible, click here to go to this section in the Web version of the book.

The community's host is the organization that's in charge of the site's infrastructure and maintenance. This organization must implement a CMS, communication services, and member-administration services. It must also input enough content to get the site off the ground. You find the following two typical types of hosts online:

• Commercial hosts: A commercial host has the members as a target market for goods or services. This host is willing to trade the cost of maintaining the site in return for exposure to the members. In a typical scenario, the host has the original idea for the community, creates an initial implementation of the site's system, fills the system with enough content to make it viable, and then launches the site and opens it to members. The host continues to feed content in, administer user data, and create communication events. The major issue to resolve in this circumstance is what right the host has to market to the members or sell member data to outsiders. Members can leave if they feel exploited. On the other hand, the host may stop if it sees a lot of cost and little return from the community.
• Member hosts: A member host is one or more potential members who decide to create a Web presence. Typically, some existing trade or interest organization with a current membership organizes and funds the initial system. As in the case of the commercial host, the member host creates an initial implementation of the site's system, fills the system with enough content to make it viable, and then launches the site and opens it to members. The key issues here are: continued funding of the site from often cash-strapped organizations, and sufficient attention paid to the site maintenance by what is often volunteer-run organizations. Of course, selling member data is also an issue for member-hosted communities.

For both the commercial host and the member host, the primary issue is to make the site truly belong to the members. As time goes on, members should become the major contributors to the site, with the host needing to supply less and less content. In a high-affiliation community, members even plan and execute the communication events (chats, online meetings, and so on). If the community is successful, then its success comes from the host's creation of a system that promotes affiliation and targeted knowledge-gathering - among a group of people who naturally gravitate to a clearly stated and well-founded common interest.

In any case, for the community to become successful, it must have a full-featured and robust CMS behind it. Without a CMS, the site can serve neither its members nor its host. At best, it becomes an enhanced bulletin board, and at worst, it becomes an unenhanced bulletin board.

***

Excerpted from Chapter 10, "The Branches of Content Management," in the section titled "The host."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Writers, public speakers, and other communication professionals, have used the concept of an audience analysis for a long time. A lot is written on this subject, appearing in textbooks and the popular press. Most of the work that I've seen boils down to the following seemingly simple points:

• Who are these people objectively? What are their ages, interests, jobs, and other relevant data?
• What does this audience already know and believe about this subject?
• What are people's needs and desires for new information in your subject area?
• What kind of presentation style are they likely to respond to favorably?
• What publications do they already trust, and to which are they likely to compare yours?
• What's the author's relationship to this audience? Is she a peer, an expert, or an outsider?
• How do you establish credibility with this audience? What do audience members consider good information sources, arguments, and examples?
• What tasks and purposes have they in mind as they approach your material?

This sort of analysis has motivated communicators from the ancient Greek rhetoricians to the modern technical writer and journalist. I believe that it's a pretty good list of the sorts of information that you need so that you can understand how to communicate with an audience. Most of the time, you conduct this analysis quite informally, and it results in an intuitive feel that the communicator gets for how to approach an audience. For a CMS audience analysis, you need to make the answers to these questions explicit and relate them to the parts of the CMS that they're going to help structure.

***

Excerpted from Chapter 21, "Cataloging Audiences," in the section titled "Audiences and communicators."

If you own the CM Bible, click here to go to this section in the Web version of the book.

In the software world, a computer-based process is known as functionality. The functionality that a computer application offers casts a human process into a series of human-computer interactions using a user interface. From the standpoint of the organization, you can say that functionality is the way that you do business by using a computer.

Simply put, functionality is the stuff that you do on the computer. Unlike text, sound, pictures, and motion, which you experience (by reading, hearing, or seeing), you do functionality (by requesting or responding to something). A user interface represents functionality as a set of buttons, menus, dialog boxes, and other controls that give you a particular capability. Microsoft Word, for example, provides table functionality. The functionality is available from the Table menu at the top of the Word window. If you choose the Table › Insert Table command, Word displays a dialog box full of buttons and other controls that enable you to specify how you want the Insert Table functionality to perform. On the Web, functionality is programming code that lives in a Web page or on a Web server. It does useful things such as performing calculations, allowing you to submit data via a form, carrying out financial transactions, verifying your credit card information, and so on.

Functionality's taken the following two major steps over the course of computing:

• It's moved away from monolithic programs, where all the functionality is built-in, toward mix-and-match programs, where the functionality exists in small chunks known as objects.
• It's moved away from applications with the single purpose of presenting functionality toward Web sites in which functionality and content intermingle and become hard to tell apart.

Taken together, these two steps enable you to treat functionality as a form of content.

***

Excerpted from Chapter 4, "Functionality Is Content, Too!," in the section titled "What Is Functionality?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Even if you will have only a couple of audiences, for starters, and a static Web site as your only publication, it is worth your while to study and document an approach to personalization. This approach can include the following deliverables:

• A messaging strategy: This document combines audiences, publications, and components together at a high level. It defines what each audience is supposed to get from each publication and which components and publication design features will be used to communicate with them. It is a high-level precursor to personalization analysis. Particularly for publications targeting external audiences, it provides a marketing context within which to do personalization. For internal publications, your messaging strategy clearly identifies which types of information are appropriate for each audience.
• A personalization strategy: This document goes into detail about exactly how you intend to do personalization in each publication. It specifies a personalization rule for each combination of publication, page, audience, and component. The core of this document is the set of personalization rules. The rules state how to fetch components from the CMS repository, based on what you know about the user, plus the values of the component's management elements. The rules also say which elements to display and how to lay out the components on the publication page.

***

Excerpted from Chapter 15, "Doing Requirements and Logical Design," in the section titled "Personalization strategy."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Like the other analysts I have described, the software analyst strategizes and plans. The software analyst plans how best to accomplish all of the programming that must be accomplished to start and run the CMS.

In particular, the software analyst is responsible for the following:

• Choosing the development environment (or environments) that will be used. There are quite a few competing environments from which to choose. The right one is the one (or ones) that requires the least retraining of the programmers you intend to use, fits most cleanly into the required system architecture supplied by the deployment analyst, and, of course, provides the tools you need to create the needed functionality.
• Creating a development framework. In a CMS, there is code everywhere. From the programming macros in a Microsoft Word document template, to the stored procedures in an enterprise resource planning (ERP) database, there are more programming sites than anyone in her right mind would call a single system. It is the job of the software analyst to get all of these different parts of the system corralled into a single programming framework. The framework organizes the creation of code, its versioning and testing, its deployment, and the sharing of code modules and objects between applications. This is no small task in an enterprise CMS.
• Deciding which features of the CMS should be custom-coded and which should be done using commercially available tools. For example, should the organization use the database connectivity code supplied by the CMS manufacturer or should they extend the code they have now, which works well with their ERP system?
• Writing the specifications and development plans for the programming tasks that require them.
• Creating estimates and plans for the staffing needed to accomplish all of the programming to start and run the CMS.

As with the deployment analyst, there are people in the world who have done this sort of thing before. Still, someone who is a good general analyst but also has significant experience programming content-manipulation applications would serve you best. This is not a rare skill set, but it is not the most common. People of this ilk can be found in the back rooms of Web sites that use Perl extensively, or in the documentation groups of large companies that have had to use Structured Generalized Markup Language (SGML) to structure and manipulate massive document databases. In any case, stay away from the people who think that content can be treated just like data. They will underestimate the complexity of their task every time.

In addition, like the other analysts, this person cannot be a back-roomer. She must be able to negotiate among the competing development interests (which are no less, and often more, vehement than the business interests) and come to a workable compromise between competing platforms.

Finally, be careful not to choose someone who is more interested in writing code than getting other programmers organized. Note that the software analyst's job description does not say "writes a lot of programs." Even if you are in a position to have only one person who is both analyst and developer, because there are so many different places where code will live, it is essential that this person really be interested in staying organized, creating standards, and adhering to them, rather than simply writing code.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "Software analyst."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Someone must set up and run the CMS. I call that person the CMS administrator.

The administrator is responsible for all of the end-user tasks required to set up and run the system. Like all administrators, the CMS administrator is neither a programmer nor a network professional (although experience in these areas helps). Rather, CMS administrators are responsible for tasks such as the following:

• Configuring the chosen CMS. The administrator enters or imports all of the component definitions, user profiles, publication definitions, and other data that the CMS needs to begin working.
• Inputting content. Where content comes into the system in bulk (for example, as the result of a conversion process), the administrator oversees the process and takes action when anything fails. Where content comes in one component at a time (for example, when authors fill in Web forms), she is responsible for ensuring that the proper methods are up and working. This may entail creating new Web input forms, distributing appropriate end-user software, or simply receiving e-mail attachments and importing them into the system.
• Fully understanding the chosen CMS software. The administrator ought to be able to make the CMS do anything it can do without additional programming. In many commercial systems, there is quite a bit that does not require programming. Much of what a CMS is capable of, however, requires you to understand content management concepts and to be able to find the right combination of options (which are often buried in text files and the system registry).
• Maintaining users and workflows. The administrator is responsible for ensuring that all staff that have access to the system are accounted for by the system. Staff may need to be profiled and added to groups in order to get access to the resources they need. In addition, the administrator needs to set up and maintain the system workflows. This may be as simple as dragging and dropping icons onto a page, or as complex as modifying a massive XML structure in a text editor.
• Triaging bugs and finding fixes. After the system is running, the administrator will be the first line of defense against problems that arise. From rebooting after a crash to spending days tracking down why one user can't seem to log in, the administrator must ensure that the train keeps running. Of course, many problems will need to be escalated past the administrator, but like the triage nurse in an emergency department, she sees them all first.
• Ensuring data hygiene. The administrator ensures that the content stored in the repository is in the best state possible. This responsibility includes making sure that required data is supplied, that content is archived or deleted on the specified schedule, and that periodic reviews and updates to content and system configurations happen as scheduled.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "CMS administrator."

If you own the CM Bible, click here to go to this section in the Web version of the book.

In society, communities are groups of people that share some common purpose or kinship ties. The situation is no different online. Although many people talk about creating online communities, few do so from this sort of understanding. The most popular concept of community I have heard is to become "the place" to go for some sort of information. If you add a chat room or a threaded discussion, and collect user data, it is called a community. Many community sites hope to "own" the attention of their users and sell it to advertisers or direct it toward other organizational goals.

Without real community, however, which offers a core of common purpose or kinship (in the widest sense of sharing some important aspect of life), these sites can never really be communities. To be a real community, an online community needs to fulfill its members' needs for affiliation and knowledge. Affiliation is the members' desire to belong to something. Knowledge is the members' desire to know something. More to my current interest, a Web-based community needs a system behind it to support both affiliation and knowledge.

***

Excerpted from Chapter 10, "The Branches of Content Management," in the section titled "Online Communities."

If you own the CM Bible, click here to go to this section in the Web version of the book.

I believe that you can do e-business the same way you do content management. That is, you can create a process to collect, manage, and publish information and functionality to a set of target audiences. Information and functionality are the content of e-business. To do e-business or content management, you must do the following:

• Collect content. Your organization must set up systems that efficiently capture the information and the functionality you want to deliver. To collect content, you need editorial and metatorial systems. Editorial systems ensure that the content has appropriate and consistent format and style. Metatorial systems ensure that the content is appropriately and consistently tagged to be part of the organization's content scheme.
• Manage content. Your organization must set up a system to store and organize information and functionality outside of any particular delivery channel. Management systems are usually databases of one sort or another that store and categorize content, making that content easy to find and retrieve.
• Publish content. Your organization must set up a system to design and deliver the right information and functionality in the ways that your audiences expect and respond to favorably. The publishing system undoubtedly will manage a comprehensive Web site, but could and should manage the other sorts of publications your organization needs.

If your organization is wise, it will look past the hype and vague promises of e-business and focus instead on how to use the new technologies that become available to do what it has always needed to do. This work ought to give you an approach to all of e-business, not simply to the application of content management.

***

Excerpted from Chapter IN, "Three Good Reasons to Do Content Management," in the section titled "How do you do e-business? ."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Localization and content management go hand in hand. In fact I'd go so far as to say that the central issues of localization are one form of the central issues of content management, as the following list discusses:

• Collection: How do you author or acquire content in a way that frees it from its context by explicitly stating its context? For localization, you make content free from its locality by tagging the parts that are locality bound. In content management in general, you make content free from any particular audience or publication by tagging the places that are audience or publication specific. In both cases, you're not trying to remove the context of the content but rather to explicitly state it so that you can formulate and implement logical rules for the use of the content. In a collection, for example, you can tag each example with the localities that it's useful for. You can develop alternative examples for your other localities.
• Management: How do you store and administer content in such a way that people can find, access, and most easily use it? In localization, the point is to deliver content to the localization team as efficiently as possible. Doing so may mean delivering only the examples that need translating to a particular language because you're tagging them for the locality that uses that language. In the wider content-management world, of course, management is responsible for delivering content to wherever it needs to go.
• Publishing: How do you ensure that the right content gets into the right publication in the right locations? In localization, this task is a matter of selecting the localized version of the content. You may, for example, want to make your CMS select and display only examples that you tag for the locality of the current user. In content management in general, of course, this concept is the central purpose of the entire publishing system.

Localization can come into play in any or all portions of your CMS design. Thus I leave the detailed discussion of localization analysis and design to the specific applicable sections throughout this work. I leave this section with the following two general principles of content management that apply especially well to localization, and I offer them as general guides to localization:

• Conservation of work: A CMS doesn't reduce the amount of work that publishing content takes; it merely shifts the burden of that work from a human to a computer. In localization, you want to adopt the attitude that your job is to put as much of the work as possible onto the CMS. You can, however, only shift it so far. If you want content that's useful to people, you can't escape that fact that people must do a core of the work.
• Balance of generality: The more general that you make your content, the easier it is to reuse. The more general it is, however, the less it communicates. You must balance a CMS between the constraints of reusability and strong communication. Similarly, you must balance the need to communicate at all with your key localities with your need to communicate well with your primary locality. Whenever I say, "on the fly," I tip the balance a bit toward my primary locality to give them deeper and wider understanding at the expense of other localities that may get less understanding.

***

Excerpted from Chapter 21, "Cataloging Audiences," in the section titled "Localization and content management."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Localization is the process of making content as understandable as possible in the variety of cultures in which people view it. I'm going to work back from this definition to one that's more useful in the context of a CMS.

The definition has the following three major concepts:

• Culture: I want to keep this very complex issue as simple as possible and define culture as a set of shared communication and behavior standards that a group of people adopts and upholds. Not all that long ago, geography was the main indicator of culture. People who lived near each other shared a culture. Today, that's too simple a way to look at it. As anyone who's walked down the street in any major city of the world can tell you, cultures aren't countries. Today, I'd define culture as a dynamic mix of language, region, ethnicity, and other affiliations. To stay within the general bounds of the accepted localization terminology, I use the word locality and not culture to capture the concept of localization.
• Understanding: What makes content as understandable as possible? Clearly the language in which you write any text is the biggest factor. But it's not just language. As I discuss in the following section, translation is only the start. You must recognize and change a world of other, more subtle local conventions.
• Process: Localization is a process. In fact, I'd say that, by and large, it's an authoring process. Content that someone authors for one locality someone else must then reauthor for another. The localization process encompasses many mechanical parts, where bits of content move from person to person for processing. But after the content arrives on the localizer's screen, the mechanics end and it becomes a human process of knowing what "works" in one locality or the other.

***

Excerpted from Chapter 21, "Cataloging Audiences," in the section titled "What is localization?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

A workflow, as I present it in this work, is a sequence of tasks that a staff member performs and that some event triggers. A workflow entity is a collection of data that specifies the tasks, staff, and triggers for a particular workflow.

Workflows involve steps that form a set of sequenced operations. For each step, you must collect the following kinds of data:

• An object, which is the part of the CMS that the step affects.
• A task, which is a discrete activity that makes some change to content, publications, or the CMS structure or configuration.
• A staff member, who performs the tasks as part of her job.
• A trigger, which is an event that signals that the step is to begin.
• A duration, which says how long the step is to take.

***

Excerpted from Chapter 19, "The Wheel of Content Management," in the section titled "Workflow and staffing."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Cutbacks may be natural, but they're not easy. Someone's desire is thwarted for this version, and she isn't pleased. In addition, you must go back and redo some amount of the planning process to account for the change in project scope.

You have a few tools for coping with unhappy campers. First, you have the prioritized requirements that you originally collected and had approved. Your cuts should start at the low-priority content and publications, to be fair to all and to avoid conflict. Second, you have your sponsor group, which is in place to help with just these sorts of events. Make your case for cuts to your sponsors, not to the people whose requirements you must deny. Finally, you can console hurt feelings with the assurance that a high-priority implementation in version 2 can produce a much better result in the long run than a low-priority implementation in version 1.

You also must decide how far back in your planning to make the cut, as follows:

• Do you simply need to scale back the logical design? If so, you can get by with some markup on your design documents, showing which parts must be postponed. In addition, you must make whatever changes are needed to your project plan.
• Do you need to drop requirements? If so, you need to get the requirements reworked and approved again. Then you can mark up the design documents and project plan.
• Do you need to change the goals? If so, you need to reconvene the mandate group to make the change. Then you can make the corresponding changes to the requirements and get them approved again. Finally, you can change the design documents and project plan.

Obviously, the further back you go in the process, the more work it is. On the other hand, the further back you go, the bigger the change you can make. Personally, I think you derive collateral benefits from reengaging your mandate or requirements group. Doing so gives members a chance to stay active as a part of the process and to reassert their support. You want this to remain everyone's project.

***

Excerpted from Chapter 17, "Implementing the System," in the section titled "Cutting back."

If you own the CM Bible, click here to go to this section in the Web version of the book.

All project managers attend to the scope, schedule, and budget of their projects. It is really no different in a CM project. Project managers usually appear most in the start-up phase of a CMS. After the CMS is running, the other sorts of managers tend to step in and take charge.

Project managers do the following:

• Manage project staff, apprising them of their deliverables and schedules. Perhaps the most difficult thing in managing a CMS project is the potentially long list of characters whose input is needed. Especially during the requirements-gathering phase for the CMS, there are a lot of meetings, phone calls, e-mail messages, and small documents that have to be scheduled, accomplished, and accounted for.
• Manage budgets, assuring that the money allotted for the project lasts as long as the project does. Conversely, a good project manager will see an overrun a mile away and let the world know that some sort of change is needed long before the money actually runs out.
• Create and enforce the project plan. It might well be beyond the ability of a project manger to create the plan for a large CMS, but it should be fully within her ability to make sure it is updated and adhered to.

The kind of project manager that you want is the kind that can keep a lot of balls in the air and make sure a thousand little things get accomplished and no one is left out. Project managers with strong technical skills but little ability to negotiate competing constraints need not apply.

A good CM project manager (PM) will have strong negotiation skills and a streak of insistence. The successful CM project is a careful balance of stopping the unending conversation about what content and functionality will be included, and assuring that all relevant and necessary content and features are fleshed out and used. Finally, although your PM need not be an expert in any of the CM skill areas, she should have somewhat the same ability as the Content Manager to understand the staff's subject matter enough to know a big problem from a little one.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "Project manager."

If you own the CM Bible, click here to go to this section in the Web version of the book.

All in all, the Content Manager is the head of the CM endeavor in the organization. Because there is no degree (that I know of) in content management, there are no recognized curricula to pass to get credentials for this position. In addition, few people can say they have much experience being in such a position. Still, there is a core set of skills that you can look for in a Content Manager. The person must be capable of understanding the multiple disciplines involved in CM. They ought to have a good head for at least the following subjects:

• Web technologies, including server and client software and the construction of Web sites and Web applications. She does not need to be a Web developer, but a good Content Manager understands the Web.
• Editorial processes, including the writing and review process. She does not need to be a writer or artist, but a good Content Manager must recognize well-constructed content when she sees it.
• Cataloging and information organization. A Content Manager does not need to be a librarian, but she does need to be good at finding structure and making sure it is enforced.
• Information technology infrastructure, including database and network administration. Because the system has to integrate with the enterprise communication infrastructure and because the collection, management, and publishing systems of a CMS are all network and database applications, some knowledge in this area is a must.
• Analysis and abstraction. This may be the most important, but least measurable, skill of a Content Manager. If you haven't noticed, content management requires you to think very abstractly about information. If you get too stuck in the concrete details of how one page or another looks, you will lose sight of the main goal of CM, which is to break information away from its presentation and instead focus on its structure and how that structure can be used to make any of a range of pages. If this lightbulb has not appeared over your Content Manager's head, you will never have a robust system.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "Content manager."

If you own the CM Bible, click here to go to this section in the Web version of the book.

To really study your sponsors, you can create written profiles that answer all of the learning questions I listed earlier in this chapter Now, if you are truly a consensus builder, you immediately will be questioning the wisdom of this endeavor. Taking notes on people and creating files on them is not the way to gain their confidence and trust. So, if this seems just too risky or Machiavellian, skip it and content yourself with thinking about the questions and discussing the answers you find with the sponsor and your team.

On the other hand, if you can get past the feeling that you are acting like the next J. Edgar Hoover, this approach can be of immense value. If you act covertly and sequester the information you collect, then you will indeed be doing espionage. If you are open about your motives and up-front about your techniques, however, you are just being conscientious. Moreover, if you have the sponsors participate in filling out their own profiles and openly discuss the profiles in group meetings, then the profiling process can be as innocuous as any survey.

The point of profiling is to be explicit about how you will approach each sponsor. The more open you can be with this information, the better for everyone. In fact, the degree to which you feel like you can be open with your profiles indicates the degree of general openness in the organization. If you can manage to create a climate in which it is all right to share your approach to sponsors openly, you will be creating just the right climate for honest debate and real agreement.

Still, you can only be an idealist for so long. To my mind, it is always best to lead with complete openness and retreat, as required, to retain you personal comfort and your job.

One way or another, you should have in mind a profile for each sponsor so that you can think explicitly about how to get each one to agree.

***

Excerpted from Chapter 14, "Securing a Project Mandate," in the section titled "Sponsor profiles."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Someone must be responsible for the overall design and creation of the system you will use to change the raw information you acquire into finished content. I call that person the conversion analyst. Her responsibilities include the following:

• Selecting or designing the tool set that the team will need. Given the set of information inputs and content component outputs that the content analyst has specified, the conversion analyst will need to figure out what tools to buy, or create, to make the transformation as efficient as possible.
• Creating the specifications for the programs that tool developers will follow.
• Designing the methods the team will use. Given the inputs, outputs, and selected tool set, the analyst must determine the right set of methodologies to move information quickly through the system.
• Designing the facilities and needed infrastructure if the team is going to be large. For example, you might need to create a large work area where dozens of people can sit and easily interact.
• Planning and estimating the staffing levels and skills that you will need to process the expected throughput of information. It can be difficult to accomplish this task if (as often happens) there will be wide swings in the amount of information that will be received per week.