Flexible intranet search does not have to mean a single search interface

Trying to provide a simple, flexible search capability for your organization’s reams of historical documents? Using a project process that generates the typical stacks of documents, databases full of status reports and issues, and other “stuff”? It’s important to think about the knowledge we are generating, and the best way to capture that knowledge – and not worry too much about how we’re going to search through those deliverables.

There is no one way to capture / store different kinds of knowledge, so there won’t be a single method to do the search. This is an important consideration; there must be some sort of search capability. It’s just that we don’t have to overthink the search form, and try to engineer something that will be a one-step search process.

A big mistake would be to try to capture all information in a single [type of] “container” – say, a Domino database or a series of MS Word documents – just because we know how to build that search, or know how to present a single search face. Some examples:

Office Documents …

• Project Charter, Requirements, Documentation (in MS Word)
• Budgets, Cost / Benefits, Sample Reports (in MS Excel)
• Meeting presentations, status updates (in MS PowerPoint)
• Diagrams, process maps, etc. (in MS Visio)
• Project Plans and schedules (in MS Project)
• Manufacturer’s user and technical documentation (in Adobe PDF)

… can be published to a shared folder, and indexed / searched using MS Index Server.

SQL data …

• Project charter / overview (from a PMO database)
• Status reports / blog entries
• Discussion forums
• Issues and trouble tickets
• Content in a corporate intranet

… can be searched using Full Text Catalogs

Notes data …

• Workflows
• Discussion databases
• Notes document history

… can be searched using Domino Search

Other web data …

• Wiki text
• Web-based documentation
• Content in a corporate intranet
• External links

… can be searched using MS Index Server.

The trick could be in how we present the search “function”. In the various groups I’ve worked with, we implemented different flavors of a web-based search tool that presented a “front-end” to the search process.

Consider a typical web search form, prompting you for the text you want to find. Instead of offering a single button, offer buttons to search Documents, SQL Data, Notes Data, or Web Stuff. Or, present a series of check boxes to indicate which repositories are to be searched, and then the web page could return multiple result sections.

Key to remember – the critical, difficult thing we’re trying to do is capture knowledge in a format that is easy to get knowledge in to, and is easily searchable. It’s important that we provide a search capability, but if we make it difficult to gather the information, there will be nothing to search.