ISO 14300-1:2011

INTERNATIONAL ISO
STANDARD 14300-1
Second edition
2011-07-15
Space systems — Programme
management —
Part 1:
Structuring of a project
Systèmes spatiaux — Management de programme —
Partie 1: Structuration d'un projet

Reference number
©
ISO 2011
©  ISO 2011
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2011 – All rights reserved

Contents Page
Foreword .v
Introduction.vi
1 Scope.1
2 Normative references.1
3 Terms and definitions .2
4 Abbreviated terms .2
5 Project management specification and plan .3
5.1 General .3
5.2 Project management specification .3
5.3 Project management plan.3
6 Work breakdown structure.4
6.1 General .4
6.2 Objectives .5
6.3 Responsibility and authority for development.5
6.4 Rules for defining the WBS .5
6.5 Management rules for changes .7
7 Project organization .7
7.1 General .7
7.2 Principles.7
7.3 Organizational requirements.7
7.4 Information and communication.8
8 Project phasing and planning .10
8.1 General .10
8.2 Project phasing.10
8.3 Product stages — Associated processes and documents.16
9 Cost and schedule management .19
9.1 General .19
9.2 Cost management .20
9.3 Schedule management .21
9.4 Evaluation after completion .23
10 Configuration management.23
10.1 General .23
10.2 Configuration management planning.23
10.3 Configuration identification.24
10.4 Configuration status accounting .24
10.5 Configuration control.24
10.6 Change control .25
10.7 Configuration status controlling.25
10.8 Configuration audit .25
11 Integrated logistics support .25
11.1 Objectives .25
11.2 Scheduling aspects.26
11.3 ILS management.26
12 Documentation and information management.27
12.1 Objective.27
12.2 Application conditions.27
12.3 List of documents to be produced.28
12.4 List of applicable and reference documents .28
12.5 Master list of documents .28
12.6 Document identification.28
12.7 Drafting of documents .29
12.8 Document authorization.29
12.9 Availability of documentation.30
13 Risk management .31
13.1 General.31
13.2 Critical items control .33
14 Project closure.33
14.1 General.33
14.2 Scheduled project closure.33
14.3 Unscheduled closure of the project.33
Annex A (informative) Management framework for space systems standards.34
Bibliography .35

iv © ISO 2011 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 14300-1 was prepared by Technical Committee ISO/TC 20, Aircraft and space vehicles, Subcommittee
SC 14, Space systems and operations.
This second edition cancels and replaces the first edition (ISO 14300-1:2001), which has been technically
revised.
ISO 14300 consists of the following parts, under the general title Space systems — Programme management:
⎯ Part 1: Structuring of a project
⎯ Part 2: Product assurance
Introduction
This part of ISO 14300 provides an overview and requirements of space programme management with the
overall objective of optimizing performance, costs and schedules and of minimizing the risks.
Programme management is an integral element of any programme, but, in space, it is particularly important
due to the following:
⎯ specific environmental conditions in space;
⎯ need for a high level of performance;
⎯ limited number of models;
⎯ limited access to the product during operations;
⎯ quasi-impossibility of making repairs in the case of failure during flight;
⎯ often high complexity of the organization;
⎯ associated high costs involved.
The deployment of this standardized common set of programme management requirements should
encourage and facilitate international space co-operation.

vi © ISO 2011 – All rights reserved

INTERNATIONAL STANDARD ISO 14300-1:2011(E)

Space systems — Programme management —
Part 1:
Structuring of a project
1 Scope
This part of ISO 14300 addresses the space programme/project management requirements, applicable
through a top-down approach in a contractual relationship between customers and suppliers.
NOTE The term programme is understood to be a group of several projects. Both “programme” and “project” may be
used in the same context throughout this part of ISO 14300.
The applicable requirements for product assurance are given in ISO 14300-2. Annex A of this part of
ISO 14300 gives the general ISO standards framework for space systems programme management.
This part of ISO 14300 is intended to be used as a basis when establishing and negotiating customer project
management requirements, and guiding the supplier's responses.
It allows:
⎯ a clear definition of the roles, responsibilities and authorities of the different customers and suppliers;
⎯ coherence between their activities;
⎯ communication capability between them;
⎯ stable and rigorous project organization; and
⎯ as far as possible, standardization of the rules applicable to various programmes/projects.
It still allows for supplier flexibility in its implementation and tailoring.
2 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.
ISO 9000:2005, Quality management systems — Fundamentals and vocabulary
ISO 10007, Quality management systems — Guidelines for configuration management
ISO 10795, Space systems — Programme management — Vocabulary
ISO 11893, Space systems — Programme management — Project organization
ISO 14300-2, Space systems — Programme management — Part 2: Product assurance
ISO 16192, Space systems — Experience gained in space projects (Lessons learned) — Principles and
guidelines
ISO 17666, Space systems — Risk management
ISO 21349, Space systems — Project reviews
ISO 21351, Space systems — Functional and technical specifications
ISO 23460, Space projects — Programme management — Dependability assurance requirements
ISO 27026, Space systems — Programme management — Breakdown of project management structures
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 9000:2005, ISO 10795 and the
following apply.
3.1
project
set of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective
conforming to specific requirements, including the constraints of time, cost and resources
NOTE Adapted from ISO 9000:2005.
3.2
programme
group of projects managed in a coordinated way to obtain benefits not available from managing them
individually
4 Abbreviated terms
The following abbreviated terms are used in this document.
CCB configuration control board
CDR critical design review
CI configuration item
CM configuration management
DF design data file
EIDP end item data package
FS functional specification
ILS integrated logistic support
IPR intellectual property rights
LB log book
LSA logistic support analysis
PDR preliminary design review
PSR pre-shipment review
QR qualification review
2 © ISO 2011 – All rights reserved

TS technical specification
WBS work breakdown structure
WPD work package description
RAMS reliability, availability, maintainability and safety
5 Project management specification and plan
5.1 General
The attainment of quality, including requirements to meet cost, schedule and technical performance
throughout project execution is the overall goal of management.
Any company involved in a space project shall take into account the requirements stated in a quality
management system standard, e.g. ISO 9001:2008.
When a level 0 customer (the first level in the contractual line issuing a contract) intends to make this part of
ISO 14300 a condition of a contract, this customer shall include in the solicitation (request for proposal,
invitation to tender, request for quotation, etc.) a dedicated project management specification for its
application by lower level customers and suppliers.
The application of the management requirements from the level 0 customer to the lowest level of suppliers in
the contract chain shall be consistent with the criticality, complexity and cost of the product to be supplied.
Thus, suppliers of less critical products may seek to have fewer requirements. Nonetheless, the continuity and
the coherence of the project requirements shall be maintained. Selection and tailoring of this part of
ISO 14300 is needed at the customer level. Any adaptation of this part of ISO 14300 shall be based on
specific objectives and constraints.
At a given level, the supplier shall adapt the management requirements contracted with his own customer to
his own suppliers. The customer can consequently fulfill his own obligations towards the next higher level (see
Figure 1).
The suppliers shall prepare a management plan in order to comply with the dedicated project management
specification, received from their customer.
5.2 Project management specification
Depending on the nature of the project or the project phase, the project management specification shall be
issued by the level 0 customer and may include additional requirements or, on the contrary, certain elements
which may be deleted with regard to this part of ISO 14300.
The level 0 customer shall require this part of ISO 14300, as tailored, and the appropriate selected clauses of
ISO 14300-2, to be used by suppliers as the basis for developing their management plans.
Each supplier of a given level acts as a customer towards his own suppliers and shall specify the
management requirements in the relevant contracts through a specific document or through the statement of
work itself.
5.3 Project management plan
In response to this project management specification, each supplier concerned prepares a project
management plan which contains descriptions of main activities, implementation methods and general
procedures with respect to its organization.
Existing supplier policies, procedures and other management controls should be used, where appropriate, and
in this case should be made available to their direct customer.
The supplier is encouraged to tailor any specified requirement that may provide more effective scheduling or
reduce costs without loss in compliance to the intent of the requirement. Such tailored requirements should be
individually identified within the supplier's project management plan to facilitate review by the customer.
The project management plan shall be submitted to the customer for acceptance. The plan, as accepted by
the customer, becomes the basis for determining compliance with the customer project management
requirements.
Figure 1 — Establishing project management rules
6 Work breakdown structure
6.1 General
The project work breakdown structure (WBS) is the reference system for project management data which:
⎯ ensures the coherence between technical, documentary, administrative and financial activities of the
whole project; and
⎯ identifies the responsibilities and authorities of each supplier.
The rules to be observed when producing, modifying and using the project WBS are specified hereafter and
detailed in ISO 27026.
4 © ISO 2011 – All rights reserved

6.2 Objectives
The project WBS is the structured and comprehensive breakdown of the whole project. On the basis of the
1)
product tree (see 6.4.3) or the function tree (see 6.4.2), it identifies the tasks and principal resources
required to complete products intended to satisfy the expressed requirements.
This breakdown is achieved in a consistent way at different levels of responsibility and authority.
The project WBS is used as a common reference for the level 0 customer and the suppliers so as to identify
all tasks required to entirely complete the project, regardless of whether these tasks are:
⎯ on the project budget or not;
⎯ under the responsibility and authority of the suppliers or other organizations.
The project WBS ensures management, planning, performance and control of all tasks implied by the project.
6.3 Responsibility and authority for development
Each supplier shall:
⎯ develop the product tree for his own supplies and limit it to interfaces with his own customer and
suppliers; and
⎯ express his requirements concerning the establishment of the WBS to his suppliers.
These requirements are in particular associated with the project organization (see Clause 7) and the
configuration items (CIs) (see Clause 10).
6.4 Rules for defining the WBS
6.4.1 Main aspects
The coding of tasks, resources and products (and possibly, functions) shall be unique and constant in time.
The tasks to be performed shall be linked to each level of the product tree (see 6.4.3).
As long as the system's product tree has not been defined, it is possible to associate tasks with functions of
the function tree (see 6.4.2).
The principal resources to be used to accomplish each task shall be clearly identified.
When the resources involved in the project have to be developed (specific resources), they shall be
considered in the same way as the products to be provided.
6.4.2 Function tree
The function tree gives the framework of system performance by breaking it down into functions. Each
function can be decomposed into sub-functions, independent of the products involved.
It is possible to link tasks to functions at the early stages of the project, i.e. at least up to the system definition
phase (phases 0, A and B; see 8.2).
At the system level, the function tree assures coherence of the whole system and the configuration control.

1) Principal resources include the development of all hardware and software (e.g. test benches, tools) necessary for the
project and also the resources required for the adaptation or the reuse of existing means, i.e. all those whose unavailability
may be a constraint for the project.
6.4.3 Product tree
The product tree gives the top-down framework of the product by breaking down the system into elements, i.e.
from the system, to subsystem, to equipment, to component level, where appropriate.
All product tree elements are under configuration control. The identifiers shall be consistent with all related
work packages and documentation.
The product approach is based on a priori knowledge or knowledge gained since the project started
concerning the products to be provided.
The product tree has to be established at the end of phase B (see 8.2.4) at the latest.
Products indicated in the product tree shall include, as a minimum, each product having a technical
specification (TS).
6.4.4 Tasks
2)
The tasks can be described in work package description (WPD) .
Each task is mainly characterized by:
a) the customer/supplier relationship;
b) a unique and identified person or organization in charge;
c) its content, including:
⎯ a title
⎯ an objective (e.g. qualification test)
⎯ a description with excluded tasks, if necessary
⎯ a task type (design, production, product assurance, management, tests, etc.);
d) its link to an element (product or function);
e) its planning constraints, including:
⎯ a planned duration
⎯ one (or several) input event(s) and data
⎯ one (or several) output event(s) and data
⎯ possibly, intermediate events (key events for the task);
f) its conditions of performance; and
g) the resources required for its performance.
The resources used shall be associated with the task which implement them.

2) A WPD is the information associated with tasks and work packages.
6 © ISO 2011 – All rights reserved

6.5 Management rules for changes
Changes in the WBS shall not modify its organization, so as not to disrupt project management.
Each added product, function, resource or task shall be given a new identification (reuse of identifiers having
already been used at any other stage shall not be allowed).
The changes take into account the modifications of mandatory services and/or requirements which shall be
accomplished in compliance with the contractual specifications (modification of clauses, riders, etc.).
7 Project organization
7.1 General
The implementation of a project organization is required to ensure consistent project performance and to
control project execution.
This clause defines the organizational principles (organization at customer and industrial levels for project
management) and specifies the organizational requirements concerning information circuits, internal and
external to the project and its environment. More requirements are defined in ISO 11893.
On the basis of contractual data, this clause is used by the different project suppliers as a definition model and
for implementation of the respective organization at each level.
7.2 Principles
The organization to be implemented shall take into account the project phases concerned, the nature of the
tasks to be performed and the associated responsibility and authority levels.
The preparation, definition and implementation of the project organization shall be planned in compliance with
project phasing (see 8.2).
The choice of the simplest and most effective management project as well as contractual relationships shall
be made taking into account the specific project aspects, whether it be a national or an international one.
The person in charge of the definition and implementation of the project organization shall be identified.
The responsibilities and authorities for project management and contracting shall be identified so as to
anticipate contractual and legal incidences.
Each project organization shall be coherent in contractual and technical terms.
If the project is associated with other programmes/projects, responsibilities and authorities regarding interface
definition and management shall be specified and taken into account when implementing the project
organization.
7.3 Organizational requirements
7.3.1 General
The project phases requiring an effective implementation of project organization (feasibility, definition,
development, production, and utilization) shall be specified. The project change may lead to modifications of
the implemented organization during project execution.
When several suppliers jointly play a common role, the responsibilities and authorities of each of them shall be
defined. When a supplier simultaneously plays several roles in the same project, they shall be clearly defined
and carried out separately. For effectiveness, however, one single authority may supervise them.
Each supplier shall identify and assign the main responsibilities and authorities for the project and implement
the internal organization in order to satisfy the contractual requirements.
Each customer and supplier are bound to play the roles both has been assigned for the duration of the project.
When several external organizations and/or internal departments are involved, the responsibilities and
authorities of each of them and their interfaces shall be clearly documented and the appropriate measures
shall be taken to ensure their co-ordination. These measures shall in particular define the nature of the
information to be exchanged between customers and suppliers.
7.3.2 Requirements
The roles of the project suppliers shall be explicitly defined and, in particular, the project organization shall
indicate who is in charge of each activity, required by the specific project management specification, i.e.:
⎯ project management;
⎯ contract management;
⎯ cost and schedule control;
⎯ engineering;
⎯ procurement;
⎯ ILS;
⎯ product assurance; and
⎯ configuration and documentation management.
The interfaces and relationships with company management should be indicated. The application of the
management rules and their effectiveness for the performed or subcontracted project activities shall be
verified according to planned and documented audits, analysis of indicators and/or reviews, as contractually
defined.
7.4 Information and communication
7.4.1 Information circuits
Rules governing the organization of information circuits shall:
⎯ define the list and role of the project customers and suppliers; and
⎯ specify the information to be exchanged between customers and suppliers and the schedule of
exchanges.
The mode of establishment, of change and application shall be stated.
8 © ISO 2011 – All rights reserved

7.4.2 Communication requirements
The requirements for the communication of information shall include:
⎯ the information to be exchanged between the actors;
⎯ the format and tools for communication;
⎯ the time-scales of the communications; and
⎯ prerogatives of the customer including delegation of it to the appropriate organization.
The pre-contractual and contractual relationships should lead to the negotiation of provisions concerning the
visibility given to the customer.
7.4.3 Protection of information
The rules concerning patent rights, intellectual property rights (IPR), levels of confidentiality, external
communication and the exploitation of results should be specified by the contract.
7.4.4 Progress reports
For the supplier(s) and customer, the purpose of these reports consists in evaluating the work progress
regarding technical, performance, commercial, schedule aspects.
The content and periodicity of these reports shall be contractually defined.
These progress reports and meetings shall permit the communication, at all necessary levels, of information
related to progress of the project, in order to take suitable decisions and to follow the implementation of
decided actions.
The agenda of progress meetings shall be fixed and accepted by all the parties. Each meeting shall produce a
report which specifies the decided actions.
7.4.5 Customer's prerogatives
When this part of ISO 14300 is made part of an agreement between a customer and a supplier, the
agreement should establish the appropriate degree to which the customer will:
⎯ monitor the application of the management requirements by the supplier;
⎯ conduct or participate in audits or reviews of the supplier; and
⎯ be informed of the progress made by the supplier in design, manufacturing, inspection, and testing.
The prerogatives needed by the customer in order to accomplish these tasks should be established by
provisions of the agreement. These provisions should cover:
⎯ customer visits to the premises of the direct supplier;
⎯ provisions that should be included in the direct supplier's agreements with lower level suppliers regarding
visits of higher level customers;
⎯ the designation of permanent or non-permanent representatives, resident at the supplier's premises; and
⎯ the delegation of all or parts of these prerogatives to national surveillance organizations, or to other
specified organizations.
7.4.6 Action items management
Throughout the project activities, the actions resulting from relations with the customer (e.g. meetings,
exchange of mail, key events, reviews) and/or those determined by the supplier as part of the application of
the management rules shall be controlled. Each action is defined by a form of identification, a clear and
unambiguous wording, an applicant, a person responsible for its completion and the corresponding deadlines
(fixed date or project event).
The final status shall be formally expressed and accepted by the applicant on presentation of the applicable
justifications.
7.4.7 Technical and management indicators
From the start of the project onwards, technical and management indicators, in particular highlighting
developments in product quality and the organizational functioning, shall be formally defined, implemented,
put to use and updated throughout the project activities. In case of significant unfavourable developments,
measures shall be taken according to the analysis of results.
These indicators are defined between the customer and the supplier and shall remain confidential.
8 Project phasing and planning
8.1 General
The objective of project phasing and planning is to minimize the technical, scheduling and economical risk of
3)
the project by introducing phases of which the ends are marked by formal milestones . By implementing this
objective, the progress of the project can be controlled with respect to cost, schedule and technical objectives.
This objective is achieved by breaking the product life cycle into distinct phases which are interlinked. The
objectives and work content of each phase shall be clearly defined.
At the end of each phase, a formal review process should be conducted to interrelate with technical baselines
subject to configuration management (CM). The results of this process are formalized by appropriate
documentation. ISO 21349 defines the complete requirements related to the review process
The number of phases and their objectives should be defined at the start of the project. They should also be
tailored to minimize risks from cost, scheduling and technical problems that can compromise the success of
the project.
The composition and content of the phases shall be determined by the level 0 customer using the project
management specification based on this part of ISO 14300 and shall be appended to the contract.
8.2 Project phasing
8.2.1 Principles
The phasing may be broken down into seven phases. The start of a phase coincides with crossing a milestone,
at which time a decision is taken by the level 0 customer (or his highest authority) at a given system level. This
usually occurs after a specific review assessing the work results of the current phase, the provisions for the
next phase and the identified risks.
The crossing of milestones at lower levels shall be decided by the relevant customers, after the relevant
reviews.
3) A milestone is a significant event marking the end of a phase of development in the project.
10 © ISO 2011 – All rights reserved

The purpose of a review is to perform a critical evaluation by a team, including the customer and others not
directly involved in the activities and with the aim of helping to:
⎯ assess the validity of the technical elements in relation to the predictions and the contractual
requirements;
⎯ enable corrective and/or preventive actions to be carried out in the case of drift or inadequacy;
⎯ mark the transition to the following stage; and
⎯ decide to cross the concerned milestone.
8.2.2 Mission analysis phase (phase 0 or pre-phase A)
This phase consists of an initial definition of the mission and of a preliminary assessment of the concepts
needed for consideration in the feasibility phase.
This phase results in:
⎯ the identification and the characterization of the mission;
⎯ an initial evaluation of needed performance, risks, requirements, and objectives, e.g. dependability and
safety;
⎯ an initial assessment of the manufacturing and operational constraints, including environmental
conditions;
⎯ the identification of possible solutions with the associated critical issues, taking into account the lessons
learned from current space programmes/projects; and
⎯ an initial evaluation of the elements of the project (organization, costs, schedules).
The results of these activities, especially mission definition and/or provisional functional specifications, should
be reviewed and summarized in a transition phase 0 to phase A document which serves as the basis of the
decision to initiate the feasibility phase.
8.2.3 Feasibility phase (phase A)
8.2.3.1 Objectives
This phase of the project consists of exploring the various possible concepts so as to meet the defined
objectives (performance, costs and schedules).
This phase results in:
a) the function tree being issued;
b) the user's objectives being formally defined in:
⎯ a reference functional specification (FS);
⎯ a preliminary issue of the TS at the system level;
c) the presentation of each concept examined in a pre-design associated with a financial proposal (costs
and schedules) for the definition phase; and
d) the estimation of technical and manufacturing feasibility and the emphasis on the critical elements of each
concept (performance, risks, costs, schedules, technical and support costs).
The result of these activities, especially preliminary system requirements and system definition, should be
reviewed and summarized in a transition phase A to phase B document (see 8.2.3.2).
8.2.3.2 Documentation
This phase results in the drafting of a “transition phase A to phase B document” under the responsibility and
authority of the level 1 customer.
These documents shall emphasize in particular:
⎯ the feasibility of proposals to meet the anticipated requirements;
⎯ the general description of these proposals, indicating the main elements for each one (performance, costs,
schedules, risks) and the one recommended; and
⎯ the organization of subsequent phases (structures, resources, etc.) and in particular those elements
allowing the start of the definition phase (WBS, costs, schedules, etc.).
8.2.4 Definition phase (phase B)
8.2.4.1 Objectives
This phase consists of selecting one proposal for development among those proposed at the end of the
feasibility phase and in specifying the necessary requirements.
This phase starts by crossing the milestone corresponding to the acceptance of phase A results.
This phase results in:
⎯ the comparison of performance and risks (regarding technical/cost/schedule aspects) of the technical
solutions previously selected to be studied;
⎯ the establishment of the TS at the system level;
⎯ the establishment of the TS at the next, more detailed, level and whenever possible in compliance with
the function tree as inputs to all specifications;
⎯ the evaluation of the dependability and the safety characteristics;
⎯ the choice of the proposal for development, in particular taking into account the financial aspects of the
proposal; and
⎯ the issue of the transition phase B to phase C document.
The result of these activities, especially system TS, the frame of the system, the associated lower TSs and the
development plan (see 8.2.4.2.3) should be reviewed [preliminary design review (PDR)] and summarized in a
transition phase B to phase C document (see 8.2.4.2).
Requirements for TSs are defined in ISO 21351.
12 © ISO 2011 – All rights reserved

8.2.4.2 Documentation
8.2.4.2.1 General
The following documents, written under the responsibility and authority of the level 1 customer, shall be
compiled with the TS and the documents drafted by the supplier:
⎯ the management plan and the development plan;
⎯ the WBS (see Clause 6);
⎯ the first level TS and, whenever possible, the associated technical clauses; and
⎯ the preliminary design data file (DF) and the justification for it.
8.2.4.2.2 Transition phase B to phase C documents
These documents in particular emphasize:
a) the necessary requirements listed in the TS. This TS shall be compared with anticipated requirements.
The purpose of this comparison is to verify that there is no incoherence between anticipated requirements,
defined by the user in the reference FS, and the technical and contractual requirements expressed in
the TS;
b) the proposed design of the solution, which has been sufficiently examined in compliance with the
requirements. This design is, in general, described in a preliminary DF and defines the architecture of the
main components. This design shall facilitate the identification of the various critical points in the product
development and manufacturing;
c) the organization of the development phase with:
⎯ the organization of the project,
⎯ the schedule for completion, including key events,
⎯ the methods allowing the various identified risks to be kept under control; and
d) the justification of the estimated cost of the development phase.
8.2.4.2.3 Development plan
4)
At the end of phase B , the development plan shall be drafted by the level 1 customer, taking into account the
requirements of his customer and with the elements of his own suppliers. This development plan shall
describe the phasing rationale used to carry out the development of the products satisfactorily under his
responsibility and authority, and in particular:
⎯ the task sequence of the project;
⎯ the mandatory steps (key events);
⎯ the significant stages in development progress and of the design verification (document issue,
manufacturing of models, tests, reviews, etc.).

4) Phase A and B activities are iterative and tend to clarify progressively requirements, thus making possible solutions
more evident.
When approved by the level 0 customer, it becomes the document for management and follow-up of the
5)
work .
8.2.5 Development (phase C) and production (phase D) phases
8.2.5.1 Merger of phases C and D
Phases C and D may be merged into one unique C/D phase if the project leads to the manufacturing of a
single-flight unit or of a very small quantity of product.
The choice shall be determined by the level 0 customer.
8.2.5.2 Integrated C/D phase
This project phase consists of making a detailed study of the solution selected upon completion of the
definition phase and subsequently manufacturing qualification model(s) and flight model(s). The purpose of
this phase is to obtain a qualified design of the deliverable products required for system operation and support.
This integrated phase starts by crossing the PDR milestone and corresponds to the acceptance of transition
phase B to phase C documents issued during the previous phase.
This phase shall include, as a minimum, the tasks necessary to complete the designed state of the system
and of each of its components [critical design reviews (CDR)].
On the basis of the verifications made during this phase and during qualification tests, the qualificatio
...