Project Requirements Process R125

Blog: Biz-Performance, David Brown

R125 – Gap Analysis – Requirements vs Target Solution

DEFINITION

The target solution is assessed to establish the extent to which it can meet the identified business critical requirements. This gap analysis focuses on functional gaps, and also on identifying technological gaps. Any needs for change are identified and assessed.

SUMMARY

The purpose of this process is to identify any gaps in the capability of the chosen solution to meet the business critical needs. This functional analysis is carried out by comparing the detailed requirements established in Process R100 to the functionality of the package modules. For each of these, identify whether it can apparently be met by:

parameterised customisation,
changes in the business practices,
modification of the package,
acquisition of a new commercial application, or
new custom development.

Where issues arise, a high-level explanation of the business issues should be provided, identifying needs for additional work or changes in the scope or defined business needs.

On the technological level, the requirements vs target solution gap analysis may result in issues and requirements for computer hardware, software, and communications systems.

The capabilities of the pre-selected package are evaluated against requirements identified as “knockout” mandatory or business critical. The detailed requirements list from Process R100 should be reviewed to identify these key requirements The assumption is made that the client organisation had good reasons for pre-selecting a specific package solution. It is, therefore, normally inappropriate to validate the non-critical requirements during this gap analysis. This process is intended only to establish that the target solution is viable – not whether it is a good choice.

The “knockout” mandatory and business critical requirements are desk checked against the specified target solution. This may be done by a combination of:

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

PATH PLANNING GUIDANCE

This process is optional. It is normal practice where a specific target packaged solution has already been identified.

DEPENDENCIES

Prerequisites (Finish-Finish):

Select package-specific base business model templates (R055)
System Vision: functions, data, volumes, performance, scope, objectives, boundaries / interfaces, technical goals, time scales (R070)
Detailed requirements matrix (R100)
Gap Analysis – existing systems vs. requirements (R120)

Dependent procedures (Finish-Start):

Establish architectural options (R130)
Estimate costs and benefits per option (R140)
Collate and agree final report (R150)

RECEIVABLES

Requirements matrix prioritised by criticality
Business data flow model
Package module functional documentation
Package module technical documentation
Software selection recommendation analysis / report (if any)

DELIVERABLES

Functional gaps and resolution – formally reported as part of the Definition of Requirements (DoR) report (R150)
Working papers showing:

Provisional way in which each critical requirement may be met
List of suggested changes and modifications
Computer hardware issues and requirements
Systems software issues and requirements
Communications systems issues and requirements

TOOLS

Business models
Package vendor’s documentation
Demonstration/training systems
Software Package Reference Model
Business Modelling tool
Example issues list

DETAILED DESCRIPTION OF TASKS

Introduction

Although packages offer a broad range of functionality, often there are areas in which the system may not fulfil business requirements to the extent necessary. For example, Some software packages do not sufficiently address shop-floor control in their production module. Although the vendor will at times produce customer specific modifications / additions to their product, it may be better to rely on other systems for certain business processes.

The purpose of this task is to identify main gaps between the critical functional business requirements and the package’s functional capabilities. The product of this process should be a list of functional gap resolutions and the impact on the project budget and schedule.

Additionally, the main gaps between the existing technological infrastructure and technological system requirements are identified in terms of:

communications capabilities and capacity,
required computing hardware / systems software and capacity, and
required user interface.

After the gap analysis is complete, there should be a list of high-level technological issues and their impact on project budget and schedule.

Prioritisation of business functions

The business areas targeted for technological revision may have been identified and diagrammed in R055 – “select package-specific base business model template”. They may have been further refined and modelled in processes R065, R067, R068 and R069. The full functional and organisational scope of the systems will have been formulated in Process R070.

Based on this, detailed requirements were established during Process R100. These may or may not have been prioritised by criticality at that time. Prioritisation by criticality requires that the client organisation identify and agree those requirements which are:

“knockout” mandatory – the solution would have to be scrapped if these could not be met,
business critical – areas of business functionality which must be addressed if the business is not to suffer significant damage,
desirable – other requirements which add value to the business.

Alternatively, the selection process of prioritising the requirements by criticality can be brought forward (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.

Identification of gaps and their effects

There are five main ways in which the critical business requirements might be met:

Parameterised customisation – using package specific functionality description.
Changes to business practices might be made without any negative effect to business processes. Some packages may be implemented alongside BPR initiatives. Indeed, packages often enable or drive re-engineering strategies.
Package modifications may be needed – occasionally minor changes will be needed to the package software. Generally such changes are not recommended as they incur additional, ongoing costs and risks in terms of reliability, support and upgradability.
A new commercial application may be needed – where business areas have been identified in the needs analysis for IT renovation, but the overall target solution does not match the business requirements
According to https://www.chapelvalley.com/services/commercial-landscaping, application is needed – where business areas have been identified in the needs analysis for renovation, but the overall target solution does not match the business requirements, occasionally, custom applications can be developed to more efficiently meet the business needs

Each of the critical requirements should be examined to see which of these approaches is most appropriate. Clearly, the majority of them should be addressable by standard package functionality.

Critical requirements may be desk checked against the specified target solution by a combination of:

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

Record against the list of critical requirements the functionality or approach that would be most appropriate. Identify separately on an issues list any conclusions which would lead to additional work or a failure to meet the defined critical needs. Discuss the impact of any significant issues with the project sponsor and other relevant management.

Future target solution releases

With some packages, new releases are often anticipated to resolve business needs to an extent that the current release does not. The anticipation of the future release adds another dimension to the requirements vs target solution gap analysis; the timeframe for that release should be kept in mind. For example, a company currently implementing a Software Application Package might expect to upgrade to release the next release when it becomes available. On the other hand, the company may expect to have a year or more delay before the next upgrade of their target solution, in which case it is much more necessary that the immediate solution meet their needs.

Technological Gap Analysis

To perform the technological gap analysis, technical documentation provided by the vendor and the existing technological infrastructure should be compared. For each business requirement, the following should be identified:

major hardware platforms to be added
major communication systems to be added.

Some examination will be required of provisional capacity and sizing information. At this stage in the project it is rarely possible to give accurate forecasts of volumes, throughput times or system sizing. Make sure this is clear to the project sponsor and key managers in the client organisation. The project team cannot take responsibility for any formal statements on capacity.

The scope of this analysis should encompass all computer systems to be utilised in the implementation project.

Estimation of budget and scheduling impact

When discussing issues and their resolution, the impact on the budget and time schedule should be considered and discussed. Information generated will be input to R130 (establish architectural options) and R140 (estimate costs and benefits per option). In those subsequent processes, options and their impact on costs and benefits will be examined, discussed and agreed with the project sponsor and other key management within the client organisation.