11/12/2008
In my last post, I outlined the elements that keep us from easily and/or quickly finding information and the costs associated with a poor findability solution. And in a future post, I'll outline how to build out a findability architecture that will integrate with your information architecture as well as integrating with the findability tools that already exist in your environment if you're running Microsoft technologies.
In this post, I'll discuss managers and business leaders. Why this is important to understand should be apparent: when they are successful, the business is successful. You can take this post as an example of how your findability solution(s) need to adapt to the work habits of different users in your organization. Managers are no exception to this rule. Build out a poor findability solution for them at your own peril. So, let's get going.
In a classic view of management, we find that managers are supposed to organize, coordinate, plan and control. But the reality is that the facts suggest otherwise. Let's take a look at some of these facts. First, managers work at an unrelenting pace and their work environments are characterized by:
- Brevity
- Variety
- Discontinuity
- Action-oriented
- Dislike reflective activities
For example, in one study of CEOs, they found that 50% of their activities lasted less than 9 minutes, that their coffee breaks and lunches are work-oriented and that 93% of CEO verbal contacts are ad hoc. One researcher put it this way: "in not one single case did a manager report obtaining important external information from a general conversation or other undirected personal communication".
Secondly, managers strongly favor verbal media, telephone calls and meetings over documents or aggregated data. Now, being a manager myself, I can tell you that a dashboard is necessary to get a quick overview of what's working and not working. But a dashboard, in and of itself, doesn't provide good data for making decisions. Instead, managers often rely on ad hoc communication. Today's gossip might very well be tomorrow's fact. Most managers cherish "soft" information and often identify decision situations and build models using tidbits of data rather than hard, aggregated data. I can attest from experience that passing comments from people, which tend to be the most honest and transparent types of comments I hear, often form the core of what I think about a person or situation.
Thirdly, projects managed indirectly by managers emerge as a series of small decisions and actions sequenced over time and must be fit into a disjointed, busy schedule. Managers tend to comprehend complex issues gradually rather than through concentrated learning. In one study, they found that CEOs were supervising as many as 50 ongoing projects related to new product development, re-organizing a weak department or launching a public relation campaign. The CEOs would give an individual project limited time and attention with enough energy to send it back into orbit while they focused on another project or C-level personnel decision.
Lastly, research has found that most authorization decisions are based on ad hoc information, even when aggregated data is available. In the same studies with CEOs, they found that the CEOs were faced with many projects that could not wait or did not have quantifiable costs and benefits from which to make informed decisions. Yet, the timing of these decisions was forced by external factors outside the control of the CEO. Their choices were complex and involved a number of difficult-to-quantify elements, such as:
- How does this choice affect other choices already made or that still need to be made?
- Is my choice Acceptable to internal influencers or will passive resistance sabotage my choice?
- Will resources be over-extended?
- Will this result in too much change for my organization?
- What are the non-monetary costs and benefits?
- Is this the right time to make this decision and move forward?
When we stop to ponder how decision-makers work and the type of information they tend to value, this helps us frame up the findability problem in terms that help them be successful. After considering these facts, one can understand how dashboards serve up the type of ad hoc information that managers really need. And if this information is generated by reliable systems, then dashboard information can become even more important to a manager. So, it is true that dashboard information isn't a good basis from which to make decisions, it is a great system to give managers the overview/ad hoc information they need to know which systems, products, teams or other parts of their business or department need more direct and sustained attention.
The reporting of data in a dashboard is technically not a findability issue. Reporting is not the same thing as finding. But there is overlap. Finding the right information at the right time assumes that there is "right" information that can be found and that this information is meaningful to its' consumer. Just like the content items in the result set need to be meaningful to the one who executed the query, the information that is exposed in the dashboard needs to be meaningful to the managers who read it. The information need to accurately make assessments for the manager or report data in such a way that it is comprehended and meaningful as soon as it is consumed.
So, while tagging of data to make documents more findable is a central part of a robust findability solution, don't forget that most of your managers don't have time to sit and read information. Consciously or not, they will flinch in the face of information overload and will filter out much of what they see and hear if it isn't immediately practical and helpful to them. So, ensure that helpful dashboards have been built. And then give them unambiguous ways of drilling down into problem areas from the dashboard to find the information they need to assess and correct and thus improve the business overall. Take time to understand the tools that your managers need to be successful and ensure that these tools add to their efficiency rather than to their workload. Doing so will help improve your business overall and might actually remove resistance to the implementation of a larger findability solution in your environment.
Even though I'm not a lawyer, in my next post, I'll discuss the problems with findability and e-discovery. This is a thorny area that we cannot ignore as we build out our findability architecture.
Bill English, MVP
11/5/2008
In this post, I want to focus on why we have poor findability solutions in our organizations and what the real costs are for maintaining a poor findability solution.
What keeps us from finding the information we need at the time we need it? Well, the AIIM research shows the following statistics:
- Poor search functionality: 71%
- Inconsistency in how we tag/describe data: 59%
- Lack of adequate tags/descriptors: 55%
- Information not available electronically: 49%
- Poor navigation: 48%
- Don't know where to look: 48%
- Constant information change: 37%
- Can't access the system that hosts the info: 30%
- Don't know what I'm looking for: 22%
- Lack the skills to find the information: 22%
Notice that the first and second bullet points deal with the most-often-pursued solution to findability (search application) and the least-often-pursued solution (tagging metadata). Why would this be? I think it's because most decision-makers can more readily understand and quantify the costs and benefits of implementing a software/hardware solution in response to a problem. Moreover, the market tends to define the problem in technical terms rather than cultural or process terms.
But is a poor findability solution really a problem? And if so, is there a way to quantify that problem in real monetary terms? I think the answer to both of these questions is "yes". The cost of a poor findability solution can be enormous. Consider the following research results:
- On any given day, the average information worker commits 20 queries in an effort to find information (Windows Live Enterprise Search, 2006)
- In any given week, the average information worker spends 9.5 hours trying to find the information s/he needs to do his/her job, costing $14,250/year/employee (Source: The Hidden Costs of Information Work, IDC)
- In any given week, the average information worker will spend 6.5 hours not finding information that s/he knows exists only to re-create it so that they have it again. This costs $9700/year/worker. (IDC paper cited above)
Hence, the costs of a poor findability solution are significant, costing organizations an average of roughly $24,000/employee/year. Implementing a solution that will reduce costs through increased productivity should be an obvious call for decision-makers. Yet, it is often overlooked or ignored. I believe this is due to multiple factors: A) culture change is never easy and the headaches associated with such change can be huge, B) the costs/benefit analysis is very difficult to quantify for a specific environment and C) a partial solution to this problem that can be quantified will likely be preferred over a fuller solution that is difficult to quantify.
In my next post, I'll discuss how to build out a Findability Architecture. Doing this will help begin the process of pulling together what I think is a real need in organizations today: how to build a robust findability solution that will improve your organizations' performance.
Bill English, MVP
In my last post, I went over some of the latest research about Findability but never really made the case for why Google's appliance is not, in and of itself, a robust or complete findability solution. In this post, I'll go over this point as well as discuss, briefly, why a technical search solution is not a full findability solution in and of itself.
In my last post, I said this:
"Findability is not a technology. Instead, it is a way of managing information that is baked into the organization. Let me be clear on this point: findability is a well-defined and well-executed strategic model of consistent practices and actions. While it is true that technologies contribute to an overall Findability solution, it is equally true that a robust findability solution is much more than the implementation of search technology."
I want to re-emphasize that building findability into your organization's architecture is tantamount to changing your organization's culture and information processes. These changes need to incorporate several permanent changes:
- Consistent tagging of data
- Assignment of ownership to data
- Willingness of end-users to pragmatically engage in the Findability solution
- Development and training on tools that will support the information architecture and findability solution
- Consistent developing and training on these tools
- Upper level and grassroots support for this effort to improve Findability and re-use of content
Because the development of a Findability solution requires a culture change for the entire organization, it should become apparent that implementing a Search solution – no matter how robust the solution – is not the same thing as implementing a full findability solution. This is why Google's "plug it in, turn it on and find it" is unrealistic. While it is true that Google's appliance – as well as most other search engines – can create a seemingly robust findability solution when applied against a smaller set of documents that are homogenous in their word structures, it is also true that as the words and their meaning randomize, the keyword search method of finding information becomes less and less effective. (Please see my Part II post for a fuller discussion on this.)
I will also say that Search Server 2008 by itself is not a full findability solution either. In fact, any search application platform cannot form a full findability solution because the search applications can find only that which exists. If the documents have not been tagged, then the search engine cannot find them by their metadata. If meaning cannot be accurately discerned from the keyword query, then findability is damaged and the user experience diminished because there is no metadata to discriminate between documents.
Do we need Search? Absolutely. But the technical solution is not a full findability solution. In my future posts, I'll continue to expand on the current research and build on this concept that implementing a full findability solution is much more than implementing a technical search application. I'll also, as promised before, build out a findability architecture that should help us all understand better how to align our information architectures with our technical solutions to produce a robust findability solution.
Bill English, MVP
When I go out and do SharePoint architecture and design sessions with companies, what I find is that most organizations really don't take time to organize their content well. Content organization and the tagging of metadata on content is nearly universally viewed as a waste of time – an overhead expense that just isn't necessary. Nothing could be further from the truth. 10/26/2008
In my first post about Findability and SharePoint, I explained what findability is an why you need to pay attention to it as you're developing your SharePoint Server 2007 deployment.
In this post, I would like to discuss some of the recently released research on findability in corporate America. I will then take a moment to go over why Google's promise of "plug it in, turn it on and find it" is both unrealistic and simplistic. So, let's start with a quick overview of some recent research on Findability in the marketplace.
You can do nearly everything right with your SharePoint deployment and yet still get it all wrong when it comes to users being able to find their information quickly and easily. For example, you can do all of the following correctly….
- Capacity plan your servers correctly
- Scale out your farm correctly
- Implement all of the customizations correctly
- Implement a robust Search and Indexing solution
- Train your users correctly
- Write the business and technical requirements for your deployment
- Manage your servers to the point where there are no errors or warnings in any of the event logs
…..And still fail in your SharePoint implementation because people can't find the information they need quickly and easily. Now, I'm not suggesting at all that these elements should be ignored or should be considered unimportant. If there's one thing we have learned, it is a SharePoint Server 2007 deployment requires excellence at each level of the deployment and from each group involved in the deployment if everyone is going to be happy. But this is to say that not integrating a coherent findability architecture into your SharePoint Server 2007 deployment will mean that you have missed one of the main reasons for implementing SharePoint Server 2007 in the first place: to find your information more quickly and easily than can be achieved by current technologies.
Published by AIIM, the Findability and Market IQ white paper exposed the perilous state of findability in most organizations today. When respondents were asked "How well is findability understood in your organization?", only 17% said that it was both well understood and adequately addressed. 30% of the respondents couldn't discern the difference between their search technologies and findability. 22% responded that there was no clear understanding of findability in their organization.
This single question revealed that over half of the organizations today either don't know what findability is or they think they have findability solved because they have a search appliance or software product in their environment. Search is too-often viewed as an application-specific solution for findability. But when one stops to look at what findability really is, a single search application suddenly misses the mark.
A typical search application focuses on trying to ask the right question by "matching" keywords with content under the assumption that if I find the right word, I've found the right content. The huge assumption here is that meaning can be derived syntactically from the word itself. I found the right word, therefore, I've found the right meaning in the content that has been presented to me in the search results. But nothing could be farther from the truth. Meaning and syntax are two entirely different things. Findability is not resolved by the humble keyword + search application.
Why would I say this? Well, consider the work of George Zipf, who developed the following axiom:
As the size of the corpus increases, the ability of the information retrieval system to retrieve relevant information will diminish
By analyzing large texts, Zipf found that, at least in the English language, a few number of words occur a large number of times. For example, he found that the 2 most frequent words account for 10% of all word occurrences in the English language. Furthermore, he found that the 6 most frequent words account for 20% of all word occurrences and the 50 most frequent words account for 50% of all word occurrences. Now, it can't be that we tend to write and discuss the same topics over and over, can it? Hardly. Instead, what we find is that the more often a word is used, the more general it's meaning and he less often a word is used, the more precise it's meaning.
But language naturally tends towards the use of fewer words to refer to different concepts, objects and elements. Hence, when a single word refers to vastly different concepts, ideas or elements, precision is impaired in the result set because syntax cannot express meaning. For example, consider these word pairs and ask yourself which concept each word is referring to:
- Minute or minute?
- Horn, horn or horn?
- Boot or boot?
- Bonnet or bonnet?
- Football or Football?
In the technology world, we borrow and reconceptualize words at an alarming rate:
- Site or site? (web site, Active Directory site)
- Zone or zone? (DNS zone or a SharePoint zone)
- Domain or domain?
This list could go on and on. Most of the words we use in technology are borrowed words with either new or extended meanings. Hence, when we enter a keyword into a search engine, the likelihood that the content items in the result set will be meaningful diminishes as the number of documents in the index increases. Why? Because, as the number of documents increase in the index, the chances that the same words are used in different ways to mean different concepts increases – often dramatically.
Even more interesting is that meaning is often expressed using different phrases or idioms and is often not expressed in a single word. Consider the following:
- "Good Grief"
- "Give it a Go"
- "I don't have a dog in that race"
- "Oh please, give me a break"
What do these phrases really mean? How difficult is it to find documents that encourage someone to try something if the keywords entered are "give it a go"? Every search engine that I've run across is unable to account for meaning using only keyword queries. Google, SharePoint, Autonomy and the others do not have a good way to account for meaning in their current keyword queries.
Findability is not a technology. Instead, it is a way of managing information that is baked into the organization. Let me be clear on this point: findability is a well-defined and well-executed strategic model of consistent practices and actions. While it is true that technologies contribute to an overall Findability solution, it is equally true that a robust findability solution is much more than the implementation of search technology.
The Paradox of Findability
The AIIM study also found that when respondents were asked the degree to which findability is critical to their overall business goals and success, 62% of respondents indicated that it is imperative or significant. Only 5% felt it had minimal or no impact on business success. Yet, 49% responded that even though Findability is strategically essential, they have no formal plan or set of goals for Findability in their organization. Moreover, of the other 51% who claimed to have a strategy, 26% reported that their strategy was ad hoc, meaning that they have no strategy at all. So, 75% have no Findability strategy, even though many believe it is strategically essential. This is a state of affairs that must change.
In a future posts, I'll outline how to develop a Findability Architecture that integrates with your SharePoint architecture and information architecture. But before I get there, I'll outline some additional research on this topic and then spend more time discussing the problems inherent with attaining precision, recall and relevance.
Bill English, MVP
10/16/2008
The more I learn about findability, the more convinced I am that this concept needs to be an organizing principle of any SharePoint Server 2007 deployment. In this post, I'll explain what findability is in generic terms and then apply these concepts to a SharePoint Server 2007 deployment. I'll also wade into a the difficult area of explaining why Google's current promise of "plug it in, turn it on and find it" is not enough for implementing a full findability solution in your organization.
What is Findability?
Succinctly stated, findability is the quality of being found or the ability to locate objects. Methods of findability includes commonly known technologies such as navigation menus or search/indexing applications. Obviously, we'll want to implement findability tools that are easy to use and integrate seamlessly into our current end-user experience.
Truths about Findability
In his book, Ambient Findability, Peter Moreville outlines several truths that I'll repeat here for sake of our discussion:
- You can't use what you can't find
- Information that can't be found is worthless
- Our customer's can't purchase what they can't find
- Information that is hard to find is hardly used
- Authority, trust and findability are interwoven
- Key to success when working with information is findability
The first truth to focus on is the most important: You can't use what you can't find. It doesn't really matter what the current technology platform is: SharePoint, Autonomy, Websphere, Vingnette, SAP, Oracle, Plumtree or any other portal or collaboration platform. If you can't find the information that has been placed inside it or if the search technology doesn't return relevant search results, then you might as well not have the information at all. The costs of producing that information will have been wasted if you're unable to find the information that you need, when you need it.
If you're running an e-commerce web site, then you should take note that your customers can't purchase what they can't find. If the findability tools on your web site are not good, then it doesn't do you any good to have your products for sale on your web site. Giving your customers the ability to find what they want, evaluate it and then make decisions on your products - all without talking to your sales staff - is the current state of e-commerce. In times past, marketing was mainly a push mechanism - the seller sends out flyers or makes phone calls or invites prospects to their seminars. Today, customers call the shots when it comes to marketing. They can find you on the web, look at your products, read evaluations about your products and services on the web, compare your products features and prices, inform themselves about you and your company and formulate their purchasing decisions without ever talking to your sales team. Why do I emphasize this twice in the same paragraph? Because the customer of today expects to see this information on your e-commerce web site and if you don't have a good web site, you're products and services won't be included in their evaluation process and you'll lose from the start. In a very real sense, the customer's experience on your web site is the experience of your brand. Put another way, the concept of a brand has been expanded to include not just a marketing position + tagline + logo + color scheme, but it now also includes the customer's experience on your web site and how easily it is for them to find that for which they're looking.
Being able to find information is one thing, but the information also needs to be trustworthy and have authority in the mind of the reader. For example, information that is found via the internet can be suspect in terms of authenticity and accuracy. Companies often claim to be "#1" or offer "high quality" products. What company is going to claim that they offer "low quality" products? Doesn't everyone want to be #1? Certain claims just lack authenticity, no matter who makes the claim. The fact that these claims are made on your web site doesn't mean that they are more trustworthy. However, when users do find information for which they are looking, they will necessarily make a value judgment on its' trustworthiness - can we trust this information to be authentic and useful?
One experience for me illustrates this point well. Around the year 2001 (roughly), I was speaking at Comdex in Las Vegas and was following an instructor who was discussing the pros and features of Windows 2000 Server. I came into the room late in his presentation. Since he was a friend of mine, I thought I'd catch up on what he was talking about in his presentations. In the last 10 minutes, he outlined how Windows 2000 Server was a "secure server platform". As soon as he said those three words - secure server platform - the room erupted in spontaneous laughter. The message from the attendees was clear: no one (at that time) thought that any Microsoft platform was secure, let alone this new Windows 2000 Server platform. My friend had to cut short his comments on Window's security system because he knew the audience wasn't going to buy it. They simply didn't find the information credible or trustworthy.
These truths about findability can be ignored, but just like economic markets will behave in a certain way whether or not you believe in capitalism, these truths will play out in your environment whether or not you choose to pay attention to them. Take them to heart and you're on your way to building a great Findability solution in your environment. Ignore them and you'll do so at your own peril.
In my coming posts, I'll explain why search applications by themselves - as illustrated by Google's marketing messages - cannot form a full findability solution. I'll also explain how to conceptualize and build out a Findability architecture for your environment and will then illustrate how a number of tools across Microsoft's platforms can work together to formulate a full findability solution.
Stay tuned.
Bill English, MVP |
|
|
|
|