NOTE THAT ALTHOUGH I AM ENTHUSIASTICALLY PART OF THE FAIRVIEW HEALTHCARE ORGANIZATION, I DO NOT SPEAK FOR FAIRVIEW HEALTHCARE.  THESE ARE MY PERSONAL OBSERVATIONS AS I SEEK TO HELP FAIRVIEW ACCOMPLISH ITS CORPORATE GOALS.

Nearly a year has gone by since I accepted the honor of being the IT Director for the Project Management Office at Fairview Healthcare in Minneapolis Minnesota.  My goal is to make appropriate care available to everyone in the great State of Minnesota regardless of location or other demographic factors.  My interest is entirely apolitical in that I intend there to be no technical or logistical reason why folks can't receive healthcare.  Policy and law are another issue entirely.

Fairview, a "not for profit" organization is perfectly positioned to deliver in line with my dream.  Fairview doesn't just want to do a good job in delivering healthcare, Fairview wants to change the world of healtchare for the common person.

So, being fairly thorough, I am one of the few people on the planet who has read HR 3200 front to back including all the changes.  Good laws provide general strategic guidelines while allowing for great tactical flexibility, in my opinion.  As such I find HR 3200 to be actionable from an information management perspective and useful in organizing healthcare efforts.  All the political issues and nuances I leave to your interpretation.

Having said that, my focus is not on taxes or finances but on creating an informational infrastructure that will facilitate Fairvew Healthcare's evolution into an "Accountable Care Organization."  Whether the law endures or not, we want to be transparent, agile, effective, focused, and driven by measurable results.  We want to treat patients through their lifespan and not episodically as their health fails.  We want to form, essentially, health care project teams that work in concert with the customer to help them leverage our skills and capabilities in managing their own health future.

Toward that end I have developed a SharePoint Informational Policy Taxonomy that is intended to describe the process-arc of an Accountable Care Organization.  We are "not for profit," so we encourage you to use this if you choose to do so.

Here is the informational taxonomy I'm deploying as a foundation for our SharePoint 2010 deployment.  Even though employed, I am still free to consult so let mek now if I can help you.

 

 

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.