Configuration Management—Jack Fisher

Configuration management (CM) is a mystery to almost everyone as it was to me when we starting working on the Pioneer Venus contract in 1974. This was a serious concern as I had been chosen to head systems engineering for the program. My first stop in the quest for understanding was the company management directives. I spent the better part of a week reading and trying to understand these with little success—they were incomprehensible. My next step was to talk to Mal Meredith, my systems engineering mentor—Mal at that time was heading systems engineering for the NASA OSO program and he surely would be able to help me. His answer—don’t worry about it—it’s really very easy to understand and when it becomes important you will pick it up quickly. Needless to say this advice was very welcome.

Configuration management had its origins in the 1950s as the Air Force was developing ballistic missiles. A missile failure would require fixes resulting in a successful launch, but if the fixes were not properly documented they perhaps could not be replicated. CM begins with the formal release of program documents and drawings and requires that modifications be classified and formally controlled so that the product configuration is always known and under control. When the system is to be delivered to the customer its performance and configuration have to be reported.

We started the program and worked the major design issues and advanced into program engineering with the release of specifications and drawings. And this occasioned the need for control of the configuration or configuration management and the appearance of Mike Chekel. The NASA Division had a CM group that Mike headed. We started having weekly Configuration Control Board (CCB) meetings that I was expected to chair. Responsible Engineering Authorities (REAs) would propose changes to modify their subsystem design and the CCB would have to evaluate and cost them making sure that if other subsystems were impacted their REA would evaluate the change. With Mike’s guidance and meticulous record keeping we handled this phase of the program without any major difficulties.

The next hurdle was the Orbiter Pre-Ship Review that was held over a four-day period, February 21-24, 1978. It was chaired by Charlie Hall, the ARC program manager, and attended by representatives of various NASA centers, GDC, the launch vehicle contractor, and the experimenters that provided instruments for the mission. The purpose was to show that the spacecraft met all specification requirements and that we knew precisely what items comprised the spacecraft to be delivered. With Mike Chekel’s support we passed those hurdles with flying colors. Systems engineering prepared a System Performance Assessment Document (SPAD) that summarized spacecraft performance versus the requirements.

We later received a commendation from Charlie Hall, the ARC program manager that thanked us for “a job well done.” The orbiter was shipped to the KSC launch site on March 15 and was launched on its way to Venus on May 20. I left for the Cape in early March and headed up the systems engineering activities at the launch site. I returned briefly to El Segundo for the Multiprobe pre-ship review April 24-29. The Multiprobe was shipped to the launch site on June 5 and was launched on August 8. With Mike Chekel’s guidance I didn’t find that configuration management was all that difficult.

This entry was posted in Technology by Jack Fisher. Bookmark the permalink.

About Jack Fisher

Jack was a systems engineer at Hughes from 1961 to 1992. He contributed to various programs including Surveyor, Pioneer Venus, Galileo, Intelsat VI and innumerable proposals. He was the manager of of the Spacecraft Systems Engineering Lab until his retirement. Upon retirement Jack taught systems engineering at a number of national and international venues.