A still from the animation, “Global Precipitation Measurement (GPM) Mission: A fly up the Nile River in Egypt, then a pull-out into space,” showing Saudi Arabia, India, and the Caspian Sea.
Credit: NASA Goddard Space Flight Center/Scientific Visualization Studio; Blue Marble Next Generation data is courtesy of Reto Stockli (Goddard) and NASA’s Earth Observatory.
At the 2009 NASA Project Management Challenge, I walked to the lectern wearing a white wig. I asked the audience to step back in time with me to the signing of the Declaration of Independence.
I represented George Washington. When the audience stopped laughing, I said, “Imagine for a moment, if we had to have all the signatures on our documents that our forefathers had during the signing of the Declaration of Independence. It would take a long time, and we would not be very productive.” The Declaration of Independence established requirements and standards for our nation. It was read, reviewed, and edited many times to be sure it was correct before it could go to England. The documents we process for our projects might not be as far reaching, but they are important to mission success. Reviews take time, but they ensure that our documentation complies with requirements and has lasting value.
Requirements and standards are the foundation of any NASA program and project. They define how a project accomplishes its objectives and moves forward to achieve its goals. It is the responsibility of configuration management to maintain the traceability of documents through the entire project life cycle. Configuration management is a formal process to document and control the coordination, evaluation, approval, and release of all changes; to maintain all project documents and drawings; and to ensure all requirements are complied with and all proposed changes have been implemented and resolved. Without configuration management, project activities would not have traceability. Configuration management ensures that technical errors are corrected and new requirements accommodated. It ensures that project objectives are being met and that the project team is performing effectively. Also, without successful configuration management, we would lack the wealth of accurate documentation that future projects can learn from and build on.
Learning by Doing
When I first started in configuration management, I worked for a company supporting Goddard Space Flight Center’s Image Processing Division. I worked in the Technical Reference Library at the Inglewood facility in Landover, Maryland. One end of the facility housed the technical publications department; at the other end was the engineering department. The library was located in the middle. This was one of the times in my career that I happened to be at the right place at the right time. I found that it is important to be close to the project office for easy access.
It was my first opportunity to establish processes for configuration management of documents and drawings. I created a logbook for all the documents and drawings. It was a challenge to keep track of which documents and drawings were released and which were being changed because I had to do it all manually. I remember getting my first computer and using the dbase III Plus application for tracking documents and drawings. It was a whole new world for me and for the configuration management process. Throughout the years, computers and software have evolved and provided a much more effective and efficient traceability process. Over the years, I progressed from dbase III Plus, dbase IV, Microsoft Access, and the Next Generation Integrated Network (NGIN) to, now, the Management Information System (MIS) on my current project.
I have worked on four “in-house” and one “out-of-house” projects at Goddard. Each of these projects had different scientific objectives. The principles of configuration management—identification, control, status accounting, and verification—do not change, but no two projects conduct configuration management in quite the same way. Configuration managers need to enforce the requirements, but still be flexible and work with the project to accomplish its unique objectives.
I learned quickly that I had to do configuration management a little differently when I worked on a project with significant cost and schedule constraints. It was a very fast-paced in-house project. Configuration management was done electronically. Before I started, the configuration management processes were viewed as a ball and chain that held back productivity. We had to accommodate the demands and limitations of the project. Because we did not do configuration management exactly as other projects may have done it, we heard criticism from the sidelines. But we met our objectives and the integrity of the documentation was not compromised. The spacecraft was launched, and the mission has been successful.
When I started working on the Extreme Ultra Violet Explorer payload module in 1989, a project manager recommended that I interact with the team I would be supporting. I realized that establishing a line of communication and a rapport with the managers and the engineers performing the actual work is very important. Configuration management personnel must get out from behind their desks, attend status meetings, and connect with the people creating the documentation. If they want to be successful, configuration management personnel have to be willing to earn their project team’s cooperation.
Working on the Solar Terrestrial Relations Observatory project, I realized how important it is to have a sense of humor and enjoy doing your job. The configuration management office was responsible for project-level documents, instrument and observatory procurements, and deliverables. Sometimes some of the managers would be late to scheduled Configuration Control Board (CCB) meetings. With the clock ticking and no one coming to the meeting, I would go into the project office, toot my fake horn, and announce: “Doo-doo-doo-doo … Is everyone ready for the CCB meeting?!” The project manager would come out of his office and tell me, that’s what he likes to see, people having a good time with their work. There are times when we are a little too serious about what we are doing, so to break the ice, you need to laugh and have a good time.
When I began working on the Lunar Reconnaissance Orbiter project in 2006, there were 250 open configuration change requests (CCRs). To close that many CCRs in a short amount of time, you need the support of the entire team. I worked with each individual subsystem lead and the project management office to get through the processing and release of the documents associated with these CCRs. I learned two things from this experience: that teamwork is very important, and that everyone needs to share the same view of the objective.
The GPM Mission
I currently work as the configuration management lead for the Global Precipitation Measurement (GPM) mission. I lead a team of six configuration management professionals. The core observatory has evolved through many versions and architectures, each producing a surge of new documentation specific to the plan at the time. The mission was initiated as a Goddard in-house effort with design work starting in earnest in 2002. As the design approached preliminary design review in late 2004, the project transitioned to an out-of-house effort managed by Goddard. The following year, the project direction shifted to a collaborative effort between Goddard and commercial vendors, in which the flight electronics and software would be procured and used on a Goddard-designed spacecraft bus. Studies were performed with potential vendors and development of procurement documents were in progress when the project reverted to the original plan of in-house development in fall of 2007. Each of these shifts created an avalanche of new and modified documents and drawings. Only through the lessons I learned on previous projects and the support of a great configuration management team have I been able to manage the project’s objectives.
Animation still showing Lake Nasser, Egypt.
Image Credit: NASA Goddard Space Flight Center/Scientific Visualization Studio; Blue Marble Next Generation data is courtesy of Reto Stockli (Goddard) and NASA’s Earth Observatory.
The GPM core observatory successfully completed its preliminary design review in November 2008 and its critical design review in December 2009. Integration of hardware into the mechanical structure is currently under way, with integration activities scheduled for most of 2011 and environmental testing throughout 2012. Shipment to the launch site at Tanegashima Space Center in Japan is planned for early the following year for a summer 2013 launch.
Configuration management is responsible for managing all aspects of the GPM design cycle: requirements specifications, analyses and parts lists, schematic drawings, interface control documents, review materials, and test procedures and results. Many of the core observatory sensors and actuators, as well as the GPM microwave imager instrument, are procured from commercial vendors, which present a different configuration management challenge—to manage all the documentation associated with procurement activities and deliverable documents. The dual-frequency precipitation radar instrument and H-IIA launch vehicle are provided by the Japan Aerospace Exploration Agency, adding the challenge of international relations and compliance with international traffic in arms regulations.
I have two mantras that work for me. The first one defines the configuration management process: baseline, control, change, control, traceability, review, and release. I developed my second mantra a few years ago when I worked with an engineer who did not provide documentation to support the work he was doing and made changes without going through the process. He told me time and time again I was keeping him from doing the work he needed to do; the configuration management process was slowing him down and causing him to not be on schedule.
One day, I walked into the room and set down in front of him a 3-foot-long 2×4 board with his name on it. I held up the board and told him that if he did not do what needed to be done I was going to use it as it was meant to be used. Now, I am not a violent person and would never have carried out the threat: my second mantra is “do not hit the engineer.” The threat was effective, though. Recently a systems engineer added his own twist to this story. The Project Management Office is the biggest force behind configuration management. They set policy and priorities, and they provide influence over the engineers to make sure they are compliant. In other words, he said, project management is the 3-foot-long 2×4.
Over the years, configuration management has grown into an important part of achieving project objectives. There are some key qualities that configuration management personnel need to accomplish their job. Good software tools to manage the information are important, but so are having good communication, people, and organizational skills—and a sense of humor. Configuration managers need to be part of the team and be grateful for the people who work to make the configuration management process successful.
Success is a team effort. It requires cooperation, flexibility… and maybe a 3-foot-long 2×4.
