230 likes | 344 Views
Code D Overview. Presented to Technical Standards Working Group Glenn Research Center October 5-6, 2004. Dick Weinstein HQ, Office of the Chief Engineer. Agenda. Code D Re-organization (p. 3-4) Budget Status (p. 5) Program Plan (p.6-10) NPD/NPR (p.11-16)
E N D
Code D Overview Presented to Technical Standards Working Group Glenn Research Center October 5-6, 2004 Dick Weinstein HQ, Office of the Chief Engineer
Agenda • Code D Re-organization (p. 3-4) • Budget Status (p. 5) • Program Plan (p.6-10) • NPD/NPR (p.11-16) • Independent Technical Authority/Warrants (p.17-23)
OFFICE OF THE CHIEF ENGINEER Theron Bradley, Chief Engineer Deputy Chief Engineer for Line Engineering Bill Kilpatrick Engineering Management Board Senior Advisor for Engineering Tools Keith Hudkins • Mission Directorate Chief Engineers • Center Engineering Directors • NEEDS • Training Coordination • Ed Hoffman, Tony Maturo, Pat Patterson • Engineering Tools • NASA Engineering and Safety Center Liason Deputy Chief Engineer for Independent Technical Authority Adm. Walter Cantrell • Center ITA/Chief Engineers • Technical Standards - Dick Weinstein • Warrants System - Walter Hussey (acting) Advanced Planning and Operations Division Deputy CE for APO Christyl Johnson Independent Program Assessment Division Deputy CE for IPA Liam Sarsfield Program and Project Management Policy Division Deputy CE for PPMP Sherry Buschmann Engineering Policy and Requirements Division Deputy CE for EPR Gregory Robinson • Trend Analysis/Lessons Learned • David Lengyel • Inventions & Contributions Board – • Walter Hussey, Paul Curto, Gail Sawyer, Iona Butler • Policy, Administration, and Process • Management – • Tanye Coleman, Maureen Moore, Marvalyn Sweeney, Yvonne Kellog, Admin Officer (Vacant) • Homeland Security • Kitty Havens, Scott Thomas • Independent Program Assessment Office (IPAO) • Michael Benik • SMO Liaison, Direction, and Policy Assessment Policy and Planning • Vacant • Agency Special Assessments requested by NASA Senior Staff • JC Duh • Systems Engineering • Steve Kapurch • Software Engineering • John Kelley • Knowledge Capture Integration • Technical Specialties • Engineering Training Requirements • Engineering Evaluation • Anngie Johnson • Program Management Policy • 7120.5 • Program/Project Governance • Program Manager Training Requirements • Program/Project Support • Sandra Smalley
Major Changes • Establishes Independent Technical Authority • Will issue “warrants’ for technical areas/product lines • Standards will be part of this organization • “Line Engineering” will oversee operating relationship with Center engineering organizations including annual operating agreements • New Program Areas • APPL/NET: Project management and technical training • Inventions/Contributions Board • Program Management • NEEDs, Knowledge Management, Communities of Practice: electronic support portals for engineering disciplines • Homeland Security • Staff up to 20-25 people • Theron Bradley is leaving
FY05 Budget • Expecting 51 day continuing resolution • Required limitations: 80% of last year level, no new starts • Original Baseline Full Cost budget was ~$53M • An over-guideline request of ~$20M proposed to cover CAIB/Diaz implementation, other pograms • No final mark yet • Advanced Planning and integration Office will conduct “zero-baseline” review • APIO requested development of 5%, 10%, 15% cut options • Full cost not yet broken out at Program Area level; now being negotiated in calls to Centers • Procurement level for Technical Standards not cut because of relationship to ITA • Proposed standards baseline consistent w/Center submits • Priorities may change when warrant holders established
Technical Standards Program PlanObjectives • Standards Plan required to support Functional Leadership Plan of the Office of the Chief Engineer • Will increasingly tie funding to specific objectives and expected products for • Budget development • Annual Center Operating Plans • Need plan to • Help order priorities • Establish basis for level of support required • Define interfaces with other program elements • Requesting feedback from Centers and other functional offices by October 27
Technical Standards Program Plan1.NASA Preferred Technical Standards • Develop NASA Technical Standards • Improve screening for new standards re: need, priority, existing alternatives, VCS options, etc • Identify Center Standards from programs for conversion to NASA Technical Standards • Common review procedure for all NASA Standards • Electronic template (on-line?) for standards development • Decrease re-certification backlog to 1 year • Identify core/mandatory standards in support of warrant system • Support and Adopt Non-NASA Standards • Screening process for NASA participation in VCS development • Initiate cooperative development agreement with 2 SDO’s
Technical Standards Program Plan2.Technical Standards System • Search, Delivery and User Support • System requirements for internal Technical Standards System to accommodate changing licensing environment • Review system controls to ensure proper use • Requirements for document management system • Identify standards OPR’s with warrant holders • Lessons Learned/Application Notes (AN’s) • Add linking from >2 sources beyond LLIS • Initiate development of AN’s with 2 more Centers • SUNS • Increase registrations through awareness with Programs • Support Shuttle standards re-certification in support of RTF
Technical Standards Program Plan3.Policy and Procedures • Update NPD 8070.6 to reflect requirements of warrant system, directives policy, etc • Revise and expand NPR defining implementation requirements and processes for Technical standards, including links to warrant system
Technical Standards Program Plan4. Other Program Interfaces • Lessons Learned/Knowledge Management System • Communities of Practice/NEEDs • Training • Warrant System • NASA Engineering and Safety Center • Mission Directorates • Air Force/Space and Missiles Center • ISO Technical Committee 20/SC14
Potential NPD Additions (1) • Designated mandatory standards to be used on all programs except as waived by the responsible Technical Authority • NASA Preferred Standards are to be considered as first choice for selection of other standards • Except for standards required by a management directive or designated as mandatory, technical standards are not requirements until designated and applied/tailored by a program or project
Potential NPD Additions (2) • Each program/project shall develop a Standards Management Plan as required by NPG 7120.5 • Tailoring of technical standards is permitted and shall be approved as required by NPR 1290.2 (Independent Technical Authority) • Program technical requirements shall be traceable to technical standards • Individual technical requirements in NASA Technical Standards shall be marked to support traceability and tailoring (What about non-NASA standards?)
Potential NPR Additions/Issues • Common development and review processes for all NASA Technical Standards Products • Center concurrences on developed or adopted standards shall demonstrate full technical and programmatic participation • HQ Mission Directorate concurrence in NASA Technical Standards required to verify policy acceptability • Update standards taxonomy for compatibility with Technical Warrant process • Revise standards development review process to add/define role of warrant holder (Standards program develops standard, warrant holders approve/concur and manage use
Potential NPR Additions/Issues (continued) • Establish process for identifying and linking lessons learned and application notes to standards • Establish criteria for designation of mandatory standards • Definition/approval requirements for variances (deviations and waivers) to NASA Technical Standards, Adopted Standards (ref. NPR 1240.1?) • NASA tailoring for adopted standards • Requirements for configuration control of NASA Technical Standards • Requirements for review and re-validation of NASA Technical Standards including VCS potential • Processes for review and cancellation of adopted standards
Potential NPR Additions/Issues (continued) • Procedures for designating and limiting standards as inactive for new design • Approval requirements for personnel participating in development of VCS
Next Steps • Feedback from TSWG • Chief Engineer Approval • Development of Program Metrics
Technical Authority and WarrantsBackground CAIB Report Volume 1, Chapter 7.3 “…responsibility and authority for decisions involving technical requirements and safety should rest with an independent technical authority.” “…technical and safety engineering organizations own the process of determining, maintaining, and waiving technical requirements with a voice that is equal to yet independent of Program Managers…” other organizations have “…invested in redundant technical authorities and processes to become highly reliable.”
What is Technical Authority • Technical Authority Definitions • Technical Authority is the authority, responsibility, and accountability to establish, monitor, and approve technical products and policy. • Independent Technical Authority provides checks and balances on the execution of technical work conducted in support of mission-related programs and projects. Having Technical Authority is being the final decision maker on whether a proposed solution is technically acceptable.
Who are the NASA Technical Authorities? • The NASA Chief Safety and Mission Assurance Officer is the NASA Technical Authority for safety and risk matters. • The NASA Chief Engineer is the NASA Technical Authority for engineering matters. • The NASA Chief Medical Officer is the NASA Technical Authority for health and medical matters. NASA Technical Authority is an Agency function that flows directly from the Administrator
Implementing Technical Authority • NPD 1240.4 (Draft), NASA Technical Authority • A system of Technical Warrants is established as the process for executing and delegating Technical Authority and independent Technical Authority. • Within this process, it is NASA policy that each Technical Authority is to appoint Technical Warrant Holders within their area of cognizance. • The Technical Warrant Holders are to be subject matter experts with mature judgment. • NPR 1240.1 (Draft), NASA Technical Warrant System • The goal of the NASA Technical Warrant System is to establish and execute a disciplined, formal process, standardized across the Agency, for delegating technical decision-making authority from the NASA Administrator to competent experienced individuals conducting and overseeing high-risk technical work for which NASA is accountable.
Types of Technical Warrants • The Chief Engineer, as NASA’s Technical Authority for Engineering, will issue warrants in engineering including: • Technical Warrants at the total system level. Technical Warrant Holders will be systems engineering experts who have the authority, responsibility and accountability to establish, monitor and approve the integration and application of engineering standards/ requirements, products and waivers for their assigned systems. • Policies and waivers for their assigned systems.Technical Warrant Holders, using their independent Technical Authority, provide the checks and balances on the execution of engineering work conducted in support of mission-related programs and projects. At the system level, Technical Warrant Holders will utilize other Warrant Holders, particularly those that represent technical areas and disciplines, as appropriate. • Technical Warrants in particular technical disciplines or areas. These Technical Warrant Holders will be engineering technical experts who have the authority, responsibility and accountability to establish, monitor and approve technical standards/ requirements, products and policies for their technical area.
Responsibilities of Warrant Holders • Responsibilities • Setting Technical Standards, • Maintaining their technical expertise, • Assuring safe and reliable products, • Making unbiased independent technical decisions, • Using sound technical rationale, and • Being accountable for their decisions. • Independence - Technical Warrant Holders are independent since they • Organizationally, will not be reporting to the Product Line program or project managers, • have a direct line to the Agency’s Technical Authority via the Warrant, without going through Programs, and • are able to charge to an Agency wide G&A service pool when performing their Technical Warrant work and therefore are not dependent on Programs’ funding.
Status of Technical Authority/Warrants • Presentation given to the Administrator 8/3/04 • Drafts have been developed for an NPD defining Technical Authority and an NPR describing how it is implemented through warrants but have not been released for formal review • Centers have proposed how they would implement Technical Authority • Issues remain to be resolved on the degree to which proposed implementation approaches met requirements