Planning a Content Management Server Project

White Paper

On This Page

Introduction
Project Phases and Deliverables
Planning a Site
Conclusion
Additional Information
Other sources of information

Introduction

This paper describes the phases of building a Web site with Microsoft Content Management Server (MSCMS). The type of site addressed in this paper is a simple Internet or intranet site; however, the phases and recommendations still apply to building a more complicated Web application that includes integration with other applications.

This paper is divided into two sections. The first addresses the phases and the second provides detailed information on planning an MSCMS site.

Building a "Page-at-a-Time" Web Site

When you build a traditional "page-at-a-time" Web site, process is extremely important. Using a well-defined process is the only way to deliver a satisfactory Web application on time. Process is the only way to avoid feature creep, and keep the project on schedule. It's no different with an MSCMS site. Process is important. The difference is that by spending a bit more time in the initial project phases for an MSCMS site, you can build a site that significantly decreases the frequency of costly maintenance releases and speeds your Web site's time to market.

Building a Microsoft Content Management Server Site

When you build a Web site using MSCMS, the same process you use to build a traditional Web site applies. However, some of the tasks performed during the steps are different. Also some of the steps may take more or less time compared to building a traditional Web site. For example, while the planning phase may take a bit longer, the development and maintenance phases are significantly reduced.

One reason for these variations is that MSCMS is a template-based system. This factor provides a distinct separation between the development of the structure of the site and the development of the content. The site building team, composed of Web developers, designers, and project managers, build the site framework, and then hand it over to content experts who populate the site with content. This means that the site building team is actually creating a Web application that non-technical staff will use to publish content. In order for these content experts to be self-sufficient, and therefore decrease the time required for site maintenance, the site has to be built with their unique requirements in mind. As a result of this and other MSCMS features, the Web building process varies from the traditional approach.

Project Phases and Deliverables

The following process is a general methodology. Individual project managers may have different names for the phases or attach different tasks to them, but the methodology is based on common Web development practices. These Web development steps may be performed by an in-house team consisting of Web developers, designers, content architects and experts—or by one of the many professional Web development consulting firms.

For a typical MSCMS implementation, the amount of time spent in each phase is:

Phase	Percentage of Project
Envisioning	10%
Planning	47%
Developing	30%
Stabilizing and Monitoring	20%

Envisioning

During this initial investigation phase, the team determines the goals, objectives, and business requirements for the project. Investigation includes the reasons for implementing MSCMS and the reasons for building the site. Often content management systems are implemented during a redesign of a site or during the creation of a new site. In these two cases, you determine the goals and objectives for the new site before creating it. In many other instances content management systems are implemented to bring order to an existing site. In this case your goal is to reproduce the current site with better processes for content creation and management.

Deliverables

The deliverables at this stage include:

Deliverable	Description
Project Proposal	High-level document indicating the goals and business scope of the project. Sign-off of this document is usually required before the project continues.
Proof of Concept	The Web team may prototype some templates as proof of concept. This deliverable is often completed if the site is a migration of an existing site. This work can often be reused during the development phase.

Planning

In this phase you define all elements of the Web site and project that are required to build it with MSCMS. This includes specifications for:

• Design

• Functionality

• MSCMS related components including navigation, templates, and workflow.

• Deployment

A detailed description of the type of information deliverables during the planning phase is found in the "Planning a Site" section of this document.

Deliverables

Deliverable	Description
Scope Document	Definition of the size of the project including areas of responsibility.
Project Plan	Project Plan consisting: · Project Specifications · Project Schedule · Budget estimate

Development

Like the site planning phase, the site development phase includes a number of tasks that are unique to an MSCMS implementation. From the site development phase forward, the Web development process is usually faster for an MSCMS site than for a traditional Web site.

AN MSCMS development is usually a two-phased approach. The Web team builds the site framework and templates, tests the usability and functionality of both the site and the templates, and then hands it over to the subject matter experts for content development. While these content experts are populating the site, the Web team can continue to work on other development work, like advanced integration tasks, which are not content-related.

Unit Testing

The process of building an MSCMS Web site is iterative. For example, you can build one channel and its associated templates, and hand it over to the content experts before the entire site is finished. This way, the development team can test assumptions made during the planning phase and ensure that the site structure, templates, and workflow meet the needs of the content experts and the content. During this phase, the development team should also test browser and other devices.

MSCMS helps speed the unit testing with its workflow process. Experts test and verify content through this workflow process before it is published.

Most links on an MSCMS site are generated dynamically, so you do not need to test any navigational links. Link testing is restricted to links that have been added manually. These links should also be tested during the content review process.

Deliverables

Deliverable	Description
Web site ready to install on production server	Web site completed to standards specified in project plan. Unit tested, ready for system testing.
Documentation	Complete documentation for functional areas of site and for content experts regarding how to use the templates.
Weekly status reports	Weekly reports delivered to project stakeholders during the project.
Training	Training for some content experts who participate in the unit testing of templates and iterative development cycle.

Stabilizing and Monitoring

This is the final stage in the delivery of the project. It involves deploying the site to the production environment, system testing the site in that environment, archiving the completed project, and launching the final Web site.

Deliverables

Deliverable	Description
Completed functional Web site	Completed Web site installed, tested, and operational in production environment.
Acceptance documents	Documents signed by team members and project stakeholders certifying that the project has been successfully delivered.
Training	Training for Web development or IT groups who will take over responsibility for the site. Training for broad group of content experts.
Archive	Archive of completed site from production environment for future reference.

Maintenance

Just as testing an MSCMS site is faster than testing a traditional site, maintenance is also much simpler. Changes you make to a template are applied automatically to all pages using this template, making design changes extremely quick to implement.

The publication of new content is handled by the content experts, so there's no need to schedule point releases to update content. You can schedule pages to expire automatically without worrying about creating broken links. The Web team becomes hands-off in updating the site and can concentrate on large releases and adding valuable functionality.

As new content requirements evolve, and as the team finds more ways of automating content publication using the MSCMS API, the Web team may be called upon to create new templates, but generally their involvement in the daily maintenance of the site is almost non-existent.

Point Releases

To aid in rapid Web development, and to create a process of continual improvement, scheduling point releases enables you to add functionality without undertaking an entirely new Web project. After each major release, you should schedule a smaller release for any fixes or features that didn't make it into the major release. Since time to market is crucial for Web projects, scheduling point releases enables you to meet the demands of increased functionality and timeliness.

Planning a Site

This section provides detailed information about preparing the project plan for an MSCMS site. In particular, it focuses on areas where planning and building a site may differ from building a "page-at-a-time" Web site.

Areas described in this section include:

• Content Plan

• Navigation Specifications

• Page Template Specifications

• Workflow Specifications

• Functional Specifications

• Deployment Specifications

This section does not address areas of Web site building that are not unique to MSCMS, for example, site design or site map planning.

Content Plan

As part of the planning process, the business users and content experts should develop a content plan. This plan identifies all the types of content on the site and their sources.

Use the content plan to determine what type of page templates will be built.

Content Sources

The development team must be involved in the content plan in two instances:

• determining how to port content from an existing site, either manually or through script. For more information about strategies for porting existing content see "Importing Existing HTML Content."

• determining how to manage content that comes in from external sources, for example, a newsfeed.

Navigation Specifications

The navigation consists of the links that people use to access the major sections and pages on your site. Unlike a static Web site, MSCMS-based navigation is dynamically generated. This means that when a page is added to the site it can automatically appear in a list of links created by a script that uses the MSCMS API. If the navigation script has been well planned, it rarely needs to be changed unless the site is being completely redesigned.

When planning navigation, some questions you should consider are:

• What type of navigation does the site require?

• Is ease of update or design more important? If you use a text-based navigation, the navigation is automatically updated as soon as a new channel is added. If you use an image based navigation you may need to have a designer and Web developer involved, depending on how the site is built.

• Will there be "static" or hard-coded links anywhere on the site?

• Are there "sub-navigations" (sections or pages of links) that would benefit from being dynamically generated? For example, if content is published in one location, you can have it automatically displayed in another location by scripting with the MSCMS API. This type of implementation can significantly reduce site maintenance.

The following is a navigation specification for a sample site. Detailed specifications for the navigation code would be found in technical specifications for the site. The following is usually enough information during the planning phase.

The site will use three main types of navigation. As well, summary pages will be used as an alternative means of navigation within channels.

Global Navigation: Global navigation will be used for the four top level channels of the site. This navigation will be contained in a horizontal navigation bar below the Woodgrove Bank logo. Dynamic HTML rollovers will be used to display one level of sub-channel under the top-level channel.

Local Navigation: Local navigation displays sub-channels under the top level channels as well as any postings in the root channel. Local navigation will appear collapsed and will expand when clicked. Postings in any root channel (or sub-channel) will appear before channels. Channel sort order will be manual (i.e. determined by the administrator).

Breadcrumb Trail: Each page will include a breadcrumb trail navigation from the root to the current page. The breadcrumb trail loops back up the channel structure to the current root channel, adding each step to the left-hand side of a series of links.

Template Specifications

Template specifications play a key part in the design of your site—the success of any site depends on the content, and the success of the content depends on the ease of use for authors. Using MSCMS makes it possible to empower users to post content, but first you must create templates that are easy for authors to use.

If you've developed content requirements and specifications as part of your planning process, you've already done half the work of planning the templates. Using your content specifications, determine what type of template is required to display particular content. For example, a press release template might require specific sections for title, sub-title, release date, body copy, an image, and company information.

When deciding how many templates are needed for your site, bear in mind that a greater number of templates will help you more tightly control the layout of your site. However, this may also create a maintenance problem because you would have more templates to update during future redesigns. Generally, Internet sites have more templates than intranet sites because the content and layout need to be more tightly controlled on public sites.

When planning your template specifications, identify each template that needs to be built, the type of content it will contain, any formatting restrictions, and the user groups who will use this template. You may also want to specify and build templates for specific browsers and devices.

The following is an example of the type of information that should be included in a template specification:

Job Posting Template

Used For:

Job postings in the Careers section of the site

Template Gallery:

Careers

Placeholder Specifications:

Placeholder Name	Placeholder Specifications
JobTitle	Text only, no formatting
JobDescription	Text only, bold, italic, and HTML styles
Qualifications	Text only, bold, italic, and HTML styles
ApplicationInstructions	Text only, bold, italic, and HTML styles

Functionality

This page displays a set of Related Links to pages that have the same classification using custom properties.

Custom Properties

Property Name	Values
Job Category	Administration Technical Customer Service Business Development Investment Strategy Account Management
Skill Set	Senior Management Entry Level Management/Supervisory Administration Intermediate Senior Non-Management

Workflow Specifications

The workflow specifications define either how the out-of-the-box MSCMS workflow will be used, or if a custom workflow will be created, how it will be defined.

When determining workflow for a new implementation of MSCMS, it is recommended to use the out-of-the-box workflow for at least the initial implementation. This is because, while MSCMS makes it much easier to publish content, it's possible to set up an extensive workflow that is so complicated that content never gets published. Make sure business users are accustomed to using a workflow and taking care of publishing their own content before adding too many levels of routing and approval.

The MSCMS out-of-the-box workflow is quite flexible. Rights can be assigned on an individual and group basis, and users can have different rights to different areas of the site. When planning the workflow you'll need to determine:

• Can existing Windows Active Directory Services or Windows NT users and groups be mapped directly to the MSCMS roles?

• Do any new groups need to be created?

• What MSCMS rights groups need to be created?

• What rights will they have?

• What users or groups will be members of these rights groups?

The following is a partial example of workflow specifications that address the previous questions.

MSCMS Role	MSCMS Rights Group	Windows ADS Group or Individual Members
Subscribers	Internet Guest Subscribers*	Internet Guest user (domain guest rights only)
Administrators	Administrators	Woodgrove Web Team
Authors	Small Business Authors	Small Biz Managers
	Corporate and Institutional Authors	Corp Managers
	Woodgrove Corp Authors	Marketing
	Job Posting Authors	HR Recruiters

Note: This site will have guest access only.

MSCMS Rights Group	Channels	Resource Galleries	Template Galleries
Subscriber Groups
Internet Guest Subscribers	All	N/A	N/A
Author Groups
Small Business Authors	All Small Business	Small Business	Case Studies Services General Use
Corporate and Institutional Authors	All Corporate and Institutional	Corporate and Institutional	Case Studies Services General Use
Woodgrove Corp Authors	Corporate Root Press Releases	Woodgrove Corporate Logos	Press Releases General Use
Job Posting Authors	Careers	None	Careers

E-Mail Notification

Workflow specifications should also include how e-mail notification will be used. For example, will every event in the workflow trigger an e-mail notification? Will authors be able to specify which editor receives notification when a page is submitted? Will notification occur for events other than those in the workflow, for example, page expiry? You will also need to determine how an e-mail address is derived from the user name. In some organizations it is the same, so "@<domain>.com" can be appended to the user name. In organizations where the Active Directory Services name is not the same as the e-mail alias, some sort of lookup table will need to be used.

Functional Specifications

The functional or technical specifications define how any functional script for the site will operate, for example extended workflow or customized search. Documenting this functionality is very important where more than one person will be developing the site, or where the site will be developed by consultants and then maintained by an internal Web team. These specifications also identify the location of all functional code and how it is included on the site.

When building an MSCMS site, it's recommended that page templates contain only HTML layout and MSCMS placeholders, and that functional script is contained in include files on the file system. These include files make it easier to troubleshoot the script, and they can also be versioned using Visual Source Safe.

The following example technical specification defines the code library used for a site, the location of the include files, and some of the global functions used in the site.

Code Library

File:	/NR/samplesite/includes/library.asp
Defined Terms:	g_objpChannel = object of the current channel
	g_objNavRootChannel = object containing the current Root channel
	g_objpPosting = object of the current posting
	g_objpSearches = search object
	g_strNavRootChannelGUID = GUID for the current root channel
	g_bModeUnpublished = Boolean - true if Autosession.IsModeUnpublished
	g_strpLanguage = String value of either English or Espagñol
	isPPCClient = Boolean - true if the client is a PPC
Functions / Subs:	GetPageTitle = Generates a title for the page
	GetSubChannel =
	LanguageChoice = Generates a link to swap between languages
	IsDefaultPosting = Checks if specified page is a default posting
	IsRootChannel = Checks to see if the passed channel is the root channel

This include file sets up the global terms used throughout the site, and includes a number of common functions. Every page in the site is dependant on this file.

Defined Terms

g_objpChannel	This term contains the object of the current channel in the site.
g_objpPosting	This term contains the object of the current posting.
g_objpSearches	This is an object set up to allow the use of searches in the site. By creating this term, rather than using Autosession.Searches for each search, the performance of the site is improved.
g_objNavRootChannel	This object contains the current root channel. This changes depending on which language section you are currently in. It is defined as /channels/English for the English section and /channels/Espagnol for the Spanish section
g_strNavRootChannelGUID	This string contains the GUID of the current root channel. This is often used to check at what level we are in the site.
g_bModeUnpublished	This is a Boolean variable which is set to TRUE if the current mode on the site is Autosession.IsModeUnpublished
g_strpLanguage	This string defines which language the site is currently using.
isPPCClient	This is a Boolean variable which is set to true if the client is a PocketPC. This is determined by checking if the client OS is WindowsCE.
g_objPlaceholders	Object containing all the placeholders for the current page

Function GetPageTitle()

Returns: HTML title for the current page

This function checks to see if the page is the default posting for the current channel, using IsDefaultPosting(). If it is the default posting, the function returns the display name of the channel. Otherwise the function returns the display name of the posting.

Deployment Specifications

The deployment specifications include information about how the site will be deployed in development, staging or content production, and production environments. They include the server configuration and network architecture diagrams.

In environments where an external team of consultants builds the Web site for a customer, deployment specifications are extremely important because the customer's IT department is usually responsible for setting up the environment into which the site is deployed.

During this part of the planning, consider the following factors and make recommendations in the project plan:

• What other software will be used in the development environment? For example, Microsoft Visual Studio or Microsoft Visual Source Safe.

• Will content authoring occur on the production server or will it occur on a staging server?

• How will MSCMS Site Deployment Manager be used to deploy content, site structure and users among servers? Will the process be automated or scheduled?

• Where is the server for Windows Active Directory Services?

• What is the load on the public facing Web site? Do MSCMS servers need to be clustered and load-balanced? If so what software or hardware will be used?

• How will you deploy functional include files between servers?

• What types of security are in place on the production servers?

The deployment specifications in the project plan are used to verify the environments and deployment during the system test phase.

The following deployment specification describes the development, staging, and production environments for a sample Internet site. These specifications would also be accompanied by detailed network topology diagrams addressing physical locations of the servers and security.

This deployment will use three environments. Microsoft Content Management Server will be installed in each environment. Windows ADS users will be accessed from Woodgrove Bank's primary domain controller. Since there are no subscribers or live authoring on the production site, the production servers do not require access to this domain. MSCMS objects, including content and templates, will be moved between environments using Site Deployment Manager. Include files will be deployed using Microsoft Application Center.

Site Development Environment

The site development environment will be used by site designers and developers only. They will build site structure and templates in this environment. New features and subsequent releases of the site will be developed in this environment.

Test/Staging/Content Environment

This environment will be used to test the entire site before it is deployed to the production environment. All content authoring will occur against this server. Content will be deployed using Site Deployment Manager. Include files will be deployed using Microsoft Application Center.

Production Environment

MSCMS will be installed in the production environment, and the site will be run dynamically. The production environment will consist of four clustered MSCMS servers. The server clusters are managed using Microsoft Application Center 2000 Network Load Balancing (NLB) and Component Load Balancing (CLB) technologies.

Conclusion

Following a well-defined, well-documented, and well-planned process is important for the success of any Web application project. When the process outlined in this document is followed for an MSCMS project, it can decrease the amount of time spent in development and in re-development of the site. Carefully planning the site and obtaining sign-off at the appropriate occasions makes the process run smoothly and ensures all the stakeholders are satisfied with the end result.

The planning and process defined in this paper is based on the implementation of a simple Internet or intranet site with MSCMS server. However, the same process can and should be applied to more complicated projects, for example those including multilingual, personalization, e-commerce, customer relationship management, or wireless capabilities.

Additional Information

For more information about building Web sites with MSCMS, including information about more advanced Web applications, visit:

https://www.microsoft.com/cmserver

For information about using Microsoft Content Management Server to build Web sites, see the user documentation:

https://www.microsoft.com/cmserver

Other sources of information

The following books provide more information about project management and planning for Web and other software applications:

Fleming, Jennifer. 1988. Web Navigation: Designing the User Experience. 1^st ed. Oreilly & Associates..

Rosenfeld, Louis, and Peter Morville. 1998. Information Architecture for the World Wide Web. 1^st ed. Oreilly & Associates.

Applehans, Wayne, Alden Globe, and Greg Laugero. 1998. Managing Knowledge: A Practical Web-Based Approach (Addison-Wesley Information Technology Series). Addison-Wesley.

McConnell, Steve. 1997. Software Project Survival. Guide. Redmond: Microsoft Press.