Taxonomy Governance Best Practices

To remain relevant, taxonomies must be maintained. They must change to account for new kinds of materials being created over time, changes in the world or organization (new products, partners, etc.), and lessons learned through experience with earlier versions of the taxonomy. 

The rationale and best practices for taxonomy governance processes are based on the premise that a team should be established to oversee its maintenance. 

There are many value propositions for creating a taxonomy governance team:

  • To improve search
  • To be responsive to target audiences
  • To provide the capability to measure results
  • Mitigate risks
  • To facilitate complete and consistent content tagging
  • To enable content oversight, monitoring, and improvement

Taxonomy governance is the set of roles, responsibilities, and processes that need to be put in place to guide the development and use of a taxonomy so that it will remain consistent and cohesive as it evolves over time. The governance team sets up and maintains the “rules of the road” for the taxonomy – they are not the “traffic cops” that enforce them. Governance artifacts are items such as process documents and editorial standard guides that are used in the governance processes.

The Initial effort to create a taxonomy can quickly be degraded without effective governance. This is the result of:

  • New kinds of content
  • New, changed, or retired people, organizations, locations, products and services, and other “things”
  • New points of view, relationships, or activities
  • Lessons learned through experience by observing and analyzing taxonomy and content use metrics

Over time, lack of oversight will result in an inappropriate assortment of poorly named categories that are ineffectively organized. Lack of coordination will result in inappropriate, or incorrectly tagged content.

Figure 1 shows the four pillars of taxonomy governance. 

Figure 1 - The 4 pillars of taxonomy governance

Figure 1 – The 4 pillars of taxonomy governance

Value Statement. Value statements are statements about the overall goals and objectives of an application or activity. In this first pillar, there needs to be a description of what it is that is trying to be accomplished and why—what the benefits are to the organization. 

Roles and Responsibilities. The second pillar is roles and responsibilities which describe the kinds of things that need to be decided in order to obtain those goals and objectives.

Policies and Procedures. The third pillar is the policies and procedures which are the definitions of the processes required to support the decisions that then enable and support those goals and objectives.

Communications. Finally, the fourth pillar is communications which is concerned with clearly explaining the definitions of the processes that describe the decisions that enable the goals and objectives.

Value Statement

The value statement identifies the overall goals and objectives related to the activity, and is used to get buy-in from executive sponsors. For example, the goal is to define the taxonomy as simply as possible, but to make technical information findable in a repository containing millions of documents. The taxonomy should be flexible to reflect changes over time, and useful to manage the repository so that documents can be archived or destroyed when they are no longer useful for current operations.

Taxonomy Team Charter. The taxonomy team charter identifies the taxonomy scope and overall taxonomy team responsibilities. The charter describes the team’s structure, and its members’ roles and responsibilities. It lists the objectives of the taxonomy team. Finally, the charter specifies the materials to be created and maintained by the taxonomy team. Figure 2 is an example of a taxonomy team charter

  • The enterprise taxonomy team is responsible for the maintenance of the enterprise taxonomy and other controlled items.
  • To make decisions on changes to the enterprise taxonomy, they will consider the costs and benefits of the suggested change.
  • In addition to maintaining the enterprise taxonomy, the team will:
    • Manage the relationship between the providers or source vocabularies and the consumers of the Taxonomy.
    • Identify new opportunities for the use of the taxonomy across the enterprise in order to improve information management practices.
    • Promote an awareness of, and use of, the taxonomy.
  • The enterprise taxonomy team will maintain the following controlled items:
    • The enterprise taxonomy, a multi-faceted classification scheme.
    • Associated taxonomy materials, such as a taxonomy editorial style guide, taxonomy training materials for content creators, indexers and programmers, the enterprise metadata standard, etc.
    • The rules and procedures of the Team are subject to review by the CIO Council (or a commensurate executive body).

Figure 2 – Example: Enterprise taxonomy team charter

Roles and Responsibilities

A taxonomy team needs to include stakeholders from across the business areas in an organization. The key role is the taxonomy manager, who has the responsibility to be the single point of contact for taxonomy work. The taxonomy should be sponsored and the team chaired by a senior member of the management team such as the CIO or CMO. 

The content owners and content users will vary by the type of organization and/or application. In a B2B organization the key stakeholders are usually the marketing department as the primary content manager and the sales department as the primary content users. In a technical documentation application, the key content owners may be equipment manufacturers and the key users may be superintendents and engineers. Intranets are usually owned and managed by the human resources team and the users are all employees. 

Executive Sponsor. The taxonomy project needs an executive sponsor who can advocate for project resources and mediate or adjudicate any disputes that may arise about the content or the disposition of taxonomy additions and changes. The sponsor needs to have the political clout to shield the team from organization politics as much as possible. The sponsor will approve resources and make the ultimate decision on appropriate levels of effort based on their costs and benefits. They ensure that no changes that affect the rest of the organization are published without their signoff. If the taxonomy team cannot accomplish a task by themselves, they will obtain needed resources. They are the final decision-maker to resolve conflicts between projects that would impact the taxonomy.

Taxonomy Manager. The taxonomy manager generates proposed taxonomy changes (re-labeling, adding synonyms, retagging content, applications changes, etc.) based on analysis of query logs, indexer feedback, and user requests. Then they update controlled vocabularies in compliance with the taxonomy governance policies and procedures. They collect metadata requirements from content managers, maintain the metadata standards, and specify methods to enforce them. They tag sample content using the taxonomy, and assist in producing and updating training materials. The taxonomy manager is the main reviewer of taxonomies and the content tagged with them. They create and maintain business rules for any automated or computer-assisted content classification and indexing.

Content Owners. The content owners represent the critical business stakeholder areas (marketing, public relations, product marketing, legal, etc.) and are responsible for determining what is appropriate content to publish. They determine access control to content management, and any required compliance to internal policies and procedures or legal regulations, for example, identification of any content that has personal identifying information (PII). They work with the Taxonomy Manager to improve the accuracy and usability of the controlled vocabularies for tagging as well as finding content. They are the primary resource on questions of scope, business objectives, target audiences, target web sites, etc. for their domain. As such they are the primary points of contact for any taxonomy issues.

Content Managers. Content managers provide a reality check on any process change suggestions by estimating the costs and benefits of editorial process changes, additional or reduced workloads, etc. They also generate proposed taxonomy changes based on needs of their domain or business unit. They help to obtain data from their systems, applications, and/or repositories. They implement or coordinate the implementation of taxonomy changes in their systems, including process changes, software changes, data tagging changes, etc. They communicate taxonomy governance policies and procedures to their systems and in their domains.

Policies and Procedures

Policies and procedures define the process to add, edit, or delete concepts or associated information from the taxonomy. It also defines the editorial guidelines for taxonomy labels, notes, and other taxonomy-related information.

Core Principles. The core principle of taxonomy governance is that all primary actions related to editing the taxonomy should be driven by policies and procedures. To ensure sufficient review and communication prior to adding or editing a metadata field or controlled vocabulary term, a change request should be submitted. All change requests should be logged and acknowledged by the Taxonomy Manager. An assessment of the benefits and impact of change requests should be completed and communicated as quickly as possible.

Figure 3 - Taxonomy change request ecosystem

Figure 3 – Taxonomy change request ecosystem

Taxonomy Changes. Figure 3 illustrates where taxonomy changes originate in the content management environment and who handles those change requests. Taxonomy changes may be triggered by: 

  • New kinds of content originated by the content creator 
  • New product lines and marketing efforts originated by content and product managers themselves
  • Qualitative or quantitative review like query log analysis by the taxonomy manager
  • End users who make requests directly to content and product managers, or the taxonomy manager, who all sit on the Taxonomy Committee

Basic Taxonomy Change Request Process. The first step in the taxonomy change process is to complete a change request form. Figure 4 is an example of a basic change request form. This form might be posted on the organization intranet, and there might be a link from a taxonomy webpage to a taxonomy change request form. The form might be a static document or an interactive web form, or be available in many different formats. 

In some organizations, one task of the content managers is to be intermediaries for taxonomy change requests, just like they are intermediaries and editors for new content that is going to be published in an application or repository or website. The goal is to collect as much information about the proposed taxonomy change as possible, and to respond with an assessment of the request, and rationale for that assessment. 

Figure 4 – Change request form

Figure 4 – Change request form

Figure 5 is a diagram that illustrates a basic change request process. The diagram shows how changes are prioritized by how simple or complex they are, and whether the change needs to be made immediately or can be published on a regular schedule, for example monthly. The diagram also shows that at each stage in the process, the requestor is informed as decisions are made on the change request priority, until there is a final disposition and the change is made or not made, and the requestor is informed of the rationale for that disposition.

Figure 5 - Basic change request workflow

Figure 5 – Basic change request workflow

In addition to a formal change request process, there needs to be a fast-track change process to make a change quickly, for example, when requested by the CEO, to correct an error that exposes the organization to risk, or other situations in which a change needs to be made immediately. It’s OK to have a fast-track process, but it’s important to go back and complete the assessment and rationale afterwards so the reason for the taxonomy change is documented and can be remembered later. 

Change Request Impact Analysis. There are likely to be many requests to make taxonomy changes, usually too many requests. So, a process is needed to prioritize change requests. A simple set of criteria can be used to rate change requests using a Likert Scale. A Likert Scale is a common method to measure attitudes, perceptions, and values in response to questions. The scale always has an odd number of measures, usually three or five measures ranging from Agree to Disagree, with the middle being Neutral. 

  • Will this taxonomy change improve access to content?
  • Will this taxonomy change require retagging content (a metadata effort)?
  • Will this taxonomy change have a business impact?
  • Will this taxonomy change have a marketing impact?
  • Will this taxonomy change have a user impact?

Table 1 shows some examples of taxonomy change request impact analyses using a three measure Likert Scale with 1 being low impact and 3 being high impact across a set of change impact areas. These sorts of techniques can be helpful in developing the rationale for making or not making taxonomy changes.

Change RequestImproving AccessMetadata EffortBusiness ImpactMarketing ImpactUser ImpactPriority Score
Add new Content Category: Calculators11222   1.6
Add new facet: Programs31221  1.8
Add new Managed Topic: Financing11223   1.8
Change Site Navigation: A-Z Index33231   2.4

Table 1 – Example of change request impact analysis

Types of Taxonomy Changes. Because taxonomies are hierarchical term lists, there is a set of taxonomy change types. Different types of changes have different levels of impact. For example, changing a term label has little or no impact on other terms, and content tagged with that term probably requires no review if the label is changed. On the other hand, splitting usually requires a lot of review to determine how content tagged with the original term should be tagged by one or the other or both of the split terms. Table 2 shows which common taxonomy changes require editorial review of content tagging and which changes don’t require editorial review.

Change TypeEditorial Review Requirement
Changing a term labelUsually has no impact on content that has been tagged with the original term
Adding a new leaf term (to the bottom level of the tree)Usually only impacts new content
Inserting a new narrower term (within a hierarchy)Similarly, only impacts new content
Moving a termUsually requires editorial review to ensure the new context is appropriate
Splitting a conceptRequires editorial review of all content that is tagged to decide which term should be used to tag the content
Deleting a narrower term (within a hierarchy)Requires editorial review if content tagged will become an orphan when there are no other terms used to tag it
Deleting a leaf termSimilarly requires editorial review if content tagged will become an orphan
Merging conceptsUsually has low impact and does not require editorial review

Table 2 – Taxonomy changes and editorial review requirements

Taxonomy Editorial Rules. Like other enterprise resources, the taxonomy should have a style guide. The purpose of the style guide is to maintain consistent style, voice, and tone. Choose an existing style standard such as The Chicago Manual of Style. It doesn’t matter which standard is chosen, but conventions should be established and used enterprise-wide. Table 3 is a set of typical taxonomy editorial rules.

Editorial RuleDescription
AmpersandsUse this special character or the word “and” spelled out consistently in taxonomy labels.
Abbreviations and AcronymsUse the most common form of a label. Sometimes this is the full name, and sometimes it is an abbreviation or acronym. If abbreviations and acronyms are used, always provide the full label as a synonym.
CapitalizationUse consistent capitalization, usually title (capitalize every word of the label) or sentence case (only capitalize the first word of the label).
Content item countProvide a count of the number of content items tagged with terms. This can help evaluate when to merge or split terms based on usage in the content collection.
HomonymsUse qualifiers to distinguish different terms with the same spelling. The same term used in multiple contexts should be qualified to distinguish between different contexts. Parentheses should be used to qualify terms, For example, “Disclaimers (Product Summaries)” and “Disclaimers (FAQs)”.
Label lengthIf the taxonomy is to be used for display labels on a website or search interface, it is desirable to keep labels as concise as possible.
LanguagesSpecify whether the taxonomy will be monolingual, or multi-lingual. Again, use the most common form of the label. Sometimes that may be in another language.
Non-hierarchical relationshipsProvide equivalent relationships for synonyms, and associative relationships for cross-references.
Scope notesWrite scope notes to clarify how a term is to be applied, especially if there may be some confusion about its meaning in a particular context. For example, the term “Agenda” could have a scope note—”Use to categorize an itemized list of topics discussed. Link Agendas to meeting minutes or another formal record of proceedings”.
Serial commas Specify whether the serial coma will be used after the penultimate item in a series of three or more items, for example, “windows, doors, and ceilings” or “windows, doors and ceilings”.
SpacesSpecify whether spaces should be used or not before and after forward and backslash, hyphens, and other special characters.
Special character conventionsSpecify whether other special characters can be used or not, for example the copyright or trademark symbol, forward and backslash, etc.
SynonymsMap synonyms, abbreviations, acronyms, nicknames, and other aliases as alternate terms. Specify how they will be used, for example, as synonym rings in a search engine.
Term orderSpecify whether term order should be direct or indirect. Do not use Inverted terms. Terms should be in direct order, or qualified as much as possible. For example, “Printed Circuit Boards” not “Circuit Boards, Printed”.
Term orderingMost lists of terms will be ordered alphabetically, but other ordering methods are possible such as chronological, for example, “Precambrian Era, Paleozoic Era, Mesozoic Era, and Cenozoic Era” not “Cenozoic Era, Mesozoic Era, Paleozoic Era, and Precambrian Era”.
Exceptions.Consider making exceptions to rules as long as there is clear rationale for doing so.

Table 3 – Taxonomy editorial rules

Use existing internal and external standards and internal vocabulary sources as much as possible. Examples of useful vocabulary sources include:

  • International standards such as ISO 3166 for country names
  • Regional standards such as NAICS (North American Industrial Classification System)
  • National standards such as the Federal Register Thesaurus
  • Internal standards such as SAP categories 
  • Published and internal glossaries, subject lists, business process models and data models.

Invent wholly new terminology sets only as a last resort.

All information should be presented in small digestible units. Chunking is a principle that applies to the effective communication of information between human beings. This idea was first suggested in the 1950s by George A. Miller, a Harvard psychologist. His research suggested that human beings could understand and remember no more than seven plus or minus two items of information at a time. This phenomenon is called the “chunking limit.” Some examples are:

  • No more than nine bullet points on a slide.
  • No more than nine bullet points on a bulleted list. 
  • No more than nine classes in an object model module.

When there are more than nine items, classify information into smaller logically related groups and introduce a subheading. Figure 6 shows an example of factoring a long list of graphics types into a few category groups.

Figure 6 - Example of factoring a list of graphic types into category groups

Figure 6 – Example of factoring a list of graphic types into category groups

Content Creator Indexing. In many organizations, the interest in defining coherent ways of applying metadata has intensified as a result of attempts to implement enterprise portals as a single point of access to company-wide information resources and applications. Another key driver of the focus on metadata in the U.S. has been HIPAA privacy issues and Sarbanes-Oxley regulation, and in Europe by comparable compliance requirements particularly GDPR.

Dublin Core is often seen and used as “integration metadata”, to enable the federation of information in multiple, heterogeneous repositories such as those containing structured (databased), and those containing unstructured (document-like) resources as well as semi-structured resources described by specific metadata elements and encoding schemes. Repositories frequently include legacy (that is, pre-existing) resources. Applications and procedures (typically facilitated by manual workflow) are developed to add metadata to new content.

There are two methods to create and maintain metadata 1) by requiring resource creators to add metadata, or 2) by using a centralized staff. Most organizations use a combination where metadata is collected during resource origination and development, and a central staff is provided to clean-up and/or add metadata so that it meets the corporate standard. Organizations that value and use metadata require a high level of completeness and consistency, and typically have a metadata staff to provide quality assurance. 

The ideal indexing scenario uses machine-aided indexing. In this scenario, various automated methods such as business rules, regular expression extraction, and semantic vectors are employed to automatically fill-in the metadata for a new content item. The content creator is then required to approve or edit the metadata form. Such a scenario will result in more consistent and complete metadata for all content items. Table 4 contains simplified indexing rules for content creators.

Indexing RuleDescription
1. Specificity ruleApply the most specific terms when tagging assets. Specific terms can always be generalized, but generic terms cannot be specialized.
2. Repeatable ruleAll attributes should be repeatable. Use as many terms as necessary to describe what the asset is about and why it is important. Storage is cheap. Re-creating content is expensive.
3. Appropriateness ruleNot all attributes apply to all assets. Only supply values for attributes that make sense..
4. Usability ruleAnticipate how the asset will be searched for in the future, and how to make it easy to find it. Remember that search engines can only operate on explicit information.

Table 4 – Simplified indexing rules for content creators

Communications Plan

Planning communications is essential to building support for and engagement with the project. The overall value of organizing knowledge in a meaningful and concise manner needs to be presented. 

Implementing a taxonomy requires planning and work. Part of this is marketing, part is educational and part is directly related to integrating the taxonomy service in an information management application. Since a taxonomy is not “one and done,” it is especially important to explain the change process so that the taxonomy can be fixed and improved while it is already being used. 

The roles and responsibilities and the decision-making process for handling taxonomy changes needs to be communicated to the end user community. The value of the taxonomy needs to be communicated in a meaningful and concise manner. In summary, a taxonomy communications model needs to identify 

  • Stakeholders and their information needs, 
  • Communication channels, and 
  • Messaging events.

Stakeholders and Their Information Needs. The taxonomy charter identifies some of the taxonomy stakeholders and their roles. The communications plan has a somewhat broader scope to include all taxonomy users. Stakeholders and their information needs are summarized in Table 1.

Taxonomy Stakeholders Information Needs 
ITRoadmap and action plan for planning, outreach and tracking of opportunities and projects. Public work area for sharing, communicating and visibility. 
Content SponsorsPresentations of the business case and functional requirements that sell the project to management and communicate it to other staff.
IT ImplementersAuthoritative versions of the requirements and controlled vocabularies, as well as any taxonomy changes.
Other StaffNatural understanding without being an expert. 

Table 5 – Taxonomy stakeholders and their information needs

  • IT. The IT organizational unit is the ultimate owner of enterprise content management. The program team provides leadership, vision and oversight specifically in defining and maintaining the roadmap of ECM applications where there are taxonomy integration points. The Taxonomy Point of Contact has the specific responsibility for tracking taxonomy integration activities, and proactively reaching out to Content Sponsors who are planning ECM applications and IT Implementers who are engaged in developing them. The most critical information need of the IT stakeholders is to have a well-defined roadmap and action plan for ECM Taxonomy application integration activities. The various requirements documents will be an output of the integration development process, and high-level presentations will be prepared to brief other stakeholders. Providing a publicly accessible work area where all these documents can be shared is a good strategy for facilitating long term communication and visibility for the ECM Taxonomy program.
  • Content Sponsors. Content Sponsors are the customers who have requirements for and use ECM applications. Working with business analysts, project owners make the business case for ECM applications. They are the immediate beneficiaries of taxonomy-driven metadata as it facilitates application development that promotes and leverages content re-use. This needs to be reflected in the business case they make and ultimately the functional requirements that are developed. Making the business case for an ECM application is usually communicated as a high-level presentation that can be easily understood by managers and other staff. Ensuring that taxonomy integration is included in these documents is very important.
  • IT Implementers. IT Implementers translate the business case and functional requirements into technical requirements that can be implemented by developers. Implementers need technical details and access to authoritative controlled vocabularies, and any taxonomy changes need to be routinely communicated to them as well. 
  • Staff. Other staff and even the public will use ECM applications, or information or components of information (such as disclosures) derived from those applications. They need to “naturally” be able to understand the quality, value and meaning of information that someone else has created and owns without themselves being a subject matter expert. Leveraging the taxonomy can help accomplish this outcome.

Communications Channels. Different information types are used to facilitate stakeholder communications during the taxonomy lifecycle. Table 2 defines some of the information types that are primary communication vehicles in the project lifecycle.

Information typesDescription
RoadmapA visual representation to illustrate the timing, criteria and ranking of related projects and activities.
Action PlanA list of action items, owners and deadlines for immediate tasks related to a project.
Business CaseA discussion of the costs and benefits associated with building or changing an application.
PresentationA high-level presentation that summarizes the details of fact finding, requirements, studies or other detailed activities associated with a project.
Functional RequirementsA detailed description of the business and use cases, and list and descriptions of functions that an application or project needs to support.
Technical RequirementsA detailed description of the metadata specification, data entry templates, workflows and presentation templates needed to implement an application.
AnnouncementA press release or similar communication vehicle that informs staff or the public about an event such as the launch of a new application.
WebsiteA public work area for sharing and communicating project documents, and providing program visibility. 

Table 6 –Taxonomy communication vehicles

Messaging Events. The typical lifecycle of an enterprise content management (ECM) project includes the following phases: 

  • Selling
  • Kick-Off
  • Requirements Definition
  • Technical Architecture
  • User Testing
  • Launch
  • Training

Table 3 lists some typical communications events around the application development project lifecycle.

EventsMessage DescriptionFromToChannel
Project SellCosts and benefitsContent SponsorBusiness ManagerBusiness Case 
Kick-OffProject overviewProject ManagerContent SponsorsPresentation
Requirements DefinitionWhat taxonomy is supposed to doBusiness AnalystContent SponsorsFunctional Requirements
Technical ArchitectureHow taxonomy will be implementedSystems AnalystApplication DevelopersTechnical Requirements
User TestingTaxonomy usabilityUsability AnalystsContent SponsorsPresentation
LaunchAnnouncement of taxonomy launchITStaffAnnouncement
TrainingTraining on how to effectively use the taxonomyTrainersApplication UsersPresentation

Table 7 – Taxonomy lifecycle communication events

  • Selling. In this phase of the ECM project, Content Sponsors need to make the business case for building, enhancing or changing an application to Business Managers. This requires analyzing and communicating the costs and benefits associated with the project. In particular, the benefits of using an ECM standard taxonomy need to be articulated. These may include avoiding re-design of standard components, compliance with company policies, compliance with government regulations, alignment with analytics categories, ability to target and re-target content, speed of implementation, etc. It is critical that the taxonomy benefits be embedded in the project at the earliest time possible.
  • Kick-Off. In this phase of the project, the Project Manager needs to communicate the project plan to the Content Sponsors. Integrating taxonomy takes some time that needs to be scheduled so that it does not cause project bottlenecks. It is important to build in considerations of the time to make any taxonomy changes as a result of the new application. This will be more significant in the first few implementations and can be expected to drop off after the first year. The taxonomy can help explain and visualize complex projects, and can be an important component of the business case.
  • Requirements Definition. In this phase, the Business Analyst needs to develop and communicate the functional requirements to the Content Sponsors. This should include use cases that involve the taxonomy, such as, re-use of standard components and controlled values in application templates, use of targeting facets and controlled values such as Audience and Territory, tagging of content by using Product categories so that analytics will be aligned with the product typology, etc. 
  • Technical Architecture. In this phase, the Systems Analyst needs to develop and communicate the technical requirements to the application developers. This should include the specification of taxonomy integration points and identify any additions or changes to controlled vocabularies that are required. Such changes need to be coordinated with the Taxonomy Point of Contact so that they can be scheduled to support the application development project plan. The technical architecture also needs to take into consideration the process for communicating taxonomy changes that impact the application after it goes live.
  • User Testing. In this phase, the Usability Analyst needs to design and conduct usability tests, analyze them and communicate their results to the Content Sponsors. The taxonomy may or may not be impacted by usability tests, but any recommendations for taxonomy changes need to be communicated to the Taxonomy Point of Contact, and then those changes need to be made and communicated back to the application developers and incorporated into the ECM application. User testing and the reporting of their results are also important because they build confidence that the application will be workable and effective. User testing and reporting can function as basic training in the use of a new ECM application. It is also an excellent communication vehicle for creating awareness and excitement about the application.
  • Launch. In this phase, IT and ECM need to announce the ECM application launch to staff. Press releases and demos are frequently used to announce and create awareness and interest in new applications. The extent to which taxonomy is a visible part of the application determines how much involvement and coordination is required of the ECM Taxonomy team. However, in all cases, it is very important that senior management be aware of the role “under the hood” that the taxonomy plays in a new ECM application. 
  • Training. In this phase, Trainers need to communicate how to use the ECM application to the application users. If the application involves tagging, then taxonomy tagging guidelines and training need to be provided as part of the training. The best training is to provide a body of examples. It is also important to receive, log and answer questions related to the appropriate use of the taxonomy for tagging content.

Taxonomy Communications Benefits. In summary, the goals of executing a taxonomy communications plan are to obtain 

  • An increase in valuable feedback
  • More complete change requests
  • An evergreen and up-to-date taxonomy