Step 1: Define the dimensions of your Information Model

We begin by defining the dimensions to identify the categories in your Information Model. These categories become the metadata we will use to label the content and make it modular.

First, the dimensions must be based on business information requirements. For example, we may categorize different product types and models, market segments, or subject matter.

Second, the dimensions must be based on author requirements. For example, we may categorize information by author, title, ID, editor, approver, original date, revision dates, version number, source and so on.

Third, we base the dimensions on user requirements. For example, we may categorize information by user job, skill level, experience, language, country, and so on.

We find it useful to develop use cases or scenarios of use, narratives that describe how authors, business analysts, and users will interact with information in the future. The more use cases we are able to construct, the better your solutions are likely to be. Not only will use cases allow us to define author, user, and content requirements more precisely, but they will provide us with a valuable way to evaluate tools and technology.

Your Information Model provides the terminology (taxonomy) to identify all the elements in your repository. One of the unexpected benefits of the process is discovering additional opportunities to improve your content, workflow, and reuse. It is much easier and less expensive to discover these opportunities early rather than later in the process. Using our expertise is likely to result in significantly lower future costs.

Step 2: Identify your information types

Then, we move on to identifying your information types. Information types define the kind of content your authors create and how the details are organized. Each information type will be based on the needs of your user community. A typical set of information types for technical information includes concepts, procedures, and reference modules. More specific information types can be derived from these basic types. For example, your organization might need different information types for maintenance procedures and end-user procedures.

Step 3: Review your delivery requirements

Next, we review your delivery requirements. What can be automated? What can be personalized or customized? What media must be supported now and in the future?

Step 4: Identify the content units

Once we have identified a minimal set of information types, we go inside the types and identify the content units that authors will use to construct the types. The content units are the components of the subject matter that will guide the development of formal Document Type Definitions (style sheets in XML or SGML) if you plan to use structured authoring systems.

Step 5: Investigate technology solutions

At the same time that we are defining the three-tiered structure of your Information Model (dimensions, information types, content units), we may begin to investigate technology solutions. However, we strongly recommend waiting until after your Information Model is quite firm to define the technology you need. Until you know in some detail how you want to deliver information to your user community and we formulate your Information Model, you are not ready to make a sound technology decision.

Step 6: Write a functional requirements document

We use all of the information we have gathered thus far to write a functional requirements document. We detail how you want to support your authors with authoring and workflow capabilities, what the content-management system must include so that you can store, manage, and retrieve modules from the repository, and, most important, how you should assemble and deliver information to your users.

We do not specify and design solutions. We stick to requirements alone. We identify and explain what you have to do. We let the vendors explain how they will accommodate your needs. We try not to place unnecessary limits on the technology solution. There will be new developments in the field that you have not anticipated.

Step 7: Ask vendors to submit a request for proposal

We ask vendors to respond to your functional requirements (as a request for proposal). After we have analyzed the responses for completeness and clarity, we ask for presentations. We use your requirements document to question the vendor representatives and be sure that you get satisfactory answers. Be aware that everyone exaggerates their capabilities to some extent. We ask for clear statements in writing about what is standard and what needs to be customized. We are very specific about compatibilities between your requirements and each tool you are considering. We ask about ease of integration between tools because integration problems can sink an otherwise sound specification.

Step 8: Visit other organizations

At the same time, we visit other organizations that are using the technology. We talk with people in the same roles as your team and find out about all the benefits and pitfalls they have encountered.

Step 9: Request a proof of concept

When you have selected a small group of final vendors, we ask for a "proof of concept" in which the vendors prepare and present their solution with your own information. Recognize that you might have to pay fees for the "proof of concept," because the development process may be quite expensive for the vendors.

One effective technique we use is to write scenarios to test with the products. We know that some scenarios might be impossible to simulate without a good deal of customization work but we are sure to try out standard scenarios for authoring, storing and retrieving, content assembly, and possibly publishing. The assembly and publishing scenarios are likely to be the most difficult to simulate and are the areas in which technologies are most likely to fall apart. If we don't test your assembly and publishing solutions, we may not discover the problems until you are deep into implementation (and your warranty period has expired).

Step 10: Meet with the implementation team

You should be comfortable with the people on the vendor's team. As you narrow your choices, we ask to meet with the implementation team if they haven't already been involved. In many cases, we meet with the sales team initially, but they are often not involved with your implementation. We are certain to communicate your requirements again to the implementation team. They might not be fully versed about your specific needs.

We can save you many problems. We will ask the right questions and we have the skills and experience to help you avoid the pitfalls. We find, when our organization works with an internal team, that our information architects ask questions no one else has asked. Because we have experience with so many implementations—more than any individual company could have—we generally help people anticipate situations that they don't know might present problems.

Deliverables

From our Phase 2 work, we prepare an Information Model (or several interrelated Information Models for your enterprise) that includes the metadata dimensions you will use to label modules in the repository, develop a minimal set of information types that your authors will use to create modules, and define the content units that will make up your information types.

We prepare a guideline for authors for implementing the Information Model. The guideline will include descriptions of the model's components and instructions for their use. Typically, you will need instructions for using the metadata tags correctly, instructions for selecting the appropriate information type for a topic, and instructions for writing in an XML or SGML editor. Writing in an editor usually includes creating links and adding graphics or other media. A well-designed system should include guided editing features that encourage authors to implement the model.

We will prepare a complete draft of your guidelines for authors in Phase 2, to which you will revise and add during your pilot project in Phase 4.

We use the information types and content units to prepare your tagging system in the form of DTDs for XML and SGML authoring. Otherwise, we set up forms-based writing or use systems that either allow unstructured documents to be included that are formatted for desktop publishing or use format-based styles to provide some structure for final formatting.

To guide your technology decision, we write a functional requirements document to send to vendors. However, we make sure that your Information Model is firmly in hand before you make any decisions about technology. Even the simplest choices of technology can significantly influence your ability to implement your Information Model.

With your Information Model completed and your technology selected, we work with you, your Web designers, and your system integrator, and other technology vendors to define exactly how the output from your content-management system will be delivered to your user communities. In all but the simplest solutions, the help of our expert team will save you time and money.

Phase 3

If you would like to learn more about any of our consulting services or you would like to talk to a representative about scheduling an activity, please email or call 303-232-7586.