Project Selection Process S040

Blog: Biz-Performance, David Brown

S040 – Format Requirements Matrix

DEFINITION

SIIPS S040 - Format Requirements Matrix.png

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.