Understanding Why Knowledge Workers Do Not Use Enterprise Information Portals

Organizations are pouring valuable IT resources into developing and deploying enterprise information portals with clear expectations for ROI. But what if knowledge-workers don't use the portal? What if the little spoken of truth behind the enterprise information portals is that, too often, users don't care? If users do not adopt the portal, much of the ROI is not realized; users continue to rely on alternative, less efficient methods to get their jobs done; and IT is left to maintain the portal as well as the ad hoc substitutes for a centralized data and content management system. To avoid the problem, we need to understand it.

Poor adoption is a problem that can strike any portal project. In the most general terms, it boils down to two issues: ease of use and integrity of content.

Ease of use and usability have been the focus of much debate, and we've all seen lists of the best and worst Web sites. We have been admonished at conferences, seminars and training classes to pay attention to how customers actually use a site. The customers for enterprise information portals (EIPs) are primarily knowledge-workers. They use EIPs to find information, find people and share information. We can't forget that they have alternative methods for finding information, finding people and sharing information; and if the alternatives are faster or more trustworthy than the portal, they kiss the portal good-bye.

Take a simple example. Suppose you're an engineer working on designing a component, and you have a problem with heat dissipation. You think some engineers on another team had a similar problem with different type of component, and you want to find out who solved the problem and how they did it. You could (a) search the portal for "heat dissipation problem," (b) scan old e-mail public folders looking for similar problems or (c) get on the phone and start dialing for answers. In too many cases, the most likely route to success is (c), followed by (b) with (a) a distant third. What are we doing wrong here?

First, most portal search tools are effectively useless because we don't invest the time required to configure them properly. This is the product of a "it works out of the box" mentality. Searching is complicated. If we download a search tool from the Web, run the crawlers and start firing off queries such as "heat dissipation problem," we'll get hits – all four thousand of them. The first step in a successful search is finding content that meets the search criteria. The second, and often forgotten step, is organizing it in such a way that users can find what they really need. This requires categorization and taxonomies, and they take time to develop. It also requires careful attention to meta data which is the foundation of parametric searching (e.g., restrict searching to documents written by a particular author, between specific dates and document type). The problem is not with the search tools (sometimes); it is with how we use them.

A related problem is making sure we provide access to information wherever it may be. Enterprise search cannot be restricted to portal content; it must include shared network drives, public e-mail folders, document management systems, industry-related sites and partners' Web sites. Search is now much more difficult; however, the point is to give our customers, the knowledge-workers, what they need – not just what is easy to deploy. We need to be careful not to fall into the trap of checking a list of portal requirements and assuming we are finished. The work to create a usable system has actually just begun.

A second cause of poor adoption is a lack of content integrity. In some cases, users do not believe what they need is actually accessible through the EIP. A comprehensive enterprise search system addresses that problem. A more subtle and challenging problem is the sense that knowledge-workers cannot get the real story from the portal. There may be best practices, case studies, system documentation and project reports, but how accurate are these? Have they been sanitized so they are closer to marketing case studies than to logs of project histories and decision-making processes, complete with wrong turns, mistakes and failures? Threaded discussions are important for collaboration during a project, but they are also valuable as records of issues that were confronted by teams and how they dealt with them. The more frank the discussion of decision-making processes (e.g., why was component X used instead of Y?) and mistakes along the way, the more likely we are to build trust in the EIP.

Build it and they will come is not a sound design strategy for enterprise information portals. We need to know what kind of information knowledge-workers want, where it is located and how to capture it. If users can find what they need and trust what they find, then users will adopt EIPs, IT will obtain its ROI and the emperor will finally have something to wear.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access