What’s Your Search Story?
Recently, I asked a list of colleagues for their thoughts on building the business case for search, since a client was trying to get funding for a project. The basic response was: “business case? We scoff at such silly questions. Search is infrastructure. How would you make a business case for email these days?” I thought to myself: Am I missing something?
In my opinion, the infrastructure response reflects the fundamental problem with how people are conceptualizing enterprise search and how it needs to be designed, built, and deployed. Search can certainly be considered infrastructure, but it still requires development and configuration to become truly useful. Content management systems and document management tools are other technologies that can be considered infrastructure, but almost nobody would just install them out of the box and expect magic. It is the application of search infrastructure to business problems that requires the same rigor that any application requires.
A successful approach to search needs to factor in integration of content tagging, best bets, faceted search, investment in federated search, and so on. You can have the basic infrastructure, but to get real value, additional investments need to be made in operations and technology.
What is “Enterprise Search” Anyway?
There are misconceptions about the nature of enterprise search and its impact in the organization. As enterprise information has grown more complex and information sources more varied, users have grown to expect a similar experience to searching on the Internet. In essence, users are looking for a “Google experience,” meaning one that delivers results reliably. It is a reasonable expectation. The question is how to get there.
At their core, search systems try to make sense of a user’s intent--using only those short ambiguous search terms that people put into the search boxes--and present the content that represents something meaningful to the user. Enterprise search adds to this scenario a variety of information sources and contexts. Imagine I asked you for information and only gave you one or two word clues, say the word “deliverable” or “proposal”, and expected you to come back with something meaningful. You'd probably want a little more of a clue: Tell me more about the types of things you need. What are you doing? Who is this for? Who are you for that matter?
If we know something about our user and what they are trying to accomplish, we can do more to present more meaningful search results. Through planning and consideration of user needs, we can give people the ability to discover more specific, more relevant and more valued content than if we just plug search in and consider it infrastructure.
Add to the mix the current trend toward using search as a mechanism for surfacing structured data from business intelligence and transactional systems. In these emerging applications, unstructured queries are being mapped to data from ERP systems, sales management tools, accounting systems and other non-traditional “search” resources. Therefore, the value of enterprise search lies in its ability to provide simple, intuitive ways to consolidate information sources, whether structured or unstructured, and surface Information assets in the correct context and at the right time.
Bridging the Gap in Perspectives
In order to get an enterprise search project funded and supported, you need to change how your stakeholders think about search. Thus, part of your search story needs to expand the concept of search from “putting a term in a search box” to a more holistic analysis of information access and functionality around specific business problems.
The question business owners usually ask is: Why do I need to do more than buy a search engine? Or, why do I need an additional or different search engine? Or better yet, why should I invest in building different search capabilities for different applications? Shouldn’t I just be able to get a really good search engine and expect it do what we need?
In your business case, you need to describe how search--the application--can solve the problems that search--the generic utility--cannot. To help stakeholders make the leap from search as a utility to an application, you will need to understand work tasks and processes, user scenarios and use cases and describe how leveraging advanced capabilities of search tools will address specific pains. These advanced capabilities include faceted search, entity extraction, auto classification, semantic search, term disambiguation, taxonomy integration, and federated search. Search tools are more powerful and feature-rich than ever, and taking advantage of that power takes more than plugging a box into the wall.
The Making of a Business Case
The bottom line is this: Search applications need to be done right. There is no “one size fits all”. Well-executed search applications make it easier to zero-in on information because they leverage the ways that users think about work tasks and the specific artefacts needed to perform those tasks. When seeking information, users don’t think precisely--that is why a search application needs to do the work for them. Getting this right will reduce information management costs by reducing redundancy and manual processes associated with information discovery.
Such a project will take time, money, and organizational resources, and will, therefore, be vying with any number of projects all clamoring for limited resources. It’s critical to have a solid business case for review by the executives who fund programs and projects. Managers are skeptical; they’ve heard it all before--especially from technology vendors and IT departments. You must have your “search story” prepared, complete with evidence and justification for its place within business applications in your organization. You need to help people understand core concepts around search and how leveraging those concepts in your specific circumstances will solve the problem. If there is a valid and credible story to tell, then you need to get the details of the business problem and lay out a concise, realistic plan of attack.
The business case captures the business reasons but also keeps a technical context for a specific project. After all, the technology is the enabler, so we can’t ignore it or “assume a search engine”, to paraphrase the punch line of an old joke (An economist on a desert island needs to open a can of food… “first, assume a can opener”.)
A business case typically includes:
- Description of the business problem, put into terms of specific impact on a functional area or audience: customer service, product development, ecommerce, etc.
- Types of artefacts and repositories that need to be accessed
- A current scenario that illustrates the “day in the life”--the types of problems people are facing and how it impacts their job, efficiency, customers, etc
- A “better world” scenario (notice I did not say perfect world)
- High level description of proposed course of action or solution (even if the course of action is to develop the solution or explore options)
- Costs of various options (including the option to not do anything), expected timeline, deliverables
- Anticipated benefits, including anticipated quantitative benefits (impact on some measurable baseline) organizational resources required (stakeholder interviews, project management resources, IT support, etc)
- Project risks and mitigation strategy
As you build your business case, it is essential to take the time to consider the specific problem to be solved as opposed to generic benefits of “improved access to information.” If there are fundamental issues affecting the flow of information and knowledge discovery within your organization, then this is the time to surface those issues with supporting evidence. Take the time to learn more about what is going on “behind the curtain” and build a solid business case for funding, resources and organizational attention.