22-26 October 2012 Page 1
Space Project Management
F.J. Fuentes
ITER Project, France
22-26 October 2012
UNAM, Mexico D.F.
22-26 October 2012 Page 2
Course General Outline and Scope
Day 1. Management Principles
• Objectives and Requirements
• Project Management Tools
• Project Phases
• Applicable Standards
Day 2. Project Development
• Lifecycle and workflow
• Requirement and Interface Management
• Project Phases and Deliverables
• Managing Design Reviews
• Standard ECSS-M-ST-10
22-26 October 2012 Page 3
Course General Outline and Scope
Day 3. Configuration Management
• What is Configuration and Configuration Management?
• Baseline Concept and Development
• CM Procedures
• Change control and NCs
• Documentation Management
• Standard ECSS-M-ST-40
Day 4/5. Quality Management
• Quality Plan
• Risk Identification and Analysis
• Risk Mitigation
22-26 October 2012 Page 4
Course Application
Two Examples on Project and Configuration Management
• FRIDA - Near Infrared Integral Field Spectrograph for GTC
http://www.jornada.unam.mx/2012/02/10/ciencias/a02n1cie
• ITER – Experimental Nuclear Fusion Device
http://www.iter.org
The application of PM and CM procedures
22-26 October 2012 Page 5
Project Management
A space project typically comprises a space segment and a ground
segment which are implemented in parallel.
They rely on, and have interfaces with the launch service segment.
These three segments comprise a space system.
Project planning includes all the processes implemented to plan and
execute a Space Project from initiation to completion, in a
coordinated, efficient and structured manner
Standarized procedures are defined to implement processes.
Procedures should ALWAYS be tailored to specific scope/needs of
each project.
Good Management Practices (GMP) should be ALWAYS based on
good equilibrium between requirements compliance, schedule and
cost
22-26 October 2012 Page 6
Key Components in the Mission Statement
• Availability or need to develop new technologies
• Availability of equipment/products that could be reused
• Availability of needed human resources, skills and technical
facilities
• Risk Assessment
• Development approach, based on mission objectives, requirements
and project constraints
• List of Project Deliverables
• Project Requirements Documents (PRD), including Management,
Engineering and Product Assurance Requirements
• Project Management Plan, defining the management approach and
the methodology to be used throughout the life cycle. It should
include
the
System
Engineering
and
Product
Assurance
22-26 October 2012 Page 7
22-26 October 2012 Page 8
22-26 October 2012 Page 9
22-26 October 2012 Page 10
22-26 October 2012 Page 11
22-26 October 2012 Page 12
22-26 October 2012 Page 13
22-26 October 2012 Page 14
WBS
Space System
Space Segment Ground Segment
Payload
Platform GSE Mission Control Center Payload Control Center Communications System Structure Thermal control On-board power supply Attitude control Data handling Instrument 1 MGSE EGSE Instrument 2 Instrument 3 Management tasks Engineering tasks Product Assurance tasks
Support function extensions
22-26 October 2012 Page 15
22-26 October 2012 Page 16
WBS (ITER)
Level 0 of the WBS represents the entire ITER project
Level 1 of the WBS includes the major phases of the ITER project including: Construction, Operation, Deactivation and Decommissioning
The ITER scope of work at Level 2 of the WBS for construction defines the six major subproject areas: the Tokamak Basic Machine, Ancillary Systems, Plant Systems, Buildings and Site, On-Site Assembly, Installation and Pre-Operations, and Project Oversight and Support. Figure 1 depicts Levels 0 – 2 of the ITER Work Breakdown Structure.
22-26 October 2012 Page 17
22-26 October 2012 Page 18
Work Package Description (Frida)
WP Name: System E: Configuration Management WP No. 3.3 Project Phase: Whole Project Duration Ref. Code:
Man Power (hours): Cost (€)
WP Manager: J. Fuentes Dedication (%):
Participants: B. Sánchez
Task Definition and Scope:
The scope of this WP is to produce and maintain the Project Configuration management procedures. Define the procedures to codify the items, describe the objectives and tasks of configuration management.
Inputs:
Information available about other projects GTC Configuration Identification GTC Control Configuration
Task to perform:
Define the procedures to codify the items, describe the objectives and tasks of configuration management, including:
o Documentation Control Procedures o Drawings Control procedures
Produce and maintain the terms glossary of the system
Produce and maintain the project documentation management procedure and tools To carry out the documentation management according to that procedure
Document elaboration
Deliverables:
Configuration Management Plan Document Control Procedure Drawings Control Procedure
22-26 October 2012 Page 19
22-26 October 2012 Page 20
22-26 October 2012 Page 21
22-26 October 2012 Page 22
22-26 October 2012 Page 23
22-26 October 2012 Page 24
22-26 October 2012 Page 25
22-26 October 2012 Page 26
Communication and Reporting
An procedure should be implemented to produce deliverables and reports
under configuration control and disseminate in an efficient and safe way.
Databases accessible through internet should be created, maintained and
updated as the key tool for configuration control. An efficient procedure to
ensure documents identification and maturity control should be
implemented:
22-26 October 2012 Page 27
Project Phases – According ECSS-M-ST-10C
Each Project Phase is a group of activities:
• Defined at System/Product level
• Depending on the specific circumstances of a project and the
acceptance of involved risk (as established in the Project Risk
Assessment), activities can overlap project phases
• Phases are ended by a formal Review that confirm traceability of
performed work with system requirements. Configuration baselines are
established after review completion
22-26 October 2012 Page 28
Project Phases – According ECSS-M-ST-10C
Activities
Phases
Phase 0 Phase A Phase B Phase C Phase D Phase E Phase F
Mission/Function Requirements Definition Verification Production Utilization Disposal MDR PRR SRR PDR CDR QR AR ORR FRR LRR CRR ELR MCR
Life cycle of space projects is typically divided in 7 phases:
• Phase 0 - Mission analysis / needs identification
• Phase A - Feasibility
• Phase B - Preliminary Definition
• Phase C - Detailed Definition
• Phase D - Qualification and Production
• Phase E - Utilization
22-26 October 2012 Page 29
Project Milestones
Activities
Phases
Phase 0 Phase A Phase B Phase C Phase D Phase E Phase F Mission/Function Requirements Definition Verification Production Utilization Disposal MDR PRR SRR PDR CDR QR AR ORR FRR LRR CRR ELR MCR
MDR – Mission Definition Review PRR – Preliminary Req. Review
SRR – System Requirements Review PDR – Preliminary Design Review CDR – Critical Design Review QR – Qualification Review AR – Acceptance Review
ORR – Operational Readiness Review FRR – Flight Readiness Review
LRR – Launch Readiness Review CRR – Commissioning Result Review ELR – End-of-Life Review
MCR – Mission Close-out Review
Activities can overlap phases
Mandatory Baselines under Configuration Control
Each Project Phase includes end milestones in the form of Project Reviews
Milestones determine readiness of the project to move forward to the next phase
22-26 October 2012 Page 30
Phase 0 – Mission Analysis / Needs Identification
Main Activities
• Elaborate the mission statement in terms of identification and characterization of the mission needs
• Develop the preliminary functional and technical requirements
• Identify possible mission concepts
• Preliminary assessment of project management data (organization, cost, schedule)
Associated Review
• Mission Definition Review (MDR)
Main Review Objectives
• Assess the mission statement
• Assess the preliminary technical and functional requirements
NASA Terminology
• Pre-Phase A
22-26 October 2012 Page 31
Phase A – Feasibility
Main Activities
• Establish the preliminary management plan, system engineering plan and product assurance plan for the project
• Update the functional and technical requirements
• Elaborate possible system and operations concepts and system architectures and compare these against the identified needs, to determine levels of uncertainty and risks.
• Assess the technical and programmatic feasibility of the possible concepts by identifying constraints relating to implementation, costs, schedules, organization, operations, maintenance, production and disposal.
• Identify critical technologies and propose pre-development activities
• Propose the system and operations concept and technical solutions, including model philosophy and verification approach, to be further elaborated during Phase B
• Elaborate the risk assessment
Associated Review
• Preliminary Requirements Review (PRR) (NASA Mission Definition Review, MDR)
Main Review Objectives
• Release preliminary management, engineering and product assurance plans
• Release the technical requirements
• Selection of system and operations concept and technical solutions, including model philosophy and verification approach, to be carried forward into Phase B
22-26 October 2012 Page 32
Phase B – Preliminary Definition
Main Activities
• Establish the project management, engineering and product assurance plans
• Establish the baseline master schedule
• Elaborate the baseline cost at completion
• Elaborate the preliminary organizational breakdown structure (OBS)
• Establish the functional and technical requirements
• Establish the technical solutions for the system concept selected in Phase A
• Establish the verification program including model philosophy
• Identify and define external interfaces
• Initiate pre-development work on critical technologies or system design areas when it is necessary to reduce the development risks
• Initiate any long-lead item procurement required to meet project schedule needs
• Prepare the space debris mitigation plan and the disposal plan
• Conduct reliability and safety assessment
• Finalize the PBS and the WBS
22-26 October 2012 Page 33
Phase B – Preliminary Definition
Associated Review
• System Requirements Review (SRR) – during the course of Phase B
• Preliminary Design Review (PDR) – at the end of Phase B
SRR Objectives
• Release updated Technical Requirements
• Assessment of preliminary Design Definition
• Assessment of preliminary Verification Program
PDR Objectives
• Verification of the preliminary design compliance of project/system requirements
• Release of final management, engineering and product assurance plans
• Release PBS and WBS
22-26 October 2012 Page 34
Phase C – Detailed Definition
Main Activities
• Completion of the system detailed design
• Production, development, testing and pre-qualification of selected critical elements and components
• Production and development testing of engineering models, as required by the selected model philosophy and verification approach
• Completion of assembly, integration and test plan for the system and its constituent parts
• Detailed definition of internal and external interfaces
• Issue of preliminary user manual
• Update of the risk assessment
Associated Review
• Critical Design Review (CDR)
Main Review Objectives
• Assess the qualification and validation status of critical processes and their readiness for deployment for Phase D
• Interface assessment
• Release the final design
• Release assembly, integration and test plan
22-26 October 2012 Page 35
Phase D – Qualification and Production
Main Activities
• Complete qualification testing and associated verification activities
• Complete manufacturing, assembly and testing of flight hardware/software and associated ground support hardware/software
• Complete the interoperability between space and ground segments
• Prepare Acceptance Data Package
Associated Review
• Qualification Review (QR) – during the course of Phase D
• Operational Readiness Review (ORR) – at the end of Phase D
• Acceptance Review (AR ) – at the end of Phase D. The outcome of this review is used to jedge the readiness of the product for delivery
QR Objectives
• Confirm that the verification process has demonstrated that the design (including margins) meets the applicable requirements
• Verify the acceptability of all DRs and NCs
ORR Objectives
• Verify readiness of operational procedures
22-26 October 2012 Page 36
Phase D – Qualification and Production
AR Objectives
• Verify that the final product is in agreement with the requirements
• Verify that all deliverable products are available per the approved deliverable items list.
• Verify the “as-built” product and its constituent components against the required “as designed” product and its constituent components.
22-26 October 2012 Page 37
Phase E – Operation/Utilization
Main Activities
• Perform all activities at space and ground segment level in order to prepare the launch.
• Conduct all launch and early orbital operations.
• Perform on-orbit verification (including commissioning) activities.
• Perform all on-orbit operations in order to achieve the mission objectives.
• Perform all ground segment activities in order to support the mission.
• Perform all other ground support activities in order to support the mission.
• Finalize the disposal plan
Associated Review
• Flight Readiness Review (FRR) – prior to launch
• Launch Readiness Review (LRR) – inmediatly prior to launch
• Commissioning Result Review (CRR) – after completion of the on-orbit commissioning activities
22-26 October 2012 Page 38
Phase F – Disposal
Main Activities
• Ensure that all mission disposal activities are adequately completed
Associated Review
22-26 October 2012 Page 39
Management Documents Delivery per Review
Document Title Phase
0 A B C D E F
MDR PRR SRR PDR CDR QR AR ORR FRR LRR CRR ELR MCR
Project management plan X X X
Product tree X X X X X X
Work breakdown structure X X X
Work package description X X X
Schedule X X X X X X X X X
Cost estimate report X X X
Configuration management plan X X X
Configuration item list X X
Configuration item data list X X X X
As-built configuration list X X
Software configuration file X X X X
Configuration status accounting reports X X X X
Risk management policy document X X X X
Risk management plan X X X X
Risk assessment report X X X X X X X X
This table describes the deliverables list per milestone
22-26 October 2012 Page 40
Frida Deliverables Item List at PDR level
Document Tree Document Title Reference Issue Description ODR PDR CDR ARSL APR LAR SAR
Science
Requirements Operational Concepts Definition FR/UR-SC/007 2.C Document describing the FRIDA reference science cases, the high level scientific requirements and the science observing modes
R A
FRIDA Observing Modes FR/UR-SC/137 1.A A Pixel and Spaxel Scales FR/TN-SC/039 2.B Impact of the proposed pixel and spaxel scales on the
image slicer and the spectrograph
I I Signal and Noise Estimates FR/TN-SC/040 2.D This technical note discusses the expected signal, noise
and detection limits
I I The Format of the Image Slicer FR/TN-SC/062 1.B I I Diffraction in the Image Slicer FR/TN-SC/063 1.B I I
Management
PP Project and Management Plan FR/PL-MG/030 2.A This document includes: the organization scheme, the project phases, the WBS structure, the schedule, manpower chart and budget
A
WBS Work Packages Description FR/MG-MG/036 1.A List and detailed description of the project work packages R
System
Requirements FRIDA System Specifications FR/SR-ST/006 1.A FRIDA technical requirements at system level A Architecture System Architecture FR/DD-ST/037 2.A General description of FRIDA design at system level. This
is the first contact with the instrument, giving a general overview of its configuration and the tracing of requirements to subsystem specification
R A
Configuration Configuration Management Plan FR/PL-ST/002 1.C Definition of configuration items and management procedures
I Documentation Control Procedure FR/PR-ST/003 2.E Documents control procedure I Drawings Control Procedure FR/PR-ST/004 1.B Drawings control procedure I Deliverable Items List FR/CM-ST/013 1.A This document A QA Risk Analysis and Mitigation Plan FR/PL-ST/065 1.A Including a list of the proposed prototypes needed to
mitigate the risk
22-26 October 2012 Page 41
Design Review Procedure
Design reviews are an integral part of the systems engineering process and are
conducted to:
• Assess whether the proposed solution meets the design input requirements
• Assess whether the proposed solution is the most robust, efficient and effective solution to
• achieve the product requirements
• Provide recommendations as required for achieving the design input requirements
• Assess the status of the design in terms of the completeness of the drawings and specifications
• Assess the evidence to support the verification of the design performance
• Verify the proper development, establishment, and control of the configuration baseline
22-26 October 2012 Page 42
Design Coordinator
The Design Coordinator has to:
• Prepare the documentation required for the review
• Distribute the required documents including the design review checklist to the members of the review panel at least 2 weeks before the design review meeting
• Prepare a presentation on the different aspects covered by the design review
• Answer to all questions by the review panel members and provide additional clarifications or documents when needed
• Organize the Design Review Meeting
• Prepare the records and minutes
• Follow-up the recommendations by the review panel, execute the actions for which is in charge
• Ensure that all action items are included in the action database
• Ensure that the recommendations are adequately addressed and record the completion of the actions
22-26 October 2012 Page 43
Design Approver
The Approver is the person responsible for approving the design documents and
drawings and authorizing proceeding to the next development phase. The Design
Approver has to:
• Develop a design review checklist
• Approve the design documents and drawings to be reviewed and authorize proceeding to the next development phase
22-26 October 2012 Page 44
Review Panel Chair
The Review Panel Chair is a technical and managerial qualified person not directly
involved in the development of the design of the system to be reviewed. In the design
review the Chair has to:
• Ensure the meeting (or meetings) agenda
• Ensure that participants understand what is required of them
• Ensure that sufficient time is allocated for design review activities
• Ensure that the meeting’s input package is issued to designated persons
• Assign tasks to participants in preparation for meetings
• Chair the design review meeting, moderate the discussions ensuring that the focus stays on the design assessment and that all present may provide their input and try to reach consensus in the review team in case of differences of opinion. If consensus cannot be reached forward minority as well as majority view(s) for decision
• Categorize chits
• Ensure that relevant issues from the meeting are recorded
• Ensure that actions and recommendations from earlier meetings have been satisfactorily addressed and closed, as appropriate
• Review and approve the record of meeting
22-26 October 2012 Page 45
Review Panel Members
The Review Panel members shall be selected considering the type of system or
component to be reviewed, its safety and quality classification, and the scope of the
design review. The members should:
• Have comparable experience and technical competence as the design developers
• Collectively have the breadth of expertise needed to competently review all aspects of the design
• They should be not directly responsible for the design, i.e., are independent from the design
• process
22-26 October 2012 Page 46
Design Review Process
The Design Review Secretary sends the review notification and agenda. The agenda
should state:
• The date, time and venue of the meeting: the capability to accommodate remote participation shall be provided
• The scope and objectives for the design review meeting
• The project name and identification number
• Participants and their functions
• The type and duration of the design review
• The section of the project under review, if appropriate
• The list of topics to be discussed, for example:
• The objectives of the design project
• The description of the design features and performance characteristics of the product
• The design or technical progress to date and problems encountered
• The outstanding issues and future areas of work
• Findings by previous reviews
• The persons who will make presentations
22-26 October 2012 Page 47
Design Review Process
• The Design Coordinator distributes the required documentation; this has to be done
not later than 2 weeks before the design review meeting
• The Design Coordinator prepares presentation materials
• All members of the Review Panel and the other invitees to the Design Review
meeting review the documentation using distributed checklist and indicate
outstanding issues by filling the chit form
• At the end of the review meeting the Review Panel categorizes issues and asks the
Design Coordinator to provide the answer to the actions within a given time
• The Design Coordinator shall review all recommendations of the review panel and
can reject those for which a justification can be provided. All issues derived from
design review are inserted in the action database
• The Design Coordinator shall collect the answers and resolve all Category 1 issues.
Category 2 issues may not be resolved during the design review meeting but shall
require formal tracking
• The Approver authorizes the Design Coordinator to proceed with the next phase of
development
• After receiving the design review report of the chairman and having assessed that
all category 1 chits have been properly addressed by the Design Coordinator, the
Approver declares the design review closed
22-26 October 2012 Page 48
Explaining Configuration
According ISO 10007 (Quality Management Systems – Guidelines for Configuration Management):
A configuration item (CI) is an aggregation of hardware, software, proccesed materials, services,
or any of its discrete portions, that is designated for configuration management and treated as a
single entity in the configuration management process.
A CI is a product component (including hardware subsystems, software packages,
cables or interfaces) that meets the following conditions:
It is well defined by an established set of functional, physical and performance
specifications
It is accepted in accordance with its set of specifications (the baseline)
It can be tested as a unit
Any uncontrolled changes in its specifications can produce severe changes in the
instrument high level performances
22-26 October 2012 Page 49
Explaining Configuration Management
According MIL-STD-973:
Configuration Management (CM), as applied to CIs, is a discipline applying technical
and administrative direction and surveillance over the life cycle of items to:
• Identify and document the functional and physical characteristics of configuration
items
• Control changes to configuration items and their related documentation
• Record and report information needed to manage configuration items effectively,
including the status of proposed changes and implementation status of approved
changes
• Audit configuration items to verify conformance to specification, drawings, interface
control documents, and other contract requirements
CM establishes the procedures to ensure the traceability of the final produced item performances
to the defining specifications, as well as the conformance of the defining documentation with the
final item.
It also enable all the engineering team to use identical data, in the same controlled status, during
the instrument development cycle
22-26 October 2012 Page 50
CM Objectives
• Know at any moment the technical description of a system and its components,
using approved documentation
• Ensure the traceability of the CI performances to the defining specifications
• Facilitate the consistency and control of internal and external interfaces
• Verify that documentation is and remains the exact image of the products it
describes
• Identify the desired configuration and the as-built configuration, in order to
recognize discrepancies detected during production, delivery or operation of the
product
• Enable any user to know the operational capabilities and limitations of each product
item and, in case of variances or non-conformances, to know which items are
affected
• Provide the engineering team with the same technical data, in the same controlled
status, during the instrument development cycle
Configuration Management is a product control function that
provides surveillance through all phases of the product life-cycle
22-26 October 2012 Page 51
Baseline Definition
The set of documents completely describing each CI at each project milestone is called
a
Baseline
When the set of documents related to each CI has been approved it becomes part of the
CI baseline, and it may be considered that the CI in turn has been also formally
accepted at the level defined by the milestone
Configuration Items divide a complex product or system into manageable
segments and components
Configuration Baselines divide the project phases for concept evaluation
(feasibility), development (preliminary definition), design (detailed definition),
production and utilization of a product into manageable segments by defining
specific reference configurations during the life-cycle of a product and
provide agreed departure points for further evolutions
CM is based on the establishment and control of different baselines for each
CI, which in turn are constituted by configuration documentation (documents
and drawings maintained under configuration control)
22-26 October 2012 Page 52
22-26 October 2012 Page 53
CM Tasks
Configuration (or baseline) identification
It includes the following activities:
Select CI s and define their Configuration Documents
Establish means for identifying and codify products and documentation
Establish configuration baselines
Configuration control
It is the process of controlling changes to any approved baseline. Modification of a baseline
shall be made according approved DRs and NCs to ensure its traceability
Configuration verification
It is the process of verifying that resulting CIs conforms to the preceding approved
baselines, and that baseline documentation is current and accurate. Configuration
verification is accomplished by technical reviews at defined milestones
Configuration accounting
It is the task of maintaining, releasing, distributing and storing configuration
documentation. It is based on the management of documents database
22-26 October 2012 Page 54
Configuration Control
It is the process for controlling the evolution or change from agreed baselines
It includes the preparation, justification, evaluation and implementation of engineering
and contractual changes, deviations and non-conformities
Changes shall be formally initiated, assessed and decided based on reported DRs and
NCs. All authorized changes shall be implemented, verified and recorded
All released baseline documentation is subject to configuration control. As such, no
formal change can be generated without an approved baseline
22-26 October 2012 Page 55
Baseline Documents
• A list of documents to be delivered at established project reviews (including
configuration and no-configuration documents) shall be included in the Deliverable
Items List (DIL)
• A detailed list of all the configuration documents approved on each baseline shall be
included in the Configuration Item Data List (CIDL). The CIDL serves as a point of
departure for the control of subsequent performance, design and build changes
• Draft issues of baseline documents can be distributed in earlier phases of the
22-26 October 2012 Page 56
Documentation Management
• Creation and Revision
During this phase the content of a document is established and the documentation
reference is assigned. Configuration control process should be applied to configuration
controlled documents
Document status shall be “In Preparation”
• Review
When the document is complete, it is submitted for review and approval as required. The
review panel either confirms that the content complies with the applicable requirements,
or states the identified discrepancies together with the proposed resolution. In the later
case, the document is returned for incorporation of comments and resolution of
discrepancies.
Document status shall be “In Review”
• Approval and Release
Approval (either in person or by electronic signature), ensures that
a. The document has not been modified after its approval, and
b. The author accept his responsibility for the content
22-26 October 2012 Page 57
Product Assurance Management
The main objective of Product Assurance (PA) is to ensure that space products
accomplish their defined mission objectives in a safe, feasible and reliable way
The management of PA should be fully embedded in the management of the project and
should receive the highest priority from the Organization Management
PA Management should cover the following activities:
• Management of Product Assurance Requirements
• Establish procedures to implement and manage the Quality Plan
• Reliability Management
• Safety Management
• Management of Configuration List for Materials, Components and Processes
(DML, DCL, DPL)
• Software Product Assurance
• Risk Management
• Management of Audits, Critical Items and NCs
• Management of Subcontractors
22-26 October 2012 Page 58
Product Assurance Management
PA should be managed by the PA Manager, by delegation and under the responsibility
of the PM
The PA Manager shall interface with:
• PM
• Risk Manager
• Configuration Manager
• Engineering, Procurement and AIV
• Customers and Subcontractors
The PA Manager shall ensure the qualification programme is defined, approved and
maintained
The PA Manager shall ensure the qualification programme is implemented and the
qualification results are recorded, evaluated and documented
The PA Manager shall ensure the Qualification Status List of the programme items is
maintained
The PA Manager shall review and approve the achieved qualification status
The PA Manager shall approve the product acceptance during the Acceptance Review
(AR)
22-26 October 2012 Page 59
Qualification Status List
A Qualification Status List (QSL) should be issued at Configuration Items (CI) level
The QSL should summarize the status achieved for each CI with respect to the planned
qualification
The QSL should include:
• CI identification
• Manufacturer identification
• Reference to requirement documents
• Reference to qualification plan document
• Qualification Reports
• Qualification Status:
o Qualified
o To Be Qualified
22-26 October 2012 Page 60
Quality Assurance Programme
The Quality Plan shall ensure that:
• All requirements are specified through adequate methods and procedures
• Methods, procedures and tools have been defined and are implemented in order to
prove that each applicable requirement is verified through one or more of the
following methods : analysis, inspection, test, review of design, audits
• For each CI there is a defined and implemented qualification approach
• Adequate controls are established for the procurement of components, materials,
software and hardware items, services
• Fabrication, integration, test and maintenance are conducted in a controlled manner
so that the end item conforms to the applicable baseline
• A NC control system is established and maintained in order to systematically track
and prevent non-conformities
• Quality records are maintained and analysed so that trends can be detected and
reported in time to enable preventive/corrective actions to be taken
• Equipment and tools used for inspecting, measuring and testing project items are
regularly calibrated to ensure their accuracy
• Procedures and instructions are established which provide for the identification,
segregation, handling, packaging, preservation, storage and transportation of all
items
22-26 October 2012 Page 61
Quality Assurance in CM
• The PA Manager shall attend all Boards established to review the suitability for
release of drawings, plans, specifications and procedures
• The PA Manager shall ensure that:
o the as-designed (to-build) status is defined prior to manufacturing
o the as-built documentation is properly defined, identified and maintained in
order to reflect approved modifications
22-26 October 2012 Page 62
Critical Items
The QA function shall contribute to the overall risk management activities by
supporting the identification and risk evaluation of critical items
An item (design, material, part, process or technology) is declared critical when:
• It is new
• It has not been applied or validated on earlier developments
• During previous use it has raised problems which remain unsolved
• It has a very limited useful life
• It is related to instrument single point failures
• It may not perform as expected
• It has a long delivery time or may not become available when needed
• Its failure can affect severely to the instrument planning, cost and/or
22-26 October 2012 Page 63
Control of Critical Items
Items will be initially identified as critical by reviewing the Declared Materials List
(DML), Declared Components List (DCL) and Declared Processes List (DPL)
Each candidate to critical item shall be considered for normal use after proper review
of:
• Item documents and datasheets
• Proposed validation documents and test reports
• Manufacturing capabilities
• Planning
• Alternatives to its use
The remaining items shall be included in a Critical Item List (CIL) that shall be prepared
and maintained by the PA Manager
22-26 October 2012 Page 64
Frida Declared Materials List (DML)
F R ID A D E C LA R E D M A T E R IA LS LIS T G ro u p N o It e m N o P ro d u c t Id e n t if ic a t io n C h e m ic a l N a t u re & T yp e o f P ro d u c t M a n u f a c t u re r P ro c u re m e n t S t a t e P ro c u re m e n t S p e c s . & S t a n d a rd s A c c e p t a n c e D o c s . & T e s t R e p o rt s P ro c e s s in g P a ra m e t e rs Us e a n d Lo c a t io n E n v iro n m . C o d e J u s t if ic a t io n o f Us e A p p ro v a l S o u rc e 1 1 Al 6061-T6 S i 0.4-0.8%, F e 0.7%, C u 0.15-0.4%, M n 0.15%, M g 0.8-1.2%, C r 0.04-0.35%, Zn 0.25%, Ti 0.15%
KAIS ER Alum inum
www.ka is e ra l.c o m R o lle d P la te a nd S he e t
F R /P C -S T/193 , QQ-A-250F , AM S -QQ-A-250/11
C he m ic a l Ana lys is , M e c ha nic a l Te s t & Ultra s o nic Ins pe c tio n vs
S upplie r S pe c ific a tio ns C e rtific a te & Da ta s he e t
M a c hining, C ryo ge nic He a t Tre a tm e nt (a c c o rding F R /TN-S T/089). S urfa c e
finis hing whe n is re quire d
Optic a l B e nc h (AO-F R -C S -100) , Optic s B a rre ls , IF U c o m po ne nts (inc luding m irro rs ), C o ld M e c ha nis m s
V/C He a t tra ta ble . High s tiffne s s /we ight. High m ic ro yie ld s tre ngth. Lo ng-te rm
dim e ns io na l s ta bility. Ve ry go o d m e c ha nic a l & the rm a l pro pe rtie s a t LN2 P re vio us us e 5 1 AIS I 304
C 0.15 %m a x. C r 17.019% Ni8.010% M n 2% m a x S i 1 % m a x P 0.045%
m a x. S 0.03% m a x.
Dis tribuido ra M e tá lic a
www.m e ta lic a .c o m .m x F la t P la te AS TM A-312
C he m ic a l Ana lys is a nd M e c ha nic a l Te s t vs S upplie r
S pe c ific a tio ns C e rtific a te
M a c hining a nd We lding De wa r (AO-F R -C T-200) V/R High s tiffne s , lo w c o s t P re vio us us e 15 1 G10-C R
Gla s s c lo th la m ina te im pre gna te d a nd c ure d with no n bro m ina te d
e po xy re s in
J J OR LY
www.jjo rly.c o m F la t S he e t NEM A G 10, M il 24768/2
S upplie r S pe c ific a tio ns
22-26 October 2012 Page 65
Reliability Management
Dependability analyses shall be performed on all space projects throughout the project
life-cycle
Dependability analyses shall be performed initially to establish the conceptual design,
and the system requirements. Thereafter, the analyses shall be continued to support
the conceptual, preliminary and detailed development and optimisation of the design,
including the testing programme, leading to its qualification
Dependability analyses shall be implemented in order to:
• Ensure that Reliability, Availability and Maintainability requirements are met,
established as:
o Product Life
o Mean Time Between Failures (MTBF)
o Mean Time To Repair (MTTR)
• Identify all potential failure modes and technical risks with respect to functional
needs which can lead to NCs
• Provide risk assessment and risk mitigation in line with the risk management
22-26 October 2012 Page 66
Reliability Analyses
The following analyses shall be used to determine Maintainability and Availability
objectives and tasks:
• Functional Analysis (FA) shall be performed to establish the relative criticality of
each function in the concept under study, in order to establish the reliability
requirements, including those for failure tolerance and software criticality
• From FA function, products and procedures can be classified in functional
categories, depending of the effect of the loss of function or failure of the product or
procedure
• Failure Modes, Effects and Criticality Analysis (FMECA) shall be performed on the
functional and physical design and the processes used to realize the final product .
In all cases the FMECA shall identify how each failure mode is detected.
• All potential failure modes shall be identified and classified according to the severity
of their consequences. Measures shall be recommended in the analysis and
introduced in the product design and in the control of processes to render all such
consequences acceptable to the project.
• Provisions for failure detection and recovery actions (including redundancies) shall
22-26 October 2012 Page 67
Principles of Risk Management
• The objective of Project Risk Management is to identify, assess, reduce, accept, and
control space project risks in a systematic, comprehensive and cost effective
manner
• Risk level for project functions should be identified and assessed throughout the
project life cycle. Risk issues should be accepted or rejected (mitigated) taking into
account the project technical and management constraints
• PM has the overall responsibility for the implementation of Risk Management,
22-26 October 2012 Page 68
Risk Management Process
Task 5: Decide if the risks may be accepted
Step 4
Monitor, communicate and
accept risks
Step 3
Decide and act
Step 2
Identify and assess the risks
Step 1
Define risk management
implementation requirements
Task 1: Define the risk management policy Task 2: Prepare the risk management plan
Task 3: Identify risk scenarios Task 4: Assess the risks
Task 6: Reduce the risks
Task 7: Recommend acceptance
Task 8: Monitor and communicate the risks Task 9: Submit risks for acceptance. (Return to Task 6 for risks not accepted)
R I S K M A N A G E M E N T C Y C L E
At the beginning of the Project
Thr
o
ug
h P
ro
je
c
t L
ife
-Cyc
le
22-26 October 2012 Page 69
Risk Management Implementation
Risk Management shall be implemented through the Risk Management Plan. This
document should cover:
• Identification of issues that could impact the risk
• Establishment of likelihood scoring scheme
• Establishment of scoring scheme for the impact and consequences
• Establishment of risk levels based on likelihood and impact
• Definition of risk acceptance criteria based on risk levels
• Establishment of criteria to determine the required mitigation actions depending on
22-26 October 2012 Page 70
Issues Potentially Impacting the Risk
• Requirements or specifications not clearly defined or not verifiable
• The schedule doesn’t provide enough time to complete the project
• Activities and/or tasks undefined
• Long-term activities are potentially risky because they can produce schedule delays
easily
• Communication is not flowing between working groups
• The project cost exceeds the allocated budget
• There are planned activities at undefined costs
• The deliverables are not clearly defined
• The allocated staff is not suitably skilled to develop all the project tasks at low or no
risk
• The proposed design is non-proven, in the sense it has not been used previously in
other instruments, or it is not well documented
• The proposed concept is very complex
• The internal and external interfaces are not well defined
• The use of non-standard materials
• The use of components not specified for the working conditions
• The use of non-standard manufacturing processes
• It is not well defined the procedure to accept individual components
• The verification procedures are not well defined or are difficult to be performed
• The instrument operation is not possible or it is not well defined
22-26 October 2012 Page 71
Risk Likelihood Scoring Scheme
Score
Likelihood
Likelihood of occurrence
E
Maximum
Certain to occur, will occur one or more times per project
D
High
Will occur frequently, about 1 in 10 projects
C
Medium
Will occur sometimes, about 1 in 100 projects
B
Low
Will seldom occur, about 1 in 1000 projects
22-26 October 2012 Page 72
Risk Impact Scoring Scheme
Score Severity Performance Cost Schedule
1 Negligible Small reduction in performance
Cost increases below 5%
Minor impact on schedule
2 Significant Some reduction in performance
Cost increases from 5 to 15%
Final delivery date slip less than 6
months
3 Major
Technical specifications could
not be achieved
Cost increases from 15 to 30%
Fine delivery date slip between 6 months and one year
4 Critical
Technical
specifications are not achieved
Cost increases over 30%
Final delivery date slip more than one
year
22-26 October 2012 Page 73
Risk Levels
Likelihood Risk Index:
Combination of Severity and Likelihood
E Low Medium High Very High Very High
D Low Low Medium High Very High
C Very Low Low Low Medium High
B Very Low Very Low Low Low Medium
A Very Low Very Low Very Low Very Low Low
1 2 3 4 5 Severity
“Red” “Yellow” “Green”
22-26 October 2012 Page 74
Risk Actions
A Risk Mitigation Plan (RMT) should be established, at least, for the risk events having
High or Very High Levels
A RMT could be also defined for Medium risk events, if it is decided by the Risk
manager (or the PM). Events having Low or Very Low severity are considered not risky
for the project development
Two different kind of actions should be included in the RMP:
• Preventive Actions – that must be taken to reduce the likelihood of risk’s
occurring
• Contingency Actions – that must be taken to reduce the impact should the risk
22-26 October 2012 Page 75
Risk Register (Frida)
FRIDA RISK REGISTER (Management & System Risk)
ID Subsystem Item Risk Event Description of Impact Event Impact Risk Preventive Actions Deadl Contingency Actions Deadl Performed Actions Date Status
1.1 Management Cost
Gloabl cost is not including all project items. Some critical elements (like IFU) have not a detailed estimate of cost
Cost over run up to the estimated
contingency (20%) MODERATE
Cost will be reviewed and updated after project review. Extra funds are requested from national agencies of the involved countries
1.2 Management Schedule Present schedule is not including
the prototypes development Schedule delays MODERATE
Schedule will be reviewed and updated after project review
1.3 Management /
System Manpower and Schedule
Coordination of engineering activities across various institutions
Delays, poor performance,
non-compliances 0.5 0.5 HIGH
Good system engineering practices implemented in the project.
Configuration and interfaces control are critical areas. Management centralized activities and a well defined chain of responsabilites are also critical points
1.4 System Intranet database
Sharepoint documents database could crash due to computer problems or to management errors
Unavailability of project documentation causing project delays
LOW
Computer hardware and sharepoint software is properly maintained and operated. A recovery procedure is implemented and validated
1.5 System Intranet database
More effort needed than currently allocated for database daily maintenance
Updated documentation not
available on line MODERATE
Database will be operated by a dedicated and trained person from the computer department at IA-UNAM
1.6 System Product Assurance
More effort needed than currently allocated for PA/QA (now shared with other system activities)
Insufficient PA/QA control to ensure the instrument development within time, cost and specifications
0.5 0.5 HIGH
A detailed Product Assurance Plan shall be produced and run. More effort shall be assigned to monitor PA/QA activities.
Performed Actions
22-26 October 2012 Page 76
Risk Management Documentation
Two key documents should be established:
• Risk Management Plan, describing the implementation of the risk management
process
• Risk Assessment Report, identifying risk issues, assessing risk impact and
describing mitigation actions (when required)
22-26 October 2012 Page 77
