Your SlideShare is downloading. ×
Lawrence.jim
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Lawrence.jim

13,241
views

Published on

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
13,241
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Again note there are three TA areas.
  • All 10 Centers have been looked at once. GSFC has had a second round in Nov 2010. The issues discussed are not being identified as Center, program or project specific.
  • We will discuss the HMTA “road ahead” and the late identification of issues later in the presentation.
  • Survey helped shape policy change - we will see how this difference is addressed in Rev E of 7120.5 later in the presentation. Also titles of TA position differ between Centers.
  • We have seen the Implementation Plans being modified at Centers to include SMA-TA but not HMTA. PMs need to review their Program/Project Plans for alignment with Center TA plans.
  • Only non-compliance outside of SW during initial Surveys. Some PMs did not include the SMA-TA in their “core team” when asked. Staffing concern is that the SMA-TA is stretched too thin and will miss important issue.
  • HMTA findings were written against HQ (not Centers). Another area where the Survey has helped shape policy changes.
  • Many people interviewed thought HMTA was the same as, or related to OSHA.
  • Many people interviewed thought HMTA was the same as, or related to OSHA.
  • Many people interviewed thought HMTA was the same as, or related to OSHA. A few specific exceptions where NASA requirements are more stringent than OSHA are included in HMTA.
  • What does this mean to the Program/Project? NPR 1800.1 – there are some NASA requirements that exceed the OSHA standard – these become HMTA requirements.
  • Looks a lot like Engineering or SMA areas but can also affect the human – therefore also HMTA.
  • EES – went to a Dissenting Opinion at HQ level by OCHMO. SOFIA – flying with door open created acoustic condition that exceeded the NASA requirements.
  • The HMTA system is counting on the program/project TA to raise potential issues so that the proper HMTA personnel can get involved earlier in the process of resolution.
  • Project TA may have to provided additional data, etc to the CMO, JSC, or CHMO if needed to assist in resolution of issue.
  • Project TA may have to provided additional data, etc to the CMO or CHMO if needed to assist in resolution of issue.
  • Prior thinking – Why is the Technical Authority flow for programs different from projects? Why does Headquarters own level 2 (program level) requirements? Answer Multiple centers will be engaged in many programs to take full advantage of the Agency’s human and facility resources. In this multi-center environment having the flow of Technical Authority by-pass the Center Director provides Headquarters the role of adjudicating differences between projects at different Centers. This avoids any concerns about a conflict of interest that might arise if the Center Director of the Host Center adjudicated differences between his/her Center and another Center.   Current view - Based on experience, the original concern related to conflict of interest proved unnecessary. This is part of the expanded role of the CD that in implemented in Rev. E
  • TA role as Systems Engineering lead reflects different implementation seen during OCE Surveys.
  • Residual risk is the remaining risk that exists after all mitigation actions have been implemented or exhausted in accordance with the risk management process. NASA Policy for Safety and Mission Success (NPD 8700.1)
  • Transcript

    • 1. Technical Authority Implementation “Strengths, Weaknesses and Improvements” Jim Lawrence Office of Chief Engineer (Dell Services)
    • 2. Objectives of Session
      • Discuss the strengths and weaknesses in Technical Authority implementation that have been observed during the Office of Chief Engineer (OCE) Surveys at all NASA Centers
      • Look at the “way ahead” to fully implement Health and Medical Technical Authority (HMTA) across the Agency and the potential impact for programs and projects
      • Overview the changes in Technical Authority contained in Revision E of NPR 7120.5
    • 3. Technical Authority Overview
    • 4. Technical Authority Overview
      • NASA has established the technical authority process as part of its system of checks and balances to provide independent oversight of programs and projects in support of safety and mission success through the selection of specific individuals with delegated levels of authority . These individuals are the Technical Authorities .
    • 5. Flow of Technical Authority
      • Technical Authority originates with the Administrator and is formally delegated to the NASA AA and then to the:
        • NASA Chief Engineer for Engineering Technical Authority;
        • Chief, Safety and Mission Assurance for SMA Technical Authority;
        • Chief Health and Medical Officer for Health and Medical Technical Authority;
        • and then to the Center Directors.
    • 6. Key Attributes of Technical Authority
      • Technical Authority delegations are made to selected individuals:
      • Who are funded independent of the Programmatic Authority (includes program or project)
      • Delegations are formal and traceable to the Administrator.
      • Technical Authorities located at Centers:
      • Remain part of their Center organization
      • Performance appraisal is signed by the management of that Center organization
    • 7. Key Attributes of Technical Authority
      • Program or Project Manager responsibilities have not been affected by the implementation of Technical Authority… still ultimately responsible for the safe conduct and successful outcome in accordance with prescribed requirements.
    • 8. Governance Model Separation of Authorities
    • 9. Engineering Technical Authority - NASA Chief Engineer Michael Ryschkewitsch SMA Technical Authority - NASA Chief, Safety and Mission Assurance Bryan O’Connor Health & Medical Technical Authority - NASA Chief Health and Medical Officer Dr. Rich Williams Agency Technical Authorities
    • 10. OCE Survey Results (11 Surveys Completed Covering all Ten NASA Centers)
    • 11.
      • The implementation of Technical Authority (TA) is continuing to evolve since its initial rollout in conjunction with the issuance of NPR 7120.5D (and NID), NPR 7120.8 and other Agency directives.
      • Engineering and Safety and Mission Assurance at the Centers have been successful in embedding TA in the programs/projects.
      • HMTA has not been fully implemented which has led to issues being either missed or identified too late in the life cycle to allow effective design changes.
      Overview
    • 12. Strengths
      • The understanding and implementation of Technical Authority is generally strong in Engineering and SMA.
      • The separation of Programmatic and Technical Authority is well understood.
      • The TA relationship between Projects, Engineering and SMA works very well.
      • The active participation by senior management in implementing the TA governance model is excellent.
    • 13. TA-Engineering Implementation Differences
      • Mission/Lead System Engineer is the TA-Eng
      • Independently funded
      • Leads the Systems Engineering effort on the Project/Program
      • Chief Engineer is the TA-Eng
      • Independently funded
      • Focus on the independent funding and requirements ownership
      • Performs special studies
      • Independent of Systems Engineering functions of the Project/Program
    • 14. Documentation Issues
      • Technical Authority Implementation Plans
      • Many only addressed Engineering TA
      • Need to include SMA-TA and HMTA
      • Program and Project Plans
      • Not aligned with Center Technical Authority Implementation Plan
      • Do not reflect Agency Technical Authority policy in NPR 7120.5D
      • Role of Technical Authority in the adjudication of waivers/deviations is not clearly defined
      • Center Documents
      • Role of Technical Authority in the adjudication of waivers/deviations is not clearly defined
      • Not aligned with the current Program/Project Management and Technical Authority governance model.
    • 15. Software Issues
      • TA-Software responsibilities are not widely understood
      • Unclear Technical Authority delegation for the software engineering responsibilities
      • Lack of functional knowledge of key Technical Authority documents and procedures with respect to software deviations and waivers
      • Awareness of specific Engineering Technical Authority requirements related to software was not prevalent among Lead Discipline Engineers
    • 16. SMA-TA Issues
      • The SMA-TA for a project was not independently funded as required by NPR 7120.5D.
      • The SMA-TA is not always co-located with the Project team. As a result, the project team may not consider the SMA-TA as a core part of the team.
      • SMA-TA must cover multiple projects due to staffing issues.
    • 17. ARMD Issues
      • The roles and responsibilities of the ARMD Technical Authority (HQ) and the relationship to the Center Engineering Technical Authority (Chief Engineer) is not clearly defined or understood.
      • The roles and responsibilities of the Center Chief Engineer as the Engineering Technical Authority for ARMD projects is not clearly defined in Center documentation
    • 18. HMTA Issues
      • Health and Medical Technical Authority is not fully implemented and is not clearly understood.
      • HMTA awareness must be improved.
      • HMTA implementation and training must consider application to Research and Technology programs and projects (NPR 7120.8) in addition to flight programs and projects (NPR 7120.5).
      • SMSR implementation should be examined to include HMTA participation when appropriate.
    • 19. HMTA Implementation
    • 20. HMTA Implementation
      • Health and Medical Technical Authority (HMTA) implements the responsibilities of the Office of the Chief Health and Medical Officer (OCHMO) to assure that Agency health and medical requirements and standards are addressed in program/project management when applicable and appropriate.
      • HMTA provides independent oversight of all health, medical, and crew performance matters that either arise in association with the execution of NASA programs or projects, or are embedded in NASA programs or projects.
    • 21. HMTA Implementation
      • For all program/project management, HMTA encompasses:
        • Health, medical, and crew performance requirements and standards related to human space flight and human rating of space vehicles, systems, and operations. (Note: Issues on Research and Technology (R&T) projects may require HMTA involvement if the output of the R&T project could later be implemented in human space flight).
        • NASA unique occupational health technical standards that are not mandated by external Federal entities (e.g. Occupational Safety and Health Administration).
        • Medical and health issues that arise where there is no NASA unique or Federally mandated health/medical requirement or standard. In such case, program/project management should consult with HMTA to resolve the issue.
    • 22. HMTA Implementation
      • HMTA is not related to non-program/project management health and medical issues (e.g. Center operations), nor health and medical program/project management issues which are governed by laws, regulations, and requirements external to NASA (e.g. Occupational Safety and Health Administration).
    • 23. HMTA Requirements Flowdown
      • HMTA Requirements Directives
      • NPD 8900.5, NASA Health and Medical Policy for Human Space Exploration - establishes NASA health and medical policy for human space exploration - OCHMO as HMTA
      • NPR 8900.1, NASA Health and Medical Requirements for Human Space Exploration - requirements and processes for implementing NPD 8900.5A – OCHMO as HMTA
      • NPR XXXX – HMTA Implementation (under development)
      • NPR 1800.1C NASA Occupational Health Program Procedures, (Sec. – 2.15, 4.2.3.2, 4.2.3.3, 4.5, 4.6, 4.8)
      • NASA-STD-3001, NASA Space Flight Human System Standard, Volume 1: Crew Health
      • NASA-STD-3001, NASA Space Flight Human System Standard, Volume 2: Habitability & Environmental Health  
    • 24. HMTA Requirements Examples
        • Internal Atmosphere
        • Off-Gassing
        • Acceleration (sustained, transient, rotational)
        • Vibration
        • Acoustics
        • Ionizing Radiation
        • Non – ionizing Radiation (Visible, IR, UV, RF)
        • Body Waste Management
        • Trash Management
        • General size, placement, arrangement, and configuration of spaces
        • Lighting
        • Safety Hazards
        • (This list is intended to show the variety of topics that could potentially become HMTA issues and is not all-inclusive.)
    • 25. HMTA Implementation Problem
      • Due to resource and infrastructure differences, HMTA implementation varies between Centers and differs significantly from Engineering and SMA Technical Authority.
      • Unlike Engineering and SMA, aside from JSC none of the Centers have HMTA mainstreamed at the working level in the day-to-day Program / Project processes.
      • These differences increase risk that HMTA issues will be missed completely or identified too late in the Program / Project life cycle to allow for design modifications without significant impact to cost and schedule.
    • 26. Examples of HMTA Issues
      • ARES engine thrust oscillation
      • Constellation Ground Ops Project Emergency Egress System (EES)
      • SOFIA Acoustics Problem
      • Each of these issues affected HMTA requirements but were identified too late to result in Design changes.
    • 27. Current HMTA Implementation
      • Currently, the CHMO delegates HMTA to a Chief Medical Officer (CMO) at five Centers:
        • Ames Research Center
        • Dryden Flight Research Center
        • Goddard Space Flight Center
        • Johnson Space Center
        • Kennedy Space Center
      • The other five Centers do not have a CMO and therefore have no HMTA presence.
      • Other than JSC, the CMOs at the other four Centers have limited Program / Project / Technical experience.
    • 28. Current HMTA Implementation
      • Bottom Line
      • The CMO is a Medical Doctor with multiple responsibilities who has no staff and little or no progam, project or technical expertise. For the Centers without a CMO there is no HMTA presence.
    • 29. HMTA Solution
      • Utilize Program / Project Engineering and SMA Technical Authorities already involved in the day-to-day Program / Project work to be the HMTA “eyes and ears” at the Centers.
      • The Engineering TA and SMA TA will not be delegated HMTA but serve as the awareness and communication links for potential HMTA issues.
        • Responsible for HMTA awareness within the assigned Program / Project.
        • Inform the appropriate levels of HMTA of potential health and medical issues in a timely manner.
        • Inform the Program / Project Manager and Center management of potential HMTA issues.
    • 30. HMTA Solution
      • Bottom Line
      • NASA is counting on the program/project Engineering and SMA TAs to raise potential issues so that the proper HMTA personnel can get involved earlier in the process of resolution.
    • 31. HMTA Process for Human Space Flight Programs and Projects – Figure 1 CHMO JSC CMO JSC POC Center SMA TA (SMA Director) Project SMA TA Project Engineering TA Project Engineering (aware of issue ) Project SMA (aware of issue) Center Engineering TA Info Info Center CMO ( Where it exists ) Flow of Authority Flow of Issue Coordination
    • 32. HMTA Process for Non-human Space Flight and R&T Programs / Projects - Figure 2 CHMO CHMO POC Center SMA TA (SMA Director) Project SMA TA Project Engineering TA Project Engineering (aware of issue ) Project SMA (aware of issue) Center Engineering TA Info Info Center CMO ( Where it exists ) Flow of Authority Flow of Issue Coordination
    • 33. HMTA Solution – HQ Actions
      • Documented by a Letter of Agreement between OCE, OSMA and OCHMO - issued June 14, 2010.
      • Points of Contact (POCs) for Engineering and SMA TAs identified at JSC and OCHMO – Nov 2010.
      • Interim guidance letter for HMTA implementation – ECD December 2010.
      • OCHMO issue new / revised directives to document HMTA implementation – ECD May 2010.
      • Implement HMTA awareness training for Engineering and SMA TAs at each Center so they are aware of requirements and types of potential HMTA issues – ECD July 2010.
    • 34. Changes in Technical Authority from NPR 7120.5E
    • 35. Technical Authority What has changed
      • Flow of Technical Authority
      • Role and Responsibility of Program/Project TA-Eng
      • Other Technical Authority Roles
    • 36. Flow of Technical Authority
      • Center Directors were previously in the TA flow for projects only . Rev. E expands the TA role of the Center Director to also cover programs .
    • 37. Role and Responsibility of Program/Project TA-Eng
      • The Engineering TA for the program or project leads and manages the systems engineering functions . This includes systems engineering, design, development, sustaining and operations.
        • A Center may have more than one engineering organization and delegates Engineering Technical Authority to different areas as needed.
      • To maintain Engineering Technical Authority independence the following existing provisions remain in effect :
        • The Engineering Technical Authority cannot be the decision maker on a board or panel that provides relief to a derived requirement. This provision does not preclude such an Engineering Technical Authority from chairing preliminary boards that provide input to the change or control board.
        • As a minimum, two Engineering Technical Authorities (e.g., the PCE and the applicable LDE) must agree with the action to accept a change to or a waiver or deviation from a Technical Authority requirement.
    • 38. Other Technical Authority Roles
      • Top level documents developed by a program detailing Agency-level requirements for human rated systems are to be signed by the Administrator or his/her formally delegated designee. (New)
      • On decisions related to technical and operational matters involving safety and mission success residual risk, formal concurrence by the responsible Technical Authority(ies) (Engineering, Safety and Mission Assurance, and/or Health and Medical) is required. This concurrence is to be based on the technical merits of the case. For residual risks to personnel or high-value hardware, the cognizant safety organization must agree that the risk is acceptable. For matters involving human safety risk, the actual risk taker(s) (or official spokesperson(s) and their supervisory chain) must formally consent to taking the risk; and the responsible program, project, or operations manager must formally accept the risk. (Residual added to correct an error in initial implementation)
    • 39. Concluding Remarks
      • Technical Authority is alive and well and continues to evolve based on experience to fulfill its basic objective of supporting safety and mission success.
      • HMTA awareness has to be improved throughout the Agency. The support of Program and Project Managers and Engineering / SMA TAs is crucial to establish needed HMTA awareness at the appropriate levels.
      • OCE Surveys will continue to provide oversight of the implementation of TA including changes resulting from Revision E of NPR 7120.5 and the final implementation of HMTA.