Advertisement

Blog

The Post Mortem That Heals

The post mortem, though not a very pleasant topic for a Best-Practices discussion, is a meeting or series of meetings intended to critically analyze problems, challenges, and successes experienced during a development cycle. The mistakes made and the lessons learned can serve to create more fool-proof guidelines for subsequent projects.

During a product's development, there are numerous activities and meetings that involve departments from everywhere inside and outside of the company. Hopefully, there has been a program manager and an engineering project manager assigned to see the development through to the New Product Introduction phase (NPI). After maybe a number of board spins and product pre-release modifications, a team usually recognizes that mistakes, oversights, and misunderstandings have taken their collective toll on an otherwise expedient development effort.

So, just as the Supplier Corrective Action Request (SCAR) from our previous article demonstrated that implementing documented procedural changes helps avoid repeated mistakes, the post mortem meeting is designed to be a comprehensive, after-the fact, critical analysis of the effectiveness or ineffectiveness of all applicable processes and procedures. (See: The SCAR Design Engineers Must Have.)

This exercise requires that both the program and project managers had been recording all the issues as they became known. Oftentimes, during the actual development, the schedule has top priority for delivery, and so the number of meetings and attendees should be carefully considered so as not to waste resources. Because everyone's efforts are dedicated to moving the development forward, when a mistake does happen, the pieces are picked up fairly quickly and the program moves on. There may be some complaints, and morale may suffer a bit, but the schedule is king, and this is not the time to have everybody get off the bus and walk ahead looking for obstructions in the road.

This meeting, jointly hosted by the program and project managers, should be attended by the various department representatives who are the “owners” of the procedures being examined. As an example, if a problem occurred that had to do with the documentation not being properly controlled such that a red-lined schematic or bill of materials change did not make it into the next board spin, the design engineer and a designated representative from Documentation Control would want to both be in attendance. The result of this discussion would be to institute an extra design-stage document check to be verified by the design engineer's authorizing signature before any board could be sent to the fab house.

A post mortem does not have to wait until the end of the entire project. If the same cycle of events is going to be repeated, as in the case of additional board spins, then the corrections need to be implemented and formalized as quickly as possible. Notwithstanding, the final post mortem review will include all intermediate changes and provide assurances that the changes are now included in the standard operating procedures.

In this manner, every problem encountered would be addressed while producing an enhanced version of the standard operating procedures for the development cycle. The end goal is to keep refining the procedures and the disciplines required to follow the procedures, such that the entire development cycle becomes less and less problematic over time. This will greatly enhance the company's likelihood of meeting its schedule commitments in the most cost-effective manner.

The post mortem analysis process is not confined to engineering disciplines. Every department in the company can benefit by recording the problems discovered during any operation. We can only know that we have learned from our mistakes when we do not make the same mistakes again.

The term “post mortem” conjures up images of cold, dead bodies laid out on stainless steel operating tables. The pathologist digging around in the various tissues and organs is looking for the cause of death. When a company dies, there seems to be no shortage of armchair pathologists identifying the probable cause of death. The post mortem as discussed here is anything but an armchair exercise; the patient is not dead yet but may have several self-inflicted wounds and be languishing.

However, left undiagnosed and untreated, the patient will continue to hemorrhage money, time, and effort. Don't let your company die a slow death by overlooking the opportunity to close the wounds and restore its health. Often there are “heroes” in the company that can fix anything. A company should not depend on heroes, but should be able to put 100 percent confidence in its standard operating procedures. The post mortem meetings are just what the doctor ordered.

2 comments on “The Post Mortem That Heals

  1. Clairvoyant
    March 20, 2012

    Excellent topic, Douglas. I actually haven't heard or thought about this process previously, but can see the advantage of Post Mortem meetings. Yet another advantageous process for companies to have implemented.

  2. Barbara Jorgensen
    March 20, 2012

    Thank goodness our PMs are not the same as doctors!' As painful as they are, I hope they are not life or death situations. Catastrophic failure of a system can, of course, cause death, but practics such as these help head off problems before they get that far. Good point that PMs don't have to be at the end of the cycle.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.