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 and products that toge
Terms defined in other standards
For the purpose of this Standard, the terms and definitions from ECSS-S-ST-00-01 apply.
Terms specific to the present standard
3.2.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, system engineering, mechanical engineering, software and communications are disciplines within the Engineering domain)
3.2.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)
3.2.3 function combination and interaction of a number of operations or processes, which together achieve a defined objective
Abbreviated terms
For the purposes of this Standard, the abbreviated terms from ECSS-S-ST-00-01 and the following apply
CBCP current baseline cost plan
EGSE electrical ground support equipment
ELR end-of-life review
MCR mission close-out review
MGSE mechanical ground support equipment
OBCP original baseline cost plan
Project planning
Introduction
Project planning and implementation involves the comprehensive processes required to effectively plan and execute a space project from start to finish This activity spans all levels of the customer-supplier chain and requires coordinated, efficient, and structured efforts It integrates inputs from various project disciplines and necessitates close collaboration across different project domains.
A space project consists of a space segment and a ground segment that are developed simultaneously, as outlined in ECSS-E-ST-70 These segments depend on and interact with the launch service segment, collectively forming a comprehensive space system.
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
The ECSS standard defines the top-level customer as the organization responsible for creating business agreements for the top-level space segment and ground segment, as well as managing interface arrangements with other external space system elements.
The following clauses 4.1.2 to 4.1.11 describe the key elements to be addressed, assessed, and balanced when planning a project.
Purpose and objectives of the project
The project initiator outlines the purpose and objectives in the mission statement, which encompasses key performance parameters and technical constraints These elements are typically aligned with the top-level customer, if one is designated.
Availability of and need to develop new technologies
The joint assessment by the customer and supplier aims to identify the necessary scientific and technological expertise required for project implementation This evaluation, which significantly influences costs and timelines, serves as a crucial input for determining the needed resources and facilities, as well as for conducting a thorough technical and programmatic risk assessment.
Availability of and need to reuse existing equipments/products
This assessment evaluates the feasibility of reusing existing products in response to customer needs The findings significantly impact cost and schedule considerations, serving as a crucial input for determining necessary resources and facilities, as well as for conducting technical and programmatic risk assessments.
Availability of and need for human resources, skills and technical
resources, skills and technical facilities
The assessment, conducted collaboratively by the customer and supplier, evaluates the necessary resources, skills, and facilities for project implementation The findings determine whether the existing resources and skills are sufficient or if additional elements are required to successfully complete the project.
Risk assessment
The customer conducts initial assessments of a project's technical and programmatic risks, utilizing inputs from the project initiator regarding its purpose, objectives, and identified constraints As the project progresses, these assessments are regularly updated to incorporate additional relevant parameters Comprehensive risk evaluations are performed during each major project review.
Development approach
The project development approach is collaboratively established by both the customer and supplier to align with the project initiator's mission statement, requirements, and constraints, while also considering the outcomes discussed in sections 4.1.3 to 4.1.6.
Project deliverables
The customer has the responsibility for defining the deliverable products, needed to meet the project initiator’s mission statement, taking into account the assessments noted in clauses 4.1.4 to 4.1.7 above.
Customer requirements and constraints
Customer requirements and constraints are formulated based on the outputs from sections 4.1.2 to 4.1.8 and organized into a format suitable for inclusion in an invitation to tender (ITT) These requirements encompass technical and programmatic aspects, along with political, commercial, and industrial constraints relevant to the project, collectively forming the project requirements documents (PRD).
Project requirements documents (PRD)
The project requirements documents are an integral part of an ITT, request for proposal (RFP), or request for quote (RFQ) prepared and released by a customer to potential suppliers
• Technical requirements documented in Technical Requirements Specification, as defined in ECSS-E-ST-10-06
• Other, project specific requirements (e.g geographical distribution, model philosophy to be applied)
The ECSS system incorporates management, engineering, and product assurance requirements through its M, E, and Q standards These standards are customized by each customer within the customer-supplier chain to align with the project's type and phase, as well as the specific tasks outlined for suppliers in the Product Requirements Document (PRD).
Project management plan
The project management plan serves as the top-level project plan, outlining the management approach and methodology for the project's entire life cycle It provides a comprehensive overview of all project management disciplines and includes the definition of the system engineering and product assurance management strategies Additionally, it may reference separate plans for system engineering and product assurance, collectively forming the complete planning documentation necessary for project implementation.
Project organization
Introduction
A well-structured organizational framework is essential for effective project management across the customer-supplier chain Each level can establish a self-sufficient project team that encompasses all necessary disciplines, or more commonly, a core project team that integrates key functions while sourcing additional support externally.
Irrespective of the organizational approach followed for a project, the elements summarized below are relevant at all levels in the customer-supplier chain.
Organizational structure
An effective project organizational structure must encompass all necessary disciplines for successful implementation, featuring clearly defined functions, reporting lines, inter-relationships, and interfaces All project participants, positioned between the top-level customer and the lowest-level suppliers, fulfill dual roles as both suppliers and customers, with their organizational frameworks designed to support these roles.
The organizational structure clearly defines and allocates individual roles and responsibilities, ensuring that each member has the necessary authority to execute their tasks effectively within the internal project setup and in relation to external project interfaces.
Communication and reporting
Effective communication is crucial for clear interaction among all project participants and between the project team and external stakeholders Information technology plays a key role in facilitating this exchange Initially, communication clarifies the project's goals and objectives, and it continues to support the daily operations of the project team Additionally, regular reporting is vital for sharing updates on the project's progress.
Audits
Audits are independent examinations to determine whether processes and procedures achieve the specified objective They are an essential tool to identify problem areas.
Project breakdown structures
Introduction
Project breakdown structures provide the basis for creating a common understanding between all actors They break the project down into manageable elements as described in the following clauses 4.3.2 to 4.3.7.
Function tree
The function tree is a systematic breakdown of system performance into distinct functions, with each function further decomposed into independent sub-functions, regardless of the product type This approach is utilized during the project start-up or system definition phase, and additional information can be found in ECSS-E-ST-10, function tree DRD.
Specification tree
The specification tree outlines the hierarchical relationships among all technical requirements for various elements of a system or product For further information on the specification tree, refer to ECSS-E-ST-10 and the specification tree DRD.
Product tree
The product tree is a hierarchical breakdown of a project into hardware and software components designed to fulfill the functions outlined in the function tree While the product and function trees may not directly correspond, the product tree encompasses development models, GSE, integration tools, test equipment, and external elements essential for validating the final product and ILS items It also includes items under customer configuration control and those specified in technical requirements Ultimately, the product tree serves as the foundation for creating the project's work breakdown structure.
An example of a product tree is shown in Figure 4-1
Work breakdown structure (WBS)
The Work Breakdown Structure (WBS) is essential for effective project management, serving as a framework to oversee costs, schedules, and technical aspects It systematically divides the project into manageable work packages, organizing tasks based on their nature and progressively detailing the total work required.
The WBS is derived from the product tree, selected elements of which are extended to include support functions (i.e management, engineering, product assurance) and associated services (e.g test facilities)
An example of a WBS is shown in Figure 4-2
Product Assurance tasks Support function extensions
Work package (WP)
A WP can be any element of the WBS down to the lowest level that can be measured and managed for planning, monitoring, and control
Control work packages are designated by the supplier at the appropriate level in the Work Breakdown Structure (WBS) where oversight and management are necessary, and reporting will take place These packages encompass the complete scope of work and are mutually agreed upon by the customer.
The work of each supplier is explicitly identified in the work breakdown structure by at least one control work package.
Organization breakdown structure (OBS)
The Organizational Breakdown Structure (OBS) outlines the proposed project organization, highlighting the interface and contractual responsibilities, in contrast to the company’s organizational breakdown structure, which focuses on functional aspects The project OBS identifies key personnel and assigns responsible parties for each work package within the Work Breakdown Structure (WBS).
Project phasing
Introduction
The life cycle of space projects is typically divided into 7 phases, as follows:
• Phase 0 - Mission analysis/needs identification
A typical project life cycle is illustrated in Figure 4-3
Project phases are interconnected with activities at both the system and product levels Depending on the unique circumstances of each project and the acceptance of associated risks, activities may overlap across different project phases.
At the conclusion of the major activities and the related project reviews configuration baselines are established (see ECSS-M-ST-40)
Phase 0 Phase A Phase B Phase C Phase D Phase E Phase F
Figure 4-3: Typical project life cycle
Phases 0, A, and B are focused mainly on
The development of functional and technical requirements for the system involves identifying key concepts that align with the mission statement, while also considering the technical and programmatic constraints set forth by the project initiator and the top-level customer.
• the identification of all activities and resources to be used to develop the space and ground segments of the project,
• the initial assessments of technical and programmatic risk,
• initiation of pre-development activities
Phases C and D comprise all activities to be performed in order to develop and qualify the space and ground segments and their products
Phase E includes all necessary activities for launching, commissioning, and maintaining the orbital elements of the space segment, as well as the utilization and upkeep of the related ground segment.
Phase F comprises all activities to be performed in order to safely dispose all products launched into space as well as ground segment
Each project phase concludes with a review milestone, which assesses the project's readiness to progress to the subsequent phase.
Requirements on organization and conduct of reviews are provided in ECSS-M-ST-10-01
All project reviews, except for the MDR which usually involves only the project initiator and the top-level customer, are conducted by all project participants, including the lowest level suppliers in the customer-supplier chain, during the relevant project phases.
The review process transitions from a "top down" approach in the PRR to PDR, beginning with the highest level customer and supplier and moving down the supply chain Conversely, the CDR to AR reviews adopt a "bottom up" sequence, starting with the lowest level supplier and its customer, and progressing upward through the supply chain to the top level customer.
“V model” is illustrated in Figure 4-4
1st Level Customer nth Level Customer
Lowest Level Supplier nth Level Supplier 2nd Level Supplier 1st Level Supplier
CDR/QR/AR CDR/QR/AR CDR/QR/AR CRR
Relationship between business agreements and project phases
A business agreement may encompass a single project phase or a series of sequential phases, influenced by factors such as funding availability, competitive tendering, schedule, and perceived risk Regardless of how individual agreements are defined, all space projects typically adhere to classical project phases, incorporating major objectives and key milestones throughout each phase.
Project phases
The clause 4.4.3 provides an introduction and overview of the typical major tasks, associated review milestones, and review objectives for each of the phases in a project life cycle
4.4.3.2 Phase 0 (Mission analysis/needs identification)
4.4.3.2.1 Overview This is mainly an activity conducted by the project initiator, the top level customer and representatives of the end users
The mission statement should clearly define and characterize the mission needs, outlining the expected performance, dependability, and safety goals It is essential to consider the mission operating constraints in relation to both the physical and operational environment to ensure comprehensive understanding and effective execution.
• Develop the preliminary technical requirements specification
• Perform preliminary assessment of programmatic aspects supported by market and economic studies as appropriate
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
The primary objective of this review is to release the mission statement and assess the preliminary technical requirements specification and programmatic aspects
This activity involves collaboration between top-level customers and one or more first-level suppliers, with the results being communicated to the project initiator and end-user representatives for their review and consideration.
• Establish the preliminary management plan, system engineering plan and product assurance plan for the project
• Elaborate possible system and operations concepts and system architectures 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
• Identify critical technologies and propose pre-development activities
• Quantify and characterize critical elements for technical and economic feasibility
• Propose the system and operations concept(s) and technical solutions, including model philosophy and verification approach, to be further elaborated during Phase B
The Preliminary Requirements Review (PRR) takes place at the conclusion of Phase A, and its results are crucial for assessing the project's preparedness to advance into Phase B.
4.4.3.3.4 Main review objective(s) The primary objectives of this review are:
• Release of preliminary management, engineering and product assurance plans
• Release of the technical requirements specification
• Confirmation of the technical and programmatic feasibility of the system concept(s)
• Selection of system and operations concept(s) and technical solutions, including model philosophy and verification approach, to be carried forward into Phase B
• Finalize the project management, engineering and product assurance plans
• Establish the baseline master schedule
• Elaborate the baseline cost at completion
• Elaborate the preliminary organizational breakdown structure (OBS)
• Confirm technical solution(s) for the system and operations 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)
• Determine the verification program including model philosophy
• Identify and define external interfaces
• Prepare the next level specification and related business agreement documents
• Initiate pre-development work on critical technologies or system design areas when it is necessary to reduce the development risks
• Initiate any long-lead item procurement required to meet project schedule needs
• Prepare the space debris mitigation plan and the disposal plan
• Conduct reliability and safety assessment
• Finalize the product tree, the work breakdown structure and the specification tree
There are 2 project reviews 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
4.4.3.4.3 Main review objectives - System requirements review
The primary objectives of this review are:
• Release of updated technical requirements specifications
• Assessment of the preliminary design definition
• Assessment of the preliminary verification program
4.4.3.4.4 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 final management, engineering and product assurance plans
• Release of product tree, work breakdown structure and specification tree
• Release of the verification plan (including model philosophy)
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
• 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
• Issue of preliminary user manual
• Update of the risk assessment
The critical design review (CDR) takes place at the conclusion of phase C, serving as a key evaluation point The results of this review determine whether the project is prepared to advance into phase D.
• Assess the qualification and validation status of the critical processes and their readiness for deployment for phase D
• Confirm compatibility with external interfaces
• Release assembly, integration and test planning
• Release flight hardware/software manufacturing, assembly and testing
• Complete qualification testing and associated verification activities
• Complete manufacturing, assembly and testing of flight hardware/software and associated ground support hardware/software
• Complete the interoperability testing between the space and ground segment
4.4.3.6.2 Associated reviews There are 3 project reviews 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
• The operational readiness review (ORR), held at the end of the phase
4.4.3.6.3 Main review objectives – Qualification review The primary objectives of this review are:
• To confirm that the verification process has demonstrated that the design, including margins, meets the applicable requirements
• To verify that the verification record is complete at this and all lower levels in the customer-supplier chain
• To verify the acceptability of all waivers and deviations
Where development encompasses the production of one or several recurring products, the QR is completed by a functional configuration verification during which:
• The first article configuration is analyzed from the viewpoint of reproducibility
• The production master files for the series productions are released
• The series production go–ahead file is accepted by the customer
4.4.3.6.4 Main review objectives – Acceptance review
The primary objectives of this review are:
• To confirm that the verification process has demonstrated that the product is free of workmanship errors and is ready for subsequent operational use
• To verify that the acceptance verification record is complete at this and all lower levels in the customer-supplier chain
• To verify that all deliverable products are available per the approved deliverable items list
• 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
• To release the certificate of acceptance
4.4.3.6.5 Main review objectives - Operational readiness review
The primary objectives of this review are:
• To verify readiness of the operational procedures and their compatibility with the flight system
• To verify readiness of the operations teams
• To accept and release the ground segment for operations
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 activities at space and ground segment level in order to prepare the launch
• Conduct all launch and early orbital operations
• Perform on-orbit verification (including commissioning) activities
• Perform all on-orbit operations in order to achieve the mission objectives
• Perform all ground segment activities in order to support the mission
• Perform all other ground support activities in order to support the mission
4.4.3.7.2 Associated reviews There are 4 project reviews associated with phase E
• The flight readiness review (FRR) is held prior to launch
• The launch readiness review (LRR), held immediately prior to launch
• The commissioning result review (CRR), held after completion of the on- orbit commissioning activities
• The end-of-life review (ELR) held at the completion of the mission
4.4.3.7.3 Main review objectives - Flight readiness review (FRR)
The flight readiness review takes place before launch to ensure that both flight and ground segments, along with all supporting systems like tracking, communication, and safety systems, are fully prepared for the launch.
4.4.3.7.4 Main review objectives - Launch readiness review (LRR)
The launch readiness review occurs immediately before the launch, aiming to confirm the preparedness of the launch vehicle, space and ground segments, and all supporting systems, including tracking, communication, and safety systems This review ultimately provides the necessary authorization to proceed with the launch.
4.4.3.7.5 Main review objectives - Commissioning result review (CRR)
The commissioning result review is held at the end of the commissioning as part of the in-orbit stage verification It allows declaring readiness for routine operations/utilization
This review is conducted after a series of on-orbit tests to ensure that all system components meet specified performance parameters The successful completion of this review usually signifies the formal handover of the system to the project initiator or system operator.
4.4.3.7.6 Main review objectives – End of life review (ELR)
• To verify that the mission has completed its useful operation or service
• To ensure that all on-orbit elements are configured to allow safe disposal
4.4.3.8.1 Major tasks Implement the disposal plan
4.4.3.8.2 Associated review The mission close-out review (MCR) is held at the end of this phase
To ensure that all mission disposal activities are adequately completed.
Project specific reviews
Depending on the project type, applicable business agreements, and the overall implementation approach, additional reviews can be incorporated into the project planning These reviews will align with agreed sub-milestones or additional milestones to address specific project requirements.
Typical examples of such reviews are :
• Detailed design review (software specific review, addressed in ECSS-E- ST-40)
• In orbit operations review (addressed in ECSS-E-ST-70)
• First article configuration review (serial production 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
Project planning
Overview
Project planning requirements are essential for all participants in a project, from the highest-level customer to the lowest-level supplier Each actor, whether acting as a customer or supplier, bears the responsibilities of both roles The extent and detail of applicable requirements depend on the actor's position in the customer-supplier chain, with the most comprehensive requirements assigned to the top-level supplier As one moves down the chain, the overall scope of requirements decreases but becomes more specific based on the actor's role and the nature of the products being developed and delivered.
Requirements on customers
Customers must prepare business agreements, such as ITTs, RFPs, or RFQs, along with project requirements documents (PRDs) for their suppliers They are required to utilize ECSS standards to define project management, engineering, and product assurance requirements Only relevant ECSS standards for the project's type and phase should be applied to suppliers Customers must tailor the minimum requirements within these standards to help suppliers meet project objectives Additionally, customers are responsible for approving their suppliers' project management plans and key personnel, as well as verifying compliance with all project requirements and constraints Furthermore, customers lower in the supply chain must ensure that their planning aligns with the requirements set by their own customers.
Requirements on suppliers
Each supplier within the customer-supplier chain is required to develop a project management plan (PMP) that adheres to the guidelines outlined in Annex A Furthermore, it is essential for each supplier to submit their PMP to the customer for approval.
Project organization
Organizational structure
5.2.1.1 Requirements on customers and suppliers a Each customer and supplier shall define the authority for project management and business agreement signing b If the project has links with other projects, each customer and supplier shall define the responsibilities relating to the definition and the management of interfaces c Where a customer, or supplier, employs consultants or other specialists to assist him in performing his duties, then the roles, responsibilities and authority of these consultants and specialists shall be defined d When a customer supplies a product to a supplier he shall have the responsibility of a supplier in respect of that product
5.2.1.2 Requirements on suppliers a The supplier shall set up the project management organization in such a way that adequate resources are allocated to the project to ensure timely completion of the business agreement b The supplier shall nominate a project manager with a project team under his authority and reporting directly to him c The supplier shall ensure that the project manager has the authority to execute all tasks needed under the business agreement with direct access to his company management hierarchy to resolve conflicts at the appropriate level d The supplier shall identify the key personnel to be deployed on the work, and include them in the project organization e The supplier shall demonstrate that the key personnel have the necessary qualification, skills and experience to perform the task for which they are allocated f The supplier’s project management organization shall exercise an active monitoring and control over its own and lower tier supplier’s activities and lead its lower tier supplier’s in the execution of subcontracted activities to ensure that their services conform to the customer’s requirements g If a supplier is responsible for more than one business agreement within a project, and the business agreements have different customers, then each business agreement shall be clearly identified and accomplished according to the appropriate relationships h The first level supplier shall establish, maintain and distribute a project directory including key personnel, as a minimum.
Communication and reporting
5.2.2.1 Requirements on customers and suppliers a The top level customer shall:
1 specify a reporting system for the project;
2 specify an action monitoring system for the project b Each customer and supplier in the customer-supplier chain shall implement and maintain the project reporting an action monitoring systems c Formal meetings between the customer and his supplier(s) shall be held to review progress against approved project planning and address major deviations or changes proposed to the project requirements documents d The frequency, location and schedule of customer-supplier project meetings shall be agreed by all participating parties e Customer-supplier meetings shall be based on an agreed written agenda f A chairperson and secretary shall be designated at the beginning of the meeting g The results of the meeting shall be documented in the agreed minutes signed by all parties involved in the meeting h Agreed actions shall be documented in an action item list i Each action shall be allocated
2 the identification of the origin (e.g meeting),
4 the description of the action (clear and concise),
5 the person responsible for the action,
8 the close-out reference (e.g document, letter) j Action items shall be reviewed at each meeting k Any matters documented in the minutes of meeting having impact on the business agreement shall be subject to the contract change procedure for implementation
5.2.2.2 Requirements on suppliers a The supplier shall prepare and submit progress reports to his customer in conformance with Annex E b The supplier shall prepare minutes of progress meetings for approval of the customer c The supplier shall notify the customer within an agreed period of time of any event that could significantly affect the achievement of the business agreement objectives in terms of cost, technical performance and schedule, and any situation resulting in a substantial schedule or planning change demanding immediate customer involvement.
Audits
5.2.3.1 General requirements a Every audit performed shall be followed by a report prepared by the auditor and containing the views of both parties b The conclusions of the audit and the draft report shall be discussed with the supplier, before finalization and release c In the event of disagreement with any of the audit conclusions, the supplier may add his observations and comments d The final audit report shall not be divulged without the agreement of the audited supplier
5.2.3.2 Requirements on customers a The customer shall notify the supplier in due time of
1 his intention to perform an audit;
2 the objectives and the scope of the audit;
3 the designated auditor and his terms of reference;
5.2.3.3 Requirements on suppliers a The supplier shall accept to be audited by the customer or by a third party agreed between the customer and the supplier in the framework of the business agreement b The supplier shall have the right to demand that the audit be performed by a third party, and that the third party obtain authorization each time the audit necessitates access to information concerning patent rights or confidentiality associated with defence secrecy c The supplier shall perform audits of his own project activities and of the project activities of his lower tier supplier(s) to verify conformance with project requirements d The supplier shall provide right of access for participation by the customer in his own audits and in audits of his lower tier suppliers e The supplier shall provide his customer access to his facilities and data which are relevant in the frame of the business agreement.
Project breakdown structures
The supplier is responsible for developing a comprehensive product tree that includes deliverable end items and integrates the product trees of lower-tier suppliers, adhering to Annex B This product tree must be established at the beginning of phase B and finalized by the Preliminary Design Review (PDR) Uniform identification rules for product items are essential, with each item receiving a unique identifier that remains consistent throughout its lifecycle, unless modifications affect interchangeability Customer approval is required for the product tree, which the supplier must keep updated under configuration control Additionally, the supplier must create a work breakdown structure (WBS) that incorporates the WBS of lower-tier suppliers, as outlined in Annex C, detailing all work related to manufacturing, assembly, integration, and testing Support functions must be clearly linked to relevant product tree elements, and the WBS also requires customer approval Each supplier is tasked with maintaining an up-to-date WBS and identifying control work packages based on the approved structure, ensuring visibility for the customer Work package descriptions must be established in accordance with Annex D, with each work package assigned a single responsible manager Finally, the supplier must develop a project organization breakdown structure (OBS).
1 the interface and contractual responsibilities amongst the involved parties
The key personnel and responsible parties for each work package in the Work Breakdown Structure (WBS) must be clearly defined The Organizational Breakdown Structure (OBS) will be submitted to the customer for approval The supplier is responsible for maintaining the approved OBS, ensuring it is kept up-to-date, and distributing it to lower-tier suppliers and the customer.
Project phasing
a The customer shall organize the project into sequential phases which include all project specific reviews and decision milestones
The customer is responsible for establishing project review procedures for all reviews, ensuring alignment with the overall project review planning Additionally, the customer must ensure that supplier project reviews follow the top-down and bottom-up sequence Decisions to transition between project phases will be based on the results of the corresponding "end of phase" review.
NOTE 1 Information concerning the expected delivery of
ECSS management branch documents per review is provided in Annex F
NOTE 2 Information concerning additional documents which are defined as outputs of the management standards requirements and which are not part of review data packages is provided in Annex G
Annex A (normative) Project management plan (PMP) – DRD
A.1.1 Requirement identification and source document
This DRD is called from ECSS-M-ST-10, requirement 5.1.3a
The PMP is prepared to state the purpose and provide a brief introduction to the project management system It covers all aspects of the latter
Introduction a The PMP shall contain a description of the purpose, objective and the reason prompting its preparation (e.g program or project reference and phase)
Applicable and reference documents a The PMP shall list the applicable and reference documents used in support of the generation of the document
Objectives and constraints of the project a The PMP shall briefly describe the objective and constraints of the project in conformance with the project requirements documents
Project organization a The PMP shall describe the project organization approach in conformance with the requirements as defined in clause 5.2
The Project Management Plan (PMP) must outline the approach to project breakdown structures in accordance with the requirements specified in clause 5.3, and it should also identify the titles of the individual documents referenced by these requirements.
The Project Management Plan (PMP) must outline the approach to configuration, information, and documentation management as specified in ECSS-M-ST-40, Annex A If this approach is detailed in a separate configuration management plan, the PMP can provide a concise summary and reference the relevant plan.
The Project Management Plan (PMP) must outline the cost and schedule management strategy as specified in ECSS-M-ST-60 If this strategy is detailed in a separate cost and schedule management plan, the PMP can provide a concise overview and reference the plan instead.
Integrated logistic support a The PMP shall describe the integrated logistic support approach, as defined in ECSS-M-ST-70
The PMP will outline the risk management strategy, which is elaborated further in the comprehensive risk management policy and plan, as specified in ECSS-M-ST-80, Annexes A and B.
The Product Management Plan (PMP) must outline the product assurance management strategy, detailing the division into various product assurance (PA) disciplines and their interconnections as specified in ECSS-Q-ST-10, Annex A If a comprehensive PA plan is available, the PMP can provide a concise overview and reference the detailed product assurance plan.
The Project Management Plan (PMP) must outline the engineering management strategy, detailing the division into various engineering disciplines and their interconnections as specified in ECSS-E-ST-10, Annex D If the engineering management strategy is already covered in a comprehensive system engineering plan, the PMP can provide a concise overview along with a reference to that plan.
Annex B (normative) Product tree – DRD
B.1.1 Requirement identification and source document
This DRD is called from ECSS-M-ST-10, requirement 5.3a
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, integral to the design definition file, serves as the foundation for selecting configuration items in accordance with ECSS-M-ST-40 and for creating the work breakdown structure It is a fundamental framework for developing the specification tree as outlined in ECSS-E-ST-10.
Introduction a 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)
Applicable and reference documents a The product tree shall list the applicable and reference documents used in support of the generation of the document
The product tree will outline the lower-level products that make up the final deliverable For each item listed in the product tree, specific information must be provided.
The product tree must be displayed as either a graphical diagram or an indented structure, illustrating the decomposition of the top-level product into lower-level products Each configuration item selected must be clearly identified within the product tree Additionally, any recurrent products from previous space projects should also be marked within the tree structure.
Annex C (normative) Work breakdown structure (WBS) – DRD
C.1.1 Requirement identification and source document
This DRD is called from ECSS-M-ST-10, requirement 5.3h
The work breakdown structure (WBS) serves as a comprehensive framework for managing project cost and schedule activities, as outlined in ECSS-M-ST-60, while also facilitating the management of technical content It aids project stakeholders in effectively organizing and overseeing their responsibilities.
• conducting tender comparisons and business agreement negotiations;
• optimizing the distribution of work amongst the different suppliers;
• monitoring the schedule of the project
The Work Breakdown Structure (WBS) organizes a project into manageable work packages based on the nature of the work It clearly defines the total work required, detailing the scope to a level that is mutually agreed upon by both the customer and the supplier.
Information concerning the determination of the appropriate WBS level of detail is provided in ECSS-M-ST-10, Annex H
Introduction a The WBS shall contain a description of the purpose, objective and the reason prompting its preparation (e.g program or project reference and phase)
Applicable and reference documents a The WBS shall list the applicable and reference documents used in support of the generation of the document
The Work Breakdown Structure (WBS) must offer a comprehensive and logical breakdown of the product tree elements, incorporating the support functions defined by the customer, such as project management, engineering, and product assurance support, essential for delivering the final items, including development and flight models Additionally, a coding scheme should be implemented for WBS elements to represent the hierarchical structure in a text format.
NOTE 1 A common coding system facilitates communications among all project actors
Each Work Breakdown Structure (WBS) element is assigned a unique code for identification throughout the project's duration, utilizing a logical decimal or alphanumeric system that reflects the hierarchy of elements and their subordinate components The WBS must encompass all control work packages, which can be further detailed by the supplier into additional work packages Collectively, these defined work packages should encompass the entire scope of work The WBS can be visually represented as either a graphical diagram or an indentured structure.
Annex D (normative) Work package (WP) description – DRD
D.1.1 Requirement identification and source document
This DRD is called from ECSS-M-ST-10, requirement 5.3n
The objective of the work package description is to describe the detailed content of each element of the WBS as defined in ECSS-M-ST-10, Annex C
D.2.1 Scope and content a The WP description shall contain the following elements:
1 project name and project phase;
3 unique identification of each WP and issue number
4 supplier or entity in charge of the WP performance;
5 WP manager’s name and organization;
7 product to which the tasks of the WP are allocated (link to the product tree);
8 description of the objectives of the WP;
10 list of the inputs necessary to achieve the tasks;
11 interfaces or links with other tasks or WP’s;
12 list of constraints, requirements, standards, and regulations;
13 list of the expected outputs;
16 start event identification including date;
17 end event identification including date;
Annex E (normative) Progress report – DRD
E.1.1 Requirement identification and source document
This DRD is called from ECSS-M-ST-10, requirement 5.2.2.2a
The objective of the progress report is to provide all actors with actual information concerning the status of the project
E.2.1 Scope and content a The progress report shall contain the following information:
1 The project manager’s assessment of the current situation in relation to the forecasts and risks, at a level of detail agreed between the relevant actors
2 The status of the progress of work being performed by the supplier
3 Status and trends of agreed key performance and engineering data parameters
4 Adverse trends in technical and programmatic performance and proposals for remedial actions
5 Planning for implementation of remedial actions
6 A consolidated report derived from the lower tier suppliers status reports
7 Progress on all actions since the previous report
Annex F (informative) ECSS management branch documents delivery per review
Table F-1 provides the information concerning the expected delivery of ECSS management branch documents per review
This table provides an initial overview of the data package content across different reviews The complete details of the data package will be defined in the business agreement, which also outlines the document delivery schedule between reviews.