I like to place the fact base right up front:
Like most info-mavens I live part-time in the practical world and the other half in my theoretical head. The mental benefit of getting paid for what comes naturally is that I get to put my theories to the test every day.
Five days a week (give or take an at-home office email marathon) I labor in the circles of a system that tests some assumptions I hold about people find, store, and most importantly act on the lessons they draw from the information in there. This learning is not the 9-5 reality of some firewalled online university. It's not garden variety intranets for dummy corporations.
It's not even the harbor of last refuge for sleep-deprived, travel-logged thought leaders and efficiency experts. For them it's about their piecing together where they need to be to cinch a deal, eliminate a problem, maybe buy an argument, dispel a doubt, or even rationalize away the reasons for taking no action.
I'm guessing that at least half their education is about confirming what they already know or apprising them of what others experience. Either way at its roots the most expansive online search expedition is really about reduction. Best case it's about making problems disappear. Worst case it's unpacking those issues into manageable chunks. Either way it's setting an expectation to follow (and perhaps lead by).
For them it's not about a system or a document or a tag or a search option. It's not about the pissing contest that ensues whenever an esprit of egos clash on what to call something. If there is any awareness of my system that's a negative:
"I can't get on KM."
"I can't find XX document from YY project."
Any obstacle between the system user and their reason for learning is at the to-do list of any knowledge planner. Now it's not just the problem our users are addressing. The problem becomes the system itself. This is by far the less welcome of the two problems. It was not invited. There's a reason that "crashing" applies to system failures and uninvited guests.
We've invited the reason for using the system. Now where to seat the system error? To my mind and experience the best way to eliminate this obstacle is to stop treating the system as an "it" and more as a process. It is not a destination but a journey. Learning is not a noun. It is a verb.
The way we've tried to achieve this is presented in the following reference model that I call Search Yield Network Contribute (S-Y-N-C). This addresses information as a process by which we can anticipate the supply and demand patterns reflected in the system's provision and usage. Any planner worth their supply chain, trading, or econometric mettle can tease the numbers from the cyclical interplays of these better-known systems we dance with every day as investors, producers, and consumers. SYNC appropriates that thinking to the interdependencies of intranet travel where the rule of all roads lead to the same dead-end:
Supply = Content Surplus
Demand = Knowledge Deficit
How do we close that gap? Some overlooked SharePoint feature? Gift cards? New, improved nomenclature? Triple nada.
Nothing gums up the works more than a dump yard of bloated ZIP folders. Nothing focuses an intranet faster than how people spend their information surplus once they can process how past outputs connect to their next steps.
Information by itself hangs itself. What folks do with it is intrinsically fascinating. That's both the motivation and method behind S-Y-N-C.
Treating information as a verb and not a noun clarifies what our users are looking for (the "S" or Search cycle of S-Y-N-C) and what they intend to do with it (the "Y" or yield in defining the usage patterns or outcomes fueled by those search results. On the supply side again it's action predicates, not subject nouns that inform the build efforts of knowledge planners. We've reduced the description of our corpus from thousands of unwinnable arguments about what our content is into three potential use cases:
* Learn
* Sell
* Do
Nothing clarifies a taxonomy like appending an a verb to a thing. This is foundational not only to the network architecture ("N" in S-Y-N-C) but to where and how your information suppliers contribute their IP (locking up the "C" in S-Y-N-C). Here the factor of storage location is key to honoring a second success factor of the reference model -- that users on the demand side should focus on usefulness to the exclusion of all supply side distractions -- particularly storage location. This notion of location neutrality can only work on the demand side if our information suppliers honor the location sensitivities of our governance structure. Location -- it should mean everything to suppliers and absolutely nothing to users.
Here's what I mean: say I need the latest, greatest outputs about some long-established frameworks that were recently retooled to meet the exacting and unique requirements of a new and potentially lucrative client? If the IP is in its place I can filter the supply by my demand criteria -- what other clients have we done this for, who did the work and when, and how was it presented in the context of those projects?
If supply is in S-Y-N-C with demand then I Joe User should not have to enter a single keyword or mind-reading mantra about what my intentions are with the work in question.
More on the clarifying power of verbs in a future post.
Like most info-mavens I live part-time in the practical world and the other half in my theoretical head. The mental benefit of getting paid for what comes naturally is that I get to put my theories to the test every day.
Five days a week (give or take an at-home office email marathon) I labor in the circles of a system that tests some assumptions I hold about people find, store, and most importantly act on the lessons they draw from the information in there. This learning is not the 9-5 reality of some firewalled online university. It's not garden variety intranets for dummy corporations.
It's not even the harbor of last refuge for sleep-deprived, travel-logged thought leaders and efficiency experts. For them it's about their piecing together where they need to be to cinch a deal, eliminate a problem, maybe buy an argument, dispel a doubt, or even rationalize away the reasons for taking no action.
I'm guessing that at least half their education is about confirming what they already know or apprising them of what others experience. Either way at its roots the most expansive online search expedition is really about reduction. Best case it's about making problems disappear. Worst case it's unpacking those issues into manageable chunks. Either way it's setting an expectation to follow (and perhaps lead by).
For them it's not about a system or a document or a tag or a search option. It's not about the pissing contest that ensues whenever an esprit of egos clash on what to call something. If there is any awareness of my system that's a negative:
"I can't get on KM."
"I can't find XX document from YY project."
Any obstacle between the system user and their reason for learning is at the to-do list of any knowledge planner. Now it's not just the problem our users are addressing. The problem becomes the system itself. This is by far the less welcome of the two problems. It was not invited. There's a reason that "crashing" applies to system failures and uninvited guests.
We've invited the reason for using the system. Now where to seat the system error? To my mind and experience the best way to eliminate this obstacle is to stop treating the system as an "it" and more as a process. It is not a destination but a journey. Learning is not a noun. It is a verb.
The way we've tried to achieve this is presented in the following reference model that I call Search Yield Network Contribute (S-Y-N-C). This addresses information as a process by which we can anticipate the supply and demand patterns reflected in the system's provision and usage. Any planner worth their supply chain, trading, or econometric mettle can tease the numbers from the cyclical interplays of these better-known systems we dance with every day as investors, producers, and consumers. SYNC appropriates that thinking to the interdependencies of intranet travel where the rule of all roads lead to the same dead-end:
Supply = Content Surplus
Demand = Knowledge Deficit
How do we close that gap? Some overlooked SharePoint feature? Gift cards? New, improved nomenclature? Triple nada.
Nothing gums up the works more than a dump yard of bloated ZIP folders. Nothing focuses an intranet faster than how people spend their information surplus once they can process how past outputs connect to their next steps.
Information by itself hangs itself. What folks do with it is intrinsically fascinating. That's both the motivation and method behind S-Y-N-C.
Treating information as a verb and not a noun clarifies what our users are looking for (the "S" or Search cycle of S-Y-N-C) and what they intend to do with it (the "Y" or yield in defining the usage patterns or outcomes fueled by those search results. On the supply side again it's action predicates, not subject nouns that inform the build efforts of knowledge planners. We've reduced the description of our corpus from thousands of unwinnable arguments about what our content is into three potential use cases:
* Learn
* Sell
* Do
Nothing clarifies a taxonomy like appending an a verb to a thing. This is foundational not only to the network architecture ("N" in S-Y-N-C) but to where and how your information suppliers contribute their IP (locking up the "C" in S-Y-N-C). Here the factor of storage location is key to honoring a second success factor of the reference model -- that users on the demand side should focus on usefulness to the exclusion of all supply side distractions -- particularly storage location. This notion of location neutrality can only work on the demand side if our information suppliers honor the location sensitivities of our governance structure. Location -- it should mean everything to suppliers and absolutely nothing to users.
Here's what I mean: say I need the latest, greatest outputs about some long-established frameworks that were recently retooled to meet the exacting and unique requirements of a new and potentially lucrative client? If the IP is in its place I can filter the supply by my demand criteria -- what other clients have we done this for, who did the work and when, and how was it presented in the context of those projects?
If supply is in S-Y-N-C with demand then I Joe User should not have to enter a single keyword or mind-reading mantra about what my intentions are with the work in question.
More on the clarifying power of verbs in a future post.
No comments:
Post a Comment