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.
