Business taxonomy, Part III

Taxonomies can be powerful tools. But too often, their complexity defeats the users they are supposed to help. The business taxonomy offers a simpler alternative. In the final part of this three-part masterclass, we examine taxonomy evolution.

By Zach Wahl

In the two preceding articles, we endeavoured to define the business taxonomy as a flexible and dynamic end-user-focused alternative to traditional taxonomies. Where a traditional taxonomy is extremely detailed and tightly controlled, a business taxonomy is simpler and more fluid in order to serve the ever-changing needs of end users.

In last month’s article, we detailed a workshop methodology designed to provide a quick and achievable first step for business taxonomy design. Managed effectively, this workshop methodology will yield a first cut at the highest levels of a taxonomy as well as the beginnings of an overarching metadata strategy.

Now, we must learn how to evolve our taxonomy from the initial workshop product to something worthy of implementation. Moreover, we must make sure that the proper systems and procedures are in place to help the taxonomy evolve in a sustainable manner. This will ensure it is dynamic enough to increasingly and continuously serve the needs of the end users, while being maintained and controlled to the point at which it does not grow out of control.

Getting it ‘good enough’ to implement

After the first workshop, an organisation ought to have developed the initial top level of a business taxonomy and may also have some areas of the second level defined. More importantly, the organisation will have a new team of educated business users, grounded in business-taxonomy design best practices and clear on their mission, to continue the taxonomy design process. It is this taxonomy team that will help the initial workshop product mature into a taxonomy worthy of implementation. There are several avenues the taxonomy team can and should take to get the taxonomy to that stage of readiness.

To begin with, the taxonomy team should schedule additional workshops to provide greater levels of taxonomic detail and refine the work already performed. It must be remembered the role of the taxonomy team is not to ‘wordsmith’, but to use their assorted business perspectives and knowledge of their audience to identify the verbs and, finally, the nouns that will comprise the business taxonomy. As with the first workshop, the role of the facilitator will be critical in keeping the process moving forward and ensuring the taxonomy team does not get bogged down in thinking too deeply about the ‘what ifs?’ of taxonomy design.

As additional workshops are held, the process should become easier. The taxonomy team will begin to take greater ownership of the process. In addition, each subsequent level of the taxonomy should be simpler to complete since it is bounded by the parent topic it represents. At the highest level of an enterprise-business taxonomy, the workshop participants are asked to identify any and all primary topics that represent their organisation.

This is open to a great deal of interpretation and is practically boundless in scope. Once those topics are defined, however, the taxonomy team has a framework in which to proceed. For example, if the highest level of an intranet taxonomy includes a topic of ‘employee benefits’, the second level should be easier for the taxonomy team to define, since it can only be made up of sub-topics from that original category, such as ‘retirement’, ‘insurance’, and ‘discounts’. In other words, each increasing level of detail should be easier since the scope is better defined.

That said, the overall amount of time each level will take to complete may increase, since there will be more of it to define. Assuming a top-level taxonomy of ten topics, the second level might be made up of 100 topics (ten for each parent, for example) and a third level could include as many as 1,000 topics (ten more for each of the second-level parents).

In reality, a business taxonomy will never acquire a perfect pyramid shape, but this demonstrates the potential exponential increase in detail that must be considered. This, of course, also demonstrates why a business taxonomy should remain fairly shallow and simple – so as not to confound business users with too much complexity.

In keeping with the end-user-centric nature of business-taxonomy design, the taxonomy team should utilise colleagues to validate the work performed and decisions made by the group. This process can begin immediately following the first workshop and should continue throughout the taxonomy design efforts.

Taxonomy team members should be encouraged to conduct informal interviews with their colleagues. These can serve as a check on the decisions of the taxonomy team and can also be an important communications mechanism to keep stakeholders informed and involved. These conversations may be as simple as discussing the major decisions of the taxonomy team or reviewing the current iteration of the taxonomy. Virtually any effort to hear from end users will be valuable to the overall design process.

Two more formal options for end-user involvement are card-sorting exercises and focus groups. With card-sorting exercises, end users outside of the taxonomy team will be asked to individually place actual corporate documents within the taxonomy or will be asked where they would expect to find a particular document within the taxonomy.

These exercises can be conducted very easily, either via e-mail, on paper or card or using survey websites. In the case of business-taxonomy design, card-sorting exercises are used to measure the level of agreement on where each exemplar document should go. If your participants are largely in agreement, that is a measure that the taxonomy design is intuitive.

If, however, your participants greatly disagree on particular documents, the taxonomy team should reconsider the design for those areas. Though there is no perfect formula, those answers that do not receive at least 70 per cent agreement from respondents are the ones that generally deserve a second look. Card-sorting disagreement may also be an indicator that the naming for a particular node may require further discussion. Performing follow-up card-sorting exercises to test different naming may also help to avoid the dreaded taxonomy team wordsmith discussions.

Convening focus groups of additional end users may also prove valuable for further design and validation of the taxonomy. In the more complex design efforts, many organisations will choose individuals from the taxonomy team to form focus groups to concentrate on defining the level two or level three topics beneath a particular top level node. For instance, many different focus groups might be convened, each of which would take responsibility for defining the sub-topics under one of the parent nodes.

Though this process helps to bring additional end users into the mix and may expedite the development of the overall design, it requires a great deal of oversight from the core taxonomy team to ensure that all the focus groups are co-ordinated. Inevitably, this approach will result in much overlap and duplication of effort, requiring the core taxonomy team to clean up the work of the various focus groups. Focus groups may also be used to refine naming and to further test usability.

Regardless of the various methods employed, the taxonomy team must keep sight of one core factor. The taxonomy will never be finished. It will never be perfect for every user. There will never be a point at which every user finds it to be completely intuitive. The goal of the taxonomy team must not be to build the perfect taxonomy, but to build a taxonomy that is good enough for the majority of users to find value in it. If that mission is achieved, there will be opportunities to improve it over time. Any higher expectation will result in unruly scope and delays that will risk the entire effort. In short, the taxonomy team should get the taxonomy to the point where it is good enough for users to benefit from it immediately – and plan for it to be even better in the future.

Taxonomy governance

Appropriate governance of the taxonomy will be imperative in ensuring the iterative improvement of the system and will also ensure the site is managed effectively. Lack of governance, or a governance model that is too loose, will result in a taxonomy that quickly grows out of control and fails to serve the needs of its end users. Organisations with little or no taxonomy governance often end up with taxonomies that are extremely deep, poorly named and filled with a mix of different categorisation approaches.

Governance that is too tight, on the other hand, will result in a stagnating taxonomy that changes too slowly to reflect the dynamic needs of business users. The taxonomy team should, therefore, put serious effort into designing not only the taxonomy, but the accompanying governance plan that will ensure the long-term sustainability and evolution of the taxonomy.

Four core components should be included in the governance plan. The value statement, initially defined in the taxonomy workshops, should be clearly published in order to set expectations appropriately and to help any stakeholder understand the who, what and why of the taxonomy design.

Second, roles and responsibilities should be clearly defined. For instance, it should be clear to all stakeholders by whom decisions about the taxonomy design and naming are being made. The taxonomy team and other groups should be clearly identified, with the capabilities of each group described in detail. These roles and responsibilities will ripple throughout the governance plan, giving clear ownership to the taxonomy.

The governance plan should also include clearly written policies and procedures. Any action associated with the taxonomy that may take place should be plotted within this section of the governance plan. Any stakeholder should be able to see the steps it would take to create a new taxonomy node, delete an old one or to edit the name or location of an existing one. Like the taxonomy itself, these procedures should be clear and simple.

Third, supporting the procedures, policies are also required to bound the role and nature of the taxonomy. For instance, rules around simple naming and maximum depth/breadth will help to ensure the business taxonomy does not slide back into something more like an unusable traditional taxonomy or other ponderous structure.

Finally, and perhaps most importantly, the governance plan should have a clearly defined communications plan for the taxonomy. It must be stressed that simply educating the end users is not enough. The communications plan must also include mechanisms to hear from the end users. Feedback mechanisms, including surveys, interviews and passive monitoring, will be critical to ensure the taxonomy continues to evolve over time to better serve the end users. The communications plan should also map back to the policies and procedures section of the governance plan to clearly define the process for collecting and acting upon feedback. This will provide a clear statement that the taxonomy team is committed to making the taxonomy better serve end user needs.

Iterative improvement

With hard work upfront through the workshops and taxonomy team design efforts and the accompaniment of a well-conceived governance plan, the business taxonomy will have the potential to evolve over time to become more intuitive, usable and valuable to each end user.

Business taxonomy design is not a project with a firm start or end date, but a mission that will continue for the life of the taxonomy. Just as your business changes, so will your business taxonomy. If designed and supported effectively, your business taxonomy may evolve to serve those changing business needs and the changing audiences that use them.

Consider a phased deployment strategy

Pilot to learn and reduce risk

Build organisational acceptance;
Ensure executive buy-in with ‘quick wins’;
Apply lessons learned to improve;
Revise & optimise methodology & governance.

Recognise taxonomy evolution

Don’t try to do it all at once;
Recognise short vs. long-term goals; use governance policies to differentiate and prioritise between them

Re-assess governance model at each stage of development

Gradually shift from centralised to more decentralised;
Reassign, distribute responsibilities over time.

About the author

Zach Wahl leads the knowledge management practice at Project Performance Corporation (PPC). He has led a number of major enterprise-information portal deployments for a variety of organisations, including aero-engine maker Pratt & Whitney, Columbia University, the US Department of Defense, the International Monetary Fund and the US Department of Energy.

Wahl has developed his own taxonomy and metadata design methodologies, authored a series of courses on portal knowledge management and development and is an internationally recognised speaker and trainer on the subjects of ‘e-governance’, portals, and taxonomy design. He can be contacted by e-mailing zwahl@ppc.com.

Founded in 1991, PPC is a management and information-technology consulting firm that focuses on simplifying complex problems for top government and Fortune 500 organisations. PPC’s knowledge management practice has helped more than 120 public and private sector organisations successfully implement the full lifecycle of portals and other KM tools. www.ppc.com.