Note: Glossary terms are bolded when they occur in definitions for other terms.

Base taxonomy. Version 1.0 of the taxonomy that includes a base set of categories as well as a schema that supports creation of scope notes, equivalent concepts and associated relationships as needed to meet the use cases.

Change management plan. The process a business will follow to implement changes across the organization. Change management plans are helpful when implementing major changes that will impact the way people do their job and the way the organization will be accountable. For example, complying with new regulations such as HIPAA or SOX (Sarbanes-Oxley).

Content inventory. A listing of all content items in a collection plus any metadata that is associated with them. An inventory is usually gathered using an automated indexing spider or bot that can crawl the directory structure of a repository or follow the links embedded in content items when they are web pages.

Content audit. An analysis of the content in an inventory that assesses it according to evaluation criteria that are pertinent to the particular circumstances or use cases, such as quality, comprehensiveness, currency, use, etc.

Current state analysis. The outcome of the discovery and assessment phase of a project is an analysis that aims to:

• Understand the current state from the business and technology context,
• Understand and clarify the business goals, desired outcomes, and objectives of the taxonomy and information management system,
• Understand the current and desired users and uses and existing and missing information assets, and
• Establish the use cases in line with the business goals and objectives.

The inputs are background research, demonstrations of existing systems, a content inventory and/or audit, user interviews one-on-one or in small groups, and evaluation scorecards or benchmarks. 

KPIs. Key performance indicators are measurements that show how well a program, service or business is meeting its objectives. The key is identifying the requirements that are meaningful and useful to measures and monitor over time, as well as understanding whether it is possible to effectively respond to those metrics. Typically, KPIs are countable metrics that can be instrumented into applications. They tell you how much and how long. However, it is also possible to have subjective KPIs that measure things like user sentiment.

Project implementation plan. A document that outlines the project goals, scope and purpose (the problem that’s being solved), as well as the staff and technical resources needed for the project to be successful. 

Project readout and roadmap. The penultimate deliverable that reviews all the tasks and deliverables included in the project. It is usually presented in conjunction with a roadmap that outlines the next steps and longer-term program for implementing the taxonomy to tag and find content, products and/or services.

Solution architecture. A description, often including a diagram, that describes the business solution within the context of the enterprise architecture. The solution is usually required to operate within these implementation constraints. For example, 

“The solution shall easily integrate with a multi-tier, distributed, component-based, and service-oriented enterprise architecture. The solution shall be built as a service, that is, a piece of business software that is constructed and interoperates in a specific manner. The software component shall have industry-standard application programming interface (API) and perform a discrete business function.”

Solution evaluation criteria. Specifies a scorecard to assess vendor proposals is helpful to ensure that you are comparing “apples to apples.” The criteria usually take the form of a list. They are a simplified version of the functional requirements that indicate what is required and what is optional. The criteria may also take into consideration what the overall criteria will be and how much each of the criteria will be weighted. For example, how much will requirements vs. cost be weighted.

Solution functional requirements. Specifies a list of requirements that describe what an information solution must do to determine if there is an off-the-shelf product available, or how much customization needs to be done to an existing product. Some of these requirements may be based on industry best practices, such as database technology, content display, application programming interface, etc. Other requirements may be particular to the specific type of application such as taxonomy management, knowledgebase, insight engine (a.k.a. search engine), digital asset management, etc.

Solution recommendation. The recommended solution based on an evaluation of the evidence gathered during the assessment process. The recommendation should be based on the evaluation criteria but may also include other considerations that have emerged during the evaluation process. 

Solution vendor demo script and scorecard. This is an outline of a specific set of tasks for vendors to demonstrate. Providing a set of test data for the vendor to use to demonstrate their system is also a good practice because this makes it easier to compare various products. A score card should be used to confirm that all tasks have been demonstrated and to assess and grade each task.

Tagged content. A taxonomy is very often used to tag content. A best practice for early validation of a draft taxonomy is to use it to tag some content. A test collection of tagged content can be used in tagging and finding taxonomy validation protocols, as examples in taxonomy documentation, and as part of taxonomy training materials. 

Tagging guidelines. Complete and consistent content tagging requires some training. Business users sometimes have ideas about tagging that may be counterproductive, for example, that more tags will make content more findable. The best practice is to select the category that the content item is mostly about and not to select all the categories that might be mentioned in the content.

Taxonomy documentation.  The documentation for a taxonomy will vary from project to project depending on the scope of the project and use cases that the taxonomy is being designed to address. Typically, the documentation will cover the taxonomy purpose, design principles, editorial rules, and a listing of the categories and any associated metadata. The taxonomy itself is often delivered as a spreadsheet, taxonomy application or human readable report generated from an application. The taxonomy documentation is often summarized in a briefing intended for business stakeholders and taxonomy sponsors.

Taxonomy governance standard operating practices (SOPs). Once a taxonomy has been implemented it will need to be maintained. This requires a set of SOPs including a value statement, roles and responsibilities, policies and procedures, and a communications plan. See our microsite on Taxonomy Governance Best Practices for more information about these taxonomy governance SOPs.

Taxonomy recommendations. The first stage in building a taxonomy is to provide a high-level outline. This also includes examples of concepts that would be part of each major taxonomy branch or facet. Facets are mutually exclusive divisions of the taxonomy and may be discrete controlled vocabularies for Products, Services, Locations, Business Purpose, People, Events, Topics, etc. The taxonomy recommendation needs to be specific enough to validate with key stakeholders that it meets the critical use cases before building out a base taxonomy.

Taxonomy training materials. Sometimes called “Taxonomy 101,” this is a briefing that explains what the taxonomy is, why it is important for business users, and how to use it to tag and find content, products and/or services. 

Taxonomy validation protocol. The goal of taxonomy validation is to provide confidence that the taxonomy is “good enough” to implement. Validation may involve different techniques so it is a good practice to specify the protocol that will be used to validate the taxonomy and to get agreement from the project sponsors and stakeholders. The validation protocol should cover the validation goals, activities and audience. The challenge is to get agreement that the protocol will provide convincing evidence that the taxonomy will be usable to tag and to find content. 

Taxonomy validation report. Taxonomy validation may be done with an online tool such as Optimal Workshop or manually using post-it’s, file cards, pen and paper, or using a combination of tools. The benefit of an online activity is that it may be instrumented so that it self-evaluates. For example, Optimal provides instantaneous results that can be shared online. Automatically generated results usually provide a good basis from which an analysis can be informed. Exactly what the results mean and what should be done with those results requires expert analysis and advice.

Use cases. Written descriptions of how users will perform tasks outline, from a user's point of view, a system's behavior as it responds to a request. Each use case is represented as a sequence of simple steps, beginning with a user's goal and ending when that goal is fulfilled. (Based on usability.gov definition, now digital.gov)

Use scenarios. Scenarios are more detailed than stories. They describe how a user interacts with a product or service in a specific context. Scenarios are sometimes presented as storyboards that illustrate how people use a product, why they use it, and what they experience.

User stories. Short requirements written from the perspective of an end user in the form:

• Who… What… Why…
• As a… I want to… So that…

Here are some user stories examples:

• As a customer I want to know how to return merchandise purchased online so that I can receive a refund.
• As a contractor I want know how to submit an invoice using the vendor website so that I can get paid.
• As the parent of a sick child, I need to get care as quickly as possible so that my child is able to return to daycare.