| I first came to the Jet
Propulsion Laboratory (JPL) 48 years ago, and was taught
that what's most important for project success is bringing
good people on board, getting them to come together as
a team, making certain that they're all on the same page,
and setting up the mechanisms to keep them communicating.
That much is true to all successful projects -- but, naturally,
it's not as simple as it sounds.
What, for example, are the most effective "mechanisms"
for communication? Today, people think about email when
they think about day-to-day communication and PowerPoint
for presentations. But many believe, including me, that
the advent of email and PowerPoint has, in some respects,
eroded our culture of engineering communication.
Of course, if you need a quick answer, if you're working
with remotely located team members -- then email can
be a tremendous communication tool. So is PowerPoint
for presenting an engineering summary or presenting
the results of a design activity. But what's important
to note here is that neither email nor PowerPoint is
an adequate substitute for engineering documentation.
By that, I mean if you have people working in a technical
area, it doesn't matter what it is, at periodic times
you need to have them capture the engineering that has
gone on. You need to do that with an engineering memo,
or a workbook, or a technical report -- whatever you want
to call it. You need to do that to provide an audit trail
of decisions that can be reviewed and challenged by peers.
that the advent of email and PowerPoint have, in
some respects, eroded our culture of engineering
For the record
A technical memorandum is what we used to call it. We
used to have a form for the engineers; they would put
their summary at the top, list their assumptions and
the boundary conditions next, and then go through the
analysis -- sometimes even including a summary of some
of the equations involved, plus the pros and cons they
had considered. All of that preceded their recommendations
and/or summary of actions taken.
That became a part of the engineering file. Anybody
could go back and review that or challenge it. You could
say, "Okay here is the analysis." You could give it
to another person or to another group and have them
validate it or critique it. It also stood as a good
way of handing off information about work that had been
done to a newcomer on the project.
What I've seen over the last ten or fifteen years has
been a gradual erosion of the discipline of that kind
of engineering documentation. Again, I think it has a
lot to do with the introduction of email and PowerPoint
-- which, once again, are tremendous tools for communicating
but not for engineering documentation.
critique a PowerPoint presentation the way you can
an engineering memo.
One way of putting it is that email and PowerPoint
are more like sound bites. You can't critique a PowerPoint
presentation the way you can an engineering memo. It
simply doesn't have the structure and the completeness
that you would find in a report or a memo. In many ways
communicating has become easier, but it's still necessary
to keep track of where you're going and the decisions
that have been made.
But does it really matter?
|The Mobile Service
Tower is being rolled away from the Titan IVB/Centaur
launch vehicle carrying the Cassini spacecraft..
Let me give you an example of a time when communication
was at the root of a project's demise. I was on the Failure
Review Board for the Mars '98 failures. The Mars Climate
Orbiter failure was ostensibly caused by a metrics conversion
error that led to a navigation failure. We were getting
the navigation data by tracking the spacecraft to calculate
the trajectory. The data that we got from the spacecraft
augmented the data from the ground -- but there had been
some inconsistency noticed during the mission well before
the failure at Mars orbit insertion.
When we observe an inconsistency during operations,
our practice is to use an engineering reporting system,
called an Incident Surprise Anomaly (ISA) report, to
record the discrepancy. It's only one page long, but
it's a formal report. Once it's submitted, it gets tracked.
During the course of a mission there may be 100 or even
hundreds of ISAs. Once you write an ISA it becomes a
permanent record in the system. It gets reviewed. Its
ongoing status gets reviewed. Its closure gets reviewed.
People have to buy off and say, "Yes, this Incident
Surprise Anomaly, whatever it was, is understood now.
We've taken the following steps to prevent it from happening
again and we've corrected whatever it is."
In the case of the Orbiter, the person who noticed
this problem didn't use the ISA form. He wrote an email
message to the person that he thought could solve the
problem. That person got the email message, and he looked
at it and worked on it for a while. Then his boss gave
him something else to do that this individual judged
to be of higher priority than working on the problem
outlined in the email.
Here is a case where the guy who noticed the problem thought
he was doing the right thing. He wanted to get the problem
taken care of quickly. He sent the email out. The email
went to where the spacecraft was being worked. The guy
who received the email probably could have solved the
problem. But he didn't. It got forgotten.
Probe Undergoes Preflight Testing.
If that message had been generated as an ISA, it could
not have been forgotten. It would have become a permanent
part of the engineering documentation. In our failure
review report, we described the problem something like
this, "Communication channels among project engineering
groups were too informal."
No one would argue that open communication is key
to project success. What I'm suggesting is that we keep
in mind that communication comes in many shapes and
sizes -- it's not a one-size-fits-all concept. We need
to reinforce the distinction between the need for rapid
communication and the need for engineering documentation,
which creates products that can be peer reviewed and
that leave an audit trail for engineering follow-up
Search by lesson to find more on:
Keeping the lines open
came out of retirement in 2003 to return to the
project management ranks at the Jet Propulsion Laboratory
in Pasadena, California. The engineering memos Casani
champions in this article are far from being the
only formal communication he sets up on his projects.
"As a project manager, I hold two regularly
scheduled meetings each week," explains Casani.
"One is with just the core project staff, and
the other gathers a more extended set of people
working on the project -- including people matrixed
to the project from each of the major technical
In addition, the full project staff -- including
out-of-town team members from other NASA centers,
government agencies, industry, and academia --
are invited to monthly meetings and many of them
make a point of attending the meetings in person.
"This is the way that we can coordinate and keep
track of how the project is going," says Casani.
"We keep everyone informed about what everyone
else is doing."
Informal communication is just as important.
Core team members are co-located in "our own corner
of the building," says Casani. "We're in contact
every day, almost every hour, in addition to the
meetings we hold."
For more about John Casani's remarkable career
at JPL, see his story, "A
New Spin," in this issue.