EN 9200:2004

SLOVENSKI STANDARD
01-april-2005
Aeronavtika - Vodenje programov - Smernice za specifikacijo vodenja projekta
Aerospace series - Programme management - Guidelines for project management
specification
Luft- und Raumfahrt - Programm-Management - Richtlinie für eine Projektmanagement-
Spezifikation
Série aérospatiale - Management de programme - Recommandation pour une
spécification de management de projet
Ta slovenski standard je istoveten z: EN 9200:2004
ICS:
03.100.40 Raziskave in razvoj Research and development
49.020 Letala in vesoljska vozila na Aircraft and space vehicles in
splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 9200
NORME EUROPÉENNE
EUROPÄISCHE NORM
November 2004
ICS 49.140
English version
Aerospace series - Programme management - Guidelines for
project management specification
Série aérospatiale - Management de programme - Luft- und Raumfahrt - Programm-Management - Richtlinie
Recommandation pour une spécification de management für eine Projektmanagement-Spezifikation
de projet
This European Standard was approved by CEN on 4 June 2004.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European
Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national
standards may be obtained on application to the Central Secretariat or to any CEN member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CEN member into its own language and notified to the Central Secretariat has the same status as the official
versions.
CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia,
Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2004 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 9200:2004: E
worldwide for CEN national Members.

Contents Page
Foreword.3
Introduction.4
1 Scope .4
2 Programme Management.6
3 Normative references .6
4 Terms and Definitions .6
5 Project context.15
6 Project establishment .16
7 Project planning.17
8 Risk management .25
9 Configuration management.27
10 Documentation management .30
11 Interfaces with other disciplines.32
12 Project monitoring and control .36
13 Resource Management .39
14 Quality assurance.41
15 Project Closure .42
Annex A (informative) Documents of accompaniment .43
Bibliography.44

Foreword
This document (EN 9200:2004) has been prepared by the European Association of Aerospace
Manufacturers - Standardization (AECMA-STAN).
After enquiries and votes carried out in accordance with the rules of this Association, this Standard has
received the approval of the National Associations and the Official Services of the member countries of
AECMA, prior to its presentation to CEN.
This European Standard shall be given the status of a national standard, either by publication of an identical
text or by endorsement, at the latest by May 2005, and conflicting national standards shall be withdrawn at
the latest by May 2005.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to implement this European Standard: Austria, Belgium, Cyprus, Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland
and the United Kingdom.
Annex A is informative.
Introduction
Project management aims at planning, monitoring and control of all aspects of a project, and the motivation
of all those involved in it, to achieve the project objectives, on time and to the specified cost, quality and
performance.
It requires:
 the definition of the activities,
 the roles and the responsibilities for the various actors,
 consistency between their activities,
 capacity for communication between them,
 a stable and rigorous project organisation.
To achieve these objectives, the present document describes the key best practices for the management of
an aerospace project, to be adapted specifically for each particular project to be managed.
In this standard, the customer is either an external identified customer, or an internal entity within the
organisation, in charge of receiving or accepting the product. Additionally, this standard may also be used as
a basis for the relationship between customers and suppliers at any level of the supply chain.
Prior to contract negotiations, the customer will issue a management specification, against which a supplier
will submit a management plan. This document will assist in that process by indicating the major issues
presented in both documents.
The customers in charge of the establishment of the project management specification should be aware that
any management requirement has an impact on the costs and that, as in the case of the requirements for a
product, the minimum acceptable requirements should be an objective.
The project management specification is to be established with the objective of achieving the highest
effectiveness in this discipline. In particular, attention is drawn to the possibility for suppliers to use, to the
maximum extent, their own internal methods and procedures, in order to obtain quality, reliability and
limitation of costs, provided internal procedures meet this recommendation.
1 Scope
For a given aerospace project, the present document is intended to be used as a reference to current best
practices. These can be used as a guideline for the creation and negotiation of the project management
specification between a customer and a supplier, and hence lead to the creation of the project management
plan.
It may be used for any project utilising several actors at different levels. In particular in the case of large
projects it presents provisions recommended for the management of a project according to (see Figure 1):
 project organisation,
 work breakdown structure,
 phasing and scheduling,
 risk management,
 configuration management,
 documentation management,
 interfaces with other disciplines,
 project monitoring and control,
- technical performance control,
- cost control,
- schedule control,
 resource management,
 quality assurance,
 project closure.
PROJECT MANAGEMENT
Project
Risk management Quality assurance
establishment
(clause 8) (clause 14)
(clause 6)
Configuration
Project planning
management
(clause 7)
(clause 9)
Documentation
management
(clause 10)
Interfaces with
other disciplines
(clause 11)
Project monitoring and control
(clause 12)
Technical performance
Cost control Schedule control
control
(subclause 12.2) (subclause 12.3)
(subclause 12.1)
Resource
management
(clause 13)
Figure 1 – Document organisation
The terminology employed is explained in clause 4. It is limited to specifying the context in which potentially
ambiguous terms are employed. As far as possible, this terminology includes definitions already appearing in
various normative documents, preferably international standards.
2 Programme Management
Referring to the definitions of project and project management as given in clause "0 Foreword", programme
management may be considered as the directing of a portfolio of projects which benefit from a consolidated
approach or towards one specific objective.
The common element of the projects in a portfolio is that they run simultaneously, or at least overlap with
one another, they share a number of common resources and are supposed to generate some income.
Under this definition, Programme Management is typically concerned with activities at a much higher level
within the organisation.
This standard will only focus on project management.
3 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
This document is consistent with the quality management requirements as considered in normative
references:
EN ISO 9000:2000, Quality management systems – Fundamentals and vocabulary (ISO 9000:2000)
EN ISO 9001:2000, Quality management systems – Requirements (ISO 9001:2000)
ISO 10006:2003, Quality management systems – Guidelines for quality management in project
ISO 10007:2003, Quality management systems – Guidelines for configuration management
EN 9100:2003, Aerospace series – Quality management systems – Requirements (based on
ISO 9001:2000) and Quality systems – Model for quality assurance in design,
development, production, installation and servicing (based on ISO 9001:1994)
EN 9130: 2001, Aerospace series – Quality management systems – Record retention
IEEE 1220:1998, Standard for Application and Management of the Systems Engineering Process IEEE
1)
Computer Society Document
4 Terms and Definitions
For the purposes of this European Standard, the terms and definitions given in EN ISO 9000:2000 and the
following apply.
4.1
acceptance (of a product or a document)
decision pronounced by the customer, acknowledging that the product or the document is in conformity with
the contractual commitments
NOTE The acceptance of a document does not involve the responsibility from the authority which accepts
it, on the use of the document.
4.2
acquisition strategy
set of principles defined by a customer as regards technologies, performances, costs, schedules,
co-operations to lead the project, …

1) Published by Institute of Electrical and Electronics Engineers Inc – 445 Hoes Lane – P.O.Box 1331 – Piscataway,
NJ 08855-1331 - USA
4.3
anomaly
gap between a current situation and an expected one
NOTE An anomaly justifies an investigation which might lead to the discovery of a nonconformity or a defect.
4.4
applicable configuration
configuration of a product identified by its changes from the configuration baseline
At a given moment, a product may have several applicable configurations.
4.5
approval
formal agreement allowing the use or the application of a document
NOTE The approving authority commits its own responsibility on the use of the document contents.
4.6
as built configuration
configuration of one product item identified by its gaps of conformity with respect to its applicable
configuration
4.7
audit
systematic and objective activity undertaken to determine to what extent the requirements related to the
agreed topic are satisfied
This audit is carried out by one or more persons independent from what is being audited.
4.8
change
changes to document content submitted to configuration control (Technical specification, Design data file, …)
and characterised by their impact on their use
4.9
configuration
functional and physical characteristics of a product as defined in technical documents and achieved in the
product
[ISO 10007:2003]
4.10
configuration baseline
configuration of a product formally established at a specific point in time, which serves as reference for
further activities
[ISO 10007:2003]
4.11
configuration item
aggregation of hardware, software, processed materials, services, or any of its discrete portions, that is
designated for configuration management and treated as a single entity in the configuration management
process
[ISO 10007:2003]
4.12
contractual hierarchy
stacking customer/supplier such as the supplier of level N becomes customer of the level N+1
4.13
corrective action
action to eliminate the cause of a detected nonconformity, or other undesirable situation
[EN ISO 9000:2000]
4.14
critical path
sequence of tasks where any delay affects the final date
4.15
design (of a product or a system)
set of technical output data of the design process describing the functional and physical characteristics of a
product or a system
NOTE The data is structured in the design data file.
4.16
design data file
a structured set of documents constituting the response of the product designer to the technical
requirements of the applicant
All the verifiable product characteristics (including the acceptance criteria) could be expressed in this
document, and the prescribed processes to produce it are indicated. This file allows identification of the
product, in order to prepare its manufacturing and inspection file and its operating documentation.
4.17
design justification data file
document gathering the whole set of information on studies and tests showing that a product is compliant
with its design data file and meets the specification expressing the need which this product shall satisfy
4.18
design justification plan
document established by the supplier describing the set of needed works in order to demonstrate that a
product compliant with its Design data file, meets the specification expressing the need which this product
shall satisfy
4.19
deviation permit
permission to depart from the originally specified requirements of a product prior to realisation
[EN ISO 9000:2000]
NOTE A deviation permit is generally given for a limited quantity of products or period of time, and for a
specific use.
4.20
execution plan
document established by every supplier which:
 describes:
- the main tasks and their logic (it ensures the consistency and integrates work of the different
disciplines such as management, systems engineering, integrated logistics support and RAMS, .),
- the resources (hardware and software) needed for their realisation;
 presents the schedule of works and in particular the critical paths of the project and the particular
actions to be carried out.
4.21
function
actions of a product or one of its components expressed exclusively in terms of finality
4.22
functional analysis
approach which consists in defining, ordering, characterising, prioritising and/or giving value to the functions
NOTE 1 The Functional analysis applies to creation or improvement of a product, it is in this case the
fundamental base of value analysis. Applied to the need only, it is the base for the establishment of the
functional performance specification.
NOTE 2 Ordering aims at classifying the operating functions (sometimes technical functions in the event of
redesign) in a logical way and allowing the identification of their interrelationships.
The characterisation consists in defining the evaluation criteria, in specifying their levels and in indicating their
flexibility.
Prioritising allows evaluation of the order of importance of the functions.
giving value to the functions prioritises their relative or absolute contributions, independently of the solutions
4.23
functional architecture
structured breakdown of the system in functions and sub-functions (internal and external interfaces and data
flow) which complies with a need
4.24
functional performance specification
document by which the applicant expresses his need (or the one which he is in charge to express) in terms
of operating and constraints functions
For each of them, evaluation criteria and corresponding levels are defined. To each of these levels, flexibility
must be associated.
NOTE 1 The establishment of a functional performance specification implies that a study allowed the precise
definition of the user’s needs.
NOTE 2 As an answer, the objective is to obtain the product proposal able to meet the expected service,
under the intended conditions, at minimum cost ; for this purpose a functional performance specification
expresses only results requirements and, in principle, no resources requirements.
NOTE 3 An evaluation criterion (of a qualitative nature) is accompanied by a scale allowing the location of its
level (of a quantitative nature).
NOTE 4 Obtaining the totality of the expected advantages of a functional performance specification implies
use of flexibility.
4.25
function-tree
representation of the product or the system showing the breakdown in functions and sub-functions which
must be fulfilled by successive products levels
4.26
integrated logistics support
co-ordinated and iterative set of technical and management tasks whose objectives are the following:
 to express the need in logistics support and the environmental constraints of use in the expression of
operational need;
 to contribute to obtaining a system design including the support elements:
- allowing to optimise and maintain its effectiveness for all its life time, in consistency with the user
resources,
- allowing total optimisation « performances/costs/schedules »;
 to realise, set up and to renew the support elements, according to the exploitation and the
maintenance needs.
4.27
integrated logistics support plan
document established by the supplier describing the organisation, the resources, the methods and the key
events set up to achieve the specified goals as regards logistics support
4.28
in use configuration
configuration of one product item identified by its as-built configuration and complemented by the
consequences of any in-service event on its functional and physical characteristics
NOTE Technical events, consumption of life potential, repairs etc. are examples of in-service events.
4.29
key-events
events considered as representative of the project progress and selected because of:
 their character as an outstanding task start/end,
 their interface character,
 their criticality, (technical, economical, schedule risks, etc),
 their contractual aspect (payment milestone).
4.30
lessons learnt
collection and exploitation, by all the actors of information concerning the events which have occurred
throughout the project
4.31
life cycle
this describes the whole series of developments of the product throughout its life starting from the expression
of its need until the disposal, whatever the form is
4.32
life cycle cost
total expenses for the whole life of the product for a given use
For a user, the life cycle cost includes the acquisition cost, the in service cost, the maintenance cost (spares,
etc.). Possibly the cost of modification, the cost of destruction, etc.
4.33
life profile
chronological description of the situations in which a product will be utilised from its delivery to its disposal
NOTE “situations” correspond to the different uses of the product and events in its life (e.g. transport,
handling, storage, maintenance, different missions.) with the respective duration and occurrences.
4.34
life time
duration, under a given set of conditions, of an interval of time, starting at a given moment and finishing
when the failure rate becomes unacceptable, or when the product is regarded as non repairable following a
failure
4.35
logistics support
set of tasks carried out on a system and including:
 maintaining or recovery of the system availability,
 providing the user and the various repairers, the supply items, the documentation, the tools, logistic
resources and the infrastructure needed to carry out the assigned tasks,
 users training,
 technical follow-up of the system in service.
4.36
logistics support analysis (LSA)
method contributing to the optimisation of the expected system design, starting from the expressed need and
the considered operational concepts
Then to define and optimise the products and the services necessary to implement, use and maintain the
availability of the system.
4.37
management plan
document established by the supplier to describe how he answers the set of requirements of the
management specification, according to its quality system
4.38
manufacturing and inspection file
document or set of documents detailing in a structured way the data necessary, in a given industrial context, for
the manufacturing and the inspection of a product compliant with its design described in the design data file
4.39
nonconformity
non-fulfilment of a requirement
[EN ISO 9000:2000]
4.40
operational need
need to be satisfied to fulfil a mission
4.41
phasing and scheduling
logical sequence of all the tasks of the project taking into account the requirements resulting from the
acquisition strategies and the execution plans declined in the stacking of customer/supplier
4.42
physical architecture
arrangement of physical elements which define a solution (products and operating processes) designed to
satisfy a need expressed by a functional architecture
[according to IEEE 1220]
4.43
preventive action
action to eliminate the cause of a potential nonconformity, or other undesirable potential situation
[EN ISO 9000:2000]
NOTE 1 There can be more than one cause for a potential nonconformity.
NOTE 2 Preventive action is taken to prevent occurrence whereas corrective action is taken to prevent
recurrence.
4.44
procedure
specified way to carry out an activity or a process
[EN ISO 9000:2000]
NOTE 1 Procedures can be documented or not.
NOTE 2 When a procedure is documented, the term "written procedure" or "documented procedure" is
frequently used. The document that contains a procedure can be called a "procedure document".
4.45
process
set of interrelated or interacting activities which transforms inputs into outputs
[according to EN ISO 9000:2000]
NOTE 1 Inputs to a process are generally outputs of others processes.
NOTE 2 Processes in a organisation are generally planned and carried out under controlled conditions to
add value.
NOTE 3 A process where the conformity of the resulting product cannot be readily or economically verified
is frequently referred to as a "special process".
4.46
product
result of a process
[according to EN ISO 9000:2000]
NOTE 1 There are four generic product categories, as follows:
- services (e.g. transport);
- software (e.g. computer programme, dictionary);
- hardware (e.g. mechanical parts);
- processed materials (e.g. lubricant).
Many products comprise elements belonging to different generic product categories. Whether the product is
then called service, software, hardware or processed material depends on the dominant element. For example,
the offered product "automobile" consists of hardware (e.g. tyres), processed materials (e.g. fuel, cooling
liquid), software (e.g. engine control software driver's manual), and service (e.g. operating explanations given
by the salesman).
NOTE 2 Service is the result of at least one activity necessarily performed at the interface between the
supplier and customer and is generally intangible. Provision of service can involve, for example, the following:
- an activity performed on a customer-supplied tangible product (e.g. automobile to be repaired);
- an activity performed on a customer-supplied intangible product (e.g. the income statement needed to
prepare a tax return);
- the delivery of an intangible product (e.g. the delivery of information in the context of knowledge
transmission);
- the creation of ambience for the customer (e.g. in hotels and restaurants).
Software consists of information and is generally intangible and can be in the form of approaches, transactions
or procedures.
Hardware is generally tangible and its amount is a countable characteristic. Processed materials are generally
tangible and their amount is a continuous characteristic. Hardware and processed materials often are referred
to as goods.
NOTE 3 Quality assurance is mainly focused on intended product.
4.47
product-tree
representation of the product or the system showing the physical breakdown in successive products levels
4.48
project
unique process, consisting of a set of co-ordinated and controlled activities with start and finish dates,
undertaken to achieve an objective conforming to specific requirements, including constraints of time, cost
and resources
[ISO 10006:2003]
4.49
project management specification
contractual document established by a customer prescribing the requirements to which his suppliers shall be
compliant for the activities of leading, organising and managing the project
4.50
project phase
part of a project during which a set of consistent and ordered necessary tasks is carried out to achieve a
predetermined goal
4.51
qualification
set of tasks contributing to provide proofs, while basing on theoretical and experimental justifications, that the
defined product satisfies the specified need and can be produced
The qualification decision is the act by which the customer, at the origin of the technical specification, attests
on the basis of theoretical and experimental justifications, that the defined product, identified by the design
data file, meets all the requirements of the Technical specification and can be produced.
4.52
quality assurance plan
supplier document which defines the quality assurance provisions specific to the project
4.53
RAMS
all aptitudes (Reliability, Availability Maintainability, Safety) of a product which enable it to have the specified
functional performances, at the requested time, for the considered duration and without damage for itself and
its environment
4.54
repair
action on a nonconforming product to make it acceptable for the intended use
[EN ISO 9000:2000]
NOTE 1 Repair includes remedial action taken on a previously conforming product to restore it for use, for
example as part of maintenance.
NOTE 2 Unlike rework, repair can affect or change parts of the nonconforming product.
4.55
requirement
need or expectation that is stated, generally implied or obligatory
[EN ISO 9000:2000]
NOTE 1 "generally implied" means that it is custom or common practice for the organisation, its customers
and other interested parties, that the need or expectation under consideration is implied.
NOTE 2 A qualifier can be used to denote a specific type of requirements, e.g. product requirements, quality
management requirement, customer requirement.
NOTE 3 A specified requirement is one which is stated, for example, in a document.
NOTE 4 Requirements can be generated by different interested parties.
4.56
review
activity undertaken to determine the suitability, adequacy and effectiveness of the subject matter to achieve
established objectives
[EN ISO 9000:2000]
NOTE Review can also include the determination of efficiency.
EXAMPLE Management review, design and development review, review of customer requirements and
nonconformity review.
4.57
rework
action on a nonconforming product to make it conform to the requirements
[EN ISO 9000:2000]
NOTE Unlike rework, repair can affect or change parts of the nonconforming product.
4.58
risk
feared event for the correct progress and obtaining of the project expected results
4.59
scrap
action on a nonconforming product to preclude its originally intended use
[EN ISO 9000:2000]
EXAMPLE Recycling, destruction.
NOTE In a nonconforming service situation, use is precluded by discontinuing the service.
4.60
support element
product or service implemented for the support of the system
4.61
system
set of complex hardware, software, personnel and operating processes, organised in a way to satisfy the
needs and to fulfil the expected services, in a given environment
NOTE A system when it constitutes a supply is a product.
4.62
systems engineering
engineering, implying the convergence of different technical disciplines, which allows the customer and the
supplier to co-ordinate the various technical processes (e.g. analysis need, design, …) concurring in an
iterative and exhaustive way to the adequacy of the solution throughout the product or system life cycle
4.63
task
action to be achieved, under fixed conditions, to obtain an expected and identified result
4.64
technical event
any significant technical event, predicted or not, arising during the life cycle of a product
4.65
technical specification
contractual document established by the product applicant, for the designer, and expressing his need (or the
one he is charged to express) in terms of technical requirements
The technical specification also defines the verification conditions of the requirements respect.
4.66
traceability
ability to trace the history, application or location of that which is under consideration
[according to EN ISO 9000:2000]
NOTE 1 When considering product traceability can relate to:
- the origin of materials and parts,
- the processing history, and
- the distribution and location of the product after delivery.
NOTE 2 In the field of metrology the definition in VIM: 1993, 6.10, is the accepted definition.
4.67
validation
confirmation, through the provision of objective evidence, that the requirements for a specific intended use or
application have been fulfilled
[EN ISO 9000:2000]
NOTE 1 The term "validated" is used to designate the corresponding status.
NOTE 2 The use conditions for validation can be real or simulated.
4.68
verification
confirmation, through the provision of objective evidence, that specified requirements have been fulfilled
[EN ISO 9000:2000]
NOTE 1 The term "verified" is use to designate the corresponding status.
NOTE 2 Confirmation can comprise activities such as:
- performing alternative calculations,
- comparing a new design specification with a similar proven design specification,
- undertaking tests and demonstrations, and
- reviewing documents prior to issue.
4.69
waiver (concession)
written authorisation to use a specimen or a batch of specimens of the product presenting a variation
between the as-built configuration and the applicable configuration
The waivers (concessions) are given for explicit uses.
4.70
work breakdown structure
global and structured breakdown of all the project, based on the product-tree or the function-tree, identifying
the tasks and the main resources required to perform the project
4.71
work packages
grouping of tasks related to the same product and the same supplier
5 Project context
Each project takes place in an overall environment, or context, which influences its implementation and
provides key features for defining its objectives.
It is essential that the various issues arising from inside or outside the company where the project will take
place are identified, understood and resolved before discussing and/or specifying the project management
requirements.
As far as the internal context is concerned, the following issues should be identified and understood:
 Business Issues: this deals with aspects such as target price, margins, generated cash flow, time to
market, exportability, etc.
 Strategic Issues: this deals with aspects such as business development opportunities, positioning
versus competitors, strategic partnerships, etc.
 Industrial Issues: the project may be an opportunity for developing new/strategic industrial capabilities
internally and/or with strategic partners or suppliers
 Technical/Technological Issues: aspects regarding the availability and mastering of key technical or
technological capabilities are essential to be considered when planning or resourcing the project
 Skills/Competencies Issues: key skills and competencies needed to successfully achieve the project
must be considered and understood
 Lessons learnt from previous projects
The external context should also be taken into account; this could deal with issues such as:
 Customer issues, as far as relationships, requirements, standards, regulations, reporting, agreements,
offsets, etc. are concerned
 Partners/Suppliers issues as far as their involvement, technical/financial/industrial capabilities are
concerned
 and any other stakeholders, such as involved public agencies, governments, lobbies, etc.
Once these issues are identified and understood, the project should consider the total picture and conduct
trade-off studies to derive the most appropriate compromise to set up the project objectives upon.
Project management specifications/requirements could be built upon these objectives. Of course, during the
life of the project, any significant change to identified issues (or new issue) should lead to a reassessment of
its consequences and a deriving of modified project objectives.
6 Project establishment
6.1 General
The project establishment should be prepared as a formal document based on project objectives,
external/internal context, available resources and the project business case.
6.2 Project objectives
Project objectives should be defined as a set of quantified targets in respect of performance / functionality,
phasing and scheduling, cost and quality.
Validation and confirmation should be sought through the project internal or external customer.
The project schedule should be defined by using major milestones which should be precisely defined. An
indication of deadlines for preliminary and/or critical project reviews should also be given.
The project objectives should be detailed and formalised during the project concept phase and should
contain Top Level Requirements, i.e.
 Top Level Product Requirements
 Top Level Project Management Requirements
 Top Level Marketing Requirements
 Top Level Business Requirements
 Top Level Procurement Requirements
 Top Level Product Support Requirements
 etc.
The assessment of project objectives should be checked throughout the whole project lifecycle.
6.3 Management of project external context
The sensitivity factors should be known and laid down in the business case and risk analysis. Depending on
the gravity of these factors, measures should be taken to reduce their possible impact.
Within the company, measures of establishing credibility for the project should be taken into account.
6.4 Management of project interactions
Possible synergies from/to other projects, or parts of them, should be taken into account.
6.5 Resource assessment
An estimate of required resources (personnel as well as infrastructure) for the whole project should be
undertaken.
Possible conflicts with resource availability should be highlighted within the risk analysis. If needed,
appropriate actions for an early resource prioritisation should be launched.
Any resource assessment should take into account the full supply chain including strategic alliances.
6.6 Project business case
The business case should contain as a minimum:
 Strategic interest;
 Market assessment;
 This should contain all market conditions which render the projects necessary, and should include
Market environment, market potential, market requirements, and the investigation of main competitors;
 Brief economic description;
 The indication of main economical parameters should be described, and should include the financing
model, funding sources, currencies, prices, etc.;
 Brief technical description;
 A technical description of the project objectives, including main technical features which determine
performance for a given cost, should be given and should include risks and opportunities, required
technologies, maturity of technology candidates, etc.
For the overall project viability assessment the following should be established in line with the Top Level
Requirements: Pricing policy, target cost, business case objectives, cash flow.
7 Project planning
7.1 Management specification and management plan
7.1.1 Purpose
The project management specification is a contractual document prescribing the requirements to which the
first level suppliers should conform for the activities of control, organisation and management of the project.
During the progress of the project, the suppliers may be subject to distinct and successive contracts
including, if necessary, a management specification which reflects the requirements of the customer.
The goal of the project management specification is to gather in the same document, the management
requirements. It should be established as soon as possible in the progress of the project (and in particular at
the stage of the invitation to tender), because it determines much of the project success.
The management specification and hence the management plans (see 7.1.3) constitute the project
management rules. These rules could be adapted to each project phase.
7.1.2 Application to all the actors of a project
Each actor at a given level has the role of customer in relation to his suppliers.
With respect to the management specification received from his customer, the actor located at a given level
adapts the management requirements for his suppliers in a way such as they satisfy his own requirements
and those of his customer.
The tailoring of the management requirements should be appropriate to the level of the supplier’s
participation, whilst ensuring the continuity and the stability of the project rules.
In all the customer/supplier relationships, the management requirements should be contractual.
7.1.3 Management plan
The management plan may be established by the supplier to describe how he answers the set of
requirements of the management specification, according to its quality system.
The management plan should be based upon and makes reference to company basis and standards The
level of document access to the customer should be defined within the contractual negotiations.
The management plan and the executive plans are different documents with different purposes (see Figure 2):
Contract
Customer
Management Technical
Specification Specification
Management Plan Execution Plans
Supplier
- Organisation - Development Plan
- … - Production Plan
- Configuration - …
Management Plan
- Quality Assurance Plan
- RAMS Plan, …
Figure 2 – Management and executive plans purposes
7.1.3.1 Setting-up
The management plan may refer to specific plans fulfilling the corresponding requirements of the
management specification (examples: quality assurance plan, integrated logistic support plan, etc.).
Each supplier should establish the relationship between the content of its management plan and the
requirements of the specification which it answers. Any possible variations are noted.
7.1.3.2 Acceptance
The supplier may submit to his customer, for acceptance, the management plan which he has prepared,
including the successive changes.
After acceptance, the management plan constitutes a supplier commitment.
7.1.3.3 Consistency of the management plans
When there are several suppliers at the same level, the customer may be led either to impose a set of common
rules, or to establish consistency between the management plans proposed by the various suppliers.
A customer may require, to ensure consistency, some management plans beyond his direct suppliers to be
supplied to him.
7.2 Project organisation
7.2.1 Purpose
The implementation of a project organisation is necessary to ensure the execution and the control of the
project. It should be the responsibility of each actor to ensure his ability to fulfil the project requirements
(contract review).
The organisation to be set up takes in account the considered project phases, the nature of the tasks to be
carried out and the specified required competencies. The project organisation should be consistent with
contractual and technical commitments.
Project peculiarities should dictate the most effective and the simplest mode of management and of
contractual relationships.
The managing and contracting responsibilities should be defined in order to evaluate the contractual and
legal commitments.
If the project has links with other projects, the responsibilities relating to the interface definition and
management may be specified and taken into account while setting up the project organisation.
7.2.2 Organisation requirements
The preparation, definition and setting up of the project organisation should be carried out consistently with
the project objectives.
At every level, the customer exp
...