Documented Experience: Re-Defining Project Management Processes
Tom Gavin of Jet Propulsion Laboratory (JPL) heads the team responsible for writing NPR 7120.5D, the document that defines the policies and requirements that will govern the programs and projects that will take NASA back to the Moon and on to Mars. Carrying out this complex, innovative, lengthy mission is as much an organizational challenge as a technical one.
The work of NASA Centers and contractors, and what is likely to be more than one generation of engineers and scientists, needs to adhere to consistent, well-defined processes to guarantee quality and safety and make it possible to coordinate those thousands of local efforts into intricate, integrated systems—think of a gigantic puzzle whose pieces must fit together perfectly. At the same time, the processes need to flexibly accommodate different kinds of projects and leave room for the creativity that will solve the myriad problems this new work will present. Most of all, these processes cannot be a bureaucratic abstraction of how work should be done; they need to be grounded in experience and embody the best of how work happens in the real world.
These processes cannot be a bureaucratic abstraction of how work should be done; They need to be grounded in experience and embody the best of how work happens in the real world.
The 7120.5D team pulls together broad and deep NASA expertise, including members from each center and mission directorate, from the Office of the Chief Engineer and the Office of Safety and Mission Assurance, from Program Analysis and Evaluation, and several mission support organizations that provide experience in human space flight and robotic projects. Gavin, currently associate director of Flight Projects and Mission Success at JPL, brings a wealth of experience in establishing consistent flight project practices at that center, but he is quick to point out that 7120.5D represents the interests and expertise of stakeholders throughout NASA.
Many organizations run into problems with coordination and collaboration because they assume that everyone understands basic terms in the same way when, in fact, they mean different things to different groups. Those differences often only surface when they try to work together but end up working at cross purposes. Some of the most critical work of the 7120.5D team involved developing a common understanding of the words that define important processes. For example, Gavin notes, "People had different views about the meaning of 'independent.' We had to resolve that." NASA's governance model includes the principle that programs and projects do not review their own work, but what, precisely, does that mean in practice? Gavin comments: "Does 'independent' mean that a person on the review board can't be part of the project or funded by the project? Yes. Does it mean they can't work at the same center? No. The technical knowledge you need is at the centers."
Everything the team did was open to discussion. 7120.5D defines roles and responsibilities in part for the same reason it defines key terms: to reduce ambiguity and eliminate confusion generated by the assumption that "everyone knows" what project, center, and headquarters roles and responsibilities are, when in fact ideas about them are likely to be vague or contradictory. Orlando Figueroa, veteran of many projects and programs and now director of Applied Engineering and Technology at Goddard Space Flight Center, drafted a matrix of roles and responsibilities for 7120.5D and "everybody beat on it once it was out there" (according to a team member) to make sure the definitions were the right ones.
The document defines key decision points and makes clear what the minimum standard of accomplishment is for each phase—what needs to be done before moving on to the next phase. So it mandates more project and program structure than in the past, when project approval was the main and sometimes the only formal decision point. But in keeping with the need for flexibility and in recognition of the professionalism of NASA employees and contractors, it focuses on what needs to be accomplished, not how a project team achieves those results.
The team's goal was to define a single, consistent, unambiguous process for all NASA programs and projects, but they recognized the need to maintain some process elements that have value for some kinds of projects and not others. Gavin says,
The general structure is the same across the board, but we wanted to keep the things that were good about existing processes. For robotics, we do a post-launch assessment review with the standing review board. For human space flight, they have a mission management team meeting every day. We wanted to preserve that function, so we wrote that exclusion into the document.
The extensive hands-on experience of the team members gave them the ability to test 7120.5D against the realities of project work. They continually asked, "Could I have been successful on my project if I had to work to these requirements?"
The NASA community beyond the drafting group also had an opportunity to apply their experience and insight to the new policies and requirements. Team members distributed their draft document informally to program, project, and mission support practitioners at their centers or organizations, asking them to test the document's provisions and definitions against their own experience. They received 1,300 comments in response. A subgroup of the team then "holed up for three days," in Gavin's words, "and went through every single one of those comments." They decided collectively whether to accept or reject each criticism or suggestion and wrote down the rationale for their decisions. The comments helped clarify the life-cycle review process. Among those adopted were a new flow chart by Bill Hill of the Space Shuttle Program Office and an explanation of how a tightly coupled program like Constellation will negotiate between program requirements for mission success and center standards of how to perform work. Gavin remarks, "Sometimes we said, 'Yes, we blew it. You got it right.'" The decisions and rationales were discussed by a core team, which approved the document revision. In several instances the core team reached out to leading Agency experts for advice on a specific subject, such as new federal Earned Value Management requirements. Then the new version was put on NODIS, the NASA Online Directive Information System, to get comments from an even wider group of NASA practitioners. The posting drew another 370 comments. Those went through the same careful evaluation process to produce the final document.
Gavin concurs that openness—developing the revision "in the sunshine" and testing its provisions with the NASA community—was critical to the quality of the process and the document.
Randy Taylor, a member of the 7120.5D team who also worked on the earlier 5A and 5B versions, notes that those documents took years to complete. "We did this version on a more aggressive schedule," he says, "which has real plusses: it meant continuity of membership, and it kept the momentum going." Probably the most important part of the process, he adds, is that "we did it in the sunshine."
Gavin concurs that openness—developing the revision "in the sunshine" and testing its provisions with the NASA community—was critical to the quality of the process and the document. He has nothing but praise for the group that devoted intense months of analysis and discussion to the task of defining the new policies and guidelines. "The operative word is 'team'," he says. "They worked as a team. They were very constructive. Everybody brought their skills and their culture, and it all melded together into one document."