How to Improve Product Development Productivity - Lessons From the Checklist Manifesto

By Ron Collett

The recently published book "The Checklist Manifesto" holds important lessons for how semiconductor and embedded systems design teams can improve their product-development productivity.

"The complexity of what we have to deliver on exceeds our abilities as experts partly because the volume of knowledge has exceeded what training can possible provide an expert."

That's how Atul Gawande, author of "The Checklist Manifesto," sets up the problem during a podcast interview with Harvard IdeaCast. Gawande is a surgeon and a staff writer for The New Yorker magazine who looks at our ability to be productive in complex situations. His interest, of course, is improving surgical outcomes.

There are, he says, 6,000 drugs and 4,000 medical procedures and increasingly specialized doctors and nurses. We've all read stories where surgical implements get left behind in the patient's body.

I was fascinated by how relevant this is to semiconductor and embedded design. Teams of varying sizes are pulled together on a regular basis-digital specialists, memory specialists, analog designers, software engineers. They're asked to build increasingly complex systems, with tighter market opportunities, and, like surgery, they find it nearly impossible to plan for the unexpected.

Process, not check marks

Gawande's checklist approach isn't about ticking off boxes per se. In the operating room, Gawande devised a two-minute checklist that builds in pauses during surgery to make sure that tasks have been accomplished, that blood is still on hand, and so forth. Perhaps most astonishingly, before the first incision is made, the team takes time to introduce each other by name, so everyone knows everyone else and their expertise and the goal of the operation.

He cites a study done by Geoffrey Smart, who studied decision making among venture capitalists. He compared outcomes of those VCs who, in choosing a entrepreneur, went with their gut (the "art critics") and those who employed a checklist approach in their selection process (the "airline captains").

Those who used the checklist approach had far fewer regrets about their selection of managers, and their investments had higher returns.

But the vast majority of VCs are "art critics," relying on their instincts and experience, rather than the more successful approach.

In system design, many managers rely on their instincts at the beginning of product development to assess how much staff they'll need and how long the project will take. Clearly something's wrong because more than 80 percent of semiconductor projects slip schedule.

Learning from the past

It doesn't have to be this way. Gawande points out that some in the investment banking community rigorously study past investments to understand where failed investments went awry. Sometimes that education leads to adding a check for their next investment checklist: "read all foot notes in the prospectus," for example.

Successful system-design teams, whether in name or spirit, use similar approaches, and they start with benchmarking themselves against the industry or their own past efforts to understand how to approach their latest product development.

As Gawande implies, it's often the simplest approaches-and, I'd add, approaches based on facts rather than instinct-that work most effectively.