Blog Posts Process Analysis

Project Management Quality Guidelines

Blog: Biz-Performance, David Brown

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 project/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 pprogramme 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 policy     appear 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 them
  • making 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;
  • 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 XYZ.
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 the 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. Appendix D provides an induction checklist

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.
  • 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 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 further 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 programme 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 level 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 to     the 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.

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, issue owner and required resolution date.
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.     In 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 available 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.
  • Softcopy 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.

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="https://www.businessprocessincubator.com/content/project-management-quality-guidelines/?feed=html" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples

BPMN.org

XPDL.org

×