Kaboodle Classification Framework (KCF): Conceptual View

In my previous post I provided an overview of the Kaboodle Classification Framework (KCF), which is the approach we use with our customers for the implementation of SharePoint projects.

Most of these engagements are not green fields, they are with customers who have been using SharePoint for quite sometime but who struggle to get the best from their investment or (more usually) they have not implemented it in a way that meets their expectations.

So we are, for the most part, called in as architects, town planners and builders to help customers turn these ugly brown fields in to gleaming citadels!  To do that we have constructed the KCF methodology that is built on years of practical lessons of doing this with real customers, so we know that it works.

In the introductory article I stressed that where most methodologies live in an abstract world where they make no assumptions about specific technologies and products, this is only partially true of the KCF.  The first part is indeed conceptual but then it becomes totally pragmatic and product focused – focused on SharePoint.

This article introduces the Conceptual View of the KCF.  Later on we’ll come back to how this is translated into the technology.

The KCF is really a change management method and the focus is not on rolling out a system but rather on brining capability improvements to an organisation.  This means that a holistic approach is required, one which addresses People, Processes and Technology.  If you focus on the technology alone then you are destined to fail.  I’ll come back to this again in more detail when I talk about the project management part of the KCF (the Align> Design> Implement> Sustain (ADIS)).

That being said, you have got to come up with a plan for how things should be and by that I mean the Information Architecture (IA).  The IA is nothing more than a plan for how information is to be organised and accessed but some up front planning and thinking will make things so much easier down the line.  In fact, this is where most organisations have struggled.  They have simply rolled out SharePoint without thinking through how it should be used.  In other words, it has never been properly aligned to the business.  And that alignment to the business is what the KCF is all about.

The Conceptual Stage consist of 4 principal tasks that provide the ground work for the implementation of a successful IA.  There are heaps more tasks in ADIS but here I am talking about getting the IA right.

I will write up how to execute each of the 4 principal tasks in their own separate article and so  I’ll finish this post off with just a summary overview of these tasks

Business Classification Scheme (BCS)

The BCS is a functional taxonomy that is used to classify information.  Record Managers all know about the BCS as this is what they need to define suitable retention policies.  However, don’t be fooled into thinking that a BCS is not required because you aren’t doing formal Records Management (RM).  You may not be using SharePoint for RM but that doesn’t mean you don’t need a BCS.

Document Type Analysis

Organisations are both consumers and producers of documents.  Documents that originate from an external source can be treated differently from documents created by the organisation as there is no need to track things such as approval routing and release.

Those which are created by the organisation can generally be classified into 3 groups:

• Managed Documents:  Those documents which must be subject to strict governance such as Policies and Procedures.
• Administrative Documents:  Those documents which are regularly generated by the organisation when conducting routine business such as correspondence (including email).
• Transactional Documents:  Those documents generated to initiate, or as a product resulting from, the execution of business processes.  Think travel forms and purchase orders.

It’s not unusual for an organisation to have dozens of Document Types, even as many as a hundred or more.  Every type of document that is created or managed by the organisation must reside somewhere in the BCS.

Metadata Schema

The Metadata Schema is the development of the set of attributes to be used to tag information products so as to aid search and retrieval, lifecycle management (Draft > Release > Archive > Disposal) and the ability to surface information in a context.

The item in the Metadata Schema should include at least the following:

• Name:  The name of the metadata attribute
• Description:  A short description of the purpose of the metadata item.
• Type:  The type characteristics of the metadata e.g. text, date, link, person etc.
• Constraints:  Constraints might be in the range of values that can be applied or their uniqueness.
• Optionality:  Whether a value is mandatory or optional.
• Format:  The way that metadata values are presented to users in the UI e.g. a number value could be presented as an integer, a percentage or as a currency value.
• Default:  What value (if any) that should be assigned to the metadata attribute unless overridden by a user.

The Metadata Schema must support the implementation of the BCS and then a metadata profile needs to be constructed for every type of document revealed in the Document Type Analysis.

Space Analysis

The Space Analysis task is about deciding what goes where.  The usual start point is to think about spaces which follow the standard Document Lifecycle.  That is to say a document gets drafted and then released and then finally archived when they are no longer relevant to current operations.

This means that we need to think of at least 3 spaces, namely:

• Production:  Where new information gets created or existing information gets reviewed and updated.
• Consumption:  Where formally released, authoritative information is accessed by the people who need it to do their job.
• Archive:  Where obsolete information gets sent before it is disposed.

It is possible to think of these 3 spaces as being virtual or physical.  A virtual space might have just one physical container (a big bucket) but logically separate documents according to a status value (Draft, Released, Archived).  This has the advantage that once a document has been created it never moves from its physical location, instead it transitions through the Document Lifecycle by a change in its status value.

Alternatively, and the approach advocated the KCF, we build 3 physical spaces one for each phase of the document lifecycle.  This may seem sub-optimal as we need to physically relocate documents as they transition through their lifecycle but there are a number of pragmatic reasons (which I won’t go into here) as to why this is the preferred approach.

Summary

In summary, the Conceptual Stage of the KCF is (like nearly all methodologies) abstract and makes no assumptions about the implementing technology.  Applying this conceptual work to SharePoint is the next Stage in the process.

There are 4 key tasks in the Conceptual Stage:

• Business Classification Scheme
• Document Type Analysis
• Metadata Schema
• Space Analysis

The next 4 posts on the KCF will look more closely at each of these in turn.