PROTECT - MANAGEMENT

X Programme Management Framework

May 2013

PROTECT- MANAGEMENT 1
 PROTECT - MANAGEMENT

Contents

The core X programme management functions are discussed in separate sections of this document.

Section Title Page

1 Governance 4

2 Organisation 14

3 Reporting 18

4 Planning 23

5 Dependency Management 32

6 Resource Management (incl recruitment) 38

7 Risk and Issue Management 44

8 Change Control 53

9 Configuration Management 58

PROTECT- MANAGEMENT 2
 PROTECT - MANAGEMENT

Version Control

Issue No Issue Date Issue Author Reason for Issue

V1.0 22 Jan 13 X PMO Re issue following a programme leadership review. Contains BUG, CIF and DR
Board ToR which remain unchanged

V1.1 29 Jan 13 X PMO Clarification of ‘procurement’ input to DA, minor amendments to decision making
levels

V1.2 15 April 13 X PMO Updated following announcement of new SRO and Programme Board, supports
changes in PSO resourcing

V1.3 15 May 13 X PMO Updates to reflect Delivery Board changes and changes in Programme
Resources

PROTECT- MANAGEMENT 3
 PROTECT - MANAGEMENT

Section 1

Governance

PROTECT- MANAGEMENT 4
 PROTECT - MANAGEMENT

1.1 - Programme Governance

Executive- Strategic Commercial

Departmental level direction Steering
Steering Group
Group

Programme Plan /
Product Approval Programme Board SMT
Go / No Go Decisions

Programme Business
Leadership User Group
Team

Design Delivery
Products Design Impact/ Approval Delivery Products
Approval Authority Escalations &
of Change Requests Board Approvals
within tolerance
Change
Impact
Forum*

Cross Tower Cross Tower

Towers
Review Review
*Change Advisory
Board Terms of
Reference on Pg 57

PROTECT- MANAGEMENT 5
 PROTECT - MANAGEMENT

1.2 - Steering Group

Aim: to provide strategic direction and departmental level approval of X Programme

Inputs: Outputs:
• X Financial Case •Produces minutes and actions
• Departmental level issues • Updates to Strategic Departmental levels Risks and Issues
• Level 1 Programme Plan

Members: Conduct of meeting:

Chair • Meets Monthly as required
X SRO
X Programme Director Proposed Agenda:
Interim CIO • Actions from last meeting
E Chief Procurement Officer • Review departmental level issues
client Procurement representative • Review programme status
R IT Director •Review strategic risks
R Business representative
Y IT Director
Decision making:
Y Business representative
• Approve Level 1 Programme Plans
XXX Business representative
• Approve X Financial Case
Interim client Agency B IT Director
client Agency B Business representative
Escalation:
client Internal Audit and Assurance
• Escalations from X Programme Board
HR representative
Secretariat

PROTECT- MANAGEMENT 6
 PROTECT - MANAGEMENT

1.3 - X Programme Board

Aim: to provide direction and approvals of X Programme Plan and Products, designed to be flexible and proactive to meet the challenges of approvals
and escalations.

Inputs: Outputs:
• X Products • Approvals of X Programme Plan and Products
• Programme Risks and Issues • Produces minutes and actions
• Commercial Products • Updates to Programme Risks and Issues Registers
• X Financial Case
• Legal issues
• Programme Plans

Members: Conduct of meeting:

X SRO & ICT Service Management Director • Meets Monthly
X Programme Director
X Finance SRO
• Extraordinary PBs to be arranged as required for key milestone Go / No
Interim client Chief Technology Officer Go decisions
Head of ICT Procurement
Secretariat

Proposed Agenda:
• Actions from last meeting
• Review issues and challenges
• Review programme and tower status reports
• Review strategic risks

Decision making:
• Approve / Monitor Programme Plans
• Approve X Programme & Procurement Products
• Approve Change
• Go / No Go decisions for key milestones

Escalation:
• Escalations included in report to FSG

PROTECT- MANAGEMENT 7
 PROTECT - MANAGEMENT

1.4 - X Design Authority

Aim: to provide control and direction in the development of the X solution to ensure integrity of the overall architecture, deliverability of the service levels and clarity of
information for bidders (scope covers both technical and service designs and operating model / organisation design considerations)

Inputs: Outputs:
• Change Requests (design) • Produces minutes and actions
• Architecture, IA, Service design and conformance papers • Updates to Solutions Issues Log
• Procurement products may be provided for information • Updates to Programme Risks and Issues Registers
• Dependency Register • Feedback / analysis from bidder engagements
• Solution Issues (formerly D&Q) log
• Solution Variance Reports
• Organisation Design products * (* Tower F products for information; sign off
achieved at SMT and/or Tower F Board)

Attendees: Conduct of meeting:

• • Meets weekly (Mondays)
• Lasts 1.5hrs
• Papers to be submitted min of 2 working days before the meeting
identifying whether they are for information (please scan) or approval
(please read)
• Authors of papers to confirm that they have received necessary peer
review prior to submission to the DA

Proposed Agenda:
• Actions from last meeting
• Review Solution Issues Log
• Review supporting papers
• Work priorities

Decision making: Out of scope:

• Approval of design related change requests • Delivery decisions (e.g. prioritisation of resources or changes to level
• Design changes and recommendations 1 milestones)
• Approval of procurement documentation is for CSG only

Escalation: Challenges and conflicts that cannot be decided in the meeting are to be escalated to the X Programme Board

PROTECT- MANAGEMENT 8
 PROTECT - MANAGEMENT

1.5 - X Delivery Board

Aim: to provide control and direction in the delivery of the X Programme and how most efficiently to secure the programme’s stated objectives

Inputs: Outputs:
• Change Requests (delivery) • Produces minutes and actions
• Level 1 and 2 Programme Plan • Updates to Programme Plan
• Level 2 Resource Plan (3mth look ahead) • Decisions on resource prioritisation
• Programme Delivery Report (produced weekly) • Updates to Programme Risks and Issues Registers
• Procurement products may be provided for information

Attendees Role at meeting: Conduct of meeting:

• Chair – Prog. Director • Meets Weekly (Monday)
Head of PMO • Lasts 1.5hrs
Tower A Lead
Tower B Lead Proposed Agenda:
Tower D & Tower C Lead • Actions from last meeting
Tower E Lead • Review L2 Programme Plan (Tower Plans)
Security Lead • Review Resource Plan
Tower F Lead • Review status of product delivery
Comms • Review Programme Issues
Secretary • Review Programme Risks (monthly)

Decision making: Out of scope:

• Approve programme plans, endorse contingency plan activities • Design and procurement related products
• Recommend (to programme board) plan baseline changes
• Resource prioritisation

Escalation:
• Routine reports are submitted to X Programme Board and to FSG

PROTECT- MANAGEMENT 9
 PROTECT - MANAGEMENT

1.6 - X Leadership Group Meeting

Aim: to provide control and direction in the delivery of the X Programme focusing on people, resourcing, general strategic direction and approaches to manage the challenges facing
the programme

Inputs: Outputs:
• Level 1 Programme Plan • Updates to Issues and Actions Log
• Level 1 Resource Plan & people management considerations • Staff Engagement Survey actions
• Line management of civil servants • General Communications
• Programme issue log
• People Survey results
• People / HR issues
• Staff Training & Development needs

Attendees (7): Role at meeting: Conduct of meeting:

• Chair: Programme Director • Meets weekly
• Lasts 1hr
Transition
Service Design • Meets monthly off-site
Finance Lead
Chief Architect Proposed Agenda:
Secretary • Actions from last meeting
• Review L1 Programme Plan
• Review Resource Plan and staff requirements
• Review Programme Issues

Decision making:
• Approve programme plans
• Endorse contingency plan activities
• Recommend (to X Programme Board) programme plan baseline changes
• Organisation changes
• Lines to take

Escalation:
• Raises issues to SRO, Programme Board, DA or DB for further action or consideration as required

PROTECT- MANAGEMENT 10
 PROTECT - MANAGEMENT

1.7 - X Business User Group Meeting

Aim: Primary business stakeholder forum for the Programme, which provides decisions on Business related matters to X; responsible for advising the Programme Board
on user requirements, key design products, implementation plans and rollout schedules that impact the business.

The BUG is both a source of information and data, and a conduit for messages into business areas; Outputs:
Inputs: • Updates to Issues and Actions Log
•X Information and Communication Technology (ICT) business requirements.; • Staff Engagement Survey actions
•X Architecture and Solution Requirements • General Communications
•X Strategy
•X Risks and Issues Log
•X Programme Plan
Conduct of meeting:
•X Transition Views and Plan
• Meets monthly
• Lasts 2hrs

Attendees (7): Proposed Agenda:

• NAME • TITLE • Minutes and actions (10 mins)
•NAME •TITLE • Key messages/updates on the X Programme from
the Chair (15 mins)
• Key messages/feedback from the Business (20 mins)
• Business Engagement - Forward Planning (20 mins)
• Spotlight session (20 mins)
• Upcoming approvals (10 mins)
• Change requests (10 mins)
• AOB (5 mins)

Role/ Decision Making

• To provide an impact assessment on those that would result in a change in scope and make a recommendation to the Steering Group;
• Advise the X Programme on business focussed performance measures for consideration as SLA/KPI’s

Escalation:
• Raises issues to DA or DB for further action or consideration as required

PROTECT- MANAGEMENT 11
 PROTECT - MANAGEMENT

1.8 - X Business User Group 2/2

Aim: Primary business stakeholder forum for the Programme, which provides decisions on Business related matters to X; responsible for advising the Programme Board
on user requirements, key design products, implementation plans and rollout schedules that impact the business.

The Logistics are that:

– The Business User Group will meet on a monthly basis as a minimum.
– Ideally the BUG will occur within the week leading up to the X Programme Board.
– From time to time there may be a need to form a sub group with selected members of the BUG plus others that meet more regularly and target a specific area.
– Advanced communication, ideally at least four working days, of decision making material is to be provided to BUG members prior to BUG meetings. This communication
will list those who have already been involved in its preparation.
– It is members responsibility to identify an appropriate nominee if they are absent. Should a decision maker send a nominee to the BUG either the nominee inherits the
decision making authority, or the BUG collectively makes a decision on behalf of the absent decision maker. Decisions will not be delayed.
– Any scheduling or planning decisions relating to transformation activities agreed at the BUG cannot be taken as final until ratified and approved by the Programme Board
and/or X Steering Group.
– Business raised at the BUG shall not be discussed with, or relayed to, external suppliers.

PROTECT- MANAGEMENT 12
 PROTECT - MANAGEMENT

1.9 - Meeting Structure Overview

Leadership Group Design Authority Delivery Board Change Impact Dependency Business User
Forum Register Forum Group
Programme

• Frequency: Weekly • Frequency: Weekly • Frequency: Weeklty • Frequency: Weekly • Frequency: • Frequency:
& Monthly All-day • Attendance: • Attendance: • Attendance: Weekly Monthly
• Attendance: • Programme • Programme • Cross Tower • Attendance: • Attendance:
• Leadership Management Management Leads • Cross Tower • Cross Tower &
Group • Cross Tower • PMO • Tower Leads • Service Design Tower Leads
Leads • Cross Tower • Team Leads Leads (Optional)
Leads • Business
• Tower Leads Representation

Architecture Forum Transition Team Service Design Service Management IA Working Group Delivery Co-ordination
Team Working Group
• Frequency: Weekly • Frequency:
Cross Tower

• Attendance: Fortnightly • Frequency: Fortnightly

• Attendance: • Frequency: • Frequency: • Frequency:
• Cross Tower • Attendance:
• Cross Tower Monthly Monthly Weekly
Architects • Full Cross Tower • Attendance:
Service Design • Attendance: • Attendance:
• Cross Tower IA Transition Team • Cross Tower &
Leads • Cross Tower & • PMO
• Tower Architects • Full Tower
• Tower Service Tower Leads Tower IA • Tower PSOs
• Tower IA Transition
Design Leads (Optional) • Enterprise • Comms
TeTower C
• Business Architecture and
Representation Information
Assurance
• client ICT IA

Tower A Team Tower B Team Tower E Team Tower D / Tower C Team Specialist Security OD&C
Team Team
• Frequency: Weekly • Frequency: Weekly • Frequency: Weekly • Frequency: Weekly • Frequency: Adhoc • Frequency: Weekly
Thursday Wednesday Wednesday • Attendance: • Attendance: Tuesday
Tower

• Attendance: • Attendance: • Attendance: • Tower D/ Tower • Security Team • Attendance:

• Full Tower A • Full Tower B • Full Tower E C • Full OD&C team
team Team Team

PROTECT- MANAGEMENT 13
 PROTECT - MANAGEMENT

Section 2

Organisation &
Functional Model

PROTECT- MANAGEMENT 14
 PROTECT - MANAGEMENT

2.1 - X Organisation / Functional Model

PROTECT- MANAGEMENT 15
 PROTECT - MANAGEMENT

2.2 - X Delivery Framework

The table below sets out the framework within which to view the key X delivery functions. Aspects of this
framework will change over time (for example Programme Board currently reports monthly). As the
programme progresses to Transition this framework will become increasingly more important as we
engage with suppliers and X FUNCTION

Ops cycle Plans Resourcing Configuration Change Control RAID Reporting /

Control Governance

Level 1 Monthly Portfolio Budget / skills / month Strategic risks and issues Initiate change (engage with Strategic X Steering Group
business)
(milestones)
Portfolio

Level 2 Fortnightly Programme TeTower C / phase / Document approvals Approve / Reject Change Programme X Programme Board
fortnight
(phases, milestones &
dependencies)
Programme

Level 3 Weekly Project Individual resource / Document Production Initiate change (engage with Project X Delivery Board
task / week suppliers)
(tasks)
Impact Assess
Project

PROTECT- MANAGEMENT 16
 PROTECT - MANAGEMENT

Delivery core processes

Below is a list of the core delivery processes, most are covered in this document others (e.g. Operational Change process) have been defined in the
X Schedules. Updates will be made on a regular basis.

Planning Change control

• Maintain Level 1 Portfolio Plans • Define a Contract change process: pre BAFO/ITQ
• Maintain Level 2 Programme Plans • Define a Contract Change process: pre award
• Maintain Level 3 Project plan • Define a Contract change process: post award
• Define an Operational Change process
• Reporting Actuals and Forecasts
• Maintain Planning Standards & Conventions
Reporting
• Manage Monthly Board Reports
RAID
• Manage Fortnightly Programme Status reporting
• Report on Strategic Risk Management
• Define Programme Risk and Issue Management Governance
• Review Project Level risk and issue management • Run and maintain approvals process
• Manage list of assumptions • Manage external stakeholder approval
• Maintain list of dependencies
• Maintain assumptions and dependencies to plans Resourcing
• Manage recruitment pipeline
Administration • Manage / track resource utilisation
• Review and manage skills requirements
• Onboarding new starters (client)
• Off-boarding leavers (client)
Configuration
• Maintain IT
• Manage product register
• Maintain facilities
• Quality assure documents & process
• Manage Information Assurance
• Define and maintain product approvals process

PROTECT- MANAGEMENT 17
 PROTECT - MANAGEMENT

Section 3

Reporting

PROTECT- MANAGEMENT 18
 PROTECT - MANAGEMENT

3.1 - Information Flow (principle delivery management flows only)

X Programme Board & X Reporting to
Steering Group
Plan updates &
changes via
Programme Management the Change
Advisory Board
X Design
Changes
Service may be
referred to
Function Governed by Design
Architecture Authority X Plans
Commercial Risk

Delivered L1
through Issue
Make up
the design Delivery POAPs CR
Board
Product sets L3 Plan progress
Report
to Plans
Created, owned,
owned by
maintained by
Product sets Towers /
Projects

PBS maintained Planning structure

NOTE: Diagram does not show all
by PMO (held maintained by PMO information flows or Project Boards
within SharePoint)
PROTECT- MANAGEMENT 19
 PROTECT - MANAGEMENT

3.2 - Reporting

PSOs Team QA by Tower Lead Team Leads

produce Reports
(weekly/as required)
R&I log and
project plans
Tower Leads Delivery Board Delivery Board
QA by PMO Lead
& PSOs Reports
(weekly)
produce

PMO Lead & Prog Board QA by Prog Mgr X Programme Board

Tower Leads Reports
produce (monthly)

PMO Lead & Stg Group QA by Prog Dir X Steering Group

Tower Leads Reports
produce (monthly)

PROTECT- MANAGEMENT 20
 PROTECT - MANAGEMENT

3.3 - Weekly Reporting Cycle

Report generation process

Notes:
(1) Mon-Wed teTower C progress against the work plan set the previous week; (2) PSOs make updates to actual plan and highlight any issues /
replanned activities, also noting implications for resource demands; (3) PSOs aim to have reports finalised by 1600 for review in the Delivery
Coordination meeting and to prepare upward reports (4) PMO distribute Delivery Board report as well as level 2 plans and programme director’s
weekly brief

PROTECT- MANAGEMENT 21
 PROTECT - MANAGEMENT

Section 4

Planning

PROTECT- MANAGEMENT 22
 PROTECT - MANAGEMENT

4.1 - Planning Levels

What Who For

A schematic plan on a page showing key activities, Level Portfolio Level – key stakeholders and suppliers;
Level 1 milestones and dependencies Weekly refresh cycle, reported monthly
1

Level
Programme Level – principally programme leadership,
A Programme Gantt Chart with full
resource utilisation and export
2 Programme and Delivery
Boards;
to cost forecasting
Weekly refresh cycle, reported weekly / monthly

Level 3 Project Level – programme and Project

Project Gantt Charts with full resource
leadership and all staff;
utilisation
Daily refresh cycle

PROTECT- MANAGEMENT 23
 PROTECT - MANAGEMENT

4.2 - Planning Products

Level 1
Programme
Plan (Schematic)

Level 1
Key phases and level 1 milestones
Programme extracted from Level 2 and 3 plans
Milestone Log
Level 2
Programme
Level 1 Plan (Gantt)
Programme
Dependency Log
Status of work informs progress through
Level 3
Level 2 – managed by Planning Manager
Integrated Programme and endorsed by Tower Leads
Plan

Level 3 plans are aggregated by the

Planning Manager into a single
Integrated Programme Plan

Level 3 Tower Plans

PROTECT- MANAGEMENT 24
 PROTECT - MANAGEMENT

4.3 - Baseline, Forecast and Actual Plans

Baseline Plan

When Programme / Project Plan Change Requests (CRs) have been approved internally by programme
leadership an updated Level 1 Programme Plan (and the CRs) will be submitted to the X Programme Board
for approval – once approved the plan will be up-rated to the next baseline

Forecast (Most Likely Outturn – MLO) Plan

Represents the most up to date, best estimate forecast of work, outputs and milestones given the current
view of risks and issues and progress

Actuals
The Actual outputs are measures of progress against the tasks agreed in the latest baseline version of the
plan

For reporting purposes X will report on Baseline Position, MLO and Actuals to Date

PROTECT- MANAGEMENT 25
 PROTECT - MANAGEMENT

4.4 - Updating the Level 1 Programme Plan

 The Level 1 Programme Plan is a living document and is subject to regular change.
 To ensure the Programmes’ baseline is properly managed, it may at times be necessary to maintain two versions of the Level 1 Programme Plan. In any such scenario the
versions maintained are:
 Level 1 Programme Plan – Baseline
 The Baseline version of the plan reflects the approved position, this is an input into other key X programme products.
 Level 1 Programme Plan (Most Likely Outturn)
 Reflects the current unapproved position, or current forecast.
 Is updated each week from the planning information held in the level 3 project plan submissions.
 Once any changes are formally approved the “MLO” becomes the next Baseline version of the plan.

4 - Followings it’s approval the 3 - Following approval of the CR

2 - A formal Change Request
Level 1, 2 & 3 plans are at a Programme level the change
process is initiated
rebaselined. goes for wider approval

V4.0 V5.0 V6.0

Level 1 Programme Plan Governance Governance Governance
& Approval & Approval & Approval
– Baseline (Approved
Position)

Change Change Change

Plan Re- Plan Re- Plan Re-
Control Control Control
Baselined Baselined Baselined
Process Process Process

Level 1 Programme Plan

– Forecast (Most Likely
Change to Baseline Change to Baseline Change to Baseline
Outturn) Plan Identified Plan Identified Plan Identified

1 - A change to a level 1 milestone is identified

PROTECT- MANAGEMENT 26
 PROTECT - MANAGEMENT

4.5 - Updating the Level 2 Programme Plan

The Level 2 plan will be maintained in a separate file from the highly detailed Level 3 plan and Level 1 Plan on a Page. On a weekly basis the changes
are not anticipated to be extensive and for plan changes will need to be accompanied by a CR

1. The Resourcing Manager will collate

updates to the recruitment pipeline
1 whilst the Planning Manager will
Mon – Wed
collate level 3 updates from PSOs
Collate updates and changes to previous week and revise the Level 2 Plan
(Resourcing & L3 Plan updates) 2. Resourcing Manager and Planning
Manager will meet to review their
2 respective changes and agree the
final plan / resourcing position
Thu
3. By 1600hrs every Thu the Level 2
Revise the Level 1 Plan and produce plan will be ‘frozen’ and a source
source data file data file (Resource Utilisation Report
3 from the Plan) will be submitted to
the Resourcing manager and
Finance Manager
Thu / Fri Thu / Fri
4. On Fri the Resourcing Manager and
Prepare report Prepare report
4 Finance Manager can manipulate
(Resourcing) (Finance) the source data file to prepare
reports for the Programme Director.
5. Fortnightly / monthly the Planning
Manager will also prepare an Earned
5 Value report to show plan/budget
progress

PROTECT- MANAGEMENT 27
 PROTECT - MANAGEMENT

4.6 - Updating the Level 3 Project Plans

 Each week the PMO takes temporary ownership of the level 3 project plans so that a number of Governance and Reporting activities can be undertaken.
 All level 3 project plans are updated in accordance with the X Programme Planning Standards by Wednesday close of business each week.

PROTECT- MANAGEMENT 28
 PROTECT - MANAGEMENT

4.7 - Planning Tolerances – RAG Statuses

 The X Programme uses RAG statuses to high-light the severity of any milestone date slippages.
 The RAG status returned in the level 2 and 3 programme and project plans is an objective measure and is calculated by assessing the variance
between the baseline finish date and the current forecast finish date (schedule slippage).
 A field has been customised in MS Project which returns a RAG status for all milestones in real-time. Automating the RAG statuses process
ensures there is consistency across the Programme while restricting the level of subjectivity.
 Level 2 Programme Plan RAG Tolerances

 Level 3 Project Plans RAG Tolerances

 Where a level 1 milestone returns an Amber RAG status the Risk Id (from the Risk Log) can be seen in the “R&I ID” column.
 Where a level 1 milestone returns a Red RAG status the Issue Id (from the Issue Risk Log) can be seen in the “R&I ID” column.

PROTECT- MANAGEMENT 29
 PROTECT - MANAGEMENT

Further Information

Further planning information and guidance will follow to cover the topics set out below:

• Earned value Management

• Reporting actual status
• Links with resourcing
• Tower Leads responsibilities to manage against a budget
• FAQs
• Assumptions
• Planning Standards & conventions

PROTECT- MANAGEMENT 30
 PROTECT - MANAGEMENT

Section 5

Dependency
Management

PROTECT- MANAGEMENT 31
 PROTECT - MANAGEMENT

5.1 - X Dependency Management – 4 types

External to X
Plan Dependencies Design Dependencies
Technical,
Internal, between
interoperability, IA,
Towers Programme POAP Solution Issues design and scope
boundary type
questions
Tower / Project

Notifications and
requirements on the
Contract Dependencies Contractual Dependencies
Noting the dependency
existing supply base e.g. mapping between X
Inter-Schedule dependencies
notice period, exit contract schedule pre
Incumbent Requirements (lvl 4,5) – covers Sch 2.1, 3.1,
provisions 3.2 (not Sch 2.2 as yet) and post contract
award covers Sch 2.1,
Authority obligations to
Changes to existing service Solution variances 3.1, 3.2 (not Sch 2.2 as
Existing supply base
requirements yet)

Solution variances
managed via the RAD
process until preferred
bidder stage where
variances of preferred
bidder are incorporated

PROTECT- MANAGEMENT 32
 PROTECT - MANAGEMENT

5.2 - Programme Management Tools

POAP AND Lvl 2&3 MSP (New) PMO Arch & IA Solution Issues Log

REVIEWER : REVIEWER : DA
CONTENTS: Plan Dependencies Design Dependencies CONTENTS:
• ‘Hard’ inter project •‘Soft’ inter
dependencies only dependencies
• External
Programme POAP Solution Issues •Design
interdependencies •IA
•Tech
•Scope
Tower / Project

Dependency Register
NEW: TBA
Contract Dependencies Contractual Dependencies Tower-specific RAD Registers

Incumbent Requirements
Inter-Schedule dependencies REVIEWER : DR Review
REVIEWER : TBA (lvl 4,5) Board
CONTENTS:
• Dependencies listed as CONTENTS:
milestones across New Supplier Requirements • Contractual
existing contract based interdependency log lvl
(XCEL or MSP) 3,4,5

Exit & Legacy Requirements Team

PROTECT- MANAGEMENT 33
 PROTECT - MANAGEMENT

5.3 - Plan Dependencies

• A dependency is a logical relationship between work items which defines the sequence in which the work can be completed.
• While the vast majority of dependencies are contained within a project there may be occasions where a product, or the outcome of a completed activity is needed by another
project.
• The Product and Activity Dependency Management Process has been set-up to manage such occurrences.
• The purpose of the Product and Activity Dependency Management Process is to ensure a dependency link exists between project plans so any timeline movement can be
recognised, applied to a corresponding dependency milestone and impact assessed.

o Outbound Dependency enables the start or continuation of another project’s work.

o Inbound Dependency enables the start or continuation of a piece of work. An outbound dependency milestone
• Both inbound and outbound dependencies require the inclusion of a
milestone in a level 3 project plan.
• By including all inbound and outbound dependencies in the level 3 project plans a view of the Programmes’
Product and Activity Dependencies can be generated.
• This view is the Dependency Log.

An inbound dependency milestone

• The Dependency Log is sourced from the level 3 project

plans and ensures the dates for outbound and inbound
dependency milestones are aligned.
• In this instance Product 1 has no date conflict while
Product 2 has a date misalignment.

A dependency date conflict

PROTECT- MANAGEMENT 34
 PROTECT - MANAGEMENT

5.4 - Plan Dependencies

• It is vital to have a record of the X dependency on client ICT project delivery. If X is basing any decisions on the assumption that something will be in place by the time
X starts its transition, we need to capture this information and monitor the progress of these client ICT projects.
• This is to ensure change in timeline or scope from the client ICT project can be monitored and where necessary impact assessed against the X assumptions made.
• In the context of the X Programme, this client ICT project dependency is an enabler for X, i.e. X is relying on it being in place so that X does not need to do it.
• These dependencies need to be actively managed via the Intercept Assessment sessions.

Initiatives are captured on the intercept index and evaluated whether

they require an assessment.

The intercept index will include initiatives from innovation, RFS

management, business directorates, Service management and
Enterprise Architecture and Information Assurance

The impact on towers will be identified at the intercept assessment

sessions.

PROTECT- MANAGEMENT 35
 PROTECT - MANAGEMENT

5.5 - Plan Dependencies

• To avoid the inclusion of too many inbound/outbound dependency milestones they should only be included for the formal publication of a product from one project to another
only. They should not, for example, be included for the review of a product.
• Every inbound and outbound dependency milestone must have a corresponding milestone in another level 3 project plan.
• An outbound dependency milestone may feed into one or more inbound dependency milestones.
• An inbound dependency milestone should have one corresponding outbound dependency milestone. Where a product or activity has multiple dependencies, multiple
dependency milestones must be created.
• A delayed dependency milestone which causes a level 1 milestone to slip is subject to formal change control.
• The following guide shows how to include a Product or Activity Dependency milestones into a level 3 project plan:
LINK DELETED

PROTECT- MANAGEMENT 36
 PROTECT - MANAGEMENT

Section 6

Resource Management

PROTECT- MANAGEMENT 37
 PROTECT - MANAGEMENT

6.1 - Resource Management Overview

Overview. Key roles and responsibilities

1. Each tower / team will have a dedicated resource coordinator in the main 4. The RACI chart below explains the key tasks and role
these are the PSOs for each tower assignment in the conduct of resource management:
2. PSOs are required to maintain project level resource plans under the
direction of the Project Lead. Project Resource Plans will be derived from
Resource PSO X Twr PSO Programme
the activities, delivery schedule and requirements detailed in the Project Manager Manager
Plan. Changes to the Project Resource Plan (or any anticipated
resourcing risks or ongoing issues) should be reported via Highlight
Identify / change I A/R C
Reports to the PMO. The PMO provide Programme resource information need
to the X Resourcing Manager and the Programme Manager. The PMO
and the Projects will be responsible for the demand-side of resourcing.
Confirm resource I C A/R
availability
3. The Programme Manager, supported by the X Resourcing Manager, will
have overall responsibility for the review and maintenance of the
consolidated Programme Resource Plan. This will provide an overview of Impact I I A
assessment
Programme resource requirements across all Projects. The Programme
Resource Plan will be aligned to and be reflected in the overall
Programme Plan. Prioritise on I I C/R A
conflicts

5. PSOs are accountable and responsible for regularly

reviewing their plans and determining any new or
revised resource requirements

6. Meetings are held twice weekly in addition to 1:1

sessions to establish an accurate view of resource
demand and supply

PROTECT- MANAGEMENT 38
 PROTECT - MANAGEMENT

6.2 - Process: Resource Management

Overview.
The following notes refer to the process chart opposite:
1. The aim is to have good visibility from the L3 plans out one Quarter and improved visibility over a 4wk look ahead
2. PSOs are to email cross Tower PSOs with a snapshot of the resource plan showing current utilisation and their proposed new demand clearly indicating the changes
3. The resource owner can conduct an impact assessment on the new / changed demand; equally this may also include the planning manager to identity any additional programme constraints or issues
4. Resource conflicts may be raised at any time to the PMO lead or Programme manager – a decision will be taken by Thu midday in order to finalise any changes to plans, update reports and in time for the requesting team to brief the individual(s) involved
5. Updates to L3 plans and Resource plans will likely happen throughout the week however 1200 Thu are the formal freeze points

PROTECT- MANAGEMENT 39
 PROTECT - MANAGEMENT

6.3 - Tracking resource utilisation and demand

Overview.
The programme will run a resource tracker spreadsheet in addition to the programme plan

This tracker will allow for a day by day breakdown of resource utilisation which will more readily enable over-allocations to be
identified and for changes to be included

The resource tracker can be found on the team site at:

Use of Resource Tracker

The Resource tracker allows a day by day breakdown of resource utilisation as

Further resource management information and guidance well as booked leave/training which more readily enables over-allocations to
will follow to cover the topics set out below: be identified and for changes to be included. It is used to:

• Record time demands from Towers against individual resource

•Use of resource tracker • Record leave and training
•Recruitment pipeline • Resolve contentions through discussions at PSO Level
•Standards and conventions used in Level 2 Plan • Provide high level management information which feeds into Delivery Board
including escalations on resource prioritisation

PROTECT- MANAGEMENT 40
 PROTECT - MANAGEMENT

Section 7

Risk and Issues

Management

PROTECT- MANAGEMENT 41
 PROTECT - MANAGEMENT

7.1 - Risk Management Overview

 The X risk management approach is based on the client Corporate and client ICT risk management processes. There have been some
adjustments to templates to facilitate the needs of X, but all should be aware of the client Corporate Risk Management Policies located at:
 The process provides early warning indicators that enable proactive resolution of potential problems. A key control is the use of a single risk
register for the entire Programme based on the standard client Risk Register.
 Each risk will be assessed using the X Programme Risk Assessment Criteria (based on the client RAC) which considers impact and
likelihood. Once risks are rated and logged they will be tracked via a regular review cycle and relevant risks will be escalated using agreed
tolerance levels for both awareness and resolution ratification. There are a number of risk related roles defined for the programme.
 The formal outputs of the risk process will come in the form of the Risk log and the Risk & Issue Programme Board Metrics.
 It is important to recognise the correlation between risks, issues and the fact they often generate a change request out of the
mitigation/resolution response.

Risk (Future): Issue (Now): Change:

Risk is defined as the uncertainty of outcome of actions or events. An issue is an event that has happened and will definitely have an
A change request can often be generated out of the response to
A risk is something that has the potential to occur but has not yet impact on an element of a project or a programme in terms of
an Issue.
occurred, e.g. there is a risk of the project overspending on cost time, cost or quality.
due to potential increases in the price of steel. This then feeds into the Change Control Process.
A statement of a risk should encompass the cause of the impact, An issue could have been previously noted on the register and
and the impact to the objective (“cause & consequence”) which been subsequently realised or could have been an unforeseen It is expected that the majority of Change Requests will already
may arise. Care should be taken to avoid: event, e.g. A project has significantly overspent on cost due to an have risks and/or issues logged in relation to them, thus meaning
•Confusing potential impacts with risks increase in the price of steel. In this case you would reclassify it to very few CRs should be a surprise.
•Stating risks which do not impact on objectives an Issue on the register.
•Defining risks by simply stating the opposite of the objective

PROTECT- MANAGEMENT 42
 PROTECT - MANAGEMENT

7.2 - Risks and Issues Management Process

Fortnightly DA Risks &
Risks & issues Issues reviews, look at
Updates made
identified by anyone ‘reds & blacks’
by PSOs
on the programme

Risk & Issue Monthly Risks & Issues

Log reviews for RAID Mgr &
Feed Tower Leads
into

Prog Board Steering Group

Highlight Reports Reports Reports

PROTECT- MANAGEMENT 43
 PROTECT - MANAGEMENT

7.3 - Risk & Issue Management - Your role

All members of the programme team and all programme stakeholders have a responsibility for being part of the Risk & Issue process and
identifying risks/issues, there are also some specific Risk & Issue (R&I) roles identified within the programme.

Risk & Issue Risk &

Risk & Issue
Explanation Awareness Issue
Roles
Level Ownership

Cross-Tower & Responsible for raising Risks & Issues as you see them arise and bringing them to the attention of All Risks Green
Tower Team your Tower Lead/PSO. Attending all Tower specific Risk & Issue review session
Members Providing updates to mitigation/resolution activity where you are the owner of that action

Project Support Responsible for capturing of all R&I items at individual project level. This includes driving the All Risks None
Officers assessment of each item and mitigation monitoring.

The Risk or Issue Owner has responsibility for ensuring the risks assigned to them have clear All Risks All
Risk or Issue
mitigation/resolution plans and are being actively progressed.
Owners
The Risk Owner does not necessarily do all the analysis and mitigation work.

This is each Project Lead. This person is ultimately responsible for R&I on the project and ensuring All Risks Green
Project Risk
(with the PMO RAID Manager) that Project level R&I items above the prescribed thresholds are
Champion
flagged at programme level.

Programme This is the X Programme Manager. This person is ultimately responsible for R&I on the X All Risks Green,
Risk Champion Programme – this includes tabling all Red & Black rated items at Programme Board. Amber

Programme Has a R&I oversight role. Responsible for tabling all Red & Black rated items at Steering Committee. Black, Red Red
Director

Notifying the Programme Management of any external risk exposure to the project. Black, Red Red
Programme Striking a balance between the level of risk and the potential beneX that the Programme may
Board achieve. Notifying Steering Committee/Programme Management of any risks/issues that affect the
project’s ability to meet Departmental, Strategic or programme objectives.

Notifying the Programme Director/Programme Board of any external risk exposure to the project. Black, Red Black
Programme
Striking a balance between the level of risk and the potential beneX that the Programme may
Steering
achieve. Notifying client Leadership/Cabinet Office of any risks/issues that affect the project’s ability
Committee
to meet Departmental, Strategic or programme objectives.

Responsible for the administration and driving of the R&I process across the programme and owns All Risks None
RAID Manager the R&I log – This person is not personally responsible for managing/owning individual risks
and issues. Pro-actively embed risk management behaviours into X at governance layers.

PROTECT- MANAGEMENT 44
 PROTECT - MANAGEMENT

7.4 - Risk Identification & Assessment

Identification
 Risks will be identified in one of three ways:
1. Structured Weekly Project/Programme RAID Reviews – At programme level and at individual project level
there will be a Monthly R&I review session led by the RAID Manager at the Programme level and as part of the
Tower Team meeting by the Project PSO
2. All Risks and Issues will be tabled as part of the weekly Delivery Board Report.
3. Planned Risk Workshops – The RAID Manager will initiate and facilitate a schedule of Risk Workshops with
various stakeholder groups across the programme. These workshops will continue at key gateways throughout
the life of the programme.
4. Ad Hoc – As on any programme or project there will always be occasions where a new risk is recognised by an
individual or group as the programme. It is the individuals’ responsibility to raise this risk with either their
Project Support Officer or the Programme RAID Manager.

 All risks will be logged and tracked via the risk section of the RAID log and reported in 2 forms – 1) Risk Register
Snapshots and 2) they will be fed into the project and programme weekly/monthly reporting cycle and appear on the
weekly Delivery Board reports.

Risk Assessment
 All risks will be assessed using the X risk assessment criteria matrix. Each risk should be rated across all 5 of the
impact types within the matrix and against the probability ratings.
 Once risks are rated against the assessment matrix they will automatically fall into a ‘risk rating’ category of either:
1. Very Low (Green)
2. Low (Green)
3. Medium (Amber)
4. High (Red)
5. Very High (Black)
 These categories drive risk awareness levels within the programme and subsequently they drive ratification levels for
recommended resolutions.

PROTECT- MANAGEMENT 45
 PROTECT - MANAGEMENT

7.5 - Risk Impact & Likelihood

Impact Types
 The assessment criteria matrix defines 5 impact areas that risks should be rated against – 1) client Business Impact,
2) Reputation, 3) Schedule, 4) Financial, and 5) Compliance/Security/Data
 The impact area that rates the highest against each risk should be the one used to register an impact level against
that risk. The impact assessment approach is aligned to client standards.

Likelihood Rating
 The likelihood of a risk occurring
is measured on a scale of 1-5 in
estimated percentage terms. The
5 likelihood levels are as follows:
1. Very Unlikely (<5%)
2. Unlikely (6-20%)
3. Possible (21-50%)
4. Likely (51-80%)
5. Very Likely (>80%)

Clearly the rating for Impact and

Likelihood can be very subjective –
it is therefore important that the risk
assessment activity is performed in
a collaborative manner to ensure a
reasonable rating. The X Risk
Assessment Criteria Matrix is shown
here.

PROTECT- MANAGEMENT 46
 PROTECT - MANAGEMENT

7.6 - Risk Management Outputs

The Risk Register The Programme Board Metrics

 The Risk and Issues Register captures all Risks for the programme.  The Programme Board Metrics
 This workbook is owned and managed by the RAID Manager from a provides a monthly summary
programme perspective and will be used as the tool for capturing weekly RAID of the key R&I elements for
updates. the programme.
 Project Support Officers and the RAID Manager will create and update risks in  The progress and trend of R&I
this log. is captured by this mechanism
 The register is made up of multiple tabs, an accepted risks tab and a reporting Today's Date 23/03/2012

tab.
Risks Exposure Current
Black 8
Red 28
Amber 55
Green 18

 Template is in the client ICT standard format

Risks Trend 30-Sep-11 31-Oct-11 30-Nov-11 31-Dec-11 30-Jan-12 29-Feb-12 31-Mar-12 30-Apr-12 31-May-12 30-Jun-12
Black 8 8 8 8 8 8
Red 28 28 28 28 28 28
Amber 55 55 55 55 55 55
Green 18 18 18 18 18 18

 It is accessible in Read Only format by all Team members on SharePoint: Issues Exposure
Red
Amber
Current
0
5
Green 0
Issues Trend 30-Sep-11 31-Oct-11 30-Nov-11 31-Dec-11 30-Jan-12 29-Feb-12 31-Mar-12 30-Apr-12 31-May-12 30-Jun-12
Red
Amber
Green

Risk Trend Issue Trend

60 1

50

40
Black

# Issues
Red

# Risks
Red Amber
30
Amber Green
20 Green

10
0
0

2
01

01

01

01

01

01

01

01

01

01
9/2

0/2

1/2

2/2

1/2

2/2

3/2

4/2

5/2

6/2
1
1

2
1

12
11
p-1

v-1

b-1
c-1

n-1

ar-
ct-

/0

/1

/1

/1

/0

/0

/0

/0

/0

/0
No

De
Se

Ja

Fe

01

01

01

01

01

01

01

01

01

01
O

M
Current Risk Exposure
5 0 0 0 0 0
Current Risk Exposure
{=SUM(IF(Risks!$B$4:$B$13=4,IF(Risks!$C$4:$C$13=3,IF(Risks!$F$4:$F$13="Open",1,0))))}
4 0 0 2 0
3 0 0 4 1 0
6 2 0 0 0 0 0
1 0 0 0 0 0
5
Impact 1 2 3 4 5
Likelihood
4 2
Shows the number of risks in each category

Impact
3 4 1
Key for RAG Status
5 10 15 20 25
2
4 8 12 16 20
3 6 9 12 15
1
2 4 6 8 10
Impact 1 2 3 4 5
0
Likelihood
0 1 2 3 4 5 6
Explains how the multiple of Impact x Likelihood equates to RAG status
Likelihood

Current Risks Age Current Issues Age

Risks Age Issues Age

8 3
8 3
7

6
2
5

3
1
2

1
0 0 0 0 0 0 0 0
0 0
<1 Week <1 Month >1 Month >2 Months >6 Months <1 Week <1 Month >1 Month >2 Months >6 Months

Risks Age <1 Week <1 Month >1 Month >2 Months >6 Months Issues Age <1 Week <1 Month >1 Month >2 Months >6 Months
# Risks 0 0 0 0 8 # Issues 3 0 0 0 0

PROTECT- MANAGEMENT 47
 PROTECT - MANAGEMENT

7.7 - Issue Management

Issue Management Description and Roles
 Issue Management is based on the premise that an Issue was a Risk that has since materialised and presents a
current and detrimental threat to the Programme. On occasion an issue may arise that was an unforeseen event.
 It is important to recognise the correlation between risks, issues and the fact they often generate a change request
out of the mitigation/resolution response.
 The roles identified in the roles slide apply to Issues also. This covers awareness levels and also levels of response
ratification.

Issue Management Process

 Issues should be logged in X RAID Log by the PSOs or RAID Manager, and then escalated as per the escalation
levels outlined in the roles section
 Thereafter Issues should be managed in the same way as Risks, as set out in the X standard for Risk and Issue
Management.
 Issues are subject to a simplified Impact assessment based on a High, Medium & Low scale.
 The ‘Likelihood’ assessment is not relevant for issue management, as the problem has now materialised.
 Anyone may be the originator of an Issue, but they should ensure that:
 Issues are identified and recorded clearly
 Issue Logs are used to document issues properly
 Determine the impact of each issue
 Prioritise issues and report on their status
 Review all issues and decide on a course of action / escalation requirements
 It is important to note that a response to an Issue may initiate a Change Request. In these cases the change will get
fed through the formal Change Process

PROTECT- MANAGEMENT 48
 PROTECT - MANAGEMENT

7.8 - Issue Management and Assessment Criteria

 The core outputs of the Issue process are the Issue Log and potentially the initiation of Change Requests.
 The Issue log captures all Issues across the programme. It contains multiple Tower tabs, a Programme wide Tab
and a consolidated view.
 This workbook is owned and managed by the RAID Manager from a programme perspective and will be used
as the tool for feeding into the weekly Delivery Board report.
 Project Support Officers and the RAID Manager will create and update Issues in this log for discussion with the
Project Leads, Programme Manager, Programme Board and Programme Steering Committee as appropriate.
 It is accessible in Read Only format by all Team members in the X shared folder structure:

PROTECT- MANAGEMENT 49
 PROTECT - MANAGEMENT

Section 8

Change Control

PROTECT- MANAGEMENT 50
 PROTECT - MANAGEMENT

8.1 - Change Approval Process

Decision Inputs Friday Monday 10:30-12:30 Mondays Weekly Monthly (or by

exception)

Changes to
L3/L4/L5 Dependency
Service Requirements Register
Review Board Impact Assessment
Service Register Changes
of Service register
changes
Changes to
Milestones L1/2
Transition ‘Strawman’
1. All Programme
Change
Changes to
Change requests
Impact
Negotiation Positions Forum Escalate for approval -
2. All Negotiation all change requests
Changes to Change requests impacting X Business
Financials Case/ X / Service Levels/
Level 1 milestones/
Changes to Solution Design/ Scope
Scope/ Requirements

Delivery Board
Change Approval Or Design
Authority

Escalations
Change Approval
Business Impact Programme
Board
PROTECT- MANAGEMENT 51
 PROTECT - MANAGEMENT

8.2 - X Change Tolerances

Plan/ Transition 3 4
Change 1. 2 5
• Zero days tolerance for any X Service Plan/
Authority Financial Commercial Scope Solution
Programme Level Transition
Plan Level 1 milestones
• 10 days variance from baselined Only L3/ 4/5
milestones Dependency
Reqs if no
Register No No No No
for non Level 1 milestones impact on
Review Board
• Zero tolerance for changes to X 1/2/3
Transition phasing/ strawman
Minor Minor Minor
Minor changes
Change changes if changes changes no
Service levels No if no impact
Advisory Board no impact on no impact Level 0/1
• Any proposed change to X Service 1 on 1/2 milestones
on 1/2/3/4
Levels/ Service Credit Model are
subject to change control Yes Level 1
Delivery Board No No No milestones Yes
escalated
Financial
• Zero tolerance for any changes
impacting the X Business Case Design
No No Yes No Yes
Authority

Scope /Solution
Programme Level 1
• All of the following are subject to Board
Yes Yes Yes
Milestone
Yes
change control:
– Baselined Programme/ Project PIDs X Steering Level 0/1
Yes Yes Yes Yes
– Solution/ architecture changes Group Milestone
– Requirements changes
– All baselined products in the X
Product Register

PROTECT- MANAGEMENT 52
 PROTECT - MANAGEMENT

4. Dependency Register Review Board

Set up and Objectives

Attendee Delegate
*Review and assess impact of all changes/ new
requirements and changes to the Dependency X Y
Register collated by the Requirements Team (Chair)

• Assess impact of proposed changes to the Service X (CIF representative) Y

Register X (Transition Architect) Y

• Meet on a weekly* basis
X (Enterprise Architect) Y
• All attendees must have delegated authority to sign
off changes in the meeting X (Service Design Lead) Y

• Decide approval / rejection of L3/L4/ L5

X (Service Design Lead) Y
Requirements changes in the meeting which have
no impact on any of the following: X (Service Design Lead) Y

• No impact on X Business Case X (Service Design Lead) Y

• No impact on Service Levels
X (Service Design Lead) Y
• No impact on Solution Design
• No impact on X Programme Plan/ X (Tower Rep) Y

Transition X (Programme Finance) Y

Recommend approved changes to the CIF via an
updated Change Request Table (CRT) Dependency X (Commercial) Y

Register Changes

Inputs * 01/10/2012 CIF agreed that no changes to requirements in schedules (outside of

schedule 2.1) can be made without formal change control (escalation to the
• Requirements CRT
CIF). This means requirements can not be moved from one schedule to another
Outputs without escalation. The DR Board only has the authority to agree requirement
changes within a schedule not the authority to move them to another schedule
• Updated CRT with actions for each Tower

PROTECT- MANAGEMENT 53
 PROTECT - MANAGEMENT

5. Change Advisory Board

Set up and Objectives Attendee Delegate

• Approval of all X changes with no impact to:
X Y
1. X Business Case
X Y
2. X Service levels X Y
3. X Overall Solution Design X Y
4. X Scope X Y
X Y
5. X Level 1 milestone
X Y
6. X Transition X Y
• Cross Programme change impact
assessment before submission to the Design
Authority for further approval of all changes
out of tolerance.
• Review all changes/ new requirements to the
Dependency Register
• Meet on a weekly* basis
• All attendees must have delegated authority
to sign off changes in the meeting
• Decide approval / rejection/ escalation of the
changes to the Design Authority

Inputs
• Requirements Change Request Table (CRT)
• X Change Requests
• Commercial Negotiations positions
Outputs
• Approved/ Rejected Change Requests
• Cross Programme Impact Assessment

PROTECT- MANAGEMENT 54
 PROTECT - MANAGEMENT

Section 9

Configuration Management

PROTECT- MANAGEMENT 55
 PROTECT - MANAGEMENT

9.1 - X Configuration Management

Why is this important with the X Programme?

The X Programme is a highly complex programme based on a multiple Procurements delivering one Target
Operating Model underpinned by the X, Schedules and Service Level Framework. In order to ensure delivery
the X Programme has to control all its products across Towers to ensure consistency and conformance.

The objectives of the document are to:

1. Define the X Configuration Management Model and high level product tracking
SharePoint:
2. Breakdown of the Configuration Management Process
The aim of the document is
to set out the discipline
3. Confirm the roles and responsibilities within X Programme
and administration of
Products which will provide
a sound basis for the
migration to SharePoint

APPENDIX
A. client ICT Configuration Management Definition
B. Protective Marking Guidance

PROTECT- MANAGEMENT 56
 PROTECT - MANAGEMENT

9.2 - High Level Configuration Process andProd

Product Tracking
uct
Prod
Prod Statu
Prod uct
Process

uct s
Stages

uct Verifi
Identi Acco
Contr catio
ficati untin
ol n&
on g&
Audit
Repo
rting
Baselined products/Updated Plans,
Outputs
Inputs

New Products / Product Status Reporting/

Change Requests Product Action Plans,
Configuration
Management

X Programme Tower
Assign Product ID/
Product Register Product
Name document/ (see appendix C)
Registers
Assign Protective Marking (see appendix C)
Roles and
Interfaces

X Configuration Tower PSO update Product

Manager Update ( Tower Configuration = Tower PSO)
Owners

PROTECT- MANAGEMENT 57
 PROTECT - MANAGEMENT

9.3 - Product Identification

Step 1: Identification of Products

• When new products/changes to existing products are identified a product description should be written/updated.
• New products should be categorised as the quality review / sign off criteria may be different on each (further
guidance is provided in this pack on page 65).
• Within the X programme, there are three different types of products and all of these products are subject to
Configuration Management and are controlled via the X Programme Product Register. These are:

Programme/ Cross Tower/ Procurement Products /

Tower Management Products X Solution Products Schedules

e.g. A Management product such as e.g. A Cross Tower product e.g. A Contractual Product, such as
‘Tower Plans and Project Initiation Such as ‘Solution Blueprint’ or X ‘Schedule 2.1, PQQ Evaluation Reports’
Documents (PIDs) Conceptual Architecture, FOM’

1 2 3

Step 2: Assigning a Unique Product ID

• Product owners send Product Description(s) to Tower PSO
• Product owner raise Change Request as per X Change Process to add to X Programme Product Register Y:\11
PMO Programme Management\11 Change Control
• Change request approved, Programme Configuration Manager assigns Product ID
Prod
uct
Prod
Prod Statu
Prod uct
uct s
uct Verifi
Ident Acco
Cont catio
ificati untin
rol n&
on g&
Audit
Repo
rting

PROTECT- MANAGEMENT 58
 PROTECT - MANAGEMENT

9.4 - Product Identification, cont’d…

Step 3a: Naming and protectively marking the Product

• All Products must be assigned a Product Name which directly mirrors its name in the X Programme Product
Register
• A version control sheet must be created which contains the following information
• Version Number Vx.x and Unique Product ID taken from the X Programme Product Register Twr-xxx
• When a Product is created it should be v0.1 and when baselined for the first time it should become v1.0. All
further changes should be saved in increments and the version number rounded to the next whole number when
next baselined.
• Version numbers will be controlled through the X Programme Product Register and Product Version Control
Sheet
• Version numbers must be recorded in the File Properties as well.
• Please do not use block capitals or abbreviations
• Product owner agrees protective marking criteria and applies to document. client guidance on protective marking
can be found in Appendix B
• The document/product owner should inform the Tower PSO to populate their Tower’s Product Register
• The definition and document criteria for naming products is as follows:

File naming should contain only the Product Name as per the X Programme Product Register
Product Name Example

xxx X Tower A Schedule 1.0 Definitions

Prod
uct
Prod
Prod Statu
Prod uct
uct s
uct Verifi
Ident Acco
Cont catio
ificati untin
rol n&
on g&
Audit
Repo
rting

PROTECT- MANAGEMENT 59
 PROTECT - MANAGEMENT

9.5 - Product Identification, cont’d…

Step 3b: Version Control Guidance
• When a Product is created it should be v0.1 and when baselined for the first time it should become v1.0. All further
changes should be saved in increments and the version number rounded to the next whole number when next
baselined.
• Version numbers will be controlled through the X Programme Product Register and Product Version Control Sheet
• Version numbers must be recorded in the File Properties as well.
Version Control guidance for Schedules
• Procurement Schedules will retain the same Product ID and name for their lifecycle but the version number will
change as the product goes through its lifecycle
Open Procurement i.e. Tower A/ Tower B Example
X Tower A Schedule 1.0 Definitions

Invitation to Negotiate Best and Final Offer

Contract Award
ITN BAFO

V1.0 V2.0 V3.0

In between formal release versions need to be managed in increments V1.01 – V1.99

Procurements under industry Frameworks Example X Tower D Lot Schedule 1.0 Security
Requirements
Market Engagement Invitation to further Contract Award
competition/ quote

V1.0 V2.0 V3.0

In between formal releases versions need to be managed in increments V1.01 – V1.99

Prod
uct
Prod
Prod Statu
Prod uct
uct s
uct Verifi
Ident Acco
Cont catio
ificati untin
rol n&
on g&
Audit
Repo
rting

PROTECT- MANAGEMENT 60
 PROTECT - MANAGEMENT

9.6 - Product Control

Step 1: Product Filing – This will be replaced by SharePoint shortly and further guidance issued.
All programme working documents are captured in the X shared filing drive.
• There are two levels of filing:
• X Programme baselined products (e.g v1.0, 2.0)
• Tower work-in-progress products or baselined products between increments (e.g, 0.1, 1.1, 2.2)
• Towers can follow their own filing structure given their varying products, however all structures must be documented
within their Product Register.
• The folder structure is aligned with that of the Programme and designed to remain high-level. ‘Nesting’ too deeply
results in difficulties saving documents to the drive, so please adhere to the following simple filing guideline below:

*
Project/Tower Phase 01 Products Product Descriptions
Archive
02 Working Documents

Step 2: Product Tracking

• The Programme Configuration Manager manages baselined products using the X Programme Product Register
• The Tower Configuration Manager/ PSO manages increments within whole numbers using the Tower Product
Register
• PSO Submit Tower Product Registers to the X Programme Product
Prod
Register fortnightly
uct
Prod
Prod Statu
Prod uct
uct s
uct Verifi
Ident Acco
Cont catio
ificati untin
rol n&
on g&
Audit
Repo
rting

PROTECT- MANAGEMENT 61
 PROTECT - MANAGEMENT

9.7 - Products Quality Review / Sign Off

• The below is a guideline for the sign off and quality review of all X Products, however the actual sign off and review
of each product should be specified in the Product Description as this will vary from Product to Product
• Design and Change Products will follow separate guidelines which are specified in their Tower Project Initiation
Document (PID)
• Approvals from the review process will be tracked within the X Programme Product Register and Tower Product
Register
Quality Review/ Sign Off

Products Tower *X peer Requirement Cross Delivery Design Programme ICT Senior X
Sign to peer s Team Tower Board Authority Board Management Steering
Off review Review Review Team Group

Programme

Management   --------------- As required -------------
Products
Cross Tower
/X Solution     ------ As required -----
Products

Procurement
Products   
--------------- As required -------------

Prod
uct
Prod
Prod Statu
Prod uct
uct s
uct Verifi
Ident Acco
Cont catio
ificati untin
rol n&
on g&
Audit
Repo
rting

PROTECT- MANAGEMENT 62
 PROTECT - MANAGEMENT

9.8 - Roles and Responsibilities

X Programme
Configuration
Manager

X –Tower PSO
Xtower PSO Xtower PSO Xtower PSO Xtower PSO Xtower PSO
Transition PSO

X Programme Configuration Manager = PMO: Tower Configuration Manager = Tower Product Owners:
Custodian of the Programme's Product Project Support Officer : Custodian of the Products
Register Custodian of the Tower’s Product Tasks include:
Tasks include: Register • Identify, request and implement all
• Receive, identify, issue and store all programme Tasks include: changes to a Product
products • Receive, identify, issue and store all Tower • Own all changes to a Product
• Maintain the X Programme Product Register products • Own quality assurance of
information • Maintain Tower Product Register information documents
• Provide status information on all baselined products • Maintain working view of Products status in
between baselines • Engage with Configuration audits
• Ensure Products are rebaselined once changes are when necessary
agreed • Provide status information on all products
• Assist the Tower Lead ensuring the quality • Inform PSO of any changes to a
• Assist the Planning Manager in creating the and conformance of all Products
Configuration / X Product Register Management Plan Product
• Product Status Accounting Reports
• Product status accounting reports • Assist in Configuration Audits
• Work with Requirements Team/Cross Tower to
assure all Programme Products
• Lead in Configuration Audits
• Ensure all baselined documents are archived on
TRIM and the Programme Baselined Products
folder

PROTECT- MANAGEMENT 63