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)
Technical Authority Implementation “Strengths, Weaknesses and Improvements” Jim Lawrence Office of Chief Engineer (Dell Services)
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 .
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.
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
OCE Survey Results (11 Surveys Completed Covering all Ten NASA Centers)
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.
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.
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).
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.
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.
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
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
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 .
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.
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)