Project Selection Process S050

S050 - Pre-qualification

DEFINITION

Define and issue pre-qualification criteria for vendors wishing to be considered for the Invitation to Tender, and evaluate their responses to determine the list of vendors.

SUMMARY

Where there are too many potential candidates to receive the Invitation to Tender (ITT) it may be possible to introduce an additional selection stage whereby vendors must respond to an invitation to “pre-qualify” for consideration in the main evaluation.  Pre-qualification may also be required by certain client organisations as part of their normal approach or due to legal obligations.

The invitation to pre-qualify is issued to all “long-listed” vendors (or alternatively to all vendors responding to advertisements).  It includes a short and simple set of questions which the vendor must respond to.  These are used as the criteria by which the responses are assessed to determine a final list of vendors to receive the full Invitation to Tender.  The criteria should be chosen, so far as is possible, as key initial discriminators.

PATH PLANNING GUIDANCE

This process is optional.  It is only used where a formal pre-qualification process is needed to select vendors for full evaluation

DEPENDENCIES

Prerequisites (Finish-Finish):

• Definition of Requirements (either per Requirements Segment or other method)
• Advertise (if applicable)
• Establish “Long List” (if applicable)

Dependent procedures (Finish-Finish):

• Finalise list of vendors to receive ITT (S110)
• Issue Invitation to Tender (ITT)

RECEIVABLES

• Definition of Requirements (or client organisation’s equivalent documentation)
• List of vendors to contact

DELIVERABLES

• Invitation to Pre-qualify
• Failure to pre-qualify letter

TOOLS

• (none)

DETAILED DESCRIPTION OF TASKS

Why use pre-qualification?

There is much work involved in the evaluation of tenders, particularly where the requirements are complex.  This workload is multiplied by the number of vendors involved and responses received.  One way of reducing this to a manageable size is to include a pre-qualification stage in the selection exercise.  Pre-qualification may also be required by the client organisation where this is their normal practice or where there is a legal obligation to issue some form of invitation to any vendor responding to an advertised opportunity.

This may be used in combination with other methods of reducing the size of the list (subject to the requirements of the client organisation), see S010 Market Review, S020 Advertise, S030 Establish Long List.  Where this is the case, vendors should not normally be excluded after this process.  Once they have “qualified” for the full Invitation to Tender (ITT), it is usually unreasonable to disqualify them.

The “right” number of vendors to include in the formal Invitation to Tender process will depend on many factors.  For a very large requirement where there are likely to be several qualified vendors, then five may be too many.  For a small requirement in a field where many vendors have competitive products then it might be possible to evaluate as many as ten or fifteen proposals.

Pre-qualification criteria

Pre-qualification criteria should be simple to state and simple to evaluate.  Their purpose is to avoid work not to create it!

At this stage it is not the intention to judge differing levels of compliance with the requirements nor the relative merits of the various approaches that the vendors might suggest.  The criteria should establish whether the vendor is likely to be able to offer a feasible solution.

They should cover the basic essential aspects of the client organisation’s requirements, for example:

• which applications are required within the integrated solution,
• which basic areas of functionality are required within those applications,
• any special non-standard functional requirements,
• which other systems the software will need to integrate with or interface to,
• the hardware, system software and architecture the software should operate on (where this is fixed),
• the approximate size and complexity of the organisation’s processing needs, eg locations, numbers of customers, accounts, staff etc
• whether the vendor organisation is capable of providing the levels of commitment and service required, eg whether they have a support organisation in each country.

Format of document

The Invitation to Pre-qualify is usually sent out in the form of a simple letter describing the client organisation and its basic needs.  A set of detailed questions would be attached.  The letter may also request other key information such as the vendor’s legal status, accounts, brochures, manuals, etc.

In some unusual cases, usually in specific market environments, the client organisation may require financial bonds to be placed by the bidders (if so, specialist assistance may be required).

As with advertisements (see Process S020), there is a choice of tactics regarding the naming of the client organisation and the address to submit responses to.  If the client’s identity has not already been disclosed, the main options are:

• issue the invitation in the client organisation’s name - ensures proper attention is paid to the true customer but can involve an unwelcome amount of contact from salesmen,
• issue the invitation in the client organisation’s name but with the Consultant as the only named contacts - avoids the problem of too much contact from the salesmen and shows the selection process will be serious and fair; it can, however, distance the true customers from the process,
• issue the invitation in Consultant’s name with the client remaining anonymous - completely avoids the problem of unwelcome contacts but makes it difficult to give the vendors a good level of information about the organisation and its needs.

Evaluating the responses

Vendors’ responses should be evaluated.  Non-compliant responses should be rejected.

It is normally reasonable to reject some of the compliant submissions where it is clear that they offer a demonstrably less satisfactory solution.  However, care must be taken to ensure that this is achieved in a way which is fair and acceptable.

Where it is possible to do so, the vendors should be reduced to a desirable number for submission of the full Invitation to Tender document (ITT).

Vendors who have been rejected should be sent a simple letter of rejection.  If the rejected vendors contact the project team to ask for further explanation, it may be polite and appropriate to disclose any clear reasons why their submission was non-compliant.  Greater caution should be exercised before disclosing any other reasons for rejection.  It may be more appropriate to refuse to comment.

Project Selection Process S045

S045 - Format Requirements Matrix (Hardware Selection)

DEFINITION

Identify and document the client organisation’s requirements for hardware into a Requirements Matrix format, suitable for inclusion in an Invitation to Tender (ITT).

SUMMARY

The requirements are prepared as a series of individual issues, listed in a tabular fashion for use as an early section in the Invitation to Tender.  Vendors will be asked subsequently to respond to these issues, and should normally write a detailed response to each of the specified issues.  The tenders will be evaluated against these issues.

The requirements will typically have been established by some earlier process in the Application Implementaton Process  path.  For example, it may already have been decided to use a certain application package, in which case the ability of hardware to support that application at the right scale and performance levels will be a key part of the requirement.

PATH PLANNING GUIDANCE

This process is normal practice in hardware selections.  It is required because suitable documentation to support an ITT for hardware selection would typically not have been generated prior to this point.

DEPENDENCIES

Prerequisites (Finish-Finish):

• R150 - Definition of Requirements (either per Requirements Segment or other method)

Dependent procedures (Finish-Finish):

• S080 - Issue Invitation to Tender

RECEIVABLES

• Definition of Requirements (or client organisation’s equivalent documentation)

DELIVERABLES

• Requirements Matrix (not yet prioritised)

TOOLS

• Requirements: example Hardware Requirements Matrix.

DETAILED DESCRIPTION OF TASKS

General format of Requirements Matrix

A Requirements Matrix is a list of requirements phrased in such a way that it is suitable for submission to potential vendors.  Initially it is prepared as a simple list of requirements needs or issues.  It would normally be in a format such that it can be re-used for several different purposes, in particular:

• as a statement of detailed requirements (ie 1 column table),
• to record the “criticality” (Knockout/Business Critical/Desirable) of each of the requirements (ie 2 column table)
• as a series of questions to pose to the vendors, showing whether or not they are mandatory and usually with space for their responses alongside the questions (ie 3 column table),
• to record the detailed prioritisation and weightings determined by the project team and client organisation for the evaluation of responses (normally a 3 column table showing both criticality and weights per issue, coupled with summary tables to record weightings for each sub-section and section in the overall table),
• optionally, as a table of all vendors’ responses alongside the original questions (ie multi-column text table),
• as an evaluation table showing the project team’s assessment of the responses alongside the questions in a tabular form (ie multi-column text and numeric table).

This reformatting can be achieved using many spreadsheet tools or word processors.  It would be normal to use the client organisation’s standard tools provided that they can manipulate text and numeric data in tables as required.  Provided there is sufficient time to prepare, it may be possible to supply the requirements to the vendors in this electronic format requesting an electronic copy of their responses as well as a formal printed and signed copy.  (Some projects have attempted a quantised self-assessment form of response allowing automatic calculation of comparative scores, but this is not yet normal practice.)

Scope and level of detail

The scope of the requirements should cover all requirements in sufficient detail for a supplier of IT hardware to propose a complete solution to the requirements.

A number of important considerations arise for hardware selection that may not have been researched in detail by earlier Software Application Implementation processes.  Such considerations should be researched at this stage and documented in the Requirements Matrix.  Depending on the exact nature of the engagement, these issues include:

• details of any specific application packages that the hardware is required to support;
• details of any specific RDBMS or TP monitor that the hardware is required to support;
• numbers and locations of users;
• performance requirements, such as user transaction response within 2 seconds, overnight batch to be completed within 7 hour window;
• anticipated transaction rates (peak and average);
• interfaces to other systems, whether hardware or software, new or legacy;
• infrastructure requirements, such as network limitations and protocols, either to be provided as part of the ITT or as a given with which the response must conform;
• security requirements;
• serviceability requirements, such as “nine-to-five”,  “24 hours a day, 365 days/year”;
• resilience to failure, such as continuity in spite of disk error;
• system and network management requirements, either for provision of the new system or for the ability to work with client’s existing solutions (e.g. must support SNMP or CMIP protocols);
• compliance with Open System standards, such as XPG4, POSIX, ANSI C and ANSI SQL.

Approach

The requirements should be reviewed and converted into a series of short statements or questions which itemise the detailed requirements into single issues in a format which potential vendors would be able to respond to.  In Software Application Implementation processes we try to re-use text as much as possible to minimise the work required.  Accordingly, the text would ideally be written in language such that it is suitable:

• as a statement of the requirement (to form part of the statement of requirements)
• as an issue for response from the vendors (to be included in the Invitation to Tender document)
• as an element of the design of the system (to be included in the relevant Implementation Paper and for the definition of system tests)
• as a statement of how things are to be done (to be included in the user documentation and training materials)

In addition to the items which represent true requirements, a Requirements Matrix should normally include other questions for information only.  These are intended to collect important information from the vendor, for example, which version of the software their responses refer to.

The Requirements Matrix should be structured into a format which makes it easy to follow and subsequently easy to evaluate.  Typical main sections might include:

• establish the precise products, version numbers, availability details, external requirements and assumptions etc  that the vendor is referring to in the tender document,
• questions/requirements about the vendor and the standard of service, support, training etc (requesting pricing information where appropriate),
• integration and interfacing,
• security,
• other functional/business requirements,
• architecture, eg client server, type of database, type of TP monitor, etc,
• communications network requirements, eg types of server, WANs, LANs, protocols, remote printers, PCs or VDU’s etc,
• hardware and system software requirements,
• backup, restore, recovery and archiving requirements,
• volume handling requirements - processor power, disk space etc,
• other technical environment requirements,
• costs, fees, recurring charges, licences, user limits, processor size limits etc - this detail can be included in Requirements Matrix or it can alternatively form a separate part of the Invitation to Tender document.

At this stage, no prioritisation need be performed on the issues.  Priorities (criticality and weights) are determined in later processes (see S070 and S090).  If the Requirements Matrices are being created in a single session with empowered representatives of the client organisation, it may be possible and efficient to perform the prioritisation at the same time.

Project Selection Process S040

S040 - Format Requirements Matrix

DEFINITION

Format the client organisation’s requirements into a Requirements Matrix format, suitable for inclusion in an Invitation to Tender (ITT).

SUMMARY

The requirements are prepared as a series of individual issues, listed in a tabular fashion for use in the Invitation to Tender.  Vendors will be asked subsequently to respond to these issues, and should normally write a detailed response to each of the specified issues.  The tenders will be evaluated against these issues.  The text used in the matrix may be used further as the main definition of requirements for the design tasks in the Delivery Segment and as part of the user documentation, training materials and definitions of system testing.

PATH PLANNING GUIDANCE

This process is optional.  It is only required if suitable documentation is not already available.  (Requirements would normally be prepared in a suitable format during the Requirements Segment - see Process R100.)

DEPENDENCIES

Prerequisites (Finish-Finish):

• Definition of Requirements (either per Requirements Segment or other method)

Dependent procedures (Finish-Finish):

• Issue Invitation to Tender

RECEIVABLES

• Definition of Requirements (or client organisation’s equivalent documentation)

DELIVERABLES

• Requirements Matrix (not yet prioritised)

TOOLS

• “Requirements” folder contains example Requirements Matrices for a wide range of applications and for differing complexities of environment.  Note that these can be collected from Consultant sources around the world and are not all in the same format.

DETAILED DESCRIPTION OF TASKS

General format of Requirements Matrix

A Requirements Matrix is a list of requirements phrased in such a way that it is suitable for submission to potential vendors.  Initially it is prepared as a simple list of requirements needs or issues.  It would normally be in a format such that it can be reused for several different purposes, in particular:

• as a statement of detailed requirements (ie 1 column table),
• to record the “criticality” (Knockout/Business Critical/Desirable) of each of the requirements (ie 2 column table)
• as a series of questions to pose to the vendors, showing whether or not they are mandatory and usually with space for their responses alongside the questions (ie 3 column table),
• to record the detailed prioritisation and weightings determined by the project team and client organisation for the evaluation of responses (normally a 3 column table showing both criticality and weights per issue, coupled with summary tables to record weightings for each sub-section and section in the overall table),
• optionally, as a table of all vendors’ responses alongside the original questions (ie multi-column text table),
• as an evaluation table showing the project team’s assessment of the responses alongside the questions in a tabular form (ie multi-column text and numeric table).

This reformatting can be achieved using many spreadsheet tools or Word Processors.  It would be normal to use the client organisation’s standard tools provided that they can manipulate text and numeric data in tables as required.  Provided there is sufficient time to prepare, it may be possible to supply the requirements to the vendors in this electronic format requesting an electronic copy of their responses as well as a formal printed and signed copy.  (Some projects have attempted a quantised self-assessment form of response allowing automatic calculation of comparative scores, but this is not yet normal practice.)

Level of detail

The level of detail included in a Requirements Matrix will vary according to the needs of the organisation and of the project team.  There may also be differences where the matrix is only being constructed as a tool in the selection process and not as the main list of requirements.

The appropriate style should be defined and agreed with the client organisation.  Typical approaches include:

1. Full list of requirements

The matrix is used as the main documentation of detailed requirements.  This provides a complete catalogue of the organisation’s requirements.

This approach should ensure that the requirements will be fully considered in the selection process and that the vendors should be obliged to make written statements about all relevant capabilities of their products.  The detailed definition of requirements will be of value both for the selection process and during the design and construction of the solution.  It can, however, lead to a large volume of work for the vendors in their responses and for the project team during the evaluation of the tenders.

2. List of major requirements

The matrix only records the major requirements, without exploring their full detail.  It omits insignificant requirements or requirements which are industry standards.

This approach may reduce the time required to collect and collate the requirements, the time to respond to the Invitation to Tender (ITT) and the time to evaluate the tenders.  It does, however, increase the risk of selecting a solution with a hidden flaw, and the missing detail may still have to be determined during the subsequent design work in the Delivery Segment.

3. List of key discriminating factors

The matrix contains only requirements which the project team believe will be most likely to discriminate between the potential vendors.  Requirements which any vendor is likely to meet or for which the standard of compliance is of minimal importance are omitted.

This approach is intended to minimise the time and effort required to make the selection decision.  It is of relatively little value in documenting the organisation’s requirements which will need to be fully defined during the subsequent Delivery Segment.

Approach

Where requirements have not already been gathered, collated, documented and agreed, the techniques described for the Requirements Segment should be used.

Where requirements have been defined but are not in an appropriate format, these should be reviewed and converted into a series of short statements or questions which itemise the detailed requirements into single issues in a format which potential vendors would be able to respond to.  In Application Selection and Implementation process  try to re-use text as much as possible to minimise the work required.  Accordingly, the text would ideally be written in language such that it is suitable:

• as a statement of the requirement (to form part of the statement of requirements)
• as an issue for response from the vendors (to be included in the Invitation to Tender document)
• as an element of the design of the system (to be included in the relevant Implementation Paper and for the definition of system tests)
• as a statement of how things are to be done (to be included in the user documentation and training materials)

Where the requirements are understood but not formally documented, it may be possible to use the example Requirements Matrices as a guide to possible requirements.  In most cases there will be more than one relevant example, representing different approaches and scales of requirements. 

These should be reviewed together to identify which items from which examples are of the most value in the particular case.  Relevant pieces would be copied and revised to match the client organisation’s actual needs.

In addition to the items which represent true requirements, a Requirements Matrix should normally include other questions for information only.  These are intended to collect important information from the vendor, for example, which version of the software their responses refer to.

The Requirements Matrix should be structured into a format which makes it easy to follow and subsequently easy to evaluate.  Typical main sections might include:

• establish the precise products, version numbers, availability details, external requirements and assumptions etc  that the vendor is referring to in the tender document,
• questions/requirements about the vendor and the standard of service, support, training etc (requesting pricing information where appropriate),
• input - facilities, user friendliness, error handling, navigation, menus, customisation of screens etc,
• processing - normally subdivided into the major aspects of functionality for this type of application
• reports and enquiries,
• integration and interfacing,
• security,
• other functional/business requirements,
• questions to establish the training and education needs, for example:
• built-in supporting tools,
• prototype training database availability,
• potential for hierarchy of help, potential level of documentation,
• additional training needs (eg needs for generic Windows training prior to training in the applications).
• architecture, eg web based, client server, type of database, type of TP monitor, etc,
• communications network requirements, eg types of server, WANs, LANs, protocols, remote printers, PCs or VDU’s etc,
• hardware and system software requirements,
• backup, restore, recovery and archiving requirements,
• volume handling requirements - processor power, disk space etc,
• other technical environment requirements,
• costs, fees, recurring charges, licences, user limits, processor size limits etc - this detail can be included in Requirements Matrix or it can alternatively form a separate part of the Invitation to Tender document.

At this stage, no prioritisation need be performed on the issues.  Priorities (criticality and weights) are determined in later processes (see S070 and S090).  If the Requirements Matrices are being created in a single session with empowered representatives of the client organisation, it may be possible and efficient to perform the prioritisation at the same time.