Project Selection Process S600

S600 - Check Business Critical Requirements against Package

DEFINITION

The capabilities of the pre-selected package are evaluated against the requirements identified as knockout mandatory or business critical.

SUMMARY

Desk check the “knockout” mandatory and business critical requirements against the specified technical solution.  This may be done by a combination of:

• putting specific questions to the package’s vendor,
• evaluating the package’s documentation,
• using a demonstration version of the system,
• using a system that is already installed,
• consulting other internal users, for example, existing users within related companies,
• consulting external existing users and visiting reference sites,
• referring to specialist consultants within Consultant Company,
• consulting and attending user groups.  

If appropriate, the full requirements matrix may be issued to the vendor to request a formal response from the vendor.

PATH PLANNING GUIDANCE

This process is normal practice in “Selection - Confirm”.

DEPENDENCIES

Prerequisites (Finish-Finish):

• Format Requirements Matrix (S040)
• Prioritise Requirements Matrix by criticality (S070)

Dependent procedures (Finish-Finish):

• Prepare, issue and agree Selection Validation Report (S610)

RECEIVABLES

• Knockout mandatory and business critical requirements
• Any information available concerning the capabilities of the pre-selected solution

DELIVERABLES

• Findings reported in Selection Validation Report - see Process S610.

TOOLS

• Library of example requirements matrices

DETAILED DESCRIPTION OF TASKS

The need to evaluate business critical requirements

Although a technical solution has been pre-selected, it may be wise to check that the solution will, in fact, meet the essential requirements of the client organisation.  It is also useful to identify and evaluate the impact of any areas where the pre-selected solution would fail to meet fully the organisation’s business critical needs.

The requirements will normally have been noted and listed in Process S040, and prioritised according to criticality in Process S070.  The prioritisation will have identified which requirements are:

• Knockout Mandatory - such requirements absolutely must be met by the solution or it would be completely incapable of meeting the client organisation’s needs,
• Business Critical - these requirements are critical to the effective operation of the business and any failure to meet them would cause severe difficulties which must, therefore, be considered in depth and addressed before deciding whether the solution could be accepted.

These key requirements should be compared with the capabilities of the pre-selected package to ensure that the technical solution will be capable of meeting the client organisation’s fundamental needs.  This will normally be noted and reviewed by recording the results against the prioritised requirements in the Requirements Matrix.

Where there is a shortfall in the capability of the package, this should be noted and evaluated.  Consideration should be given to any alternative way of meeting the needs, for example, by introducing additional software or changing manual processes.  Customising the basic package is not normally a cost-effective solution given the likely difficulty and cost of supporting and upgrading the system, but it should be evaluated on its merits where appropriate.  The impact of the shortfall plus the estimated costs and benefits of any options should be reviewed.  A course of action should then be discussed and agreed with the client organisation.

The findings from this evaluation will be reported in the Selection Validation Report - see Process S610.

Fact finding techniques

It is important to get sufficiently detailed information upon which to base the evaluation.  The appropriate techniques will depend upon the particular circumstances of the client organisation and the reason why the pre-selection was made.

If the pre-selection has been made because of a decision taken by a parent organisation or related company, it may be possible to use the information upon which the decision was made, for example, the existing responses to an Invitation to Tender, vendor’s proposals and  contracts.  It would also be possible to discuss the merits of the solution with the relevant personnel in the parent or related organisation.

Where the system has already been supplied to the client organisation or a related organisation, it should be possible to refer to the documentation supplied and to investigate the actual experiences of those people who implemented it.  It might also be appropriate to prototype some of the needs on that system should there be any areas of doubt.

Specialist consultants will normally be available within Consultant who have experience of the packages concerned.  In some cases Consultant may be able to prototype the client organisation’s needs on a Consultant “showcase” system.  

Other users of the system may be consulted, for example, by visiting reference sites and user groups.  This technique alone is unlikely to give a definitive answer to the issues, but does give valuable corroboration to the information and views gathered from other sources.

The package vendor is often the best source of information concerning the package’s capabilities.  However, there are some particular considerations:

• the vendor may not be interested in any substantial amount of work if the decision will not result in an additional sale of the system (eg where there is a group licence or where an existing centralised system will be used),
• as with any selection, the vendor may distort the information in their favour - accordingly, the project team should always take steps to corroborate the information and investigate further any aspects of which they are unsure.

Information may be sought from the vendor in the same way as in a normal selection exercise, for example:

• by using a formal request for information listing the critical requirements,
• by issuing a full invitation to tender including the detailed requirements matrices
• by organising demonstrations or question and answer sessions,
• by asking for documentation
• by asking for a demonstration copy of the system or a Package Fit Study (see Process S180)

Further guidance on these techniques may be found in the relevant Selection Segment processes.

It may also be appropriate to perform a formal benchmark exercise (see Process S240), or to set up a Feasibility Prototype (see Process S400) before a final decision is taken.