So This Is Knowledge Sharing

By Susan Motil

The Concept Review had not gone well, and my entire team was in the dumps. It took months for them to stop feeling lousy about their work and themselves. Not exactly a fun place to be in for me, the project manager, as we headed into the next review.

At the heart of the problem was the review itself. We had tried to cram too much information into only three days. The review panel was inundated with so much information that by the end of the process, anyone — no matter how well they understood the project — would be cross-eyed. Detailed follow-up questions during the presentation pushed the review into overtime, and no one ever had the opportunity to talk with the expert engineers about the particulars of the project.

I told my supervisor that I would like to have some control over how the next review was done. She was supportive. She saw how poorly the Concept Review had gone, and the impact it had on the team’s morale. We all wanted to make our Preliminary Design Review better for everybody, both project team and reviewers.

ASKing the right person for help
A couple of weeks later, my supervisor came to me and said, “Read this article and let me know what you think.” It was a story in ASK Magazine about reviews by Marty Davis, a project manager at Goddard Space Flight Center. I read the article and thought I could apply his concepts to my project, so I gave him a call to get more information and to discuss my ideas with him.

I got hold of Marty in his office and told him what had happened with our review. “Well, you don’t want that,” he said, laughing. I pitched some ideas, and he listened and told me what he had done to improve the reviews on his project. He affirmed my own feeling that the project manager has to be involved in the selection of the review board. This doesn’t mean that the panel is going to be less independent, or that you’re trying to hide a problem. It means that you’re looking for particular expertise. He encouraged me to be forceful. “This can best be handled by presenting the benefits to making this change,” Marty told me. And so that is what I did.

Taking charge
Following Marty’s lead, I asked for input before assembling the new review board. I called around, and I got wonderful support from management. My supervisor began looking around for potential reviewers, as did my program manager.

My program manager identified the person who ended up being chair of the review board. I called and spoke with him to find out if he was interested in working on the board. He had more than 25 years of experience with hardware similar to my project. He understood what it took to take a flight project from concept to design and through development. I told him how much this would mean to our team to have him as the chair, and he said he would be delighted.

I went back to my division chief and said, “Here’s the charge to the review panel. This is what they are going to review, and here are the reviewers.” He looked at my review plan and was pleased with the results. I wanted a panel with handpicked expertise and management approval, and that’s what I got.

Taking another page out of Marty Davis’s playbook, I decided to be flexible and try to think of new ways to streamline things. I didn’t plan to do things exactly like Marty had. His project was orders of magnitude larger than mine. Mine was a microscope, and his an entire satellite. What I liked about his approach, and what I thought I could adapt to my own project, was what he did at the system level. He kept the system level review focused on the higher order issues. If the review panel had subsystem questions, sure they could ask them, but if the questions started to get too detailed, then Marty stepped in and said, “Let’s have a one-on-one about this tomorrow.”

I tailored my review similarly in that I had two sets of reviews, one for each subsystem, and then one for the system. It was amazing how well it worked. At the subsystem level, I blocked out two weeks of time and tried to keep it as informal as possible. It was formal from the standpoint that there was an attendance sheet, a written report, and a presentation at the system level, but it was informal once the reviewers got into the room. They would come in and sit around a table and have a dialogue with the engineers. The engineers could show the reviewers hardware, show them test data, and the reviewers could ask anything they wanted. At the system level, the reviewers stayed focused during the presentation, and had the subsystem review reports as additional data. The second day was reserved for reviewers to discuss detailed questions with the technical experts.

Reviewing the reviews
I firmly believe that a review should be beneficial for both the panel and, more importantly, the project. A crucially important aspect of the project life cycle is the independent evaluation of a project’s readiness to proceed to the next phase. Reviews should be looked upon as an opportunity, not a dreadful experience.

Having the right reviewers on the panel is important, but I can’t emphasize enough the importance of one-on-one communication. It was Marty’s experience that Requests for Action (RFAs) are often written because of a basic misunderstanding on the part of the reviewer. One-on-one communication can reduce that risk. If we can get reviewers to understand our position and if they still disagree with our approach, then fine, write the RFA, but first let both parties come to an understanding of the issues. Additionally, if there is an issue, reviewers’ recommendations can be discussed and understood by the project team at the time of the review.

Addressing an inappropriate RFA is a waste of my time, a waste of the engineer’s time, and a waste of the reviewer’s time. The review board did write RFAs, but many others were not written because of the one-on-one sessions with the technical people on the project. With every comment that the review panel made, they gave us valuable suggestions. The whole board, by the way, recommended that we go forward with the design.

We spent a significant amount of time and effort dealing with the RFAs from the first review. The second review, by comparison, was much more streamlined and effective.

I estimate that the first review cost the project $700,000. The second review about $200,000. Reviews are expensive and time consuming — but they should also be beneficial. If you can refine the process and tailor it to best serve your system, your project will reap benefits. Saving half a million dollars, after all, is hardly something to shrug off.

Lessons

• People within large organizations have probably already dealt with problems similar to the problems that you face; you can save time and money by taking advantage of that experience and knowledge.
• Knowledge sharing by mentors can empower less experienced managers who would otherwise not challenge the status quo.
• Reviews should encourage joint problem solving rather than just reporting. To accomplish this, ensure that the review process is viewed as feedback from independent and supportive experts.

Question
The review process has two objectives: control for external stakeholders and internal sponsors; and learning by providing real-time feedback to the team. How can you share this learning with the rest of your organization and not intrude on the intimacy that exists between the reviewers and the project team?

Read more about the Space Station:
Smart Buying

About the Author

Susan Motil has been at NASA Glenn Research Center for 13 years, with 9 years in Project Management. Her management experience has primarily been with flight experiments under the Microgravity Science Division at Glenn. She is currently working on the Critical Viscosity Xenon 2 (CVX-2) experiment, soon to fly on STS-107 in January 2003, and the Light Microscopy Module (LMM), an International Space Station payload.