| In July, the Academy
of Program and Project Leadership (APPL) conducted
a two-week class in Advanced Project Management
at Ames Research Center. In the heart of Silicon
Valley, Ames is known as one of NASA's strongest
Centers in software development and information
technology. To take advantage of these local resources,
course manager John Newcomb structured the class
with a specific focus on managing complex software
Included in each Advanced Project Management class
is a practicum, otherwise known as the Enterprise
project assignment. The students are asked to solve
an ongoing problem faced by one of NASA's project
teams. In this case, Newcomb invited the Mars Science
Laboratory (MSL) mission, managed by Mike Sander
of the Jet Propulsion Laboratory, to use the Enterprise
project as an opportunity to address a problem facing
MSL. "We're rapidly coming up on our concept review,"
Sander stated. "Getting a firm handle on the technology
development plan for MSL is very much of an issue."
Sander, and his deputy Rich Doyle, came up with
the following problem for the class: To create
a workflow process, description, and test case that
identifies, selects, matures, and integrates new
software with existing software to create flight
code for MSL. Integral to the assignment, class
members, who represented seven of the ten NASA Centers
as well as Headquarters, had to make certain to
address costs, schedule, and risk constraints.
It felt as though we were getting nowhere that
first night as we tried to discuss the problem. We were
twenty-three people thrown together in a room, without
a leader, and we didn't have anything to go on beyond
what we had heard from Mike Sander.
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.
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.
to listen to the input of the team, or you're going
to do the project harm.
| 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
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.