ICL Pathway
COMMERCIAL IN CONFIDENCE
PATHWAY RELEASE POLICY
Ref:
Version:
Date:
FUJ00001329
FUJ00001329
PA/STR/o03
5.0
16/07/99
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 of new Releases of
Software and Data.
Pathway Management Team
Approved
4.0
Jim Morley, updated by Anne Cooper
© 1999 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE
Page 1 of 16
FUJ00001329
FUJ00001329
ICL Pathway PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
Contents List
1. DOCUMENT CONTROL od
1.1 DOCUMENT HISTORY. 3
1.2 APPROVAL AUTHORITIE: 4
1.3 CHANGES FORECAST... 4
1.4 ABBREVIATIONS USED..... a
2. INTRODUCTION 4
2. PURPOS! 4
2.2 DEFINITION OF RELEASE 5
2.3, IDENTIFICATION OF NEW BUSINESS OPPO! 5
2.4 CHANGE CONTROL 6
2.5 CONTRACTUAL AND FUTURE RELEA: 7
3. CLASSIFICATION OF RELEASES 7
3.1 SOFTWARE RELEASE 7
3.1 NEW PRODUCT RE E 8
3.12 SOFTWARE INFRASTRUCTURE RELEASES. 9
3.13 MAINTENANCE RELEASES.. io
3.2 REFERENCE DATA RI 0
3.3. EMERGENCY PROCEDURI 2
4. DEFINITION OF RELEASE CONTENT.....
41 RELEASE CONTROL & CONTENT
5. RELEASE SCHEDULE.
5.1 SOFTWARE RELEASES...
5-L1 SOFTWARE DI;
5.2 REFERENCE DATA DISTRIBUTION...
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 2 of 16
FUJ00001329
FUJ00001329
ICL Pathwoy PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
1. DOCUMENT CONTROL
1.1 DOCUMENT HISTORY
Version I Date Reason
On 20/10/96 _I First Draft for Pathway internal use only
O2 30/10/96 I Second draft following application of Pathway comments.
03 30/10/96 Draft for issue to the PDA.
O4 12/11/96 Updated following PDA comments through Michael
Purchase.
O85 17/11/96 Updated following PDA & Sponsor comments received
through Michael Purchase.
0.6 18/11/96 Further comments applied from Pathway and PDA.
O7 24/11/96 Further comments applied from PDA.
10 26/11/96 Further comments applied from POCL.
1 27/11/96 Further comments applied from PDA, BA and POCL
12 28/1/96 I Incorporates revisions following review by Pathway, PDA,
POCL and BA
13 1/5/98 Brought up to date to recognise differences between
infrastructure and new product releases
2.0 29/03/99 I Applied comments and approved ready for issue
2a 21/05/99 Amended to reflect the current definition for Reference
Data changes.
2.2 22/06/99 Amended to reflect the signed Heads of Agreement (24'"
May 1999)
23 25/06/99 Amended to reflect comments from Pathway review
3.0 28/06/99 __ I Further comments applied and approved ready for issue
3a 14/07/99 I Amended to reflect comments from Horizon/POCL review
7.0 14/07/99 __I Pathway review comments applied and approved ready for
issue
5.0 16/07/99 Amended to reflect comments from Horizon/POCL review.
CCN4o8.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 3 of 16
FUJ00001329
FUJ00001329
ICL Pathwoy PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
1.2 APPROVAL AUTHORITIES
Name Position Signature Date
Tony Oppenheim Commercial and
Finance Director
Stephen Muchow Customer Service
Director
Liam Foley Business
Development
Director
Terry Austin Development
Director
Mike Coombs Deputy Managing
Director
1.3 CHANGES FORECAST
None.
1.4 ABBREVIATIONS USED
The terms and abbreviations used in this document are those defined in
Schedule Aoi of the Agreement.
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 that is responsive to the business needs of POCL, and which
also conforms to the provisions of the Agreement. Overall, it aims to:
a) establish the principles associated with releases of Pathway Services in
the context of the Agreement;
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Page 4 of 16
FUJ00001329
FUJ00001329
ICL Pathwoy PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
b) establish the principles for regular and on-going Releases of the Pathway
systems and services; including software infrastructure releases, new
product releases and maintenance releases:
c) 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;
d) establish indicative timescales for the different types of Release in order
to put these into context.
The Pathway Release Policy is a key element in the process of
establishing business change, and provides a set of principles for the
timely and efficient introduction of new or improved products and
services.
2.2 DEFINITION OF RELEASE
The Agreement defines 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 hardware/system 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;
ii. changes to business rules, e.g. whether or not to print a receipt for
Automated Payment Transactions;
iii.amending the format or information provided for existing transaction
types;
iv. franchising an existing outlet, or creating a new outlet;
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 5 of 16
FUJ00001329
FUJ00001329
ICL Pathwoy PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
v. implementing a new client for an existing service;
vi. introducing a new client transaction or new product ;
vii.re-engineering services within POCL’s own operations.
The time, risk and cost of implementing such business changes will vary,
depending upon the extent of:
a) systems development;
b) type of reference data changes;
c) changes to infrastructure;
d) changes to support Services, such as Help Desk;
e) changes to documentation;
f) training requirements;
g) changes to marketing material;
h) network changes and telecommunications;
i) clients process re-engineering;
j) and so on.
All these changes must be taken into account in the process of defining new
business opportunities and setting priorities.
New business opportunities will require a formal response from ICL
Pathway detailing options and costs to support and qualify the business case
for POCL. Authorisation for Pathway to commence work will be subject to
the Change Control process.
2.4 CHANGE CONTROL
Where a proposed change to the software includes a change to the
contractual requirements or Contract Controlled Documents then the
change will have to be introduced by a Change Request from POCL or a
Change Proposal from Pathway. A proposed change becomes contractually
committed upon the presentation of a CCN by Pathway and its approval by
POCL.
Pathway will also raise CCNs to introduce Software Infrastructure releases
in order to get POCL’s agreement to implementation.
Pathway will not commit resources or expenditure to the development and
implementation of a change until the CCN has been approved, other than
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 6 of 16
FUJ00001329
FUJ00001329
ICL Pathwoy PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
the agreed level of support for impact assessment and preparation of the
CCN.
In certain circumstances where a change is needed urgently it is possible to
implement using the Emergency Procedures defined in Section 3.3.
2.5 CONTRACTUAL AND FUTURE RELEASES
Release 1 was delivered in 3 phases: Release 1a (April 1997); Release 1b (May
1997); Release 1c (November 1997).
The CSR provides extended MIS functionality, introduces APS and EPOSS
functionality, and passes information to POCL’s interim TIP system for
accounting and reconciliation purposes. CSR forms the basis for contractual
acceptance, and will support the mounting of the Live Trial and so the
launching of National Rollout.
The CSR+ will provide extended APS functionality, encompassing Smart
Card functionality and the introduction of the Logistics Feeder Service
(LFS).
Further releases may be required on an ongoing basis. A number of new
products are already envisaged to extend the range of business functionality
available at the counter. There will, from time to time, be a need to refresh
or extend the supporting software infrastructure and the ongoing
maintenance of the services will necessitate fault correction. Performance
and Scalability upgrades will also be implemented according to Component
scalability plans, but these are outside the scope of Software or Reference
Data Releases.
3. CLASSIFICATION OF RELEASES
Releases are classified as either Software Releases or Reference Data
Releases.
Software Releases fall into 3 main categories: Software Infrastructure
Releases, New Product Releases and Maintenance Releases.
Similarly, Reference Data releases fall into a number of categories according
to the impact and indicative timescales for implementation. The timescales
are intended to be indicative only. The classifications may also be reviewed
in the light of experience.
Emergency Procedures for releases of software are described.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 7 of 16
FUJ00001329
FUJ00001329
ICL Pathwoy PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
3.1 SOFTWARE RELEASES
Software Releases result from a number of different requirements to change
or to extend the Services.
This may be simply in order to maintain them in good working order,
addressing faults, and improving service levels i.e. Maintenance Releases.
It may be that one or more additional areas of business functionality are
required, perhaps introducing an entirely new service. This would give rise
to a New Product Release.
The supporting infrastructure services will periodically need to be updated
to take account of the software infrastructure required to support new
products , releases or workload changes. So, depending on the nature of the
changes required, different types of release are demanded. The impact of
such changes measured in terms of the time, effort and risk and cost of
implementing the changes will vary widely from one change to another, and
these serve to characterise the different types of release.
Some changes will require extensive development effort and perhaps
involve co-ordinated changes to hardware/system infrastructure and
support services, while others require only minor localised software
development with little or no need for changes to the hardware/system
infrastructure or support services. Some can be implemented in a highly
segregated manner, without disrupting too many of the existing
components, whilst others may be highly invasive. As a consequence some
may require little in the way of re-integration effort, whilst others may
require a great deal. All will require comprehensive and systematic testing
of the areas concerned.
Between these extremes there is a continuum of the possible scale and
complexity of implementation of changes, but according to their essential
characteristics, all will fall into their respective categories of either New
Product Release or Software Infrastructure Release.
Because of the development, integration and testing lead times involved
with Software Infrastructure Releases, it is planned that a maximum of one
a year could be implemented. Several New Product Releases may be
planned each year, but in general releases should be spread out at least 3
months apart, and avoiding the busy Christmas period where POCL outlets
are involved. Section 6 provides more information on timescales.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 8 of 16
FUJ00001329
FUJ00001329
ICL Pathwoy PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
3.1.1 NEW PRODUCT RELEASES
A new product release may contain one or more business products. An
approved CCN will be required to develop and implement a new business
product.
The principal characteristics of the changes that form a New Product
Release are as follows:
a)
b)
2ae
=>
Non-invasive changes, requiring little or no revision to the existing
components of the services already operating
May be implemented by the addition of discrete components,
perhaps entire new services, highly segregated from the existing
components, requiring little or no re-configuring of the existing
services and their interfaces
May be tested largely in isolation
Imposes little or no re-integration of existing services
Involves little or no migration from existing services
Can be implemented with a backward compatible path, allowing
gradual introduction across the network of POCL outlets, and as
such permits the operation of a limited pilot
Usually introduces significant new business functionality, and so
requires significant levels of user training, which implies a
requirement for a gradual training programme
Several can be developed in parallel by virtue of the segregation, are
typically of short duration, and can be implemented flexibly, either
as separate releases or combined as one release
Reference Data changes will be included within the release
3.1.2 SOFTWARE INFRASTRUCTURE RELEASES
An approved CCN will be required to introduce a Software Infrastructure
Release.
The principal characteristics of the changes that form a Software
Infrastructure Release are as follows:
a)
b)
Invasive changes, requiring significant revision to existing
components of the services already operating
Major infrastructure components refreshed, or significant re-
configuring of the existing services and their interfaces
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 9 of 16
FUJ00001329
FUJ00001329
ICL Pathwoy PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
c) Extensive service-wide regression testing required
d) Imposes significant levels of re-integration of existing services
e) May involve migration from existing service state
f) May introduce major enhancements to existing business
functionality
Cannot easily be developed in parallel because of the re-integration aspects,
are typically of long duration, and must be implemented as planned and
separate from other releases if possible. Because of the long lead-times such
changes are generally best grouped together as one big release.
3.1.3 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 fall into three main types:
e Performance / capacity improvements (CCN required)
e Scheduled releases containing fault fixes combined with small functional
changes (CCN required)
¢ Urgent fault fixes (No CCN required)
Maintenance Releases 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 timings. The requirement
for testing will be determined by reference to assessed technical and
operational impacts for each overall Release and notified to POCL.
Maintenance Releases shall be planned and implemented under Pathway’s
management control.
Minor maintenance releases that are designed solely to rectify faults
reported to ICL Pathway through the incident and problem management
process and that result in no associated changes to designed system
functionality, process, procedure, training or documentation (bug fixes),
will be applied to the system as soon as they have been authorised by ICL
Pathway Customer Service Release Management. POCL Business Service
Management will be notified immediately by entries made in the Online
Problem Management database. Notification that such releases have been
applied will be given at the regular Horizon Service Review Forum meetings
and will be documented in the Horizon Service Review Book. Although not
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 10 of 16
FUJ00001329
FUJ00001329
ICL Pathwoy PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
subject to the Change Control Procedure POCL will be given the
opportunity to assess the content of the release in terms of possible business
impact.
All other Maintenance Releases shall be subject to the Change Control
procedure; and the Emergency Change procedure (Section 3.3) shall be
invoked only when immediate action is needed.
3.2, REFERENCE DATA RELEASES
Reference Data changes fall into three main categories:
¢ Those governed by the Operational Business Change Process
e Those required as a result of a fault reported via the incident and
problem management process
¢ Those required to implement a business/functional change which will be
released in conjunction with a New Product or Maintenance Release and
are subject to the normal Change Control Process defined in section 2.4.
POCL Reference data releases are governed by the Operational Business
Change processes where the required business change has been defined and
agreed in advance.
The purpose of Operational Business Change (OBC) is to predefine
common changes to the POCL business that occur often and require a short
implementation cycle e.g. changing the price of a bus ticket. By pre-defining
these changes the impacting cycle of the change is greatly reduced and the
implementation actions and time scales can be defined in advance.
Operational Business Changes are initiated through the receipt of an OBC
request form and Reference Data files, as defined in the process documents.
Reference Data Releases (under OBC) are broken down into more detailed
change types according to the impact and indicative timescales for
implementation. The change types are documented in the "ICL
Pathway/POCL Interface Agreement for Operation Business Change -
Product" document. The interface agreement identifies specific types of
business change in advance so that their characteristics (e.g. timescales,
dependencies and responsibilities) can be understood by POCL when
managing their business. These would be to support, for example,
negotiation with clients and service management processes.
The broad categories of change type for Operational Business Change are:
« Outlet Advanced - requires additional activity from ICL Pathway e.g.
relocating an outlet
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 1 of 16
FUJ00001329
FUJ00001329
ICL Pathwoy PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
« Outlet Basic - Class 1 reference data change only e.g. change of phone
number
« Product Advanced - requires additional activity from ICL Pathway
e.g. creation of new buttons on the counter menu
« Product Basic - Class 1 reference data change only e.g. change to the
price of a bus ticket.
Class 1 Reference Data is reference data that has no additional impact on the
Horizon system, although verification of the new data by POCL is required
for High Risk changes.
3-3 EMERGENCY PROCEDURES
Schedule Aos allows that if Pathway considers that any change is necessary
in order for it to comply with its obligations under the Agreement 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 POCL with a CCN for retrospective change. Such
change shall be subject to the procedures described in Schedule Aos, and if
POCL, acting reasonably, do not agree to such change, such change shall be
invalid and Pathway shall at its own expense promptly take all steps
necessary to reverse and remove the effects of such change.
4. DEFINITION OF RELEASE CONTENT
4.1 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 (other than those exclusively containing Fault
fixes) is determined through appropriate documentation baselined by 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 Change Control.
Requirement 476 requires POCL’s approval (such approval not being
unreasonably withheld) to the:
¢ contents of any release
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 12 of 16
FUJ00001329
FUJ00001329
ICL Pathwoy PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
© upgrade path for any release
¢ timing of the distribution of any release
© timing of the activation of any release
The definition of release content for any specific Release (other than those
exclusively containing Fault fixes), and the development of any more
detailed specifications, will need to take into account, amongst other things,
the business priorities of the business changes in that Release and the
alignment with associated POCL and Client systems. Processes for release
content definition are to be developed to address such issues.
Processes will also be defined to address the co-ordinated development,
trialing and introduction of Releases where these need to be aligned with
POCL system releases e.g. TIP.
5. RELEASE SCHEDULE
5.1 SOFTWARE RELEASES
Pathway plans to implement approved CCNs in a number of Software
Releases each year, disregarding releases covered under Maintenance
Releases and Emergency Procedures (section 3.3).
In scheduling these releases a number of factors need to be considered.
Due to the long lead-times involved in Software Infrastructure Releases,
largely stemming from the need to perform extensive re-integration, it is
impractical to plan for more than one Software Infrastructure Release in a
twelve month period.
Whatever the release type concerned, implementation periods need to be
spread out to avoid conflict. The critical interval can be judged from the
experience of other large service contracts. Experience dictates that they
should be at least 3 months apart to achieve 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.
Implementations involving the POCL outlets should be planned to avoid
their busy Christmas period wherever possible.
New Product Releases, and some Software Infrastructure Releases will
involve a phased implementation period, with user training activities and
possibly the running of a Pilot. These post go-live activities need to be
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 13 of 16
FUJ00001329
FUJ00001329
ICL Pathwoy PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
scheduled in and taken into consideration regarding the scheduling of
subsequent releases.
Under certain circumstances it may be advantageous to all parties to cluster
a number of releases together into a single implementation period. This is
particularly relevant to New Product Releases. The frequency of Releases
will be reviewed in line with experience gained during live operation. The
current view is that between 2 and 3 releases are likely each year including
one Software Infrastructure release and one or two New Product Releases.
Each New Product Release may include one or more business products,
depending on the size and the complexity of each.
The relationship between the release definition activities and the ultimate
implementation of the release is illustrated below:
Release
v
3 months 9 months r
oot rr Time —_—
Construct
Release 'n'
Content Definition
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 for, say, a Software
Infrastructure Release encompassing some functional enhancements
delivered in the Autumn, then avoiding the Christmas period, a combined
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 14 of 16
FUJ00001329
FUJ00001329
ICL Pathwoy PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
release comprising maybe 2 New Products , delivered in the following
Spring.
Release I Design Developme I Test & Implement I Release
Contents nt Integratio Go Live
Baseline n
d
TJanuary I 1Jan- 1Feb - TApr - 1 Sep - 1 October
28 Feb 31 May 30 Sep 30 Nov
aJuly ijuly- 3 I1Aug- 3/1Nov - 1 Mar - 1 April
July Oct 28 Feb 31 May
Fig 6.2 - Release Timetable
In constructing the illustrative timetable shown above, Pathway has
assumed that the Test & Integration period will encompass a period of
POCL confidence testing (if required by POCL). It is anticipated that the
testing and product acceptance processes after the initial releases will be
rationalised by mutual agreement.
For the avoidance of doubt, if an element of the Services under test fails its
testing criteria and it is decided by POCL and Pathway to withdraw it in
order to maintain Release timescales, then that failed element will be
included in the next Release unless otherwise agreed.
5.1. SOFTWARE DISTRIBUTION AND ACTIVATION
Some software releases will involve a phased implementation period, with
user training activities and possibly a pilot. In these cases there will be a
schedule of software activation agreed with POCL.
The new software for a release will normally be distributed to the outlets
over a period of time (dependent on the size of the software release) prior to
activation. Software release activation will normally be done over a week-
end, but where contact cannot be made with any outlets the activation will
necessarily span a few days. Both Data Centres will normally be upgraded
at the point of Software release activation.
Urgent fault fix maintenance releases may be done overnight during the
week if required.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 15 of 16
FUJ00001329
FUJ00001329
ICL Pathwoy PATHWAY RELEASE POLICY Ref: PA/STR/003
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 16/07/99
5.2, REFERENCE DATA DISTRIBUTION
Indicative timescales for the implementation of the different classes of
Reference Data Release are provided in document "ICL Pathway/POCL
Interface Agreement for Operation Business Change - Product".
Reference Data changes initiated as part of fault fixes or new products will
be an integral part of the New Product or Maintenance release of which
they form a part and will be scheduled in accordance with the agreed
release date.
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 16 of 16