The Kaboodle Classification Framework (KCF)

I was so tempted to call this work the Kaboodle Framework Classification by some finger-licking organisation got there before me with the TLA, so KCF it is!

I’ve been around this information and knowledge management arena for quite some time now – over 20 years in fact, and I like to think that some of that experience has parked itself as wisdom in some corner of my head.

The Gripes

I see virtually the same set of challenges with nearly every organisation I work with.  You know, the usual stuff:

• Why can’t I find anything?
• How am I supposed to figure out which stuff is still relevant?
• Are you sure this is latest version?
• Are we reading the same document?
• Is this really the position and view of the business?
• It’s changed 3 times since I sent it to you as an email attachment last week!
• It’s in the XYZ folder on the P: drive or maybe it’s also in the ZYX folder in G: drive
• Mmm, I’m not sure I should have the permissions to read this.

All that seems to be different, is the stage at which an organisation is in it’s level of maturity with addressing these challenges.  Some are just at the “Huston we have a problem” stage while other are closer to “The Eagle has landed”.  Although disorganisation it’s not always the case, new startups for example benefit from being unencumbered with the friction associated with 20+ years of unmanaged file shares, by and large the problems are the same and all that seems to be different is the context.

That’s not to say that the solution to addressing these issues will always be the same as each business is unique in terms of how it is organised, what it does and how it conducts itself and its culture.  However, there are enough similarities on the pathway to success such that some of the useful lessons learnt along the way can be applied to improving the situation for businesses struggling with dragging themselves out of the chaos resulting from years of information miss-management!

Adapt or die – you’ve got no other choice

If the list of bullet point presented above resonate with you then I offer you the KCF as a tool in your arsenal (especially if you are using,  or planning to use Microsoft SharePoint) to help put things right.  If none of the list applies to you then you are among the lucky few and I thank you for reading this far and usher you on your way, for you have nothing to learn here.

So, your still with me – good.  As any recovering alcoholic will tell you, the first step to salvation is to admit you have a problem.  That’s actually not so difficult for most organisations, they seem to know when things aren’t right.  More likely, it’s just that I don’t get to meet with them until they recognise that something needs fixing.

The point I am trying to make here is that most businesses live in a world where they need to have systems which must meet a certain level of compliance with regard to their Information Management (IM).  In some cases, failure to comply means revoking of a license to operate.

I have 2 major player customers in the Oil and Gas sector and a new customer who runs an international airport.  For them, failure to comply could mean failure to operate leading to severe loss of income and ultimately business failure.  Or, in the event of catastrophe (loss of life or environmental disaster) if poor IM processes are in any way to blame the business will simply go under and the management team left hanging out to dry!

Even if the business is not highly regulated then good IM is still essential because IM is not really the issue, DM (Decision Making) is the real issue.  Decisions are made by people (your people, call them your team – or anything you like – other than resources, grr).  In fact if you don’t need a person for their decision making abilities then you probably don’t need a person for that job at all – go buy a robot.

The decisions that people take determine whether the business thrives or not.  However, these decisions are based on the knowledge (and experience, which collectively we might call wisdom) available to the decision maker.  Now, stay with me, knowledge is something that for the most part resides in the minds of people – the decision makers, but it doesn’t just magically appear there.  No, knowledge is accumulated by the consumption of information.  And what is information?  Why it’s nothing more than processed data (facts, figures, truths, variables, estimates and guesses) in a context presented in such a way as to convey meaning or intent.  That sounds a lot like a good definition for a document – and so it is.

So the chain of logic goes like this:

• In order to thrive businesses need to make good decisions
• Decisions are made by people (at all levels) in the organisation
• The quality of decision making is based on the knowledge internalised within the decision maker
• Knowledge is internalised by assimilating information
• Information is processed data in a context with the intent of communicating meaning.
• Information resides (for the most part) in documents, either assembled by the organisation itself or received into the organisation from some external source.
• Therefore the quality of knowledge, decision making and ultimately the success of the business is directly dependant on ensuring that people have ready access to information which is timely, trusted and relevant.

So, even in unregulated businesses, if your IM is not right your DM will suffer and you will find yourself out-punched by competitors at every turn.

The bottom line is that unless you are in the position of protected monopoly you have no choice but to ensure your IM systems deliver or you’ll soon go out of business or something worse.  I hope I’ve convinced you.

Not another methodology!

Ok, the world really doesn’t need any more methodologies but I would argue that the KCF is different.  In fact its not really a methodology at all but rather the stitching together of some well known practices and techniques, sprinkled with some best practice guidance based on years of doing this in the real world, with a dash or pragmatism thrown in for good measure.

Also, most methodologies tend to sit in the lofty towers of conceptual world and as such they make no assumptions about the technology or products used to deliver a system.  KCF is different, it has been specifically designed with the capabilities and limitations of a particular product in mind, namely Microsoft SharePoint, including SharePoint Online (SPO) as part of Office 365 (O365).

Some purest will quite right claim that this is arse about face.  First you need to design a conceptual architecture free from real world constraints and then (and only then) go in search of the technology capable of delivering the vision.  That’s great in theory but in practice:

• I have yet to discover a product that can deliver all of the functional requirements and expectations of the business.  So its just a matter of where you are prepared to compromise.
• Many of the customers we deal with are already SharePoint customers and don’t really want to throw away what might be years of investment and start over with something new.

So, whilst the KCF does start out in the conceptual world it progresses all the way through to implementation and beyond.  The power, frustration and limitations of SharePoint are all interwoven with the approach.  I guess it could therefore be argued that the KCF is less useful as generic tool but highly useful for SharePoint projects where document management is important (which is virtually all of them).  That being said, the conceptual half of the framework is technology agnostic and so could be used as the front end for any document or record management project.

One final point, and its an important one, the KCF is not focused on delivery of a technical solution but rather on the delivery of a capability.  Capability is what’s important and there is no point in rolling out a perfect technical solution if nothing has been done to ween users off file shares.  We have a name for those sort of projects, there called white elephants.

The KCF (at last)

Ok, so all that went before was just setting the scene and it would obviously be fool hardy to try and present everything the KCF has to offer in a single article as it would be way to long.  So, with that in mind I wind up this post with a brief summary of what the KCF is all about and support that with a number of separate articles which address each key element of the KCF in turn.

The above diagram seeks to present the essence of the KCF in a single graphic.

The KCF consist of 2 Stages, 4 Phases and 8 Tasks, 4 within each stage.

The 2 Stages

Most methodologies address the project in an abstract way and make no assumptions about the technology used to implement the capability.  The KCF only does this in the first stage, known as the Conceptual Stage.  The 2nd stage, the SharePoint Stage, explicitly names the technology.  I make no apologies for this.  By being targeted, you are free to explore the implementation options available to you.  This means specific elements of the SharePoint platform such as the MMS, Content Types, Document Sets and dozens of other features can all be considered specifically rather than in some hypothetical and abstract way, which only serves to waste time and effort.

At the end of the Conceptual Phase you will know whether SharePoint is the right platform.  If it is, then you can confidently move on the SharePoint Stage.  If the conclusion is that SharePoint is not the right platform, here is where you exit stage right and map the design to some other product stack.

So, here is my logic:

• If the project is known to be a SharePoint project (because the customer has said so) then use the KCF for the complete transformation process, though it is still sensible to conduct a review at the end of the Conceptual Stage to make sure there are no showstoppers.
• If the project is predisposed to SharePoint (maybe they are already using it, or someone high up has used it successfully elsewhere, or they think anything else will be unaffordable) but the business, for whatever reason, is not yet 100% certain that SharePoint is the right technology (often the reasons are political or just that the project team must be seen to be performing due diligence), then follow the KCF to the end of the Conceptual Stage with the view to answering the all important question – is SharePoint the right platform.  Assuming that SharePoint is a goer then move on the SharePoint Stage.
• If the project is not predisposed to SharePoint then I tend to walk away.  SharePoint is what we do at Kaboodle Software and we are proud to be specialists.  If the customer is thinking TRIM (now HP RM), Documentum, OpenText or the like then we’re not the guys to help them and I wish them good luck on their journey.

The 4 Phases

The 4 Phases in the KCF are the project management elements of the approach.  It’s loosely based on structured project management methods, mainly PRINCE2 although the process is much lighter and focused on IT projects that seek to bring about change.

When you break it down it ain’t rocket science.  In fact its incredibly simple, 4 easy to understand dots along the line to improvement – Align, Design, Implement & Sustain (ADIS).

Align

 The Align Phase is about preparation and getting orientated to the challenge. Put simply the Align Phase seeks to establish the “As Is” picture.

Design

The Design Phase is focused on the design and development of a system that will fulfil the customers requirements (although establishing these requirements can sometimes be a challenge). In the Design Phase, the “To Be” vision of the new system will be defined.

Implement

The Implementation Phase centres on how to bring the new capability into operational use and marks the transition from “As I” to “To Be”.

Sustain

The system will need to be monitored and managed so that can evolve to the changing needs of the organisation.  In other words, we need a governance framework.

8 Tasks

The KCF consist of 8 key technical tasks.  There are other supporting tasks of course which are part of the ADIS process but here what I am taking about is about the development of an Information Architecture (IA) that will serve the business well for years, if not decades to come.  So each of the 8 key tasks will result in 8 principal products that are the cornerstones of the IA.  I’ll cover each of these tasks and their resulting products in its own separate article but by way of a quick overview:

In the Conceptual Stage we have:

• Business Classification Scheme (BCS):  The BCS is a functional taxonomy that is used to classify information.
• Document Type Analysis: Review and analysis of the types of information product created and managed by the organisation.
• Metadata Schema: Development of the set of attributes to be used to tag information products so are to aid search and retrieval, lifecycle management (Draft > Release > Archive > Disposal) and the ability to surface information in a context.
• Space Analysis:  The usual start point is to think in 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.

In the SharePoint Stage we have:

• Managed Metadata Service (MMS): SharePoint’s hierarchical taxonomy tagging infrastructure.
• Content Types:  The mechanism that SharePoint uses to provide a context envelope around information products to specify the following key elements:
  • Metadata Profile
  • Information Management Policies
  • Workflows
  • Document Templates (in the case of Document Content Types)
• Site Columns:  The definition of a core set of metadata attributes that can be used to tag information products as part of their associated Content Type.
• Portals and Team Sites:  Construction of web sites, pages, lists and libraries that is going to host the IA.

It is no accident that each key task in the Conceptual Stage maps to a corresponding task in the SharePoint Stage.  That’s entirely by design and the astute observers amongst you will have noticed that they are the same colour in the overarching KCF diagram.

Once again the idea here is simple.  Develop key elements of the IA conceptually and then map that to the capabilities in the technology (SharePoint).

Summary

Having worked with SharePoint for getting on 2 decades now (yes I was around in the days of Site Server and Tahoe Server, which laid the foundation for SharePoint Team Sites and SP2001 respectively) with a myriad of customers all around the world, you get to understand that nothing is new under the sun and that organisations everywhere struggle with the same challenges and issues.

This experience has helped me to uncover patterns which I have now decided to formalise into a framework which I call the KCF.  I guess you could say that it amounts to a best practice guide for implementation of document-centric SharePoint projects.  I’m sure that the KCF doesn’t cover all the bases and whether you agree with me that it is a best practices guide is a mute point.  Why, because I know that it works and I know that customers get it.

In the coming weeks I will be releasing more of the KCF and I am more than happy to receive feedback (good or bad – so long as it is constructive).