Integrated coordination of tasks involving common hardware used by different teams minimizes the impact of configuration changes.
Element processing schedule compression and overlapping assembly and test activities during processing of Flight 2A hardware at NASA’s Kennedy Space Center Space Station Processing Facility resulted in procedural and schedule disconnects. Hardware that had previously been configured for test or closed out for flight was inadvertently deconfigured / disassembled by teams working parallel tasks on the same system or hardware.
An assembly or test team working to an approved work authorization document (WAD) would configure a system or hardware for an upcoming test or flight. Later, a different assembly or test team — also working to a valid work document — would disassemble or reconfigure that hardware for a different task. This sometimes caused a loss of known configuration, which necessitated the release of unplanned event paperwork to document the restoration of the hardware to its original state of completion, causing delays to already tight schedules.
One example involved inter-module ventilation port caps that had been configured (installed and leak-tested) for flight. The team testing the Environmental Control and Life Support System inter-module ventilation needed to connect air ducting to the same ports and removed the caps and proceeded with their tasks, negating the previously certified hardware configuration.
Lesson Number: 1224
Lesson Date: September 11, 1998
Submitting Organization: Johnson Space Center
HIGHLIGHTS
LESSON LEARNED
- Integrated coordination of tasks involving common hardware used by different teams or groups for test, closeout, and inspection will minimize the need for repeated activities caused by unexpected configuration changes.
RECOMMENDATIONS
- Require procedural coordination between assembly and checkout teams and test teams.
- Require application and removal of tags identifying element hardware and systems configured for test or flight.
Consult the lesson learned for complete lists.
Paul Mogan
Photo Credit: NASA
NASA Kennedy Space Center Configuration Management Program Manager Paul Mogan on the importance of this lesson learned:
I think this lesson is important because as NASA develops more complex systems, configuration changes made during test and checkout can be more far-reaching and difficult to spot, leading to increased cost and schedule impacts from working the type of situations described in the lesson.
Configuration management (CM) is a rigorous discipline ensuring the truth, trust, and traceability of data and ensuring the integrity of our systems. Implementing CM becomes more complex as our systems become more complex.
The important ingredient in CM is people, whether you’re performing CM using paper and file cabinets or using the best modern tools. People develop the work procedures and schedules. People perform the necessary integration between tasks and across organizations. People and their understanding of their role in maintaining system configuration make all the difference.
Keeping systems in a known, correct configuration is essential. In order to keep the system in a known configuration it is necessary to know the initial configuration and to have a controlled process for identifying, controlling, approving, and verifying the implementation of changes.
Testing or other operations can result in changes to what is known as the operational configuration. An example of an operational configuration change might be connecting / disconnecting cables, opening compartments, removing covers / panels, or applying certain settings. Changes to operational configuration are nothing more than changes to the system and these also need to be controlled and documented.
CM professionals need to be involved in testing and other operational activities so that the system operational configuration can be managed. Prior to testing or other activities there needs to be a configuration verification to ensure the system is correctly configured for the activity. When there is schedule pressure, there is a tendency to be less rigorous, which can lead to the type of problems described in the lesson learned.
When people are in a hurry, they may not thoroughly verify that one test / operation has been completed prior to starting the next one. This can happen especially when different teams or organizations are doing different things to the same system.
Related Resources
Systems Engineering Handbook: Configuration Management
Environmental Control & Life Support System (ECLSS): Human-Centered Approach
Spotlight on Lessons Learned is a monthly series of articles featuring a valuable lesson along with perspective from a NASA technical expert on why the lesson is important. The full lessons are publicly available in NASA’s Lessons Learned Information System (LLIS).
If you have a favorite NASA lesson learned that belongs in the spotlight, please contact us and be sure to include the LLIS Lesson Number.
