Template for IDA project (Project ID)

Template for specific development (Contract ID)

Project Management and Quality
Plan
Issue 3
Project Management and Quality Plan Page ii
IDA-MS-PMQP
Issue 3
TABLE OF CONTENTS
0 PREFACE PLEASE READ FIRST.........................................................................1
0.1 Purpose of this document.............................................................................................1
0.2 !er!ie"........................................................................................................................1
0.# Purpose..........................................................................................................................1
0.$ %enefits of the Pro&ect '(n()ement (nd *u(+it, P+(n -P'*P..............................2
0./ Scope of the P'*P......................................................................................................#
0.0 App+ic(1i+it, to 2(rious T,pes of Pro&ects..................................................................$
0.3 Re+(tionship of the P'*P to ther Documents........................................................$
1 I4TRD5CTI4......................................................................................................../
1.1 Purpose of the Pro&ect '(n()ement P+(n -P'*P.................................................../
1.2 Scope of the Pro&ect....................................................................................................../
1.# De!i(tions from the P'*P........................................................................................../
1.$ References (nd (pp+ic(1+e documents........................................................................0
1./ Termino+o),...................................................................................................................3
2 2ER2IE6 F T7E PR8ECT..............................................................................9
2.1 Pro&ect description........................................................................................................9
2.2 De!i(tions since the ITT..............................................................................................9
2.# :+o1(+ Pro&ect Time P+(n.............................................................................................;
2.$ Contr(ctu(+ 6or< 5nits...............................................................................................;
2./ De+i!er(1+es (nd Pro&ect Document(tion...................................................................;
# PR8ECT R:A4ISATI4 A4D RESP4SI%ILITIES....................................11
#.1 7i)her +e!e+ pro&ect or)(nis(tion structure..............................................................11
#.2 The Commission=s o1+i)(tions (nd responsi1i+ities.................................................11
#.# 1+i)(tions (nd responsi1i+ities of other In!o+!ed :roups.....................................12
#.$ >e, pro&ect personne+ (nd represent(ti!es..............................................................12
#./ Su1contr(ctors............................................................................................................1#
#.0 Esc(+(tion Process.......................................................................................................1#
$ PR8ECT PRCESS C4TRLS.........................................................................1$
$.1 P+(ns.............................................................................................................................1$
$.2 Pro)ress me(surement (nd monitorin)....................................................................1$
$.# Process Contro+s..........................................................................................................1/
/ ACCEPTA4CE A4D PA?'E4TS...........................................................................13
/.1 5se of de+i!er, notes...................................................................................................13
/.2 :ener(+ (ccept(nce procedure...................................................................................19
/.# P(,ment.......................................................................................................................19
/.$ Fin(+ (ccept(nce (nd c+osure of the pro&ect.............................................................19
0 C4TRL F T7E P'*P......................................................................................20
0.1 P'*P Production.......................................................................................................20
0.2 P'*P Appro!(+..........................................................................................................20
0.# L(c< of (dherence to the P'*P...............................................................................20
Project Management and Quality Plan Page iii
IDA-MS-PMQP
Issue 3
3 SECTI4S FR A PR8ECT PR:RESS REPRT..........................................21
DC5'E4T C4TRL.....................................................................................................22
DC5'E4T SI:4FF........................................................................................................22
DC5'E4T C7A4:E RECRD.....................................................................................22
Project Management and Quality Plan Page 1
IDA-MS-PMQP
Issue 3
0 PREFACE PLEASE READ FIRST
0.1 PURPOSE OF THIS DOCUMENT
#1 This document is a generic document for use by IDA projects. It provides guidance
and template material which is intended to assist the relevant management or
technical staff, whether client or supplier, in producing a project specific document.
It is also useful bac!ground reading for anyone involved in developing or monitoring
the IDA "anagement #ystem $IDA "#%.
0.2 OVERVIEW
#1 This preface is for information only.
#& The preface is therefore not meant to be retained in the project specific document.
#' The remaining sections $numbered 1, &, ',(% constitute a template that should be
used to construct the projectspecific document.
Te)t in normal case is in the most part *boilerplate+ that can be retained,
amended or deleted in the document.
Te)t in italics provides instructions on how to complete a section and should be
removed once the section is written.
#, The template should be used pragmatically, that is where a section is not relevant it
should be omitted. -onversely, the material contained in this document is not
necessarily e)haustive. if there is a subject that is relevant to the project, but is not
included in this document, it should still be included.
0.3 PURPOSE
#1 The purpose of this writing guide is to define the structure and content for /roject
"anagement and 0uality /lans $/"0/s% to be used by IDA projects and their
suppliers $internal or e)ternal% of software, e1uipment, services, studies or
consultancy.
#& 2y producing a /"0/ that adheres to the format defined in this writing guide,
suppliers and IDA achieve the following objectives3
responsibilities and general principles are defined for managing the relationships
between IDA projects and the suppliers $internal or e)ternal% to these projects of
e1uipment, software development, services, studies and consultancy.
a basis for 1uality assessments of the procedures employed by suppliers to fulfil
their contractual obligations to IDA is defined.
#' This document consists of3
"andatory instructions on sections to be included in the /"0/ 4 which are
indicated by the presence, in bold, of the word 5must6
-larification and refinement of the instruction shown in italic text.
Te)t which could be used and included in the actual /"0/ 4 written in normal
font.
Project Management and Quality Plan Page 2
IDA-MS-PMQP
Issue 3
#, The structure of this document must be used as the structure of the /roject
"anagement /lan, e)cept where indicated in section 1.' Deviations from the /"0/.
The te)t, which describes how to fill in each section, will obviously be replaced by the
appropriate descriptions.
#7 This section must of course be omitted from the deliverable /"0/.
#8 The supplier6s /roject "anager must produce the /"0/. An initial draft of the
/"0/ must be introduced for review at the project !ic!off meeting, which normally
occurs within & wee!s of contract signing. The first issue of the /"0/ must be
delivered within two wee!s after the !ic!off meeting.
0.4 BENEFITS OF THE PROJECT MANAGEMENT AND QUALITY PLAN
PMQP!
#1 9)perience shows that the most successful relationships between suppliers and
purchasers are those which are defined precisely, clearly and completely, and in
which there is agreement on these points before the start of the project.
#& The benefits of an agreed /"0/ are those resulting from the fact that3
there is effective communication between IDA projects and their suppliers of
computer e1uipment, services, software, studies and consultancy,
all business and management transactions are properly directed and authorised
between IDA and its suppliers, within the scope of a contracted project,
all changes to project plans, specifications, etc. are ade1uately controlled in a
specified and agreed manner,
both the IDA project and its suppliers have a clear understanding of project
objectives, of the progress towards attaining these objectives and any impediment
to their attainment,
there is clear agreement between the IDA project and its suppliers on the
standards, procedures and methods employed to meet project objectives,
procedures are in place for ensuring that the IDA project receives all items
specified by the contract, to agreed standards of 1uality and timeliness.
the /"0/ is used by the IDA project and its suppliers as a basis for agreement
$rather than conflict%.
Project Management and Quality Plan Page 3
IDA-MS-PMQP
Issue 3
Project Management
Plan
External
Standards
Best Practices
IDA Project
Management
Methodology
PMP Model
Contractor Project Methodology
Project
Characteristics
User
Requirements
Alication Area
!ye
Security"Sa#ety
Budget
!ime$scales
Si%e
The Objectives of the Project Management Plan
0." SCOPE OF THE PMQP
#1 This /"0/ must be produced in all cases of contractual relationships with suppliers
initiated by an IDA project. The /"0/ is e1ually applicable to situations in which
computer and communications e1uipment, computer software, services, studies and
consultancy or any combination of these are to be provided.
#& :hen the contract is agreed, the life of the /"0/ will continue until the supplier has
satisfactorily completed all of its obligations under the contract.
#' The /"0/ will define the relationship in terms of3
;rganisation and -ommunication.
/roject Time /lan.
/rogress "onitoring and <eviews.
-hange -ontrol "anagement.
<is! "anagement.
#tandards, /rocedures and "ethods.
Deliverable /roducts.
<oles and <esponsibilities.
#, In addition this document provides an outline of a 0uality Assurance process which
the IDA project may elect to prescribe in any of its relationships with suppliers.
0.# APPLICABILITY TO VARIOUS TYPES OF PROJECTS
#1 The /"0/ described in this document must be tailored to each specific instance of
contractual relationship between an IDA project and its suppliers.
Project Management and Quality Plan Page
IDA-MS-PMQP
Issue 3
#& #hould the supplier uses its own /"0/ template then there must be a crossreference
table, included in that /"0/, to demonstrate how the supplier6s /"0/ meets the
re1uirements of this /"0/.
#' The template should be used pragmatically, that is where a section is not relevant it
should be omitted. -onversely, the material contained in this /"0/ is not necessarily
e)haustive. if there is a subject that is relevant to a particular /"0/ but is not
included in the guide, it should still be included in the /"0/.
#, In the conte)t of this document the term =project= is to be interpreted to mean *the set
of activities by which the #upplier satisfies its obligations to the -ommission under
the contract.+ In some cases, the project will refer to a continuing service provided by
the #upplier. >or e)ample, provision of consultancy services to the -ommission would
constitute a project in this sense. The /"0/ described in this document is applicable
to any of these situations, although the specific /"0/ must be tailored to the
particular circumstances.
0.$ RELATIONSHIP OF THE PMQP TO OTHER DOCUMENTS
0.$.1 C%&'()*'
#1 The /"0/ must refer to the contract between the IDA project and the #upplier. :hen
agreed by both parties, the /"0/ will have the force of the contract. It is intended
that a model /"0/ and this :riting ?uide be sent to each prospective #upplier as a
part of the Invitation to Tender $or <e1uest for /roposal%. In any case of conflict
between the /"0/ and the basic contract, the contract shall be the senior document.
0.$.2 IDA+MS
#1 The present /"0/ template and guide is a component of the IDA "anagement
#ystem $IDA"#%, a policy framewor! and *tool!it+ to assist IDA and its suppliers
with the management and e)ecution of projects. There may be other components, the
use of which is agreed between IDA and a supplier as obligatory, recommended or
worth considering. These should be identified in the /"0/.
#& The IDA project must provide access to the relevant parts of IDA"# as needed to
enable #uppliers to meet their contractual obligations.
0.$.3 S')&,)(,- )&, ./0,120&1-
#1 All wor! underta!en must be reviewed against the appropriate sections of the
following3
IDA"#
IDA Architecture ?uidelines.
Project Management and Quality Plan Page !
IDA-MS-PMQP
Issue 3
1 INTRODUCTION
1.1 PURPOSE OF THE PROJECT MANAGEMENT PLAN PMQP!
#1 <eproduce, and if necessary e)tend, the te)t below.
"1 #his PMQP document$ which will %orm &art o% the contract$ descri'es the &rocesses
%or management o% the relationshi&s 'etween an IDA &roject and its su&&liers(
"2 In addition$ this document also &ro)ides an outline o% a Quality Assurance &rocess$
which should assure user con%idence in the *uality o% the wor+ that the Project #eam
will &er%orm$ 'y showing how the &roject will 'e carried out$ measured$ monitored$
accounted %or and sa%eguarded during and a%ter the e)ents(
#& The amount of detail to be included in the /"0/ must be tailored according to the
comple)ity, si@e and duration of the project. -lear statements are necessary to ensure
that ambiguity and assumptions are minimised so that everyone understands what
controls are in place for the smooth progression of the project.
"3 #his PMQP contains details on,
de%initions o% the roles and res&onsi'ilities$ %or each mem'er &artici&ating in the
&roject$ with em&hasis on the re*uired s+ill sets to address the com&lexities and
ris+s o% the &roject$
indications o% how the &rocesses relating to changes and &ro'lems should 'e
identi%ied$ re&orted and managed$
re*uirements %or the content$ %ormat$ sign-o%% and re)iew &rocesses$ and
identi%ication o% clear acce&tance criteria %or each deli)era'le$
descri&tions o% all the means that are and will 'e a&&lied to meet the user-s
technical and *uality re*uirements$
in%ormation on *uality assurance and *uality control acti)ities that are to 'e
a&&lied to the &roject acti)ities and deli)era'les$
statement o% the &rocedures$ rules$ and a&&lica'le methods to 'e ado&ted(
1.2 SCOPE OF THE PROJECT
#1 A1 Describe here the scope of the project, possibly referring to the Terms of
<eference $To<%. This section must clearly demonstrate which activities this /"0/ is
applicable.
1.3 DEVIATIONS FROM THE PMQP
#1 In the case of deviation from this /"0/ writing guide, the following information
must be given in this section3
an introductory te)t e)plaining the structure of the /"0/
the precise reference of the standard to which the /"0/ adheres
Project Management and Quality Plan Page .
IDA-MS-PMQP
Issue 3
a reference to appendi) $A% containing a crossreference table to demonstrate
how the /"0/ meets the re1uirements of this guide.
1.4 REFERENCES AND APPLICABLE DOCUMENTS
1.4.1 R131(1&*1 ,%*/41&'-
#1 All reference documents must be listed, giving for each its name, its identification,
version number and issue date and a se1uential number to use as reference in the te)t
$<1,...<n%.
#& Typically, among reference documents are3
internal guides, studies document
organisational notes
technical notes
legal documents
wor!ing documents.
1.4.2 A5520*)621 ,%*/41&'-
#1 All applicable documents must be listed, giving for each its title, its reference, the
version number, the issue date and applicable sections or subsections and a
se1uential number to use, if necessary, as reference in the te)t $A1,...An%.
#& It is recommended that the applicable sections of a document be specified precisely,
as sometimes only part of a document is applicable.
#' Typically, among applicable documents are3
the IDA"# methodology $or agreed components thereof%
the IDA Architecture ?uidelines
the Invitation to Tender document
the /roposal submitted by the supplier A subcontractor
the Terms of <eference for the project and anne)es
the signed -ontract
specific standards to be adhered to
documents that e)ist and cover the contents of some sections $e.g. Development
/lan, -onfiguration "anagement /lan, -hange -ontrol /lan, #ecurity /lan,
Test /lan, #pecifications etc.%.
1." TERMINOLOGY
1.".1 A66(170)'0%&- )&, )*(%&84-
#1 All abbreviations and acronyms used in the /"0/ must be e)panded and e)plained.
Project Management and Quality Plan Page /
IDA-MS-PMQP
Issue 3
#& "ention both the e)pansion and the acronym on first use in the te)t. 9)cessive use of
abbreviations and acronyms ma!es reading difficult. That is why it is recommended
that their use be limited to a few words commonly employed in the field.
#' It is possible to combine this section and the following one into a unified glossary.
Depending on the si@e of the glossary, creation of an appendi) to contain it may help
the *usability+ of the /"0/.
1.".2 D130&0'0%&-
#1 All terms, the meaning of which may lead to incomprehension, misunderstanding or
ambiguities, must be defined.
#& /lease refer to the IDA ?lossary first, to find out if the term is already defined.
#' This section is very important, as words are often interpreted in very different ways
and thus can seriously affect the understanding of 1uality re1uirements.
Project Management and Quality Plan Page 0
IDA-MS-PMQP
Issue 3
2 OVERVIEW OF THE PROJECT
2.1 PROJECT DESCRIPTION
#1 The purpose of this section is to give a feeling of what the project is about. A short
presentation of the project must include3
a brief description of project phases and !ey activities in relation to the overall
project
the objectives and e)pectations of this project $this should include the business
and user objectives and e)pectations, and system objectives% i.e. what the project
is aiming to achieve and why it is important to achieve the stated aims
an e)planation of the overall environment of the project to include3
i a brief specification of all constituent parts of the system which are the
subject of this project. Include not only the parts for which the /roject Team
is directly responsible $either developed by itself or by others%, but also the
relationship with other systems $or subsystems%
ii an overview diagram showing the structure of the system as viewed by the
user, giving system, subsystems and main parts
iii the elements of hardware and software to be developed and those which are
to be bought by the /roject Team
the constraints that may adversely affect the progress or result of this project e.g.
the dependency on thirdparties, untried technology, restricted protocols A
platforms, user cooperation and readiness etc.
any limitations of the system i.e. give a brief statement of which features will be
limited, as a result of the constraints identified
the assumptions that need to be indicated here to ensure the smooth running of
the project e.g. availability of relevant reference documents A information in a
timely manner, data from users for test purposes etc.
the name and identification of the deliverables that will be produced.
2.2 DEVIATIONS SINCE THE ITT
#1 There could sometimes be a delay of more than ' months between the issue of the
Invitation to Tender and the project !ic!off, and it is possible that during this period
some components of the project may have been changed.
#& This section must list all the changes. If there are no changes, then the statement *Bo
deviation identified+ must be included in this section.
#' If the changes that have been identified result in having an impact that cannot be
accepted in the approved framewor!, the change control procedure must then be
used.
Project Management and Quality Plan Page 1
IDA-MS-PMQP
Issue 3
2.3 GLOBAL PROJECT TIME PLAN
#1 The initial global project time plan must to be presented in this section. It can be
presented either as a simple 9)cel spreadsheet table $for smaller projects% or in the
form of a ?antt -hart using a more sophisticated project management tool such as
"icrosoft /roject or /roject :or!bench, for inclusion in the appendi).
#& The subse1uently revised and updated project time plans are to be provided
separately so that this /"0/ need not be reissued each month, when the project time
plan is reviewed and updated.
#' As a minimum re1uirement, these details must be included $for each of the project
phases and the !ey activities and milestones% into the project time plan3
start date for the activity
delivery dates
overall contractual deadline
intermediate dates lin!ed to 1uality assurance type activities such as validation,
reviews, project progress meetings etc.
events lin!ed to user6s obligations such as providing e1uipment, interfaces, data
for testing, approval of documents etc.
2.4 CONTRACTUAL WOR9 UNITS
#1 >or each wor! unit defined in the contract $or the wor! in its entirety if it is not
divided in the contract%, the following information must be provided.
description of the unit $brief description if it is already detailed in the contract%
estimation of production deadlines3 it should correspond to deadlines mentioned
in the contract for that unit
estimation of the amount of manmonths
estimation of necessary resources in e1uipment $where applicable%
#& Information can usefully be presented using tables. Information about the wor!load
and resources $listed above% must be consistent with those the supplier already !nows
through the proposal or commercial negotiation.
2." DELIVERABLES AND PROJECT DOCUMENTATION
#1 #everal types of deliverables e)ist3
products bought by or created under the responsibility of the /roject Team,
products provided to the /roject Team by the IDA project or other involved
groups.
#& Those products
1
may comprise3
1
Product, 2esult o% acti)ities or &rocesses( A &roduct may include ser)ice$ hardware$ &rocessed
materials$ so%tware or a com'ination thereo%( A &roduct can 'e tangi'le 3e(g( assem'lies or &rocessed
materials4 or intangi'le 3e(g( +nowledge or conce&ts4$ or a com'ination thereo%%( IS5 1661, 111
Project Management and Quality Plan Page 16
IDA-MS-PMQP
Issue 3
hardware
software
project related materials
training
system documentation and manuals
#' All deliverables must be identified here. They could be categorised as3
2usiness deliverables provided by the supplier, which will satisfy the business
needs. The list should be developed and refined to ensure that it contains a
complete and correct specification of both the final products and also the main
immediate ones, which have to be developed as steppingstones to the final
products.
/roject "anagement deliverables, provided by the supplier, which are produced
to help manage, control and monitor the progress of the project, as well as
fulfilling the obligations demanded by the methodology and standards adopted
e.g. Design #pecification, Development /lan, -onfiguration "anagement /lan,
Test /lan, #ecurity /lan etc.
Deliverables provided by the client, which are usually related to3
information in the form of documents
software that needs to be integrated or tested with the main business
deliverable
hardware that needs to be interfaced to the final product
test data for acceptance testing
Deliverables provided by other parties, which are usually related to
specific information in the form of documents
specific piece of software
specific hardware
#, >or easy identification, the deliverables may be listed in a matri) table. An e)ample
is given below.
De+i!er(1+es Pro!ided
1, Supp+ier
Pro!ided
1, IDA
Pro&ect
Pro!ided
1, ther
:roups
T(r)et
De+i!er,
D(te
Project Management and Quality Plan Page 11
IDA-MS-PMQP
Issue 3
3 PROJECT ORGANISATION AND RESPONSIBILITIES
3.1 HIGHER LEVEL PROJECT ORGANISATION STRUCTURE
#1 A formal project organisation structure $with role titles% must be identified here,
which would allow for channels of communication to decisionma!ing forums
between the IDA project and the supplier.
#& 9ach role title identified must be bac!ed up by a role description which would specify
the responsibilities, goals, limits of authority, relationships, s!ills, !nowledge and
e)perience re1uired of the role. These detailed role descriptions would best be
included in the appendi).
#' The project organisation structure would best be presented in a graphical or chart
form, showing3
the hierarchical dependency between the management group overseeing the
project,
the /roject "anager and the different team leaders $when this level of
organisation e)ists%, and also
the organisational environment of the project with entities e)ternal to the
development $e.g. e)pert group, technical committee, 1uality assurance, the
client%.
#, #pecify the highest authoritative level of the project organisation which represents at
managerial level the 2usiness, Cser and #upplier interests of the project. This
usually ta!es the form of either a /roject 2oard or a /roject #teering -ommittee.
The composition of the /roject 2oard or the /roject #teering -ommittee should
therefore comprise of at least
a #enior 9)ecutive who loo!s after the business interest of the project $e.g. a
senior IDA representative%,
a #enior Cser who champions the desired outcome re1uired by users and ensure
that the project delivers it $e.g. senior "ember #tate <epresentative, Cser ?roup
representative, or 9)pert ?roup representative%,
a #enior #upplier member who has the authority to provide the necessary
resources to deliver the contractual products.
3.2 THE COMMISSION:S OBLIGATIONS AND RESPONSIBILITIES
#1 Dist here the -ommission6s obligations and responsibilities. These may relate to3
<esources $personnel, premises, hardware, software and any other e1uipment%
put at the projectEs disposal
-oordination of activities involving e)pert and user groups, technical
committees
/roviding the deliverables re1uired for use by the supplier
Project Management and Quality Plan Page 12
IDA-MS-PMQP
Issue 3
/roviding all documentation and information necessary for the project within
acceptable delays. This includes sufficient availability of the users and other
involved persons
/rocedures and timetables for the acceptance of deliverables which have to be
respected by the IDA project. Approval of a deliverable imply the approval of the
users concerned with the content of the deliverable. A deliverable cannot be
considered accepted until the IDA /roject "anager has signed it off.
A fast feedbac! from the IDA project to the #upplier. This is a necessary
condition to diagnose 1uic!ly any possible misunderstandings between the
partners. It is therefore important that the IDA /roject comment on minutes of
meetings and drafts of documents as soon as possible.
3.3 OBLIGATIONS AND RESPONSIBILITIES OF OTHER INVOLVED GROUPS
#1 <eproduce, and if necessary e)tend, the te)t below.
"1 #he grou&s identi%ied as ha)ing in)ol)ement in this &roject must, -
Pro)ide documentation and access to s&ecialist in%ormation( Mem'ers o% ex&ert
grou&s and technical committees ha)e to &ro)ide all documentation and
in%ormation necessary %or the &roject within acce&ta'le time-scale
7nsure attendance at meetings to &ro)ide ex&ert in&ut( Mem'ers o% ex&ert grou&s
and technical committees ha)e to 'e a)aila'le to attend those meetings that
re*uire their &resence in %urthering the &roject8s &rogress(
3.4 9EY PROJECT PERSONNEL AND REPRESENTATIVES
#1 Cse the e)ample table below to list all !ey project personnel involved with the project.
#& <eproduce, and if necessary e)tend, the italic below.
"1 All the +ey &ersonnel %rom the main contractor$ su'-contractor$ IDA &roject$ 9sers
2e&resentati)es$ Quality contractor$ 7x&ert :rou&s and #echnical ;ommittees are
identi%ied in the ta'le 'elow(
Ro+e Tit+e 4(me Comp(n, @
r)(nis(tion
Cont(ct Det(i+s
-em(i+ @ te+..
#' This mandatory sentence must follow the table3
"2 Any change to the Su&&lier8s Project Manager shall 'e su'ject to the ;ommission-s
written agreement(
#, 9ach of the role title identified must be fully described as to why they are involved in
the project and what their responsibilities, contributions and e)pectations are. If there
are many roles involved then the descriptions would be better placed in an appendi)
to the /"0/.
Project Management and Quality Plan Page 13
IDA-MS-PMQP
Issue 3
3." SUBCONTRACTORS
#1 All the subcontractors that the supplier intends to use in performing its obligations on
the project must be listed here. This list shall specify the name and address of the
subcontractor organisation, the nature of the products or services that it will provide
as a part of the project, the contact person and the start A end dates for the
re1uirement.
#& <eproduce, and if necessary e)tend, the te)t below.
"1 #he su&&lier$ as &rime contractor$ has %ull res&onsi'ility %or the &roducts or ser)ices
&ro)ided 'y the su'contractor( <elow is a list o% the su'contractor3s4 to 'e used(
Su1contr(ctor 4(ture of Ser!ices Pro!ided Cont(ct Person D(te ReAuired
r)(nis(tion St(rts Ends
3.# ESCALATION PROCESS
#1 A description of the process by which project problems and other e)ceptions are ta!en
to progressively higher levels of management attention within the -ommission and
the supplier organisations must be included here.
#& The criteria for deciding when these escalation actions are to ta!e place must be
specified.
#' <eproduce, and if necessary e)tend, the te)t below.
"1 #his &rocedure would a&&ly when,
Project exce&tions meet the s&eci%ied escalation criteria
agreement cannot 'e reached on Project Issues or Pro'lems
Project Management and Quality Plan Page 1
IDA-MS-PMQP
Issue 3
4 PROJECT PROCESS CONTROLS
#1 The /"0/ must include a number of control measures to manage, monitor and
communicate the project activities and deliverables. This section shall specify the use
of plans, the production of reports that help to measure and monitor project progress,
and the controls and measures adopted to ensure the success of the project.
4.1 PLANS
#1 All the clientfocused plans that will be produced and implemented for this project
must be listed here. Include the target available dates for each of these plans. The
precise list of plans to be included must be agreed with the /roject ;fficer for the
specific project.
#& The following list, which is not e)haustive, should be tailored and used according to
the needs based on the si@e and comple)ity of the project3
Acceptance /lan
-onfiguration "anagement /lan
-hange -ontrol "anagement /lan
Installation /lan
"igration A -onversion A Transition /lans
/roduct #upport /lan
/roject ;perational 0uality /lan
<e1uirements "anagement /lan
<eplication, Delivery, Installation and #ervicing /lan
<esources /lan
<is! "anagement /lan
#ecurity /lan
#ervice Implementation /lan
Test #trategy /lan
Test /lans
Training /lan
4.2 PROGRESS MEASUREMENT AND MONITORING
#1 The means and the types of information that would be needed and used to assist with
measuring and monitoring the progress of the project must be described here. The
following list, which is not e)haustive, should be tailored and used accordingly based
on the si@e and comple)ity of the project3
#& Information about work progress. The means by which the #upplier /roject "anager
monitors progress and informs IDA, the /roject ;wner, his management and the
project team about the project progress must be stated here. The progress of a project
Project Management and Quality Plan Page 1!
IDA-MS-PMQP
Issue 3
is usually reported in the form of a /roject /rogress <eport, which is produced by the
#upplierEs project manager and sent to the /roject ;fficer before the progress
meeting, along with the meeting notification and agenda.
#' A suggested table of contents for the /roject /rogress <eport is given in section F.
#, The fre1uency and the format of the /roject /rogress <eport must be agreed in
conjunction with the /roject ;fficer.
#7 ;ther documents that provide details for monitoring purposes are3
A first version of the project time plan. This must be provided at the beginning of
the project. It will need to be updated monthly until the final acceptance. The
updating of the project time plan should ta!e place before each progress meeting
and would usually contain several milestones, at least one per wor! unit. The
progress should be evaluated with respect to the milestones.
During the guarantee and maintenance periods, progress will be measured on the
basis of the ;bservation <eports and -hange <e1uests produced, and the
Actions ta!en. The major points will be the response time to, and the importance
of, reported problems or re1uired modifications.
#8 Project progress meetings. The project progress meeting must be held at least
monthly until the final acceptance. The #upplier is responsible for preparing and
sending the meeting notification and agenda to all the e)pected participants 7
wor!ing days before the meeting. It is, however, up to the -ommission to ma!e sure a
meeting room is available. "inutes of the meeting are to be provided by the #upplier
after each project progress meeting within 7 wor!ing days.
#F Technical and informal meetings. These may be held more fre1uently, especially at
the beginning of the project, to maintain a good coordination between the #upplierEs
team, the -ommission and other involved parties. The participants to these meetings
will vary according to the meetingEs objectives. In all cases, minutes of the meeting
must be written by the #upplierEs representative and distributed to the meetingEs
participants and both project managers $IDA and the #upplier%.
4.3 PROCESS CONTROLS
#1 The purpose of adopting controls is to ensure that the project3
Is producing the re1uired products which meet the defined Acceptance -riteria
Is being carried out to schedule and in accordance with the resource and budget
plans
<emains viable
#& The level of controls to be applied to the management of the project must be
described here.
#' The following list, which is not e)haustive, should be tailored and used according to
the needs based on the si@e and comple)ity of the project3
#, Quality reviews and approval process. Indicate the fre1uency and types of 1uality
reviews, the approval process and other verification activities that will be adopted
throughout the life of the project and its development lifecycle. If there is a need for
Project Management and Quality Plan Page 1.
IDA-MS-PMQP
Issue 3
a project audit to be performed during the lifespan of the project, then it must be
indicated here.
#7 Risk Management. It must be specify how the identified project and business ris!s
would be monitored and managed. It may be useful to list them in the form of a <is!
"atri) table that could be easily updated with the actions ta!en to minimise or reduce
them.
#8 hange ontrol. The change control mechanism must be defined for managing
changes to the contractual and agreed re1uirements, including the authorisation level
for the approval of changes, and the interfacing between the supplier and the
-ommission
#F !tandards and protocols. -odes of practice, ?uidelines, #tandards, rules and
conventions that are used in the project and applied to the production of
documentation or to other development wor! must be listed here.
#G Project file. The creation and inde)ing of all project documents must be detailed here
and performed to an agreed standard. This is so that the project file contains all the
relevant documents that could use not only to manage the project but also for future
evaluation purposes. The use of standard reports or forms should also be detailed
here.
#H Monitoring of subcontractors. To monitor the effectiveness of subcontractors the
supplier, who is effectively, the prime contractor must consider addressing3
verification and chec!points processes with an indication of3
the authority responsible for the action
a short description of what is going to be verified e.g. subsystem,
documentation, etc.
when it will ta!e place e.g. stated fre1uency or at the end of a phase
$completion of a document, end of production, etc.%
the type of action to be ta!en e.g. inspection, wal!through, review, audit, etc.
the type of records that will be produced and !ept $inspection report, test results
acceptance sheet, audit report etc.%.
Project Management and Quality Plan Page 1/
IDA-MS-PMQP
Issue 3
" ACCEPTANCE AND PAYMENTS
#1 The acceptance and payments processes, that are agreeable to the ommission,
must be described here. The following list, which is not e)haustive, should be tailored
and used accordingly based on the si@e and comple)ity of the project. <eference may
need to be made to -ommission procedures3
#& >or simplicity, list all the products that have to be formally accepted by IDA
$deliverables, intermediate deliveries, documents, etc.% and when this process is to
occur $end of phase or final acceptance%. Indicate when approval is re1uired, the
time allowed for comments, and where the decision is to be recorded.
#' The e)ample table below could be used to clearly identify the products re1uiring
formal acceptance.
Pro&ect
ph(se
De+i!er(1+es 5ser B
IDA
Re!ie"s
Fin(+ IDA
Re!ie"
T(r)et
Appro!(+
D(te
Appro!(+
-? or 4.
#, Approval and disapproval must be formally notified and recorded.
#7 If an acceptance is lin!ed to a payment, a copy of the formal acceptance by IDA must
be anne)ed to the invoice.
".1 USE OF DELIVERY NOTES
#1 -onfirm here the supplier6s adherence to the /roject ;fficer6s delivery note usage
practice. This means that all deliverable items are to be delivered by the #upplier to
the designated contact point for deliveries. #ince in most cases deliverables are
capable of being emailed the normal practice is that a covering email should be
sent with the deliverable and the /roject ;fficer6s designated contact will
ac!nowledge receipt of the deliverable by means of a return email.
#& The covering email should include the following details3
<eference to what is delivered3
i reference and version number of document
ii product identity name and number with version number and serial number
<eference to the deliverable as planned in the /"0/
<ecipient information,
>ormat of deliverable.
#' This return email shall not necessarily imply acceptance of the deliverable, however
it will confirm the ability to open the attached files. A deliverable cannot be
considered accepted until the IDA /roject "anager has signed it off.
Project Management and Quality Plan Page 10
IDA-MS-PMQP
Issue 3
".2 GENERAL ACCEPTANCE PROCEDURE
#1 The general acceptance procedure that is agreeable to the -ommission must be
described here. #ome of the points to consider are3
Dates of submission of deliverables for acceptance. These must be agreed in
advance by IDA $see section &.'%. 2earing in mind that the review process may
involve users and e)pert groups, a realistic turnaround timescale for comments
to be fed bac! to the supplier should be &I wor!ing days. At the end of the &I
wor!ing day period, the deliverable shall be deemed to be accepted if no
comments are made to the #upplier.
:here comments from user and e)pert groups are invited, it should be the /roject
;fficer6s responsibility to collate and decide on the overall acceptability of the
comments before transmitting the final comments bac! to the supplier.
:hen the final comments are fed bac! to the supplier, by the -ommission, an
agreed revision shall be produced by the #upplier within &I wor!ing days.
>ormal signing off by the IDA /roject "anager shall constitute acceptance.
The acceptance of software modules will normally be based on the successful run
of tests described in the Acceptance Test /lan. <epresentatives of the
-ommission, with support from the #upplier6s representative$s%, will perform this
operation. The results must be logged in the Acceptance Test <eport.
".3 PAYMENT
#1 Describe the payment schedule with a clear definition of the trigger for each
payment. $This may be a restatement or a clarification of the relevant contractual
clause%. The triggers could be3
A given date
A certain event
Acceptance of a set of deliverables
".4 FINAL ACCEPTANCE AND CLOSURE OF THE PROJECT
#1 This processes for these important final steps must be described here so that the final
acceptance and project closure is performed effectively. The following list, which is
not e)haustive, should be tailored and used accordingly based on the si@e and
comple)ity of the project3
chec! the e)tent to which the objectives set out in the /"0/ have been met
confirm to what e)tent all e)pected products have been handed over and
accepted by the customer
indicate whether maintenance and operation arrangements are in place $where
appropriate%
ma!e recommendations for any followon actions and lessons learned resulting
from the project
detail the handling of reservations
Project Management and Quality Plan Page 11
IDA-MS-PMQP
Issue 3
communicate with the /roject 2oard A /roject #teering -ommittee on closure of
the project and to notify all involved parties
#& It is the /roject ;fficer6s responsibility to send a final acceptance note to the #upplier
to signify project closure.
Project Management and Quality Plan Page 26
IDA-MS-PMQP
Issue 3
# CONTROL OF THE PMQP
#.1 PMQP PRODUCTION
#1 >or large projects, identify the role titles responsible for preparing and producing the
various sections of the /"0/. A table may usefully summarise this information. This
is not necessary for smaller projects or those that do not involve multiple parties.
#.2 PMQP APPROVAL
#1 -onfirm here the adherence to the standard /"0/ approval process which is3
The supplier6s /roject "anager prepares the /"0/.
An initial draft is introduced for review at the project !ic!off meeting, which
normally occurs within & wee!s of contract signing.
The user representative, the any designated 0uality Assurance authority, and the
/roject ;fficer review the /"0/. -ollated comments are then fed bac! to the
supplier within the specified turnaround period.
-omments are integrated into the /"0/ in order to produce the final version
which has to be approved by the IDA /roject "anager.
The first issue is delivered within two wee!s of the !ic!off meeting.
#.3 LAC9 OF ADHERENCE TO THE PMQP
#1 Define a process that would allow the supplier6s and the -ommission6s 1uality
authorities to3
identify the lac! of adherence to the /"0/
evaluate the impact and conse1uences as a result of the nonadherence
initiate corrective actions.
#& 9ither describe, in detail, the procedure to be followed or ma!e reference to the
applicable 0uality #ystem procedure if available.
Project Management and Quality Plan Page 21
IDA-MS-PMQP
Issue 3
$ SECTIONS FOR A PROJECT PROGRESS REPORT
#1 A project progress report must be structured as defined below.
1 Introduction
1(1 Pur&ose o% the document
1(2 Intended readershi&
1(3 5)er)iew o% the document
1( De%initions$ acronyms and a''re)iations
1(! 2e%erences
2 Project acti)ities
#ummarise activities in the previous reporting period.
Dist deliverables produced, presentations given and meetings attended.
3 =or+ &ac+age status
Describe the project wor! pac!ages started, continuing or completed during
the reporting period. #ummarise their status $e.g. in progress, suspended,
completed etc%.
Project deli)era'les status
Dist all the /roject deliverables and summarise their status $not started,
started, delivered, accepted%
! ;omments on the &roject
!(1 :eneral
Discuss the issues arising from the activities performed in the
reporting period.
!(2 >ew ris+s
Tabulate all ris!s to the project that have arisen in the reporting
period.
!(3 ;ontinuing ris+s
Tabulate all ris!s to the project raised in previous reports that still
e)ist
. Project wor+ &lan
>orecast what progress is e)pected in the ne)t period.
Jighlight any changes of plan with respect to the /"0/ and last progress
report.
Project Management and Quality Plan Page 22
IDA-MS-PMQP
Issue 3
DOCUMENT CONTROL
Tit+eC Project Management and Quality Plan
IssueC Issue 3
D(teC 1/ ?anuary 2661
AuthorC ?ohn <rin+worth
Distri1utionC 7; D: 7nter&rise @ :a)ino Murgia
Project #eam
ReferenceC IDA-MS-PMQP
Fi+en(meC 23.1!!!2.(doc
Contro+C 2eissue as com&lete document only
DOCUMENT SIGNOFF
4(ture of Si)noff Person Si)n(ture D(te Ro+e
Author Arances Ste)ens Senior ;onsultant
2e)iewer ?ohn <arcro%t ?ohn <arcro%t
2e)iewer ?ohn <rin+worth Project ;ontroller
DOCUMENT CHANGE RECORD
D(te 2ersion Author Ch(n)e Det(i+s
60 August 2666 Issue 1 Dra%t ! ?ohn <arcro%t 2e)iew comments
13 >o)em'er 2666
3B Issue 1 Dra%t
.4
?ohn <rin+worth Incor&orating ;omments
%rom the ;ommission
1! ?anuary 2661 Issue 3 Dra%t 1 Sue #urner 2e%ormatted
1/ ?anuary 2661 Issue 3 Mar+ Pillatt Issue