FUJ00232424 - Pathway release policy - This document defines the Pathway policy for the identification and planning new Releases of Software and data. V1.0

Evidence on official site

ICL Pathway

PATHWAY RELEASE POLICY

Ref:

Date:

Version:

FUJ00232424
FUJ00232424

PA/STR/0003
1.0
26/11/96

Document Title:

Document Type:

Abstract:

Distribution:

Document Status:

Document Predecessor:

Author:

Pathway Release Policy

Strategy Document

This document defines the Pathway policy for the
identification and planning new Releases of

Software and data.

Pathway Management Team
PDA

Draft

0.7 POCL review

Jim Morley

Printed: 22/09/97

C:\OFFICE\TMP\TO18\RELV10R.DOC

COMMERCIAL IN-CONFIDENCE
Page 0
FUJ00232424

FUJ00232424
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: 1.0
Date: 26/11/96
Contents List
1. DOCUMENT CONTROL 392926 3
1.1 DOCUMENT HISTORY 392927 3
1.2 CHANGES FORECAST 392928 3
1.3 ABBREVIATIONS USED 392929 3
2. INTRODUCTION 492930 4
2.1 PURPOSE 492931 4
2.2 DEFINITION OF RELEASE 492932 4
2.3 IDENTIFICATION OF NEW BUSINESS OPPORTUNITIES 592933 5
2.4 CHANGE CONTROL 692934 6
2.5 INITIAL RELEASES 7
3. CLASSIFICATION OF RELEASES 8
3.1 SOFTWARE RELEASES
3.2 REFERENCE DATA RELEASES
4. DEFINITION OF RELEASE CONTENT 12
4.1 DEFINITION OF CHANGES: 12
4.2 PREPARATION OF CCN, 13
4.3 CCN EVALUATION AND DECISION 14
4.4 RELEASE CONTROL & CONTENT 14
ENCY PROCEDURES 14
5. MAINTENANCE RELEASES 16
6. RELEASE SCHEDULE 17
6.1 SOFTWARE RELEA. 17
6.2 EXCEPTIONAL RELE: 18
6.3 REFERENCE DATA DISTRIBUTION: 18

Printed: 22/09/97 COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO18\RELV10R.DOC Page 1
ICL Pathway

PATHWAY RELEASE POLICY Version:

Ref:

Date:

FUJ00232424
FUJ00232424

PA/STR/0003
1.0
26/11/96

1. DOCUMENT CONTROL

1.1 DOCUMENT HISTORY

Version I Date Reason

0.1 20/10/96 First Draft for Pathway internal use only

0.2 30/10/96 Second draft following application of Pathway comments.

0.3 30/10/96 Draft for issue to the PDA.

0.4 12/11/96 Updated following PDA comments through Michael
Purchase.

0.5 17/11/96 Updated following PDA & Sponsor comments received
through Michael Purchase.

0.6 18/11/96 Further comments applied from Pathway and PDA.

0.7 24/11/96 Further comments applied from PDA.

1.0 26/11/96 Further comments applied from POCL.

1.2 CHANGES FORECAST

None.

1.3 ABBREVIATIONS USED

The terms and abbreviations used in this document are those defined
in the AUTHORITIES Agreement (Schedule A01).

Printed: 22/09/97

C:\OFFICE\TMP\TO18\RELV10R.DOC

COMMERCIAL IN-CONFIDENCE

Page 2
FUJ00232424

FUJ00232424
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 1.0
Date: 26/11/96

2. INTRODUCTION

2.1 PURPOSE

This document describes Pathway’s policy for identifying and planning
the development of new Releases of Software and data. Pathway
aims to do this in a manner which is responsive to the business needs
of the Authorities and of Pathway and which also conforms with the
provisions of the Related Agreements. Overall, it aims to:

a) establish the principles associated with releases of Pathway
Services in the context of the Related Agreements;

a) establish the principles for regular and on-going Releases of the
Pathway systems and Services;

a) establish the provisions to bring in changes to functionality and new
POCL Clients more quickly and frequently through Reference Data
provided by POCL and/or Pathway and to explain the main
qualifiers for doing this;

a) establish indicative timescales for the different types of Release in
order to put these into context, while recognising that these may
need review when the underlying processes have been detailed;

The Pathway Release Policy is one component of a process of
establishing business change. A number of associated processes,
such as qualification and prioritisation of business opportunities, the
definition of release content, service management and reference data
management also need to be defined. This document supports the
development of such processes and establishes the principles for the
introduction of new functionality and Service improvements.

The incentives to introduce new functionality and Service
improvements in a timely and efficient manner are shared by both
Pathway and the Authorities, since commercially successful Services
will benefit both parties.

2.2 DEFINITION OF RELEASE

The Related Agreements define a Release to be “a documented
collection of Software and/or data provided by the CONTRACTOR to
deliver a Service” while the Requirement 476 makes it clear that the
definition also includes Reference Data. Throughout this document
releases will be referred to as either Software Releases or Reference
Data Releases. It is possible that both Software Releases and
Reference Data Releases require the co-ordinated implementation of

Printed: 22/09/97 COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO18\RELV10R.DOC Page 3
FUJ00232424

FUJ00232424
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 1.0
Date: 26/11/96

other Infrastructure and Supporting Services and it will be seen that
this requirement leads to further subdivisions of the definition of
Releases later in the document.

2.3 IDENTIFICATION OF NEW BUSINESS OPPORTUNITIES

Releases are required to support changes of Service delivery in order
to implement business change. This business change will cover a wide
range of scale and complexity. For example:

i. adjustment to POCL trading variables, such as the price of a first
class stamp;

i. changes to business rules, e.g. whether or not to print a receipt for
Automated Payment Transactions;

i. amending the format or information provided for existing transaction
types;

i. franchising an existing outlet, or creating a new outlet;

implementing a new client for an existing service;

introducing a new service for a client service;
i. Re-engineering services within the AUTHORITIES own operations.

The time, risk and cost of implementing such business changes will
vary, depending upon the extent of:

a) systems development;
a) reference data changes;

a) Infrastructure;

a) support Services such as Help desk;
a) documentation;

a) training;

a) marketing collateral;

a) network and telecommunications;

a) clients process re-engineering;

a) and so on.

All these changes must be taken into account in the process of
defining new business opportunities and setting priorities.

Printed: 22/09/97 COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO18\RELV10R.DOC Page 4
FUJ00232424

FUJ00232424
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 1.0
Date: 26/11/96

Releases which embrace new business opportunities will require a
study to prepare and qualify the business case for the AUTHORITIES
and for Pathway. Pathway wishes to participate in this work in a spirit
of business partnership. Successful studies will result in an agreed
Business Requirements Definition document which then becomes the
basis of a formal change request.

2.4 CHANGE CONTROL

The delivery of new or changed Software and Services beyond that
committed in the Related Agreements is subject to change control
under Clauses 101.3, and 101.4, and Schedule AO5 of, the
AUTHORITIES’ Agreement, the POCL Agreement and the DSS
Agreement. Changes which require modification to the Related
Agreements are approved under Clause 101.3 while conforming
changes are approved under Clause 101.4. All Releases except those
described as Class 1 Reference Data Releases at section 3.2.1 below
are subject to Change Control. It is emphasised here that a new
Release is the instrument of underlying business change and it is this
business change that is primarily the subject of Change Control.

A proposed change becomes contractually committed upon the
presentation of a Change Control Note (CCN) by the CONTRACTOR
and its approval by the AUTHORITIES. The CCN as defined by
Schedule A05 requires a detailed explanation of the requirements and
commercial impact of each change together with commitments to
timescales and costs. It is not required that the CONTRACTOR should
commit resources or expenditure to the development and
implementation of a change until the CCN has been approved.

In some circumstances it is possible that the lack of a complete
specification of a Clients requirements, or lack of commercial
commitment by a Client at an early stage of negotiations, could
prejudice the time to market for a new Service. To help avoid such
delays Pathway proposes that the commercial risk which is inherent in
incomplete requirements or in Client commitment may be shared by
the relevant AUTHORITY and PATHWAY by mutual agreement.
Clearly the willingness of either party to accept such risks and the
apportionment of the risk between them will be determined by their
perception of the business opportunities. The acceptance and
apportionment of such risks is the key to enable the time to market for
new services to be shortened significantly for suitable business
opportunities. The agreement of the acceptance and apportionment of
any such risks, including any special conditions for the cancellation of
the change, shall be recorded within the “Risk” section of the CCN.

For the avoidance of doubt Pathway emphasises that the commercial

Printed: 22/09/97 COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO18\RELV10R.DOC Page 5
FUJ00232424

FUJ00232424
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 1.0
Date: 26/11/96

and risk aspects of Change Control discussed in the preceding
paragraphs do not apply to changes that are already described by the
Service Definitions and anticipated by the Score Card in Schedule AO6
of the Related Agreements.

2.5 INITIAL RELEASES

Schedule B7 of the AUTHORITIES’ Agreement describes the initial
functionality of the Services delivered in two Releases. These are
henceforth referred to as Release 1 and Release 2. The contents of
Release 1 are described in the associated “ Release 1.0 Content
Description” document.

Release 2 enables the CONTRACTOR and the AUTHORITIES to
introduce additional functionality at around October 1997, the release
will also be defined in a Release Content Description.

Printed: 22/09/97 COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO18\RELV10R.DOC Page 6
FUJ00232424

FUs00232424
ICL Pathway Ref: PA/STR/O003
PATHWAY RELEASE POLICY Version: 1.0
Date: 26/11/96
3. CLASSIFICATION OF RELEASES

Releases are classified as either Software Releases or Reference
Data Releases. In this section, Reference Data releases are further
classified according to the impact and indicative timescales for
implementation. It is emphasised that the classifications are not (and
cannot be) exhaustive and the timescales are intended to be indicative
only. Pathway will provide firm timescales for each Release, on a case
by case basis, taking into account, amongst other things, the business
priorities for the associated changes and relationships with changes to
related Authorities and Client systems.

3.1 SOFTWARE RELEASES

Software Releases result from changes and additions to the
functionality of the Services. The impact of such changes measured in
terms of the time, effort and risk and cost of implementing functional
changes will vary widely from one change to another. Some changes
will require extensive development effort or co-ordinated changes to
Infrastructure and support Services while others require only minor
localised Software development with little or no need for changes to
the Infrastructure or support Service. Between these extremes there is
a continuum of the possible scale and complexity of implementation of
changes but all will require extensive and systematic testing. The
impact of Software changes will be evaluated and stated in a Change
Control Note (CCN) for each Change which is requested or
recommended.

It is planned that two new Software Releases shall be implemented
each year and Section 6 provides more information on timescales.

3.2 REFERENCE DATA RELEASES

Reference Data Releases are broken down into more detailed classes
according to the impact and target timescales for implementation. The
classes are numbered 1 to 5 in order of complexity and timescale to
implement. The different classes are not mutually exclusive and
compound Releases consisting of elements from different classes can
be envisaged. In these circumstances the Release taken as a whole is
classified according to the class of the highest element within the
Release. The class of a Release (other than for Class 1 Releases) will
be advised by Pathway by analysis of the business requirement.

Printed: 22/09/9

‘7 COMMERCIAL IN-CONFIDENCE

C:\OFFICE\TMP\TO18\RELV10R.DOC Page 7
FUJ00232424

FUJ00232424
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 1.0
Date: 26/11/96

The “APS Client Takeon Plan” is recognised to be a special case of
Reference Data Release that will require a co-ordinated approach to
implementation and migration that will be planned separately from the
standard classes of Reference Data Releases that are discussed
below.

3.2.1 STANDARD REFERENCE DATA CHANGES (CLASS 1 )

This represents the simplest and quickest type of Release to
implement and includes Immediate Reference Data and Advance
Reference data as described in the Related Agreements. Class 1
changes apply only to the value of those defined Reference Data fields
which are conformant with the Service Definitions, the SADD and other
Controlled Documents. No Software is developed and there are no
physical or logistical constraints associated with Service delivery.
Typically, such changes will be characterised by simple numeric
adjustments to POCL trading variables such as the price of a first class
stamp.

The potential for distribution is overnight for use the next day. Service
Level targets apply to this class of Reference Data and the
commercial aspects of the changes are covered by the Score Card in
Schedule A06 of the Related Agreements. This is the only class of
Reference Data that is implemented outside the Change Control
procedure.

3.2.2 BUSINESS RULES CHANGES (CLASS 2)

These are relatively simple changes to values of Reference Data fields
which define how the services operate. Such changes will require a
change to the Service Definitions, SADD and/or other controlled
documents.

No Software needs to be developed and there are no logistical
constraints associated with Service delivery. Testing of Reference
Data parameter changes may be required and also minor changes to
documentation. Typically, such changes will be characterised by
changes to the business rules. An example could be the requirement,
whether or not, to print a receipt for Automated Payment Transactions.

The potential for distribution is within one month from approval of the
Change Control Note allowing time for any changes to Pathway or
Authorities’ business rules as identified in the impact analysis. It is
anticipated that the commercial aspects of most Class 2 changes are
covered by the Score Card in Schedule A06 of the Related
Agreements.

Printed: 22/09/97 COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO18\RELV10R.DOC Page 8
FUJ00232424

FUJ00232424
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: 1.0
Date: 26/11/96
3.2.3 LOGISTICALLY CONSTRAINED CHANGES (CLASS 3)

This represents a class of change that is subject to logistical
constraints on Service delivery. Typically these are physical changes,
such as refurbishment of premises and installation and testing of
counter equipment. Some examples are:

. Franchising an existing Outlet
. Creating a new Outlet

The potential for distribution is within one month from approval of the
Change Control Note, although the actual timescale will be in line with
the associated change in service delivery. The commercial aspects of
Class 2 changes will in some cases be covered by the Score Card in
Schedule A06 of the Related Agreements.

3.2.4 EXTENDED FUNCTIONALITY (CLASS 4)

Class 4 covers more extensive changes which reuse existing Software
in the same business context or modify functionality and which can be
activated by means of Reference Data without new software
development. Examples of Class 4 changes include modifying the user
interface for existing transactions, amending the format of outputs and
re-using existing transaction types with a new set of Reference Data.
By their nature, Class 4 changes will probably require testing, data
take-on, revisions to marketing collateral and user documentation, and
user training.

The expected turnaround time will vary from case to case and will be
determined by impact analysis during change control. A significant
determinant of timescales will be the need (or not) for a new Client link.
Without such a need, straight forward transaction type reuse could be
envisaged in one month. Implementing a new Client link could take up
to 4 months from approval of the CCN. Other Class 4 changes are
likely to take between these two extremes.

3.2.5 NEW FUNCTIONALITY (CLASS 5)

This class of Reference Data Release is directly dependant upon a
related Software Release and is associated with the development and
testing of new Software. Examples are:

. New (or amended) Service requiring changed Software.
. New (or amended) Service requiring a new type of Reference
Data.
Printed: 22/09/97 COMMERCIAL IN-CONFIDENCE

C:\OFFICE\TMP\TO18\RELV10R.DOC Page 9
ICL Pathway

PATHWAY RELEASE POLICY

FUJ00232424
FUJ00232424

Ref: PA/STR/0003
Version: 1.0

Date: 26/11/96

The planning and management of this class of change will be
incorporated into that for the related Software Release.

Printed: 22/09/97 COMMERCIAL IN-CONFIDENCE

C:\OFFICE\TMP\TO18\RELV10R.DOC

Page 10
FUJ00232424

FUJ00232424
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 1.0
Date: 26/11/96

4. DEFINITION OF RELEASE CONTENT

The change management procedures described at Schedule A05 of
the Related Agreements represents the contractual basis for the
definition of functional changes to Services, which once agreed, will be
included in the contents of Releases. The control, testing and
approval of Releases are also subject to the provisions of Requirement
and Solution 476.

This section considers:
e Definition of changes
« Preparation of CCN
« CCN Evaluation and decision
« Release Control & Content

e Emergency Procedures

4.1 DEFINITION OF CHANGES

The AUTHORITIES may request changes and Pathway may
recommend changes to the Related Agreements. Neither the
AUTHORITIES nor Pathway shall unreasonably withhold or delay their
agreement to a change. Following approval, changes may be
implemented in one or more new Releases.

It is anticipated that the POCL will predominantly request changes
which are associated with the introduction of new or improved Services
to their Clients. It is anticipated that DSS will predominantly request
changes to meet legislative requirements and improve business
controls. It is anticipated that Pathway will predominantly seek
changes which improve the quality and control of the Services.

A formative stage of discussion is envisaged during which Pathway’s
Business Development section will work together with POCL or DSS
business managers to develop and qualify new business opportunities
for the AUTHORITIES and for the CONTRACTOR. Support will be
given to the development of the business case and establishing the
feasibility of developing new business through new Service
functionality. A business qualification process will include indicative
business volumes from the AUTHORITIES and indicative timescales
and prices from the CONTRACTOR.

Qualified business opportunities will be taken to the next stage either

Printed: 22/09/97 COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO18\RELV10R.DOC Page 11
FUJ00232424

FUJ00232424
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 1.0
Date: 26/11/96

by the AUTHORITIES, who will raise a change request or by the
CONTRACTOR who will raise a recommendation for a change by
CCN.

The request for a change shall contain sufficient information to enable
Pathway to respond with the fully costed and timetabled proposal that
is required in a CCN. The Business Requirements Definition for each
qualified business opportunity shall form the basis for the change
request. This should cover:

a) A statement of the business opportunity which explains the key
business drivers and gives firm transaction volumes;

a) Required changes to the Related Agreements, particularly any new
or changed:

ii) Requirements
iii) Service Definitions, Service Levels and other Schedules.

iv) Controlled Documents which are maintained by the
AUTHORITIES.

c) Assumptions, e.g. the indicative timescales and prices already
provided by the CONTRACTOR.

Workload volumes will be forecast by POCL annually in a document
called the “Workload Compendium”, which taken together with the
“Client Take On Plan”, provides the basis for more detailed plans.

4.2 PREPARATION OF CCN

The content of the CCN is set out at Schedule A05 (para 3.2.1). Each
CCN contains a statement of the costs and charges, timescales for
implementation and the period of validity of the CCN. Each functional
change will be mapped on to one (or possibly more than one) Release.
The period of validity of each CCN will take into account commercial
considerations and also the cut-off date by which the associated
Release Contents document must be approved by the AUTHORITIES
in order to meet the planned dates for each Release.

The commercial terms and target timescales for producing a CCN are
described in Schedule AOS.

The CCN also includes a statement of any commitments that are
required of the Contracting Authorities in order that Pathway can
implement the change requested.

To the extent that the business predictions are not firm at the time of
preparing a CCN, then the identification of the degree of risk and the
proposed risk sharing arrangements will be included as described at
Section 2.4 above.

Printed: 22/09/97 COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO18\RELV10R.DOC Page 12
FUJ00232424

FUJ00232424
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 1.0
Date: 26/11/96

4.3 CCN EVALUATION AND DECISION

The AUTHORITIES’ CCB shall evaluate each CCN and indicate its
acceptance or otherwise as set out in Schedule A05 (para 3.1). Those
CCN’s which are approved within the period of validity of the CCN will
be implemented as part of the Release(s) identified in the CCN.

4.4 RELEASE CONTROL & CONTENT

The Requirement and Solution 476 refers to the testing, control and
approval of Releases while the testing of Releases is described in
Pathway’s testing strategies and plans.

The content of a Release is determined through one or more CCNs
that shall be approved prior to a predetermined cut-off date for each
Release. The purpose of this cut-off date is to ensure that the changes
required in each Release are fully defined in time for the start of
detailed design, development and testing. After the cut-off date
changes may only be introduced under contract Change Control.

Requirement 476 requires the AUTHORITIES’ approval (such approval
not being unreasonably withheld) to the:

« contents of any release
e upgrade path for any release
e timing of the distribution of any release

e timing of the activation of any release

4.5 EMERGENCY PROCEDURES

Schedule A05 (paragraph 4) allows that if Pathway considers that any
change is necessary in order for it to comply with its obligations under
the related Agreements and there is insufficient time to comply with the
procedures then Pathway shall be entitled to proceed with such
change, provided that it shall as soon as practicable provide the
AUTHORITIES with a CCN for retrospective change. Such change
shall be subject to the procedures described in Schedule A05, and if
the AUTHORITIES, acting reasonably, do not agree to such change,
such change shall be invalid and the CONTRACTOR shall at its own
expense promptly take all steps necessary to reverse and remove the
effects of such change.

Printed: 22/09/97 COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO18\RELV10R.DOC Page 13
FUJ00232424

FUJ00232424
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 1.0
Date: 26/11/96

5. MAINTENANCE RELEASES

From time to time there will be a need for Releases of new Software
and data in order to remove faults or to improve Service Levels without
changing business functionality or business data. Such Releases are
called Maintenance Releases. Maintenance Releases shall be planned
and implemented under Pathway’s management control. Maintenance
Releases shall be subject to the Change Control procedure and the
Emergency Change procedure (Paragraph 4.5 above) shall be invoked
only when urgent action is needed.

Maintenance Release will range in scope from very minor Releases
which require little regression testing to major Releases that may
require full Regression testing and the recalibration of SLA measures
and timings. The requirement for testing will be determined on a case
by case basis.

Printed: 22/09/97 COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO18\RELV10R.DOC Page 14
FUJ00232424

FUJ00232424
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: — 1.0
Date: 26/11/96

6. RELEASE SCHEDULE

6.1 SOFTWARE RELEASES

Pathway plans to implement approved changes in two Software
Releases each year. This frequency is judged, from the experience of
other large service contracts, to be the optimum balance between the
business imperative to introduce new functionality and the risk of
adverse impact on Service Levels resulting from excessive rates of
change. The frequency of Releases will be reviewed in line with
experience gained during live operation.

The scheduling of releases will normally be in the spring and the
autumn in order to avoid the POCL seasonal Christmas peak
workload.

The relationship between activities in successive Releases is
illustrated below.

Release 'n' Release 'n+1'

6 months

3,4mon bs 9 months Time _

Fig 6.1 - Release Planning

Changes which have been approved within the Validity Period of the
associated CCN will be included within the Release Contents
Definition for the Release stated. Three months are allowed for the
approval of each Release Contents Definition which is then baselined
while the Release is implemented. Thus in steady state, there will be at
any time, one live Release (Release “n”) and two new Releases ( n+1
and n+2) at different stages of design and implementation.

The table below illustrates a possible timetable.

Printed: 22/09/97 COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO18\RELV10R.DOC Page 15
FUJ00232424

FUJ00232424
ICL Pathway Ref: PA/STR/0003
PATHWAY RELEASE POLICY Version: 1.0
Date: 26/11/96

Release Design Developme I Test & Implement I Release
Contents nt Integration
Frozen
1 July 4 July - 1 Aug - 1 Nov - 4 Mar - 4 April

31 July 31 Oct 28 Feb 31 Mar
1 January I 1 Jan - 1 Feb- 1 May - 1 Sep - 1 October

31 Jan 30 Apr 31 Aug 30 Sep

Fig 6.2 - Release Timetable

In constructing the illustrative timetable shown above, Pathway has
assumed that the four month Test & Integration period will include a
period of one month within which the Authorities undertake joint testing
and Acceptance of the Release.

As was discussed at the paragraph 2.4 it is possible that the time to
market for a new Client or Service could be reduced significantly if the
AUTHORITIES and/or PATHWAY are willing to accept the risk which
is inherent in committing resources and expenditure ahead of a
complete specification of requirements or ahead of commercial
commitment by the client.

6.2 EXCEPTIONAL RELEASES

In the event that an exceptional circumstance including for example a
Legislative change or an exceptional business opportunity requires an
additional release or a non-standard release schedule then Pathway

shall use reasonable endeavours to meet that need.

6.3 REFERENCE DATA DISTRIBUTION

Indicative timescales for the implementation of the different classes of
Reference Data Release have been provided at Paragraph 3.2 above.

Printed: 22/09/97

C:\OFFICE\TMP\TO18\RELV10R.DOC

COMMERCIAL IN-CONFIDENCE

Page 16