Keep in mind that any organization has a number of taxonomies, not just one. There are taxonomies for roles and titles, physical locations, product ordering schemas, manufacturing bills of materials, and so on. When they function properly, these taxonomies provide a method for keeping information straight and seeing how things interact during the course of business operations. These taxonomies are usually independent of each other until the corporate culture determines how they fit together and what priority each has.
Increasingly one hears anecdotes and stories about SharePoint implementations that went well for three-to-six months but then stopped working properly. Upon review it is usually found that a few fundamental mistakes were made on deployment that led to failure, and that the only remedy is to essentially decommission the existing deployment and redeploy the way things "should have been done" in the first place. Every failure story I've ever heard in relation to SharePoint had nothing to do with the technology itself. Rather it had to do with a lack of homework and planning up front by the leadership in the organization. It wasn't even a failure by IT in most cases, but a fundamental mis-understanding and erroneous expectations on the part of the senior leadership team. My workshops are intended to correct this fundamental misunderstanding by putting business and technology leadership on the same page (and in the same room for two day).
Before you can begin designing your role, site, navigation, and document taxonomies you need to establish your "Top-Level" taxonomy as the overall organizing principle for information storage and management. This is one of many terms I've coined in an effort to communicate new ideas to new audiences, but what kind of taxonomy is this? What I've been calling a top-level taxonomy is actually a "POLICY TAXONOMY" and not a document taxonomy. It has to do with groups of corporate policies and the documents associated with them. So, step one is to create a clear taxonomy of corporate policies that will govern the supporting polices and best practices that bring order to the SharePoint environment.
This POLICY TAXONOMY absolutely CAN'T be created or maintained by IT. It is a whole-business taxonomy that organizes how everyone thinks about the information being managed. Everything from roles to approval workflows find their foundation in the POLICY TAXONOMY.
So the POLICY TAXONOMY must be created and maintained by a small Governance Board composed of policy-setters from various stakeholder organizations across the organization. This is why my Governance and Taxonomy Workshop can be so valuable. We get the policy-setters or their designates together and arrive at a POLICY TAXONOMY that enables everyone to understand the key management issues involved in keeping up and maintaining the information within a SharePoint environment.
The POLICY TAXONOMY also provides a test case for the Governance Board to use in learning how to function together in guiding business policies that govern information contained within SharePoint.
© 2008, Mark Ragar Schneider, All Rights Reserved
Comments