ECSS-M-ST-10C Rev.

1
6 March 2009

Space project management

Project planning and implementation

ECSS Secretariat ESA-ESTEC Requirements & Standards Division Noordwijk, The Netherlands

ECSSMST10CRev.1 6March2009

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 associationsforthepurposeofdevelopingandmaintainingcommonstandards.Requirementsinthis Standardaredefinedintermsofwhatshallbeaccomplished,ratherthanintermsofhowtoorganize and perform the necessary work. This allows existing organizational structures and methods to be appliedwheretheyareeffective,andforthestructuresandmethodstoevolveasnecessarywithout rewritingthestandards. This Standard has been prepared by the ECSSMST10 Working Group, reviewed by the ECSS ExecutiveSecretariatandapprovedbytheECSSTechnicalAuthority.

Disclaimer ECSSdoesnotprovideanywarrantywhatsoever,whetherexpressed,implied,orstatutory,including, butnotlimitedto,anywarrantyofmerchantabilityorfitnessforaparticularpurposeoranywarranty that the contents of the item are errorfree. In no respect shall ECSS incur any liability for any damages,including,butnotlimitedto,direct,indirect,special,orconsequentialdamagesarisingout of, resulting from, or in any way connected to the use of this Standard, whether or not based upon warranty,contract,tort,orotherwise;whetherornotinjurywassustainedbypersonsorpropertyor otherwise;andwhetherornotlosswassustainedfrom,oraroseoutof,theresultsof,theitem,orany servicesthatmaybeprovidedbyECSS.

Publishedby:

Copyright:

ESARequirementsandStandardsDivision ESTEC, P.O. Box 299, 2200 AG Noordwijk The Netherlands 2009 by the European Space Agency for the members of ECSS

ECSSMST10CRev.1 6March2009

Change log

ECSSM10A 19April1996 ECSSM10B 13June2003 ECSSMST10C 31July2008

Firstissue

Secondissue

Thirdissue This issue combines the contents of ECSSM10B, ECSSM20B and ECSSM30A.Itsupersedesthesethreestandards. The descriptive text of the previous standards has been combined and rewrittentodeleteduplicationsandcorrectinconsistencies. The requirements of ECSSM10B have been maintained with following exceptions: Requirements on function tree have been deleted and moved to ECSSE10. Requirementsonmodelmatrixhavebeendeleted. Some requirements have been moved to newly established DRDs (e.g. WBSandWPDRD). Somerequirementshavebeeneditedtoeliminateinconsistencies.

The requirements of ECSSM20B have been maintained with following exceptions: Somerequirementshavebeendeletedbecausetheyareobvious. Requirementsofclause5.4arecoveredbyECSSMST40. Somerequirementshavebeeneditedtoeliminateinconsistencies.

ThecontentofECSSM30Ahasbeencompletelyupdatedandrewritten. ECSSMST10CRev.1 Thirdissuerevision1 6March2009 ChangeswithrespecttoversionC(31July2008)areidentifiedwithrevision tracking.Themainchangesare: Changed term technical specification to technical requirements specification. TableF1updatedtoalignitwithECSSEST10,andTableG1updatedto identifyDRDreferences. Insertion of missing Header 4.4.3.2.1 Overview (resp. 4.4.3.3.1 Overview)afterclausenumber4.4.3.2(resp.4.4.3.3)causingrenumbering ofsubsequentclauses.

ECSSMST10CRev.1 6March2009

Table of contents
Change log .................................................................................................................3 Introduction................................................................................................................7 1 Scope.......................................................................................................................8 2 Normative references .............................................................................................9 3 Terms and definitions ..........................................................................................10
3.1 3.2 3.3 Terms defined in other standards............................................................................. 10 Terms specific to the present standard ....................................................................10 Abbreviated terms .................................................................................................... 11

4 Principles ..............................................................................................................12
4.1 Project planning........................................................................................................12 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 4.1.7 4.1.8 4.1.9 4.1.10 4.1.11 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.3.1 Introduction.................................................................................................12 Purpose and objectives of the project ........................................................ 12 Availability of and need to develop new technologies ................................ 13 Availability of and need to reuse existing equipments/products ................. 13 Availability of and need for human resources, skills and technical facilities.......................................................................................................13 Risk assessment ........................................................................................13 Development approach ..............................................................................13 Project deliverables .................................................................................... 13 Customer requirements and constraints..................................................... 14 Project requirements documents (PRD)..................................................... 14 Project management plan...........................................................................14 Introduction.................................................................................................15 Organizational structure .............................................................................15 Communication and reporting ....................................................................15 Audits..........................................................................................................15 Introduction.................................................................................................16 4

Project organization..................................................................................................15

Project breakdown structures ...................................................................................16

ECSSMST10CRev.1 6March2009 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 4.4 4.4.1 4.4.2 4.4.3 4.4.4 Function tree...............................................................................................16 Specification tree ........................................................................................16 Product tree ................................................................................................16 Work breakdown structure (WBS) .............................................................. 17 Work package (WP) ...................................................................................18 Organization breakdown structure (OBS)................................................... 18 Introduction.................................................................................................19 Relationship between business agreements and project phases............... 21 Project phases............................................................................................21 Project specific reviews .............................................................................. 28

Project phasing.........................................................................................................19

5 Requirements........................................................................................................29
5.1 Project planning........................................................................................................29 5.1.1 5.1.2 5.1.3 5.2 5.2.1 5.2.2 5.2.3 5.3 5.4 Overview.....................................................................................................29 Requirements on customers.......................................................................29 Requirements on suppliers......................................................................... 30 Organizational structure .............................................................................30 Communication and reporting ....................................................................31 Audits..........................................................................................................32

Project organization..................................................................................................30

Project breakdown structures ...................................................................................33 Project phasing.........................................................................................................34

Annex A (normative) Project management plan (PMP) DRD ............................35 Annex B (normative) Product tree DRD..............................................................38 Annex C (normative) Work breakdown structure (WBS) DRD..........................40 Annex D (normative) Work package (WP) description DRD .............................42 Annex E (normative) Progress report DRD ........................................................44 Annex F (informative) ECSS management branch documents delivery per review ...................................................................................................................45 Annex G (informative) Management documents delivery (periodic or incident triggered)...............................................................................................47 Annex H (informative) Determination of the appropriate WBS level of detail.....................................................................................................................48 Bibliography.............................................................................................................50

ECSSMST10CRev.1 6March2009

Figures
Figure 4-1: Product tree example...........................................................................................17 Figure 4-2: WBS example ......................................................................................................18 Figure 4-3: Typical project life cycle ....................................................................................... 19 Figure 4-4: Review life cycle ..................................................................................................21

Tables
Table F-1 :Management Documents Delivery per Review..................................................... 46 Table G-1 : Management documents delivery (periodic or incident triggered)....................... 47

ECSSMST10CRev.1 6March2009

Introduction
Project planning and implementation is the project function, encompassing a coherentsetofprocessesforallaspectsofprojectmanagementandcontrol. Thisisdoneby: establishing the project requirements and constraints derived from the missionstatement. defining phases and formal milestones enabling the progress of the project to be controlled with respect to cost, schedule and technical objectives(i.e.projectcontrolfunction). definingprojectbreakdownstructures,whichconstitutethecommonand uniquereferencesystemfortheprojectmanagementto:

identifythetasksandresponsibilitiesofeachactor; facilitatethecoherencebetweenallactivitiesofthewholeproject; performschedulingandcostingactivities.

settingupaprojectorganizationtoperformallnecessaryactivitiesonthe project.

ECSSMST10CRev.1 6March2009

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 together provide a coherent and integrated projectplanningacrossthe3ECSSbranches. Where other ECSS management, engineering, or product assurance standards contain more specific and detailed requirements related to project planning, referencesareprovidedtoidentifywherethesecanbefoundwithintheECSS system. Thisstandardmaybetailoredforthespecificcharacteristicandconstrainsofa spaceprojectinconformancewithECSSSST00.

ECSSMST10CRev.1 6March2009

2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references,subsequentamendmentsto,orrevisionofanyofthesepublications donotapply,However,partiestoagreementsbasedonthisECSSStandardare encouragedtoinvestigatethepossibilityofapplyingthemorerecenteditionsof the normative documents indicated below. For undated references, the latest editionofthepublicationreferredtoapplies. ECSSSST0001 ECSSMST40 ECSSsystemGlossaryofterms SpaceprojectmanagementConfigurationand informationmanagement

ECSSMST10CRev.1 6March2009

3 Terms and definitions

3.1 Terms defined in other standards
For the purpose of this Standard, the terms and definitions from ECSSSST0001apply.

3.2

Terms specific to the present standard

3.2.1 discipline
specificareaofexpertisewithinageneralsubject NOTE The name of the discipline normally indicates the typeofexpertise(e.g.intheECSSSystem,system engineering,mechanicalengineering,softwareand communications are disciplines within the Engineeringdomain)

3.2.2

domain

generalareaofinterestorinfluencecoveringanumberofinterrelatedtopicsor subareas NOTE Thenameofadomainnormallyindicatesthearea of interest (e.g. in the ECSS System, the Management,Engineering,andProductAssurance branchesrepresentthreedifferentdomains).

3.2.3

function

combination and interaction of a number of operations or processes, which togetherachieveadefinedobjective

10

ECSSMST10CRev.1 6March2009

3.3

Abbreviated terms
ForthepurposesofthisStandard,theabbreviatedtermsfromECSSSST0001 andthefollowingapply.

Abbreviation
AR B/L CBCP CDR CRR DRL EAC EGSE ELR ETC FRR GSE ILS ITT LRR MCR MDR MGSE N/A OBCP OBS ORR PDR PMP PRD PRR QR RFP RFQ SRR WBS WP

Meaning
acceptancereview baseline currentbaselinecostplan criticaldesignreview commissioningresultreview documentrequirementslist estimateatcompletion electricalgroundsupportequipment endoflifereview estimatetocompletion flightreadinessreview groundsupportequipment integratedlogisticsupport invitationtotender launchreadinessreview missioncloseoutreview missiondefinitionreview mechanicalgroundsupportequipment notapplicable originalbaselinecostplan organizationalbreakdownstructure operationalreadinessreview preliminarydesignreview projectmanagementplan projectrequirementsdocuments preliminaryrequirementsreview qualificationreview requestforproposal requestforquote systemrequirementsreview workbreakdownstructure workpackage

11

ECSSMST10CRev.1 6March2009

4 Principles
4.1 Project planning
4.1.1 Introduction

Project planning and implementation encompassesall of the processes carried outinordertoplanandexecuteaspaceprojectfrominitiationtocompletionat all levels in the customersupplier chain in a coordinated, efficient and structuredmanner.Itisaprojectwideactivityreceivinginputsfromallproject disciplinesandinvolvingclosecooperationacrosstheprojectdomains. A space project typically comprises a space segment and a ground segment whichareimplementedinparallel(seeECSSEST70).Theyrelyon,andhave interfaces with the launch service segment. These three segments comprise a spacesystem. In principle, a proposal to initiate a space project can be raised by any party. However,themostcommoninitiatorsare: individual governments, or cooperation between a number of governments; national,orinternationalspaceagencies,eithersinglyorcollectively; nationalorinternationalscientificcommunities; operatorsofcommercialspacesystems.

In this ECSS standard, the top level customer is defined as the organization responsible for generating the top level space segment and ground segment business agreements and for interface arrangements with other external space systemelements. Thefollowingclauses4.1.2to4.1.11describethekeyelementstobeaddressed, assessed,andbalancedwhenplanningaproject.

4.1.2

Purpose and objectives of the project

Thepurposeandobjectivesoftheprojectaredefinedbytheprojectinitiatorin the mission statement which includes key performance parameters and technical and programmatic constraints to be applied to the project. They are normallycoordinatedwiththetoplevelcustomer,ifonehasbeenassigned.

12

ECSSMST10CRev.1 6March2009

4.1.3

Availability of and need to develop new technologies

This is an assessment carried out jointly by the customer and supplier to identify the availability of scientific and technological knowhow and 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 assessmentofrequiredresourcesandfacilitiesandtothesubsequenttechnical andprogrammaticriskassessment.

4.1.4

Availability of and need to reuse existing equipments/products

This is an assessment of the feasibility of reusing existing products and is typicallycarriedoutasadirectresponsetoacustomerrequirement.Theresult of this assessment, which also can have a significant influence on cost and scheduleisamajorinputtotheassessmentofrequiredresourcesandfacilities andtothesubsequenttechnicalandprogrammaticriskassessment.

4.1.5

Availability of and need for human resources, skills and technical facilities

This is an assessment carried out jointly by the customer and supplier of the resources, skills and facilities required to implement the project. The result of thisassessmentshowsifrequiredresources,skillsandfacilitiesareadequate,or ifadditionalskills,resources,orfacilitiesareneededtocompletetheproject.

4.1.6

Risk assessment

Theinitialassessmentsofthetechnicalandprogrammaticrisksofaprojectare carriedoutbythecustomer,basedontheprojectinitiatorsinputswithrespect to the purpose and objectives of the project, together with the identified technicalandprogrammaticconstraintstobeappliedtotheproject.Theinitial assessment is subsequently regularly expanded to include other relevant parameters as they become available, and as the project matures. Comprehensiveriskassessmentsareconductedateachmajorprojectreview.

4.1.7

Development approach

Thedevelopmentapproachforaprojectisjointlydefinedbythecustomerand suppliertocomplywiththeprojectinitiatorsmissionstatement,requirements and constraints, and balancing these with the outcome of paragraphs 4.1.3 to 4.1.6above.

4.1.8

Project deliverables

The customer has the responsibility for defining the deliverable products, neededtomeettheprojectinitiatorsmissionstatement,takingintoaccountthe assessmentsnotedinclauses4.1.4to4.1.7above.

13

ECSSMST10CRev.1 6March2009

4.1.9

Customer requirements and constraints

Customerrequirementsandconstraintsarepreparedbythecustomerbasedon the outputs from 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 requirementsdocuments(PRD).

4.1.10

Project requirements documents (PRD)

TheprojectrequirementsdocumentsareanintegralpartofanITT,requestfor proposal (RFP), or request for quote (RFQ) prepared and released by a customertopotentialsuppliers. ThePRDtypicallycomprise Statementofwork Technical requirements documented in Technical Requirements Specification,asdefinedinECSSEST1006 Managementrequirements Engineeringrequirements Productassurancerequirements Programmaticrequirements Other, project specific requirements (e.g. geographical distribution, modelphilosophytobeapplied) Documentsrequirementslist(DRL) Tenderrequirements

Under the ECSS system, management, engineering and product assurance requirementsarecontainedintheM,E,andQstandards,progressivelytailored byeachcustomerinthecustomersupplierchaintoreflectthetypeandphaseof the project covered by the business agreement, as well as the scope of the supplierstasksrequiredbythePRD.

4.1.11

Project management plan

The top level project plan is the project management plan which defines the projectmanagementapproachandmethodologytobeusedthroughoutthelife cycle of the project, together with an overview of all elements of project management disciplines. It includes the definition of the system engineering and product assurance management approach or provides references to separatesystemengineeringandproductassuranceplanswhichtogethermake upthetotalplanningdocumentationusedtoimplementaproject.

14

ECSSMST10CRev.1 6March2009

4.2

Project organization
4.2.1 Introduction

Theestablishmentofawellstructuredandcoherentorganizationalstructurefor implementing a project at all levels in the customersupplier chain is a key factor for ensuring an effective and efficient management approach. At each levelinthecustomersupplierchainaprojectorganizationcanbebuiltasaself standing project team containing all necessary disciplines within the team structureor,moreoften,canbebuiltaroundacoreprojectteamcontainingkey project functions with other necessary functions being provided from outside theprojectteamasexternalsupport. Irrespectiveoftheorganizationalapproachfollowedforaproject,theelements summarizedbelowarerelevantatalllevelsinthecustomersupplierchain.

4.2.2

Organizational structure

Itisessentialthattheprojectorganizationalstructureisarrangedtoincludeall disciplines essential to implement the project with well defined functions as wellasclearreportinglines,interrelationshipsandinterfaces.Allprojectactors below the top level customer and above the lowest level supplier(s) have the roles of suppliers and customers, and their organizational structures are constructedtoaccommodatebothroles. Theorganizationalstructureprovidesaclearandunambiguousdefinitionand allocation of individual roles and responsibilities together with the necessary authority to implement these within the internal project setup as well as towardsprojectexternalinterfaces.

4.2.3

Communication and reporting

Effective means of communication are essential tools for ensuring clear and efficient interaction 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 clarityabouttheprojectsgoalsandobjectivesandsubsequently,tosupportthe daytodayworkoftheprojectteam.Regularreportingisanimportanttoolfor exchanginginformationconcerningtheprogressoftheproject.

4.2.4

Audits

Audits are independent examinations to determine whether processes and proceduresachievethespecifiedobjective.Theyareanessentialtooltoidentify problemareas.

15

ECSSMST10CRev.1 6March2009

4.3

Project breakdown structures

4.3.1 Introduction

Project breakdown structures provide the basis for creating a common understanding between all actors. They break the project down into manageableelementsasdescribedinthefollowingclauses4.3.2to4.3.7.

4.3.2

Function tree

Thefunctiontreeisthebreakdownofthesystemperformancesintofunctions. Each function is decomposed into subfunctions independent of the type of productsinvolved.Thefunctionapproachisappliedduringprojectstartup orduringthesystemdefinitionphase.Moredetailsaboutthefunctiontreeare giveninECSSEST10,functiontreeDRD.

4.3.3

Specification tree

The specification tree defines the hierarchical relationship of all technical requirements specifications for the different elements of a system or product. More details about the specification tree are given in ECSSEST10, specificationtreeDRD.

4.3.4

Product tree

The product tree is the breakdown of the project into successive levels of hardware and software products or elements, articulated to perform the functionsidentifiedinthefunctiontree.However,thefunctionandtheproduct tree do not necessarily mirror each other. The product tree includes the development models, the GSE, the integration tools and test equipment, and externalitemsnecessarytovalidatetheendproductandILSitems.Itincludes itemssubmittedtocustomerconfigurationcontrolanditemsthatarethesubject of a technical requirements specification. The product tree forms the basis for theelaborationoftheprojectworkbreakdownstructure. AnexampleofaproducttreeisshowninFigure41.

16

ECSSMST10CRev.1 6March2009
Space System

Space Segment

Ground Segment

Platform

Payload

GSE

Mission Control Center

Payload Control Center

Communications System

Structure

Instrument 1

MGSE

Thermal control

Instrument 2

EGSE

On-board power supply

Instrument 3

Attitude control

Data handling

Figure41:Producttreeexample

4.3.5

Work breakdown structure (WBS)

TheWBSistheprincipalstructureusedinmanagingaprojectandprovidesa framework for managing cost, schedule and technical content. It divides the project into manageable work packages, organized according to the nature of the work by breaking down the total work to be performed into increasing levelsofdetail. The WBS is derived from the product tree, selected elements of which are extended to include support functions (i.e. management, engineering, product assurance)andassociatedservices(e.g.testfacilities). AnexampleofaWBSisshowninFigure42.

17

ECSSMST10CRev.1 6March2009

Figure42:WBSexample

4.3.6

Work package (WP)

A WP can be any element of the WBS down to the lowest level that can be measuredandmanagedforplanning,monitoring,andcontrol. Control work packages are identified by the supplier at the level in the WBS where visibility and control is required, and for which reporting is to be performed.Thecontrolworkpackagesrepresentthetotalworkscopeandare agreedbythecustomer. The work of each supplier is explicitly identified in the work breakdown structurebyatleastonecontrolworkpackage.

4.3.7

Organization breakdown structure (OBS)

TheOBSdepictstheproposedprojectorganization,includingtheinterfaceand contractual responsibilities, as opposed to company organization breakdown structure,whichdepictsthefunctionalaspectsofthecompany.TheprojectOBS shows the key personnel and the assigned responsible parties for each work packageintheWBS.

18

ECSSMST10CRev.1 6March2009

4.4

Project phasing
4.4.1

Introduction

Thelifecycleofspaceprojectsistypicallydividedinto7phases,asfollows: Phase0Missionanalysis/needsidentification PhaseAFeasibility PhaseBPreliminaryDefinition PhaseCDetailedDefinition PhaseDQualificationandProduction PhaseEUtilization PhaseFDisposal

AtypicalprojectlifecycleisillustratedinFigure43. Project phases are closely linked to activities on system and product level. Depending on the specific circumstances of a project and the acceptance of involvedrisk,activitiescanoverlapprojectphases. At the conclusion of the major activities and the related project reviews configurationbaselinesareestablished(seeECSSMST40).

Figure43:Typicalprojectlifecycle

19

ECSSMST10CRev.1 6March2009
Phases0,A,andBarefocusedmainlyon the elaboration of system functional and technical requirements and identification of system concepts to comply with the mission statement, takingintoaccountthetechnicalandprogrammaticconstraintsidentified bytheprojectinitiatorandtoplevelcustomer. theidentificationofallactivitiesandresourcestobeusedtodevelopthe spaceandgroundsegmentsoftheproject, theinitialassessmentsoftechnicalandprogrammaticrisk, initiationofpredevelopmentactivities.

PhasesCandDcompriseallactivitiestobeperformedinordertodevelopand qualifythespaceandgroundsegmentsandtheirproducts. PhaseEcomprisesallactivitiestobeperformedinordertolaunch,commission, utilize,andmaintaintheorbitalelementsofthespacesegmentandutilizeand maintaintheassociatedgroundsegment. Phase F comprises all activities to be performed in order to safely dispose all productslaunchedintospaceaswellasgroundsegment. Eachoftheaboveprojectphasesincludesendmilestonesintheformofproject review(s), the outcome of which determines readiness of the project to move forwardtothenextphase. Requirements on organization and conduct of reviews are provided in ECSSMST1001. With the exception of the MDR which normally involves only the project initiator, and the top level customer, all other project reviews up to and including the AR are typically carried out by all project actors down to the lowest level supplier in the customersupplier chain involved in the project phasescontainingthesereviews. FromthePRRtothePDR,thesequenceofthereviewsistopdown,starting withthetoplevelcustomerandhistoplevelsupplier,andcontinuingdownthe customersupplierchaintothelowestlevelsupplier.FromtheCDRtotheAR, the sequence of reviews is reversed to bottom up, starting with the lowest level supplier and its customer and continuing up through the customer supplierchaintothe1stlevelsupplierandthetoplevelcustomer.Thissocalled VmodelisillustratedinFigure44.

20

ECSSMST10CRev.1 6March2009

Figure44:Reviewlifecycle

4.4.2

Relationship between business agreements and project phases

Abusinessagreementcancoverasingleprojectphase,asequentialgroupingof projectphasesorsubphases(e.g.phaseB1/phaseB2;phaseB2/phaseC1/phase C2), depending on such factors as funding availability, competitive tendering, schedule, perceived risk. Irrespective of the approach used for defining the scope of individual business agreements, all space projects essentially follow the classicalproject phases insequence andincludeall of the major objectives andkeymilestonesofeachofthesephases.

4.4.3
4.4.3.1

Project phases
General

The clause 4.4.3 provides an introduction and overview of the typical major tasks,associatedreviewmilestones,andreviewobjectivesforeachofthephases inaprojectlifecycle.

4.4.3.2
4.4.3.2.1

Phase 0 (Mission analysis/needs identification)

Overview

This is mainly an activity conducted by the project initiator, the top level customerandrepresentativesoftheendusers.

21

ECSSMST10CRev.1 6March2009 4.4.3.2.2

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 respecttothephysicalandoperationalenvironment. Developthepreliminarytechnicalrequirementsspecification. Identifypossiblemissionconcepts. Perform preliminary assessment of programmatic aspects supported by marketandeconomicstudiesasappropriate. Performpreliminaryriskassessment.

4.4.3.2.3

Associated review

Themissiondefinitionreview(MDR)isheldattheendofphase0. Theoutcomeofthisreviewisusedtojudgethereadinessoftheprojecttomove intophaseA.

4.4.3.2.4

Main review objective(s)

The primary objective of this review is to release the mission statement and assess the preliminary technical requirements specification and programmatic aspects.

4.4.3.3
4.4.3.3.1

Phase A (Feasibility)
Overview

This is mainly an activity conducted by the top level customer and one or several first level suppliers with the outcome being reported to the project initiator,andrepresentativesoftheendusersforconsideration.

4.4.3.3.2

Major tasks

Establish the preliminary management plan, system engineering plan andproductassuranceplanfortheproject. Elaborate possible system and operations concepts and system architectures and compare these against the identified needs, to determinelevelsofuncertaintyandrisks. Establishthefunctiontree. Assess the technical and programmatic feasibility of the possible concepts by identifying constraints relating to implementation, costs, schedules, organization, operations, maintenance, production and disposal. Identifycriticaltechnologiesandproposepredevelopmentactivities. 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 elaboratedduringPhaseB. Elaboratetheriskassessment.

22

ECSSMST10CRev.1 6March2009 4.4.3.3.3 Associated review

Thepreliminaryrequirementsreview(PRR)isheldattheendofPhaseA.The outcomeofthisreviewisusedtojudgethereadinessoftheprojecttomoveinto PhaseB.

4.4.3.3.4

Main review objective(s)

Theprimaryobjectivesofthisrevieware: Releaseofpreliminarymanagement,engineeringandproductassurance plans. Releaseofthetechnicalrequirementsspecification. Confirmationofthetechnicalandprogrammaticfeasibilityofthesystem concept(s). Selection of system and operations concept(s) and technical solutions, including model philosophy and verification approach, to be carried forwardintoPhaseB.

4.4.3.4
4.4.3.4.1

Phase B (Preliminary definition)

Major tasks

Finalize the project management, engineering and product assurance plans. Establishthebaselinemasterschedule. Elaboratethebaselinecostatcompletion. Elaboratethepreliminaryorganizationalbreakdownstructure(OBS). Confirm technical solution(s) for the system and operations concept(s) andtheirfeasibilitywithrespecttoprogrammaticconstraints. Conduct tradeoff studies and select the preferred system concept, togetherwiththepreferredtechnicalsolution(s)forthisconcept. Establishapreliminarydesigndefinitionfortheselectedsystemconcept andretainedtechnicalsolution(s). Determinetheverificationprogramincludingmodelphilosophy. Identifyanddefineexternalinterfaces. Prepare the next level specification and related business agreement documents. Initiate predevelopment work on critical technologies or system design areaswhenitisnecessarytoreducethedevelopmentrisks. Initiate any longlead item procurement required to meet project scheduleneeds. Preparethespacedebrismitigationplanandthedisposalplan. Conductreliabilityandsafetyassessment. Finalize the product tree, the work breakdown structure and the specificationtree. Updatetheriskassessment.

23

ECSSMST10CRev.1 6March2009 4.4.3.4.2

Associated reviews

Thereare2projectreviewsassociatedwithPhaseB. Thesystemrequirementsreview(SRR)heldduringthecourseofPhaseB. 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 moveintoPhaseC.

4.4.3.4.3

Main review objectives - System requirements review

Theprimaryobjectivesofthisrevieware: Releaseofupdatedtechnicalrequirementsspecifications. Assessmentofthepreliminarydesigndefinition. Assessmentofthepreliminaryverificationprogram.

4.4.3.4.4

Main review objectives Preliminary design review

Theprimaryobjectivesofthisrevieware: Verification of the preliminary design of the selected concept and technicalsolutionsagainstprojectandsystemrequirements. Releaseoffinalmanagement,engineeringandproductassuranceplans. Releaseofproducttree,workbreakdownstructureandspecificationtree. Releaseoftheverificationplan(includingmodelphilosophy).

4.4.3.5
4.4.3.5.1

Phase C (Detailed definition)

Major tasks

The scope and type of tasks undertaken during this phase are driven by the modelphilosophyselectedfortheproject,aswellastheverificationapproach adopted. Completionofthedetaileddesigndefinitionofthesystematalllevelsin thecustomersupplierchain. Production,developmenttestingandprequalificationofselectedcritical elementsandcomponents. Productionanddevelopmenttestingofengineeringmodels,asrequired bytheselectedmodelphilosophyandverificationapproach. Completionofassembly,integrationandtestplanningforthesystemand itsconstituentparts. Detaileddefinitionofinternalandexternalinterfaces. Issueofpreliminaryusermanual. Updateoftheriskassessment.

4.4.3.5.2

Associated review

Thecriticaldesignreview(CDR)isheldattheendofphaseC.Theoutcomeof thisreviewisusedtojudgethereadinessoftheprojecttomoveintophaseD.

24

ECSSMST10CRev.1 6March2009 4.4.3.5.3

Main review objectives

Assessthequalificationandvalidationstatusofthecriticalprocessesand theirreadinessfordeploymentforphaseD. Confirmcompatibilitywithexternalinterfaces. Releasethefinaldesign. Releaseassembly,integrationandtestplanning. Releaseflighthardware/softwaremanufacturing,assemblyandtesting. Releaseofusermanual.

4.4.3.6
4.4.3.6.1

Phase D (Qualification and production)

Major tasks

Completequalificationtestingandassociatedverificationactivities. Complete manufacturing, assembly and testing of flight hardware/softwareandassociatedgroundsupporthardware/software. Complete the interoperability testing between the space and ground segment. Prepareacceptancedatapackage.

4.4.3.6.2

Associated reviews

Thereare3projectreviewsassociatedwithphaseD Thequalificationreview(QR)heldduringthecourseofthephase. Theacceptancereview(AR)heldattheendofthephase.Theoutcomeof thisreviewisusedtojudgethereadinessoftheproductfordelivery. Theoperationalreadinessreview(ORR),heldattheendofthephase.

4.4.3.6.3

Main review objectives Qualification review

Theprimaryobjectivesofthisrevieware: To confirm that the verification process has demonstrated that the design,includingmargins,meetstheapplicablerequirements. To verify that the verification record is complete at this and all lower levelsinthecustomersupplierchain. Toverifytheacceptabilityofallwaiversanddeviations.

Where development encompasses the production of one or several recurring products,theQRiscompletedbyafunctionalconfigurationverificationduring which: The first article configuration is analyzed from the viewpoint of reproducibility. Theproductionmasterfilesfortheseriesproductionsarereleased. Theseriesproductiongoaheadfileisacceptedbythecustomer.

25

ECSSMST10CRev.1 6March2009 4.4.3.6.4

Main review objectives Acceptance review

Theprimaryobjectivesofthisrevieware: To confirm that the verification process has demonstrated that the product is free of workmanship errors and is ready for subsequent operationaluse. To verify that the acceptance verification record is complete at this and alllowerlevelsinthecustomersupplierchain. To verify that all deliverable products are available per the approved deliverableitemslist. To verify the asbuilt product and its constituent components against therequiredasdesignedproductanditsconstituentcomponents. Toverifytheacceptabilityofallwaiversanddeviations. ToverifythattheAcceptanceDataPackageiscomplete. Toauthorizedeliveryoftheproduct. Toreleasethecertificateofacceptance.

4.4.3.6.5

Main review objectives - Operational readiness review (ORR)

Theprimaryobjectivesofthisrevieware: Toverifyreadinessoftheoperationalproceduresandtheircompatibility withtheflightsystem. Toverifyreadinessoftheoperationsteams. Toacceptandreleasethegroundsegmentforoperations.

4.4.3.7
4.4.3.7.1

Phase E (Operations/utilization)
Major tasks

Themajortasksforthisphasevarywidelyasafunctionofthetypeofproject concerned.Therefore,onlyageneraloverviewofactivitiesduringthisphaseis providedhere. Perform all activities at space and ground segment level in order to preparethelaunch. Conductalllaunchandearlyorbitaloperations. Performonorbitverification(includingcommissioning)activities. Performallonorbitoperationsinordertoachievethemissionobjectives. Performallgroundsegmentactivitiesinordertosupportthemission. Perform all other ground support activities in order to support the mission. Finalizethedisposalplan.

26

ECSSMST10CRev.1 6March2009 4.4.3.7.2

Associated reviews

Thereare4projectreviewsassociatedwithphaseE. Theflightreadinessreview(FRR)isheldpriortolaunch. Thelaunchreadinessreview(LRR),heldimmediatelypriortolaunch. Thecommissioningresultreview(CRR),heldaftercompletionoftheon orbitcommissioningactivities. Theendoflifereview(ELR)heldatthecompletionofthemission.

4.4.3.7.3

Main review objectives - Flight readiness review (FRR)

The flight readiness review is conducted prior to launch. The objective of this reviewistoverifythattheflightandgroundsegmentsincludingallsupporting systems such as tracking systems, communication systems and safety systems arereadyforlaunch.

4.4.3.7.4

Main review objectives - Launch readiness review (LRR)

Thelaunchreadinessreviewisconductedjustpriortolaunch.Theobjectiveof this review is to declare readiness for launch of the launch vehicle, the space and ground segments including all supporting systems such as tracking systems, communication systems and safety systems and to provide the authorizationtoproceedforlaunch.

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 inorbit stage verification. It allows declaring readiness for routine operations/utilization. This Review is conducted following completion of a series of onorbit tests designed to verify that all elements of the system are performing within the specified performance parameters. Successful completion of this review is typicallyusedtomarktheformalhandoverofthesystemtotheprojectinitiator ortothesystemoperator.

4.4.3.7.6

Main review objectives End of life review (ELR)

Toverifythatthemissionhascompleteditsusefuloperationorservice. Toensurethatallonorbitelementsareconfiguredtoallowsafedisposal.

4.4.3.8
4.4.3.8.1

Phase F (Disposal)
Major tasks

Implementthedisposalplan.

4.4.3.8.2

Associated review

Themissioncloseoutreview(MCR)isheldattheendofthisphase.

4.4.3.8.3

Main review objectives

Toensurethatallmissiondisposalactivitiesareadequatelycompleted.

27

ECSSMST10CRev.1 6March2009

4.4.4

Project specific reviews

Inadditiontotheprojectreviewsidentifiedabove,anddependingonthetype of project, the applicable business agreement and the overall implementation approachadopted,additionalreviewscanbeinsertedintotheprojectplanning against agreed submilestones/additional milestones to meet particular project needs. Typicalexamplesofsuchreviewsare: Detailed design review (software specific review, addressed in ECSSE ST40) Inorbitoperationsreview(addressedinECSSEST70) Firstarticleconfigurationreview(serialproductionspecificreview) Systemdesignreview Systemqualificationreviewatgroundlevel(launcherspecificreview) Systemqualificationreviewatflightlevel(launcherspecificreview)

Thesereviewsarenotfurtheraddressedinthisstandard.

28

ECSSMST10CRev.1 6March2009

5 Requirements
5.1 Project planning
5.1.1 Overview

Projectplanningrequirementsareapplicabletoallactorsofaprojectfromthe top level customer down to the lowest level supplier. Project actors who have theroleofacustomerandasuppliercarrytheresponsibilitiesassociatedwith bothroles.Thescopeanddetailofrequirementsmadeapplicableisafunction ofthelevelofeachactorinthecustomersupplierchain,withthefullscopeof all requirements applicable to the top level supplier. The overall scope made applicable reduces, down through the customersupplier chain but becomes more specific as a function of the role played by each of these actors and the typeofproduct(s)tobedevelopedanddeliveredbythem.

5.1.2
a.

Requirements on customers

Each customer shall prepare business agreements (ITTs, RFPs, or RFQs),includingtheprojectrequirementsdocuments(PRD)tobemade applicablebetweenhimandhissupplier(s). Each customer shall use the ECSS standards to establish the project management, engineering and product assurance requirements applicablefortheproject. Each customer shall make applicable to his supplier(s) only those ECSS standards relevant to the type and phase(s) of the project addressed by thebusinessagreement. Each customer shall specify by tailoring the minimum requirements within the applicable standards necessary for his supplier(s) to achieve theprojectobjectives. Each customer shall approve the project management plans and key personnelofhissupplier(s). Eachcustomershallverifycomplianceofhissupplier(s)withallproject requirementsandconstraints. Each customer below the top level customer in the customersupplier chainshallinadditionensurethatplanningforhissuppliersisconsistent withtheplanningrequirementsimposedonhimbyhiscustomer.

b.

c.

d.

e. f. g.

29

ECSSMST10CRev.1 6March2009

5.1.3
a. b.

Requirements on suppliers

Each supplier in the customersupplier chain shall prepare a project managementplan(PMP)inconformancewithAnnexA. EachsupplierinthecustomersupplierchainshallsubmitthePMPtohis customerforapproval.

5.2

Project organization
5.2.1
5.2.1.1
a. b.

Organizational structure
Requirements on customers and suppliers

Each customer and supplier shall define the authority for project managementandbusinessagreementsigning. If the project has links with other projects, each customer and supplier shall define the responsibilities relating to the definition and the managementofinterfaces. Where a customer, or supplier, employs consultants or other specialists toassisthiminperforminghisduties,thentheroles,responsibilitiesand authorityoftheseconsultantsandspecialistsshallbedefined. When a customer supplies a product to a supplier he shall have the responsibilityofasupplierinrespectofthatproduct.

c.

d.

5.2.1.2
a.

Requirements on suppliers

Thesuppliershallsetuptheprojectmanagementorganizationinsucha waythatadequateresourcesareallocatedtotheprojecttoensuretimely completionofthebusinessagreement. Thesuppliershallnominateaprojectmanagerwithaprojectteamunder hisauthorityandreportingdirectlytohim. The supplier shall ensure that the project manager has the authority to executealltasksneededunderthebusinessagreementwithdirectaccess to his company management hierarchy to resolve conflicts at the appropriatelevel. Thesuppliershallidentifythekeypersonneltobedeployedonthework, andincludethemintheprojectorganization. Thesuppliershalldemonstratethatthekeypersonnelhavethenecessary qualification,skillsandexperiencetoperformthetaskforwhichtheyare allocated. The suppliers project management organization shall exercisean active monitoring and control over its own and lower tier suppliers activities and lead its lower tier suppliers in the execution of subcontracted activities to ensure that their services conform to the customers requirements.

b. c.

d. e.

f.

30

ECSSMST10CRev.1 6March2009
g. Ifasupplierisresponsibleformorethanonebusinessagreementwithin a project, and the business agreements have different customers, then each business agreement shall be clearly identified and accomplished accordingtotheappropriaterelationships. The first level supplier shall establish, maintain and distribute a project directoryincludingkeypersonnel,asaminimum.

h.

5.2.2
5.2.2.1
a. 1. 2. b.

Communication and reporting

Requirements on customers and suppliers
specifyareportingsystemfortheproject; specifyanactionmonitoringsystemfortheproject.

Thetoplevelcustomershall:

Each customer and supplier in the customersupplier chain shall implement and maintain the project reporting an action monitoring systems. Formalmeetingsbetweenthecustomerandhissupplier(s)shallbeheld toreviewprogressagainstapprovedprojectplanningandaddressmajor deviationsorchangesproposedtotheprojectrequirementsdocuments. The frequency, location and schedule of customersupplier project meetingsshallbeagreedbyallparticipatingparties. Customersuppliermeetingsshallbebasedonanagreedwrittenagenda. A chairperson and secretary shall be designated at the beginning of the meeting. The results of the meeting shall be documented in the agreed minutes signedbyallpartiesinvolvedinthemeeting. Agreedactionsshallbedocumentedinanactionitemlist. Eachactionshallbeallocated 1. 2. 3. 4. 5. 6. 7. 8. auniqueidentification, theidentificationoftheorigin(e.g.meeting), theinitiator, thedescriptionoftheaction(clearandconcise), thepersonresponsiblefortheaction, thecloseoutdate, thecurrentstatus,and thecloseoutreference(e.g.document,letter).

c.

d. e. f. g. h. i.

j. k.

Actionitemsshallbereviewedateachmeeting. Anymattersdocumentedintheminutesofmeetinghavingimpactonthe businessagreementshallbesubjecttothecontractchangeprocedurefor implementation.

31

ECSSMST10CRev.1 6March2009

5.2.2.2
a. b. c.

Requirements on suppliers

Thesuppliershallprepareandsubmitprogressreportstohiscustomerin conformancewithAnnexE. Thesuppliershallprepareminutesofprogressmeetingsforapprovalof thecustomer. Thesuppliershallnotifythecustomerwithinanagreedperiodoftimeof anyeventthatcouldsignificantlyaffecttheachievementofthebusiness agreement objectives in terms of cost, technical performance and schedule, and any situation resulting in a substantial schedule or planningchangedemandingimmediatecustomerinvolvement.

5.2.3
5.2.3.1
a. b. c. d.

Audits
General requirements

Every audit performed shall be followed by a report prepared by the auditorandcontainingtheviewsofbothparties. Theconclusionsoftheauditandthedraftreportshallbediscussedwith thesupplier,beforefinalizationandrelease. In the event of disagreement with any of the audit conclusions, the suppliermayaddhisobservationsandcomments. Thefinalauditreportshallnotbedivulgedwithouttheagreementofthe auditedsupplier.

5.2.3.2
a. 1. 2. 3. 4.

Requirements on customers
hisintentiontoperformanaudit; theobjectivesandthescopeoftheaudit; thedesignatedauditorandhistermsofreference; theauditschedule.

Thecustomershallnotifythesupplierinduetimeof

5.2.3.3
a.

Requirements on suppliers

The supplier shall accept to be audited by the customer or by a third partyagreedbetweenthecustomerandthesupplierintheframeworkof thebusinessagreement. Thesuppliershallhavetherighttodemandthattheauditbeperformed byathirdparty,andthatthethirdpartyobtainauthorizationeachtime the audit necessitates access to information concerning patent rights or confidentialityassociatedwithdefencesecrecy. Thesuppliershallperformauditsofhisownprojectactivitiesandofthe projectactivitiesofhislowertiersupplier(s)toverifyconformancewith projectrequirements.

b.

c.

32

ECSSMST10CRev.1 6March2009
d. e. The supplier shall provide right of access for participation by the customerinhisownauditsandinauditsofhislowertiersuppliers. The supplier shall provide his customer access to his facilities and data whicharerelevantintheframeofthebusinessagreement.

5.3

Project breakdown structures

a. Thesuppliershalldeveloptheproducttreeforhisproductsdowntothe deliverable end items, incorporating the product trees of each of his lowertiersuppliers,inconformancewithAnnexB. TheproducttreeshallbeestablishedatstartofphaseBandfinalizednot laterthanPDR. The rules for product item identification shall be uniform within the project. Auniqueidentificationshallbeassignedtoeachitemwithintheproduct tree. The identification shall remain unchanged during the product lifetime, unlessamodificationcausesdiscontinuationofinterchangeability. Theproducttreeshallbesubjecttocustomerapproval. The supplier shall maintain the product tree uptodate under configurationcontrol. Thesuppliershallestablishtheworkbreakdownstructure(WBS)forhis workshare,incorporatingtheWBSofeachofhislowertiersuppliers,in conformancewithAnnexC. Work related to manufacturing, assembly, integration and test of all productmodelsshallbeshownintheWBS. Support functions (management, engineering, product assurance) shall beidentifiableinconnectionwithitsrelatedproducttreeelements. TheWBSshallbesubjecttocustomerapproval. EachsuppliershallmaintainuptodatetheWBSforhisworkshareinthe project. Thesuppliershallidentifycontrolworkpackagesbasedontheapproved WBS,andthelevelofvisibilityrequiredbythecustomer. The supplier shall establish work package (WP) descriptions for each workpackageshowninhisWBSinconformancewithAnnexD. EachWPshallhaveasingleresponsibleWPmanager. The supplier shall establish a project organization breakdown structure (OBS),whichincludes. 1. 2. theinterfaceandcontractualresponsibilitiesamongsttheinvolved parties the key personnel and the assigned responsible parties for each workpackageintheWBS

b. c. d. e. f. g. h.

i. j. k. l. m. n. o. p.

33

ECSSMST10CRev.1 6March2009
q. r. TheprojectOBSshallbesubmittedtothecustomerforapproval. The supplier shall maintain the approved OBS, keep it uptodate, and issueittothelowertiersuppliersandthecustomer.

5.4

Project phasing
a. The customer shall organize the project into sequential phases which includeallprojectspecificreviewsanddecisionmilestones. NOTE b. c. Phasesandreviewsaredefinedinclause4.4.3.

The customer shall prepare project review procedures for all project reviews. Thecustomershallensurethattheprojectreviewsofhissupplier(s)are in line with the topdown / bottomup sequence of the overall project reviewplanning. Thecustomershalltakethedecisiontomovefromonephasetothenext onthebasisoftheoutcomeoftheassociatedendofphasereview. NOTE1 Information concerning the expected delivery of ECSS management branch documents per review isprovidedinAnnexF. NOTE2 Information concerning additional documents which are defined as outputs of the management standardsrequirementsandwhicharenotpartof reviewdatapackagesisprovidedinAnnexG.

d.

34

ECSSMST10CRev.1 6March2009

Annex A (normative) Project management plan (PMP) DRD

A.1 DRD identification
A.1.1 Requirement identification and source document

ThisDRDiscalledfromECSSMST10,requirement5.1.3a.

A.1.2

Purpose and objective

The PMP is prepared to state the purpose and provide a brief introduction to theprojectmanagementsystem.Itcoversallaspectsofthelatter.

A.2

Expected response
A.2.1
<1>
a.

Scope and content

Introduction

The PMP shall contain a description of the purpose, objective and the reasonpromptingitspreparation(e.g.programorprojectreferenceand phase).

<2>
a.

Applicableandreferencedocuments
The PMP shall list the applicable and reference documents used in supportofthegenerationofthedocument.

<3>
a.

Objectivesandconstraintsoftheproject
ThePMPshallbrieflydescribetheobjectiveandconstraintsoftheproject inconformancewiththeprojectrequirementsdocuments.

<4>
a.

Projectorganization
The PMP shall describe the project organization approach in conformancewiththerequirementsasdefinedinclause5.2.

35

ECSSMST10CRev.1 6March2009

<5>
a.

Projectbreakdownstructures
The PMP shall describe the project breakdown structures approach in conformance with the project breakdown structure requirements as definedinclause5.3andidentifythetitleofindividualdocumentscalled upbytheserequirements.

<6>
a.

Configuration,informationanddocumentation management
The PMP shall describe the configuration, information and documentation management approach, as defined in ECSSMST40, AnnexA. If the configuration, information and documentation management approach is contained in a rolledout configuration management plan, thePMPmayincludeonlyabriefdescriptiontogetherwithareferenceto theconfiguration,informationanddocumentationmanagementplan.

b.

<7>
a. b.

Costandschedulemanagement
ThePMPshalldescribethecostandschedulemanagementapproach,as definedinECSSMST60. If the cost and schedule management approach is described in a rolled out cost and schedule management plan, the PMP may include only a brief description together with a reference to the cost and schedule managementplan.

<8>
a.

Integratedlogisticsupport
The PMP shall describe the integrated logistic support approach, as definedinECSSMST70.

<9>
a.

Riskmanagement
The PMP shall briefly describe the risk management approach which is describedinmoredetailinarolledoutriskmanagementpolicyandplan, asdefinedinECSSMST80,AnnexesAandB.

<10>
a.

Productassurancemanagement
The PMP shall describe the product assurance management approach, includingtheproposedbreakdownintoPAdisciplinesandtheinterfaces betweenthesedisciplines,asdefinedinECSSQST10,AnnexA. Iftheproductassurancemanagementapproachisdescribedinarolled outPAplan,thePMPmayincludeonlyabriefdescriptiontogetherwith areferencetotheproductassuranceplan.

b.

36

ECSSMST10CRev.1 6March2009

<11>
a.

Engineeringmanagement
The PMP shall describe the engineering management approach, including the proposed breakdown into engineering disciplines and the interfaces between these disciplines, as defined in ECSSEST10, AnnexD. If the engineering management approach is described in a rolledout system engineering plan, the PMP may include only a brief description togetherwithareferencetothesystemengineeringplan.

b.

A.2.2
None.

Special remarks

37

ECSSMST10CRev.1 6March2009

Annex B (normative) Product tree DRD

B.1 DRD identification
B.1.1 Requirement identification and source document

ThisDRDiscalledfromECSSMST10,requirement5.3a.

B.1.2

Purpose and objective

Theobjectiveoftheproducttreedocumentistodescribe,inasingledocument, the hierarchical partitioning of a deliverable product down to a level agreed betweenthecustomerandsupplier. Theproducttreeispartofthedesigndefinitionfile.Itisthestartingpointfor selecting configuration items (as specified in ECSSMST40) and establishing the work breakdown structure. It is a basic structure to establish the specificationtree(asdefinedinECSSEST10).

B.2

Expected response
B.2.1
<1>
a.

Scope and content

Introduction

Theproducttreeshallcontainadescriptionofthepurpose,objectiveand the reason prompting its preparation (e.g. program or project reference andphase).

<2>
a.

Applicableandreferencedocuments
The product tree shall list the applicable and reference documents used insupportofthegenerationofthedocument.

<3>
a.

Treestructure
The product tree shall provide the breakdown of lower level products constitutingthedeliverableproduct.

38

ECSSMST10CRev.1 6March2009
b. For each item identified in the product tree, the following information shallbeprovided: 1. 2. 3. 4. c. identificationcode; itemname; itemsupplier; applicablespecification.

The product tree shall be presented either as a graphical diagram or an indenturedstructurewheretheproduct(i.e.atthetoplevelofthetree)is decomposedintolowerlevelproducts. Eachproductitemselectedasconfigurationitemshallbeidentifiedinthe producttree. When recurrent products from previous space projects are used, they shallbeidentifiedinthetreestructure.

d. e.

B.2.2
None.

Special remarks

39

ECSSMST10CRev.1 6March2009

Annex C (normative) Work breakdown structure (WBS) DRD

C.1 DRD identification
C.1.1 Requirement identification and source document

ThisDRDiscalledfromECSSMST10,requirement5.3h.

C.1.2

Purpose and objective

Theobjectiveoftheworkbreakdownstructure(WBS)istoprovide,inasingle document,aframeworkforprojectincostandschedulemanagementactivities (as defined in ECSSMST60) and for managing technical content. It assists projectsactorsin: conductingtendercomparisonsandbusinessagreementnegotiations; optimizingthedistributionofworkamongstthedifferentsuppliers; monitoringthescheduleoftheproject.

The WBS divides the project into manageable work packages, organized by natureofwork.Itidentifiesthetotalworktobeperformeddowntoalevelof detailagreedbetweenthecustomerandsupplier. Information concerning the determination of the appropriate WBS level of detailisprovidedinECSSMST10,AnnexH.

C.2

Expected response
C.2.1
<1>
a.

Scope and contents

Introduction

The WBS shall contain a description of the purpose, objective and the reasonpromptingitspreparation(e.g.programorprojectreferenceand phase).

40

ECSSMST10CRev.1 6March2009

<2>
a.

Applicableandreferencedocuments
The WBS shall list the applicable and reference documents used in supportofthegenerationofthedocument.

<3>
a.

Treestructure
The WBS shall provide a logical and exhaustive breakdown of the product tree elements, that includes the customers 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. A coding scheme for WBS elements that represents the hierarchical structurewhenviewedintextformatshallbeused. NOTE1 A common coding system facilitates communicationsamongallprojectactors. NOTE2 E.g.:toeachWBSelementisassignedacodeused for its identification throughout the life of the project.Itcanbeasimpledecimaloralphanumeric coding system that logically indicates the level of an element and related lowerlevel subordinate elements.

b.

c. d. e. f.

TheWBSshallidentifyallcontrolworkpackages. Thecontrolworkpackagesmaybefurtherbrokendownbythesupplier inseveralmoredetailedworkpackages. Alldefinedworkpackagestogethershallcoverthetotalworkscope. The WBS shall be presented either as a graphical diagram or an indenturedstructure.

C.2.2
None.

Special remarks

41

ECSSMST10CRev.1 6March2009

Annex D (normative) Work package (WP) description DRD

D.1 DRD identification
D.1.1 Requirement identification and source document

ThisDRDiscalledfromECSSMST10,requirement5.3n.

D.1.2

Purpose and objective

Theobjectiveoftheworkpackagedescriptionistodescribethedetailedcontent ofeachelementoftheWBSasdefinedinECSSMST10,AnnexC.

D.2

Expected response
D.2.1
a. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

Scope and content

projectnameandprojectphase; WPtitle; uniqueidentificationofeachWPandissuenumber supplierorentityinchargeoftheWPperformance; WPmanagersnameandorganization; supplierscountry; product to which the tasks of the WP are allocated (link to the producttree); descriptionoftheobjectivesoftheWP; descriptionofthetasks; listoftheinputsnecessarytoachievethetasks; interfacesorlinkswithothertasksorWPs; listofconstraints,requirements,standards,andregulations; listoftheexpectedoutputs;

TheWPdescriptionshallcontainthefollowingelements:

42

ECSSMST10CRev.1 6March2009
14. 15. 16. 17. 18. listofdeliverables; locationofdelivery; starteventidentificationincludingdate; endeventidentificationincludingdate; excludedtasks.

D.2.2
None.

Special remarks

43

ECSSMST10CRev.1 6March2009

Annex E (normative) Progress report DRD

E.1 DRD identification
E.1.1 Requirement identification and source document

ThisDRDiscalledfromECSSMST10,requirement5.2.2.2a.

E.1.2

Purpose and objective

The objective of the progress report is to provide all actors with actual informationconcerningthestatusoftheproject.

E.2

Expected response
E.2.1
a. 1.

Scope and content

The project managers assessment of the current situation in relation to the forecasts and risks, at a level of detail agreed betweentherelevantactors. The status of the progress of work being performed by the supplier. Statusandtrendsofagreedkeyperformanceandengineeringdata parameters. Adverse trends in technical and programmatic performance and proposalsforremedialactions. Planningforimplementationofremedialactions. Aconsolidatedreportderivedfromthelowertiersuppliersstatus reports. Progressonallactionssincethepreviousreport.

Theprogressreportshallcontainthefollowinginformation:

2. 3. 4. 5. 6. 7.

E.2.2
None.

Special remarks

44

ECSSMST10CRev.1 6March2009

Annex F (informative) ECSS management branch documents delivery per review

Table F1 provides the information concerning the expected delivery of ECSS managementbranchdocumentsperreview. NOTE This table constitutes a first indication for the data package content at various reviews. The fullcontentofsuchdatapackageisestablished as part of the business agreement, which also defines the delivery of the document between reviews.

The various crosses in a row indicate the increased levels of maturity progressivelyexpectedversusreviews.Thelastcrossinarowindicatesthatat thatreviewthedocumentisexpectedtobecompletedandfinalized.

45

ECSSMST10CRev.1 6March2009

TableF1:ManagementDocumentsDeliveryperReview
Phase DocumentTitle
0 A X X X X X X X X X X B C D E F ELR MCR

DRDref.

MDR PRR SRR PDR CDR QR Projectmanagementplan Producttree Workbreakdownstructure Workpackagedescription Schedule Costestimatereport Configurationmanagementplan Configurationitemlist Configurationitemdatalist Asbuiltconfigurationlist Softwareconfigurationfile Configurationstatusaccountingreports Riskmanagementpolicydocument Riskmanagementplan Riskassessmentreport 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 X X X X X X X

AR ORR FRR LRR CRR X X X X X X X X X X X

ECSSMST10,AnnexA ECSSMST10,AnnexB ECSSMST10,AnnexC ECSSMST10,AnnexD ECSSMST60,AnnexB ECSSMST60,AnnexG ECSSMST40,AnnexA ECSSMST40,AnnexB ECSSMST40,AnnexC ECSSMST40,AnnexD ECSSMST40,AnnexE ECSSMST40,AnnexF ECSSMST80,AnnexA ECSSMST80,AnnexB ECSSMST80,AnnexC

46

ECSSMST10CRev.1 6March2009

Annex G (informative) Management documents delivery (periodic or incident triggered)

TableG1liststhedocumentswhicharedefinedasoutputsofthemanagement standardsrequirementsandwhicharenotpartofreviewdatapackages.

TableG1:Managementdocumentsdelivery(periodicor incidenttriggered)

DocumentTitle
Costbreakdownstructure Scheduleprogressreport CompanyPriceBreakdownForms GeographicalDistributionReport CostEstimatingPlan MilestonePaymentPlan InventoryRecord CostandManpowerReport OBCPandCBCPforCostReimbursement OBCPandCBCPforFixedPrice EACandETCforCostReimbursement EACforFixedPrice ContractChangeNotice Changerequest Changeproposal Requestfordeviation Requestforwaiver

DRDref.
ECSSMST60,AnnexA ECSSMST60,AnnexC ECSSMST60,AnnexD ECSSMST60,AnnexE ECSSMST60,AnnexF ECSSMST60,AnnexH ECSSMST60,AnnexI ECSSMST60,AnnexJ ECSSMST60,AnnexK ECSSMST60,AnnexL ECSSMST60,AnnexM ECSSMST60,AnnexN ECSSMST60,AnnexO ECSSMST40,AnnexG ECSSMST40,AnnexH ECSSMST40,AnnexI ECSSMST40,AnnexJ

47

ECSSMST10CRev.1 6March2009

Annex H (informative) Determination of the appropriate WBS level of detail

Themainchallengeassociatedwithdevelopingtheworkbreakdownstructure (WBS)istodeterminethebalancing between the project definition aspects oftheWBSandtherequirementsfordatacollectingandreporting.Onehas to keep in mind that the WBS is a tool designed to assist the project manager whendecomposingtheprojectonlytothelevelsnecessarytomeettheneedsof theproject,thenatureofthework,andtheconfidenceoftheteam. An excessive WBS levels can lead to unrealistic levels of maintenance and reporting,andconsequentlytoaninefficientandovercostlyproject.Thetheory 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 difficulttomanageortheriskunacceptable. Among the different questions arising when developing a WBS, an important oneis:shouldtheWBSbedecomposedfurther? Tohelpansweringthisquestion,weproposethefollowinglistofquestions.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,thenadditionaljudgmentisneeded. Is there a need to improve the assessment of the cost estimates or progressmeasuringoftheWBSelement? 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 createdduringthecompletionoftheWBSelement. Does the WBS element content include more than one type of work processorproducesmorethanonedeliverableatcompletion? Isthereaneedtoassessthetimingofworkprocessesthatareinternalto theWBSelement? Is there a need to assess the cost of work processes or deliverables that areinternaltotheWBSelement? Are there interactions between deliverables within a WBS element to anotherWBSelement?

48

ECSSMST10CRev.1 6March2009
Are there significant time gaps in the execution of the work processes thatareinternaltotheWBSelement? DoresourcerequirementschangeovertimewithinaWBSelement? Are there acceptance criteria, leading to intermediate deliverable(s), applicablebeforethecompletionoftheentireWBSelement? Arethereidentifiedrisksthatrequirespecificattentiontoasubsetofthe WBSelement? Can a subset of the work to be performed within the WBS element be organizedasaseparateunit?

49

ECSSMST10CRev.1 6March2009

Bibliography

ECSSSST00 ECSSEST10 ECSSEST40 ECSSEST70 ECSSMST1001 ECSSMST60 ECSSMST70 ECSSMST80 ECSSQST10

ECSSsystemDescription,implementationand generalrequirements SpaceengineeringSystemengineeringgeneral requirements SpaceengineeringSoftwaregeneralrequirements SpaceengineeringGroundsystemsandoperations SpaceprojectmanagementOrganizationand conductofreviews SpaceprojectmanagementCostandschedule management SpaceprojectmanagementIntegratedlogistic support SpaceprojectmanagementRiskmanagement SpaceproductassuranceProductassurance management

50