pn unc workgroup 20/9/11 requirements definition to delivery

PN UNC Workgroup 20/9/11Requirements Definition to Delivery

Action from previous meeting

• Action NEX08/03: Xoserve to assess what was the most appropriate way to progress/bring in Modification 0380. Update to be provided at 20/09/11 meeting.

UN

CE

RT

AIN

TY

Requirements to Delivery

Project Nexus launch

Current Start design

Time

Critical date (?)

Able to defer?

Need to accelerate?

Lead time – ability to concertina?

Reduce uncertainty

UNC discussions

SMIP ?

Technical, efficiency and business requirements

drivers

Original timeline overview

Requirements definition progress

• Excellent engagement – ‘requirements register’ being worked through

• Some aspects outside UNC – e.g. some iGT matters, industry data management

• Some matters stalled pending understanding of scope of SMIP – subsequently re-started

• Some key UNC industry requirements considered in detail – industry definition drawing to conclusion – year end target

Current timeline overview

Scoping Additional

Moving to the next Phase

• Preparing for economic, efficient, next phase with longevity

• Pre-requisites:– Defined requirements, expected outcomes and benefits– Priorities and dependencies

• Analysis of industry requirements

• Consider solution options

• Develop a delivery plan– reflecting the volume and nature of change – ensuring continuity of services

• Gain customer commitment

• Implemented UNC modification(s) [maybe in parallel with above]

Requirements Definition

Industry Topic Development

Industry Business rule definition

Functional Requirements

Xoserve Functional requirements

Non-Functional Requirements

Requirements Defined

& Signed Off

The development of a delivery plan may require iterations to fully work through the functional and non-functional requirements.

Mod 380 is part of a ‘family’: demand attribution, allocation and reconciliation

A ‘family’ of processes and objectives:

• Reduced reliance on allocation – Allow for more DM on back of AMR and Smart

• Increased accuracy of NDM allocation – AQ representative of more recent usage (mod 380)– Introduce more EUCs – potentially support for modest change

• Reduced risk of AQ ‘gaming’– Remove AQ amendments– Oblige shippers to submit all readings?

• NDM reconciliation attributable to individual sites– Meter point reconciliation

Keeping the family together!

Typical medium/ Large scale programme

Detailed Requirements

Analysis & Design

Application Build

Infrastructure Build

Testing & Trials

ImplementationBusiness case, sourcing, contracting, mobilisation

3-6 months 3-5 months 3-6 months 6-9 months 3months 2months

Programme life 20 – 30 months (not including lapsed time for Governance, procurement & contracting activities

Phasing and prioritisation - TBA

2012 2013 2014 2015 2016/17 2020

DCC Day 1 DCC evolutionDCC Foundation

In-flight project delivery

UKL sustaining actions

Smart roll out support

DCC Access Control

Exception & error Handling

Dumb to Smart Meter Exchanges

Increased Meter Read capacity

Rolling AQ

EU Changes

DCC evolution

Improved Energy Allocation products

Meter Point Reconciliation

UKL sustaining Nexus Topics

European driven change

?

Next Process Check Points

• PNAG – 17/10/11– Transition from support and guidance re approach to Requirements

Definition?

• Shipper seminar – 3/11/11

• Solution options and plan – likely Q2 2012