Taxonomy is a Sleeper.
I’m a taxonomy practitioner at Fishbowl Solutions who has worked with many companies to implement simple to sophisticated document management systems. I’ve noticed over the years the large number of obstacles that have prevented companies from establishing taxonomy frameworks to support effective document management. I won’t review an exhaustive alphabetic list of obstacles, in fact, there are probably far more than 26, but I’ll highlight the top culprits that have turned even the best, most sophisticated companies away from taxonomy. Don’t fall asleep. Don’t hit snooze. Make sure you don’t miss one of the most important parts of a document management software project–taxonomy. Taxonomy is a necessity to deliver effective document management solutions in Oracle WebCenter Content, SharePoint, or any other enterprise content management solution. You’ll get the most out of the software and your users.
Authority. Who owns taxonomy? Does IT own the taxonomy or a Quality Management Department or all departments own a piece? Determining decision-makers and authority to sign off on taxonomy frameworks can be difficult. After all, taxonomies are best when they are enterprise-wide solutions. Then, users have a familiar context when working with documents for all business purposes. Don’t let challenges with authority prevent you from establishing taxonomy for your project. Plan on establishing a governance team to own the taxonomy practice for the current project and in the future.
Bright. Shiny. Object. Taxonomy is not a bright shiny object. It’s not as fancy as the user interface of the new software. It doesn’t have the “bells and whistles” that hardware and devices have either. So, too often document management projects end up focusing on the software and not the necessary taxonomy that makes that software a rock star. Don’t be blinded. If you want users to have a great experience, work with documents effectively, and generally adopt your new document management software, you must ensure you define a taxonomy. Otherwise, your bright shiny object may easily be replaced by the next one as it loses appeal.
Complicated. I often hear from customers that a business taxonomy is complicated. It can seem insurmountable to sift through existing taxonomy frameworks (or identify new ones), synthesize frameworks, identify new requirements, and really come up with something comprehensive. Regardless, it’s necessary. If a taxonomy effort is complicated, think of how complicated managing and searching documents is for your users. Help your users by including taxonomy in your next project to simplify their experience. It’s the foundation for browsing, searching, contribution, workflows, interface design, and more.
Glamour. Unfortunately, taxonomy is not glamorous. It’s hard, investigative work. It entails identifying stakeholders; meeting with stakeholders to really understand documentation, process, and users; generating consensus; and documenting, documenting, documenting. On top of that, it’s invisible. Users often don’t even notice taxonomies, especially if they’re good. But if a taxonomy is non-existent or poorly designed, your users will notice the taxonomy for all the wrong reasons—unintuitive naming, missing categories, illogical hierarchies, and more. Even though taxonomy is not glamorous, it demands an investment to ensure your project is successful, at launch and thereafter.
Time. It’s common to hear in projects that there is just not enough time. Customers may say “We need to complete X with the project by date Y.” Or, “The management team really needs to see something.” Frequently, the most important milestones for projects are software-related, causing taxonomy to lose focus. The good thing about taxonomy is that projects can work concurrently on the software build out as they work on taxonomy frameworks. You can do both and do them well. Resist the urge to scope out taxonomy in your next project and consider creative ways to plan in taxonomy.
What? Yes, taxonomy has been around for a long time, but still often in projects I see that it’s just something that people are not aware of. It’s existed for years in the biological and library sciences fields and has had application in IT and many other fields, but often it is just not understood for document management projects. If you’re not familiar with taxonomy, see my previous blog post “Taxonomy isn’t just for frogs anymore.” and consider hiring a reputable company that can guide you through the practice for your next project.
ZZZs. It’s often perceived as a boring practice with tasks that are in the weeds, but some of us do love it. Actually, we even find it rewarding to solve the puzzle of the perfect categorization that works for the project and the customer. If you’re new to taxonomy, you may find that you like it too. If not, find a resource for your project who has a passion for taxonomy because a good taxonomy is so important to successful document management projects.
It’s time to have your eyes wide open. If you’re considering a document management software or improvement project, consider how important the underlying taxonomy is for your project and plan taxonomy analysis and development as a required effort. Your users will appreciate it and your business will see increased software utilization. Remember the old adage, “Technology cannot solve your business problems?” It can’t. But technology + taxonomy can.
This blog is one in a series discussing taxonomy topics. Watch for the next blog coming soon.
