I don't remember where I got this, but the guidelines are very logical and sensible. 

This guide outlines the factors that should be considered in the selection of a software package and its associated hardware. It indicates the steps that should be taken in the evaluation processes and possible sources of help.

Section One: Objectives
Section Two: Costs
Section Three: The Requirements Specification
Section Four: Who to Approach
Section Five: Evaluating the Alternatives

Section One: Objectives

The introduction of a new software package is a costly and time consuming exercise and it is therefore important that the reasons for the acquisition and the benefit that it is expected to achieve are considered and documented. A written statement of objectives will help to define the scope of the project and can be used to evaluate its success on completion.

Section Two: Costs

It is essential that the full cost of the project is assessed. This is likely to be considerably more than the initial purchase cost of the software and should include the initial costs, the on-going support costs and perhaps also the cost of expanding the system over a period of time. Items that may need to be considered are as follows.

Hardware purchase

This may include hardware for the central software/database, network hardware and desktop hardware for the users. University standards should be followed and the availability of discount purchase arrangements considered. Compatibility with other campus equipment and the availability of campus expertise and maintenance should also be considered as a priority.

Hardware maintenance

Provision must be made for a suitable level of hardware maintenance. Desktop equipment can normally be maintained under the Campus Maintenance contract administered by Computing Services. Central servers and specialist equipment will need specific arrangements either via existing campus contracts or through the supplier or manufacturer. Most equipment will come with a warranty period providing free cover, but it is important to consider whether the free service provides a fast enough response.

For very critical systems it may be necessary to invest in extra equipment to provide resilience in the case of any failure.

Software License

Apart from the application itself there may be a need for database software, reporting software, backup software and other system management software. University standards should be followed and questions of compatibility, sharing of support expertise and the availability of discount purchase schemes should be considered.

Software is licensed in many different ways. Common ones are 'per concurrent user', where the license allows up to a pre-set number of people to use the software at any one time, 'per registered user' which requires a license payment for every user who will ever use the system, 'site-license' which generally gives unrestricted access throughout the organization, but sometimes has limitations imposed.

A license may be for a fixed period or perpetual. However even if it is perpetual it is not uncommon for suppliers to redevelop their package from time to time and to treat it as a new product requiring a new license fee.

Software support

Provision must be made for a suitable level of software support. A support contract will normally provide a Help Service, a software error fixing service and upgrades of the software from time to time. The cost is often a percentage of the license cost, 15% being about average, but 20% not uncommon.

If the systems is liable to be affected by statutory changes (e.g. income tax or VAT), or other mandatory changes outside your control (e.g. national statistical returns), you should ascertain whether these will be provided free of charge under the contract.

Implementation

There will be specific costs associated with implementing the system. These include training and consultancy on how to set it up to suit your needs. There will also be the cost of loading the initial data, either by converting it from an earlier system or by entering it manually. If the system needs to interface with other systems there may be costs in developing the necessary software or acquiring the necessary hardware.

Computer systems take a considerable amount of effort to implement so there will be a cost in staff time and there may be a need for extra temporary help during the project.

Operation and Administration

Computer systems require on-going operating, administration and housekeeping activities and consideration needs to be given as to who will carry out these duties. Examples are setting up security facilities, registering new users, taking regular backups, monitoring and reorganizing the database to avoid file overflows and to maintain performance.

Some of these activities may be carried out by non-specialist staff with suitable aptitude and training. Others will require specialist technical expertise. If this is not available in the department then arrangements will need to be made with another department, IT Services, the software supplier or a third party.

Upgrades and developments

Upgrades should be provided under the maintenance agreements, but suppliers may charge for the installation of the upgrade, and there will be work in testing any new software before it is implemented on a live system.

Development of the software to meet changing needs may or may not be covered by the support agreement. A supplier who wishes to maintain a position in the market will normally wish to keep the package up to date, but specific needs that may arise for a specific customer are likely to be chargeable. Some suppliers may only provide a standard package and may decline to make specific changes for a single customer.

Section Three: The Requirements Specification

It is advisable to produce a written statement of your requirements. This will help prospective suppliers to produce suitable proposals and will help you to evaluate the alternative options. It can also become part of the contract that is eventually agreed with the chosen supplier. Suppliers should be asked to provide a written response to the specification.

The areas that should be covered in a Requirements Specification are outlined below, and examples of such documents are available in IT Services.

Set the scene

Tell the prospective suppliers a little about your department, who you are and what you do. Say why you are looking to acquire or replace the computer system, and how this system fits with other systems both within your department and beyond.

Functionality

Specify what you want the system to do. It is a good idea to classify requirements into essential items, desirable items and requests for information. For example on the question of charging for issues from stock you might want to say the system must use average pricing for stock issues, or it is desirable that the system can use latest pricing, or simply ask 'which methods of stock pricing are available?'.

When selecting packages for common requirements in widespread use, for example a Stores system, it is better to concentrate on specifying areas where your needs may be non-standard, rather than stating basic functionality where the answer from all suppliers will be yes.

General Features

General facilities to be provided by the package should also be specified. These include:

• Reporting and printing facilities.
• Screen handling facilities, i.e. the ways in which it is possible to move between screens and between records either randomly or in pre-set sequences.
• On-line help facilities.
• Security, e.g. limiting groups of users to specific screens, data or functions and the availability of suitable audit facilities.
• Backup, recovery and housekeeping facilities.
• Archiving, i.e. facilities to move old data out of the current files, but still retain access as necessary.
• Customization facilities, and, if available, how software upgrades are affected.

Operating Environment

This section should specify what type of hardware, operating software and database the package must use, or ask what alternatives are available. University standards should be followed and advice can be obtained from IT Services. Local and wider area networking requirements should also be considered.

Documentation and Source Code

The supplier should be asked what documentation is provided with the package and whether the source coded is provided.

The source code is needed for a programmer to make changes to the system. It can be useful to have the source code of any reports provided as part of the system, as it may then be possible to copy and adapt them for other reporting purposes. It is not advisable to attempt to alter any processes within the system as this can easily lead to errors which will not be covered by the maintenance agreement. Even the adaptation of reports needs to be carried out with caution and may need to be re-worked when a new release is installed.

If source code is not provided (which is the norm), it is advisable to consider taking out an escrow agreement. This is an agreement for the source code to be lodged with a third party such as a bank or the National Computing Centre. In the event that the supplier ceases to trade the source code is made available to the customers and may enable them to make other support arrangements.

Installation, Implementation and Training

Ask the supplier what assistance they will provide and what training will be required. Obtain costs for all these services.

Contractual Information

Ask the supplier to provide a copy of their licence agreement and maintenance contract. Check on the level of service that they provide under the agreement, including:

• Does the agreement cover new releases of the product, how frequently, and are there any extra costs involved in installation.
• When is the help desk available and what response time is expected.
• Whether on-site assistance is provided, and whether this costs extra.

Company Details

Ask for details about the company, for example its size, number of customers, market share, and length of time in business. Ask them about their future plans and objectives to ensure that the package will move forward in a way that suits your plans.

Ask the supplier to provide a copy of their annual accounts for the last two years.

It is also worth asking whether there is a user group and what role it plays in the development of the product.

For shortlisted packages the supplier should be asked to provide reference sites who can be consulted or visited to get a user view of the software.

Sizing and Performance

Provide the supplier with information on the current size of the system and any expected increase over say three or five years. This should include the number of users of the system and volumes of the main items held or processed, e.g. customers, orders, suppliers.

The supplier should be asked to give estimated hardware requirements and timings of critical items eg. major processes or on-line responses.

Section Four: Who to approach

Proposals for the supply of the system should be invited from a number of suppliers. For some applications the possible options will be very limited, for others the choice may be very large, making it difficult to know how to limit the evaluation exercise.

In drawing up a list of potential suppliers the following factors should be considered:

• Is a similar package already in use on campus - a register of applications is kept in IT Services.
• Is there an education agreement for a package - consult the CHEST directory and IT Services.
• Is such a package in use at other institutions - consult colleagues in other institutions and IT Services may also have information.
• If the package needs to operate closely with some existing software, can the suppliers of that software suggest any suitable suppliers.
• Consult the trade press (both the computing press and the subject/business area for which the package is required).
• Consult professional organizations in the appropriate field.
• Consider whether you want to go for a tried and tested market leader, or a new package which may be innovative but immature (the latter will have a high degree of risk and potentially a high cost in terms of testing, fixing and possible adverse business impact when problems arise).

Section Five: Evaluating the alternatives

Evaluation should normally include the following steps, though the sequence may vary and some stages may be iterative.

• Assess the suppliers' written response to the requirements specification, noting particularly how many 'essential' items they are unable to meet, and considering the answers to the requests for information.
• Arrange for a demonstration of the package by the suppliers. This can be used to clarify areas of uncertainty from the written proposal and to assess factors such as ease of use and the general 'look and feel' of the product. Try some 'hands on' use of the product. If possible try putting some of your own data through the system, testing specific processes that you consider critical.
• If necessary arrange follow up demos, or 'workshops' on specific aspects of the product.
• Arrange to visit a user site to see the product in action in a real environment. Ideally this should be a user who has a similar type of operation to your own. Question the user about the level of service and support that they receive.
• Contact some further users to find out if they have similar views and experiences.
• Carry out an assessment of the financial stability of the supplier. Assistance with this can be provided by the Finance Office.
• Collect together all the information gathered from these evaluations and consider how suitable the package and the company are for your current and future needs.
• Check the license and maintenance contract carefully and negotiate changes as necessary. IT Services and the Finance Office can provide advice and help.
• Negotiate a suitable staging of payments to allow the system to be proved to be satisfactory prior to final payment.