Chris Kartchner first wrote about CM in the article "Content Management: Getting from Concept to Reality" (

www.press.umich.edu/jep/03-04/kartchner.html). He is a frequent panelist, conference speaker and seminar leader and is a member of Pace University's Academic
Advisory Board for their Masters in Publishing Program, where he also is an adjunct professor teaching modern technology courses. Chris is the former CEO of CDIS, a publishing services firm, and is currently a principal for
Blueflame, a Web consultancy. He may be contacted at ckartchner@blueflameinc.com.

The Web explosion brought with it the proliferation of published content and the heightened need for content management (CM). Before that CM lived primarily in the publishing industry, where it never truly
fulfilled its promise. Now that the "dot-com" hysteria has settled CM has become a focal point again as mature, more traditional enterprises from all industries tune their sites – Internet, intranet and extranet.

Few
enterprises will argue that CM and some type of CM system are not important aspects of their Web software infrastructure strategy. This strategic acceptance helps. However, there are disconnects between making the strategic
decision to work with CM and the tactics required to ensure success. This article seeks to provide some guidance to information technology (IT) organizations preparing to make the CM leap or those who have already made the leap but
found the waters too shallow or too cold.

Before focusing entirely on CM's current audience, it makes sense to understand the genesis of CM. Armed with an historical perspective and knowledge of present realities,
today's IT managers will be better prepared to help CM fulfill its promise.

Though it hasn't necessarily been labeled as such, CM has been around as long as content. The form CM took remained surprisingly basic and
manual for a very long time. In the pre-Web years content was not the concern of technologists but the domain of the publishing industry. Therefore, CM and CM systems were also the domain of the publishing industry and those
attempting to serve them.

The traditional goal of managing content was to get it published to paper. How it happened was thought to be far less important than that it happen. Great care went into the authoring of
content, the editorial process and even the design, production and marketing of a publication. However, little thought went into how the content moved through this process, the potential value of elegant movement or the potential
value of the content beyond the intended publication.

The publishing world survived and operated for centuries on this relatively even technological playing field. People who got into the industry out of a love for
literature have traditionally run publishing firms. Most arrived without management training. English and literature majors don't usually learn much about process control, digital standards or value creation – to many, the
antithesis of the liberal arts.

For hundreds of years, this lack of orientation to technology did not matter, but in the past 10 years, it has become key to the prosperous survival of the publishing industry. The
industry is no longer on an even playing field due to the explosion of the Web as a publishing medium for all, not just traditional publishers.

Technology has forced a significant paradigm shift that has dramatically
changed the publishing industry, the business of content and the importance of CM. This shift began when technology allowed content to be published in forms besides paper: on diskettes, CD-ROMs and eventually the Web. Multiple
forms crystallized the realization that the value of published material went well beyond its finished physical form and that in fact its true value is the content, particularly if it can be re-purposed continually and profitably.
In this environment CM took on a new level of strategic importance.

CM and the "New Publishers"

As the Web began to explode in the mid-1990s the publishing industry was struggling to make the
concept of CM a reality. The focus was not on enterprise-wide CM systems, but on publication-specific systems. This focus was partly practical and partly shortsighted. While the traditional publishing industry struggled, the "new
publishers," those publishing to the Web, rushed to do things faster and better. They bumped into barriers along the way, yet unlike traditional publishers, they acted swiftly to overcome them.

The new publishers
did not arrive with the burden of having done things virtually the same way for 400 years. In fact, the new publishers came with few burdens, just a mandate to get the job done. With near reckless abandon HTML pages started springing up everywhere, from the simplest personal page to relatively fancy consumer-oriented sites, corporate brochureware, intranets and extranets. Since technology and marketing, not literary excellence, were driving the Web explosion, the new publishers were not only open to CM and other technology advances, they demanded it at a whirlwind pace.

In response, the world of CM shifted from serving traditional publishers and specific publications, to serving those publishing to the Web. In corporate environments, this group included everyone who created content
or decided what content should be posted to the Internet, intranet or extranet and, unfortunately, some poor soul in IT whose job it was to get that content into HTML and then on to its designated server. Recognizing that these
functions might not be the best use of IT talent, management started to give the need for CM a lot of attention, more than it ever received in the publishing business.

A CM system for the new publishers essentially has
the same components as a publication-specific system: an authoring/editing environment, a workflow engine with versioning capabilities, a database and an output mechanism. The fundamental business driver for such systems is the
need for non-technical content creators to publish material to the Web without distracting IT from their more traditional and higher impact duties. Since the potential audience for such systems is big, growing and salivating,
several "off-the-shelf" products have emerged.

To varying degrees such systems have met the needs of new publishers, and in some cases even old publishers. Some products, such as Interwoven's TeamSite, were designed
specifically to support Web publishing; others such as Vignette's Story Server evolved from a publication-specific system, and still others, such as Documentum, evolved from a document management system. These and other products
are on their third, fourth or fifth releases. We now have a better understanding of where they came from, what is expected of them and what they do best. How they can be utilized and implemented on an enterprise basis
is what has become critical to the IT world.

With this background in mind, we come to the crossroad of caution that is largely the premise of this article. While we can make a historical and functional case for the need for
CM, it remains difficult to move from recognizing its strategic importance to getting some form of CM up and running in substantial form across the enterprise.

The primary reason for this gap is that different
organizations have different needs that are met in varying degrees by different products, but rarely perfectly by any single product. For "dot-com" businesses getting information to the website easily and accurately is possibly the
most important aspect of the business. The dot-coms may be some of the easiest organizations in which to implement a CM strategy. Such contained work groups with a very specific focus have very definable requirements and a keen
sense of the necessary process when they generate Web content.

For larger enterprises, whose business is something besides putting information on the Web, the challenge is more complicated. The complexity is due to the
sheer volume of content that is generated and is appropriate for corporate Internets, intranets and extranets, as well as the functional disparity between those generating that information and those deciding what gets posted and
when.

The well-oiled software marketing engines generate literature and buzz that would have us believe that a product is designed to accomplish precisely what one needs "out of the box," with little human
intervention. But if the needs of different organizations truly do differ so wildly, then the degree to which a product meets them, by definition, must differ. The degree of business analyst and developer intervention will also
differ. So how can an IT manager deal with this problem? How does one get from deciding that there must be a CM system in place to selecting such a system and planning for its implementation? The following guidelines should help.

Consider but Beware of the Analysts

Years ago the most powerful people in the software business weren't necessarily the technology visionaries, but the public relations wizards who were able to bring
the story of a company's product from obscurity to prominence. Today, the most powerful people in the software business may be the various analyst groups, who wield even more power when talking of different companies and their
products, because they come with the credibility of thought leadership and the assumption of objectivity.

In fact much of what they write is credible and objective. However, be aware that the same software companies
that used to spend wildly getting public relations firms to get seemingly independent and objective articles published in key publications, similarly target the various technology analysts responsible for their sector. To protect
yourself from this reality while still getting the benefit of the analysis don't rely on a single source. In addition to using multiple analyst sources consider consultants that have a relationship and, more importantly, practical
experience with more than one product. This puts them in a strong position to compare and contrast a product's strengths and weaknesses relative to your specific needs.

Understand Departmental vs. Enterprise Scope

It is critical to come to terms with whether you need a departmental or enterprise-wide solution. Understanding these needs will lead to appropriate product selections. Not understanding these needs could result
in a decision with unnecessarily high licensing, training and support costs or functionality that is too limited.

If a departmental solution is what is needed, it may be worthwhile to consider a custom solution.
Traditional buy-versus-build techniques can be used to help with this analysis. It is easy for licensing costs alone for an enterprise-strength CM system to reach and exceed $500,000, to say nothing of the professional services
necessary to make the package work properly for your environment. Frequently, departmental solutions can be built for a smaller budget and still meet your specific needs. Remember that "custom" does not mean "proprietary," so the
support risk of a custom system frequently is no greater than that of an "out-of-the-box" solution. When there is no need to expand the system beyond the department, this approach is valid and worthy of consideration.

When evaluating a departmental request, IT must look beyond the request to consider whether other business units may have similar needs or might be able to benefit from the implementation of a CM system. IT should also look
internally for potential benefits that might make buying an enterprise-class system a better decision, even though the impetus is coming from the departmental or business-unit level. For example, the collective amount of time IT
spends developing, posting and supporting simple HTML pages may be significant, even though no single business unit is particularly demanding.

Success Comes from the Implementation, Not the Product Selection

Assuming an enterprise-wide system is in order, it is not uncommon to pick a department to pilot an implementation. The business unit with the most pressing need normally drives the project. If the decision is made to
pilot a department with the intent of rolling the system out throughout the enterprise, develop a roll-out plan that is ready to implement upon the successful conclusion of the initial pilot and has an IT advocate and owner driving
it. Otherwise, you will have made an enterprise investment where a departmental solution would have sufficed.

The roll-out plan should be based upon the various needs of different business units or departments. IT and
the business units together can best determine these needs. IT may measure needs by the cost of IT support for a unit to get its content posted properly to a website. A business unit may measure needs based upon the cost and
efficiency of the existing workflow process versus a more automated one or the speed and accuracy with which information can be brought to customers. All are valid measures and should influence the order of the roll-out.

Even if an enterprise-wide roll-out is in order, not all content developed may be appropriate for the CM system. As part of the roll-out process IT needs to help the business units make these decisions, which will
change from department to department and business unit to business unit and which require appropriate analysis at the outset of the business-unit implementation.

This is critical to making CM successful on an enterprise basis,
though it is largely in conflict with IT's typical role of aiding in product selection and getting it up on the server, then leaving it to the business unit to make it work. In fact, not only does IT need to stay involved through
the initial implementation, at that point preparations should be well underway for the next implementations at both a technical and business level.

Embrace the Non-technical Complexities of CM Implementation

By now it should be clear that CM system implementation increases in complexity, based upon its size and the varying needs of different business units. This understanding is precisely where many implementations break
down. Many of the complexities of implementing a CM system are not technical, but business-process oriented. Accordingly, there is a gap between IT's knowledge of a selected system and the skill and desire to evaluate and
understand business-unit requirements, even though this effort is precisely what is necessary for successful CM implementation. Its evaluation must include the relevant workflow processes of a business unit, the content types,
frequency and duration of posting, and user make-up.

Realizing this problem up-front is key to successful IT management. IT can then appoint the right type of resource to be the CM advocate. IT can select an advocate
with the necessary technical and business skill both to represent the IT issues and to understand the business processes. The advocate can then develop an implementation plan that best matches both sets of requirements. This
individual should also have ownership of the implementation, with specific time goals and stated executive support for cross business-unit cooperation. It is important that the advocate also have the ability to gain trust and
support from targeted business units.

Hire the Right Consultants to Fill the Gaps

IT has long recognized the benefit of using consultants to provide immediate skills that may be lacking within IT.
While it is obvious that this approach is valid when considering and implementing CM systems, it may be trickier than it appears on the surface. First, if a consultant is being retained to help with the buy-versus-build decision,
select one who will not benefit any more or less from such a decision. Second, make sure the consultant has both the technical and business resources to help coach the enterprise on all phases of the process: the initial
implementation, the development of a roll-out plan and an implementation methodology. Third, if IT is ultimately going to take support responsibility, make sure the consultant provides the proper knowledge transfer as part of the
engagement.

This approach is a sound one for any consulting engagement, but it is particularly important for CM engagements. CM generally requires a skill set not prevalent in IT departments, but one that is important
if IT is to succeed in leading the enterprise through a CM implementation.

These guidelines may seem basic, and they are. But basic or not, they are frequently overlooked because of the varied business drivers. Either
a business unit or IT can drive the need for a CM system. The business unit advocate won't have the same enterprise view and responsibility as the IT advocate, but the IT advocate may not have the business knowledge necessary to
implement successfully.

To overcome this problem senior IT management must recognize the nuances and complexities of a CM implementation. They must assign resources willing to take on a project that will require less
technical skill and more business skill. The assigned advocate must be able to properly select and manage the right type of consultants, be willing to seek out various business units to present the roll-out plan and seek and gain
broad support. This approach and diligence will help IT succeed by leveraging the CM investment on an enterprise-wide basis.

That the promise of CM has cycled through different industries over different time periods
is a clear indication of its validity. More people will continue to develop more content for publication in more forms. IT leaders must fully understand what CM can and cannot do, how to bring that message to the enterprise and how
to develop and successfully implement a roll-out plan. With these skills, they are in a unique position to direct the success of the next generation of CM.