KM in the Jerkplace: Episode Two -- Knowledge Engineering for Solitary Scrum Masters

(c) http://3.bp.blogspot.com/

Installment Summary: The Big Four knowledge survivalist jumps into the awaiting arms of the engineering camp for a once mighty developer of media software – back when hardware mattered. At first the opportunity is virgin territory. This inviting place to plant the knowledge flag is signified by efforts to source and build a search capability for leveraging the company’s collective assets. The initial optimism is however tempered by factional infighting and an unwillingness to fly those engineering colors under the SAME flag.

The Factory Gates Open for Knowledge Engineering

A week before I was to ship out as a SharePoint business ninja within IT, I hitched onto a passing knowledge raft. This water-logged trial balloon was powered by the knowledge-seeking curiosities of the engineering arm of Keen Core Technology – arms dealer to Hollywood, TV, and recording industries, and now under siege by an unceasing array of disruptor insurgencies from all sides of the media production spectrum.

While I had worked along-side IT and engineers with MBAs (a.k.a. “management consultants”) I had never been subsumed into the belly of the engine room: that is IT itself. I learned software-making as a repeatable cycle in need of documentation as-in coding the coders. I learned about daily stand-ups as the perfect antidote for task-drenched programmers who would rather be writing code than getting sucked into meetings.

My mission at Keen Core was to classify the wikis, channel the documentation stream, and socialize the release cycle of the half-dozen or so product development teams. Ultimately this meant distilling all these outputs into a single automated helping of digestible knowledge called “search.” The fact that there was no enterprise-wide answer to the perennial how-do-we-know-what-we-know question meant two things to the engineering crew of Keen Core:

1. Conceptual – how do we boil this ocean of applications, file-shares, lapsed repositories, and group-based collaborations from Outlook to Google Docs?
2. Practical – once boiled, how do we care and feed this resource so we can retreat to our safety zones in the comfort of knowing we can test our forward-leaning hunches against our collective history?

The Knowledge Safety Net

From a theoretical perspective the wish list that brought me to Keen Core began and ended with the same staggering and sober realization: we can scale the production of code but we don’t have a clue how to trap, catalog, and ultimately leverage the by-products of that effort.

This overwhelming sense of an organization’s inability to get out of its own way is not well-served by a top-down inventory of all assets – whether they live in the U.S. Patent Office or under “the digital landfill” as AIIM's John Mancini would say.  Rather than over-analyze the backlog of dumpster-grade documents, we looked to establish the safety net – not the uber knowledge archive.

There was nothing random to this sampling. Domain experts come out of the wood work – reluctantly sometimes because they’re often “heads down” …

• On some failure-is-not-an-option mission, or
• Closing in on some new shortcut to faster, better, cheaper.

These are not the sycophants of social media in search of the likability badging trophy. 

These are the folks who build stuff. They might not communicate effectively and their managerial skills lapsed long ago – if they ever had them. They are socially speaking apolitical, meaning they are drawn to fixing problems, not towards handling them. They are by-and-large drawn from the ranks of engineering and they are my brilliant, argumentative, recalcitrant, misunderstood people.

These are the ones who emerge when the call goes out for who-knows-how-stuff-works. And like their own circles, the documentation they travel in lands off the documentation radar. It lives on the outskirts of any centralized repository that confers authority, explains connections, or unpacks the experience that inspired it. In the case of the Keen Core safety net it was little more than providing a link to an obscure server I might or might not find password accessible. But after a series of non-threatening prods I had my unofficial off-the-map collection of references that the engineering teams swear by.

Not the sanitized intranet they were used to swearing at.

The Bake-off

The legendary chef Julia Child once said, “Always start out with a larger pot than what you think you need.” She might as well have been describing the process for picking an enterprise search engine. This proof-of-concept or PoC is your due diligence for matching internal priorities and selection criteria to your bake-off results. PoCs demand an improbable mix of reference able work product – no matter where it comes from, the application particulars, or the sub par referencing used to catalog the electronic version of what lives inside organizational roles and responsibilities.

Once I had my vetted safety net, I was clear to map them to the safe harbor of the search interface where memories get tested, experiments are run, and explanations are concocted.  That mapping included a healthy respect for the mismatch between Googling for cat videos that stick to our social billboards and researching a backlog of databases that live behind a corporate firewall. A PoC was undertaken to reduce the vast, uncharted wilderness of Keen Core to a single search box and a choice of search vendors – hence the “bake-off” that played out against the following design choices:

#1 – Fact versus Conceptual Search: Most business problems are not reducible to the distance of the closest pizzeria with the highest reputation ranking. In other words the answer is neither immediate nor obvious. It’s not persuasive on its own but needs the back-story to connect its relevance to the problem at-hand. That connection can only be provided by the searcher – not the search engine. The conceptual search idea was welcome by my colleagues as they were well-acquainted with the status and responsibilities of domain-expert-as-content-curator.

#2 – Single Answers versus Iterative: Because of their research-focused nature, most business or enterprise search problems are not only conceptual but iterative. They are greatly influenced by changes in time frame, authorship, formatting, narrative style, and context – the reason the artifact exists in the first place. Enterprise search results defy definitive or conclusive answers. They’re conversational – not just among peers but with the search interface itself which guides the searcher with:

1. Related events, 
2. People, 
3. Locations, and 
4. Organizations that suggest …
5. Further probing, 
6. Competing explanations, or even …
7. Complete redirections of our original assumptions.

This relatedness was realized in the proof of concept. Human-mediated tagging was neither doable nor desirable but the prospective search technologies proved up to the task for grouping these relations as search facets.

#3 – Search versus Source Dependent: The key to building our knowledge safety net is not so much keyword searching as enterprise sourcing: The ability not just to crawl volumes of pages, folders, and files but to evidence why anyone bothered to do so. Search scoping is essential because it brings the sense-making role of any single artifact apparent to colleagues with otherwise no shared experience beyond a common holiday calendar and pay cycle. Sourcing logic reinforces the cohesive logic of coordination across business lines and supporting functions:

1. Want to know what the customer sees before it’s out on your website? Search on marketing. 
2. Want to understand our products better? Search on training. 
3. Visual learner? Precede to training videos, etc. 
4. The more technical explanation? Go to the core requirements hammered out by account managers and the engineers who design to them.

Everyone at Keen Core understood the different lenses for sifting through the same content. The challenge was that only engineering had a seat at the bake-off table.

Enterprise Assets or Liabilities?

The good news is that each of these ingredients was factored into an enterprise search proof of concept for the engineering crew at Keen Core. The correct sources were indexed and configured to a search-driven interface reflecting both the nature of the index and the information-seeking goals of the searcher. Better still I got to run a true side-by-side comparison between two enterprise search vendors (Coveo and Google). The thinking here: My colleagues could base their tool of choice on their actual problem-solving.

The bad news is that Keen Core’s enterprise resembled a potluck more than a catered sit-down. The number of place settings changed with who wanted a seat at the table. The unsettled seating arrangements made it hard to move forward without revisiting some tired assumptions like:

• The Google Slam Dunk: Hey, wipe that Google web smirk off your enterprise requirements for Google Search Appliance. We’re talking two different engines here!
• The How Big-is-Our-Data Routine? What constitutes a fair test sample when a vendor solution crawls across diverse operating systems, repositories, and legacy apps (with licenses no one bothered to renew)?  
  
• The How-Open-is-Open Question? What's bothering your colleagues about access to resources? What's the important stuff we can get access to if we need it?  What are the content bottlenecks that hinder a silo-bound organization?

Conclusion: At every milestone selecting the right vendor was resistant to simple risk-to-benefit reductions. Multiple trade-offs were the norm. So were the dug-in heels of competing vendor camps. All of these larger lessons were lost to the conflicting agendas of poker-faced stakeholders – regardless of the actual bake-off winner.

Next week: The bake-off verdict is clouded by a crash diet spending plan courtesy of a stock delisting and a CEO whose blunt leadership style distances him from all non-depreciable costs -- including the company’s ingrained know-how on the building of its products.

***

The blog series KM in the Jerkplace is a work of fiction. Names, characters, businesses, places, events and incidents are either the products of the author’s imagination or used in a fictitious manner. Any resemblance to actual persons, living or dead, or actual events is purely coincidental.

Requiem for a Working Stiff

There are two reasons that economies exist: (1) to remunerate the owners of capital to the optimal degree; and (2) to maintain social stability, a.k.a. so the renters of capital keep the roofs on their backs and don't storm the gates of McMansionville. 


The further the U.S. strays from reason #2 the more convinced I am that there is a price for greed. There is a cost for fear. What us humans will stumble over the brambles of adversity in the life auction to bid for at any price is stability. What's the market doing today -- name your price. It's stability that's priceless. There's actually a third reason -- electing more Republicans to public office by promising to cut the taxes of all Americans (dead or alive). But I digress. 


I showed you my economic cards to foreshadow a recent get-together with a former colleague once removed. It happened at a completely pass-up-able trade show in Boston few weeks back. I wasn't speaking, I wasn't listening. I wasn't paying or expensing or conventioning any of it. But I went because it gave me the opportunity to run into folks I normally graze indirectly through a fleeting tweet or a bump on a blog. The fact that these are "chance" meetings with no formal agendas or hard stops is sometimes as appealing as the names that drop into these calendar openings.


However, there was one meeting of particular merit because it reminded me of a time in the past where terms like "career-building" and "ladder-climbing" were more than platitudes to gold watches and indentured supplicants. The gentleman I was meeting with had just accepted a job to work as a KM grunt with a prestigious and high-flying brain factory fired from piping, fresh HBS idea ovens. 


George (I'll call him here) had a much better run than I as an independent KM consultant with longer feasts, shorter famines, and enough returning engagements to get him on the short list of folks who are called into bless, validate, and handicap most big ticket enterprise content decisions.


What search engine do we buy? Why is garbage-in, garbage-out the only process flow that works with any regularity in our document life-cycle? George was the guy who could address the daunting and predictable questions  looming on  the radars of cash-rich, strategically impoverished IT shops left minding the information management store.


Maybe it was another college tuition to meet? Perhaps it was a spouse furloughed by the uncertainty that the future includes a place for over educated Americans who expect promotions and raises? Maybe it was the shock of knowing that mom and dad are now not just confusing our names with our siblings but referring to us as their own siblings? 


Whatever landed over the top on the wrong side of the watershed  bed, George decided that being paid twice a month was preferable to the prospect of fatter, inconsistent pay days. He confided that it stung a little to see no press release parading the new home of his worthy track record and talents. The simple fact is that companies don't crow about their costs and George's new employer doesn't sell KM consulting for a living. 


Do they want to deliberate about how the only thing standing between them and bigger deals is better knowledge-sharing? Nope. And especially nope if they can't bill for it. Community-building? IP propagation? That's what we hired you to do, George. Let us know when you've fixed it and we'll have something.


I sympathize with George -- to a point. But then I need to remind him -- not of his senile parents or farcical former clients but that he is now firmly under the radar and cleared for take-off. This is a glide-path where he can pilot the hypotheticals. The slideware is gone.  Every new hire is not just a collegial grunt but a recruitment opportunity: what is it from me you expect? If the answer is a blank stare, I'll mold the fillings. You'll be pedaling your fulfillment right out of our showroom (or intranet for those of you viewing at work).

It's worth noting that in my own family my wife had her own recent breakthrough on working stiff etiquette.  Rather than lamenting the fact that her basket case nonprofit closes its firewall to remote access, she saw her dysfunctional IT operation as the gift that it is -- six uninterrupted hours on Acela to wifi her way to a job that leaves her alone long enough to live her life.  


In conclusion, George, believe your indoctrination into the land of working stiffs will offer its own rewards – not the least of which is far greater flexibility to unleash your pragmatic creative problem-solving in an environment that will benefit your new colleagues in ways they scarcely know.

Requiem for a Working Stiff

There are two reasons that economies exist: (1) to remunerate the owners of capital to the optimal degree; and (2) to maintain social stability, a.k.a. so the renters of capital keep the roofs on their backs and don't storm the gates of McMansionville. 


The further the U.S. strays from reason #2 the more convinced I am that there is a price for greed. There is a cost for fear. What us humans will stumble over the brambles of adversity in the life auction to bid for at any price is stability. What's the market doing today -- name your price. It's stability that's priceless. There's actually a third reason -- electing more Republicans to public office by promising to cut the taxes of all Americans (dead or alive). But I digress. 


I showed you my economic cards to foreshadow a recent get-together with a former colleague once removed. It happened at a completely pass-up-able trade show in Boston few weeks back. I wasn't speaking, I wasn't listening. I wasn't paying or expensing or conventioning any of it. But I went because it gave me the opportunity to run into folks I normally graze indirectly through a fleeting tweet or a bump on a blog. The fact that these are "chance" meetings with no formal agendas or hard stops is sometimes as appealing as the names that drop into these calendar openings.


However, there was one meeting of particular merit because it reminded me of a time in the past where terms like "career-building" and "ladder-climbing" were more than platitudes to gold watches and indentured supplicants. The gentleman I was meeting with had just accepted a job to work as a KM grunt with a prestigious and high-flying brain factory fired from piping, fresh HBS idea ovens. 


George (I'll call him here) had a much better run than I as an independent KM consultant with longer feasts, shorter famines, and enough returning engagements to get him on the short list of folks who are called into bless, validate, and handicap most big ticket enterprise content decisions.


What search engine do we buy? Why is garbage-in, garbage-out the only process flow that works with any regularity in our document life-cycle? George was the guy who could address the daunting and predictable questions  looming on  the radars of cash-rich, strategically impoverished IT shops left minding the information management store.


Maybe it was another college tuition to meet? Perhaps it was a spouse furloughed by the uncertainty that the future includes a place for over educated Americans who expect promotions and raises? Maybe it was the shock of knowing that mom and dad are now not just confusing our names with our siblings but referring to us as their own siblings? 


Whatever landed over the top on the wrong side of the watershed  bed, George decided that being paid twice a month was preferable to the prospect of fatter, inconsistent pay days. He confided that it stung a little to see no press release parading the new home of his worthy track record and talents. The simple fact is that companies don't crow about their costs and George's new employer doesn't sell KM consulting for a living. 


Do they want to deliberate about how the only thing standing between them and bigger deals is better knowledge-sharing? Nope. And especially nope if they can't bill for it. Community-building? IP propagation? That's what we hired you to do, George. Let us know when you've fixed it and we'll have something.


I sympathize with George -- to a point. But then I need to remind him -- not of his senile parents or farcical former clients but that he is now firmly under the radar and cleared for take-off. This is a glide-path where he can pilot the hypotheticals. The slideware is gone.  Every new hire is not just a collegial grunt but a recruitment opportunity: what is it from me you expect? If the answer is a blank stare, I'll mold the fillings. You'll be pedaling your fulfillment right out of our showroom (or intranet for those of you viewing at work).

It's worth noting that in my own family my wife had her own recent breakthrough on working stiff etiquette.  Rather than lamenting the fact that her basket case nonprofit closes its firewall to remote access, she saw her dysfunctional IT operation as the gift that it is -- six uninterrupted hours on Acela to wifi her way to a job that leaves her alone long enough to live her life.  


In conclusion, George, believe your indoctrination into the land of working stiffs will offer its own rewards – not the least of which is far greater flexibility to unleash your pragmatic creative problem-solving in an environment that will benefit your new colleagues in ways they scarcely know.

Taskonomy -- Where Resource Meets Resourcefulness

How does an information architect get their IP connoisseurs to feast on delectable helpings of choice information?

This morning we had an interface designer in to look at our search outputs. We showed him lots of buckets brimming with appointed rounds of patterns and hit counts that speak to the taste, smell, and texture formed by tens of thousands of documents and list items simmering in the stew pot called SharePoint.

But as orderly and configurable as each displayable facet, this designer made me realize the ball of confusion that awaits the untrained eye. No matter how complete the documentation, each bucket spills into a claustrophobic interface. Point and consider isn't quite so convincing as point and click. Every patch of white space already claimed by some rankable re-ordering of some expandable (if not expendable) subtext.

I'd like to think that we stock the best content store that any interface chef could conceivably conjure in devising the smartest possible holding tank for knowledge transfer.

I own that with equal parts frustration and pride. Pride speaks to the hard-won realization that we are not stockpiling content for the sake of collecting it. It's calibrated, populated, and ready for serving. Each artifact passes more than a knowing glance that it's intended for re-assemblages to support some new revenue-bearing endeavor.

The frustration is that our basis for action stumbles in a poorly designed interface. In fact our design is about as kludgy as our metadata is immaculate. Why are we so late to this table? Perhaps there is no rapid translation on intranets from look-and-feel to shop-and-spend? Then again we've squandered resources straying off the SharePoint reservation because of our unwelcoming and cluttered interface.

What we've executed on is metadata and the assertion that an action-based taxonomy is foundational. But the front door that swings open to users can dignify the underlying structure by exposing the proper detail at the moment of instigation -- that user becomes a producer by synthesizing those not-so-raw materials into a refined and unique deliverable.

Whether the end game is simple (the completed form is in my out-box) or glorified (IP creation), it takes the marriage of taxonomy and design to deliver a taskonomy -- that stretchable dimension between what's been conceived and what will become conceivable.

Taskonomy -- Where Resource Meets Resourcefulness

How does an information architect get their IP connoisseurs to feast on delectable helpings of choice information?

This morning we had an interface designer in to look at our search outputs. We showed him lots of buckets brimming with appointed rounds of patterns and hit counts that speak to the taste, smell, and texture formed by tens of thousands of documents and list items simmering in the stew pot called SharePoint.

But as orderly and configurable as each displayable facet, this designer made me realize the ball of confusion that awaits the untrained eye. No matter how complete the documentation, each bucket spills into a claustrophobic interface. Point and consider isn't quite so convincing as point and click. Every patch of white space already claimed by some rankable re-ordering of some expandable (if not expendable) subtext.

I'd like to think that we stock the best content store that any interface chef could conceivably conjure in devising the smartest possible holding tank for knowledge transfer.

I own that with equal parts frustration and pride. Pride speaks to the hard-won realization that we are not stockpiling content for the sake of collecting it. It's calibrated, populated, and ready for serving. Each artifact passes more than a knowing glance that it's intended for re-assemblages to support some new revenue-bearing endeavor.

The frustration is that our basis for action stumbles in a poorly designed interface. In fact our design is about as kludgy as our metadata is immaculate. Why are we so late to this table? Perhaps there is no rapid translation on intranets from look-and-feel to shop-and-spend? Then again we've squandered resources straying off the SharePoint reservation because of our unwelcoming and cluttered interface.

What we've executed on is metadata and the assertion that an action-based taxonomy is foundational. But the front door that swings open to users can dignify the underlying structure by exposing the proper detail at the moment of instigation -- that user becomes a producer by synthesizing those not-so-raw materials into a refined and unique deliverable.

Whether the end game is simple (the completed form is in my out-box) or glorified (IP creation), it takes the marriage of taxonomy and design to deliver a taskonomy -- that stretchable dimension between what's been conceived and what will become conceivable.

SearchBoards

The choice of text versus numbers is starting to ring false. The trade-off between relational tables and keywords is no longer a stretch or a compromise. The missing ingredient isn't the optimal content database or the more responsive search tool but the outcomes that live in the cross-hairs between traditional BI and conventional keyword matches, and what began many formatting standards ago as decision support.

The purpose of SearchBoards is to classify content on a granular level. The goal is not panning for knowledge gold but to scratch the itch that prompts the question. Searchboarding doesn't retrieve articles and files, Search Targeting informs what happens next. As Judith Jaffe, Knowledge Manager from the Risk Management Foundation put it in yesterday's Boston KM Forum it's to embed interventions into workflows. It's us knowledge workers reconfiguring the juggernaut of documentable consequences. In English that means indexing spreadsheets so that the nuggets are discoverable, process-specific, action-based, and quantifiable as assets.

The counting goes beyond raw first and secondary wordcounts inherent in typical SEO analytics and goes to a tender info fantasy older than any taxonomic model. That's flipping on a switch and having the proposal auto-generate or the diagnosis nestle in a warm bed of evidence. There's a problem, a set of case tables, and a battery of check boxes. No one is left holding the word bag.

This is a good thing because it takes the conversation away from hit counts and page ranks and into the more tangible matters of solving problems and completing tasks. It's not about capturing insights -- yawn. It's about the rich conversation between what we're working with (data sources) and what we're working on and against (projects and deadlines).

Another promising development is that when our data sources are bullets and talking points, we remove the ambiguities that are full-time occupants of Planet Google. And those doubtful citizens answer to a toppled leader called "intention." And the lingua franca of intentionality are particles of speech. They disappear with SearchBoards. That's because SearchBoards eliminates the source of the ambiguity -- that troublesome middle man between all causes and effects called the predicate. It's problematic because predicates are the nerve endings of human logic and they fall apart completely at the mercy of search technology.

And those search engines are as good as teaching how futile this is as they are abysmal at overcoming their own limitations. We've been trained well to keep our expectations low. Witness a Stanford University study cited by yesterday's forum speaker Mark Sprague that suggests 2.4% of all search terms include verbs. No small wonder we have no idea what to do with our global information surplus.

Another tedious argument that goes away here is the Coke vs. Pepsi piss-off that parallels taxonomies and folksonomies. The liberation here is that common meeting grounds like "results" or "teams" or "industries" lend themselves to pattern-friendly sets of finite values (classification schemes). Other more fluid fields like "results" or "objectives" remain open-ended. But the rich variety of how those stories play out become the bucketed narratives on the SearchBoard results queue.

Finally the biggest payback is that we get to keep serendipitous top-of-mind association. Was there ever any doubt? And we can still bask in our most enduring content structures. What's there not to like when the only thing we have to Google is Google itself?

SearchBoards

The choice of text versus numbers is starting to ring false. The trade-off between relational tables and keywords is no longer a stretch or a compromise. The missing ingredient isn't the optimal content database or the more responsive search tool but the outcomes that live in the cross-hairs between traditional BI and conventional keyword matches, and what began many formatting standards ago as decision support.

The purpose of SearchBoards is to classify content on a granular level. The goal is not panning for knowledge gold but to scratch the itch that prompts the question. Searchboarding doesn't retrieve articles and files, Search Targeting informs what happens next. As Judith Jaffe, Knowledge Manager from the Risk Management Foundation put it in yesterday's Boston KM Forum it's to embed interventions into workflows. It's us knowledge workers reconfiguring the juggernaut of documentable consequences. In English that means indexing spreadsheets so that the nuggets are discoverable, process-specific, action-based, and quantifiable as assets.

The counting goes beyond raw first and secondary wordcounts inherent in typical SEO analytics and goes to a tender info fantasy older than any taxonomic model. That's flipping on a switch and having the proposal auto-generate or the diagnosis nestle in a warm bed of evidence. There's a problem, a set of case tables, and a battery of check boxes. No one is left holding the word bag.

This is a good thing because it takes the conversation away from hit counts and page ranks and into the more tangible matters of solving problems and completing tasks. It's not about capturing insights -- yawn. It's about the rich conversation between what we're working with (data sources) and what we're working on and against (projects and deadlines).

Another promising development is that when our data sources are bullets and talking points, we remove the ambiguities that are full-time occupants of Planet Google. And those doubtful citizens answer to a toppled leader called "intention." And the lingua franca of intentionality are particles of speech. They disappear with SearchBoards. That's because SearchBoards eliminates the source of the ambiguity -- that troublesome middle man between all causes and effects called the predicate. It's problematic because predicates are the nerve endings of human logic and they fall apart completely at the mercy of search technology.

And those search engines are as good as teaching how futile this is as they are abysmal at overcoming their own limitations. We've been trained well to keep our expectations low. Witness a Stanford University study cited by yesterday's forum speaker Mark Sprague that suggests 2.4% of all search terms include verbs. No small wonder we have no idea what to do with our global information surplus.

Another tedious argument that goes away here is the Coke vs. Pepsi piss-off that parallels taxonomies and folksonomies. The liberation here is that common meeting grounds like "results" or "teams" or "industries" lend themselves to pattern-friendly sets of finite values (classification schemes). Other more fluid fields like "results" or "objectives" remain open-ended. But the rich variety of how those stories play out become the bucketed narratives on the SearchBoard results queue.

Finally the biggest payback is that we get to keep serendipitous top-of-mind association. Was there ever any doubt? And we can still bask in our most enduring content structures. What's there not to like when the only thing we have to Google is Google itself?

SharePoint -- Suiting Up for the Sophomore Season

I'm presenting next week on a webcast hosted by Waltham-based KMA ("Knowledge Management Associates"). The venue is called SharePoint the Sophomore Year: Maximizing your investment in SharePoint after initial implementation.

I didn’t know SharePoint when I came on board in my current role and I came on-board to implement SharePoint. The freshman year was about implementing SharePoint 2003 for a business region. SharePoint 2007 was launched in early 2008. You don’t know me so I’ll focus on the ugly and the unscripted. Stay off script, come clean with your failures and people believe you -- even when they know more about SharePoint than they do about me.

Here are some the of the takeaways I'll be sharing:

Centrality: The sophomore year story is around making SharePoint the cat herder’s container of choice. How do we unify and rally around our mutual interconnectedness? It begins with shared experiences all employees cycle through. I count three: bi-weekly pay dates, bi-monthly staff meetings, and logging into SharePoint. You could set your watch to this. That's a big arrow in the quiver of the enterprise cat-herder.

Utilization: No ability counts more in consulting than billability. For cost centers like KM grunts and SharePoint administrators this means designing systems with a user focus. A user focus for us is about architecting SharePoint by actions – not destinations or cataloguing, or laundry lists. The results mean fewer arguments about what to call things and no need to memorize where documents are stored. This is a skill reserved for savants and reference librarians -- not management consultants.

Motivation: Motivation centers on the draw of SharePoint in skill-building for our consultants – not because we have it but because our clients do.

Participation: Participation bridges directly to our community of practice discussions. The end game is that there’s content supply (corpus) and demand (search logs). That’s how we remind our users that they’re knowledge producers too. When they ask for advice they have a responsibility to re-invest those assets back into SharePoint.

Payback: Payback is not about proving how many more deals go through because now we’re all on the same SharePoint page or even reducing the number of search results our users have to slog through before their requirements are met. Payback is about fitting form to function. That means addressing knowledge demands through best bets, search collections, inbound email, and expertise finders to name a few.

The metadata schema is a huge reporting payoff because it helps us understand the long tail – those queries that are specific to a set of requirements – not the common search terms that can be found in the short tail of most search logs. In the build above you can see how our metadata structure is helping the user to combine specific teams, practices, date ranges, and even caliber of results. Best of all they can subscribe to the results as an RSS feed in Outlook so they needn’t ever run the search again.

So those are a few ways of leveraging your sophomore year investment – hopefully without having to pay for your junior year in advance!

SharePoint -- Suiting Up for the Sophomore Season

I'm presenting next week on a webcast hosted by Waltham-based KMA ("Knowledge Management Associates"). The venue is called SharePoint the Sophomore Year: Maximizing your investment in SharePoint after initial implementation.

I didn’t know SharePoint when I came on board in my current role and I came on-board to implement SharePoint. The freshman year was about implementing SharePoint 2003 for a business region. SharePoint 2007 was launched in early 2008. You don’t know me so I’ll focus on the ugly and the unscripted. Stay off script, come clean with your failures and people believe you -- even when they know more about SharePoint than they do about me.

Here are some the of the takeaways I'll be sharing:

Centrality: The sophomore year story is around making SharePoint the cat herder’s container of choice. How do we unify and rally around our mutual interconnectedness? It begins with shared experiences all employees cycle through. I count three: bi-weekly pay dates, bi-monthly staff meetings, and logging into SharePoint. You could set your watch to this. That's a big arrow in the quiver of the enterprise cat-herder.

Utilization: No ability counts more in consulting than billability. For cost centers like KM grunts and SharePoint administrators this means designing systems with a user focus. A user focus for us is about architecting SharePoint by actions – not destinations or cataloguing, or laundry lists. The results mean fewer arguments about what to call things and no need to memorize where documents are stored. This is a skill reserved for savants and reference librarians -- not management consultants.

Motivation: Motivation centers on the draw of SharePoint in skill-building for our consultants – not because we have it but because our clients do.

Participation: Participation bridges directly to our community of practice discussions. The end game is that there’s content supply (corpus) and demand (search logs). That’s how we remind our users that they’re knowledge producers too. When they ask for advice they have a responsibility to re-invest those assets back into SharePoint.

Payback: Payback is not about proving how many more deals go through because now we’re all on the same SharePoint page or even reducing the number of search results our users have to slog through before their requirements are met. Payback is about fitting form to function. That means addressing knowledge demands through best bets, search collections, inbound email, and expertise finders to name a few.

The metadata schema is a huge reporting payoff because it helps us understand the long tail – those queries that are specific to a set of requirements – not the common search terms that can be found in the short tail of most search logs. In the build above you can see how our metadata structure is helping the user to combine specific teams, practices, date ranges, and even caliber of results. Best of all they can subscribe to the results as an RSS feed in Outlook so they needn’t ever run the search again.

So those are a few ways of leveraging your sophomore year investment – hopefully without having to pay for your junior year in advance!

The Clarifying Power of Verbs

I notice that whenever I give my S-Y-N-C talk the note-takers reach for their pens when the discussion comes to verbs. The action-based taxonomy that I advocate is a simple and effective way to anticipate (and eliminate) some common barriers to enterprise architecture before we crash into them:

* Hair-splitting -- The chances for semantic quibbling over what to call stuff are greatly reduced when things become actions. There are many fewer ways of describing a predicate than a subject. The likelihood for shared agreements increases.

* User-centric -- Instead of fighting over what to call things an action-based taxonomy helps us agree on how and why our customers draw on our content supply.

* Reporting -- You can't plot the outcomes you're supporting (new IP, project requirements, business development) without building an architecture atop the actions needed to trigger those developments.

* 80/20 Rule -- If every 80/20 rule lined up in single formation they would all be parading to the battle hymn of mother necessity; that the perfect is the enemy of the good. In our marching orders action is the most telling of all metadata elements because it reveals those deepest and fleeting mysteries of all uncharted KM waters -- who wrote this sucker and who was their intended audience? Figure out that side of the shipping manifesto and: (1) you're 80% of the way from content supply to knowledge demand; and (2) your cargo gets unpacked. Why? Because it has an identity that speaks to users.

* Disambiguation -- Probably there is no greater praise for verbs than giving some long-delayed respect they deserve for disambiguation. Next time you hear yourself mutter: "use it in a sentence" tell me the word that drives you to the home of understanding isn't a verb. And while it may be their job that's no reason to overlook their vast powers of clarification.

The Clarifying Power of Verbs

I notice that whenever I give my S-Y-N-C talk the note-takers reach for their pens when the discussion comes to verbs. The action-based taxonomy that I advocate is a simple and effective way to anticipate (and eliminate) some common barriers to enterprise architecture before we crash into them:

* Hair-splitting -- The chances for semantic quibbling over what to call stuff are greatly reduced when things become actions. There are many fewer ways of describing a predicate than a subject. The likelihood for shared agreements increases.

* User-centric -- Instead of fighting over what to call things an action-based taxonomy helps us agree on how and why our customers draw on our content supply.

* Reporting -- You can't plot the outcomes you're supporting (new IP, project requirements, business development) without building an architecture atop the actions needed to trigger those developments.

* 80/20 Rule -- If every 80/20 rule lined up in single formation they would all be parading to the battle hymn of mother necessity; that the perfect is the enemy of the good. In our marching orders action is the most telling of all metadata elements because it reveals those deepest and fleeting mysteries of all uncharted KM waters -- who wrote this sucker and who was their intended audience? Figure out that side of the shipping manifesto and: (1) you're 80% of the way from content supply to knowledge demand; and (2) your cargo gets unpacked. Why? Because it has an identity that speaks to users.

* Disambiguation -- Probably there is no greater praise for verbs than giving some long-delayed respect they deserve for disambiguation. Next time you hear yourself mutter: "use it in a sentence" tell me the word that drives you to the home of understanding isn't a verb. And while it may be their job that's no reason to overlook their vast powers of clarification.

Enterprise Search Plummet

I take no satisfaction to in repeating back what one CEO from an Israeli startup told me but I had to agree: "complete meltdown."

He was referring to the lack of imagination, attendees, and reasons for showing up at Information Today's Enterprise Search Summit. Much of the dour story is told through realities that no event planner can possibly correct. I saw the low numbers at the Boston Gilbane show last December and that was sobering. Still given the strong concentration of media/finance/law/consulting communities in and around NYC I thought enough of a core group existed to attract the vendors and analysts -- maybe even some splashy announcements.

Nothin' doin'. No luminaries -- The Steve Arnolds, Sue Feldmans, Oz Benjamins -- all no shows. Even the vendor speakers seemed in a hurry to finish their sessions so that we'd have more time to mix. Precious little was said or speculated on concerning FAST and its place in the Microsoft search arsenal. Even less was offered in terms of SharePoint customizations, 3rd party tools, and what's worth planning for in the new release.

As an Information Today subscriber, contributor and speaker I have no incentive to trash their earnest efforts to stage an influential and instructive conference. It's equally true that I did get value from going. Even in a lean year I benefitted much from exposure to Lou Rosenfeld who I had interviewed but never seen shine in a conference setting. One of the keynoters, a guy named Jared Spool gave a spot-on repudiation to the vendors; that the search bar is not the common ally of the uninformed masses but actually a tool of last resort. The guy I was teamed with on the interface track, John Ferrara, laid out an astute and telling case for the suggest function.

That said perhaps it's time to rethink why we used to come each year. Maybe its time to consider how those reasons might be wearing thin while others that go begging could be answered in future forums?

For starters there's very little give-and-take between attendees in terms of first-hand feedback on their specific deployments. Why not an open mic night version for info-geeks? We could kick the vendors out (or they could forget booth-sitting and pay the sponsor for eavesdropping privileges.

Another improvement would be to attempt some prototyping among breakout groups that try to advocate on behalf of their mock project. Another team could shoot it down on numerous grounds and both teams could learn a thing or two about implementation politics that are not so obvious when sequestered behind your own firewall. Dave Snowden does a far better job of describing and staging this exercise in the Art of Ritual Dissent.

Finally if I put on my dust-laden vendor cap I can imagine how these gatherings could be used to test drive my MRD requirements: what user pains are consensus-forming and which ones only apply to fringe customers? Where should I aim my priorities for upcoming releases? A face-to-face test lab might do the trick.

Enterprise Search Plummet

I take no satisfaction to in repeating back what one CEO from an Israeli startup told me but I had to agree: "complete meltdown."

He was referring to the lack of imagination, attendees, and reasons for showing up at Information Today's Enterprise Search Summit. Much of the dour story is told through realities that no event planner can possibly correct. I saw the low numbers at the Boston Gilbane show last December and that was sobering. Still given the strong concentration of media/finance/law/consulting communities in and around NYC I thought enough of a core group existed to attract the vendors and analysts -- maybe even some splashy announcements.

Nothin' doin'. No luminaries -- The Steve Arnolds, Sue Feldmans, Oz Benjamins -- all no shows. Even the vendor speakers seemed in a hurry to finish their sessions so that we'd have more time to mix. Precious little was said or speculated on concerning FAST and its place in the Microsoft search arsenal. Even less was offered in terms of SharePoint customizations, 3rd party tools, and what's worth planning for in the new release.

As an Information Today subscriber, contributor and speaker I have no incentive to trash their earnest efforts to stage an influential and instructive conference. It's equally true that I did get value from going. Even in a lean year I benefitted much from exposure to Lou Rosenfeld who I had interviewed but never seen shine in a conference setting. One of the keynoters, a guy named Jared Spool gave a spot-on repudiation to the vendors; that the search bar is not the common ally of the uninformed masses but actually a tool of last resort. The guy I was teamed with on the interface track, John Ferrara, laid out an astute and telling case for the suggest function.

That said perhaps it's time to rethink why we used to come each year. Maybe its time to consider how those reasons might be wearing thin while others that go begging could be answered in future forums?

For starters there's very little give-and-take between attendees in terms of first-hand feedback on their specific deployments. Why not an open mic night version for info-geeks? We could kick the vendors out (or they could forget booth-sitting and pay the sponsor for eavesdropping privileges.

Another improvement would be to attempt some prototyping among breakout groups that try to advocate on behalf of their mock project. Another team could shoot it down on numerous grounds and both teams could learn a thing or two about implementation politics that are not so obvious when sequestered behind your own firewall. Dave Snowden does a far better job of describing and staging this exercise in the Art of Ritual Dissent.

Finally if I put on my dust-laden vendor cap I can imagine how these gatherings could be used to test drive my MRD requirements: what user pains are consensus-forming and which ones only apply to fringe customers? Where should I aim my priorities for upcoming releases? A face-to-face test lab might do the trick.

S-Y-N-C-ing Content Supply to Knowledge Demand

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.

S-Y-N-C-ing Content Supply to Knowledge Demand

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.

Site in the clouds

The last couple of weeks I've been nibbling away at a new approach to staging knowledge portals by staging a pilot through Google Sites. It's the anti-intranet. It's the thousand tiny SharePoints of light. It's not proprietary although it is password protected. It's a portal into something larger -- not smaller than the sum of its hyperlinks. No one needs an encryptocard or a secret handshake other than the invite to join.

The one frustration is that the so-called scripts that pass for gadgets are as erratic as a unexpected and unwelcome one-two patch on a Windows update. I must have toyed with a half-dozen customizable RSS interfaces. They all fell apart the minute I went into tweak them. That's my kneejerk response to the false positives pouring from references to Obama that include neither 'government' nor 'politics.' (Talk about departing from false positives as usual).

The ticker display widgets, especially from one source called SaneBull are a hearty lot. The driving directions from MapQuest won't drain the batteries on your GPS compass. I am in awe of the Google spreadsheets that sing and dance or cry and mope depending on the market gyration du jour. It's also a guilty pleasure to be searching on filetype and trolling for all these "kickass PowerPoints." That's not my emotional connection but those of the consultants who respirate, perspire and dream in slideware. The punch line is that it's public domain presentations so the getting something for nothing buzz lasts a lot longer than the going rate on RSS feeds.

The nicest part about cloud computing for builders and users alike is that you've replaced Little IT with Big Google. And there are no bruised egos, server crashes, or even pink slips -- how beneficent can Google be?

The other knot that I still haven't untangled is that the Custom Google Search closes for business whenever I log off the web. This is never an issue on the blog where the Javascript holds the custom search in place regardless of whether hot PowerPoints can keep me burning through spent fuel rods well after the intranet shuts its doors.

Site in the clouds

The last couple of weeks I've been nibbling away at a new approach to staging knowledge portals by staging a pilot through Google Sites. It's the anti-intranet. It's the thousand tiny SharePoints of light. It's not proprietary although it is password protected. It's a portal into something larger -- not smaller than the sum of its hyperlinks. No one needs an encryptocard or a secret handshake other than the invite to join.

The one frustration is that the so-called scripts that pass for gadgets are as erratic as a unexpected and unwelcome one-two patch on a Windows update. I must have toyed with a half-dozen customizable RSS interfaces. They all fell apart the minute I went into tweak them. That's my kneejerk response to the false positives pouring from references to Obama that include neither 'government' nor 'politics.' (Talk about departing from false positives as usual).

The ticker display widgets, especially from one source called SaneBull are a hearty lot. The driving directions from MapQuest won't drain the batteries on your GPS compass. I am in awe of the Google spreadsheets that sing and dance or cry and mope depending on the market gyration du jour. It's also a guilty pleasure to be searching on filetype and trolling for all these "kickass PowerPoints." That's not my emotional connection but those of the consultants who respirate, perspire and dream in slideware. The punch line is that it's public domain presentations so the getting something for nothing buzz lasts a lot longer than the going rate on RSS feeds.

The nicest part about cloud computing for builders and users alike is that you've replaced Little IT with Big Google. And there are no bruised egos, server crashes, or even pink slips -- how beneficent can Google be?

The other knot that I still haven't untangled is that the Custom Google Search closes for business whenever I log off the web. This is never an issue on the blog where the Javascript holds the custom search in place regardless of whether hot PowerPoints can keep me burning through spent fuel rods well after the intranet shuts its doors.

Tag, We're It

Yesterday I attended Laurie Damianos's discussion at the Boston KM Forum ("Tag Me -- Social Bookmarking in the Enterprise"). I had the good fortune of meeting Laurie first at last spring's Enterprise Search Summit.

I found that my number of questions for Laurie has increased since our last interview for the Provider Base piece set to go in the Nov/Dec Searcher. That increase is not because Laurie dodges good questions. It is inspired by the topic -- the richness of the subject itself.

To her credit as a speaker Laurie led an attentive and engaging group whose inputs were both numerous and broadly distributed. Here are some of the more engrossing threads of our dynamic session:

Life in Email --

The immediate remedy at Mitre began as the antidote to a ton of email sitting on some restricted fileserver archive. Increasing access points to content was the business case. A persuasive case was made that there was an over-reliance on 1:1 communication (email) whose knowledge might prove useful to others. Interestingly the Mitre approach includes bookmarking email message based on embedded links in the message.

Anatomy of a Tag --

Do the users make up their own terms? Apparently they have the choice between a pre-formed set of suggested tags or their own. The form includes the original bookmarker and others who've bookmarked their entries. Laurie refers to the comment feature as "a reverse blog."

Links to Nowhere --

Pointers need owners or the link goes stale. The broken link icon shows benefits of a link scan process that tests for 404 errors. Each owner is notified of the bookmarks they develop which they can choose to ignore, fix, or delete. Hovering over a padlock tells the user how to pick the lock (i.e. what password to use or group to contact). Users can mouse over faces and get lots of detail at a glance. When they leave the company the residual bookmarks are placed in separate account -- they can be copied for 90 days or let expire.

Social Tags (Supply) and Search Terms (Demand) --

The terms that bubble to the top of the results pages are not repesented in Mitre's subject taxonomy. According to Laurie the taxonomy is growing ... slowly. The search term is creating equivalencies between search terms and tags. Governance rules are in place to maintain the folksonomy so it is not altered by an intermediary. Laurie's team allows the differences to remain, not trying to normalize different forms of the same expression.

Expert Finders --

Administrators and gatekeepers had all the topic-related documents so they've been falsely deemed as experts. The same fiction occurs when a top-tagger is confused with being an expert in the subject they're tagging. There's no gaming of the system because there's no built-in incentive to compete head-on or outrank the next prolific tagger.

Social Bookmark Reporting --

There's a seven day window of the most recent popular tags. This breaks the dominance of librarian taggers as most prolific contributors. Tagging activity shows how users are related by interest area. Users can view bookmarks by department. Different sorting options including tags, bookmarks, bookmarks by department. Laurie noted some surprisingly bad taggers even as the firm's KM enablers or "knowledge stewards." Lynda Moulton noted that it takes mindset to do it consistently and effectively. People are getting it.

Tagging by the Numbers --

The system holds...

* 21,000 bookmarks
* 99,000 tags with 12.5K unique to the system (-- doesn't account for spelling and punctuation discrepancies)
* Average number of tags have doubled from 2.7 to 5.4
* The past three years the average is that bookmarks are 83% external

Performance Benchmarks --

According to Caterina Fake of Flickr 9-15% of population are contributors in social communities. This equates to 85-90% of users as lurkers. Fourteen percent of user population contributes at Mitre among those with access. Half of employees use the system.

Next Steps for Tagging --

Laurie mentioned an organization called LCC ("Language Computer Corporation") that examines semantic construction of document to relate tags to each other by generating "did-you-mean-this prompts" to the content provider. It also make recommendations to other users: "you need to talk to this person." It's based on common interests they're sharing beyond the recognition that their interests are shared.

Other Tagging Resources --

FURL caches the bookmarked resources. Users request feature but can't provide it internally because of copyright restrictions. Scuttle is easy to deploy and extend. Twine is another solution with an interesting social component. ConnectBeam and DogEar were also mentioned as self-contained tagging platforms.