While I loved the Agile approach in concept, in practice the learning curve was really steep. My team would have to learn sprints, scrums, and velocity management. Team members would need to learn new roles. It’s easy to find semester-long courses on how to run Agile projects. How were we going to take this on while we were busy doing our day jobs?
The Kanban approach seems more straightforward to me, and apparently to many others. In fact, Kanban project management is now starting to supplant Agile in many places.
If your New Product Development (NPD) project management reliably delivers new products better, faster and cheaper than your competition, I’m impressed. Most of us are working hard to improve our NPD performance.
The adoption of Agile project management techniques has been a key driver of improved new product development (NPD) productivity in tech and software companies (along with Moore’s law and industry adoption of technical standards). Here are ten ways Agile project management differs from traditional gantt-based management.
I’ve been writing recently about the wholesale abandonment of Gantt-based project management (including critical chain) by software and tech companies. In the software world, the Gantt approach has been wholly supplanted by Agile Project Management. Agile Software Development is a class of new project management techniques that has become standard practice at modern software companies, including Google, Spotify, Amazon and practically every software startup. Agile-based new product development (NPD) leads to products that better meet customer and business needs, with shorter development timelines and with less development investment. What’s not to like?
In a recent post http://jaycaplan.com, I explained why medtech companies should look to software and tech companies, to improve project management techniques to drive increases in new product development productivity. Today I’d like to re-emphasize that despite common belief, new product development is rarely limited by the classical critical path. Instead, I assert that our timelines are almost always capacity limited. You’ve been trained not to believe me, but I beg you to look at the evidence dispassionately. Read on to learn more.
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.
I’m not going out on much of a limb when I say that, as an industry, medical device companies are not particularly strong in project management. A tool (like Microsoft Project) is not a management technique. Program management offices abound in larger companies, but rarely do you find a systematic approach to defining the activities of project management. The Critical Chain approach has advantages over a traditional Gantt chart, but at the end, it’s still only a tool. We’re really stuck in last century thinking.
Over the past several months, I’ve had the privilege of meeting many entrepreneurs who are raising funds for new medical device startups. One common VC refrain they hear: “Come back when you have more data.” Many times this can be a VC’s way of saying no without saying no. Sometimes though, the VC really means what s/he says: the current proof-of-concept data hasn’t proved the concept. It’s not just startups that face this challenge. I’ve seen weak proof-of-concept data in bigger companies too. How can you make sure your proof-of-concept data is solid?
Is there a medical device company anywhere that doesn’t use Microsoft Project to manage product development projects? After all, it’s a time-tested, incredibly powerful Gantt-charting tool, and it plays nicely with Microsoft Office. What’s not to like?
Okay, maybe I have a few pet peeves:
Project management is much more than just a Gantt chart. I want tools to help manage shared files, calendars, bug/issue-tracking, and assignable tasks.
Distributed teams need to be able to access and update the project plan in real time from anywhere. Sharing mpp files via email is a recipe for version conflict. And who wants to shell out for a copy of MS Project for everyone on the team?
Too many times I’ve seen MS projects enter the land of tangled task links, where timelines in project plans no longer make any sense. Too many times, project planning meetings screech to a halt so distraught project managers can run off and burn several hours untangling links and rearranging tasks.
I could go on. So I’ve been looking for a better solution for years, and I’m starting to see signs of life beyond MS project.