Home Career

Some new approaches to maintenance agreements may prove useful.

Error Correction Agreements

This is the "classic" maintenance agreement, which was developed in the days of large-scale bespoke developments where the developer's involvement in error correction could be expected to be high.

In the days of IBM 1400 series Autocoder, or System/360 Assembler, everything that the computer was expected to do was written into the programs. Later, these languages incorporated "macros", so that some common functions, such as reading from punched cards or disks, could be performed without the programmer having to write out all the program statements needed to perform these functions, such as positioning heads on disk drives.

As programming languages moved "higher", programmers were less concerned with the functions of the computers on which the programs would run: the possibility of errors was reduced.

Later, with the introduction of objects into programming, programmers could increasingly rely upon objects behaving correctly, with a further corresponding decrease in the possibility of errors.

While the possibility of errors within programming code was declining, the features and power of testing tools was increasing, so that testing of complex programs became easier.

With the addition of comprehensive acceptance testing, the possibility of errors occurring within program code is now often negligible.

There is now a good argument, in some instances, for abolishing the error correction agreements, with their annual maintenance fees, and treating the correction of errors in much the same way as the addition of enhancements.

This argument ignores the views of software developers, which have been formed by their experience with customers.

Often, in the past, software developers reached agreement with customer for bespoke software on the understanding that there would be an ongoing role for the software developers in providing new enhancements and extensions to the software.

Quite often, these enhancements and extensions would not materialize, usually because of budget cuts in the IS department. As a result, software developers had no continuous revenue stream from those customers.

Software developments have a history of running over time and budget, and some software developers relied upon the enhancements and extensions to provide profit. Without some form of continuous revenue, many developers would not make a profit on the original development.

The maintenance agreement, with its annual fee, provided a revenue stream to software developers.

Clearly, there has to be some re-thinking of the relationship between the customer and the developer.

This can be achieved by:

1. The customer adopting a more relaxed attitude during the development, allowing for re-negotiation of the price where budgets will be exceeded.
2. The developer quoting realistic prices for development.
3. Both the customer and the developer keeping a focus on each other's objectives, constraints and problems.

The result could be:

• prices for development which allow the developer to make a profit without cutting corners;
• the abolition of annual maintenance; and
• an agreed mechanism for error correction, with shared risks from the results of the errors.

Upgrade Agreements

It is important that all of the issues involved are clearly understood before the package is purchased or the customization applied. As part of the software selection process, the customer should check on the package vendor's policy on new versions and take this into consideration during the selection and also during the development of the agreements with the developer.

It may be, for example, that a customer will decide to reject any packages that are subject to an "upgrade or else" provision by the package vendor.

Another customer may insist that the developer will ensure that the customization remains in step with the release of new versions of the package and that this is done as part of the annual maintenance agreement. It is, after all, the developer's choice to support a particular package; if the developer does not like the package vendor's policies, then it should either negotiate changes to them or "dump" the vendor.

All of these issues and decisions must be addressed during the selection process: they cannot be left until problems actually occur.