2. Requirements (commercial articulation in an output based specification and demonstration/certification of it)

PFI Assurance Issue:

2. Requirements (commercial articulation in an output based specification and demonstration/certification of it)

…to provide assurance that the PFI contract will be (or continues to be) viable where the requirement (can be / is) suitable for the principles of PFI (e.g. stable and long term) in accordance with mandated policy and best practice and is articulated in a manner that is clear, robust, legally enforceable, output based, is able to be demonstrated, certified & verified using objective criteria traceable forwards/backwards to the commissioning tests/solution/SRD/URD/KURs and where ongoing performance is monitored, and delivery of the requirement is appropriately incentivised by aligning it fully with the payment and incentive mechanism.12

Commercial/Financial Assurance Guide Ref:

DE&S Commercial Assurance Guidance: 1. Commercial scope/Requirement & 19. Acceptance Criteria

Relevant MOD policy/guidance used as measure for assurance:

Relevant external policy/guidance used as measure for assurance:

MOD PFU Guidance Note - MOD Standard Project Agreement v1 for PFI Projects

MOD PFU Guidance Note - Demonstration & Certification of PFI Services

• [MOD PFU Guidance Note - Output based Requirements for PFI Projects]13

HM Treasury: Standardisation of PFI contracts (SoPC) Version 4

• OGC Achieving Excellence Guide 9 - Design Quality

• OGC Achieving Excellence Guide 10 - Through Health and Safety

OGC Common Minimum Standards

HMT Technical Note 7: How to Achieve Design Quality in PFI Projects

Evidence Required for each Procurement Phase

All phases:

• Key User Requirements14

• User Requirement Document

• Historical data and trend analysis to support requirement15

Up to Initial Gate:

Up to Market Engagement:

Up to close dialogue and Preferred Bidder appointment:

Up to Main Gate:

Up to Contract Award:

Post Contract Award:

• Service/System Requirements Document16 (SRD) (as a schedule in Project Agreement)

• Requirement traceability matrix (mapping KURs-URD-SRD-solution-demo/cert)

• Description of Service Levels up to full service and Mechanism for transition to full service

• ITN/ITT (instructions to bidders)

• Design review process/mechanism (as a schedule in Project Agreement)

• Demonstration/certification mechanism (as a schedule in Project Agreement)

• Independent Certifier deed of appointment (as a schedule in Project Agreement)

• Evidence of Customer/Sponsor sign-off of SRD

• Design review process/mechanism (as a schedule in Project Agreement)

• Demonstration/certification mechanism (as a schedule in Project Agreement)

• Independent Certifier deed of appointment (as a schedule in Project Agreement)

• Bidders acceptance of SRD (as a schedule in Project Agreement)

• Evidence of Customer/Sponsor sign-off of SRD

• Demonstration/Certification/Commissioning Test programme plan

• System Demonstration Schedule(s)

• Demonstration/Certification/Commissioning Test programme plan




__________________________________________________________________________________________

12 Assurance does NOT include assurance of the requirement itself or that it meets the customers needs.

13 In draft.

14 Including whether the original KURs are still valid for signed projects.

15 Robust data is needed if project teams are to specify their requirements accurately and make clear to contractors the risks being transferred to them. Acquisition teams should ensure that the initial planning stage of each project includes the production of suitably robust data on any existing use of the required service, forecast usage and the condition of assets being transferred to the private sector. The PFU should check that this information is available before bidding competitions commence.

16 Also known as a Statement of Requirement (SOR) or Comprehensive Core Requirements (CCR) document.