Copyright: LBMS, Inc. (c) 1994 v2.5


Short Cut
Package Selection - Short Cut

Package Selection

Concepts

Step PS 01  Initial Package Investigation

Overview

Adapting

Approach 1: Standard Approach

Approach 2: Alternative Approach

Roles

Entry/Exit Criteria

Task .010  Identify Potential Software Packages

Task .020  Establish Mandatory Requirements and Constraints

Task .030  Create and Distribute a Request for Information

Task .040  Follow Up with Vendors

Task .050  Conduct Initial Package Evaluation

Task .060  Review Initial Package Evaluation

Task .070  Assess Feasibility Of Package Evaluation

Task .080  Establish Approach For Detailed Evaluation

Task .090  Produce Package Investigation Report

Task .100  Inform Rejected Vendors

Task .110  Review Initial Package Investigation

Step PS 02  Package Evaluation

Overview

Adapting

Roles

Entry/Exit Criteria

Task .010  Prepare Package Selection Criteria

Task .020  Develop Request For Proposal

Task 030  Facilitate the Request for Proposal Process

Task .040  Perform Functional Comparison

Task .050  Perform Initial Data Structure Comparison

Task .060  Establish Vendor Demonstration Agenda

Task .070  Conduct Vendor Demonstrations

Task .080  Check Vendor References

Task .090  Identify Preferred Packages

Task .100  Perform Detailed Data Comparison

Task .110  Perform Process Comparison

Task .120  Evaluate Outstanding Technical Issues

Task .130  Review Evaluation Process

Step PS 03  Final Package Selection

Overview

Adapting

Roles

Entry/Exit Criteria

Task .010  Specify Customization Requirements

Task .020  Cost Customization Requirements

Task .030  Negotiate Contractual Terms

Task .040  Establish Outline Implementation Plans

Task .050  Establish Overall Costs

Task .060  Determine Cost/Benefit Analysis

Task .070  Prepare Recommendation

Task .080  Present Recommendation to Management

Task .090  Conduct Benchmark Test

Task .100  Publish Recommendation

Task .110  Inform Vendors

Task .120  Finalize Procurement Process

Task .130  Plan Implementation with Vendor


Package Selection
 	Templates

Package Selection


Step PS 01  Initial Package Investigation

Step PS 02  Package Evaluation

Step PS 03  Final Package Selection


Package Selection


Concepts
 	 	  	Package Selection

Package Selection

Concepts

The use of package software has become an established practice in many areas of the information systems industry. The major reasons for this are:

The reduced risk, cost and time frame associated with the implementation of proven solutions to recognized business needs.

The reduced overhead involved in maintaining the resulting system by procuring packages from vendors committed to their ongoing maintenance.

Although the rationale for employing package software is clear, many organizations have been disappointed with the results of package implementations. The most frequently encountered problems are:

A mismatch between package functionality and business requirements.

The level of customization required to ensure successful implementation.

Inflexibility of the package to meet the changing needs of the business.

The level of maintenance required.

An inadequate level of vendor support.

Poor vendor choice.

Amount of effort required to interface a package to existing systems.

The above problems are almost always attributable to an inadequate analysis of business needs, or a poor procedure for the evaluation and selection of a package, or both.

Package Selection has been specifically designed with these experiences in mind and provides a comprehensive approach for the evaluation, selection and installation of a package software solution.

Package Selection consists of a three step approach for the evaluation and selection of package software.

It provides a structured approach to investigation, evaluation and selection which can be integrated with the Classic Template or any of the other application development templates.

The package selection process is driven primarily by the requirements defined during the initial stages of analysis.

Once a package has been selected, the activities within the chosen application development template are used to effect customization and implementation.


Step PS 01   Initial Package Investigation
 	  	Step PS 02 	Package Selection

Package Selection

Step PS 01  Initial Package Investigation

Task .010  Identify Potential Software Packages

Task .020  Establish Mandatory Requirements and Constraints

Task .030  Create and Distribute a Request for Information

Task .040  Follow Up with Vendors

Task .050  Conduct Initial Package Evaluation

Task .060  Review Initial Package Evaluation

Task .070  Assess Feasibility Of Package Evaluation

Task .080  Establish Approach For Detailed Evaluation

Task .090  Produce Package Investigation Report

Task .100  Inform Rejected Vendors

Task .110  Review Initial Package Investigation


Overview
 	 	  	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Overview

Objectives

Identify and gather initial, high-level data from potential vendors of software packages to determine the feasibility of a package solution.

Overview

The Initial Package Investigation step involves the development of an initial request for information followed by a review of vendor responses.

This is conducted primarily to test the market and establish if a package based approach is viable.

The result of this step would normally be one of the following:

Rejection of a package implementation as a viable option, in which case the project is continued as per a normal 'in-house' development.

Selection of a short-list of packages, to be considered by a more detailed evaluation process.

Selection of one or more packages to be installed on a trial basis from which a final selection will be made.

This is usually only proposed in situations where the cost of the packages are so minimal that an extremely detailed evaluation would not be cost justified.

The decision to investigate market availability for package solutions is made in the Project Initiation stage (PI 03.010 Determine Project Approach).

This decision should include a definition of the approach to be used during the Analysis stage.


Adapting
 	 	  	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Adapting

One of two approach options is possible, depending on the overall objectives of the project and the requirements of the organization. These alternative approaches are:

Approach 1: Standard Approach

Approach 2: Alternative Approach


Approach 1: Standard Approach
 	 	Approach 2  	Adapting

Package Selection

Step PS 01  Initial Package Investigation

Adapting

Approach 1: Standard Approach

Most often, Step PS 01 - Initial Package Investigation, will be carried out in parallel with the first step of the Analysis Stage, either Systems Investigation or Requirements Definition. The option within this approach is whether or not to investigate the current system. Step AN 01 - Systems Investigation is an optional step which should be utilized when the systems requirements are based upon existing system facilities. This step will be carried out in situations where a knowledge of the existing environment is key to the success of the overall project and is of specific importance to defining the requirements for the system.

In situations where an investigation of the current environment is unlikely to be a major contributing factor to the definition of requirements or the determination of package selection criteria, the Systems Investigation step may be omitted. In such cases, the package investigation would usually be conducted in parallel with the Requirements Definition step.


Approach 2: Alternative Approach
 	Approach 1	 	Adapting

Package Selection

Step PS 01  Initial Package Investigation

Adapting

Approach 2: Alternative Approach

The Initial Package Investigation step may be conducted prior to the Requirements Definition step in situations where knowing what's available will help to determine the system requirements. For example:

The resulting package is likely to be installed without customization and will therefore drive the business requirements.

The business requirements are ill-defined and a view of the capabilities of candidate packages will assist in formalizing the user requirements for the system.

The concept with this approach is much like an iterative prototyping approach where you would need to see some possibilities before deciding on requirements. This approach should be done for low risk projects only.

If Approach 2 was chosen initially as the development approach in Project Initiation, and Risk Analysis in the later step of Project Initiation shows the project to have medium or high risk, it is recommended that the development approach be changed to the Standard Approach (Approach 1).

Another caution to using this approach is to be sure that the amount of time between sending Requests for Information (RFIs) and waiting for a response is kept to an acceptable elapsed time. If the "wait" time is going to be significant, then the Standard Approach should be chosen over Approach 2.

This alternative approach may be viable for investigation of systems where requirements are easily defined or industry standards exist, e.g.:

time card system application

spreadsheets.

It is important that the inclusion of this approach into the project plan gains project management acceptance and approval before beginning the Package Selection steps.


Roles
 	  	 	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Roles	Responsibilities

Business Analyst	Produce

Business Coordinator	Contribute

Data Resource Manager	Contribute

Documenter	Contribute

Facilitator	Contribute

Planning Coordinator	Consult

Project Board Member	Approve

Purchasing Agent	Consult

Stage Manager	Supervise

Technical Coordinator	Contribute

Vendor	Receive


Entry/Exit Criteria
 	 	 	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Entry/Exit

Inputs	Applicability

Problem/Requirement List	Mandatory

Products	Applicability

Approach for Detailed Evaluation	Mandatory

Initial Evaluation and Recommendation	Mandatory

INITIAL PACKAGE INVESTIGATION	Mandatory

Letters to Vendors	Mandatory

Package Evaluation Feasibility	Mandatory

Package Investigation Report	Mandatory

Problem/Requirement List	Mandatory

Request for Information (RFI)	Mandatory

Short-List of Packages	Mandatory


Task .010   Identify Potential Software Packages
 	 	Task .020 	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Task .010  Identify Potential Software Packages

Identify vendors which supply package software applicable to the area under investigation. Potential sources for data include but are not limited to:

published software surveys

software directives and previous software purchases

trade shows and trade journals

application software catalogs

consultants

business publications and business conferences.


Task .020   Establish Mandatory Requirements and Constraints
 	Task .010 	Task .030 	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Task .020  Establish Mandatory Requirements and Constraints

In order to facilitate the initial evaluation, those requirements that must be satisfied by the package, should be defined. For example, an accounting package must provide for security and auditing capabilities.

Constraints which were previously defined in Project Initiation should be expanded to include package constraints. An example of a technical constraint is that the package must run on IBM hardware under MVS.

These requirements and constraints will be used as initial criteria to evaluate the vendor responses to the Request For Information (RFI) and to determine those packages which are to be short-listed for further investigation.

Some factors to be considered in establishing these requirements may include:

Vendor stability

customer base

size

location

financial stability

time in business

Support Capabilities

customization capabilities and services

mechanisms for ongoing maintenance (may include mean time to repair or established processes for upgrades)

availability and types of training

post sales support facilities (may include number of available support personnel)

development/delivery history

users group

Product Features

technical operating platform

mandatory features

compliance with internal standards

functions to be supported (may include response time for key transactions)

integration with other applications software

Commercial Terms

pricing

contractual requirements (such as requirements for confidential or non-disclosure agreements when proprietary information may be disclosed to the vendor).

Whenever possible, the requirements should be defined in precise terms (e.g. vendor must have been in business for over 5 years), such that the subsequent steps of evaluation may be effected in a clear and unambiguous manner.


Technique:	Critical Requirements Analysis


Task .030   Create and Distribute a Request for Information
 	Task .020 	Task .040 	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Task .030  Create and Distribute a Request for Information

Produce a Request For Information (RFI) document based upon the deliverables from the Project Initiation stage. This document should include the following information:

organizational and business setting

overview of the scope of the proposed system

overview of functionality required

mandatory requirements and constraints

glossary (to ensure understanding of terminology)

include a covering letter outlining the following:

reason for the RFI.

types and levels of data required in response to the RFI (e.g. written response, product descriptions, annual/financial reports, company overview, etc.).

contacts within the organization and procedures for communication by vendors.

Distribute the RFI to those vendors previously identified.


Task .040   Follow Up with Vendors
 	Task .030 	Task .050 	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Task .040  Follow Up with Vendors

Vendors should be contacted to ensure that the RFI has been received. Some time should be dedicated to answering questions from vendors and ensuring that appropriate information is provided in response to the request.


Task .050   Conduct Initial Package Evaluation
 	Task .040 	Task .060 	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Task .050  Conduct Initial Package Evaluation

Each response to the RFI should be evaluated in detail against the previously defined mandatory requirements.

It is usual at this time for the evaluators to identify features available in one or more packages that would be useful to the organization, but have not been included in the initial requirements.

These features, if justifiable, may be added to the requirements list. However, care should be taken not to predispose, bias or incorrectly focus the evaluation process.


Task .060   Review Initial Package Evaluation
 	Task .050 	Task .070 	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Task .060  Review Initial Package Evaluation

Review the results of each evaluation, in order to establish the subsequent action to be taken. Based upon this review, classify the package into one of the following categories:

Rejected	mandatory system or vendor requirements not met or addressed, no further evaluation justified

Standby	packages which meet a reasonable subset of requirements may therefore be reconsidered based upon a re- evaluation of requirements

Proceed	Short-listed for further evaluation.


Task .070   Assess Feasibility Of Package Evaluation
 	Task .060 	Task .080 	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Task .070  Assess Feasibility Of Package Evaluation

The overall results of the initial package evaluation process should be assessed based upon the number of packages contained in the short-list.

The objective of the initial evaluation is ideally to identify from 2 to 6 packages to be the subject of further detailed investigation.

In situations where this is not achieved, the following should be considered:

large number of packages seem to be worth further investigation:

re-evaluate and tighten or expand the mandatory requirements such that only a limited number of candidates are selected.

no packages seem to be worth further investigation:

re-evaluate or construct the project scope such that superior products, offering a subset of the required functionality may be short-listed

re-evaluate the requirements to ensure that they are truly mandatory

abandon the package evaluation process for an in-house, custom approach to development

identify additional vendors.

The Project Board should be informed of the results of this assessment.

Based upon the results of this task, a subset of the Initial Package Investigation step may be repeated.


Task .080   Establish Approach For Detailed Evaluation
 	Task .070 	Task .090 	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Task .080  Establish Approach For Detailed Evaluation

If it is determined from the initial evaluation that a more detailed investigation is justified, then the approach to be followed should be planned and agreed.

This should include the selection of team members within the project or team members to be added to the project to conduct the detailed investigation.

This team should be multidisciplinary and include both business and systems experts who are familiar with the area under investigation.


Task .090   Produce Package Investigation Report
 	Task .080 	Task .100 	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Task .090  Produce Package Investigation Report

A brief report should be prepared outlining the:

mandatory requirements

vendor packages reviewed

results of the evaluation

recommendations and/or proposed approach for further investigation

projected cost range.

Copies of this initial report should be sent to Purchasing and Legal Departments. It may be advisable to contact Purchasing at this time and agree their role in the package selection.


Task .100   Inform Rejected Vendors
 	Task .090 	Task .110 	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Task .100  Inform Rejected Vendors

Vendors whose offerings have been rejected should be informed. It is often valuable to explain the reasons for this decision in order to ensure that vendors have provided all available information.


Task .110   Review Initial Package Investigation
 	Task .100 	 	Step PS 01

Package Selection

Step PS 01  Initial Package Investigation

Task .110  Review Initial Package Investigation

The results of this step should be reviewed with the Project Board and authorization to continue the investigation or redirect the project should be obtained.


Step PS 02   Package Evaluation
 	Step PS 01  	Step PS 03	Package Selection

Package Selection

Step PS 02  Package Evaluation

Task .010  Prepare Package Selection Criteria

Task .020  Develop Request For Proposal

Task 030  Facilitate the Request for Proposal Process

Task .040  Perform Functional Comparison

Task .050  Perform Initial Data Structure Comparison

Task .060  Establish Vendor Demonstration Agenda

Task .070  Conduct Vendor Demonstrations

Task .080  Check Vendor References

Task .090  Identify Preferred Packages

Task .100  Perform Detailed Data Comparison

Task .110  Perform Process Comparison

Task .120  Evaluate Outstanding Technical Issues

Task .130  Review Evaluation Process


Overview
 	 	  	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Overview

Objectives

To obtain detailed proposals from short-listed package vendors and to conduct an evaluation of the fit of the selected packages with the predefined requirements for the system.

Overview

This step produces a final short-list of vendor packages which are worth further consideration based upon initial and detailed evaluation processes.

The requirement to perform this evaluation is established as an integral part of the Business System Options step of the Analysis stage.

The initial activities within the Required Systems Specification step of the Analysis stage are used to prepare a detailed set of selection criteria which form the basis of a Request For Proposal (RFP).

The Request For Proposal is issued and the resulting bid from each vendor is evaluated and a limited number of packages (usually two) are chosen for final evaluation and selection.

In cases where packages fail to meet the selection criteria established for the system, an `in-house' approach to development may be resumed by continuing the Required System Specification step.


Adapting
 	 	  	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Adapting

The interrelationship between the Package Evaluation step and other application development activities is illustrated below:


Roles
 	 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Roles	Responsibilities

Business Analyst	Produce

Business Coordinator	Consult

Data Resource Manager	Consult

Database Manager	Consult

Planning Coordinator	Consult

Production Support Analyst	Consult

Purchasing Agent	Consult

Stage Manager	Supervise

System Designer	Consult

Technical Coordinator	Consult

Technical Support Analyst	Consult

User Representative	Approve


Entry/Exit Criteria
 	 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Entry/Exit

Inputs	Applicability

Initial Package Investigation	Mandatory

Products	Applicability

Package Comparison	Mandatory

Package Data Structure Comparison	Mandatory

PACKAGE EVALUATION	Mandatory

Package Functional Comparison	Mandatory

Package Selection Criteria	Mandatory

Request for Proposal (RFP)	Mandatory

Short-List of Packages	Mandatory

Vendor Demonstration Agenda	Mandatory


Task .010   Prepare Package Selection Criteria
 	 	Task .020 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Task .010  Prepare Package Selection

Assemble the criteria directly from the results of the initial phase of the Required System Specification step , including:

Functional Criteria

Function Catalog supplemented where necessary with details from the required Data Flow Diagram and Problem/ Requirement List

details of the required inputs/outputs for each function where available

special processing characteristics including transaction volumes, response times, etc.

Data Criteria

entities and relationships required

keys for each entity

major data items with associated attributes

special data requirements including verification and validation, data volumes, etc.

Process Criteria

the transactions required to support desired business processes

operational requirements

Interface Requirements

Identify sources and recipients of data between the package and any existing automated or manual systems. Separate transactions will need to be defined for each interface to existing automated systems.

Audit and Security Requirements

Determine the selection criteria to be used

Review the specifications of each of the above areas and identify product features which would have to be in place to support these requirements.

This, in essence, will provide a more detailed view of requirements. These product features will become the package selection criteria.

For example, there may be a requirement that the system should be "user friendly" and require minimal user training time. Software features which could satisfy these requirements are system tutorials and on-line help screens. These features become package selection criteria.

Weight the selection criteria to be used

In order to facilitate the evaluation, each of the criteria should be weighted according to the following scheme:

1	Mandatory
2	Key
3	Desirable
Some of these criteria may have to remain loosely defined, however, it is best to rigorously identify features which correspond to mandatory requirements


Technique:	Critical Requirements Analysis


Task .020   Develop Request For Proposal
 	Task .010 	Task .030 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Task .020  Develop Request For Proposal

The Request For Proposal (RFP) is a document issued to short-listed vendors in order to obtain specific information to carry out a detailed investigation of those vendors' offerings. This document will typically include data developed during the detailed definition of requirements, such as:

Business/Organization background

Required Data Flow Diagram

Required Data Model

descriptions of required functions

outline specification of requirements and constraints (derived from the problem / requirement list)

Package Selection Criteria.

Questionnaire

Where additional information or a precise response to specific questions is required, the requirements should be placed in the form of a questionnaire.

Detailed vendor technical documentation may also be requested at this stage to facilitate the evaluation process.

References

Ask each vendor to provide contact names, addresses and telephone numbers for at least four reference sites for possible future discussions and visits. Ideally, these sites should be of a similar business and technical profile to the evaluating organization.

In addition, you may decide to request a list of third party (independent) consultants who can describe recent, real experience with the software package.

RFP Procedure

Describe the procedure by which the RFP will be handled including:

the required format of response (e.g., document or file layouts)

the required response date

the central contact to which responses/questions should be directed

the conditions governing the bid

provisions for obtaining additional data

process for communicating requirement changes to vendors

schedule of events in the evaluation process (e.g., response due date, demonstration dates, decision date)

the minimum data which the vendor is expected to provide in response to RFP

It is essential that the RFP is impartial so as to provide vendors a fair chance at bidding their products against the organization's requirements. Ensure that the vendors are aware that their response may form the basis of a contract.


Task 030   Facilitate the Request for Proposal Process
 	Task .020 	Task .040 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Task 030  Facilitate the Request for Proposal Process

Vendors should be provided with access to knowledgeable individuals in order to clarify questions and ensure that the RFP is fully understood.

This should be coordinated by a central contact to ensure that the required bidding process is maintained.

It is recommended that an extension to the Project Technical Coordination role is to be this central contact.


Task .040   Perform Functional Comparison
 	Task .030	Task .050 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Task .040  Perform Functional Comparison

The purpose of the functional comparison activity is to determine whether the package will meet the functional requirements of the proposed system.

This activity is not intended to evaluate in detail how a particular function is performed, this is left until detailed process comparison.

The performance of the package against the functional requirements should be defined using a standard (weighted average) evaluation scheme, as illustrated below:

3	Good Match
2	Satisfactory Match
1	Unsatisfactory Match
0	No Match
Audit Trail

A precise reference to the function and associated documentation should be used to provide an audit trail for the evaluation.

Enhancements

In addition to indicating the current level of performance of the package, a further indication of planned or a customizable enhancement may also be made.

Demonstrations

In order to facilitate the evaluation, it may be necessary to conduct brief vendor demonstrations. These should only be performed once a detailed review of the RFP has been performed and will be used to verify or further illustrate the functionality of the vendor's package.

Non RFP Documents

Where the functional performance of the package is derived by assessing any documents outside of the RFP response, a follow up questionnaire may be issued to ensure that a formal written response supporting the evaluation is in place.

Initial Scoring

An initial review of the functional comparison should be conducted and a total score for each package prepared. Based upon the total score of the package, the list of potential vendors may be reduced by categorizing packages as either `rejected' or `standby'.


Task .050   Perform Initial Data Structure Comparison
 	Task .040 	Task .060 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Task .050  Perform Initial Data Structure Comparison

The basis for the data evaluation is to compare the required data model to the data structure underlying the package. The purpose of this comparison is to ensure that the data requirements for the application can be satisfied by the package.

The data required for the comparison may be either supplied directly by the vendor, or produced by the evaluation of package documentation. The comparison of data structures should be aimed at how well the package supports:

required entities

required relationships

In conducting the comparison, it is essential to recognize that a required entity or relationship may be supported by an equivalent although different structure. (For example, an organizational hierarchy may be reflected by a recursive relationship.)

The major factors to consider in the evaluation are:

correspondence of entities/objects

data volumes supported.

The fit of the package data structure should be evaluated in terms of the following scheme:

3	Good Match
2	Satisfactory Match
1	Unsatisfactory Match
0	No Match
The results of the evaluation should be summarized. Based upon this assessment, the overall viability of the package should be reassessed and the status of the package revised, thus potentially reducing the packages to be evaluated further.


Task .060   Establish Vendor Demonstration Agenda
 	Task .050 	Task .070 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Task .060  Establish Vendor Demonstration Agenda

Objective

The objective of a vendor demonstration is to clarify everyone's understanding and expectations of what the package can and cannot do.

Agenda

A required agenda for vendor demonstrations should be developed. Where possible, a demonstration script which is to be performed during the presentation, should also be produced to ensure that the objectives of the session are achieved.

The vendor should be told to minimize the time to be spent on general vendor company related information. Consider carefully the level of the audience you wish to attend.

User Site Visits

If it is not possible to establish an in-house or vendor-site demonstration within the required time frame, it may be feasible to visit one or more user sites to talk with users of the package and witness the package in operation, Visits may be in addition to a vendor demonstration.


Task .070   Conduct Vendor Demonstrations
 	Task .060 	Task .080 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Task .070  Conduct Vendor Demonstrations

Demonstrations should be set up and conducted with each of the final vendors. The purpose of the demonstration is to:

display actual systems functionality (on-line)

provide `hands-on' experience in the area of the package.

Demonstration scripts should be referred to during the demonstration to ensure that salient points are addressed.

Wherever a user-site visit has replaced a vendor demonstration, package selection criteria should still be referred to when assessing a package in this manner.

The initial functional comparison, should be confirmed based upon the demonstrations and the evaluations should be updated to reflect the results.


Task .080   Check Vendor References
 	Task .070 	Task .090 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Task .080  Check Vendor References

Establish telephone contact with the reference sites provided by the vendor using the following topics ( also on-site visit questions)

Orientation/Background

job title/role of reference

type and level of involvement with the package

length of time package installed

release level of installed package

components of package installed

level of customization undertaken.

Experience with the package

functionality

ease of use

ease of training

ease/quality of customization

reliability

integrity

flexibility.

Evaluation of vendor

business practices

organizational stability

management effectiveness

timeliness of releases

responsiveness to problems and modification requests

level/quality of training provided

telephone support and on site support

cautions in dealing with vendor.

Organization/Business Impact

overall end user acceptance of the system

degree to which expected benefits were realized

unexpected benefits

implementation problems encountered.

General

quality of documentation

installation problems

level of use

best/worst features

user group (if one exists, how effective is it)

reasons for the selection

overall degree of satisfaction

additional advice

It may also be relevant to inquire as to the reference's familiarity with other vendor packages still under consideration by your organization.


Task .090   Identify Preferred Packages
 	Task .080 	Task .100 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Task .090  Identify Preferred Packages

Based upon the data and functional comparison, a final short-list of two to three vendors should be selected for detailed presentation and evaluation.

The review should involve weighting through the following:

general product outline (e.g. name, price, vendor, etc.)

review of weighted functional comparison

review of weighted data comparison

results of vendor references.

Legal and Purchasing reviews of the software licenses and associated contracts should also be performed at this time.


Task .100   Perform Detailed Data Comparison
 	Task .090 	Task .110 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Task .100  Perform Detailed Data Comparison

The data required for the comparison may either be supplied directly by the vendor, or produced by evaluation of package documentation.

If neither of these sources is available, it may be necessary to attend vendor training to assess a data comparison. This also applies to the Process Comparison task.

The previous comparison of data structures should be extended to three levels:

support for required entities

support for required relationships

support for required data items

major factors to consider in this comparison are

correspondence of entities/objects

correspondence of keys/identification schemes

inclusion of major data items within each entity

verification and validation rules for data items

correspondence of foreign keys/relationships

additional data collection requirements

support for data volumes

The purpose of performing the above comparisons is to determine how good the match is between the software package and the required system as specified.

These comparison results will be used to define the degree of customization which will be required for the implementation of an individual package


Task .110   Perform Process Comparison
 	Task .100 	Task .120 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Task .110  Perform Process Comparison

Based upon the detailed demonstration of the package, a comprehensive process comparison should be produced.

The vendor should be required to demonstrate each required function and the associated transactions. If this information is not available, attending vendor training may be a viable option.

The evaluation should assess the following:

match between the package and the defined requirements

effort required to customize transactions to meet requirements

impact of transactions which come with the package but are not required (e.g. integrity/additional operational effort)

cost and impact of changing business practices to fit package

business data not supported and associated impact

acceptability of the Human-Machine Interface and overall style of dialog and screens.

A business area in which change is likely to occur very rapidly or consistently may have additional requirements for package flexibility. These areas of flexibility should also be specifically addressed to determine the impact of probable changes in business requirements on the package.

A prioritized requirements list for package modification should be produced together with an outline evaluation document. Priorities for this list should be based on the previously defined and prioritized requirements list.


Task .120   Evaluate Outstanding Technical Issues
 	Task .110 	Task .130 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Task .120  Evaluate Outstanding Technical Issues

Follow up any remaining technical issues not yet addressed e.g.:

audit and security

resourcing capability

systems performance

hardware utilization based on loading

hardware and software requirements

installation procedures and complexity

technical training required

system interfaces.


Task .130   Review Evaluation Process
 	Task .120 	 	Step PS 02

Package Selection

Step PS 02  Package Evaluation

Task .130  Review Evaluation Process

Review the evaluation process to ensure that the packages selected provide the basis for an appropriate business solution.

This review should be performed in conjunction with the Project Board and other parties (e.g. purchasing and legal department personnel) involved in the decision process.

Based upon the review, the package selection process may be abandoned in favor of an `in-house' development.

This would require the completion of the Required Systems Specification step.


Step PS 03   Final Package Selection
 	Step PS 02 	 	Package Selection

Package Selection

Step PS 03  Final Package Selection

Task .010  Specify Customization Requirements

Task .020  Cost Customization Requirements

Task .030  Negotiate Contractual Terms

Task .040  Establish Outline Implementation Plans

Task .050  Establish Overall Costs

Task .060  Determine Cost/Benefit Analysis

Task .070  Prepare Recommendation

Task .080  Present Recommendation to Management

Task .090  Conduct Benchmark Test

Task .100  Publish Recommendation

Task .110  Inform Vendors

Task .120  Finalize Procurement Process

Task .130  Plan Implementation with Vendor


Overview
 	 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Overview

Objectives

To prepare and present a recommendation as to which package to implement, supported by a detailed evaluation of the costs and implementation requests.

Overview

This step finalizes the selection process and initiates the procurement of a package solution.

The focus of the Final Package Selection step is around the development of a business case, considering in detail the costs of the package (e.g., licensing, customization, implementation, operation and level of vendor support) and its benefits.

The output from this step is a final recommendation to purchase and an implementation plan.

The implementation plan defines those activities, from the Classic template, required to design, customize and construct and test, and implement the package.


Adapting
 	 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Adapting

The following diagram illustrates how the Final Package Selection step can be used with the Classic template:

The guidelines for using the Classic template to effect package customization and implementation are as follows:

further expand, in detail, the data and process definitions of only those areas to be customized

for each area requiring customization, conduct a specific Interactive Development Workshop on the following topics :

demonstration of the areas of the package to be customized

development of new/modified screens and reports

definition of detailed transaction specifications

Developers, vendors and users should all participate in these workshops.

parallel basic package testing activities with customization work. These activities may also generate additional change requests from which further customization work will be effected

unless modifications are extensive, omit logical design activities focusing directly upon physical design and associated transaction specifications

construction, testing, and implementation activities should be unaffected


Roles
 	 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Roles	Responsibilities

Business Analyst	Produce

Business Coordinator	Consult

Database Manager	Consult

Data Resource Manager	Receive

Operations Manager	Consult

Planning Coordinator	Consult

Production Support Analyst	Consult

Project Board Member	Approve

Purchasing Agent	Consult

Stage Manager	Supervise

System Designer	Receive

Technical Coordinator	Consult

Technical Support Analyst	Consult

Trainer	Consult

User Representative	Approve


Entry/Exit Criteria
 	 	 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Entry/Exit

Inputs	Applicability

Package Evaluation	Mandatory

Products	Applicability

Benchmark Testing Results	Mandatory

Business Case Document	Mandatory

Cost/Benefit Analysis	Mandatory

Customization Costs	Mandatory

Implementation Costs	Mandatory

Implementation Factors	Mandatory

INITIAL PACKAGE SELECTION	Mandatory

Letters to Vendors	Mandatory

Negotiated Contractual Terms	Mandatory

Package Customization Specifications	Mandatory

Package Purchase Approval	Mandatory

Package Recommendation Report	Mandatory

Stage Plan Implementation	Mandatory


Task .010   Specify Customization Requirements
 	 	Task .020 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Task .010  Specify Customization Requirements

The required systems specification should be extended to reflect the customization requirements.

The purpose of this task is to formalize the package match factors determined from the weighting and scoring in the previous step as input to customization costing. This should include:

modifications to the required Data Flow Diagrams

expanded to reflect the business or package areas to be changed.

modifications to the required Data Model

to reflect changes in the package data structure.

additions and modifications to Transaction Descriptions.

prioritized package customization requirements list.

modifications to the Human-Machine Interface

in the form of a new Dialog Design and screen/report layouts.


Technique:	Data Flow Diagrams

Data Modelling


Task .020   Cost Customization Requirements
 	Task .010 	Task .030 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Task .020  Cost Customization Requirements

The requirements for package customization should be reviewed and a detailed cost for customization should be produced based upon either vendor proposals or vendor assisted estimates of the effort required to internally customize the package.

Customization requirements should include a statement of who will support the customized pieces of the package, which will in turn affect the cost of customization.


Task .030   Negotiate Contractual Terms
 	Task .020 	Task .040 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Task .030  Negotiate Contractual Terms

The details of contractual terms should be negotiated prior to the final selection.

Legal and Purchasing reviews of the software licenses and associated contracts should have been done previously in Step PS 02.090.


Task .040   Establish Outline Implementation Plans
 	Task .030 	Task .050 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Task .040  Establish Outline Implementation Plans

An initial evaluation of the factors involved in the implementation of the package should be produced.

This should focus upon the required effort and costs for key activities associated with the testing, data conversion and installation of the software package.


Task .050   Establish Overall Costs
 	Task .040 	Task .060 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Task .050  Establish Overall Costs

An overall cost evaluation for the short-listed packages should be prepared, this would typically include the following:

license costs

hardware costs

other additional software required (e.g. operating system; DBMS)

training costs (data processing and business people)

staff requirements and associated costs

vendor maintenance costs

computer related operating costs

in-house maintenance costs

business related operating costs

customization costs

implementation costs

Cost profiles should be based upon the projected life of the solution (e.g. five year operational life) as opposed to simply determining the initial expenditure required.


Task .060   Determine Cost/Benefit Analysis
 	Task .050 	Task .070 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Task .060  Determine Cost/Benefit Analysis

In conjunction with the users involved in the project, a profile of the tangible and intangible benefits should be developed for each selected package.

This should ideally be produced in comparison with other options such as enhancing the existing system or the `in-house' development of a comparable solution.

These would normally be the non-package options considered in the Business System Options step.


Task .070   Prepare Recommendation
 	Task .060 	Task .080 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Task .070  Prepare Recommendation

Based upon the process evaluation and the follow up specification and review of custom installation requirements and costs, a recommendation should be prepared.

This should include an overall comparison matrix which contains the following:

overall comparison of package functions and features

overall comparison of data requirements

cost/benefit analysis

hardware requirements

software requirements

customization specification

support services

The package recommendation should contain a clear statement of risks and differences.


Task .080   Present Recommendation to Management
 	Task .070 	Task .090 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Task .080  Present Recommendation to Management

The recommendation produced should be presented to the Project Board and approval for capital expenditure obtained.


Task .090   Conduct Benchmark Test
 	Task .080 	Task .100 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Task .090  Conduct Benchmark Test

The selected package may be tested on a trial to ensure functionality prior to installation.

In instances where a trial cannot be negotiated, benchmark tests may be performed in conjunction with either the vendor or other existing users of the package.


Task .100   Publish Recommendation
 	Task .090 	Task .110 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Task .100  Publish Recommendation

The recommendation should be published to all MIS and user representatives involved in this project.


Task .110   Inform Vendors
 	Task .100 	Task .120 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Task .110  Inform Vendors

The vendors should be informed of the selection and thanked for their assistance in the process.


Task .120   Finalize Procurement Process
 	Task .110 	Task .130 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Task .120  Finalize Procurement Process

Implement the appropriate procedures for finalizing the procurement of the package including the generation of purchase orders.

Contractual and licensing terms should also be finalized and agreed at this time, and executed with purchase orders, if necessary.


Task .130   Plan Implementation with Vendor
 	Task .120 	 	Step PS 03

Package Selection

Step PS 03  Final Package Selection

Task .130  Plan Implementation with Vendor

The vendor should be requested to assist in the detailed planning of the following:

detailed testing

package customization

data conversion

business conversion

training

installation of the package

post implementation support


Techniques in K:\HYPERGUI\PKG\PKGSEL.DOC as of:07/26/93 05:40 PM

Critical Requirements Analysis

Data Flow Diagrams

Data Modelling


Critical Requirements Analysis Where Used

Package Selection	PS 01	Initial Package Investigation	Task .020

PS 02	Package Evaluation	Task .010


Data Flow Diagrams Where Used

Package Selection	PS 03	Final Package Selection	Task .010


Data Modelling Where Used

Package Selection	PS 03	Final Package Selection	Task .010