Federated search roadmap: Part I - Stating the business case

This roadmap series raises and addresses a number of issues that prospective customers of federated search solutions will encounter. It is based on the outline I published last week; I’ve made a couple of changes to the outline to reflect reader input. Here is the new outline:

1. State the Business Case
   a. Who wants the solution?
   b. Why?
   c. Who is paying?

2. Identify Benefits
   a. What are you expecting to save?
   b. What are you expecting to get?

3. Define Requirements
   a. Brainstorm requirements
   b. Create checklist of things to consider
     i. Solicit stakeholder requirements
     ii. Identify user Requirements
     iii. Determine technical Requirements
   c. Produce a requirements document

4. Create evaluation criteria
   a. Base criteria on requirements
   b. Gear criteria towards simple vendor responses
   c. Produce criteria evaluation document

5. Perform initial vendor screening
   a. Circulate the criteria (perhaps as an RFI) to chosen vendors
   b. Ask the hard questions
     i. Is vendor’s target market aligned with your organization?
     ii. Can vendor connect to your unique data sources?
     iii. Does the vendor have the resources to support, maintain, and extend your solution?
     iv. Do the vendor’s references check out?
   c. Assess responses; narrow the list of potential vendors

6. Perform rigorous evaluation of vendor offerings
   a. Request pilots if appropriate
   b. Rigorously test pilots
   c. Select solution

7. Deploy solution
   a. Plan the deployment
   b. Schedule the deployment
   c. Educate stakeholders
   d. Evaluate a test deployment
   e. Deploy live system
   f. Celebrate

8. Evaluate system in production
   a. Watch and monitor performance
   b. Get user feedback
   c. Identify post-production issues
   d. Correct issues

Stating the business case is the very first step of this long journey and it is a critical step. Ask yourself these questions:

1. Why does management want a federated search solution?
2. Who are the stakeholders and how do they stand to benefit?
3. What is the broad problem I’m trying to solve?
4. How does federated search fit into a greater vision for my organization?
5. Is there sufficient commitment to spending money? Is it clear what the funding source is?
6. Are all the key decision makers in alignment with the decision to purchase a federated search system?

It is critical for all key personnel to be aligned with the decision to move forward with procuring a solution. An organization may spend a year or longer investigating and acquiring a solution. Throughout that period the organization will face numerous challenges, some small and others large. A lack of firm commitment will greatly magnify any stress along the way.

From the perspective of the federated search vendors, lack of clarity of goals will waste much of their time and will make it difficult to respond to RFPs. This is not to say that the organization needs to be clear about what its requirements are at this first step. But, without a clear purpose it will be easy to be sloppy in getting clear in later steps.

This first step is not the time to identify detailed benefits and requirements. The organization may generally state desired benefits to users and it may very broadly state requirements but spending too much time in the details at this stage may take away from understanding the deeper motivators for finding a solution.

At this stage it is sufficient to know that users are complaining about the current solution, or that users are not getting the most value from the content you pay for, or that management wants to be competitive with other organizations in your industry that do provide federated services. It is fine to not have an idea what the best solution is; strive to understand the problem first.

If there is not consensus among key staff that a solution is desired, it may be the case that not everyone agrees that there is a sufficiently large problem or perhaps not everyone understands what federated search can and can’t do. At this stage, without diving too deeply into product features and user requirements, consider educating stakeholders broadly as to the benefits of federated search. You can accomplish this through vendor webinars, by pointing interested parties to vendor web-sites and by pointing them to some of the basic articles in this blog.

The consensus issue is a particularly important one in the library community because many librarians don’t see the value of federated search even when their users do. I’ve written about the subject here and here. Many librarians believe that users should be using the library resources (i.e. going to the native sources directly) but the reality is that a very large percent of users would rather search Google than search library resources one by one and have to learn the quirky interfaces of each. I don’t find the argument that federated search competes with library resources to be a valid one because federated search will result in better utilization of the library’s resources. And, if the solution is simple enough to use, it will keep many users from going to Google. So, if librarians don’t support the move to federated search, their attitudes will greatly strain the process. Surface, explore, and resolve their concerns as early as possible.

This early in the process is a good time to determine how much pain your organization is in. More pain will motivate you more to move. If users are unhappy, are they unhappy enough to commit to finding a solution? In what time frame? At what cost? These are things to consider early on.

What does a business case look like? Wikipedia has a good outline of the elements that go into producing one. In addition to the questions I raised, it reminds us that the business case process should ensure some critical things:

• the required issues have been thoroughly considered and documented
• sufficient information to facilitate fair evaluations of different proposals is available
• both the value and risks inherent in the proposed project are clear
• the project is sponsored by, and has the commitment of, an executive with the capability and authority to deliver the benefits
• the delivery of the outcomes and benefits can be traced and measured.

The next article will look at benefits of federated search. Benefits are not features. I believe that users care more about features than they do benefits. Identifying benefits is the next important step to a successful deployment.

If you enjoyed this post, make sure you subscribe to the RSS feed!

Tags: federated search