Page 208 - The Art of Designing Embedded Systems

People Musings 195

(for example, schedule slippages due to changing specs), then these should
be coldly, accurately documented in a form that’s useful to all involved.
No whining allowed.
No, a successful postmortem is an unemotional, nonconfrontational,
reasoned, thoughtful process. It works when all participants buy into the
idea that improvement is important and possible.
I feel that a successful postmortem results in a written document that
will be preserved with other engineering materials, perhaps in a drawing
system. The document is important, as it’s a formal analysis of ways of
doing engineering better. Just as a contract is a written version of an infor-
mal understanding, the postmortem report codifies the information.
A great postmortem results in a report that’s eminently readable, that
even people not involved with the project can understand. File these to-
gether and give them to all new hires to give them “virtual experience.”
The document is a critical look at every part of the project (Figure
9-1). Did the specifications change often? How often, and what was the
real impact on the project? Were the tools up to snuff? What other tool-
chains could you have used, and why didn’t you? Did real-time problems
cause trouble? Did you badly estimate the scope of the system. . . and if
so, why?
Never forget to look at the skills of all of the players. Did a new lan-
guage no one really understood create problems? Perhaps new hires just
didn’t understand the company’s technology.
Structure the report as a series of recommendations. “The tools
sucked” is useless. Better: “The selected CPU had no real tool support.
Next time pick a chip with at least two different ICES and three compilers
so we have options.”

1
Product

Code inspections Quahtyldesign
Hardware design
Change control
How we did it Team burnout Perform mce
Change frenzy
People avadability

FIGURE 9-1 Areas a post mortem should cover