Irrelevant taxonomies

I’ve been working on a number of taxonomy projects lately and each one has reminded me both how relevant and how irrelevant to the business a taxonomy project can be depending on how it’s done.

Now before I get too far ahead of myself, I’ll start by acknowledging that taxonomy projects can have a wide range of goals, from optimizing file plans to branding and corporate strategy. So let me level set here by saying that this post (and any follow ons) will be concerned with a narrow slice of that range: taxonomy projects for document management.

But despite this narrower focus, I hope that the subject will have wide applicability, because document management is one of the most ubiquitous use cases for taxonomy (alongside areas like website design and user experience).

Irrelevant taxonomies

With that out of the way, I wanted to start with what I consider the fundamental differences between relevant and irrelevant taxonomy projects for document management, because if you don’t get this right, no amount of quality work or best practices later will make the project valuable to the organization.

You’ll notice right away that the first three of these are specific to taxonomy, but that the last two could be said of any relevant/irrelevant project.

You also may notice (particularly if you’ve had any experience with doing taxonomy work for document management) that devaluing things like comprehensiveness, application neutrality, and a document focus seem to run counter to approaches to taxonomy you may have been exposed to.

The wrong approach

And if you have, you’ve encountered more of a library science approach to taxonomy. And I intentionally left library science lower case because I don’t mean here to devalue the discipline of Library Science, but rather an approach to taxonomy that takes some of the tools of Library Science and applies them inappropriately in a business context.

The results of such an approach include things like:

• A formally consistent taxonomy that no one adopts
• A seemingly unending process of classifying documents across the enterprise
• Difficulty implementing the taxonomy in a system or application

And I’d be willing to bet you twenty dollars that if you’ve taken part in a taxonomy project for document management, you’ve experienced at least one of these, because far more of these projects are undertaken from the library science approach than not.

To be fair, these results are not solely due to the flawed approach I’m describing here. Even a taxonomy project that takes a more business-centric approach can suffer from these problems—I’ve personally worked on examples of them—things like not having clear goals for the project or not having a specific document management application in mind for the taxonomy can lead to these problems as well.

But you at least have a shot of overcoming these problems if you approach your document management taxonomy from the right perspective: if you take the library science approach I’m describing here, you have virtually no chance of doing so.

The final word

I know I’ve definitely ruffled some feathers with this post, because as academic and technical as taxonomy can be, it also inspires passionate opinions and beliefs among practitioners. If that’s you, throw off the gloves and jump in—let’s get a good debate about this going.

If you’ve been involved in successful, more library science taxonomy projects, tell us about it, and let’s all think out loud about how to modify my success criteria to account for it. Or if you see problems in my analysis, tell me, and let’s get a back and forth going about the strengths and weakness of my approach.

In the meantime, I’m going to sharpen up my pencil to dig into taxonomy for document management a little more by planning out a series of posts to articulate my approach in more detail. And if folks out there have ideas or suggestions for posting topics in this space, let me know, and I’ll try to address them.