In medtech, project managers struggle with project complexity, and unknowns. Once you start adding complexity and unknowns to the project, you will need a paradigm that properly fits the project at hand. Product Creation Studio recently released a video on 3 project management strategies and offers some advice on what might work best for medical technology hardware product development.
Adaptive Project Management from Product Creation Studio on Vimeo.
1. Waterfall
This popular project management paradigm allows the project to flow from requirements to implementation to testing (like water flowing off the edge). Once a plan is completed, work flows through the plan. This is a detailed paradigm with tasks broken down and assigned. It tolerates very little unknowns. If any tasks slip, the delivery date slips by a day. It is mostly used for projects that have to coordinate dozens of companies, from various locations, with complex interactions done in a specific order and materials arriving just in time (e.g. building a skyscraper).
Waterfall requires experienced practitioners who can do their jobs with very little uncertainly. In addition, it does not accommodate unknowns, which makes it less suited for product development of devices. For example, it cannot accommodate new tools and processes.
There are, however, some useful ideas from waterfall. Product managers should track the critical path and long lead time items. Complex device development could benefit from tracking dependencies. And work breakdown structures (even if they are incomplete) help everyone map and meet requirements.
2. Agile
Agile was developed for software projects and has become popular for medical device development. Agile involved developing stories (i.e. light weight requirements) for each work phase. Agile development operates in 2-week sprints. Priorities are set at the beginning of each sprint. At the end of each sprint, the goal is to have something to take to the stakeholder for feedback. That feedback is incorporated into the stories for the next sprint.
For agile to work well, it is best to focus on projects for which the complete build and budget are small, and for which the cost of a small mistake is minimal. Automated testing helps ensure the product does what it says. However, the process has some deficiencies. There is no way to deal with complex product dependencies, or to determine a critical path. There is no way to deal with long lead times. In addition, prototypes can be expensive and lead to an expensive build. Further, the costs of making mistakes can be high.
Agile does offer some great lessons. It values customer collaboration over contract negotiation to ensure everyone is happy with the final product. It emphasizes engagement with all stakeholders early and often to get the necessary feedback, and is responsive to change through value-added learning, as opposed to following an outdated plan or contract.
3. Adaptive
Adaptive project management is the paradigm that may make the most sense for hardware product development. The most important focus is on reducing risk early (whatever point you’re working on, reduce risk at that point). Examples of reducing risk: build a prototype and testing or creating a mitigation plan when you can’t test.
It includes sufficient planning so that you know the team is always working on the correct tasks, but no more planning than that (like waterfall-style planning but without the same amount of precision). It allows teams to focus on the critical path and long lead time items (but not at the expense of risk reduction).
To build an adaptive project management plan, you need to understand your greatest risks and how to reduce them (this is the most major point of the adaptive paradigm). The next need is setting milestones and building a plan to achieve them. Milestones can include investor meeting or conference. Communication is paramount in the adaptive paradigm. Stakeholders need regular and clear updates, as do team members. Agile daily scrum meetings can be useful.
Accuracy is valued over precision. With uncertainty or unknowns, there will be a certain amount of rebuilding the plan. So rather than say, “I can get this done in 25 hours,” say, “It will take about 2 days,” with the idea that some days you will overshoot and some days will be faster and average out the estimation. As your understanding of the project increases, the detail in the plan should reflect that knowledge.
[Want to stay more on top of MDO content? Subscribe to our weekly e-newsletter.]
