Cereal in the saucepan
As I mentioned in the last post, Irrelevant Taxonomies, I want to spend a few cycles digging in to my approach to taxonomy, both to contrast it with how I see taxonomy typically done as well as to solicit feedback, comments, and general heckling from you all out there–nothing like industry scorn to sharpen your ideas, right?
I thought I’d begin by explaining more about each of the dichotomies I introduced in the last post.
Today, let’s look at the first one: focus on the documents being stored versus focus on the process that work with the documents being stored.
Contrary to popular belief, a taxonomy project for document management shouldn’t primarily be concerned with documents, but with how folks use those documents. And I would even go a step further and say that no taxonomy project–if it wants to be successful–should be concerned with the things being organized but rather with how folks will use them. I can think of one exception, but let’s get to that later. Let’s start with the rule that proves the exception.
Boxes and arrows, Crate and Barrel
One of the most ubiquitous, every-day taxonomies in the Western world is the kitchen. Silverware, dishes, glasses, pots and pans, appliances, dry goods, perishable foods, table linens, chachkes–you’ve got a great mix of objects and a range of activities they support in the lifecycle of the household and its occupants.
To build an effective taxonomy for your kitchen and store all these objects, you need to weigh two considerations: how you’re going to use each object and the space available to you. And you need to weigh them in that order, otherwise your kitchen will be less-than-usable. Here’s why.
If we wanted to organize our kitchen to maximize space, we would never do things like store empty pots and pans or glasses in one place and disposable boxes of dry goods in another…we’d dump the dry goods into those empty pots, pans, and glasses and toss the disposable boxes they came in–et voila: maximized space!
Cooking, however, would pose a bit of a challenge if we used this principle to organize our kitchens. Which is why we don’t.
Instead, all of us organize our kitchens to make it easier to do what we do in kitchens: cook, clean, and eat. We leave pots and glasses empty because we need to fill them with food and liquids while cooking and eating; we put some utensils right by the stove rather than in the drawer because we need them to cook; others can remain in the drawer because we need them to prep food on the counter; some glasses are stored above the dishwasher because we use them all the time (and are therefore washing them and putting them away all the time); others are used on special occasions (or are only hand washed) and can live elsewhere. And so on.
The same is true for the documents we want to organize as part of our taxonomy projects: the goal of organization is to make them easier to have on hand when and where folks need them.
To do this, you need to understand the business processes that use these documents, so that you can build a taxonomy that supports those processes. By doing so, you will naturally organize the documents in a way that makes them easier to have on hand when and where folks need them. What you do not do under any circumstances (except maybe if the main goal of the taxonomy project is to maximize space in a physical facility) is to start from a list of all documents in use and build a taxonomy that organizes all of them–a recipe (groan) for disaster.
The final word
With the issue of document-focus versus process-focus out of the way, in the next post we’ll move to the issue of taxonomy scope, i.e., striving to be comprehensive versus striving to be targeted. In the meantime, if folks have thoughts, bones to pick, or comments, jump in–let’s get the conversation started!
I love it! “Instead, all of us organize our kitchens to make it easier to do what we do in kitchens: cook, clean, and eat.”.
I have seen the equivalent with very low-tech filing of business documents. Sometimes the process allow a better filing structure to be identified. Other times, looking at the structure of information gives you an idea about the processes behind the scenes. I know that filing documents and detailed taxonomies for classification aren’t necessarily synonymous, but they certainly overlap. I blogged about this here: http://blog.consected.com/2010/06/avoiding-rat-holes-by-working-backwards.html
Either way, a taxonomy of information definitely needs to pay attention to the dynamics of what creates information in it. In my filing system example, modeling business functions in a record-plan does this, rather than the pots and pan approach of just looking at the departments that produce the records.
Nice post!
Phil,
First, thanks for the kind words–glad you enjoyed the post and found it useful.
Second, thanks for sharing your own work here. I loved the post: not only the great advice it had for practitioners, but also the compelling narrative of working with that particular client.
Looking forward to making your blog a regular read and would love to have you weigh in here more–so come back often!
Cheers,
Joe
Joe,
Its a pleasure. I’m pleased you found my blog interesting too. I think there is a big overlap in what we discuss.
Cheers,
Phil
Nice post Joe, looking forward to the rest
Taxonomies should be about semantics, not syntax. A dictionary is a nice example of a form of semantics: lots of words to explain a single one
Taxonomies are the opposite of that: extremely long (usually XML / XBRL) tags describing one single word: they don’t even define themselves, let along their context and their neighbouring friends
You can always tell how a taxonomy is going to fail: when it’s the guys from IT (mostly) doing it – whereas there should be a 10-1 business-IT ratio for a successful taxonomy
While I agree with the “use” argument of the article, @Martijn, good luck on finding 9 relevant, able-thinking business types working for same company! The issue I take with the 10:1 comment is that, as I’ve found across three different businesses now, the business “wants” a useful taxonomy but is inadequately able to define it — leading to I/T being asked to define it so it can be critiqued as a failure! (tongue-in-cheek).
The base problem I’ve seen is that the use of the taxonomy is spread across different user types, each with its own definition of how documents should/could be used. This, in my opinion, leads to the need for multiple taxonomies across user needs. One quick (easy) example, referring to the kitchen example from the author … suppose all your family members are right-handed. They’d likely place the stove-top utensils in the drawer to the RIGHT of the stove, while if all were left handed they’d place it on the other side. The author argues for “where” things are stored based on usefulness to the user and knowing the users themselves should lead to the taxonomy (multiple, in my opinion) necessary for success. There are always a minimum of two user types for a business taxonomy — the users and those paying for it to be created (think c-level). Reporting is “easiest” when configured in a way that relays the “best” information for the cheapest cost to the first customer (c-level). I believe that I/T will most usually pursue the easiest way to meet the need (time, storage, performance, etc.) while not necessarily working to ensure the user is the #1 focus … and to that extent, I agree that business involvement is a highly desired companion IF they are truly user-focused.
Adrian,
It’s true (but sad) that it’s often difficult to find relevant, able-thinking types at the same company to work on the taxonomy, but I think just as often we don’t find these folks because we haven’t articulated our project and its goals in a way that communicates effectively what we’re doing.
The result is that the project comes across as either (i) inscrutable or (ii) scrutable, but as an IT science project–in both cases, the relevant, able-thinking types don’t even bother getting involved.
One of the first things I do on a taxonomy project is help the team articulate the goals and methods in a way that speaks to our customers and stakeholders, from the folks who we need to work alongside, to the folks who simply need to be informed of the project, to those who ultimately cut the check for it (CXOs).
I find that getting this part right makes the rest of it go much more smoothly and brings the relevant, able-thinking business folks out of the woodwork.
It makes me think of that famous saying from Mark Twain: “At 18, I thought my father was an idiot; at 21 I was amazed how much he had learned in 3 years.”
Anyway, thanks for taking the time to jump in with such a thoughtful, comprehensive contribution–I appreciate it!
Cheers,
Joe
Martijn,
Thanks for the comments and the kind words–hope you enjoy the rest of the series!
Cheers,
Joe
Excellent analogy Joe…