Project Requirements Process R120

Blog: Biz-Performance, David Brown

R120 – Gap Analysis – Existing System versus Requirements

DEFINITION

Comparison of the existing systems and the defined requirements, intended to establish whether any parts of the existing systems might be retained to meet some or all of the requirements.

SUMMARY

There may be significant value in retaining parts of the existing systems to meet the newly defined requirements. One business option might even be to retain the entire current technical solution but to improve the way in which it is used. What value is the existing system in the new architecture? What could be kept? What should be replaced?

The requirements as defined in the “system vision” (see Process R070) and the detailed requirements defined in process R100, are compared with the potential functionality of the existing systems. Areas where existing approaches would (or could) meet those requirements are noted.

The results are reviewed and discussed with the project sponsor to identify the best overall solution for the client organisation. The findings would be included and formally agreed in the Definition of Requirements (DoR) report.

PATH PLANNING GUIDANCE

This process is optional. It is used where the existing system may still be of value in the final solution.

DEPENDENCIES

Prerequisites (Finish-Start):

Foundation (R010)
System Vision (R070)

Prerequisites (Finish-Finish):

Constraints (R040)
Detailed Requirements (R100)

Dependent procedures (Finish-Finish):

Collate and agree final report (R150)

RECEIVABLES

Constraints (technical, organisational and financial)
Foundation (analysis of existing systems)
System Vision
Detailed Requirements

DELIVERABLES

Gap Analysis – part of the Definition of Requirements (DoR)

TOOLS

(none)

DETAILED DESCRIPTION OF TASKS

Why consider the existing system?

There is frequently a possibility that the existing systems may be of some value in meeting the defined needs of the client organisation. In some extreme cases, existing systems have been found to be entirely suitable for the organisation’s needs – what was wrong was either the way they were being used or their lack of maintenance.

Retaining the existing systems usually presents one of the business options – in terms of calculating the net benefit to the organisation it is often the lowest cost but lowest benefit scenario. In many ways it represents the standard against which other solutions should be judged.

Although it is uncommon for organisations to decide to retain their existing solutions, it may be that some components of the existing systems could provide some of the business solution for low cost and without a significant reduction in the benefits. For example, an organisation wishing to implement integrated financial and administrative systems might find that it could retain its existing payroll system without losing any real benefit and thus save considerable time and expenditure.

Even where it is decided that all aspects of the current system will be discontinued, it may be necessary to consider the short-term retention of some components during a phased introduction of new integrated systems.

Approach

The high-level and detailed requirements can be compared with the known capabilities of the existing systems. Where the requirements cannot be met, it may be appropriate to establish what level of effort might be involved in making changes such that the requirements could be met.

It is particularly valuable to match the existing system against the business critical requirements – these represent the minimum realistic standard that any acceptable solution should achieve. Process R100 – Identify Requirements may have identified key business principles and rules to a sufficient degree for this comparison.

Alternatively, the selection process of prioritising the requirements by criticality can be brought forward to identify which of these requirements is essential to the business solution, and which are of lesser value (see Process S070 – Prioritise by Criticality). Failing this, it should at least be clear which aspects of functionality are critical in the new business solution.

With in-house custom systems, the appropriate IT staff should be interviewed and systems documentation reviewed as appropriate. With externally supplied systems such as packages, the system’s documentation may be studied and specialised advice can be obtained (for example by referring to consultants experienced with the package concerned). It may also be possible to discuss the capabilities of the package with its vendor who may be willing to spend some time to prevent the client organisation moving to a competing vendor whether or not there is a likelihood of fresh revenue for the existing vendor. The existing vendor might also anticipate possible work in modifying the existing systems.

The review process may be controlled and documented using a six-column version of the Requirements Matrix showing:

each requirement
its criticality (eg “knock-out mandatory, business critical or desirable)
whether it is met (yes, no, with modifications)
how it could be met
what time it would take (initial planning estimate only)
what cost would be involved (initial planning estimate only)

The fact that the Requirements Matrix is structured according to major areas of functionality should help to highlight aspects of the solution that could be met by the existing systems.

These results are then reviewed to identify any feasible solutions involving components of the existing systems. The costs of modifications involved would be summarised and any shortfall in desired benefits would be highlighted for the feasible options.

The findings and evidence would be reviewed with the project’s sponsor who should agree whether:

some existing components should become part of the overall solution
some existing components should be evaluated as alternatives against vendors’ proposed solutions during the subsequent Selection Segment (or against any pre-selected package modules in the case where no selection is involved)
existing components should not be considered for the business solution (but may nevertheless be evaluated as a benchmark against which to measure the net benefit of the eventual new system).

If any revised scenario is agreed, changes may be needed in the “system vision”, cost/benefit models, project plan and detailed requirements. These should be applied, subject to due consideration, review and agreement.