The way in which the installation and implementation of the search application is conducted will be very specific to a particular company. The milestones for an open-source project will also be somewhat different to those for a commercial application. In this chapter a distinction is made between installation and implementation. Installation covers the provisioning and testing of servers and networks, loading all the modules of the search application, checking that user authentication is being managed correctly and undertaking User Acceptance Tests (UAT) that confirm that the base performance criteria are being achieved on a test collection.
Implementation is the process of extending the application to work on live servers and content, and moving the acceptance testing to the search support team and a small group of testers. Overall this could take at least a month to achieve and may be longer with more complex federated search implementations.
Installing and implementing an enterprise search application is a complex project with perhaps forty or fifty individual work packages. There will be little or no previous experience of installing enterprise search so this project calls for the best project manager the organization employs or hires. The availability of this project manager will decide when the project can begin, and of course the project will begin perhaps one or two months before the software arrives as the vendor begins the task of fully understanding the content, information architecture and security management environment.
Search implementation projects are characterized by a fairly large number of short-duration work packages that have a lot of interdependencies. Every dependency is a risk and excellent risk management is essential if the project is going to deliver to schedule and objectives. There are many different approaches to project management, and a popular methodology is Prince2. However organizations fail to recognize that a project can be fully compliant with the Prince2 methodology and still fail to deliver the expected outcomes. It is not just about writing a very detailed Project Initiation Document (PID) but having the experience to include all the relevant details. Otherwise comparison with the PID will not flag up issues that need urgent attention.
Vendors will have their own approach to project management and at the earliest opportunity there should be a discussion about how the vendor and customer project plans are going to be integrated into a common plan.
At the commencement of the project the vendor will identify information and support that they require from the customer. This could include a working area with secure storage, remote access to the customer network and the servers that will be used for the application, and content for indexing. The list will be quite long and a failure on the part of the customer to deliver to agreed schedules could have some significant knock-on impacts on the project because of the dependencies between the work packages. Many vendors and system integrators are small companies and are working on multiple projects so a delay of a week in providing a test sample of content could extend the project by several weeks.
The big question is whether to go for a hard launch (switch off the old and switch on the new) or a soft launch in which both applications are available. The factor that shapes the roll-out plan is how much training and support resource is available. If there is a significant upgrade in capability compared to the current application then users will need support to get the best of the initial version. The initial group of users will also be a test group, so it is not just a question of supporting their use of the application but collecting feedback on how to improve the search experience.
The launch plan also needs to take into account the business cycle. Expecting users to spend time learning the new search application just as the annual business planning cycle starts is probably not a good idea. There could be other upgrades and system launches taking place which should also be taken in to consideration. In public companies the communications team will have more important priorities to deal with than the launch of a new search application.
Even in quite large vendors the team responsible for installing the application is quite small, as specialist skills are needed to cope with the intricacies of the enterprise architecture of the customer. The availability of this team has to be matched to a period of stability with both the content repositories and applications that are going to be indexed by the search application. What might seem to be quite an innocuous upgrade could have a major impact on connector performance.
The overall schedule is then fixed by two dates.
The earliest date that the project can start is when:
Project manager and search support team in place
All necessary hardware and access permissions have been established
Work packages have been agreed and respective roles of vendor and customer have been established
A full content scope and audit has been completed
Vendor and customer are confident that security management issues have been addressed
A communications plan is in place for all stakeholders
The launch date is set by:
When enough content and functionality is available for users to have a good initial search experience
Usability tests have smoothed out the initial rough edges to the user interface
There are enough resources to support the launch, including training and a Help Desk and analysis of the initial set of search logs
The launch will not take place when another business application is being launched or the business cycle means that users will not have either the incentive or time to make use of the new search application
There is still enough time to sort out any major problems before a full release to all employees is undertaken
The chances are that there will then not be enough time to undertake all the work needed to deliver the required search experience, so an iterative approach to project scheduling will be required. The point is that beginning the project without being fully prepared and launching the application without adequate content, functionality and support is not to be recommended. Nothing travels faster than news that the launch of a new application, especially one that will be used by the majority of employees, has all the hallmarks of a disaster.
There is a lot to learn both about the process of search and the technology of the new search application. The worst possible approach is for the vendor team to work in isolation from the search support team. The team not only needs to understand what the search application can offer but also a good knowledge of how the search application works. Even more important is a clear understanding of what the search support team can change without needing to pay for additional consulting days from the vendor.
Forget all about search needing to be intuitive. That may be partially true for end-users but certainly not for the IT team working on the installation and implementation, and for the search support team. Search is complicated and there may well be a requirement to teach about how search works before moving on to the specific elements of the search application that is being implemented.
There should be an initial one or two day training course for the search support team and the project team on the architecture and functionality of the search application so that issues that arise in the course of the implementation can be put into context. Just providing a pile of documentation is not useful.
In addition to this introduction to the project a meeting with a reference client whose implementation has been carried out by the same project team is very valuable. If the vendor is reluctant to come up with a reference client then a proposal to use the LinkedIn Enterprise Search Professionals site to see if any customers have views on the implementation process they would like to share should result in a change of heart. This is so important that it should be written in to the contract. It is all about ensuring that there is a high level of commitment and competence among the vendor project team members.
Two elements of the implementation project have the potential to be major show stoppers and if they are not managed well could jeopardize the success of the project. The first is that the content is as it was described in the content audit and the second is that the security model is as it was described in the initial statement of requirements. The vendor will have carried out some due diligence prior to confirming the contract price but will almost certainly not had the time or support from the organization to do a deep dive into either of these two areas. They represent risks of the highest level of impact on the project and solving problems that were not highlighted in the initial presentations will not only be costly but could mean that the search application cannot deliver to the expectation of users and stakeholders.
The potential problems arising from a failure to have undertaken a full content audit and a full disclosure of security management issues will be especially significant when the plan is to extend the search across multiple applications.
Because of the potential impact of content and security issues it is essential to start indexing content at the earliest possible opportunity, even if it is with only a base configuration of the software and on open-access collections. This approach will have the benefit of showing all the stakeholders that the investment in the search application will pay off.
There is little in this book about user interface design. This is not because it is unimportant but because there are many excellent books on the subject, notably those by Marti Hearst, Peter Morville, Tony Russell-Rose and Tyler Tate, and Greg Nudelman.
The challenge is summed up very concisely by Tony Russell-Rose:
The results page plays a crucial role in the search experience, conveying to users a response to their information needs, and engaging them in a dialogue that guides them along their information journey. By drawing on a broad repertoire of layouts, views and configurations, it can support a variety of search modes and contexts. And even when there are no results to return, it can still facilitate productive exploration and discovery.
When a project schedule slips the work packages that almost always get cut are the usability tests on the user interface design. Usability tests are as important as any other element of the search implementation process, and setting high standards for the tests at the implementation stage provides benchmarks for tests undertaken later in the life of the search application when new applications or new facets are added to the search scope. Accessibility is also important to test. This is the extent to which users with a range of visual and physical disabilities are able to use the search application. Often the terms ‘usability’ and ‘accessibility’ are used interchangeably but they refer to different aspects of the user experience.
Effective disaster recovery is essential in a search application because there is a significant danger of content being crawled but not indexed. It is important to actually test the disaster recovery procedures under real-life conditions. Often search disaster recovery comes down the bottom of the list of priority applications to restore. However a search application will still be able to identify information from its index even if the core application is not running.
The implementation process will touch a lot of other applications and the team on the IT Help Desk need to be involved at the earliest possible opportunity. The technical team from the vendor needs to talk in technical jargon not only to the Help Desk team but to other IT specialists. Using the project manager to relay messages is going to confuse rather than communicate. Servers in particular tend to have shorthand descriptions linked to a Configuration Management Database. One of the few pleasures that IT managers have is devising up with naming conventions that are unambiguous to internal staff but have no meaning at all to external staff to reduce any chance of inadvertent or deliberate hacking. Every server that might somehow be affected by the search implementation needs to be identified. This is especially important when indexes and repositories are maintained on a remote and/or virtual basis. The name that Corporate IT uses for a server in India could be very different from its local description. This should not be the case but all too often it is.
Good search needs good metadata. It is as simple as that. Part of the implementation plan should be about not only how metadata is going to be added in the future but how legacy content is going to be enriched by metadata. The need for this work will quickly become obvious as the initial implementation crawls, indexing and queries are undertaken.
At a minimum content needs to have:
A good title
A good file name
A date that defines when the content was released for use
Correctly spelt names of the authors
In addition a good summary will be a source of keywords in a defined field, and probably less of an effort to add than working through a lot of drop-down lists in a CMS. This may seem a somewhat heretical view from an information scientist but what might be ideal and what can be accomplished in a very busy and probably under-staffed department are two different things.
From the moment the contract is agreed a communications plan needs to be implemented, which means that it should have been developed well before the contract is signed. There is a role here for Internal Communications to use every possible communications channel available to spread the news about the objectives and progress of the project. The communications plan needs to include ways in which employees can have concerns answered and be able to make contributions to the progress and outcomes of the project.
This level of communications activity may well not have been used for the new finance system or the new customer relationship management system but these applications touched only a relatively few employees. In the case of search everyone with access to a desktop pc, a smartphone and/or a tablet will be looking to assess the outcomes of the investment at the earliest opportunity.
If the installation and initial implementation are not undertaken with a high level of care and resource allocation the value of the investment in the application will be jeopardized. Implementation planning should be started at the commencement of the project and not at the point of discussing the contract. The creation of test collections is an important element of benchmarking technical and end-user performance.
You'll find some additional information regarding the subject matter of this chapter in the Further Reading section in Appendix A.