Project Delivery Process D167

Blog: Biz-Performance, David Brown

D167 – Consider and Review Needs for Custom Development / Modifications

DEFINITION

Consider and review needs for custom development or custom modifications to the package software or to other applications.

SUMMARY

Custom development or custom modifications to the package software or to other applications may provide a way to extend the functionality of the basic package to meet the business needs. Such development often represents higher costs and risks, coupled with extended timescales. The full need is reviewed and the options are assessed. Recommendations are formulated and agreed.

PATH PLANNING GUIDANCE

This process is optional. It is used where custom development may be required.

DEPENDENCIES

Prerequisites (Finish-Finish):

Implementation Strategy – Process S700 / S710
Approach to integration – Process D160
Data Conversion Strategy – Process D180

Prerequisites (Finish-Finish):

Create detailed specifications – processes D600, D602, D604, D606

RECEIVABLES

Delivery Approach Definition (DAD)
Approach to integration IP (D160)
Data Conversion Strategy IP (D180)

DELIVERABLES

Use of Custom Development IP

TOOLS

(none)

DETAILED DESCRIPTION OF TASKS

Custom development may be used to fill gaps in the functionality of the package software when addressing the business needs. This process provides an initial examination of the needs and considers the options which may be available. The advantages and disadvantages of each approach are evaluated leading to recommended approaches. These would then be discussed and agreed with the client organisation. The findings are presented in the form of an implementation paper.

It should always be a first preference to avoid the use of custom development. There are several reasons for this:

Use of custom development techniques invalidates the “parallel approach” assumptions. The great efficiencies of the IDDI (Integrated Design Development and Implementation) approach cannot be taken advantage of.
Custom development often takes a long time and can delay the project. It may require the services or co-operation of bodies outside the project team, eg

the package supplier
the client organisation’s IT department
development team’s for other software applications concerned.

In addition, custom modifications to the package software have certain significant drawbacks:

The supplier is unlikely to provide full support for the application unless a fault can be reproduced on an unaltered version of the software
Bug fixes may clash with the changes made by the project
Documentation and help information may not match the way the system works
Upgrades can be very difficult to accommodate. Often it is necessary to re-analyse and repeat all the changes applied to the earlier system.

Where custom work is vital, an option to consider might be to contract the package supplier to undertake the work and to incorporate it in future releases. This can substantially reduce the current and future risk.

There will be options regarding how the custom work can be undertaken. For example, modifications would preferably be made using “user exits” in the package modules and using the package’s in-built language facilities. Most packages also have version control systems which should be used to ensure that the custom changes are controlled and maintained properly.

The recommendation will be formulated on the basis of the projected costs and risks in comparison with the business benefit that can be achieved by conducting the work. This is essentially a business decision which should be taken by the client organisation.