POL00028534
POL00028534
E
.D
SS RWPxx a
Bringing Technology to Post Offices and Benefit Payments \ . 08
CONGO 4 FALLBACK OPTION OUTLINE RELEASE SPECIFICATION
Author: PDA Release Management Version: Draft B
Authority: John Meagher (PDA Service Development) 28 July 97
Reference: RWPxx ~
Contents Page
. 1, INTRODUCTION
1,1 Background.
2, OBJECTIVE OF THE FALLBACK RELEASE...
3. KEY POINTS
4. DETAILED DESCRIPTION
4.1 Testing Approach.
4.2 Assurance Approach
4.3 RAB process.........
4.4 Implementation & Migration..
4.5 Support.
© 0 AD
28 July 97 Page 1 of9 — Draft A
POL00028534
POL00028534
RWPxx
1. INTRODUCTION
1.1 Background
On 2 May 97 Congo Release 2 went live. This release provides up to 190 post offices with
OBCS functionality using Order Book stop list data supplied from PRCS and is supported by
Pathway Release 1b. On 2 June 97 Congo Release 3 went live. This is an upgrade of CAPS
from release 2.0 to 2.1. This is supported by Pathway Release la and impacts the 10 initial go-
live (IGL) post offices where Child Benefit Payments are made by card.
Both these two Releases will be superseded by Congo Release 4. Congo Release 4 will provide
Child Benefit card payment fux(ctionality (BPS) and OBCS functionality to both the 10 IGL *
outlets and also those post offices previously supported by Congo 2. All of these post offices
will be supported by the new Pathway Release Ic.
* Pathway have experienced problems in developing Release 1c which has led to a re-planning
exercise with Pathway proposing a later go-live date for Congo 4 (Pathway lc) of 13 October
97. As part of the re-planning exercise, in response to the effect on CAPS PDR load
requirements of this later go-live date for Congo 4 (Pathway Ic) and the delayed
implementation of subsequent Congo and Nile Releases, Pathway have amended the scope of
Release 1c to include the functionality required to support the CAPS development of both a
multi-service and multi-ACC environment.
It is important that Pathway provide a new release on the 13 October 97 as proposed, so that
confidence in the Programme is not undermined and to allow CAPS to commence their PDR
Load migration activity. In considering this, Pathway have proposed-that a contingency plan be
in place, should further slippage be experienced preventing the go-live of Congo 4 (Pathway
1c) on 13 October 97. This contingency plan involves the Fallback Release option of providing
the full 1c product as planned on the 13 October 97, but with acceptable faults. These faults
would subsequently be fixed to agreed timescales. . . -
1.2 Purpose
This is a discussion paper describing the Congo 4 Fallback Release Option. It is intended to
prompt further detailed analysis by the involved groups within the sponsor organisations, the
Suppliers and PDA to enable the Fallback Release to be successfully implemented, should it be
invoked.
Working agreement to this contingency option has already been obtained from Sponsor
Organisations and Suppliers (Paul Rich for POCL, George McCorkell for DSS, John Bennett
for Pathway).
28 July 97 Page 2 of 9 Draft A
POL00028534
POL00028534
RWPxx
1.3 Scope
This paper:
© Details the objectives of the Fallback Release;
© Provides a detailed description of the:
This paper does not provide:-
«, Agreement on the acceptability of a Fallback release, (This is the responsibility of
Service Delivery in their assurance role.)
¢ Authority to proceed with the implementation of a Fallback release rather than a full
Congo 4 Release
¢ -Proposals for any re-planning exercises that may be required should a Fallback Release
be implemented
_ assured; .
testing approach for the Fallback Release;
assurance approach, the method by which the fallback release is defined and
checkpoints and criteria to be employed in deciding whether or not to invoke
the contingency Fallback Release. .
RAB process for the Fallback Release;
implementation & migration issues surrounding a Fallback Release;
support management procedures for the Fallback Release;
\
28 July 97
Page 3 of 9 Draft A
POL00028534
POL00028534
I
RWPxx
2. OBJECTIVE OF THE FALLBACK RELEASE
The objective of the Fallback Release is to maintain the CAPS PD/r migration timetable.
The Fallback Release provides the option of delivering a pre-release of Pathway Release Ic to
the 10 IGL offices only. This involves the delivery of the full set of planned functionality
which contains an acceptable level of faults together with the provision of supporting
workarounds such that a viable release (for the 10 IGL offices) is implemented.
The Fallback Release must therefore exhibit the following characteristics:
1) The ability to maintain the CAPS PD/r migration timetable through support of the .
CAPS multi-service operation (to be implemented with CAPS Release 2.2 (Congo
4.1);
2) Functionality that equals or exceeds that exhibited in IGL thereby maintaining the
payment of Child Benefit by card to the 1400 customers already using this service.
These requirements determine the minimum level of functionality that must be delivered. This
functionality is defined in more detail in the Minimum Acceptable Contents Description paper
(see attachment 1).
28 July 97 Page 4 of 9 Draft A
POL00028534
POL00028534
RWPxx
4, DETAILED DESCRIPTION
4.1 Testing Approach :
fs
The fallback release is a contingency option; the testing approach will be goed towards the
implementation of the full Pathway 1c (Congo 4 ) Release on 13 October using the sequence
of tests already planned. All of the currently planned tests must-be completed before either a
full or fallback release could go ahead.
As a result of the decisions taken at each checkpoint the emphasis, and the priority,
placed on the correction of errors will reflect whether a full or fallback release looks the most
viable option.
During this period the PDA testing and assurance areas will continue to be closely involved so
that the fallback release, if required, will evolve dynamically by ensuring that the priority is
given to error correction for those areas which meet the fallback criteria without compromising
the aim to deliver the full 1c on 13 October.
4.2 Assurance Approach
The assurance process must ensure that the key criteria for a fallback release are satisfied:
support to CAPS PD/r load by implementing the multi service/ multi ACC capability;
the provision of BPS functionality that acceptably replaces IGL/1a;
no degradation in security or accounting and reconciliation in comparison with IGL/1a;
the maintenance of the existing level of customer service in the 10 IGL offices.
eoeee
The assurance process takes place as part of the testing activity and is managed’by the Service
Development Team within the PDA. Assurance involves three areas:-
¢ Security;
¢ Technical;
© Business.
Assurance determines the viability of the release from a business perspective to ensure that the
overall requirements from the release are met.
The process for the full release would be that:
all faults are passed to the appropriate area within Service Development
the errors are prioritised based on business impact
these priorities are agreed with Pathway
fixes are reviewed where appropriate
workarounds are agreed when considered necessary -
PDA testing are kept up to date
any change to expected functionality is agreed with sponsors
28 July 97 : Page 6 of 9 Draft A
POL00028534
POL00028534
RWPxx
To enable Pathway to invoke the fallback release, if required, while continuing to put all their
effort into ensuring the full release can be delivered the prioritisation will categorise faults into
“full” - critical/ non critical and “fallback” - critical/ non critical The mechanism for this
judgement will be comparing:
IGL Releasele
Functionality Faults Functionality Faults
« MACD ¢ Known e.RCD e Known errors
(see attachment) deficiencies
¢ Known errors
(fom help desk)
¢. Business impacts
The Minimum Acceptable Contents Description (MACD) is designed as a guideline to identify,
at a high level, the areas of functionality provided in IGL, and the known deficiencies, and will
be used as an aid by Service Development in conjunction with the other factors (including the
overall criteria) to set priorities for error correction.
It should be stressed that this process is, by its nature, subjective ie. deciding if the
functionality provided in 1c is more acceptable than that in IGL, but it should also be stressed
that the judgements will be made on sound business and technical knowledge allied to a clear
understanding of the Pathway system.
The assurance process will also be focused on whether the overall release components as
finally delivered can be judged as “fit for purpose” even if the minimum IGL replacement
functionality is robust.
4.3 Checkpoints
The decision whether to implement a fallback release will depend on progress made in testing
and on the satisfactory resolution of priority faults agreed during the assurance process.
Checkpoints will be employed to enable this decision to be made by allowing an accurate
evaluation of the status of error correction and progress against plan at pre-determined stages
in the testing cycle.
In addition checkpoints will be used to determine the tage of offices the release should go to
ie. 10 IGL only or plus the 190 1b outlets.
Each checkpoint will provide an assessment of the stability of the functionality being tested;
this analysis will result in three possible outcomes, one of which contains two variants:-
1. If testing is progressing according to plan Pathway Release 1c will go live on 13 October
2. If sufficient progress is NOT being made, against the plan, and testing will not be completed
or if there are an unacceptable number of outstanding faults then the release schedule would
need to be slipped involving another re-planning exercise
28 July 97 Page 7 of 9 Draft A
POL00028534
POL00028534
RWPxx
3. If progress is NOT being made against the plan in terms of error correction but there is an
acceptable level of faults measured against the fallback criteria then a fallback release will be
implemented on 13 October (provided that this pre-release of Ic is viable as a whole) - the
variants concem the number of offices (10 or 200) that it would be considered prudent to
Telease to. . :
4.3.1.1 Checkpoint Timing
Checkpoints will be fortnightly to assess the functionality with an additional checkpoint to
confirm the target number of offices to implement the release in.
Checkpoint I High Level Description Date
1 Functionality Analysis 26 August
2 Functionality Analysis and Rollout Analysis _I 8 September
3 Rollout Analysis 15 September
4 Functionality Analysis 22 September
4.4 RAB process
The responsibility of deciding whether the Release should be implemented into the live
environment will rest with the Release Authorisation Board (RAB). The RAB for Congo 4 is
currently scheduled for the 6" October 97.
The normal process will apply with assurance being required for:
© business content;
© testing;
© operations;
© commercial.
The input to this process will cover whether the level of functionality meets-the minimum “~
acceptable contents (see attachment 1), the status of PINICLs and any associated workarounds
and the operational and commercial risks and benefits of authorising the Release.
The RAB will be chaired by Peter Crahan with representation from Pathway, Sponsors and
relevant areas with the PDA.
4.5 Implementation & Migration
The implementation strategy and current plans will be re-visited should the Fallback Release
need to be invoked. The implementation strategy for both the Fallback Release and the
provision of fixes for the live faults involved will need to be defined as part of the assurance
process together with any impact on future release plans. However, the approach to the
implementation of the Fallback Release would not change from that currently planned for the
full 1c Release. The main effect on the this approach will be on the timing of the various stages
through the requirements to:
* Support only the 10 IGL Outlets
28 July 97 Page 8 of 9 Draft A
POL00028534
POL00028534
RWPxx
¢ Provide fixes-to the live faults introduced in the Fallback Release so that the le
functionality is corrected to its full (target) status and can be rolled out to the 190
Congo 2 offices also.
The key steps in the migration process will be as follows:
1. Clear the Pathway 1c data centre down (Wigan Data Centre) following completion of
MOT and prepare it for live use, linking it with the existing Pathway 1b data centres to
allow splitting of OBCS data received fom BA and merging of OBCS data retumed to
BA.
2. Keep the Pathway 1b data centre running in parallel with the new lc data centre
(Wigan) for the duration of the Ic interim release.
3. Migrate the 10 IGL (1A) offices over the implementation weekend. Dispense with the
IGL data centre and start communicating with CAPS S (version 2.1) using the new
Pathway Ie data centre.
And to complete the process for the Full Pathway 1c Release (Congo 4):
4. Updating the fallback 1c system to target 1c Release status for all 10 IGL outlets;
5. Providing a short period for the target 1c system to bed in;
6. Migrating 1b outlets to Ic as originally planned.
4.6 Support
For the fallback option:-
¢ The support functions in the service management area will continue at t the I level ~~
specified and agreed for IGL;
¢ There will be no degradation in the detail supplied in the Weekly Performance Report
supplied by ICL Pathway.
28 July 97 Page 9 of 9 Draft A