Ecss m St 10c Rev.1(6march2009)

7/31/2019 Ecss m St 10c Rev.1(6march2009)

1/50


2/50

ECSSMST10CRev.1

6March2009

2

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 SpaceAgency, national space agencies and European industry

associationsforthepurposeofdevelopingandmaintainingcommonstandards.Requirementsinthis

Standardaredefinedintermsofwhatshallbeaccomplished,ratherthanintermsofhowtoorganize

andperform thenecessarywork.Thisallowsexistingorganizational structuresandmethods tobe

appliedwheretheyareeffective,andforthestructuresandmethodstoevolveasnecessarywithout

rewritingthestandards.

This Standard has been prepared by the ECSSMST10Working 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 inanywayconnected to theuseof thisStandard,whetherornotbasedupon

warranty,contract,tort,orotherwise;whetherornotinjurywassustainedbypersonsorpropertyor

otherwise;andwhetherornotlosswassustainedfrom,oraroseoutof,theresultsof,theitem,orany

servicesthatmaybeprovidedbyECSS.

Publishedby: ESARequirementsandStandardsDivisionESTEC, P.O. Box 299,

2200 AG Noordwijk

The Netherlands

Copyright: 2009 by the European Space Agency for the members of ECSS


3/50

ECSSMST10CRev.1

6March2009

3

Change log

ECSSM10A

19April1996

Firstissue

ECSSM10B

13June2003

Secondissue

ECSSMST10C

31July2008

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 havebeenmoved to newly establishedDRDs (e.g.WBSandWPDRD).

Somerequirementshavebeeneditedtoeliminateinconsistencies.

The requirements of ECSSM20B have been maintained with following

exceptions:

Somerequirementshavebeendeletedbecausetheyareobvious.

Requirementsofclause5.4arecoveredbyECSSMST40.

Somerequirementshavebeeneditedtoeliminateinconsistencies.

ThecontentofECSSM30Ahasbeencompletelyupdatedandrewritten.

ECSSM

ST

10C

Rev.

1

6March2009Third

issue

revision

1

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.


4/50

ECSSMST10CRev.1

6March2009

4

Table of contents

Change log................................................................................................................. 3

Introduction................................................................................................................ 7

1 Scope....................................................................................................................... 8

2 Normative references............................................................................................. 9

3 Terms and definitions .......................................................................................... 10

3.1 Terms defined in other standards............................................................................. 10

3.2 Terms specific to the present standard .................................................................... 10

3.3 Abbreviated terms .................................................................................................... 11

4 Principles .............................................................................................................. 12

4.1 Project planning........................................................................................................ 12

4.1.1 Introduction................................................................................................. 12

4.1.2 Purpose and objectives of the project ........................................................ 12

4.1.3 Availability of and need to develop new technologies ................................ 13

4.1.4 Availability of and need to reuse existing equipments/products ................. 13

4.1.5 Availability of and need for human resources, skills and technicalfacilities....................................................................................................... 13

4.1.6 Risk assessment ........................................................................................ 13

4.1.7 Development approach .............................................................................. 13

4.1.8 Project deliverables .................................................................................... 13

4.1.9 Customer requirements and constraints..................................................... 14

4.1.10 Project requirements documents (PRD)..................................................... 14

4.1.11 Project management plan........................................................................... 14

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

4.2.1 Introduction................................................................................................. 15

4.2.2 Organizational structure ............................................................................. 15

4.2.3 Communication and reporting .................................................................... 15

4.2.4 Audits.......................................................................................................... 15

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

4.3.1 Introduction................................................................................................. 16


5/50

ECSSMST10CRev.1

6March2009

5

4.3.2 Function tree............................................................................................... 16

4.3.3 Specification tree ........................................................................................ 16

4.3.4 Product tree................................................................................................ 16

4.3.5 Work breakdown structure (WBS).............................................................. 17

4.3.6 Work package (WP) ................................................................................... 18

4.3.7 Organization breakdown structure (OBS)................................................... 18

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

4.4.1 Introduction................................................................................................. 19

4.4.2 Relationship between business agreements and project phases............... 21

4.4.3 Project phases............................................................................................ 21

4.4.4 Project specific reviews .............................................................................. 28

5 Requirements........................................................................................................ 295.1 Project planning........................................................................................................ 29

5.1.1 Overview..................................................................................................... 29

5.1.2 Requirements on customers....................................................................... 29

5.1.3 Requirements on suppliers......................................................................... 30

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

5.2.1 Organizational structure ............................................................................. 30

5.2.2 Communication and reporting .................................................................... 31

5.2.3 Audits.......................................................................................................... 325.3 Project breakdown structures................................................................................... 33

5.4 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 perreview................................................................................................................... 45

Annex G (informative) Management documents delivery (periodic orincident triggered)............................................................................................... 47

Annex H (informative) Determination of the appropriate WBS level ofdetail..................................................................................................................... 48

Bibliography............................................................................................................. 50


6/50

ECSSMST10CRev.1

6March2009

6

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


7/50

ECSSMST10CRev.1

6March2009

7

Introduction

Projectplanning and implementation is theproject function, encompassing a

coherentsetofprocessesforallaspectsofprojectmanagementandcontrol.

Thisisdoneby:

establishing theproject requirements and constraintsderived from the

missionstatement.

defining phases and formal milestones enabling the progress of theproject to be controlled with respect to cost, schedule and technical

objectives(i.e.projectcontrolfunction).

definingprojectbreakdownstructures,whichconstitutethecommonand

uniquereferencesystemfortheprojectmanagementto:

identifythetasksandresponsibilitiesofeachactor;

facilitatethecoherencebetweenallactivitiesofthewholeproject;

performschedulingandcostingactivities.

settingupaprojectorganizationtoperformallnecessaryactivitiesonthe

project.


8/50

ECSSMST10CRev.1

6March2009

8

1Scope

The scopeof thisECSSStandard is limited todescribing thekeyelementsof

project planning and implementation and identifying the top level

requirements and products that together provide a coherent and integrated

projectplanningacrossthe3ECSSbranches.

WhereotherECSSmanagement,engineering,orproductassurance standardscontainmore specific and detailed requirements related to project planning,

referencesareprovidedto identifywherethesecanbefoundwithin theECSS

system.

Thisstandardmaybetailoredforthespecificcharacteristicandconstrainsofa

spaceprojectinconformancewithECSSSST00.


9/50

ECSSMST10CRev.1

6March2009

9

2Normative references

The following normative documents contain provisions which, through

reference in this text, constitute provisions of thisECSS Standard. Fordated

references,subsequentamendmentsto,orrevisionofanyofthesepublications

donotapply,However,partiestoagreementsbasedonthisECSSStandardare

encouragedto

investigate

the

possibility

of

applying

the

more

recent

editions

of

thenormativedocuments indicatedbelow. Forundated references, the latest

editionofthepublicationreferredtoapplies.

ECSSSST0001 ECSSsystemGlossaryofterms

ECSSMST40 SpaceprojectmanagementConfigurationand

informationmanagement


10/50

ECSSMST10CRev.1

6March2009

10

3Terms 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 Thenameof thedisciplinenormally 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


11/50

ECSSMST10CRev.1

6March2009

11

3.3 Abbreviated terms

ForthepurposesofthisStandard,theabbreviatedtermsfromECSSSST0001

andthefollowingapply.

Abbreviation Meaning

AR acceptancereview

B/L baseline

CBCP currentbaselinecostplan

CDR criticaldesignreview

CRR commissioningresultreview

DRL documentrequirementslist

EAC estimateatcompletion

EGSE electricalgroundsupportequipment

ELR

endof

life

review

ETC estimatetocompletion

FRR flightreadinessreview

GSE groundsupportequipment

ILS integratedlogisticsupport

ITT invitationtotender

LRR launchreadinessreview

MCR missioncloseoutreview

MDR missiondefinitionreview

MGSE mechanicalgroundsupportequipment

N/A notapplicable

OBCP originalbaselinecostplan

OBS organizationalbreakdownstructure

ORR operationalreadinessreview

PDR preliminarydesignreview

PMP projectmanagementplan

PRD projectrequirementsdocuments

PRR

preliminaryrequirements

review

QR qualificationreview

RFP requestforproposal

RFQ requestforquote

SRR systemrequirementsreview

WBS workbreakdownstructure

WP workpackage


12/50

ECSSMST10CRev.1

6March2009

12

4Principles

4.1 Project planning

4.1.1 Introduction

Projectplanningand implementationencompassesallof theprocessescarried

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

interfaceswith the launch service segment.These three segments comprise a

spacesystem.

Inprinciple,aproposal to initiatea spaceprojectcanbe raisedbyanyparty.

However,themostcommoninitiatorsare:

individual governments, or cooperation between a number of

governments;

national,orinternationalspaceagencies,eithersinglyorcollectively;

nationalorinternationalscientificcommunities;

operatorsofcommercialspacesystems.

In thisECSS standard, the top level customer isdefined 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

technicalandprogrammaticconstraints tobeapplied to theproject.Theyare

normallycoordinatedwiththetoplevelcustomer,ifonehasbeenassigned.


13/50

ECSSMST10CRev.1

6March2009

13

4.1.3 Availability of and need to develop newtechnologies

This is an assessment carried out jointly by the customer and supplier to

identify the availability of scientific and technological knowhow and the

technologyneeded

to

implement

the

project.

The

result

of

this

assessment,

which canbe a significant cost and scheduledriver, is amajor input to the

assessmentofrequiredresourcesandfacilitiesandtothesubsequenttechnical

andprogrammaticriskassessment.

4.1.4 Availability of and need to reuse existingequipments/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 humanresources, skills and technical facilities

This isanassessment carriedoutjointlyby the customerand supplierof the

resources,skillsand facilitiesrequired to implement theproject.The resultof

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

andconstraints,andbalancing thesewith theoutcomeofparagraphs4.1.3 to

4.1.6above.

4.1.8 Project deliverables

The customer has the responsibility for defining the deliverable products,

neededtomeettheprojectinitiatorsmissionstatement,takingintoaccounttheassessmentsnotedinclauses4.1.4to4.1.7above.


14/50

ECSSMST10CRev.1

6March2009

14

4.1.9 Customer requirements and constraints

Customerrequirementsandconstraintsarepreparedbythecustomerbasedon

theoutputs from4.1.2 to4.1.8aboveandput intoa formatsuitable fordirect

application in an invitation to tender (ITT). They address technical and

programmatic requirements, aswell as political, commercial, and industrial

constraints tobe applied to theproject 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

Statementof

work

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 coveredby thebusiness agreement, aswell as the scope of the

supplierstasksrequiredbythePRD.

4.1.11 Project management planThe top levelprojectplan is theprojectmanagementplanwhichdefines the

projectmanagementapproachandmethodologytobeusedthroughoutthelife

cycle of the project, together with an overview of all elements of project

managementdisciplines. It includes thedefinition of the system engineering

and product assurance management approach or provides references to

separatesystemengineeringandproductassuranceplanswhichtogethermake

upthetotalplanningdocumentationusedtoimplementaproject.


15/50

ECSSMST10CRev.1

6March2009

15

4.2 Project organization

4.2.1 Introduction

Theestablishment

of

awell

structured

and

coherent

organizational

structure

for

implementing a project at all levels in the customersupplier chain is a key

factor for ensuring an effective and efficientmanagement approach.At each

levelinthecustomersupplierchainaprojectorganizationcanbebuiltasaself

standing project team containing all necessary disciplines within the team

structureor,moreoften,canbebuiltaroundacoreprojectteamcontainingkey

project functionswithothernecessary functionsbeingprovided fromoutside

theprojectteamasexternalsupport.

Irrespectiveoftheorganizationalapproachfollowedforaproject,theelements

summarizedbelowarerelevantatalllevelsinthecustomersupplierchain.

4.2.2 Organizational structure

Itisessentialthattheprojectorganizationalstructureisarrangedtoincludeall

disciplines essential to implement the projectwithwelldefined functions as

wellasclearreportinglines,interrelationshipsandinterfaces.Allprojectactors

below the top levelcustomerandabove the lowest level supplier(s)have the

roles of suppliers and customers, and their organizational structures are

constructedtoaccommodatebothroles.

Theorganizationalstructureprovidesaclearandunambiguousdefinitionand

allocationof individual roles and responsibilities togetherwith thenecessary

authority to implement these within the internal project setup as well astowardsprojectexternalinterfaces.

4.2.3 Communication and reporting

Effectivemeans of communication are essential tools for ensuring clear and

efficient interactionbetweenallprojectactors,aswellasbetween theproject

teamand itsexternal interfaces. Information technology is theprimarymeans

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.


16/50

ECSSMST10CRev.1

6March2009

16

4.3 Project breakdown structures

4.3.1 Introduction

Projectbreakdown

structures

provide

the

basis

for

creating

acommon

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 thedifferentelementsofa systemorproduct.

More details about the specification tree are given in ECSSEST10,

specificationtreeDRD.

4.3.4 Product tree

Theproduct

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

developmentmodels, theGSE, the integration tools and test equipment, and

externalitemsnecessarytovalidatetheendproductandILSitems.Itincludes

itemssubmittedtocustomerconfigurationcontrolanditemsthatarethesubject

ofa technicalrequirementsspecification.Theproduct tree forms thebasis for

theelaborationoftheprojectworkbreakdownstructure.

AnexampleofaproducttreeisshowninFigure41.


17/50

ECSSMST10CRev.1

6March2009

17

SpaceSystem

Space Segment Ground Segment

PayloadPlatform GSEMission Control

CenterPayload Control

CenterCommunications

System

Structure

Thermal control

On-board power

supply

Attitude control

Data handling

Instrument 1 MGSE

EGSEInstrument 2

Instrument 3

Figure41:Producttreeexample

4.3.5 Work breakdown structure (WBS)

TheWBS istheprincipalstructureusedinmanagingaprojectandprovidesa

framework formanaging cost, schedule and technical content. Itdivides the

project intomanageableworkpackages,organizedaccording to thenatureof

theworkbybreaking down the totalwork tobe performed into increasing

levelsofdetail.

TheWBS is derived from the product tree, selected elements ofwhich are

extended to includesupport functions (i.e.management,engineering,product

assurance)andassociatedservices(e.g.testfacilities).

AnexampleofaWBSisshowninFigure42.


18/50

ECSSMST10CRev.1

6March2009

18

Figure42:WBSexample

4.3.6 Work package (WP)

AWP canbe any element of theWBSdown to the lowest level that canbe

measuredandmanagedforplanning,monitoring,andcontrol.

Controlworkpackagesare identifiedby the supplierat the level in theWBS

where visibility and control is required, and for which reporting is to be

performed.Thecontrolworkpackagesrepresent thetotalworkscopeandare

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 organizationbreakdown

structure,whichdepictsthefunctionalaspectsofthecompany.TheprojectOBS

shows the keypersonnel and the assigned responsibleparties for eachwork

packageintheWBS.


19/50

ECSSMST10CRev.1

6March2009

19

4.4 Project phasing

4.4.1 Introduction

Thelife

cycle

of

space

projects

is

typically

divided

into

7phases,

as

follows:

Phase0 Missionanalysis/needsidentification

PhaseA Feasibility

PhaseB PreliminaryDefinition

PhaseC DetailedDefinition

PhaseD QualificationandProduction

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


20/50

ECSSMST10CRev.1

6March2009

20

Phases0,A,andBarefocusedmainlyon

the elaboration of system functional and technical requirements and

identificationofsystemconcepts tocomplywith themissionstatement,

takingintoaccountthetechnicalandprogrammaticconstraintsidentified

bytheprojectinitiatorandtoplevelcustomer.

theidentificationofallactivitiesandresourcestobeusedtodevelopthe

spaceandgroundsegmentsoftheproject,

theinitialassessmentsoftechnicalandprogrammaticrisk,

initiationofpredevelopmentactivities.

PhasesCandDcompriseallactivitiestobeperformedinordertodevelopand

qualifythespaceandgroundsegmentsandtheirproducts.

PhaseEcomprisesallactivitiestobeperformedinordertolaunch,commission,

utilize,andmaintaintheorbitalelementsofthespacesegmentandutilizeand

maintain

the

associated

ground

segment.

PhaseFcomprisesallactivities tobeperformed inorder to safelydisposeall

productslaunchedintospaceaswellasgroundsegment.

Eachoftheaboveprojectphasesincludesendmilestonesintheformofproject

review(s), theoutcomeofwhichdetermines readinessof theproject tomove

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 theAR are typically carried outby 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 sequenceof reviews is reversed to bottomup, startingwith the lowest

level supplier and its customer and continuing up through the customer

supplierchaintothe1stlevelsupplierandthetoplevelcustomer.Thissocalled

VmodelisillustratedinFigure44.


21/50

ECSSMST10CRev.1

6March2009

21

Figure44:Reviewlifecycle

4.4.2 Relationship between business agreementsand project phases

Abusinessagreementcancoverasingleprojectphase,asequentialgroupingof

projectphasesorsubphases(e.g.phaseB1/phaseB2;phaseB2/phaseC1/phase

C2),dependingonsuch factorsas fundingavailability,competitive tendering,

schedule, perceived risk. Irrespective of the approach used for defining the

scope of individualbusiness agreements, all spaceprojects essentially follow

theclassicalprojectphases insequenceand includeallof themajorobjectives

andkeymilestonesofeachofthesephases.

4.4.3 Project phases

4.4.3.1 GeneralThe clause 4.4.3 provides an introduction and overview of the typicalmajor

tasks,associatedreviewmilestones,andreviewobjectivesforeachofthephases

inaprojectlifecycle.

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

customerandrepresentativesoftheendusers.


22/50

ECSSMST10CRev.1

6March2009

22

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 andmission operating constraintswith

respecttothephysicalandoperationalenvironment.

Developthepreliminarytechnicalrequirementsspecification.

Identifypossiblemissionconcepts.

Performpreliminaryassessmentofprogrammaticaspects supportedby

marketandeconomicstudiesasappropriate.

Performpreliminaryriskassessment.

4.4.3.2.3 Associated review

Themissiondefinitionreview(MDR)isheldattheendofphase0.

Theoutcome

of

this

review

is

used

to

judge

the

readiness

of

the

project

to

move

intophaseA.

4.4.3.2.4 Main review objective(s)

Theprimary objective of this review is to release themission statement and

assess thepreliminary technical requirements specificationandprogrammatic

aspects.

4.4.3.3 Phase A (Feasibility)

4.4.3.3.1 Overview

This ismainly an activity conductedby the top level customer and one or

several first level supplierswith the outcomebeing reported to the project

initiator,andrepresentativesoftheendusersforconsideration.

4.4.3.3.2 Major tasks

Establish the preliminarymanagement 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.


23/50

ECSSMST10CRev.1

6March2009

23


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 Phase B (Preliminary definition)


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 agreementdocuments.

Initiatepredevelopmentworkoncritical technologiesorsystemdesign

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.


24/50

ECSSMST10CRev.1

6March2009

24

4.4.3.4.2 Associated reviews

Thereare2projectreviewsassociatedwithPhaseB.

Thesystemrequirementsreview(SRR)heldduringthecourseofPhaseB.

Thepreliminarydesign review (PDR)held at the end of PhaseB.The

outcomeof this review isused tojudge the readinessof theproject tomoveintoPhaseC.

4.4.3.4.3 Main review objectives - System requirements review


Releaseofupdatedtechnicalrequirementsspecifications.

Assessmentofthepreliminarydesigndefinition.

Assessmentofthepreliminaryverificationprogram.

4.4.3.4.4 Main review objectives Preliminary design reviewTheprimaryobjectivesofthisrevieware:

Verification of the preliminary design of the selected concept and

technicalsolutionsagainstprojectandsystemrequirements.

Releaseoffinalmanagement,engineeringandproductassuranceplans.

Releaseofproducttree,workbreakdownstructureandspecificationtree.

Releaseoftheverificationplan(includingmodelphilosophy).

4.4.3.5 Phase C (Detailed definition)


The scope and typeof tasksundertakenduring thisphase aredrivenby the

modelphilosophyselectedfortheproject,aswellastheverificationapproach

adopted.

Completionofthedetaileddesigndefinitionofthesystematalllevelsin

thecustomersupplierchain.

Production,developmenttestingandprequalificationofselectedcritical

elementsandcomponents.

Productionand

development

testing

of

engineering

models,

as

required

bytheselectedmodelphilosophyandverificationapproach.

Completionofassembly,integrationandtestplanningforthesystemand

itsconstituentparts.

Detaileddefinitionofinternalandexternalinterfaces.

Issueofpreliminaryusermanual.

Updateoftheriskassessment.


Thecritical

design

review

(CDR)

is

held

at

the

end

of

phase

C.

The

outcome

of

thisreviewisusedtojudgethereadinessoftheprojecttomoveintophaseD.


25/50

ECSSMST10CRev.1

6March2009

25

4.4.3.5.3 Main review objectives

Assessthequalificationandvalidationstatusofthecriticalprocessesand

theirreadinessfordeploymentforphaseD.

Confirmcompatibilitywithexternalinterfaces.

Releasethefinaldesign.

Releaseassembly,integrationandtestplanning.

Releaseflighthardware/softwaremanufacturing,assemblyandtesting.

Releaseofusermanual.

4.4.3.6 Phase D (Qualification and production)


Completequalificationtestingandassociatedverificationactivities.

Complete manufacturing, assembly and testing of flight

hardware/softwareandassociatedgroundsupporthardware/software.

Complete the interoperability testing between the space and ground

segment.

Prepareacceptancedatapackage.


Thereare3projectreviewsassociatedwithphaseD

Thequalificationreview(QR)heldduringthecourseofthephase.

Theacceptancereview(AR)heldattheendofthephase.Theoutcomeof

thisreviewisusedtojudgethereadinessoftheproductfordelivery.

Theoperationalreadinessreview(ORR),heldattheendofthephase.

4.4.3.6.3 Main review objectives Qualification review


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.

Wheredevelopment encompasses theproduction of one or several recurring

products,theQRiscompletedbyafunctionalconfigurationverificationduring

which:

The first article configuration is analyzed from the viewpoint of

reproducibility.

Theproductionmasterfilesfortheseriesproductionsarereleased.

Theseriesproductiongoaheadfileisacceptedbythecustomer.


26/50

ECSSMST10CRev.1

6March2009

26

4.4.3.6.4 Main review objectives Acceptance review


To confirm that the verification process has demonstrated that the

product is free of workmanship errors and is ready for subsequent

operationaluse.

Toverify that theacceptanceverificationrecord iscompleteat thisand

alllowerlevelsinthecustomersupplierchain.

To verify that all deliverable products are available per the approved

deliverableitemslist.

Toverify theasbuiltproductand itsconstituentcomponentsagainst

therequiredasdesignedproductanditsconstituentcomponents.

Toverifytheacceptabilityofallwaiversanddeviations.

ToverifythattheAcceptanceDataPackageiscomplete.

Toauthorizedeliveryoftheproduct.

Toreleasethecertificateofacceptance.

4.4.3.6.5 Main review objectives - Operational readiness review(ORR)


Toverifyreadinessoftheoperationalproceduresandtheircompatibility

withtheflightsystem.

Toverifyreadinessoftheoperationsteams.

Toacceptandreleasethegroundsegmentforoperations.

4.4.3.7 Phase E (Operations/utilization)


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.


27/50

ECSSMST10CRev.1

6March2009

27


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 flightreadinessreview isconductedprior to launch.Theobjectiveof this

reviewistoverifythattheflightandgroundsegmentsincludingallsupporting

systemssuchas trackingsystems,communicationsystemsandsafetysystems

arereadyforlaunch.

4.4.3.7.4 Main review objectives - Launch readiness review (LRR)

Thelaunchreadinessreviewisconductedjustpriortolaunch.Theobjectiveof

this review is todeclare readiness for launchof the launchvehicle, 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 isheld at the endof the commissioning as

partof the inorbitstageverification. Itallowsdeclaring readiness forroutine

operations/utilization.

This Review is conducted following completion of a series of onorbit tests

designed to verify that all elements of the system areperformingwithin 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 Phase F (Disposal)


Implementthedisposalplan.


Themissioncloseoutreview(MCR)isheldattheendofthisphase.

4.4.3.8.3 Main review objectives

Toensurethatallmissiondisposalactivitiesareadequatelycompleted.


28/50

ECSSMST10CRev.1

6March2009

28

4.4.4 Project specific reviews

Inadditiontotheprojectreviewsidentifiedabove,anddependingonthetype

ofproject, the applicablebusiness agreement and theoverall implementation

approachadopted,additionalreviewscanbeinsertedintotheprojectplanning

againstagreedsubmilestones/additionalmilestones tomeetparticularproject

needs.

Typicalexamplesofsuchreviewsare:

Detaileddesignreview (software specific review,addressed inECSSE

ST40)

Inorbitoperationsreview(addressedinECSSEST70)

Firstarticleconfigurationreview(serialproductionspecificreview)

Systemdesignreview

Systemqualificationreviewatgroundlevel(launcherspecificreview)

Systemqualificationreviewatflightlevel(launcherspecificreview)

Thesereviewsarenotfurtheraddressedinthisstandard.


29/50

ECSSMST10CRev.1

6March2009

29

5Requirements

5.1 Project planning

5.1.1 Overview

Projectplanningrequirementsareapplicabletoallactorsofaprojectfromthe

top levelcustomerdown tothe lowest levelsupplier.Projectactorswhohave

theroleofacustomerandasuppliercarrytheresponsibilitiesassociatedwith

bothroles.Thescopeanddetailofrequirementsmadeapplicableisafunction

ofthelevelofeachactorinthecustomersupplierchain,withthefullscopeof

all requirementsapplicable to the top level supplier.Theoverall scopemade

applicable reduces, down through the customersupplier chainbutbecomes

morespecificasa functionof theroleplayedbyeachof theseactorsand the

typeofproduct(s)tobedevelopedanddeliveredbythem.

5.1.2 Requirements on customers

a. Each customer shall prepare business agreements (ITTs, RFPs, or

RFQs),includingtheprojectrequirementsdocuments(PRD)tobemade

applicablebetweenhimandhissupplier(s).

b. Each customer shall use the ECSS standards to establish the project

management, engineering and product assurance requirements

applicablefortheproject.

c. Eachcustomershallmakeapplicable tohissupplier(s)only thoseECSS

standardsrelevant to the typeandphase(s)of theprojectaddressedby

thebusiness

agreement.

d. Each customer shall specify by tailoring the minimum requirements

within theapplicable standardsnecessary forhis supplier(s) toachieve

theprojectobjectives.

e. Each customer shall approve the projectmanagement plans and key

personnelofhissupplier(s).

f. Eachcustomershallverifycomplianceofhissupplier(s)withallproject

requirementsandconstraints.

g. Each customerbelow the top level customer in the customersupplier

chain

shall

in

addition

ensure

that

planning

for

his

suppliers

is

consistent

withtheplanningrequirementsimposedonhimbyhiscustomer.


30/50

ECSSMST10CRev.1

6March2009

30

5.1.3 Requirements on suppliers

a. Each supplier in the customersupplier chain shall prepare a project

managementplan(PMP)inconformancewithAnnexA.

b. EachsupplierinthecustomersupplierchainshallsubmitthePMPtohis

customerforapproval.

5.2 Project organization

5.2.1 Organizational structure

5.2.1.1 Requirements on customers and suppliers

a. Each customer and supplier shall define the authority for project

managementandbusinessagreementsigning.

b. If theprojecthas linkswithotherprojects,eachcustomerand supplier

shall define the responsibilities relating to the definition and the

managementofinterfaces.

c. Whereacustomer,orsupplier,employsconsultantsorotherspecialists

toassisthiminperforminghisduties,thentheroles,responsibilitiesand

authorityoftheseconsultantsandspecialistsshallbedefined.

d. When a customer supplies a product to a supplier he shall have the

responsibilityofasupplierinrespectofthatproduct.

5.2.1.2 Requirements on suppliers

a. Thesuppliershallsetuptheprojectmanagementorganizationinsucha

waythatadequateresourcesareallocatedtotheprojecttoensuretimely

completionofthebusinessagreement.

b. Thesuppliershallnominateaprojectmanagerwithaprojectteamunder

hisauthorityandreportingdirectlytohim.

c. The supplier shallensure that theprojectmanagerhas theauthority to

executealltasksneededunderthebusinessagreementwithdirectaccess

to his company management hierarchy to resolve conflicts at the

appropriatelevel.

d. Thesuppliershallidentifythekeypersonneltobedeployedonthework,

andincludethemintheprojectorganization.

e. Thesuppliershalldemonstratethatthekeypersonnelhavethenecessary

qualification,skillsandexperiencetoperformthetaskforwhichtheyare

allocated.

f. Thesuppliersprojectmanagementorganizationshallexerciseanactive

monitoringandcontrolover itsownand lower tiersuppliersactivities

and lead its lower tier suppliers in the execution of subcontracted

activitiesto

ensure

that

their

services

conform

to

the

customers

requirements.


31/50

ECSSMST10CRev.1

6March2009

31

g. Ifasupplierisresponsibleformorethanonebusinessagreementwithin

a project, and thebusiness agreements have different customers, then

eachbusiness agreement shallbe clearly identified and accomplished

accordingtotheappropriaterelationships.

h. The first levelsuppliershallestablish,maintainanddistributeaproject

directoryincludingkeypersonnel,asaminimum.

5.2.2 Communication and reporting

5.2.2.1 Requirements on customers and suppliers

a. Thetoplevelcustomershall:

1. specifyareportingsystemfortheproject;

2. specifyanactionmonitoringsystemfortheproject.

b. Each customer and supplier in the customersupplier chain shall

implement and maintain the project reporting an action monitoring

systems.

c. Formalmeetingsbetweenthecustomerandhissupplier(s)shallbeheld

toreviewprogressagainstapprovedprojectplanningandaddressmajor

deviationsorchangesproposedtotheprojectrequirementsdocuments.

d. The frequency, location and schedule of customersupplier project

meetingsshallbeagreedbyallparticipatingparties.

e. Customersuppliermeetingsshallbebasedonanagreedwrittenagenda.

f. Achairpersonandsecretaryshallbedesignatedat thebeginningof themeeting.

g. The resultsof themeeting shallbedocumented in the agreedminutes

signedbyallpartiesinvolvedinthemeeting.

h. Agreedactionsshallbedocumentedinanactionitemlist.

i. Eachactionshallbeallocated

1. auniqueidentification,

2. theidentificationoftheorigin(e.g.meeting),

3. theinitiator,

4. thedescriptionoftheaction(clearandconcise),

5. thepersonresponsiblefortheaction,

6. thecloseoutdate,

7. thecurrentstatus,and

8. thecloseoutreference(e.g.document,letter).

j. Actionitemsshallbereviewedateachmeeting.

k. Anymattersdocumentedintheminutesofmeetinghavingimpactonthe

businessagreementshallbesubjecttothecontractchangeprocedureforimplementation.


32/50

ECSSMST10CRev.1

6March2009

32


a. Thesuppliershallprepareandsubmitprogressreportstohiscustomerin

conformancewithAnnexE.

b. Thesuppliershallprepareminutesofprogressmeetingsforapprovalof

thecustomer.

c. 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 Audits

5.2.3.1 General requirementsa. Every audit performed shallbe followedby a report preparedby the

auditorandcontainingtheviewsofbothparties.

b. Theconclusionsoftheauditandthedraftreportshallbediscussedwith

thesupplier,beforefinalizationandrelease.

c. In the event of disagreement with any of the audit conclusions, the

suppliermayaddhisobservationsandcomments.

d. Thefinalauditreportshallnotbedivulgedwithouttheagreementofthe

auditedsupplier.

5.2.3.2 Requirements on customers

a. Thecustomershallnotifythesupplierinduetimeof

1. hisintentiontoperform anaudit;

2. theobjectivesandthescopeoftheaudit;

3. thedesignatedauditorandhistermsofreference;

4. theauditschedule.


a. The supplier shall accept tobe auditedby the customer orby a third

partyagreedbetweenthecustomerandthesupplierintheframeworkof

thebusinessagreement.

b. Thesuppliershallhavetherighttodemandthattheauditbeperformed

byathirdparty,andthatthethirdpartyobtainauthorizationeachtime

theauditnecessitatesaccess to information concerningpatent rightsor

confidentialityassociatedwithdefencesecrecy.

c. Thesuppliershallperformauditsofhisownprojectactivitiesandofthe

projectactivitiesofhislowertiersupplier(s)toverifyconformancewith

project

requirements.


33/50

ECSSMST10CRev.1

6March2009

33

d. The supplier shall provide right of access for participation by the

customerinhisownauditsandinauditsofhislowertiersuppliers.

e. Thesuppliershallprovidehiscustomeraccess tohis facilitiesanddata

whicharerelevantintheframeofthebusinessagreement.

5.3 Project breakdown structures

a. Thesuppliershalldeveloptheproducttreeforhisproductsdowntothe

deliverable end items, incorporating the product trees of each of his

lowertiersuppliers,inconformancewithAnnexB.

b. TheproducttreeshallbeestablishedatstartofphaseBandfinalizednot

laterthanPDR.

c. The rules for product item identification shallbe uniformwithin the

project.

d. Auniqueidentificationshallbeassignedtoeachitemwithintheproduct

tree.

e. The identification shall remainunchangedduring theproduct lifetime,

unlessamodificationcausesdiscontinuationofinterchangeability.

f. Theproducttreeshallbesubjecttocustomerapproval.

g. The supplier shall maintain the product tree uptodate under

configurationcontrol.

h. Thesuppliershallestablishtheworkbreakdownstructure(WBS)forhis

workshare,incorporatingtheWBSofeachofhislowertiersuppliers,in

conformancewithAnnexC.

i. Work related to manufacturing, assembly, integration and test of all

productmodelsshallbeshownintheWBS.

j. Support functions (management, engineering, product assurance) shall

beidentifiableinconnectionwithitsrelatedproducttreeelements.

k. TheWBSshallbesubjecttocustomerapproval.

l. EachsuppliershallmaintainuptodatetheWBSforhisworkshareinthe

project.

m. Thesupplier

shall

identify

control

work

packages

based

on

the

approved

WBS,andthelevelofvisibilityrequiredbythecustomer.

n. The supplier shall establishwork package (WP) descriptions for each

workpackageshowninhisWBSinconformancewithAnnexD.

o. EachWPshallhaveasingleresponsibleWPmanager.

p. The supplier shallestablishaprojectorganizationbreakdown structure

(OBS),whichincludes.

1. theinterfaceandcontractualresponsibilitiesamongsttheinvolved

parties

2. thekey

personnel

and

the

assigned

responsible

parties

for

each

workpackageintheWBS


34/50

ECSSMST10CRev.1

6March2009

34

q. TheprojectOBSshallbesubmittedtothecustomerforapproval.

r. The supplier shallmaintain theapprovedOBS,keep ituptodate, and

issueittothelowertiersuppliersandthecustomer.

5.4 Project phasing

a. The customer shall organize the project into sequential phaseswhich

includeallprojectspecificreviewsanddecisionmilestones.

NOTE Phasesandreviewsaredefinedinclause4.4.3.

b. The customer shall prepare project review procedures for all project

reviews.

c. Thecustomershallensurethattheprojectreviewsofhissupplier(s)are

in linewith the topdown /bottomup sequence of the overall project

reviewplanning.

d. Thecustomershalltakethedecisiontomovefromonephasetothenext

onthebasisoftheoutcomeoftheassociatedendofphasereview.

NOTE1 Information concerning the expected delivery of

ECSSmanagementbranchdocumentsper review

isprovidedinAnnexF.

NOTE2 Information concerning additional documents

whicharedefinedasoutputsof themanagement

standardsrequirementsandwhicharenotpartof

reviewdatapackagesisprovidedinAnnexG.


35/50

ECSSMST10CRev.1

6March2009

35

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

ThePMP isprepared tostate thepurposeandprovideabrief introduction to

theprojectmanagementsystem.Itcoversallaspectsofthelatter.

A.2 Expected response

A.2.1 Scope and content

Introduction

a. ThePMP shall contain adescription of the purpose, objective and the

reasonprompting itspreparation(e.g.programorprojectreferenceand

phase).

Applicableandreferencedocuments

a. The PMP shall list the applicable and reference documents used insupportofthegenerationofthedocument.

Objectivesandconstraintsoftheproject

a. ThePMPshallbrieflydescribetheobjectiveandconstraintsoftheproject

inconformancewiththeprojectrequirementsdocuments.

Projectorganization

a. The PMP shall describe the project organization approach in

conformancewith

the

requirements

as

defined

in

clause

5.2.


36/50

ECSSMST10CRev.1

6March2009

36

Projectbreakdownstructures

a. The PMP shall describe the projectbreakdown structures approach in

conformance with the project breakdown structure requirements as

definedinclause5.3andidentifythetitleofindividualdocumentscalled

upbytheserequirements.

Configuration,informationanddocumentation

management

a. The PMP shall describe the configuration, information and

documentation management approach, as defined in ECSSMST40,

AnnexA.

b. If the configuration, information and documentation management

approach is contained in a rolledout configurationmanagement plan,

thePMPmayincludeonlyabriefdescriptiontogetherwithareferenceto

theconfiguration,informationanddocumentationmanagementplan.

Costandschedulemanagement

a. ThePMPshalldescribethecostandschedulemanagementapproach,as

definedinECSSMST60.

b. If thecostandschedulemanagementapproach isdescribed inarolled

out cost and schedulemanagementplan, thePMPmay includeonly a

brief description together with a reference to the cost and schedule

managementplan.

Integratedlogisticsupport

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

definedinECSSMST70.

Riskmanagement

a. ThePMPshallbrieflydescribe theriskmanagementapproachwhich is

describedinmoredetailinarolledoutriskmanagementpolicyandplan,

asdefinedinECSSMST80,AnnexesAandB.

Productassurancemanagement

a. The PMP shall describe the product assurancemanagement approach,

includingtheproposedbreakdownintoPAdisciplinesandtheinterfaces

betweenthesedisciplines,asdefinedinECSSQST10,AnnexA.

b. Iftheproductassurancemanagementapproach isdescribed inarolled

outPAplan,thePMPmayincludeonlyabriefdescriptiontogetherwith

areferencetotheproductassuranceplan.


37/50

ECSSMST10CRev.1

6March2009

37

Engineeringmanagement

a. The PMP shall describe the engineering management approach,

including theproposedbreakdown intoengineeringdisciplinesand the

interfaces between these disciplines, as defined in ECSSEST10,

AnnexD.

b. If the engineeringmanagement approach is described in a rolledout

systemengineeringplan, thePMPmay includeonlyabriefdescription

togetherwithareferencetothesystemengineeringplan.

A.2.2 Special remarks

None.


38/50

ECSSMST10CRev.1

6March2009

38

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,

thehierarchicalpartitioning of adeliverableproductdown to a level agreed

betweenthecustomerandsupplier.

Theproducttreeispartofthedesigndefinitionfile.Itisthestartingpointfor

selecting configuration items (as specified inECSSMST40) and establishing

the work breakdown structure. It is a basic structure to establish the

specificationtree(asdefinedinECSSEST10).

B.2 Expected response

B.2.1 Scope and content

Introduction

a. Theproduct

tree

shall

contain

adescription

of

the

purpose,

objective

and

the reasonprompting itspreparation (e.g.programorproject reference

andphase).


a. Theproduct treeshall list theapplicableandreferencedocumentsused

insupportofthegenerationofthedocument.

Treestructure

a.

The

product

tree

shall

provide

the

breakdown

of

lower

level

products

constitutingthedeliverableproduct.


39/50

ECSSMST10CRev.1

6March2009

39

b. For each item identified in theproduct tree, the following information

shallbeprovided:

1. identificationcode;

2. itemname;

3. itemsupplier;

4. applicablespecification.

c. Theproduct treeshallbepresentedeitherasagraphicaldiagramoran

indenturedstructurewheretheproduct(i.e.atthetoplevelofthetree)is

decomposedintolowerlevelproducts.

d. Eachproductitemselectedasconfigurationitemshallbeidentifiedinthe

producttree.

e. When recurrent products from previous space projects are used, they

shallbeidentifiedinthetreestructure.

B.2.2 Special remarks

None.


40/50

ECSSMST10CRev.1

6March2009

40

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 formanaging technical content. It assists

projectsactorsin:

conductingtendercomparisonsandbusinessagreementnegotiations;

optimizingthe

distribution

of

work

amongst

the

different

suppliers;

monitoringthescheduleoftheproject.

TheWBS divides the project intomanageablework packages, organizedby

natureofwork.It identifiesthetotalworktobeperformeddowntoa levelof

detailagreedbetweenthecustomerandsupplier.

Information concerning the determination of the appropriate WBS level of

detailisprovidedinECSSMST10,AnnexH.

C.2 Expected response

C.2.1 Scope and contents

Introduction

a. TheWBS shall contain adescription of the purpose, objective and the

reasonprompting itspreparation(e.g.programorprojectreferenceand

phase).


41/50

ECSSMST10CRev.1

6March2009

41


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

supportofthegenerationofthedocument.

Treestructure

a. 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 toproduce the end itemdeliverables (development

and flight models) and the necessary services as appropriate for the

project.

b. 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 levelof

an element and related lowerlevel subordinate

elements.

c. TheWBSshallidentifyallcontrolworkpackages.

d. Thecontrolworkpackagesmaybefurtherbrokendownbythesupplier

inseveralmoredetailedworkpackages.

e. Alldefinedworkpackagestogethershallcoverthetotalworkscope.

f. The WBS shall be presented either as a graphical diagram or an

indenturedstructure.

C.2.2 Special remarks

None.


42/50

ECSSMST10CRev.1

6March2009

42

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 Scope and content

a. TheWPdescriptionshallcontainthefollowingelements:

1. projectnameandprojectphase;

2. WPtitle;

3. uniqueidentificationofeachWPandissuenumber

4. supplierorentityinchargeoftheWPperformance;

5. WPmanagersnameandorganization;

6. supplierscountry;

7. product towhich the tasks of theWP are allocated (link to the

producttree);

8. descriptionoftheobjectivesoftheWP;

9. descriptionofthetasks;

10. listoftheinputsnecessarytoachievethetasks;

11. interfacesorlinkswithothertasksorWPs;

12. listofconstraints,requirements,standards,andregulations;

13. listoftheexpectedoutputs;


43/50

ECSSMST10CRev.1

6March2009

43

14. listofdeliverables;

15. locationofdelivery;

16. starteventidentificationincludingdate;

17. endeventidentificationincludingdate;

18. excludedtasks.

D.2.2 Special remarks

None.


44/50

ECSSMST10CRev.1

6March2009

44

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 Scope and content

a. Theprogressreportshallcontainthefollowinginformation:

1. The project managers assessment of the current situation in

relation to the forecasts and risks, at a level of detail agreed

betweentherelevantactors.

2. The status of the progress of work being performed by the

supplier.

3. Statusandtrendsofagreedkeyperformanceandengineeringdata

parameters.

4. Adverse trends in technical and programmatic performance and

proposalsforremedialactions.

5. Planningforimplementationofremedialactions.

6. Aconsolidatedreportderivedfromthelowertiersuppliersstatus

reports.

7. Progressonallactionssincethepreviousreport.

E.2.2 Special remarksNone.


45/50

ECSSMST10CRev.1

6March2009

45

Annex F (informative)ECSS management branch documents

delivery per review

TableF1provides the information concerning theexpecteddeliveryofECSS

managementbranchdocumentsperreview.

NOTE This table constitutes a first indication for thedata package content at various reviews. The

fullcontentofsuchdatapackageisestablished

as part of thebusiness agreement,which also

defines thedelivery of thedocumentbetween

reviews.

The various crosses in a row indicate the increased levels of maturity

progressivelyexpectedversusreviews.Thelastcrossinarowindicatesthatat

thatreviewthedocumentisexpectedtobecompletedandfinalized.


46/50


47/50

ECSSMST10CRev.1

6March2009

47

Annex G (informative)Management documents delivery

(periodic or incident triggered)

TableG1liststhedocumentswhicharedefinedasoutputsofthemanagement

standardsrequirementsandwhicharenotpartofreviewdatapackages.

TableG1:Managementdocumentsdelivery(periodicor

incidenttriggered)

DocumentTitle DRDref.

Costbreakdownstructure ECSSMST60,AnnexA

Scheduleprogressreport ECSSMST60,AnnexC

CompanyPriceBreakdownForms ECSSMST60,AnnexD

GeographicalDistributionReport ECSSMST60,AnnexE

CostEstimatingPlan ECSSMST60,AnnexF

MilestonePaymentPlan ECSSMST60,AnnexH

InventoryRecord ECSSMST60,AnnexI

CostandManpowerReport ECSSMST60,AnnexJ

OBCPandCBCPforCostReimbursement ECSSMST60,AnnexK

OBCPandCBCPforFixedPrice ECSSMST60,AnnexL

EACandETCforCostReimbursement ECSSMST60,AnnexM

EACforFixedPrice ECSSMST60,AnnexN

ContractChangeNotice ECSSMST60,AnnexO

Changerequest ECSSMST40,AnnexG

Changeproposal ECSSMST40,AnnexH

Requestfordeviation ECSSMST40,AnnexI

Requestforwaiver ECSSMST40,AnnexJ


48/50

ECSSMST10CRev.1

6March2009

48

Annex H (informative)Determination of the appropriate

WBS level of detail

Themainchallengeassociatedwithdevelopingtheworkbreakdownstructure

(WBS)istodeterminethebalancing between theprojectdefinitionaspects

of

the

WBS

and

the

requirements

for

data

collecting

and

reporting.

One

has

tokeep inmind that theWBS isa tooldesigned toassist theprojectmanager

whendecomposingtheprojectonlytothelevelsnecessarytomeettheneedsof

theproject,thenatureofthework,andtheconfidenceoftheteam.

An excessive WBS levels can lead to unrealistic levels of maintenance and

reporting,andconsequentlytoaninefficientandovercostlyproject.Thetheory

thatmoremanagement data equates tobettermanagement control hasbeen

proven false many times over in the last decades when assessing systems

performance.On theotherhand, ifnotdetailedenough itmakes theelement

difficulttomanageortheriskunacceptable.

Among thedifferentquestionsarisingwhendevelopingaWBS,an important

oneis:shouldtheWBSbedecomposedfurther?

Tohelpansweringthisquestion,weproposethefollowinglistofquestions.If

mostof thequestions canbeansweredYES, then theWBSelementanalyzed

should be decomposed. On the contrary, if most of the questions can be

answeredNO, 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 theremore than one individual responsible for theWBS element?

Oftenavariety

of

resources

are

assigned

to

aWBS

element,

aunique

individual is assigned the overall responsibility for the deliverable

createdduringthecompletionoftheWBSelement.

Does theWBS element content includemore than one type of work

processorproducesmorethanonedeliverableatcompletion?

Isthereaneedtoassessthetimingofworkprocessesthatareinternalto

theWBSelement?

Is thereaneed toassess thecostofworkprocessesordeliverables that

areinternaltotheWBSelement?

Are

there

interactions

between

deliverables

within

a

WBS

element

to

anotherWBSelement?


49/50

ECSSMST10CRev.1

6March2009

49

Are there significant time gaps in the execution of thework processes

thatareinternaltotheWBSelement?

DoresourcerequirementschangeovertimewithinaWBSelement?

Are there acceptance criteria, leading to intermediate deliverable(s),

applicablebefore

the

completion

of

the

entire

WBS

element?

Arethereidentifiedrisksthatrequirespecificattentiontoasubsetofthe

WBSelement?

Can a subsetof thework tobeperformedwithin theWBS elementbe

organizedasaseparateunit?


50/50

ECSSMST10CRev.1

6March2009

Bibliography

ECSSSST00 ECSSsystemDescription,implementationand

generalrequirements

ECSSEST10 SpaceengineeringSystemengineeringgeneral

requirements

ECSSEST40 SpaceengineeringSoftwaregeneralrequirements

ECSSE

ST

70

Space

engineering

Ground

systems

and

operations

ECSSMST1001 SpaceprojectmanagementOrganizationand

conductofreviews

ECSSMST60 SpaceprojectmanagementCostandschedule

management

ECSSMST70 SpaceprojectmanagementIntegratedlogistic

support

ECSSMST80 SpaceprojectmanagementRiskmanagement

ECSSQST10 SpaceproductassuranceProductassurance

management

Ecss m St 10c Rev.1(6march2009)

Documents

Transcript of Ecss m St 10c Rev.1(6march2009)