Space Project Management F.J. Fuentes ITER Project, France 22-26 October 2012 UNAM, Mexico D.F. 22-26 October 2012 Page 1
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 2
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 Standards ECSS-Q-ST-10, ECSS-M-ST-80 22-26 October 2012 Page 3
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 Proyecto satelital Quetzal UNAM-MIT 22-26 October 2012 Page 4
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 5
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 approaches. 22-26 October 2012 Page 6
Mission Objectives 22-26 October 2012 Page 7
Space Mission Analysis and Design Process 22-26 October 2012 Page 8
Top Level Mission Requirements 22-26 October 2012 Page 9
Science Objectives vs. Payload Instrument Matrix 22-26 October 2012 Page 10
Strawman Payload 22-26 October 2012 Page 11
Project Management Tools 22-26 October 2012 Page 12
Project Breakdown Structures 22-26 October 2012 Page 13
WBS Space System Space Segment Ground Segment Platform Payload GSE Mission Control Center Payload Control Center Communications System Structure Instrument 1 MGSE Thermal control Instrument 2 EGSE Management tasks On-board power supply Instrument 3 Engineering tasks Attitude control Product Assurance tasks According ECSS-M-ST-10C Support function extensions Data handling 22-26 October 2012 Page 14
WBS (FRIDA) 22-26 October 2012 Page 15
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 16
Work Package Description 22-26 October 2012 Page 17
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 18
Schedule 22-26 October 2012 Page 19
Gantt Chart 22-26 October 2012 Page 20
Gantt Chart 22-26 October 2012 Page 21
Organizational Chart 22-26 October 2012 Page 22
Integrated Models using Concurrent Engineering 22-26 October 2012 Page 23
Integrated Model Example 22-26 October 2012 Page 24
Cost Estimation 22-26 October 2012 Page 25
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: Frida Documents Controls Database 22-26 October 2012 Page 26
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 Project Phases define the advance of the project between baselines 22-26 October 2012 Page 27
Project Phases According ECSS-M-ST-10C Activities Phases Phase 0 Phase A Phase B Phase C Phase D Phase E Phase F MDR PRR Mission/Function SRR PDR Requirements CDR Definition Verification QR Production Utilization Disposal AR ORR FRR CRR LRR 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 Phase F - Disposal 22-26 October 2012 Page 28
Project Milestones Activities Mission/Function Requirements Definition Verification Production Utilization Disposal Phases Phase 0 Phase A Phase B Phase C Phase D Phase E Phase F MDR PRR Activities can overlap phases SRR PDR CDR QR AR ORR Mandatory Baselines under Configuration Control FRR CRR LRR 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 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 29
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 Mission Concept Review (MCR) 22-26 October 2012 Page 30
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 31
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 Update the risk assessment 22-26 October 2012 Page 32
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 Release the Verification Plan, including Model Philosophy 22-26 October 2012 Page 33
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 Release User Manual 22-26 October 2012 Page 34
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 Accept and release the ground segment for operations 22-26 October 2012 Page 35
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. Verify that the Acceptance Data Package is complete 22-26 October 2012 Page 36
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 End-of-Life Review (ELR) at the completion of the mission 22-26 October 2012 Page 37
Phase F Disposal Main Activities Ensure that all mission disposal activities are adequately completed Associated Review Mission Close-out Review (MCR) 22-26 October 2012 Page 38
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 It should be produced is early development phase (tailored to each project) 22-26 October 2012 Page 39
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 Signal and Noise Estimates FR/TN-SC/040 2.D This technical note discusses the expected signal, noise and detection limits 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 I I 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 A 22-26 October 2012 Page 40
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 Propose improvements 22-26 October 2012 Page 41
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 42
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 Approve the design review report 22-26 October 2012 Page 43
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 Ensure that the meeting s minutes are issued to designated persons 22-26 October 2012 Page 44
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 Review technical aspects of the design in their area of responsibilities 22-26 October 2012 Page 45
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 The list of reference documents and the contents of any attached input data package 22-26 October 2012 Page 46
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 47
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 48
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 CM IS THE MANAGEMENT OF THE TECHNICAL DESCRIPTION OF CIs 22-26 October 2012 Page 49
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 50
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 51
Project Phases and Baseline Definitions 22-26 October 2012 Page 52
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 53
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 54
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 project for information and informal reviews if needed 22-26 October 2012 Page 55
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 At the end of this phase the document reaches the status of Released 22-26 October 2012 Page 56
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 57
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 58
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 o Qualification In-Progress 22-26 October 2012 Page 59
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 60
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 o o the as-designed (to-build) status is defined prior to manufacturing the as-built documentation is properly defined, identified and maintained in order to reflect approved modifications CIs to be delivered comply with the as-built documentation 22-26 October 2012 Page 61
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 performances 22-26 October 2012 Page 62
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 63
Frida Declared Materials List (DML) FRIDA DECLARED MATERIALS LIST Gro up No Ite m No P ro duc t Ide ntific a tio n C he m ic a l N a ture & Type o f P ro duc t M a nufa c ture r P ro c ure m e nt S ta te P ro c ure m e nt S pe c s. & S ta nda rds A c c e pta nc e D o c s. & Te s t R e po rts P ro c e s s ing P a ra m e te rs Us e a nd Lo c a tio n Env iro nm. C o de J us tific a tio n o f Us e A ppro v a l S o urc e 1 1 Al 6061-T6 Si 0.4-0.8%, Fe 0.7%, Cu 0.15-0.4%, Mn 0.15%, Mg 0.8-1.2%, Cr 0.04-0.35%, Zn 0.25%, Ti 0.15% KAISER Aluminum www.kais eral.co m Ro lled P late and Sheet FR/P C-ST/193, QQ-A-250F, AMS-QQ-A-250/11 Chemical Analys is, Mechanical Tes t & Ultras o nic Ins pectio n vs Supplier Specificatio ns Certificate & Datasheet Machining, Cryo genic Heat Treatment (acco rding FR/TN-ST/089). Surface finis hing when is required Optical Bench (AO-FR-CS-100), Optics Barrels, IFU co mpo nents (including mirro rs ), Co ld Mechanis ms V/C Heat tratable. High s tiffnes s /weight. High micro yield s trength. Lo ng-term dimens io nal s tability. Very go o d mechanical & thermal pro perties at LN2 P revious use 5 1 AISI 304 C 0.15 %max. Cr 17.019% Ni8.010% Dis tribuido ra Metálica Mn 2% max Si 1 % max P 0.045% www.metalica.co m.mx max. S 0.03% max. Flat P late ASTM A-312 Chemical Analys is and Mechanical Tes t vs Supplier Specifications Certificate Machining and Welding Dewar (AO-FR-CT-200) V/R High s tiffnes, lo w co s t P revio us us e 15 1 G10-CR Glas s clo th laminate impregnated and cured with no n bro minated epo xy res in J J ORLY www.jjo rly.co m Flat Sheet NEMA G 10, Mil 24768/2 Supplier Specificatio ns Certificate Machining Suppo rt Trus s es (AO-FR-CS-200) V/C High s tiffnes s /weight, lo w heat co nducto r, High Machinability P revio us us e 22-26 October 2012 Page 64
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 o o Product Life Mean Time Between Failures (MTBF) 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 process implemented on the project 22-26 October 2012 Page 65
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 be provided as part of the FMECA. 22-26 October 2012 Page 66
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, ensuring an integrated, coherent approach for all project domains 22-26 October 2012 Page 67
Through Project Life-Cycle Risk Management Process Step 1 Define risk management implementation requirements At the beginning of the Project Task 1: Define the risk management policy Task 2: Prepare the risk management plan Step 2 Identify and assess the risks Step 3 Decide and act Task 3: Identify risk scenarios Task 4: Assess the risks Task 5: Decide if the risks may be accepted Task 6: Reduce the risks Task 7: Recommend acceptance R I S K M A N A G E M E N T Step 4 Monitor, communicate and accept risks Task 8: Monitor and communicate the risks Task 9: Submit risks for acceptance. (Return to Task 6 for risks not accepted) C Y C L E 22-26 October 2012 Page 68
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 risk level 22-26 October 2012 Page 69
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 Maintenance is complex or it is not feasible 22-26 October 2012 Page 70
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 A Minimum Will almost never occur, 1 of 10 000 or more projects 22-26 October 2012 Page 71
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 5 Catastrophic Leads to termination of the project 22-26 October 2012 Page 72
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 73
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 occur 22-26 October 2012 Page 74
Risk Register (Frida) FRIDA RISK REGISTER (Management & System Risk) Summary Description Score Mitigation Plan Performed Actions 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, noncompliances 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 Insufficient PA/QA control to More effort needed than currently ensure the instrument allocated for PA/QA (now shared development within time, cost and with other system activities) 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. 22-26 October 2012 Page 75
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) RISK SHOULD BE CONTINOUSLY ASSESSED THROUGH ALL LIFE CYCLE 22-26 October 2012 Page 76
Applicable Standards ESA Standards ECSS-M-ST-10C Project Planning and Implementation ECSS-M-ST-40C Configuration and Information Management ECSS-M-ST-60C Cost and Schedule Management ECSS-M-ST-80C Risk Management ECSS-Q-ST-10C Product Assurance Management 22-26 October 2012 Page 77