ECSS-M-30B Draft 14
6 July 2007
Space project
management
Project planning and implementation
This ECSS document is a draft document distributed for Public Review.
It is therefore subject to change without any notice and my not be referred to as en
ECSS Standard until published as such.
End of Public Review: 28 September 2007.
ECSS Secretariat
ESA-ESTEC
Requirements & Standards Division
Noordwijk, The Netherlands
ECSS-M-30B Draft 14
6 July 2007
Published by: ESA Requirements and Standards Division
ESTEC, P.O. Box 299,
2200 AG Noordwijk,
The Netherlands
ISSN:
1028-396X
Price:
€ 10
Printed in The Netherlands
Copyright 2007 © by the European Space Agency for the members of ECSS
2
ECSS-M-30B Draft 14
6 July 2007
Foreword
This Standard is one of the series of ECSS Standards intended to be applied
together for the management, engineering and product assurance in space
projects and applications. ECSS is a cooperative effort of the European Space
Agency, national space agencies and European industry associations for the
purpose of developing and maintaining common standards.
Requirements in this Standard are defined in terms of what shall be
accomplished, rather than in terms of how to organize and perform the
necessary work. This allows existing organizational structures and methods to
be applied where they are effective, and for the structures and methods to
evolve as necessary without rewriting the standards.
The formulation of this Standard takes into account the existing ISO 9000
family of documents.
This Standard has been prepared by members of the Management Subgroup,
reviewed by the ECSS Executive Secretariat and approved by the ECSS
Technical Authority.
This document cancels and replaces ECSS-M-10B, ECSS-M-20B and ECSS-M30A.
3
ECSS-M-30B Draft 14
6 July 2007
Contents
Foreword...............................................................................................................................................3
Introduction ..........................................................................................................................................4
1
Scope .......................................................................................................................................4
2
Normative references ...............................................................................................................4
3
3.1
3.2
Terms and definitions ...............................................................................................................4
Terms and definitions ..................................................................................................................... 4
Abbreviated terms ......................................................................................................................... 4
4
4.1
4.2
4.3
4.4
Principles ..................................................................................................................................4
Project planning ............................................................................................................................. 4
Project organization ....................................................................................................................... 4
Project breakdown structures ......................................................................................................... 4
Project phasing .............................................................................................................................. 4
5
5.1
5.2
5.3
5.4
Requirements ...........................................................................................................................4
Project Planning Requirements....................................................................................................... 4
Project Organization Requirements ................................................................................................ 4
Project breakdown structures ......................................................................................................... 4
Project review requirements ........................................................................................................... 4
Annex A (normative) Project management plan - DRD.........................................................................4
Annex B (normative) Design and Development plan - DRD ..................................................................4
Annex C (normative) Product tree - DRD ...............................................................................................4
Annex D (normative) Work Breakdown Structure - DRD..........................................................................4
Annex E (normative) Work Package Description - DRD..........................................................................4
Annex F (informative) Determination of the appropriate WBS level of detail........................................4
Applicability matrix...............................................................................................................................4
Bibliography ........................................................................................................................................4
4
ECSS-M-30B Draft 14
6 July 2007
Figures
Figure 1
Figure 2
Figure 3
Figure 4
Product Tree Example ....................................................................................................... 4
WBS Schematic ................................................................................................................. 4
Typical project life cycle.................................................................................................... 4
Review life cycle................................................................................................................ 4
Tables
Table 1
Document Requirements List – Management documents ............................................... 4
5
ECSS-M-30B Draft 14
6 July 2007
Introduction
Project planning and implementation is the project function, which provides a
coherent set of processes for minimizing the technical, scheduling and economic
risks of the project. This is done by:
•
establishing the project requirements and constraints derived from the
Mission Statement and an initial set of assessments.
•
introducing phases and formal milestones enabling the progress of the
project to be controlled with respect to cost, schedule and technical
objectives (i.e. project control function).
•
defining project breakdown structures, which constitute the common and
unique reference system for the project management to:
— identify the tasks and responsibilities of each actor;
— ensure the coherence between technical, documentary, administrative
and financial activities of the whole project;
— perform scheduling and costing activities.
•
6
setting up a project organization to implement a structured and complete
approach to perform all necessary activities on the project.
ECSS-M-30B Draft 14
6 July 2007
1
Scope
The scope of this ECSS Standard is limited to describing the key elements of
Project Planning and Implementation and identifying the top level
requirements, processes and products that together provide a coherent and
integrated Project Planning across the 3 ECSS domains.
Where other ECSS Management, Engineering, or Product Assurance
Standards contain more specific and detailed requirements related to Project
Planning, pointers are provided to identify where these can be found within the
ECSS System.
7
ECSS-M-30B Draft 14
6 July 2007
2
Normative references
The following dated normative documents are called by the requirements of
this ECSS Standard and therefore constitute requirements to it. Subsequent
amendments to, or revisions of any of these publications do not apply.
NOTE However, parties to agreements based on this ECSS
Standard are encouraged to investigate the possibility of
applying the most recent editions of the normative
documents indicated below. For undated references, the
latest edition of the publication referred to applies.
1
8
To be published.
ECSS-E-10C 1
Space engineering
requirements
ECSS-Q-10A 1
Space product
management
–
System
assurance
–
engineering
Product
general
assurance
ECSS-M-30B Draft 14
6 July 2007
3
Terms and definitions
3.1
Terms and definitions
For the purposes of this document, the terms and definitions given in
ECSS-P-001B and the following apply.
3.1.1
discipline
specific area of expertise within a general subject
NOTE The name of the discipline normally indicates the type of
expertise (e.g. in the ECSS System, power, structures and
software are disciplines within the Engineering domain)
3.1.2
domain
general area of interest or influence covering a number of inter-related topics
or sub-areas
NOTE The name of a domain normally indicates the area of
interest (e.g. in the ECSS System, the Management,
Engineering, and Product Assurance branches represent
three different domains within the system).
3.1.3
function
combination and interaction of a number of operations or processes, which
together achieve a defined objective
3.2
Abbreviated terms
For the purposes of this document, the abbreviated terms given in
ECSS-P-001B and the following apply.
Abbreviation
Meaning
B/L
baseline
ELR
end-of-life review
ITT
invitation to tender
MCR
mission close-out review
MDR
mission definition review
9
ECSS-M-30B Draft 14
6 July 2007
10
RFP
request for proposal
PRD
project requirements document
RFQ
request for quote
ECSS-M-30B Draft 14
6 July 2007
4
Principles
4.1
Project planning
4.1.1
Introduction
Project planning encompasses all of the processes required to plan and execute
a project from initiation to completion at all levels in the customer/supplier
chain in a coordinated, efficient and structured manner. It is a project wide
activity requiring inputs from all project disciplines and close co-operation
across the project domains.
In principle, a proposal to initiate a Space Project can be raised by any party.
However, the most common initiators are:
•
individual governments, or co-operation between a number of governments
•
national, or international Space Agencies, either singly or collectively
•
national or international scientific communities
•
operators of commercial space systems
Although the project initiator is de facto the top level customer, and also
possibly the end user, in many cases the responsibility for the actual planning
and implementation of a space project is delegated to an agent acting on behalf
of the project initiator. In this ECSS standard, the top level customer is defined
as the organization responsible for letting the prime contract.
The following clauses describe the key elements to be addressed, assessed, and
balanced when planning a project.
4.1.2
Purpose and objectives of the project
These are defined by the project initiator, typically in the form of a Mission
Statement, together with technical and programmatic requirements and
constraints. They are normally coordinated with the top level customer, if one
has been assigned.
4.1.3
Risk assessment
The initial assessments of the technical and programmatic risks of a project are
carried out by the top level customer, based on the project initiator’s inputs
with respect to the purpose and objectives of the project, together with the
identified technical and programmatic constraints to be applied to the project.
The initial assessment is subsequently regularly expanded to include other
relevant parameters as they become available, and as the project matures.
11
ECSS-M-30B Draft 14
6 July 2007
Comprehensive risk assessments are conducted at each major project review
milestone.
4.1.4
Availability of and need to develop new technologies
This is an assessment carried out primarily by the top level customer to
identify the availability of the technology needed to implement the project. The
result of this assessment, which can be a significant cost and schedule driver is
a major input to the assessment of available resources and facilities needed to
implement the project and to the subsequent technical and programmatic risk
assessment.
4.1.5
Availability of and need to reuse existing
equipments/products
This is an assessment of the feasibility of reusing existing products and is
typically carried out either as a direct response to a top level customer
requirement, or as an option by suppliers to meet project cost and/or schedule
requirements. The result of this assessment, which also can have a significant
influence on cost and schedule is a major input to the assessment of available
resources and facilities needed to implement the project and to the subsequent
technical and programmatic risk assessment
4.1.6
Availability of and need for human resources, skills and
technical facilities
This is an assessment carried out by the top level customer of the resources
and skills available to implement the project and the availability of facilities
needed to carry out the project. The result of this assessment will show if
available resources, skills and facilities are adequate, or if additional skills,
resources, or facilities are needed to complete the project.
4.1.7
Development approach
The development approach for a project is defined by the top level customer to
comply with the project initiator’s Mission Statement, requirements and
constraints, and balancing these with the outcome paragraphs 4.1.3 to 4.1.5
above. The most important parameters in defining the development approach
are the model philosophy to be used and the qualification approach to be
applied.
4.1.8
Project deliverables
The top level customer has the responsibility for defining the project content in
terms of the deliverable products, needed to meet the project initiator’s Mission
Statement, as well as that needed to meet clauses 4.1.4, to 4.1.7 above.
4.1.9
Top Level Customer requirements and constraints
These are prepared by the top level customer based on the outcome of the
assessments carried out in 4.1.2 to 4.1.8 above and put into a format suitable
for direct application in an Invitation to Tender (ITT). They address technical
and programmatic requirements, as well as political, commercial, and
industrial constraints to be applied to the project and collectively represent the
Project Requirements Documents (PRD).
4.1.10
Project Requirements Documents (PRD)
The Project Requirements Documents are an integral part of an ITT (Invitation
to Tender), Request for Proposal (RFP), or Request for Quote (RFQ) prepared
and released by a customer to potential suppliers.
The PRD typically comprise
12
ECSS-M-30B Draft 14
6 July 2007
a.
Statement of work
b.
Management requirements
c.
Engineering requirements
d.
Product assurance requirements
e.
Programmatic requirements
f.
Other, project specific requirements (e.g. geographical distribution, model
philosophy to be applied)
g.
Documents Requirements List (DRL)
h.
Draft Business Agreement
Under the ECSS System, items b. to d. are contained in the M, E, and Q
standards, progressively tailored by each customer in the customer/supplier
chain to reflect the type and/or phase of the project covered by the Business
Agreement, as well as the required scope of the suppliers’ tasks.
4.2
Project organization
4.2.1
Introduction
The establishment of a well structured and coherent organizational structure
for implementing a project at all levels in the customer/supplier chain is a key
factor for ensuring an effective and efficient management approach. At each
level in the customer/supplier chain a project organization may be built as a
self-standing project team containing all necessary disciplines within the team
structure or, more often, can be built around a core project team containing key
project functions with other necessary functions being provided from outside
the project team as external support.
Irrespective of the organizational approach followed for a project, the elements
summarized below are relevant at all levels in the customer/supplier chain.
4.2.2
Organizational structure
It is essential that the project organizational structure is arranged to include
all disciplines required to implement the project with well defined and easily
identifiable functions as well as clear reporting lines, inter-relationships and
interfaces. All project actors below the top level customer and above the lowest
level supplier(s) have the roles of suppliers and customers, and their
organizational structure has to be built to accommodate both roles.
4.2.3
Responsibilities and authority
It is essential that the organizational structure provides a clear and
unambiguous definition and allocation of individual roles and responsibilities
together with the necessary authority to implement these within the internal
project set–up as well as towards project external interfaces.
4.2.4
Communication and reporting
Effective means of communication are essential tools for ensuring clear and
efficient inter-action between all project actors, as well as between the project
team and its external interfaces. Information technology is the primary means
for the exchange of information. Communication serves initially to provide
clarity about the project’s goals and objectives and subsequently, to support the
day to day work of the project team.
4.2.5
Audits
Audits are independent examinations to determine whether processes and
procedures specific to the project requirements are adequately applied,
13
ECSS-M-30B Draft 14
6 July 2007
implemented effectively and suitable to achieve the specified objective. They
are an essential tool to identify problem areas.
4.2.6
Project Management Plan
The top level project plan is the Project Management Plan which defines the
project management approach and methodology to be used throughout the life
cycle of the project, together with an overview of all elements of project
management disciplines. It provides pointers to supporting Management,
Engineering and Product Assurance Plans which together make up the total
planning documentation required to implement a project.
4.3
Project breakdown structures
4.3.1
Introduction
Project breakdown structures provide the basis for creating a common
understanding between the various participants. They break the project down
into manageable elements by:
•
identifying the space system in such a way that it can be sub-divided into
clearly defined functions and products,
•
attributing unique item identifications and definitions and defining the
associated tasks and resources;
•
identifying the responsibilities of individuals within the organization for
performing the work;
•
coordinating and optimizing the necessary resources required for
performing the tasks;
•
enabling a structured definition, production and verification of documents
for the management of
— all tasks to be performed,
— cost and schedule,
— interfaces,
—
configuration baselines,
— changes,
— risks.
4.3.2
Function Tree
The function tree is the structure resulting from breakdown of the system
performances into functions. Each function can be decomposed into sub–
functions, so making a “tree”, independent of the type of products involved. The
“function” approach is applied during project start–up or during the system
definition phase.
4.3.3
Product tree
The product tree is the breakdown of the system into successive levels of
hardware and software products or elements, based on the functions identified
in the function tree. The creation of product tree starts after the functional
structure of the product has been identified. As a minimum it includes items
submitted to customer configuration control and items that are the subject of a
technical specification. The product tree forms the basis for the elaboration of
the project work breakdown structure.
An example of a Product Tree is shown in Figure 1.
14
ECSS-M-30B Draft 14
6 July 2007
Satellites
Platform
ECSS-E-10
Structure
System
engineering
On-board
power
supply
Thermal
Control
Payload
Main parts of the System
Attitude
Control
Data
handling
Mission 1
Mission 2
Mission 3
Batteries
Antennas 2
Solar arrays
Repeater 2
Fuses
...
Structure 2
Receivers 2
Reflector 2
Amplifiers 2
Feeds 2
Filters 2
...
...
Figure 1 Product Tree Example
4.3.4
Work Breakdown Structure
The Work Breakdown Structure (WBS) is an effective project management tool
that assists both the customer and the supplier in fulfilling their business
obligations.
The purpose of the WBS is to provide a framework for managing planning and
control of cost, schedule and technical content. It divides the project into
manageable work packages, organized according to the nature of the work. It
identifies the total work to be performed with increasing levels of detail.
The WBS is the principal structure used in managing a project. It is derived
from the Product Tree, selected elements of which are extended to include the
customer-defined support functions and associated services. It defines the scope
of the work to be carried out, and is based on an analysis of all management,
product assurance and engineering tasks needed to complete the project. For
each element in the product tree, it is determined which tasks shall be
performed together with the required resources. These tasks are identified by
one or more work breakdown structure elements.
The WBS is the basis for :
•
identifying the necessary resources;
•
defining the work packages to the level necessary to manage the project;
•
planning and controlling schedule, cost and technical content of the work
packages
The schematic of a WBS is shown in Figure 2.
15
ECSS-M-30B Draft 14
6 July 2007
PROJECT
SYSTEM
SUBSYSTEM
ASSEMBLY
Product
Tree
UNIT
Support
Function
Extensions
MODEL
WORK BREAKDOWN STRUCTURE SCHEMATIC
Development
Model
Extensions
Figure 2 WBS Schematic
4.3.5
Work package
A Work Package (WP) can be any element of the WBS down to the lowest level
that can be easily measured and managed for planning, monitoring, and
control. The actual level in the WBS down to which control is required is
agreed between the customer and his supplier(s). However, each supplier is
explicitly identified in the work breakdown structure by at least one WP
4.4
Project phasing
4.4.1
Introduction
The life cycle of Space Projects is typically divided into 7 phases, as follows :
•
Phase 0 - Mission analysis/needs identification
•
Phase A - Feasibility
•
Phase B - Preliminary Definition
•
Phase C - Detailed Definition
•
Phase D - Qualification and Production
•
Phase E –Utilization
•
Phase F – Disposal
A typical project life cycle is illustrated in Figure 3. Project phases are closely
linked to activities on system and product level. Depending on the specific
circumstances of a project and the acceptance of involved risks, activities can
overlap project phases. At the conclusion of the major activities and the related
project reviews configuration baselines are established (see ECSS-M-40C).
16
ECSS-M-30B Draft 14
6 July 2007
Phases
Activities
Phase 0
Phase A
MDR
Phase B
Phase C
Phase D
Phase D/E
Transition
Phase E
Phase F
PRR
Mission/Function
SRR
PDR
Requirements
CDR
Definition
QR
Verification
AR
Production
ORR
FRR
LRR
Utilization
FQR
ELR
MCR
Disposal
Mission
objective
B/L
Configuration
baselines
Functional
configuration
B/L
Development
configuration
B/L
Functional
configuration
Design
configuration
B/L
Product
configuration
B/L
Development
configuration
Product
configuration
Figure 3 Typical project life cycle
Phases 0, A, and B, sometimes identified as the “preparatory phases” of a
project, are focused mainly on
•
the elaboration of system functional and technical requirements and
identification of system concepts to comply with the Mission Statement,
taking into account the technical and programmatic constraints identified
by the project initiator and top level customer.
•
the identification of all activities and resources required to develop the
space and ground segments of the project,
•
the initial assessments of technical and programmatic risk.
Phases C and D, sometimes identified as “the development phase”, comprise all
activities required to develop the space and ground segment systems and their
products.
Phase E comprises all activities required to operate, utilize, and maintain the
deliverable products of a project.
Phase F comprises all activities required to safely dispose all project products
launched into space as well as ground systems.
Each of the above project phases includes end milestones in the form of
mandatory Project Review(s), the outcome of which determines readiness of the
project to move forward to the next phase.
Information about organization and conduct of reviews is provided in
ECSS-M-HB-30A.
17
ECSS-M-30B Draft 14
6 July 2007
4.4.2
Relationship between Business Agreements and project
phases
A Business Agreement can cover a single project phase, a sequential grouping
of project phases or sub-phases (e.g. Phase B1/Phase B2; Phase B2/Phase
C1/Phase C2), depending on such factors as funding availability, competitive
tendering, schedule, perceived risk, etc. Irrespective of the approach used for
defining the scope of individual Business Agreements, all space projects
essentially follow the classical project phases in sequence and include all of the
major objectives and key milestones of each of these phases.
4.4.3
Project phases
4.4.3.1
Phase 0 (Mission analysis/needs identification)
Major tasks:
•
Elaborate the Mission Statement in terms of identification and
characterization of the mission needs, expected performance, dependability
and safety goals and mission operating constraints with respect to the
physical and operational environment and develop the first issue of the
functional specification.
•
Identify possible system concepts.
•
Perform preliminary assessment of programmatic aspects (cost, schedule)
•
Perform preliminary risk assessment.
Associated Mandatory Review Milestone
The Mission Definition Review (MDR) is held at the end of Phase 0.
The outcome of this review is used to judge the readiness of the project to move
into Phase A.
Main Review Objective(s)
The primary objective of this review is to confirm the mission requirements and
the preliminary programmatic assessment.
4.4.3.2
Phase A (Feasibility)
Major Tasks
•
Establish the preliminary management,
assurance requirements for the project.
•
Elaborate possible system concepts and compare these against the
identified needs, to determine levels of uncertainty and risks.
•
Assess the technical and programmatic feasibility of the possible concepts
by identifying constraints relating to implementation, costs, schedules,
organization, operations, maintenance, production and disposal.
•
Quantify and characterize critical elements for technical and economic
feasibility.
•
Propose the system concept(s) and technical solutions to be further
elaborated during Phase B.
•
Elaborate the risk assessment.
engineering
and
product
Associated Mandatory Review Milestone
The Preliminary Requirements Review (PRR) is held at the end of Phase A.
The outcome of this review is used to judge the readiness of the project to move
into Phase B.
18
ECSS-M-30B Draft 14
6 July 2007
Main Review Objective(s)
The primary objectives of this review are:
•
Release of the preliminary requirements.
•
Confirmation of the technical and programmatic feasibility of the system
concept(s).
•
Selection of system concept(s) and technical solutions to be carried forward
into Phase B.
4.4.3.3
Phase B (Preliminary Definition)
Major tasks
•
Finalize the project management, engineering and product assurance
requirements and plans.
•
Confirm technical solution(s) for the system concept(s) and their feasibility
with respect to programmatic constraints.
•
Conduct “trade-off” studies and select the preferred system concept,
together with the preferred technical solution(s) for this concept.
•
Establish a preliminary design definition for the selected system concept
and retained technical solution(s) including model philosophy and
verification approach.
•
Identify pre-development work on critical technologies or system design
areas when it is necessary to reduce the development risks.
•
Identify any long-lead item procurement required to meet project schedule
needs.
•
Conduct reliability and safety assessment.
•
Finalize the Product Tree, the Work Breakdown Structure and the
Specification Tree.
•
Update the risk assessment.
Associated Mandatory Review Milestones
There are 2 Mandatory Project Review Milestones associated with Phase B.
•
The System Requirements Review (SRR) held during the course of Phase
B.
•
The Preliminary Design Review (PDR) held at the end of Phase B. The
outcome of this review is used to judge the readiness of the project to move
into Phase C.
Main Review Objectives - System Requirements Review
The primary objectives of this review are:
•
Release of System Requirements.
•
Assessment of the preliminary design definition.
Main Review Objectives – Preliminary Design Review
The primary objectives of this review are:
•
Verification of the preliminary design of the selected concept and technical
solutions against project and system requirements.
•
Release of Management, Engineering and Product Assurance Plans.
19
ECSS-M-30B Draft 14
6 July 2007
•
Release of Product Tree, Work Breakdown Structure and Specification
Tree.
•
Confirmation of model philosophy and verification approach.
4.4.3.4
Phase C (Detailed Definition)
Major Tasks
The scope and type of tasks undertaken during this phase are driven by the
model philosophy selected for the project, as well as the verification approach
adopted.
•
Completion of the detailed design definition of the system at all levels in
the customer-supplier chain.
•
Production, development testing and pre-qualification of selected critical
elements and components of the system.
•
Production and development testing of engineering models, as required by
the selected model philosophy and verification approach.
•
Completion of assembly, integration and test planning for the system and
its constituent parts.
•
Detailed definition of internal and external interfaces of the system.
•
Update the risk assessment.
Associated Mandatory Review Milestone
The Critical Design Review (CDR) is held at the end of Phase C. The outcome
of this review is used to judge the readiness of the project to move into
Phase D.
Main Review Objectives
•
Assess readiness of development testing and pre-qualification testing for
entering Phase D.
•
Release the final design at all levels of customer/supplier chain.
•
Release assembly, integration and test planning.
•
Release flight hardware / software manufacturing, assembly and testing.
4.4.3.5
Phase D (Qualification and Production)
Major Tasks
•
Complete qualification testing and associated verification activities.
•
Complete manufacturing, assembly and testing of flight hardware/software
and associated ground support hardware/software.
•
Prepare Acceptance Data Package.
Associated Mandatory Review Milestones
There are 2 Mandatory Project Review Milestones associated with Phase D
•
The Qualification Review (QR) held during the course of the Phase.
•
The Acceptance Review (AR) held at the end of the phase. The outcome of
this review is used to judge the readiness of the product for delivery.
Main Review Objectives –Qualification Review
The primary objectives of this review are:
20
ECSS-M-30B Draft 14
6 July 2007
•
To verify that all qualification testing has been completed successfully and
verified against the specified verification requirements.
•
To verify that any other methods used to qualify the product have been
reviewed and accepted.
•
To verify that the verification record is complete at all levels in the
customer/supplier chain.
Main Review Objectives –Acceptance Review
The primary objectives of this review are:
•
To verify that all acceptance testing has been completed successfully.
•
To verify that all deliverable products are available per the approved
Deliverable Items List and ready for acceptance.
•
To verify the “as-built” product and its constituent components against the
required “as designed” product and its constituent components.
•
To verify the acceptability of all waivers and deviations.
•
To verify that the Acceptance Data Package is complete.
•
To authorize delivery of the product.
Phase D/Phase E Transition (System Level)
There are 4 additional Mandatory Project Reviews on system level associated
with the transition from Phase D to Phase E. The allocation of these to Phase D
or Phase E is determined by the objectives of the Acceptance Review at system
level. These Mandatory Project Reviews are:
•
Operational Readiness Review (ORR)
•
Flight Readiness Review (FRR)
•
Launch Readiness Review (LRR)
•
Flight Qualification Review (FQR)
Operational Readiness Review (ORR)
The Operational Readiness Review may be conducted prior to, or after, delivery
of the space segment to the launch site. The primary objective of this review is
to assure satisfactory inter-operability between the space segment and ground
segment, including the supporting communications infrastructure.
Flight Readiness Review (FRR)
The Flight Readiness Review is conducted prior to launch. The primary
objective of this review is to certify that the total launch configuration and all
supporting ground systems, tracking systems, communication systems and
safety systems are ready for launch.
Launch Readiness Review (LRR)
The Launch Readiness Review is conducted just prior to launch to declare
readiness for launch of all flight and ground systems.
Flight Qualification Review (FQR) / On-orbit Commissioning Review
This Review is conducted following completion of a series of on-orbit tests
designed to verify that all components of the system, including redundancy, are
21
ECSS-M-30B Draft 14
6 July 2007
performing within the specified performance parameters. Successful
completion of this review milestone is typically used to mark the formal
handover of the system to the end user (system operator).
4.4.3.6
Phase E (Operations/Utilization)
Major Tasks
The major tasks for this phase vary widely as a function of the type of project
concerned. Therefore, only a general overview of activities during this phase is
provided here.
•
Perform all on-orbit system and payload activities and functions required
to achieve the mission objectives.
•
Perform all control centre activities and functions required to support the
mission.
•
Perform all other ground support activities and functions required to
support the mission.
•
Finalize the Disposal Plan.
Associated Mandatory Review Milestone
The End of Life Review (ELR) is held at the end of the phase.
Main Review Objectives
•
To verify that the mission has completed its useful operation or service.
•
To ensure that all on-orbit systems are configured to allow safe disposal.
4.4.3.7
Phase F (Disposal)
Major Tasks
Implement the Disposal Plan
Associated Review Milestones
The Mission Close-out Review (MCR) is held at the end of this phase.
Main Review Objectives
•
To ensure that all mission disposal activities are adequately completed.
4.4.4
Review sequencing
With the exception of the MDR which normally involves only the project
initiator, and the top level customer, all other mandatory project reviews up to
and including the AR are applicable to all project actors down to the lowest
level assembly supplier in the customer/supplier chain involved in the project
phases containing these reviews.
From the PRR to the PDR, the sequence of the reviews is “top down”, starting
with the top level customer and his top level supplier (normally the prime
contractor), and continuing down the customer/supplier chain to the lowest
level assembly supplier. From the PDR to the AR, the sequence of reviews is
reversed to “bottoms up”, starting with the lowest level assembly suppliers and
their customers and continuing up through the customer/supplier chain to the
top level supplier and the top level customer. This so called “V model” is
illustrated in Figure 4.
22
ECSS-M-30B Draft 14
6 July 2007
System Operator
Project Initiator
FQR
MDR
Top Level Customer
PRR/SRR/PDR
CDR/QR/AR
1st Level Supplier
1st Level Customer
PDR
CDR/QR/AR
2nd Level Supplier
2nd Level Customer
CDR/QR/AR
PDR
nth Level Supplier
nth Level Customer
PDR
Lowest Level Supplier
Figure 4 Review life cycle
4.4.5
Project Specific Reviews
In addition to the mandatory project reviews identified above, and depending
on the type of project, the applicable Business Agreement and the overall
implementation approach adopted, additional reviews may be inserted into the
project planning against agreed sub-milestones/additional milestones to meet
particular project needs.
Typical examples of such reviews are :
•
Detailed Design Review (software specific review, addressed in E-40)
•
In Orbit Operations Review (addressed in E-70)
•
First Article Configuration Review (serial production specific review)
•
System Design Review (launcher specific review)
•
System Qualification Review at Ground Level (launcher specific review)
•
System Qualification Review at Flight Level (launcher specific review)
These reviews are not further addressed in this standard.
23
ECSS-M-30B Draft 14
6 July 2007
5
Requirements
5.1
Project Planning Requirements
5.1.1
Introduction
Project Planning requirements are applicable to all actors of a project from the
top level supplier down to the lowest level supplier. Project actors who have the
role of a customer and a supplier carry the responsibilities associated with both
roles. The scope and detail of requirements made applicable is a function of the
level of each actor in the customer/supplier chain, with the full scope of all
requirements applicable to the top level supplier. The overall scope made
applicable reduces, down through the customer/supplier chain but becomes
more specific as a function of the role played by each of these actors and the
type of product(s) to be developed and delivered by them. ECSS standards are
normally limited to addressing requirements levied by customers on suppliers.
In this standard it is necessary to identify the important responsibilities of
customers in setting up the planning of a project in order to put the
requirements on suppliers in context.
5.1.2
Customer responsibilities
Each customer in the customer/supplier chain is responsible for:
24
•
organizing the project into sequential phases which include all mandatory
and project specific review and decision milestones;
•
ensuring that his suppliers reviews are in line with the top down /
bottom up sequence of the overall project review planning;
•
preparing ITT’s, RFP’s, or RFQ’s, including the Project Requirements
Documents;
•
preparing the Business Agreement to be made applicable between them
and their supplier(s);
•
using the ECSS Standards to establish the project management,
engineering and product assurance requirements applicable for the project;
•
making applicable to their supplier(s) only those ECSS standards relevant
to the type and phase(s) of the project addressed by the Business
Agreement;
•
specifying by tailoring the minimum requirements within the applicable
standards necessary for their supplier(s) to achieve the project objectives;
•
approving his supplier(s) project management plans and key personnel;
ECSS-M-30B Draft 14
6 July 2007
•
setting up a reporting system;
•
scheduling regular meetings with his supplier(s) to review progress against
approved project planning;
•
setting up an action monitoring system;
•
identifying and specifying any additional reviews to be conducted during
the life cycle of a project over and above the mandatory reviews;
•
preparing project review plans for all project reviews;
•
taking the decision to move from one phase to the next on the basis of the
outcome of the associated “end of phase” review;
•
verifying supplier
constraints;
•
accepting the responsibilities of a supplier for any products supplied by the
customer to lower level suppliers in the customer-supplier chain.
compliance
with
all
project
requirements
and
In addition, each customer below the top level customer in the
customer/supplier chain is responsible for ensuring that planning for his
suppliers is consistent with the planning requirements imposed on him by his
customer.
5.1.3
5.2
Requirements on Suppliers
a.
Each supplier shall prepare a Project Management Plan as defined in
Annex A.
b.
Each supplier shall prepare a System Engineering Plan as defined in
ECSS-E-10C, Annex D.
c.
Each supplier shall prepare a Product Assurance Plan as defined in ECSSQ-10A, Annex TBD.
d.
Each supplier shall prepare a Design and Development Plan as defined in
Annex B
Project Organization Requirements
As an input to the Project Management Plan (Annex A), each supplier shall:
a.
set up a project management organization in compliance with the approved
management plan;
b.
identify the key personnel to be deployed on the work, and include them in
the project organization;
c.
nominate a project manager with a project team under his authority.
d.
ensure that the project manager has the authority to execute all tasks
needed under the contract with direct access to his company management
hierarchy to resolve conflicts at the appropriate level;
e.
demonstrate that the key personnel have the necessary qualification, skills
and experience to perform the task for which they are allocated;
f.
prepare and submit Progress Reports to his customer in compliance with
reporting requirements;
g.
prepare minutes of progress meetings for approval of the customer.
h.
maintain an action item reporting and tracking system;
i.
perform audits of his own and his sub-suppliers project activities to verify
conformance to project requirements:
j.
inform the customer about the audit schedule;
25
ECSS-M-30B Draft 14
6 July 2007
k.
5.3
5.4
provide right of access for participation by the customer in the supplier
audits and for the customer audits of the supplier and his project related
activities.
Project breakdown structures
a.
Each supplier shall prepare the Function Tree for his work share in the
project as defined in ECSS-E-10C, Annex H.
b.
Each supplier shall develop the Product Tree for his products down to the
deliverable end items, incorporating the Product Trees of each of his lower
tier suppliers, as defined in Annex C.
c.
Each supplier shall establish the Work Breakdown Structure (WBS) for his
work share, incorporating the WBS of each of his lower tier suppliers, as
defined in Annex D.
d.
Each supplier shall establish Work Package Descriptions (WPD) for each
Work Package shown in his WBS as defined in Annex E.
Project review requirements
5.4.1
Introduction
The requirements contained in this clause address only the documentation to
be provided by suppliers for each of the mandatory and project specific reviews
identified in Clause 4 of this standard. The Document Requirement Definitions
(DRD) specifying the content of each of the documents addressed are either
included as Annexes to this standard, or pointers are provided indicating where
the DRD can be found in other ECSS standards.
5.4.2
26
Phase review documentation
a.
Each supplier shall submit for customer review all Project Management
documentation listed in Table 1 as specified for each Mandatory Project
Review.
b.
Each supplier shall submit for customer review all Engineering
documentation identified in ECSS Standard E-10 as specified for each
Mandatory Project Review.
c.
Each supplier shall submit for customer review all Product Assurance
documentation identified in ECSS Standard Q-10 as specified for each
Mandatory Project Review.
d.
Each supplier shall submit for customer review all Management,
Engineering and Product Assurance documentation identified by the
customer and specified for each Project Specific Review.
e.
Each supplier shall maintain all project documentation for which he is
responsible up to date with respect to ongoing project activities by
incorporating all internally and externally approved changes affecting
ongoing project activity.
Project management plan
Design and development plan
Product tree
Work breakdown structure
Work package description
Cost Breakdown Structure
Schedule
Schedule Progress Report
Company Price Breakdown Forms
Geographical Distribution Report
Cost Estimating Plan
Cost estimate report
Milestone Payment Plan
Inventory Record
Cost and Manpower Report
OBCP and CBCP for Cost Reimbursement
OBCP and CBCP for Fixed Price
EAC and ETC for Cost Reimbursement
EAC for Fixed Price
Contract Change Notice
Information/documentation management
plan
Configuration management plan
Information/documentation Management
Plan
Configuration item list
Configuration item data list
As-built configuration list
S/W configuration file
Document Title
Table 1
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
0
A
B
C
D
MDR PRR SRR PDR CDR QR AR
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Phase
X
X
X
X
D/E Transition
ORR FRR LRR
FQR ELR
E
Document Requirements List – Management documents
Configurati
on Baseline
X
X
X
X
X
X
X
X
X
X
Regular or
Incident
specific
X
ECSS-M-40
ECSS-M-40
ECSS-M-40
ECSS-M-40
ECSS-M-40
ECSS-M-40
ECSS-M-40
ECSS-M-30
ECSS-M-30
ECSS-M-30
ECSS-M-30
ECSS-M-30
ECSS-M-60
ECSS-M-60
ECSS-M-60
ECSS-M-60
ECSS-M-60
ECSS-M-60
ECSS-M-60
ECSS-M-60
ECSS-M-60
ECSS-M-60
ECSS-M-60
ECSS-M-60
ECSS-M-60
ECSS-M-60
ECSS-M-60
DRD ref.
6 July 2007
27
ECSS-M-30B Draft 14
X
Part of Review Data Package
Configuration status accounting reports
Change request
Change proposal
Request for deviation
Request for waiver
Risk management policy document
Risk management plan
Risk assessment report
Document Title
X
X
X
X
X
X
X
X
X
X
X
X
X
X
0
A
B
C
D
MDR PRR SRR PDR CDR QR AR
Phase
X
X
X
D/E Transition
ORR FRR LRR
FQR ELR
E
Configurati
on Baseline
X
X
Regular or
Incident
specific
X
X
X
X
X
ECSS-M-40
ECSS-M-40
ECSS-M-40
ECSS-M-40
ECSS-M-40
ECSS-M-80
ECSS-M-80
ECSS-M-80
DRD ref.
ECSS-M-30B Draft 14
6 July 2007
28
ECSS-M-30B Draft 14
6 July 2007
Annex A (normative)
Project management plan - DRD
A.1
DRD identification
A.1.1 Requirement identification and source document
ECSS-M-30B, requirement 5.1.3.a.
A.1.2 Purpose and objective
The project management plan is prepared to state the purpose and provide a
brief introduction to the project management system. It covers all aspects of
the latter.
A.2
Expected response
A.2.1 Response identification
The requirements for document identification contained in ECSS M-13 shall be
applied to the Project Management Plan.
A.2.2 Scope and content
The Project Management Plan shall provide the information presented in the
following sections:
<1>
Introduction
The Project Management Plan shall contain a description of the purpose,
objective and the reason prompting its preparation (e.g. program or project
reference and phase).
<2>
Applicable and reference documents
The Project Management Plan shall list the applicable and reference
documents used in support of the generation of the document.
<3>
Project organization
The Project Management Plan shall describe the project organization in line
with the project organization requirements as defined in ECSS-M-30B, subclause 5.2.
<4>
Project breakdown structures
The Project Management Plan shall describe the process for developing project
breakdown structures in line with the project breakdown structure
requirements as defined in ECSS-M-30B, sub-clause 5.3.
29
ECSS-M-30B Draft 14
6 July 2007
<5>
Risk management
The Project Management Plan shall briefly describe the risk management
approach which can be described in more detail in a dedicated risk
management policy and plan.
<6>
Project phasing and planning
The Project Management Plan shall describe the project phasing and planning
approach. It can be contained in a dedicated design and development plan, in
which case this clause need only contain a brief description together with a
pointer to the design and development plan.
<7>
Configuration management
The Project Management Plan shall describe the configuration management
approach. It can be contained in a dedicated configuration management plan,
in which case this clause need only contain a brief description together with a
pointer to the configuration management plan.
<8>
Documentation and information management
The Project Management Plan shall describe the documentation and
information management approach. It can be described in a dedicated
documentation and information management plan, in which case this clause
need only contain a brief description together with a pointer to the
documentation and information management plan.
<9>
Cost and schedule management
The Project Management Plan shall describe the methodology, processes and
means to ensure timely completion of the project within the approved budget.
It shall be based on the work and organization breakdown structures and
interfaces, and shall be consistent with the project phasing and planning.
It shall address, as a minimum, milestone management, margins management,
progress reporting, resources and cost management. It shall also define the
methods to be employed to undertake recovery actions, should these become
necessary.
<10>
ILS (Integrated logistic support)
The Project Management Plan shall define material resources, spare
provisioning and essential services required to support operation, maintenance
and control of associated operational risks particularly in terms of utilization
cost and availability.
<11>
Product assurance management
The PA Management Plan shall describe the product assurance management
approach, including the proposed breakdown into PA disciplines and the
interfaces between the disciplines. It can be described in a dedicated PA
Management Plan, in which case this clause need only contain a brief
description together with a pointer to the product assurance plan.
<12>
Engineering management
The Engineering Management Plan shall describe the engineering
management approach, including the proposed breakdown into engineering
disciplines and the interfaces between these disciplines. It can be described in a
dedicated Engineering Management Plan, in which case this clause need only
contain a brief description together with a pointer to the product assurance
plan.
A.3
Special remark
None.
30
ECSS-M-30B Draft 14
6 July 2007
Annex B (normative)
Design and Development plan - DRD
B.1
DRD identification
B.1.1
Requirement identification and source document
ECSS-M-30B, requirement 5.1.3.d.
B.1.2
Purpose and objective
The objective of the Design and Development Plan is to describe the approach,
the process, the methods and the facilities to be used throughout the complete
project life cycle to maintain the control over the schedule and the technical
and programmatic constraints of the project.
B.2
Expected response
B.2.1
Response identification
The requirements for document identification contained in ECSS M-13 shall be
applied.
B.2.2
Scope and content
The Development Plan shall provide the information presented in the following
sections:
<13>
Introduction
The Development Plan shall introduce the following items:
•
the purpose and objective of the design and development plan;
•
the Project to which the design and development plan belongs to;
•
the status of the design and Development Plan, major changes and the
reason for change.
<14>
Applicable and reference documents
The Development Plan shall contain the list of applicable and reference
documents, used in support of the generation of the document.
<15>
Mission definition, mission requirements and constraints
The Design and Development Plan shall consist of the actual status of the
mission definition, mission requirements and constraints applicable to the
project and their specific impact.
31
ECSS-M-30B Draft 14
6 July 2007
<16>
Project life cycle
The Design and Development Plan shall briefly describe the project life cycle
which will be used in the elaboration of the development logic and the master
schedule.
<17>
Development logic and model philosophy
a. The Design and Development Plan shall identify the various development
activities, their interactions and the overall logic.
b.
The list of products and their life cycle shall be identified associated with
their dependencies (product flow and interfaces).
c.
The various development models shall be identified with their objectives
and their constraints.
<18>
Activities, methods and tools
d. The Design and Development Plan shall define the approach to be followed
to manage the product engineering, discipline by discipline in coherence
with the Work Breakdown Structure and the Product Tree.
e.
The integration, verification and validation process shall be established
together with the methods and tools.
<19>
Master schedule and planning
a. The Design and Development Plan shall describe the project master
schedule.
b.
B.3
This information can be contained in a dedicated document, in which case
the Design and Development Plan shall only contain a brief description
together with a pointer to the document.
Special remark
None
32
ECSS-M-30B Draft 14
6 July 2007
Annex C (normative)
Product tree - DRD
C.1
DRD identification
C.1.1 Requirement identification and source document
ECSS-M-30B, requirement 5.3.b.
C.1.2 Purpose and objective
The objective of the product tree document is to describe, in a single document,
the hierarchical partitioning of a deliverable product down to a level agreed
between the customer and supplier.
The product tree is part of the design definition file. It is the starting point for
selecting configuration items (as specified in ECSS-M-40C) and establishing
the work breakdown structure (as specified in ECSS-M-30B). It is a basic
structure to establish the specification tree (as defined in ECSS-E-10).
C.2
Expected response
C.2.1
Response identification
The requirements for document identification contained in ECSS-M-40C shall
be applied.
C.2.2 Scope and content
The product tree shall provide the information presented in the following
sections:
<1>
Introduction
The product tree shall contain a description of the purpose, objective and the
reason prompting its preparation (e.g. program or project reference and phase).
<2>
Applicable and reference documents
The product tree shall list the applicable and reference documents used in
support of the generation of the document.
<3>
a.
Tree structure
The product tree shall provide the breakdown of lower level products
constituting the deliverable product.
33
ECSS-M-30B Draft 14
6 July 2007
b.
For each item identified in the product tree, the following information shall
be provided:
— identification code;
— item name;
— item supplier;
— applicable specification.
c.
The product tree shall be presented either as a graphical diagram or an
indentured structure where the product (i.e. at the top level of the tree) is
decomposed into lower level products.
d.
A product item selected as configuration item shall be identified in the
product tree.
e.
When recurrent products from previous space projects are used, they shall
be identified in the tree structure.
C.2.3 Special remarks
None.
34
ECSS-M-30B Draft 14
6 July 2007
Annex D (normative)
Work Breakdown Structure - DRD
D.1
DRD identification
D.1.1 Requirement identification and source document
ECSS-M-30B, requirement 5.3.c.
D.1.2 Purpose and objective
The objective of the work breakdown structure (WBS) is to provide, in a single
document, a framework for project in cost and schedule management activities
(as defined in ECSS-M-60C) and for managing technical content. It assists
project's participants in:
•
conducting tender comparisons and business agreement negotiations;
•
optimizing the distribution of work amongst the different suppliers;
•
monitoring the schedule of the project.
The WBS divides the project into manageable work packages, organized by
nature of work. It identifies the total work to be performed down to a level of
detail agreed between the customer and supplier.
D.2
Expected response
D.2.1 Response identification
The requirements for document identification contained in ECSS-M-40C shall
be applied.
D.2.2 Scope and contents
The WBS shall provide the information presented in the following sections:
<1>
Introduction
The WBS shall contain a description of the purpose, objective and the
reason prompting its preparation (e.g. program or project reference and
phase).
<2>
Applicable and reference documents
The WBS shall list the applicable and reference documents used in
support of the generation of the document.
35
ECSS-M-30B Draft 14
6 July 2007
<3> Tree structure
a. The WBS shall provide a logical and exhaustive breakdown of the product
tree elements, that includes the Customer’s defined support functions (e.g.
project management, engineering, product assurance support) necessary to
produce the end item deliverables (development and flight models) and the
necessary services as appropriate for the project.
b.
Each WBS element at completion shall represent a quantifiable output.
c.
A coding scheme for WBS elements that represents the hierarchical
structure when viewed in text format shall be used.
NOTE a common coding system facilitates communications
among all project participants.
EXAMPLE
d.
The WBS shall identify all Control work-packages.
e.
The Control work-packages may be further broken down by the supplier in
several more detailed work-packages.
f.
All defined work-packages together shall cover the total work scope.
g.
The WBS shall be presented either as a graphical diagram or an
indentured structure.
D.2.3 Special remark
None.
36
to each WBS element is assigned a code used for
its identification throughout the life of the project.
It can be a simple decimal or alphanumeric coding
system that logically indicates the level of an
element and related lower-level subordinate
elements.
ECSS-M-30B Draft 14
6 July 2007
Annex E (normative)
Work Package Description - DRD
E.1
DRD identification
E.1.1
Requirement identification and source document
ECSS-M-30B, requirement 5.3.d.
E.1.2
Purpose and objective
The objective of the work package description is to describe the detailed content
of each element of the WBS as defined in ECSS-M-30B, Annex C.
E.2
Expected response
E.2.1
Response identification
The requirements for document identification contained in ECSS-M-40C shall
be applied.
E.2.2
Scope and content
The WP description shall contain the following elements:
a.
project name and project phase;
b.
WP title;
c.
unique identification of each WP and issue number
d.
supplier or entity in charge of the WP performance;
e.
WP manager’s name and organization;
f.
supplier’s country;
g.
product to which the tasks of the WP are allocated (link to the product
tree);
h.
description of the objectives of the WP;
i.
description of the tasks;
j.
list of the inputs necessary to achieve the tasks;
k.
interfaces or links with other tasks or WP’s;
l.
list of constraints, requirements, standards, and regulations;
m. list of the expected outputs;
n.
list of deliverables;
o.
location of delivery;
37
ECSS-M-30B Draft 14
6 July 2007
38
p.
start event identification including date;
q.
end event identification including date;
r.
excluded tasks.
ECSS-M-30B Draft 14
6 July 2007
Annex F (informative)
Determination of the appropriate
WBS level of detail
The main challenge associated with developing the Work Breakdown Structure
(WBS) is to determine the balancing between the project definition aspects
of the WBS and the requirements for data collecting and reporting. One has
to keep in mind that the WBS is a tool designed to assist the project manager
when decomposing the project only to the levels necessary to meet the needs of
the project, the nature of the work, and the confidence of the team.
An excessive WBS levels can lead to unrealistic levels of maintenance and
reporting, and consequently to an inefficient and over costly project. The theory
that more management data equates to better management control has been
proven false many times over in the last decades when assessing systems
performance. On the other hand, if not detailed enough it makes the element
difficult to manage or the risk unacceptable.
Among the different questions arising when developing a WBS, an important
one is: should the WBS be decomposed further?
To help answering this question, we propose the following list of questions. If
most of the questions can be answered YES, then the WBS element analyzed
should be decomposed. On the contrary, if most of the questions can be
answered NO, then this is not necessary. If the answers are approximately
50/50, then additional judgment is needed.
•
Is there a need to improve the assessment of the cost estimates or progress
measuring of the WBS element?
•
Is there more than one individual responsible for the WBS element? Often
a variety of resources are assigned to a WBS element, a unique individual
is assigned the overall responsibility for the deliverable created during the
completion of the WBS element.
•
Does the WBS element content include more than one type of work process
or produces more than one deliverable at completion?
•
Is there a need to assess the timing of work processes that are internal to
the WBS element?
•
Is there a need to assess the cost of work processes or deliverables that are
internal to the WBS element?
•
Are there interactions between deliverables within a WBS element to
another WBS element?
39
ECSS-M-30B Draft 14
6 July 2007
40
•
Are there significant time gaps in the execution of the work processes that
are internal to the WBS element?
•
Do resource requirements change over time within a WBS element?
•
Are there acceptance criteria, leading to intermediate deliverable(s),
applicable before the completion of the entire WBS element?
•
Are there identified risks that require specific attention to a subset of the
WBS element?
•
Can a subset of the work to be performed within the WBS element be
organized as a separate unit?
ECSS-M-30B Draft 14
6 July 2007
Applicability matrix
This Annex provides the applicability matrix for this standard.
It lists all the requirements specified in this Standard with their correspondent
identifier, and provides the means for the user of this Standard to make each
requirement for the project:
•
applicable as is (A),
•
applicable as modified (M), or
•
not applicable (N).
41
Each supplier shall prepare a Product Assurance Plan as defined in
ECSS-Q-10A, Annex TBD.
Each supplier shall prepare a Design and Development Plan as
defined in Annex B
As an input to the Project Management Plan (Annex A), each supplier
shall:
5.1.3 c.
5.1.3 d.
5.2
42
Each supplier shall prepare a System Engineering Plan as defined in
ECSS-E-10C, Annex D.
5.1.3 b.
j. inform the customer about the audit schedule;
i. perform audits of his own and his sub-suppliers project activities to
verify conformance to project requirements:
h. maintain an action item reporting and tracking system;
g. prepare minutes of progress meetings for approval of the customer.
f. prepare and submit Progress Reports to his customer in compliance
with reporting requirements;
e. demonstrate that the key personnel have the necessary
qualification, skills and experience to perform the task for which they
are allocated;
d. ensure that the project manager has the authority to execute all
tasks needed under the contract with direct access to his company
management hierarchy to resolve conflicts at the appropriate level;
c. nominate a project manager with a project team under his
authority.
b .identify the key personnel to be deployed on the work, and include
them in the project organization;
a. set up a project management organization in compliance with the
approved management plan;
Each supplier shall prepare a Project Management Plan as defined in
Annex A.
Requirement
5.1.3 a.
Identifier
(A/M/N)
Applicable
Modified requirement
ECSS-M-30B Draft 14
6 July 2007
Each supplier shall prepare the Function Tree for his work share in
the project as defined in ECSS-E-10C, Annex H.
Each supplier shall develop the Product Tree for his products down to
the deliverable end items, incorporating the Product Trees of each of
his lower tier suppliers, as defined in Annex C.
Each supplier shall establish the Work Breakdown Structure (WBS)
for his work share, incorporating the WBS of each of his lower tier
suppliers, as defined in Annex D.
Each supplier shall establish Work Package Descriptions (WPD) for
each Work Package shown in his WBS as defined in Annex E.
Each supplier shall submit for customer review all Project
Management documentation listed in Table 1 as specified for each
Mandatory Project Review.
Each supplier shall submit for customer review all Engineering
documentation identified in ECSS Standard E-10 as specified for each
Mandatory Project Review.
Each supplier shall submit for customer review all Product Assurance
documentation identified in ECSS Standard Q-10 as specified for each
Mandatory Project Review.
Each supplier shall submit for customer review all Management,
Engineering and Product Assurance documentation identified by the
customer and specified for each Project Specific Review.
Each supplier shall maintain all project documentation for which he
is responsible up to date with respect to ongoing project activities by
incorporating all internally and externally approved changes affecting
ongoing project activity.
5.3 b.
5.3 c.
5.3 d.
5.4.2 a.
5.4.2 b.
5.4.2 c.
5.4.2 d.
5.4.2 e
k provide right of access for participation by the customer in the
supplier audits and for the customer audits of the supplier and his
project related activities.
Requirement
5.3 a.
Identifier
(A/M/N)
Applicable
Modified requirement
43
ECSS-M-30B Draft 14
6 July 2007
ECSS-M-30B Draft 14
6 July 2007
Bibliography
44
ECSS-M-40C
Space project management – Information, documentation
and configuration management
ECSS-M-80A
Space project management – Risk management
ECSS-M-HB-30A
Space project management – Organization and conduct of
reviews