Project Management Quality Guidelines

INTRODUCTION

Summary

The Programme Management Quality Guidelines summarise the programme and individual 
project level management control, reporting and review processes together with the essential 
quality assurance standards and quality control processes recommended for the programme 
deliverables.  It captures the principles of the project management approach.

The purpose of the guidelines is to assure a consistent level of management and quality control 
processes across the projects and workstreams, the customer and all significant suppliers for 
the overall programme. The intention is to create an environment where reporting, tracking and 
issues resolution is precise, effective and open. While it is recognised that many grey areas, 
and degrees of uncertainty may exist within large scale business programmes and there may
be a degree of change and strategy, the Programme Management Quality Guidelines aim to 
assist in providing an overall management process whereby uncertainty and risk are reduced.

These Programme Quality Control Guidelines supplement the overall Programme Management 
Plan which defines the goals, objectives, deliverables and timescales for complete delivery.

ORGANISATION AND RESPONSIBILITIES

Programme Organisation

Introduction

The attached chart shows the overall management group structure for the direction, control, 
benefits realisation and risks management for the programme. The roles and responsibilities may 
be divided into individual responsibilities and group roles for the Programme Review Board and 
Senior user Group.

Programme Manager’s Role

The Programme Manager has a key role in the effective benefits management, planning, control, 
risk mitigation and review of the programme involving multiple-projects and workstreams. 
The main areas are:

• Responsible for defining the overall programme structure, organisation, delivery  strategy 
  and schedule across all the projects and workstreams, working with the programme 
  sponsors and roject/workstream leaders
• Responsible for establishing the benefits and managing their delivery and  communication in 
  conjunction with the Programme Board.1
• At the business level the Programme Manager is responsible for assuring the coordination 
  and integration of all the projects and workstreams across the programme and in assisting 
  the  Programme Director with continual alignment of the projects and workstreams against 
  the business goals and target business benefits.
• The Programme Manager will ensure project planning, monitoring and control mechanisms 
  are in place for the effective and efficient execution of the programme and for assessing the 
  impact of the overall programme of significant change within any of the projects or 
  workstreams.
• Continually assessing risk and associated mitigation strategies.
• Continually identifying the needs and concerns of all stakeholders.
• Developing, resourcing and implementing a change management and communications 
  strategy and plan
• Reporting to the Programme Board on overall progress, benefits, costs, issues and risk 
  in a timely manner.
• Working closely with the Applications Support manager to ensure effective post 
  implementation support resources and processes are in place.
• Responsible for the overall supplier performance and contract.
• Responsible for overall cost management with the Programme management office.
• Responsible for developing, implementing and sustaining the effectiveness of the 
  Programme Quality guidelines and processes supported by the programme management 
  office.
• Leading and mentoring the individual project and workstream managers
• Establishing and sustaining then overall Programme Management Plan to deliver the
  target functionality and benefits.

For the Programme, the Programme Managers primary interfaces within the organisation 
maybe with:

• The Group IT Director
• The CMS Director (Programme Director)
• The Customer Operations Director (Senior User Group and Programme Board 
  chairperson)
• The Regional Managing Directors
• The head office area directors
• The individual project and workstream managers

The Programme Manager will be responsible for working closely with, and advising, the 
Customer Systems Director, Group IT Director and Customer Services Director on the risks 
and recommendations to ensure beneficial outcome.

The role is one of leadership, rather than administration, and comprises three main threads:

1. Leadership, change management and advising on pragmatic business solutions and
   realisable benefits within the Customer Care context.
2. Planning and organisational development, project management, monitoring, control 
   and reporting - including supplier management
3. Quality Assurance, including risks  management and deliverables quality review.

Programme Sponsor’s Role

The Programme Sponsor’s role is to:

• ensure that the product being developed achieves the expected benefits,
• ensure that the programme is completed within the costs and timescales approved, and 
  canvas support for the programme at all levels of the organisation where benefit from its 
• products will be leveraged,
• chair the Programme Board

• obtains decisions (or endorsement of decisions) in any circumstance where the overall 
  strategy, its milestones or justification are threatened or when changes in policy appear 
  necessary, and
• maximise the partnership between the programme team and the stakeholders involved

• ensure that projects are given the level of support and commitment required for success at 
  all stages of the project lifecycle.

The project sponsor has authority only within the scope of the programme to which they are 
assigned. 
He/ she should be:

• be a person who would directly or indirectly benefit from the implementation of the 
  programme,
• be a senior member of staff with sufficient energy, will and time to contribute towards 
  the programme’s success,
• be a person who has the organisational power to launch the programme and sustain it 
  support for through to its completion,
• have an understanding of the need for the programme’s products within the business 
  and demonstrable commitment to it,
• be authorised and empowered by the organisation to delegate, and make decisions.

His / her responsibilities include:

• supporting the promotion of the programme and advocating its needs if required
• ensuring where appropriate that local resources are allocated as necessary to the 
  programme to ensure it is a success
• acting with authority on programme matters, making decisions, setting priorities and  
  agreeing changes
• co-ordinating the activities of key stakeholders with respect to the programme
• managing expectations within the Business with respect to the programme’s delivery 
  of functionality and benefits
• resolving programme-level issues with the Programme Manager
• signing off and committing to project implementation plans
• building the benefits case for the project, based upon realistic predictions of benefits
• monitoring the continuing viability of the programme against the Business Case and 
  the  programme’s overall objectives.
     
   Programme Board Role

The Programme Board’s role is to:

• be the ultimate authority responsible for the initiation, monitoring, review and eventual  
  closure of the project
• provide overall direction and guidance to the programme,

in a way that:

• ensures that the programme meets agreed standards of quality, time and cost,
• ensures that the project remains viable against its Business Case,
• commits the necessary resources to carry out the programme,
• obtain decisions (or endorsement of decision) in any circumstance where the overall strategy, 
  its milestones or justification are threatened or when changes in policyappear necessary,

so that:

• ultimate responsibility and accountability for the success and quality of the project is assigned 
  and accepted.

The Programme Board has authority only within the scope of the project to which they are assigned. 
It should be chaired by the Programme Sponsor and members should:

• have a direct interest in, and benefit from the outcome of, the project
• have the appropriate level of authority necessary to commit the resources required by the
   programme.

Their responsibilities include:

• appointing the Programme Manager and other key personnel
• ensuring that the Terms of Reference (ToR) are available and understood by all affected 
  parties  
  checking and approving the Programme initiation/ definition document
• reviewing and signing-off programme plans, risk management plans and key deliverables
  authorising the start of each phase – or recommending termination of the programme

• monitoring plan progress at a frequency decided by the mmaking decisions on exception plans

• resolving programme-level issues when necessary authorising programme closure.

Project Manager’s Role

Each project manager within the programme will be assigned documented aims and responsibilities. 
All contractors will be assigned a Terms of Reference..

The project manager has the ultimate responsibility, authority and accountability for the overall 
success of the individual project or workstream. The project manager is responsible for the overall management of the individual project or workstream and for co-ordinating with the Programme Manager and Programme Director to obtain required resources.

Project responsibilities are categorised and summarised below:

Category	Responsibility
Iterative	Develop/update the Project Definition Document; View Develop and/or review detailed project work plans; Adhere to Programme reporting mechanisms, as defined in the Programme  Quality Guidelines;     Ensure project status reports are produced and distributed on a regular basis; Conduct regular status meetings within the project team; and, Take part in and present regular high level reports at the programme status  meetings.
Continuous	Ensure project objectives and business expectations are met; Monitor and control project progress; Monitor the quality assurance processes including deliverable acceptance and  sign-off; Oversee the project change control and issue resolution processes and ensure  that they adhere to Programme standardsl; Monitor project risk; and, Maintain continuous communications with the project team and the whole  Programme.
Human Resource	Monitoring overall performance of project team members; Determine skill requirements and identify required resources; Monitor and manage user expectations; Develop and communicate the project organisation structure; Delegate responsibilities to team leaders, as appropriate;     Manage project staff; Manage relationships with subcontractors; and, Identify and manage resistance within the customer.
As Needed	Co-ordinate milestone deliverable sign-off; and, Implement appropriate corrective actions when progress deviates from plan.

Specific outputs include the following:

• Project Definition Document;
• detailed project schedules including milestones, resources and costs;
• weekly status reports;
• project issues;
• project risks.

The role of project manager will commence on [Date] and it is expected to last for at least 18 months.

The following quality guidelines will be followed:

• Customer Care Programme Quality Guidelines;
• Project Office Guidelines.

Programme Office Role

The Programme Office (PO) has a key support role in the effective planning, control, risk mitigation,
 reporting and quality review of the programme. This is achieved by being an integral part of the 
programme management function. The role of the Programme Office is as follows:

• Team List Maintenance
  The PO is responsible for arranging the timely update of a master programme stakeholders and 
  team list showing team members against their project and workstream with contact numbers.

• Storyboard Maintenance
• The programme office under the guidance of the programme manager will maintain an 
  overall programme presentation covering vision, goals.
• benefits of change
• Architecture
• change impact
• programme organisation
• Function
• development plans
• implementation plans
• support plans
• communication plans
• Issues
• benefits of change
• Architecture
• change impact
• programme organisation
• Function
• development plans
• implementation plans
• support plans
• communication plans
• Issues
• successes so far
• Quality/Technical/Resource Plan Production

The Programme Office will assist in production of the plans and will facilitate workshops
 if required. The Programme Office will also quality check all plans. The production of 
plans and obtaining  the necessary approval will be the responsibility of the Project 
Managers. The Programme Office will also check that all programme documentation is 
produced including a Project Definition for each project.

• Plan Maintenance

The Programme Office will monitor progress against the overall Programme  WBS 
(Level 2) and will report variances to the Programme Manager. Each individual project 
manager and workstream will ensure plans are kept up to date including the percentage
 of work complete.

• Resource Allocation and Control
  The Programme Office will maintain the resource information and provide support 

regarding resource/skill allocation and levelling.

• Budget Control

The Programme Office will track and report on previously agreed budgets.

• Risks/Problems/Exceptions/Change/Management

The PO will monitor the process, contribute to the analysis, carry out any progress chasing and
 produce any summary reports. It will be the responsibility of the Project Managers to ensure all
information is recorded.

• Product Deliverables/Quality Reviews

The PO will monitor the process and record those items issued for quality review or approval 
and record the reviewers and approvers.

• Supplier Correspondence

The PO will record the distribution and receipt of all supplier correspondence including reports, 
specifications, issues, deliverables and invoices etc.

• Documentation/Administration

The circulation, review and authorisation of documentation will be controlled by the Programme 
Office. They will also provide a service to produce reports, graphs and trend analysis.For the 
Programme, the Programme Office function will comprise both dedicated management  
administration resources working specifically within the team, supported by the Project Office 
function for advice, guidance and support on the implementation of standards, risk assessment
and  quality assurance.

• Procurement Management

The commercial management of suppliers is key. The PO will be responsible under the 
guidance of the programme manager for raising and authorising requisitions, raising PCs with 
suppliers against agreed deliverables, specifications and timescales, and receiving and 
approving invoices, passing approved invoices to accounts for payments, handling invoice 
queries with suppliers..

• Induction of new staff

The programme office will be responsible for arranging the induction of new staff joining the 
programme. This will include arranging desk space and facilities, arranging appropriate 
systems access, updating team lists supplying the baseline programme documentation in a 
starter pack.

Team Leader’s Role

The Team Leader’s role is to:

• manage the work packages of a small team within a project,
• prepare detailed work plans and schedules for that team,
• co-ordinate the efforts of the team members,integrate the team members into an cohesive work 
  group, rather than a collection of individuals,
• ensure that task assignments are performed on schedule, within intended scope and to a 
  satisfactory level of quality.

The Team Leader should have a suitable level of technical expertise to enable him to assist the team 
members in their tasks. For a discrete segment of the project he/ she is responsible for:

• assigning appropriate work to team members,
• monitoring task assignments to ensure they are performed on schedule, within intended scope 
  and to a satisfactory level of quality,
• implementing proactive measures when progress deviates from plan,
• reviewing the team’s timesheets to ensure an accurate picture of the work performed and 
  estimated time remaining is portrayed
• obtaining assistance in resolving problems in a timely and expedient manner
• maintaining an awareness of potential risks
• reviewing progress and issues regularly with the project manager.

Planning, Reporting and review

Programme and Project Planning

Introduction

The key driver and focus for the delivery of the overall programme and business benefits is the 
Programme Management Plan (PMP). Within the Programme Management Plan, key sections are the 
deliverables lists and the overall Gantt high level project workstream and milestone plan. In addition, 
resources to be used should be entered in the plan and a resource plan produced.

The detailed Programme Management Plan will be preceded by a Programme Briefing and Definition 
document to serve as an early communication document. This will outline the vision, goals and benefits
 of the programme aligned to the organisation’s mission and strategy.

The planning approach and communication of these plans will adopt a simple 4 level approach. In 
essence these are:

• Level 1 - High Level Programme plan. This is a graphical summary on one piece of paper 
  showing the overall timescale, phases and key milestones and deliverables. It is used for high 
  level communications and scope explanation    
• Level 2 - Overall Programme Work Breakdown Structure (PWBS). This is the consolidated 
  Gantt schedule and WBS for all the workstreams, including suppliers. It is the baseline and 
  framework against which the programme is measured, managed and communicated at a detail 
  level. It is the schedule ‘bible’ for the programme manager and will be developed and controlled 
  by the programme office planning consultant. It should be simple in that it will be structured with 
  clarity showing all workstreams key activities, inputs, outputs and dependencies at a work 
  package level, but not necessarily the detailed tasks and resources.
• Level 3 - Detailed Workstream Plans. These are owned and controlled by the Workstream 
  Managers who develop them to show the activities , WITH resource allocation, key milestones 
  and deliveries. Input dependencies will also be shown. The programme manager is NOT 
  concerned with this level of detail, as all programme relevant information will be rolled up into the 
  overall programme WBS and schedule. In many cases these level 3 plans may differ from the 
  overall Level 2 PWBS in that resource allocation is demonstrated to the point whereby assurance
   is reached that the tasks can be completed in the time with the available resources.

Planning Process and Levels

The purpose of this section is to describe the style and format recommended for the four key levels of 
plans:

• Level 1 - High Level Programme Plan
• Level 2 - Overall Programme WBS
• Level 3 - Detailed Project Plans
• Level 4 - Graphical Task Sheets

The High Level Programme plan should be represented in Presentation format showing the key 
workstreams, end-deliverables and milestones. It serves as an overall summary for the Programme 
 board, senior management and staff of the organisation and should be presented in a clear 
unambiguous way. Key phases, deliverables, and scheduled benefit points should be clearly indicated.
It is a communications mechanism, rather than a control mechanism

Overall Programme Work Breakdown Structure (Level 2 )

This is the consolidated Gantt schedule and WBS for all the workstreams, including suppliers. It is the 
baseline and framework against which the programme is measured, managed and communicated at a
 detail level. It is the schedule ‘bible’ for the programme manager and will be developed and controlled 
by the programme office planning consultant. It should be simple in that it will be structured with clarity 
showing all workstreams key activities, inputs, outputs and dependencies at a work package level, but 
not necessarily the detailed tasks and resources.

Detailed Workstream Plans. (Level 3)

These are owned and controlled by the Workstream Managers who develop them to show the activities
, WITH resource allocation, key milestones and deliveries. Input dependencies will also be shown. 
The programme   manager is NOT concerned with this level of detail, as all programme relevant 
information will be rolled up into the overall programme WBS and schedule. In many cases these 
level 3 plans may differ from the overall Level 2 PWBS in that resource allocation is demonstrated to
 the point whereby assurance is reached that the tasks can be completed in the time with the available 
resources.

Level 4 - Graphical Task Descriptions.

In many cases workstream level plans and schedules need to be developed or communicated in a 
very detailed way whereby individual responsibilities and deliverables for complex tasks needs to be 
very clearly understood. An example of this is planning the logistics and transition steps for a cut-over
from a single development environment to a geographically dispersed live production environment for 
business critical systems. In such cases detailed graphical task maps are an important element of 
developing, communicating and agreeing these roles, responsibilities and timings.

Planning Process and Levels

The purpose of this section is to describe the style and format recommended for the four key levels of 
plans:

• Level 1 - High Level Programme Plan
• Level 2 - Overall Programme WBS
• Level 3 - Detailed Project Plans
• Level 4 - Graphical Task Sheets

High Level Programme Plan (Level 1)

The High Level Programme plan should be represented in PowerPoint format showing the key 
workstreams, end-deliverables and milestones. It serves as an overall summary for the Programme 
board, senior management and staff of the organisation and should be presented in a clear 
unambiguous way. Key phases, deliverables, and scheduled benefit points should be clearly indicated. 
It is a communications mechanism, rather than a control mechanism.

Overall Programme WBS (Level 2)

The overall programme WBS and milestone planning will be in a Gantt style format. It is not necessary 
to use CPM or PERT style network planning, but concentrate on the use of dependency linked Gantt 
work breakdown structures (WBS), supported by high level schematics of key milestones (level 1)

Programme WBS planning is an ongoing process as projects are initiated, or external and internal 
events influence the achievability or desirability of the current baseline plan. It is key that during the 
programme Mobilisation Phase a reasonably comprehensive baseline programme WBS/milestone 
schedule is developed and agreed and used as the basis for firm progress tracking and control from 
thereon. Re-baselining of the overall programme WBS/milestone schedule should only be undertaken 
against an understood set of events, issues, or emerging risks by the Programme Manager with the 
approval of the Programme Director.

Overall, WBS/milestone planning is the responsibility of the Programme Management together with the
 individual project or workstream managers.

The Planning process to arrive at the initial baseline schedule against which progress and slippage will 
be firmly tracked will be broadly a four stage process.

• The Programme Management unction is responsible for developing the initial overall high level 
  picture of all programme deliverables and milestones across all the projects and workstreams 
  identified. This is done in conjunction with the programme sponsors and identified project 
  managers and workstream leaders during the Programme Mobilisation phase and serves as a 
  focus and a starter for refinement and development.

The Programme level schedule will identify:

• Key Projects
• Key Workstreams
• Key Milestones and Deliverables within the workstreams
• Key Dependencies where known

The programme level Gantt schedule will be supported by a high level Programme Organisation Chart 
and Colour Schematic of the overall delivery milestones.

• The initial programme level  schedule is disseminated to all project managers and work-stream
  leaders who are responsible for understanding and recording all input dependencies and defining
  all project/workstream outputs, and developing their element of the overall schedule to show a 
  level of work breakdown, intermediate deliverables and milestones.
• A Dependency and Risk Planning’ workshop is held with the Programme Management and all
  project managers and workstream managers where the input and output dependencies are 
  explored and tested using, for example, a ‘brown-paper’ process.
• From the Dependency and Risk Planning workshop, Programme Management will baseline the 
  overall programme management plan.

In practice the planning process will iterate around this model. However, these guidelines serve to set 
the overall expectation of the process and responsibilities for WBS/milestone planning. An example of 
the detail and look and feel of the Level 2 WBS is given below.

Detailed Project Plans WBS / Resource Usage (Level 3)

The detailed project and workstream plans developed by the project managers and workstream 
managers should allocate resources against each activity to ensure that full consideration of resource 
availability to achieve the work is undertaken. The form of these plan should follow the Programme 
WBS form as far as possible and should identify ALL end deliverables, receipt and review milestones 
Together with all dependency milestones (receipts, deliverables, approvals etc) upon which that 
workstream is dependent. The PMM approach advocates the use of dependency analysis workshops 
to help identify all necessary dependencies.

For the detailed level 3 project plans details of the resources to be used should be entered into the plan
 using the Resource Sheet in appropriate WBS tool.. The resource name should be entered as 
surname followed by the commonly used Christian name, e.g. Smith Dave. The group should also be 
entered. Where the name is not known, generics should be used, e.g. Programmer in Resource Name
and enter group. If appropriate, details of costing rates should be entered. The resources should then 
be assigned to the plan and a Resource Usage Plan produce.

Information in the Calendar, e.g. working hours per day/hours per week, day start/finish times along with
individual resource information, e.g. holidays should be maintained.

Graphical Task Sheets (Level 4)

In many cases workstream level plans and schedules need to be developed or communicated in a very
 detailed way whereby individual responsibilities and deliverables for complex tasks needs to be very 
clearly understood. An example of this is planning the logistics and transition steps for a cut-over from 
a single development environment to a geographically dispersed live production environment for 
business critical systems. In such cases detailed graphical task maps are an important element of 
developing, communicating and agreeing these roles, responsibilities and timings.

Overall progress Monitoring

Many project management approaches advocate the use of Earned Value (EV) overall progress 
monitoring techniques. The PMM approach advocates the use of a simpler single overall progress 
curve showing planned progress, against actual progress based on a weighted milestone approach.

Drawn from the Level 1 WBS the Programme Manager, Workstream managers and Programme 
Director should identify the set of individual deliverable and milestone points. Those which mark overall 
benefit delivery and those which are project interdependent milestones are most suitable. On an 
arbitrary scale each milestone should be given a weighting. At each time point, the actual number of 
points gained (full completion would merit full points credit for that milestone) is recorded. Using 
Excel’s graphical facilities an actual against planned progress curve is easily obtained.

In general this has been found to be more effective than attempting to link in complex progress graphical tools to the baseline WBS tool. This often invokes a high burden and overhead on Programme Office schedule and resource planners.

Tools

The tool to be used for Gantt scheduling will be Microsoft Project or other Project Tools

For overall progress monitoring Spreadsheet could be used.

Gantt Schedule Style and Format

Ensuring a consistent style for programme Gantt charts will enable all team members to quickly 
absorb information contained in Gantt charts.

Key features are:

Activity Levels

A programme is comprised of a number of projects and workstreams . Programme Management is 
itself one of these workstreams. Within the Gannt schedule the maximumum number of levels below 
the overall programme that should be shown is four, which are:

• level 0 - Programme
• level 1 - Project or Workstream
• level 2 - Stage (of project or workstream)
• level 3 - Work Package (a set of logically related sequential activities within a stage)    
• level 4 - Activity

Projects or workstreams MAY comprise a number of STAGES but this is not mandatory.

• A STAGE MAY comprise a number of Work Packages
• Where possible Projects or Workstreams should be structured not to have multiple 
  workpackkages within multiple stages (keep it simple), but for large complex programmes this is
  sometimes unavoidable.

Layout

• Work breakdown structure (WBS) using legal paragraph numbering;
• Use of standard fonts to accentuate visual impact of plans with:

• tasks in Arial 8;
• roll-up tasks (other than level 1 and level 2 in the WBS) in Arial 8 bold;
• level 2 roll-up tasks in Arial 10 bold underlined (note that if a task, i.e. non-roll up, sits at l
  evel 2 in the WBS then it will be in plain Arial 8);
• level 1 roll-up tasks in Arial 12 bold underlined.

• Showing task start and end dates on print-outs and displays.

The task description should not be extensive. If further descriptive text is necessary it should be placed 
in the notes.In addition, standard headers and footers should be used.

Organisation Breakdown Structure

Two high level view of the programme organisation for both the day-to-day management and 
performance and the overall organisational sponsorship, alignment and risk management should be 
shown as clear schematics. These are essential for clarity, understanding and communication. 
Examples are shown here:

Programme Core Team Structure

Programme Sponsorship and Risk Management Structure

Programme and Project Reporting

Introduction

Programme project status reporting will be conducted primarily at three levels.

• Fortnightly Project and workstream reports to the Programme Office and thence tothe 
  Programme Manager.
• A monthly consolidated Programme Report from the Programme Office to the Programme 
  Director and for dissemination back to the project teams as a communications medium.
• A monthly brief Programme Steering group report from the Programme Manager to the 
  Programme Steering Group

Project and Programme level reporting requires to be brief and efficient and concentrate on problem 
areas and their resolution.

Project and Workstream Status Reports

Project and workstream managers will complete a brief project status report, the style and headings of
 which is given in Appendix B as form PPR. The intention is that this should be brief, precise and 
concentrate on:

• Status - Red, Amber or Green
• Progress during last period
• Immediate tasks for next period
• Major issues
• Major concerns
• Project plan and budget
• Risks

This may be submitted to the Programme Office by either paper report or e-mail. If appropriate a brief 
status report may be phoned in. These should be no more than 1 or 2 sides of A4.

The purpose of these weekly reports is to focus the project and workstream managers weekly on the 
deliverables schedules, milestones, issues and dependencies.

Programme Management Status Report

The Programme Management office will then use these reports plus their own ‘findings’ to produce a 
single consolidated Programme Status Report.

The purpose of the consolidate Programme Status Report is to provide:

• programme highlights and achievements against the plan
• a single consolidated view of the overall progress
• a RAG (Red, Amber, Green) indicator for each project or workstream
• summary of the programme dependencies
• highlight key issues and risks
• plan summary for the next month  
• items subject to change request

The Programme Status Report and selected Project/Workstream reports for high risk or amber/red 
projects will be used as the basis for the weekly Programme Management meeting and distributed to 
the Programme Director and the projects team members.

This Programme Status Report may be presented at the regular programme progress review meetings
and be incorporated within the minutes of the agenda of these review meetings.

Programme Steering Group Report

At a minimum, a formal written Programme Status Report should be distributed to the Programme 
Director, Executive Steering Group and Project or Workstream managers monthly by the Programme 
Office. 
Programme / Project Meetings and Reviews

Introduction

Programme and project reviews go hand-in-hand with the need for regular project level and programme level status reports. Again, it is recommended that reviews be conducted at the two principal levels of Programme and Project/Workstream review.

Programme Review Meetings

The scope of this review will be :

• to highlights project achievements against the plan
• highlight specific non-achievements
• report a consolidated view of the overall progress
• review the risk position of each workstream or project
• review internal / external dependencies
• review plan summary for next two weeks

The Programme Status Report forms the basis for this review.

The Programme review will be held weekly on a Monday morning and chaired by the Programme 
Director.

Project / Workstream Reviews

Project Workstream Reviews are under the control of the project or workstream manager. A 
particular review meeting cycle is not mandated as the need depends largely on the scale, scope, 
nature and status of the project. However, for workstreams with staff resource it is recommended
that formal reviews be adopted at least fortnightly. Where programme workstreams map cleanly to 
a business process or functional area the department meetings may serve as the programme 
- workstream reviews for the duration of the programme.

The scope of these project level reviews should cover:

• Review success highlights - milestones achieved and signed -off
• Review milestones not achieved and why.
• Issues arising
• Key risks emerging
• Statement of intent for the following two weeks

Other Reviews (Design, Change, Contract , Quality etc.)

In the course of the programme other formal reviews will be required as part of the delivery process. 
These will cover:

• Design Reviews
• Change Control Committee Reviews
• Contract Performance Reviews
• Quality Reviews for Deliverables

These Programme Management Quality Guidelines do not specify the form, timescales or nature of 
these reviews as these are specific to the requirements of the individual Programme Workstreams 
and will be determined by the appropriate Project or Workstream Manager in consultation with the 
Programme Management.

The specific Programme Management Plan (Quality Control Section) will specify the requirements in 
these areas. A minimum requirement for such reviews is that they have an agenda and are minuted 
according to the standards below.

Agendas and Minutes

An essential project management discipline to be adopted for formal meetings and reviews, both 
internally and with suppliers, is the use of structured Agendas and Minutes. Appendix B provides 
example forms for agendas and minutes. For the sake of efficiency minutes should be brief, concise 
and concentrate on actions, responsibilities and due dates. The forms AGN and MIN in the appendices 
provide guidelines.

CONFIGURATION AND SCOPE MANAGEMENT

Introduction

This section covers the basic quality and control principles around identifying deliverables and their 
statuses, scoping and defining requirements and controlling change to previously agreed scopes or 
status.

Configuration Item Management

A configuration item is a key managed project deliverable which should be subject to review, approval 
and change control. It may be a key deliverable with the process or conduct of the project e.g. a 
specification; or it may be an end deliverable of the project (an application, an item of hardware, an 
item of software, document, a building etc.) Many project management methodologies put significant 
emphasis on the lifecycle and approvals management of project deliverables (e.g. configuration items 
(CIs) ).

Where an item may exist in several major versions or releases within the project context, prior to final 
completion, (typically the case for items of software or documentation) it may exist as several CIs 
with incrementing version or release number.

It is important that care is taken with the level that CIs are registered and controlled. They should be 
registered for major items of significant importance which require managerial review or approval. 
Every single output or product arising from the management and delivery of a large programme should 
not necessarily be registered and controlled to this degree. However, typically for a large programme 
(greater than £10million overall budget) there would normally be about 50-150 CIs.

The key benefits of CI management is simply one of control, clarity and communication.

For programme when a Configuration Item (key project deliverable) is identified as needed or is clearly 
implied by the scope of the project, this item should be registered as a CI in the RMS system by the 
project manager responsible for managing the approval and sign-off of that deliverable. RMS provides 
a simple multi-user database system for the registration and control of configuration items with easy 
status update, control and reporting.

Requirements Specification

This section refers to the specification of software application requirements. All software application 
functionality and requirements must be associated with a Business requirements and benefit 
statement. One business requirement and associated benefit statement may spawn a set of 
application functionality requirements.

Change Control

A major contributor to timely project success is stability of requirements. In most cases change to 
requirements or previously agreed implementation or design methods leads to increased programme 
cost and timescales. It must also be remembered that the evaluation of Change Requests involves 
significant time and effort on behalf of all parties.

However, the nature of large scale business change programmes is that change, driven either by 
internal or external influences in programme strategy and scope is a matter of fact, and may also be 
used to improve the delivery of programme benefits.

The extent and cumulative impact of change being requested as the programme progresses will be 
monitored at Programme Manager level.

Once a project deliverable has been agreed as an appropriate baseline, it is crucial that once a any 
change to that baseline is requested and managed through this change control procedure. The 
process below outlines for the Customer Care Programme the work-flow in terms of establishing 
modified specifications and agreed work orders arising from a Change request.

All changes are to be requested via Project Record Management System (PRMS) or by submitting the 
Change Request Form to the Programme Office for entry into PRMS. All Change requests must be 
accompanied by a High Level Requirement definition. Examples of both Change Request Forms and 
High level Requirements specification are given in Appendix B.

The owning project manager specifies when a deliverable is suitable for baselining and is responsible 
for the subsequent application of formal change request through PRMS. This Change request must be
 approved by both the Programme Manager and Business area manager before it is submitted to the 
supplier

The Programme Manager will review with the supplier the feasibility and statuses of all submitted 
change requests on a regular basis, either as a separate Change Control review, or as an addendum 
 to the regular programme management review meetings.

Software Supply Control

Software Release Procedure (SRP)

During the life of the Programme there will be multiple suppliers of software and systems. It is 
important that a consistent process for the receipt and recording of software and systems deliveries is
 established across the programme.

All software which is baselined as a deliverable product, either final or intermediate deliverable, will be 
accompanied by a completed Software Release Form, (SRF), delivered to the workstream or project 
manager responsible. A copy of the Software Release Form must also be lodged with the Programme 
Office at the time of receipt. This enables sound management of software release and fault and query 
management against releases across the overall programme.

Every software release will be identified by a specific Module Name and Version Number. The precise 
formats for module naming and version numbering will be agreed with the suppliers or workstreams. 
All Software Releases will be recorded in the RMS system as Configuration Items.

All released baselined software will be backed up to a suitable medium and stored in a suitable media 
library.

Software Error / Query Reporting

It is important that a consistent process is used for software and systems error and query reporting 
across the programme. While management of software and systems error reporting for particular 
software delivery is the responsibility of the project or workstream managers it is key that a programme
wide view of faults arising and trends is maintained by the Programme Management Office.

There are four principal work streams for which systems of software query and fault management is 
vital:

1. Live faults and query reporting. Responsible manager
2. Data conversion trials faults and query reporting. Responsible Manager
3. Acceptance testing and pre-implementation systems assurance. Responsible manager

Software or system queries or faults (SQFs) will be registered in the Faults and Queries section of 
RMS (record management system)

Error/Query Reviews

For each project or workstream which is managing the receipt, integration or testing of software 
regular Error/Query reviews should be scheduled between the suppliers and acceptors of the software.
During Acceptance Testing these should be at least every week unless otherwise agreed, this meeting
will review the status of the SQFs raised on the software and agree plans for their resolution.

ISSUES AND RISK MANAGEMENT

Issues Management

Issues management is an important process for concentrating attention on potential risk areas which 
may impact the deliverables or intended benefits of the programme. It is useful for prioritising tasks and
 actions which come to light outside the planned schedule. Programme issues as they are identified 
will be recorded within the Programme Record Management System (RMS) with a priority, owner and 
resolution date identified.

An issue is a matter which requires resolution, or identification of how it will be resolved in the short 
term, and is an activity or concern not shown on the project plan. A worry, or concern has arisen, and it
 requires short term resolution. It has a dependency outside the influence or control of the manager 
raising the issue and thus need notifying to higher management to assist with resolution. It differs from 
risk in that a risk is an event which has been pre-predicted that if it occurs may impact the benefits, 
cost, time, or quality of the overall programme. Risk management is discussed briefly below.

The data available for recording on the Issues form is given above in Record Management System, 
which apart from descriptive detail, raiser, owner, due date, status, includes impact and action 
conclusion data fields.

The Programme Office is primarily concerned with issues which may, if not resolved promptly, effect
 the timescales, quality, function or overall cost of the Programme, or which cause or amend a 
dependency on another project or workstream within the programme. The Programme Office will 
assist the project and workstream managers in the resolution or cat

The data available for recording on the Issues form is given above in RMS, but is that defined by PPM, 
which apart from descriptive detail, raiser, owner, due date, status, includes impact and action 
conclusion data fields.egorisation of issues.

The Programme Office is primarily concerned with issues which may, if not resolved promptly, effect 
the timescales, quality, function or overall cost of the Programme, or which cause or amend a 
dependency on another project or workstream within the programme. The Programme Office will 
assist the project and workstream managers in the resolution or categorisation of issues.

Any member of the programme may raise an issue at any time, through RMS, and it is the 
responsibility of the Project or Workstream Manager for escalating the issue to the Programme Office
 if it is considered to have an impact on the overall programme.

Issues may be placed on the RMS issues list by either:

• Being raised at meetings and minuted. Issues will then be copied to the Consolidated Issues 
  List in the Programme Record Management System (RMS).
• Notification from team leaders (by phone, e-mail, or memo) of an issue item with brief 
  description
   The objectives of the Issue Management Procedure are to:
  Facilitate the resolution of issues.

• Control and coordinate issues. 
  
  Encourage issues to be raised by providing a visible tracking system.
  Communicate the resolution to affected areas.

Risk Management

Risks are factors which may arise at a future time and effect the course of the project. Unlike issues, 
Risks may occasionally be positive events, although Risks are normally viewed in the light of events that
 may negatively affect the realisation of the project goals. They are also often more strategic and wide 
ranging than issues. Risks need to be communicated and managed at the Project sponsor level. They 
are most often identifiable, prior to their occurrence. Hence action and mitigation plans should be 
established to deal with, or provision for, their occurrence.

The risk form data follows most risk management methodology requirements, particularly PRINCE 2. 
The risk form is similar to the issues form but includes fields, pull-down menus and tables for definition 
of risk areas, risk probabilities, risk factors and risk costs. Overall risk factors are calculated automatically from the probability and impact values entered.

The RMS Risks Management section has built in a standard set (some 65) risk areas based on a Risk 
Management Framework. Pull down menus are available for assigning Risk probability and Impact.

Risk management involves assessing the possible events, both internal and external, which may 
impact the planned benefits, timescales, cost or quality of the programme. The Programme requires 
the Programme/Project Managers to identify the key risks, analyse their impact, plan how to avoid the 
risk, plan what to do if the event occurs. It is a useful process for focusing on the difficult and potentially
disruptive events and provides another view on planning required.

For Programme Management, together with the Programme Director, Project Assurance and project 
workstream leaders will derive an initial risk list at the first Dependencies and Risk Planning workshop 
held during the Mobilisation phase.

The extent to which specific risk management techniques are applied on this programme depend on 
the initial risk assessment arrived at. At a minimum an initial key risk list will be developed and an overall
risk assessment derived. These will be recorded in the programme RMS. As risks emerge during the 
programme these will be captured within RMS

Programme Management or Project and Workstream Managers may input risks into RMS at any time. 
These will be reviewed weekly by the programme office. A catalogue of the high priority risks will be
 printed and attached to the Programme Management Report.

Quality Review and Approval

Introduction

As outputs from the programme are delivered it is recommended that a consistent approval and 
sign-off process is instigated across all projects and work-streams for designated key deliverables. 
There are primarily two levels of approval and review:

• Level 1 - Review and Approval by a single authority, such as the Project, Workstream Manager
   or Programme Director. In this case the approval authority should review and sign an associated
   Product Approval Form. The form allows the recording of exceptions or rework requirements.
• Level 2 - More detailed Peer Review and quality review meeting approval process. these cases the quality review process should be completed with a formal QA review and managed through the use of the QRF process and procedure. This provides the form and process for:

• establishing the review
• capturing peer review comments and rework requirements,
• recording approval and agreed exceptions.

The level of review required will be decided by the Programme Manager in conjunction with the Project 
or Workstream managers. The Programme Office will coordinate key deliverable quality reviews with 
the appropriate Project or Workstream managers.

General Benefits for Full Quality Reviews

The benefits to be gained from the effective use of Quality Reviews are:

• a structured and organised approach to the examination of subjective quality criteria
• early identification of defects in products and, therefore, a platform for product improvement with
  attendant reduction in the costs of the final product during development and in operation
• as products are considered complete once they have successfully passed Quality Review, an 
  objective measurement for management progress control is provided; progress is measured by 
  product delivery 
  all vested interests are working together to improve product quality; this helps build the team 
  approach to development
• once a product has gone through the Quality Review procedure, personnel are more willing to 
  commit to that product. As ownership of the product is shared between Quality Review 
  participants, Users, who are represented on the Quality Review team, are much more willing to 
  sign off a reviewed product
• apart from defects on the part of the creator(s), defects may also be caused by deficiencies in 
  standards and methods. Failure to use a standard may indicate that the standard is no longer 
  practical to use. Such events should instigate a review of the suspect standards area and
   provide a starting point for standards improvements.

A Quality Review is an involved partnership designed to ensure a product’s completeness and 
adherence to standards by a review procedure. It is a team review of a product with the emphasis on 
checking the product for errors (as opposed to, for example, improved design). This partnership should
 involve all those with a vested interest in the product, and with any specialist knowledge which can 
contribute to monitoring quality.

The level of review required and the selection of possible participants in a review should be made 
during the planning of the relevant stage, guided by the information contained in the Product Description
 . The most effective Quality Reviews have participants from all areas which can effectively contribute 
to the quality of the product.

Objectives

The objectives of a Quality Review are:

• to produce a product which meets business, user and specialist requirements
• to assess the conformity of a product against set criteria
• to provide a platform for product improvement
• to involve all those who have a vested interest in the product
• to spread ownership of the product
• to obtain commitment from all vested interests in the product
• to provide a mechanism for management control.

Steps in the Quality Review procedure

The review procedure has a number of activities, the central element being the review meeting, where all participants gather to identify and agree on any defects in the product.

There are three basic steps in the Quality Review procedure.

• Preparation,consisting of:

1. confirmation of the availability of the nominated reviewers and agreement on dates for the
    return of comments and the review itself
2. distribution of a copy of the product and its Product Description to reviewers, where this is
    possible, for instance if it is a printed document. Alternatively, making the product 
   for inspection by the reviewers   
3. assessment of the product against the quality criteria
4. entry of the major errors on an Error List    
5. annotation of minor errors on     the product, where applicable
6. return of the annotated product and Error List to the Producer
7. a plan of the review meeting, and agreement on the agenda.

• Review Meeting, consisting of:

1. discussion and clarification of each of the major errors raised by the reviewers
2. agreement of the follow-up appropriate to each error    
3. summary of the actions at the end of the meeting
4. agreement on the Quality Review outcome, and sign-off of the product, if appropriate.

Document Management

Central Filing System (Document and Transmittal Register)

Introduction

All Programme Management material necessary for management, communication and control of the overall programme relating to the scope, planning, finances and progress of the overall programme will be stored in a the master Programme Management files under the control of the programme office.

This includes, but is not limited to:

• Documents including:

• Correspondence, letters, faxes
• File notes on interview notes
• Reports, workshop output
• Agendas and minutes
• Requirements
• Specifications

• Spreadsheets, Workbooks, charts,     etc
• Presentations
• Project plans

The programme office will maintain the physical and electronic programme filing system for all 
significant programme level outputs, correspondence and documentation. In effect a controlled 
correspondence and document register. The key purpose of this is to maintain control and auditability 
on primarily supplier correspondence and configuration items (controlled documents) produced by the
programme.

A physical filing system will be established within the programme office together with an electronic file 
server based system whose structure will mirror the physical filing system. Documents managed in 
primarily in electronic form only will have master copies held within the electronic library. Documents 
managed in hard-copy form only will have master copies held within the physical library.

A single register covering the contents of both electronic and physical library will provide a catalogue of 
the contents of the whole library (electronic and physical).

Informal memos and e-mails need not be filed, unless specifically required. However, it is 
recommended that electronic copies should be retained where appropriate and stored in the 
appropriate shared directory.

All products and outputs once they have reached a status whereby they are being reviewed outside the
direct author group, or workstream will be copied to the Programme Office and managed as

External inputs received by the programme office will be catalogued and filed in the Programme Filing 
Systems, and copied to the intended recipient(s). Inputs received directly by project managers from 
external suppliers will be copied and submitted to the Programme Administrator for recording in the 
Programme Filing System.

Document Register

The document register assists configuration management by recording:

• Document (deliverable) Name.

• Version.

• Source.

• Distribution.

• Soft copy path and file name

• Scheduled sign off date

• Responsible Owner

• Responsible Author

Record Management System (RMS) provides a simple database system for managing a document register 
(Configuration Items).The Document Register procedure ensures that documentation is retrievable both within 
the project library filing system and on the project network. It assists distribution control by specifying the 
document version, date and distribution. The filing system provides the means of accessing hard copies of 
information.

Register of External (Supplier) Correspondence Received.

All agreements, understandings, or decisions arrived at with the suppliers must be recorded in at least 
one of the following; minutes of meeting, letter/e-mail or project memorandum. Copies of these must 
be retained in the Programme Management File. Communication of matters relating to performance of 
contract should be formalised as a letter or project memorandum.

If RMS is used then correspondence received from suppliers must be registered by the programme 
office in RMS - Document Transmittal. This provides an easy to manage correspondence control 
environment and allows search and find and catalogue facilities for all correspondence.

Register of External (Supplier) Correspondence Sent

Similarly all correspondence sent to supplier must be logged in RMS and a transmittal sheet sent with 
the correspondence. Where e-mail is used to communicate significant issues, actions or agreements 
than this should also be logged in the Document transmittal log AND the e-mail stored as electronic 
text within the Correspondence directory under an appropriate sub-directory identifying the supplier. 
See Filing Structure below.

Register of Programme Documentation and Configuration Items

The section on Configuration Item Management stipulates that all substantive documentation, i.e. that 
requiring review, approval or implementation outside the programme must be registered as a 
Configuration Item. RMS has a simple automated Configuration Item register which will be administered
 by the programme office.

Filing Structure

The overall structure of the project filing system will be divided into:

a.    Management

b.    Technical

c.    Quality

d.    Miscellaneous

1. The detailed designations of the sub-sections of this filing system is given below.
2. This filing structure as an electronic directory system should be established as a master set on 
   a fileserver under the master directory.
3. For each workstream as defined by the formal organisation structure this set should be 
   duplicated as required. Some programmes prefer to use textual workstream identifiers within 
   the filing system. Other prefer to use numerical identifiers, which is often the case where the 
   organisation gives programmes and projects registration identifiers.
4. The purpose of the workstream level library directories is for the development of work-in-progress
    items only, for that workstream. Any outputs which are issued outside that workstream as a
   configuration item for review, approval, communication or implementation MUST be copied to the
    master PROGMGT appropriate directory.

Programme Filing List

The table below provides a schema for the high level library structure. Appropriate sub directories 
should be created where appropriate. This is normally done by supplier, or workstream, or document
type.

   

FILE REF	FILE DESCRIPTION
	MANAGEMENT FILES
M01	REFERENCE MATERIAL
M02	PROGRAMME AND PROJECT PLANS
M03	PROJECT ORGANISATION, ROLES
M04	PROGRAMME OFFICE ADMINISTRATION
M05	EXTERNAL CORRESPONDENCE (IN AND OUT)
M06	AGENDAS AND MINUTES
M07	STATUS REPORTS
M08	CONTRACT, FINANCES AND INVOICES
M09	PRESENTATIONS
M10	WORK IN PROGRESS
M11	FINAL DELIVERABLES
M12	LESSONS LEARNT AND CUSTOMER SATISFACTION
	TECHNICAL FILES
T01	REQUIREMENTS
T01-A	REQUIREMENTS - AREA A
T01-B	- AREA B     etc
T02	BUSINESS PROCESS
T02-A	BUSINESS PROCESS - AREA A
T02-B	AREA B etc
T03	ARCHITECTURE AND DESIGN
T04	PHYSICAL DESIGN
T05	DEVELOPMENT
T06	UNIT TESTING
T07	SYSTEMS INTEGRATION
T08	SYSTEMS TESTING
T09	ACCEPTANCE TESTING
T10	ROLL-OUT AND IMPLEMENTATION
T11	USER AND SYSTEM DOCUMENTATION
T12	TRAINING AND EDUCATION
T13	MAINTENANCE AND SUPPORT
	QUALITY FILES
Q01	TEMPLATES, FORMS AND STANDARDS
Q02	RISK MANAGEMENT PLANS
Q03	ISSUES REPORTS AND ISSUES CATALOGUE
Q03	SYSTEM QUERIES
Q04	CHANGE CONTROLS
Q06	TEST AND ACCEPTANCE
Q07	QUALITY REVIEWS
Q08	PROJECT AUDIT REPORTS
Q09	CONFIGURATION MANAGEMENT RECORDS
	MISCELLANEOUS
Z01	MISCELLANEOUS
Z02	MISCELLANEOUS 2, etc.

File Naming Conventions

File names should include reference to the version of the document. This will enable new versions of a 
document to be stored in the same sub-directory without causing problems over duplicate names. 
Document names should therefore be structured as follows:

Version Control

All deliverables should contain a reference date, a version number and should specify whether they are
 draft or final versions.

When a deliverable is under development, then the version number should be 1.0 DRAFT. Informal 
reviews can occur repeatedly without the need for the version number to change. The deliverable 
control can be managed through the reference date.

When a deliverable is issued for final approval then, as a general rule, the version number should be 
1.0 FINAL. If changes are required, then the deliverable should be updated and re-issued for approval 
as version 1.1 FINAL. Incremental version changes will continue for each “cycle” of review and update.

If, after acceptance of the deliverable, major changes are required (e.g. due to a change in scope, or a 
major issue which affects the overall direction of the project) then a new version of the document 
should be produced with the version number as the next integer.

As an example:

After formal reviews and updates a deliverable was accepted as version 1.3 FINAL.

A major change in scope then occurred which required revisiting the deliverable. The deliverable then became 
2.0 DRAFT whilst being developed and version 2.0 FINAL when being formally reviewed.

During the formal reviews, one round of changes was required. The formally accepted version of the deliverable 
was 2.1 FINAL once the changes from the formal review had been incorporated.

Document Storage

All master copies of [Project Name] deliverables will be stored as hard copies within the Project Office 
Library, as well as electronically, on the [clientname] LAN. In all instances, the most recent, master 
document should always be held and maintained on the [clientname] LAN within the [Project Name] 
directory to ensure that the most up to date version of a document is maintained.

Electronic File Security

This procedure provides a means of making the electronic documents of the project available to all project team
members while protecting them from inadvertent and unauthorised deletion or modification. All directories within 
the [Project Name] structure are available to the team members as Read Only access. Write access is limited to 
the appropriate member.

Backup and Recovery

All electronic copies of deliverables will be stored on [customername]’s Local Area Network. Backup 
and recovery procedures are addressed through [customername]’s current procedures for the Local 
Area Network.

If, for any reason, working documents/files are stored on a local hard disk of a workstation, then it is the 
responsibility of the owner of the document/file to take adequate backups (e.g. by copying to diskettes or to a 
network drive).

[customername] is responsible for backing up those files held on the network on a daily basis. The 
PO will be responsible for coordinating backup of major project deliverables. All files held on local drives 
are the responsibility of the relevant user.