Do you feel like there is a "missing link" in your SharePoint plan?  No, I'm not talking about broken links that occur when you migrate existing pages into SharePoint, I mean something more fundamental.  These days SharePoint deployment and configuration are relatively straight forward.  It still takes a great deal of skill and care so don't get me wrong.  But it isn't something that usually requires extensive planning and innovation anymore.  For most companies and most implementations, there is now a growing body of "best practices" that provide solid guidelines for deployment.

But once it is deployed, what do you actually DO with it?  Most of the SharePoint failures that I'm aware of have been technical successes but business failures.  Somewhere between deployment and successful business use there is a missing link.

The answer is in the creation of a policy taxonomy.  This taxonomy is not an ordered structure of nouns used to classify documents.  Essentially the policy taxonomy is a set of business domains that are used to both organize the site structures within SharePoint, but more importantly serve as a method to organize a governance team to oversee and manage SharePoint use "within the cloud" without crushing it.

Each of the seven-to-ten policy taxonomy buckets has a governance owner who is responsible to act as steward for that section of SharePoint use, its policies, look and feel, growth and structure.  Together the various bucket owners form the business governance team for SharePoint and work together to establish enterprise-wide standards.

So there is probably a missing link hiding somewhere in your executive ranks, but it is easy to fix.  In two days the policy taxonomy can be established, agreed to, governance owners assigned, and a project charter written.

Interested in more information?  Please email me at mark@vitalskill.com and put "workshop" in the subject line.

Thanks!

This is a very good question that pops up frequently during my Governance and Taxonomy Planning Workshops.  If you've read my earlier blog posts you know that I highly admire the Dewey Decimal System as a benchmark in taxonomy planning.  It is:

• Simple -- a grade school child can memorize and understand it.
• Robust -- it provides a framework for virtually all human knowledge.
• Durable -- it has lasted for over 100 years.
• Universal -- it is in use in nearly every library in the world
• Scalable -- it works for libraries of any size
• Deployment Agnostic -- it works in a collection of books as small as a single bookshelf and scales to libraries encompassing multiple buildings.
• Media Agnostic -- it works with books, tapes, disks, parchment...
• Language Agnostic -- it works with any language
• Efficient -- it enables a huge amount of information to be managed by a very small team of specialists
• Self-Governed -- it is governed by the same community that uses it.
• Virtual -- because all the libraries in the world (more or less) use the same logical structure, the entire world is one huge virtual library.  If I look for a book at my local library in Champlin Minnesota and don't find it, magical elves driving an Inter-Library Loan van bring me the book from a participating library.  This means that my local library is actually a portal into the entire world-wide matrix of books available in the Inter-Library Loan System.   This is a miracle of interoperability that has existed for decades.  We in the computer realm only dream of this degree of logical unity.
• Policy-based -- some sections of the taxonomy have special policies that invoked by the type of book identified.  Examples include the reference section (you can't check out the books), the current periodicals (ditto), and any attached historical archives (only open to scholars).

• Extensible -- it has been flexible enough to encompass computer technology, lasers, recombinant DNA and a host of other topics that were not even concepts when it was first introduced, and it didn't break! 

The virtues of the Dewey Decimal System go on ad infinitum.  So why not use it?  To make a long story short, it isn't collaborative.  Go to your local library and start writing in the books if you don't believe me.  Policy taxonomy buckets vary in the degree to which the information remains stable, how the information is interpreted, and how people interact in creating, managing, publishing and interpreting it.

I advocate grouping policy taxonomy "buckets" into one of several types in order to express these differing levels of stability, interpretation and interaction:

1. One-to-one: closed-conversation emails, phone calls, conversations, memos.

2. One-to-many: policies, news items, press releases, newsletters.

3. Many-to-one: reports, surveys, dashboards, KPIs

4. Many-to-many: meetings, SharePoint Team Sites, instant messaging, conference calls

The use and management of ad hoc information in an organization requires all four genres be represented in the collaboration environment, and it also requires that specific rules and guidelines exist as well.  You don't use the same rules of interpretation when evaluating an off-hand remark in a meeting (the economy stinks) as you would in a formal press release ("the CEO of XYZ company says the economy stinks).  One is a formal communication, one-to-many, that speaks with the voice of the organization.  The other is an off-hand and informal remark common to group interaction.

The Dewey Decimal System is a miracle of organization, but sadly it is only designed to work with one-to-many communications.  It is not designed for conversation (shhh!) and if you are smart you will not go to the library and start **CHANGING** books.  It is a repository of one-to-many information.

So you could conceivably organize your document or record management system according to the Dewey Decimal System because these represent static artifacts that speak on behalf of the organization and its processes.

SharePoint is designed to facilitate the use of ad hoc data during daily operations.  It connects people, information and things so that teams of people can self-organize and accomplish their tasks more effectively.

So you need a policy taxonomy that can serve as a schematic for the "big bucket" business policies and processes that govern how your organization operates day-to-day.  Otherwise there is no way to track and manage those processes according to their policies once they are "in the cloud" of virtualized SharePoint sites, libraries and documents.

It is interesting that most of the information available about SharePoint focuses on the nuances of the technology itself.  This isn't all that surprising, I guess.   There is a lot to know and there are many very bright people to help you figure things out.  Don't forget that the point of SharePoint isn't technology, but improved business performance where ad hoc data is concerned.

SharePoint isn't an application in the traditional sense.  It isn't a special-purpose automation tool focused on a particular pattern of business processes.  PeopleSoft is a traditional application.  It has flexibility, but it's purpose is to help your organization organize, integrate and automate a particular set of business processes.  SharePoint is something else entirely.  It is a virtual environment that connects people, information and work areas in order to accomplish ad hoc tasks.  The truly amazing thing is that it does so in a way that enables the knowledge workers to have a great deal of tactical freedom while maintaining a strategic structure and focus to all of their activities.

Installing SharePoint and configuring it is rapidly becoming a "commodity service."  Unless it is a huge or sophisticated implementation, the implementation tends to be pretty straightforward.  The bigger portion of the story is what you do with it once you have it in place.  Your organization has to understand what SharePoint "means" to your culture, your processes and your people.  It is the peopleware and not the hardware or software, that will differentiate vendors moving forward.  Can your implementation and services vendor help you figure out how to successfully leverage and use SharePoint after it is in place?  If not then all they have done is help you install a really expensive "U: Drive."

In order to make the most out of SharePoint you need to not only deploy the technology, but you need to decide how it is to be used in day-to-day operations.  And then, here's the tricky part, you need to figure out how to manage the ad hoc information in the SharePoint environment.  The word "manage" is actually out of vogue in favor of "governance" because the goal is no longer to strictly limit and control the use of information from the "top down."  The goal now is to set up a system in which the users will be able to operate with tactical freedom while being supported and focused by a strategic framework.  This strategic framework is the policy taxonomy that I talk so much about.

The policy taxonomy is not so much about findability, although it helps with that too, but more about managing information "in the cloud"where there no longer is a "top" or a "down."  No policy taxonomy = no governance structure = U Drive.

KEY THOUGHT: Policy taxonomies should ideally be organized into a "process arc" that clearly tells the story of the organization's creation and use of information.

 

Having worked with policy taxonomies and the site structures they create, I've come to the strong opinion that the policy taxonomy should form a "process arc" if at all possible.  Not all organizations are strongly process-centric, so not all policy taxonomies will fit neatly into an arc.  On the other hand, your organization does have a process arc of some kind or it wouldn't be in business.  Find the process arc and align it with your policy taxonomy and you have a winning combination that is both intuitive and effective.

The diagram above shows a fairly typical process arc, in this case for a non-profit organization.  We worked for nearly eight hours to gather a broad range of information, distill it down according to the best practices for policy taxonomies, and then validate it as being robust enough to meet the organization's information management needs.

Then we spent time organizing the taxonomy "buckets" into a process arc.  I can't emphasize enough how important this is for the long-term usefulness of a policy taxonomy.  It takes a static set of policy domains and organizes them to tell a story that describes the operation and purpose of the organization.  It is a lot of fun when some participants see the arc as it evolves and exclaim "so that is what our company does!"

Again, keep in mind that these are not noun-based taxonomies that are common in document management and knowledge management systems.  Those taxonomies still have their place and they are still important.

Here is what the diagram above "says"

1. We begin with our company, its structure, history, departments and organizational information.
2. The company is an organization of people, our customers are ultimately people, as are our partners and competitors.  Information about people tend to have the same metadata structures, constraints, reporting guidelines and other policy structures.
3. The people's activities are constrained and informed by policies (remember this is an NPO)
4. The people's activities are then guided by processes and best practices.
5. The end result is the "value proposition" for the organization, whether it is in the public or private sector.  The value of an organization is almost always defined in terms of goods and services.

All processes produce artifacts or documents that then must be managed.  SharePoint is a great platform for ad hoc and team-based information management for current work-in-progress.  After the process has closed and the product or service is complete, it may be a good idea to archive the process artifacts in a records or document management system and provide interoperability between the two systems.

In addition to blogging, writing and putting on workshops I am a project management contractor and consultant.  Although very strong in the SharePoint project space, I also have a great deal of experience in product development and management, program management, infrastructure projects, outsourcing projects, software development and organizational change.  If you want a reasonably-priced project manager who will understand your business, your leadership, your organizational culture, and your existing infrastructure and processes then I'm your guy.

I am based in the Minneapolis area but do accept contracts throughout the U.S., Canada, and Europe.  Contract arrangements would have to include travel expeneses to return home on the weekends.

My rates are very reasonable.

Here is my resume for your review. Download Mark Schneider Executive Resume 1 97