Of all the important elements of medical device new product development (NPD), project planning and management gets the least attention and is the most poorly performed. Full stop.
We expend tremendous product development effort to deliver patient safety, product performance, and physician ergonomics. We design for cost, manufacturability, and reliability. We agonize over the wording and acceptance criteria of every requirement. Our drawings are exquisitely toleranced. No spec is left unverified or unvalidated. Instruments and fixtures are IQ’d, OQ’d and PQ’d. Manufacturing processes are thoroughly validated. We justly take pride in these achievements. One medtech engineer told me that he sleeps better at night knowing his risk analysis was well-done.
Yet when it comes to planning a project, our attention wanders. We put in some effort, get frustrated by the complexity and ambiguity of the project tasks and dependencies, and call it “good enough.” We don’t put nearly the effort into planning that we put into FMEA’s or inspection instructions. We write something up, get it signed, and a couple of weeks later, project plans lie quietly buried and already outdated in a design history file. Most of the time, we don’t know how to make the plan any better, even if we wanted to.
Sound familiar? Software companies have shown us that there is a better way.
We call NPD a core competency. We recognize that business success derives from rapid, efficient, and effective new product development, and we trumpet our innovation culture. Yet doesn’t it seem strange that critical company initiatives are often so poorly planned? Schedules slip. End-of-project all-nighters ensue.
I’m here to tell you – medtech is way behind the curve. Tech and software companies recognized the importance of NPD project management long, long ago. Just as the advent of lean manufacturing led to dramatic improvements in manufacturing productivity, these newly developed project management techniques have led to improved NPD productivity. In other words, the adoption of agile and kanban project planning techniques is one of the main drivers of the increased productivity of tech and software companies. Increased NPD productivity brings new products/services to market, better, faster and cheaper. It should come as no surprise that VC’s have turned their attention to sectors that achieve better product-market-fit on faster timelines at lower development cost.
So what did tech and software companies recognize about traditional project management approaches? Well, traditional critical path and critical chain project planning are all about defining task dependencies, and the time spent defining, analyzing, and maintaining detailed task dependencies in project plans is rarely time well spent.
Here are the top five reasons why:
- Unpredictability. In medical device produce development, it’s impossible to predict task dependencies more than a few months in advance with any accuracy. Things change. The critical path we define today is unlikely to be the critical path we’d see if we looked back in six months.
- Unparseable plans. The more accurate the gantt chart, the more detail is required. The more detailed the gantt chart, the more unparseable it becomes for anyone other than the PM.
- Unrealistic versus unmanageable links. The better the task linking, the less manageable it becomes for the PM. Real world task dependencies happen at low levels in the task hierarchy, but linking at low levels is unmanageable. Linking at high levels in the task hierarchy is manageable but rarely realistic. PM’s are caught between inaccurate oversimplification and time-sucking complexity.
- Sclerosis. Task links are sclerotic. It’s hard to make significant changes to highly-linked project plans without wholesale surgical intervention, which requires significant effort.
- Critical chain fallacy. Despite the “can’t have a baby in less than nine months” mentality promulgated by critical chain advocates, projects are almost always capacity-limited not critical-chain limited. More about this in another post.
Tech and software companies have abandoned critical path approaches, in favor of agile techniques. If you’ve spent any time studying agile, you might not see how agile or kanban applies to medtech product development. More about this later too.
Jay Caplan on Medical Devices 
I worked as a PM for a small division at Boston Scientific one year. I managed a dozen engineers and had large complicated plan. But it worked. Yes, things had to change all the time, but that was my job. And having interconnected tasks let me know that if one person got behind, how it would effect some one else down the road. I abstracted each engineers jobs and had weekly meeting to keep them focused. I think they liked knowing what they had to concentrate on each week to stay on task and not burden another engineer because they let something slip.
I think for PM to work, some one has to make it a priority, it can’t be an after thought or the 3rd part of some one’s job.