/
De-Mystifying Search Implementations De-Mystifying Search Implementations

De-Mystifying Search Implementations - PowerPoint Presentation

pasty-toler
pasty-toler . @pasty-toler
Follow
396 views
Uploaded On 2016-10-20

De-Mystifying Search Implementations - PPT Presentation

Why do a search project in the first place How do good projects go bad If so many firms have done these projects arent there best practices What internal resources do we need for the project ID: 478504

requirements data document search data requirements search document responsible client amp fireman infrastructure design sources company project technical content

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "De-Mystifying Search Implementations" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

De-Mystifying Search ImplementationsSlide2

Why do a search project in the first place?

How do good projects go bad?

If so many firms have done these projects, aren’t there best practices?

What internal resources do we need for the project

?What can a firm do to prepare for a search project?What is the best scope for a first rollout?How do we avoid going off the rails?How standard is standard? What if we are different to other firms?

Today’s FocusSlide3

Knowledge management:

Find my documents and email

Find examples from my colleagues and understand their experienceSee content in contextService delivery:Respond to RFPs

Staffing and pricing

Build search apps:Electronic matter fileConflict checkingWhy do a search project in the first place?Slide4

Scope, scope and

scopeBad data

Resourcing constraintsBelief in one’s fundamental uniqueness and that of your firm

Ignoring your own past project

historyHow do good projects go bad?Slide5

Take a

phased approachUnderstand scope up front

Don’t over-designPerfection is the enemy of the goodCommunicate transparently

Manage rigorously

Aren’t there best practices?Slide6

Sample Project PlanSlide7

Infrastructure Team

Infrastructure Manager – will be responsible to support project timelines for sizing, procurement, and setup of hardware for search

SAN engineer – Will be primarily responsible for setting up SAN storage for search implementationInfrastructure engineer

– Will be responsible for providing input for sizing; will procure hardware based on recommendations from Fireman & Company and Recommind; will be responsible for setting up hardware, installing operating system, granting access to Fireman & Company team, etc.

What Internal Resources Do We Need for the Project?Slide8

Application Team

Application Manager – will be responsible to support development needs for search; will be responsible to identify development resources needed for internal development pieces (i.e. SQL view); will be responsible to identify key IT liaisons for each data sources

DM IT resource – will provide access to DM library and support integration needs; will be responsible to monitor DM system for performance impact as part of full crawl

Wall Builder IT resource

– will be responsible to provide stored procedure that will return all restricted clients and client matters for a given user. Fireman & Company will provide a standard template, but Client IT will be responsible to update and provide accurate scriptsExample: Client IT RolesSlide9

Application Team

Application development IT resource

– will be responsible to provide SQL views of data fields identified as part of requirements for people, clients, and matters; data could be retrieved from multiple sources (i.e. HRIS, InterAction, Elite, etc.

); Fireman

& Company will require that all data for Expertise and Matters tab of search will be provided in SQL viewElite IT resource – will be responsible to grant access to Elite system for crawling of time notes; will be responsible to provide guidance for crawling of information (i.e. environment of Elite)SharePoint IT resource – will be responsible to grant access for search; will need to support mapping of content types in SharePoint to content types defined by Recommind

Example: Client IT RolesSlide10

Focus on DATA up-front!

Data source management is often not focused on the impact of data integration

Firms merge, but data Band-Aids persistSecurity by obscurity is a persistent risk

What can a firm do to prepare for a search project

?Slide11

Initial risk assessment: What are the key risks and dependencies for the target data sources: DMS, financials, HRIS, CRM, web site, file shares, etc.

Preparation:

Identify key data stewards for each system

Identify list of validations (intra/inter sources)

Draft list of data outputs needed to begin analysisData Integrity StepsSlide12

Analysis:

Identify key metadata fields per data source

Confirm code/value combinations for each data source

Understand cross data source dependencies

Look at impacts of historical dataLog data issuesRemediate issuesData Integrity StepsSlide13

DMS Data ExampleSlide14

People Data ExampleSlide15

Start with transparency; no question is too obvious and no detail is too insignificant

Our goal is to reduce the risk of misunderstanding: “I thought you were going to…”

All parties need a clear understanding of scope, roles and responsibilities

What is the best scope for a first rollout

?Slide16

You want to start as close to out-of-the-box as possible

Everyone thinks they are unique; you’re not as unique as you think you areRemember your users – the project team is much more sophisticated than the average end-user

It’s better to roll out quickly, on-time and on-budget, and then move to stage two…

Start with the BasicsSlide17
Slide18

Example: In-Scope Data SourcesSlide19

Requirements Definition

+

Functional and Technical Designs How do we avoid going off the rails

?Slide20

Document the content size (number of documents and average size of document) from all data sources being considered for the search implementation (include projected growth for system that will be utilized for Technical Infrastructure Design)

Document the Technical Infrastructure Design that identifies the environments and specifications for each environment based on the content analysis and additional requirements from

the firm

Document the functional requirements (including a final list of all data sources) for the Decisiv Search implementation

Document/diagram the wire-frames for the Decisiv Search implementationYour to-do listSlide21

Example: BRD in the SOW

Description

Fireman & Company will work with client team in the definition of system requirements and design. The areas of focus will be limited to:

Technical Infrastructure Design

Functional RequirementsWireframes for tabs of Decisiv SearchDeliverables

Deliverable #2: System requirements and design:

Hardware sizing analysis

Technical infrastructure design

Functional requirements

Wireframes design

FileShare

analysis and recommendation

Acceptance Criteria

Document the content size (number of documents and average size of document) from all data sources being considered for the Decisiv Search implementation

This will include projected growth for system that will be utilized for Technical Infrastructure Design

Document the Technical Infrastructure Design that identifies the environments and specifications for each environment based on the content analysis and additional requirements from Client

Document the functional requirements (including a final list of all data sources) for the Decisiv Search implementation

Document/diagram the wire-frames for the Decisiv Search implementation

Document the recommended approach for integrating

FileShare

content into Decisiv Search and the overall user experience

Client Business Lead, Application Services Lead and Infrastructure Lead shall evaluate the deliverable for completeness, consistency, and accuracy.

Slide22

Technical Approach

The requirements definition phase provides an effective way to define the system requirements necessary to meet Client’s needs. These documented requirements will provide the foundation for subsequent design tasks. To complete the requirements phase, Fireman & Company will perform the following:

Fireman & Company will work with Client Business Lead and Client Project Manager to identify key firm resources who will be involved in the requirements definition. Resources from Client will be expected to contribute to the requirements gathering tasks, but Client Business Lead, IT Application Services Lead, and Infrastructure Lead will be responsible for finalization of the requirements with Fireman & Company.

Fireman & Company will conduct focus groups/requirement gathering sessions to get input from KM, IT, and other firm resources as identified by the Client Business Lead.

Fireman & Company will define and document the functional and system requirements for the solution including:Identification and final list of data sources that will indexed for the Decisiv Search implementationDocument the current content size and project the growth of content for each data sources.Document technical infrastructure. This will include sizing, storage, and processor needs for Development and Production environments.

Determine approach for crawling of data for Matters and Expertise. Fireman & Company will work with Client to assess bringing the matters and people data from various sources into a single view for Matters and a corresponding view for People.

Wireframe the documents, matters and people modules. This will include search results, facets/filters, and previews of the three modules.

Document what features/functions of the Decisiv Search will be implemented.

Document customizations requested by Client.

Identify Key Risks/Issues from requirements gathering process

Review and obtain sign-off for functional requirements, wireframes, and technical infrastructure design with key Client

stakeholders

Example: BRD in the SOWSlide23

[

Sample document]

Example: BRDSlide24

Hardware

sizing analysis

Technical infrastructure design

Functional

requirements Wireframe designFunctional test planCritical DocumentsSlide25

Founder and President

Fireman & CompanyJoshua.Fireman@firemanco.com

Rick Krzyminski

Knowledge Management Director

Baker, Donelson, Bearman, Caldwell & Berkowitz, PCrkrzyminski@bakerdonelson.com

Joshua

Fireman