POL00031106
POL00031106
David Miller, Esq.
Horizon Project Director
BA & POCL
King Edward Building
King Edward Street
London ECIA 1AA
18th September 1998
Dear Dave, . iCL
Without Prejudice .
‘
This is in response to your letter of 17th August to Mike Coombs regarding the
Replan, and deals with the contractual matters raised. Mike has dealt with
program related items under separate cover.
We were surprised and disappointed at the aggressive tone of the letter and by
the number of gratuitous and unjustified allegations of fault on the part of ICL
Pathway. You will understand that, much as we wish to concentrate on moving
the programme forward on a joint working basis with yourselves, we cannot let
these assertions go unanswered.
As a “general point” (with reference to your section A), we do not accept that
we have a "track record" of failure to meet planned dates in a context where the
other parties have "hit" or been "on target" with respect to their own
obligations. No such context has ever existed for ICL Pathway. In the case of
CAPS, the number of releases continues to grow, and each time that happens,
essential functionality and performance targets are deferred to later releases.
This delay in turn has a knock on impact on the timing of benefit migration to
cards, a matter which is specifically subject to Change Control by virtue of the
Authorities’ own Requirement 974. The “track record” is in fact that these
changes have been done unilaterally and without regard to the additional work,
lost time and lost income which are the inevitable impacts on ICL Pathway.
Schedule B7 sets out as a programme dependency just one date for CAPS
availability to enable full function testing of the end to end system. That date is
1 September 1996. At this point, accordingly, the Authorities are about two full
years off "target", with further significant delays apparent from lans declared
by them.
The Ministerial Review process continues to take its course, We expect that a
significant revision of the commercial framework will be needed to reach a
satisfactory commercial accommodation between the parties. In the meantime, !CL Pathway Ltd
we continue to hold that we should seek to address only those commercial Forest Road
issues which have a direct and immediate bearing on moving the programme je
forward.
“Fax +44 (0)181 730 4124
- Regueredh trgand no 2013561
ons
iigtier
‘London SWi5 1SW
POL00031106
POL00031106
Sn
Turning to your designated "Commercial and Acceptance Points", we would
comment as follows:
1. Irrevocable acceptance and multi-benefits
Your letter presents the Replan as a given, which necessarily has certain
"consequences". On the contrary, as your disclaimers clearly state, the Replan
is a proposal which requires both endorsement at the programme level and
agreement as to the commercial implications. For the reasons stated above, we
see the latter as ‘on hold’ pending clear guidelines from the Ministerial
Review.
The Replan proposes significant shifts in the risk profile which would damage
ICL Pathway and which therefore will need to be addressed in any
renegotiation of terms.
The first relates to the delayed introduction of multi-benefits by the DSS.
Multi-benefits were always to have been CAPS enabled from Day One. ICL
Pathway’s NR2 contains multi-benefit functionality today, as indeed does
Release 1c. The architecture makes it indifferent to payment types, which are a
matter for CAPS and the DSS feeder systems. In addition, and at DSS’s
request, ICL Pathway brought forward on-line DSS functionality and
temporary tokens from Release 2 (both Drop Down and CCN105 had these
facilities in Release 2) into New Release 2 (hence its new designation). This
was to provide the supporting services the DSS represented to us were
necessary for JSA and IS in particular (DSS’ two top priorities for multi-
benefit) - a new requirement relative to Drop Down and CCN105 versions of
the contract (both of which had these facilities coming on stream in the second
release). Introducing these facilities in the first release,cost us time, money and
tisk. The only DSS requirements not included in NR2 are on-line enquiries and
“Soft EVP”. On-line enquiries are not supported by the current version of
CAPS. The interface specification for the future CAPS release which will
support on-line enquiries was submitted to us as a Change Request only within
the last month. We have had to reject it in its current form because it seeks to
introduce new requirements for which adequate definition is absent.
Meanwhile, we have agreed to deal with DSS enquiries via the help desk - at
ICL Pathway’s expense. If volumes threaten to overwhelm the help desk, we
have agreed to introduce on-line enquiries as an increment on NR2. As to Soft
EVP, CCN243 has been with the Authorities for approval since 20" April and
remains unapproved today. We have made it clear repeatedly at CNT and
elsewhere that the Authorities’ failure to agree CCN243 is delaying New
Release 2+. The Authorities stance that they must have Soft EVP by a deadline
of their choosing is utterly unreasonable under these circumstances. We
consider that the Authorities are in breach of Schedule C5 (Change Control)
clause 2.2 for unreasonably witholding or delaying their agreement to this
CCN.
POL00031106
POL00031106
I
Whatever the reason for DSS now wishing to defer the introduction of multi-
benefits, it is not down to ICL Pathway. Yet the effects are (i) to introduce an
additional strand of testing work (and therefore cost), (ii) to deprive ICL
Pathway of income (iii) to defer the point at which DSS wish to determine
whether it accepts the NR2 system. That point is now delayed until some six
months after roll out has begun, thereby greatly increasing ICL Pathway’s cash
exposure to failed Acceptance.
You characterise NR2 Acceptance as being essentially meaningless. We
disagree. NR2 Acceptance matters because software accepted at NR2 (equating
to the first contractual release) cannot be rejected subsequently, and because
any faults accepted at NR2 Acceptance do not then count towards the
Acceptance threshold of NR2+ (equating to the second contractual release).
Under the Drop Down and CCN105 baselines, some 80% of contracted
functionality would have been tested and accepted at the first contractual
release, This would have left an “allowance” of 10 high/medium severity faults
at the second release to cover 20% of the functionality, with reasonable cure
periods allowed. This position has held true since Drop Down, when the
regime for split Acceptance releases was introduced in recognition of the fact
that the large number of agreements to agree and unfulfilled Contracting
Authority Responsibilities made it wholly impractical to introduce 100% of
functionality in a single release (at least, not without delaying it indefinitely).
Bringing forward on-line CAPS and temporary tokens into NR2 increased the
functionality to nearer 90%, and, with the allowance of high/medium severity
faults still set at 10, reduced the overall Acceptance risk accordingly. Dropping
not only on-line CAPS and Temporary Tokens but also multi-benefits from
'NR2 Acceptance, as your proposal suggests, would reduce the value of pre-
rollout Acceptance to no more than 70% of total functionality. To deny us the
opportunity to secure a more complete Acceptance, when an additional 20% of
functionality is in the product and will have been tested exhaustively (including
end to end testing with the DSS), is unreasonable.
With respect to your final paragraph, we reject the inference that ICL Pathway
has been solely responsible for project delays. We will not, therefore, accept
that, if the DSS is unready, it should be entitled to delay multi-benefit testing
on this pretext.
2. Release Authorisation and Pre-proving
We have discussed this item and agreed provisionally that it should not be a
barrier to progress. This is based on your assurances that you are not in fact
proposing to add to our existing contractual commitments. Two points should
be made to ensure no misunderstanding of our position.
Requirement 476 talks in specific terms of releases “iwhich are to be
distributed to and subsequently activated within any of the Services”. The
Services do not come into effect before Acceptance. Requirement 476 also
states that “the implementation of any release shall not cause any significant
disruption to Users... [and] shall not disrupt the normal working environment
of Users”. This only makes sense in the context of upgrades to an existing
service. It follows that Requirement 476 can only be taken to apply to releases
of software after the conclusion of Operational Trial. It does not justify a
second “Release Authorisation” hurdle for contractual releases which are
subject to Acceptance.
The Authorities are not reliant solely on Acceptance to ensure their
performance interests are met. The contract’s three sets of complementary
safeguards, taken together, represent powerful levers on the contractor.
e Acceptance tests exist to confirm compliance with functional and facility
requirements prior to release; !
¢ Termination review conditions under the Service Definitions limit the
latitude for operational performance variations;
e Remedies are triggered under the Service Definitions for lesser variations in
operational performance.
To go beyond these would represent “double jeopardy”. Such double jeopardy
was not agreed during the original or Drop Down contract negotiations (nor
during CCN105 discussions) and we have no reason to change our position
now. Neither do we believe that you should feel the need to do so given the
safeguards you already have.
The “custom and practice [of Release Authorisation] within the Programme” to
which you refer may have been appropriate for the interim releases we have
had to date, and we may have agreed to it for that purpose, but that does not
make it a contractual requirement. For a Release Authorisation process to be
introduced into the contract (under change control sponsored by the
Authorities), the relationship between Release Authorisation and Acceptance
would need to be reconciled such as to remove the double jeopardy.
3. Income Guarantees
The guarantee structure is set out clearly in Schedule A06. Guarantees are and
always have been tied to rollout of the physical infrastructure, without any
caveat or qualification. This follows the conclusion of Operational Trial and
the commencement of Roll Out (defined term). The guarantee structure did not
change at Drop Down when the split contractual release concept was first
introduced. CCN 105 did not hint at any change in this regard, and certainly
none has been agreed. Guarantees remain tied to physical rollout.
The logic for guarantees during Rollout was, I believe, never in dispute. Under
PFI, Rollout places the heaviest burden on the contractor's financial resources
and it is therefore reasonable that the contractor can count on a committed
minimum level of income to offset against those cash demands. The argument
_ POL00031106
POL00031106
POL00031106
POL00031106
that the contractor’s costs will be reduced because of lower start up activity
does not work. The fact that one of the Authorities may not be ready does not
significantly reduce operational costs during the start up period. The additional
costs of testing, rework to align with additional CAPS releases, lost card
production utilisation, phased customer education and potentially re-training
inevitably will add to the aggregate cost.
4. Live Trial Duration
While, again, we take issue with your characterisation of the extended duration
as a reflection of the Authorities' "past experience", we remain willing to
discuss a request for testing beyond that required by the Related Agreements.
‘
i
We understand that the Authorities have assessed the elapsed time requirement
to carry out the activities they now wish to carry out during Live Trial. We
recall similar discussions prior to CCN105. The conclusion is clearly that the
desired process will take longer than contemplated in the contract currently.
That is a proposed change to the schedule which stands on its own. We do not
expect a separate change request but the impact will need to be counted as part
of the whole.
We note the “clarification” that not only do the Authorities wish to have an
extended initial Live Trial, but that they in effect wish to have two Live Trials
spanning a period of a year. The first equates approximately to a “POCL Live
Trial”, success at which qualifies us to commit the large scale Rollout moneys
without any meaningful commitment or Acceptance by the DSS. The second,
as above, is reserved for DSS functionality deferred at DSS’ request. The “DSS
Live Trial” only completes six months after POCL’s, and six months after
commitment to Rollout. The adverse impacts on ICL Pathway are significant
and we again reject the proposition that the Authorities have any right to
demand them.
We would point out that the milestone tables in the Authorities’ Schedule B7
effectively set a maximum duration for Acceptance testing in general and the
Authorities' testing in particular within the framework of the current contract
length. .
5. Contingency Periods
Mike has covered this point in his separate letter. We do not take issue with the
need to have contingency within the plan. Our concern centred on reaching
agreement on how it could be utilised. You have provided clarification on this
point, and we are content with that. ,
It is unclear whether “our experience” (last sentence) is intended to collectively
include ICL Pathway or whether, on the contrary, you were referring to the
POL00031106
POL00031106
Authorities in their dealings with ICL Pathway as a supplier. If the latter, we
again utterly reject the innuendo that we are solely to blame for the delays.
6. Limit of 4000 Offices
As stated previously, we can find no contractual basis for the Authorities’
seeking to limit rollout following Acceptance of the first release, nor for
‘Release Authorisation’ in this context.
We find it perverse that the DSS should seek to apply a cap to benefit rollout
because of the lack of certain facilities (on-line enquiries and Soft EVP) when
the specification of those facilities depends on change control agreement which
has been delayed by the Authorities. In the absence of formally agreed CCNs,
we will not accept the development risks associated with Soft EVP and on-line
enquiries.
However, providing the proposed 4000 limit applies only to the multi-benefit
component of DSS card rollout, and does not apply to post office rollout, it
should be possible to deal with it as part of an overall commercial settlement.
7. OBCS
The position as we understand it is that you are seeking confirmation that DSS
intend to follow through with OBCS in all outlets except those in Northern
Treland, as currently contracted for.
8. Roll-out Rate i
As noted in Mike’s letter, we are content with your clarification. Thank you.
Under "Programme Issues", I have already elaborated on why we consider the
DSS to be to blame for the delays to multi-benefits. Other points have
generally been dealt with by Mike’s letter and by subsequent programme level
interaction, with some real progress being made.
Yours sine G R O i
ci i
Tony Oppenheim