Finally, the class agreed on two things that we needed to accomplish immediately: One was to define the problem; the other was to define a process for accomplishing the task we had been given.

We broke up into groups. In my group it was total chaos. Eventually, we managed to define the problem, but we completely failed to come up with any kind of process for getting things done. At that point, I started thinking that we only had three more nights to work on this. How would we get anywhere if we didn't even have a process?

I looked at this thing with two agendas in mind. Agenda number one was to give the class a problem, which was challenging and stimulating. Agenda number two was to see if a bright group of people might come up with some notions about how to bridge these worlds of technology development and flight system development. We had actually been thinking about this problem for a couple of years, off and on. I thought, well look, here is an opportunity to get some bright folks who bring a lot of capability to the table. I'll explain the problem to them and see if they can offer some fresh insights and ideas. It's a very powerful process and one that we have now already put to use in MSL in a number of different areas: getting people who haven't been in the middle of the forest, but are still very strong technically, to step in and think about the problem for a while and offer their observations. Mike Sander, Jet Propulsion Laboratory

When we regrouped as a class, it turned out that we had all come up with similar definitions of the problem, but the processes were all over the map. It took us at least another hour to agree on the wording of a mission statement, and then we couldn't come to any agreement about what came next. I started to say we need a leader. Nobody was listening. So I kept saying, "We need a leader."

Finally, someone said, "Well, why don't you be our leader?" It was classic. You know, I said, "We need this," and then they said, "Okay, you do it." I should have seen that coming -- the old be-careful-of-what-you-ask-for scenario. We had a vote, and I became the leader.

It was now my job to lead the discussion about how to proceed. It was clear to everyone that we would need to break into groups to accomplish anything. It took a while but we came to the consensus that each group would work the problem and present a solution, rather than dividing up the problem into pieces. As a class we would decide which of the solutions to present to Mike Sander.

My plan was to go around the room, count off, and randomly select the three teams. It would be fast and easy. But as it turned out, there were people who felt strongly about working with other like-minded people. As a result, the class as a whole would attack the problem from different perspectives. So, we broke into teams that way.

One group that emerged said, "Yes, we can do this. It's not so hard." They were optimistic that they could put together a good workflow for the problem based on their collective knowledge. It was simply a matter of identifying useful software that had already been developed and finding a way to evaluate and integrate it.

Another group that emerged said, "No, we don't think that's even been done successfully before. It's not a problem that we know how to solve at this point." They wanted to try to come up with some innovative ideas, push the envelope, and explore things that hadn't been tried before.

You have to listen to the input of the team, or you're going to do the project harm.

Then there was a third group that kind of said, "You know, you guys are making such a big deal of this. Why don't we just do it?" I called them the Nike group. It wasn't that they didn't care about working the problem; they just didn't see the point in all the philosophical discussions about approaches. They simply wanted to get to work.

When it was time to divide up into teams, I joined with a group of people who, like me, felt the project assignment wasn't as easy or straightforward as other people in the class made it out to be. Almost instantly, we were dubbed "the pessimists." But I never felt that was an accurate description. I would like to think that a more accurate name for our group was "the realists." We were simply saying that a major revamping of the mindset at NASA would need to occur to solve this problem we were handed. We didn't think the assignment was trivial or easy to do; trying to recruit autonomy knowledge from the private industry and university sectors was an extremely difficult challenge. Everyone on our team had a software background. All of them, except for me, came from Ames -- but none of them knew one another well. We got started with some brainstorming concepts that the folks from the design company, IDEO, taught us on the first day of class. I think, as a result, that we all felt comfortable sharing our ideas. We didn't always remember to apply the rules they gave us (such as the one that says to "defer judgment"), but we did work collaboratively and courteously. Someone would draw an idea on the easel we were using, and then someone else would build on it. Before long, our ideas began to coalesce. Rob Toaz, Jet Propulsion Laboratory

We spent quite a bit of time that next night getting organized. We came up with a plan for the rest of the week's schedule, how we were going to achieve this work. On a small scale, we were seeing demonstrated many of the things being taught in the class: the value of putting in time up front to define requirements, the need for flexible leadership, the importance of team building, and more.

What became immediately obvious was that we had an amazing amount of technical expertise in that room. I think that was another great lesson for me, just listening and seeing how divergent ideas that emerged from individuals strengthened the group as a whole. I saw in practice that you have to listen to the input of the team, or you're going to do the project harm.

And I also came to see that having these different perspectives grouped together, rather than randomly selecting teams, enhanced the entire exercise. For one thing, our productivity would have been much less because there would have been too much time spent saying, "I want to do it this way" and "Well, I want to do it that way." The teams probably wouldn't have gotten as far as they did as fast.

As a class, we did some work to make certain that we all understood our mission, that we shared a "common vocabulary" when it came to critical terminology, and that we understood what each team was going to produce. Then, the next night, the class broke into teams and worked independently on producing our main deliverable: a workflow that described how to find existing software, integrate it with new software, and produce code.

During our last Enterprise meeting before talking to Mike, each team got up and presented their solutions. I had put together a management team and we set up selection criteria and produced an evaluation form that asked the class to rate each solution: Did the solution meet the requirements? Was the solution innovative? Was the solution feasible?

Both the "pessimist" and the "optimist" teams, as we had come to call them, came up with strong solutions, and when we tallied up the class votes, their scores were close. One rated higher in innovation, the other in feasibility. Together, they offered a balanced approach. Our plan had been to down-select to one solution, but eventually we agreed to present both.

After the three teams presented their solutions, the class voted. Though our team didn't come out on top, we ran a close second. I listened to the discussion that followed the vote as the class planned the final presentation. After a while, I raised my hand. "Look," I said, "there's no doubt this team came up with a good approach, and they won in terms of the votes of the class. But there's obviously merit in the other presentations, and I think it's going to be more beneficial to Mike Sander and the JPL organization if we present them with more than one path they might go down." In the end, the class agreed to present two approaches to Mike -- one dealt more with the development of software, the other with how to find what applicable software was already out there. I felt as though presenting both approaches was the right decision, and I think that Mike confirmed that the night that we delivered our solutions to him. After the first pitch, about approaches to software development, Mike sounded apprehensive. After the second presentation, he sounded more excited. It's not that the presentation or the concept was better, but I think that he started to get a more complete picture of what we had to offer him. He made it very clear that he understood and appreciated the value in what we had prepared -- to the point that he was going to share our input with his management. His response was gratifying. Bill Huddleston, NASA Headquarters

My job that last night, when we made our class presentation to Mike and to his deputy, Rich Doyle, was to summarize our work. Preparing for that summary, I became more aware of the shared concepts that the three teams had come up with, such as how to mitigate risk when dealing with flight code developed by people outside the Agency, and the importance of thinking beyond the immediate mission.

I think this was a good assignment. We got to experience an entire project from start to finish within a few days. That's an experience you don't have in NASA because our projects take a long time. They're huge. And they can be daunting, with so much at stake. Here, we had the freedom to explore the process itself and examine the roles involved. The Advanced Project Management class handed us a microcosm of a project that helped me, and I think others, to see the forest for the trees.