In this column, we discuss how dividing a very large development project into sub-projects keeps the product team focused and aligned while enabling them to identify and fix design issues much earlier in development. 

Relying on a single system integration at the end of development is always a big risk. Without regular check-ins with each other, departments tend to drift apart during long development projects. In addition, without regular customer feedback, the entire project could drift away from addressing core customer needs. Breaking down development into a series of smaller, bite-sized chunks of development helps identify problems before they become too big. This is what we refer to as “micro projects.” 

CONCEPT 6: Micro Projects and Learning Cycles

With micro projects, you still need to accomplish the same tasks you would in traditional development (a schedule, a Gantt chart, resource planning, etc.), but the difference here is to break a single big block of work into micro projects just long enough that each one produces a measurable deliverable and short enough that you can visualize how you will get there. Each micro project will vary in duration—typically two to eight weeks—depending on the goals and technology involved. It should be focused on verifying a critical aspect of the development path for the system, including the different technologies involved with an endpoint that can be measured and demonstrated.

A benefit of this approach is that if the result of the micro project doesn’t work (i.e., you miss the functionality you are after), the team will need to learn from this failure and then repeat the process. This is the concept of “learning cycles”—design iterations with the intention of learning from each cycle. 

Prototypes with Customers

Complex products are typically divided into subsystems and components of subsystems or partial subsystems. These partial subsystems will be the aggregate of many micro projects. As often as possible, the team needs to build prototypes of these partial subsystems to build into demonstrable system prototypes. These prototypes can be hardware or software only or a combination of both to test out the limits of the current design.

At appropriate points, with subsystems sufficiently built and demonstrable, you should be getting customer feedback on these system prototypes. You want to be sure you’re spending time and money developing something that actually provides value to the customer, not just a really cool piece of technology. Not all micro projects need to be tested with customers, but those that have a feature or a component relevant to their experience should be.

Subsystem Integration

The product team needs to be sure that what one subsystem is doing will fit with what another subsystem will do. This, of course, is the concept of system integration. However, the team should be performing small integrations during the overall development long before the complexity becomes overwhelming. They should be setting up how to test these outcomes, as those tests will be used again in larger integration testing.

Break the large stretches of work into small micro projects. When possible, build prototypes in these micro projects and demonstrate them to customers to get feedback. Importantly, when subsystems are sufficiently built, integrate them immediately with other subsystems early in the development. If all the subsystems have been vetted along the way in micro project iterations, the testing and customer validation of the whole system ultimately becomes a repeat of the many smaller pieces built and tested already. These micro projects will uncover design flaws much earlier and allow time for more design optimization than a single, big integration at the end of development.

Figure 1 illustrates how micro projects can integrate the work of three teams working on different subsystems of the same product. Some features only require the work of one team and can be integrated into the system independently. Other features (6 and 8 in the diagram) require the combined work of all three teams to function and multiple integrations will force the alignment of these teams.

Breaking Down Silo Behavior

Large, cross-functional product teams that are required for the development of complex medical devices are prone to silo behavior, which can lead to many design flaws in the resulting system. For example, an electrical engineering group designing a new board may not realize it is incompatible with a mechanical assembly being designed simultaneously by a mechanical engineering team (due to thermal problems, shielding issues, grounding, etc.). Until a large integration at a later time, the teams do not know whether their deliverables will work together. By definition, the whole point of micro projects is to identify weaknesses in how the pieces come together before integrating the final system design.

The ill-fated Eagle Project from our first column in MPO, “What Makes Complex Medical Devices Different?” relied upon a single system integration to combine subsystems developed in silos. Theoretically, that was the most efficient way to schedule the project. But it didn’t work. They discovered a large number of design flaws only at the end of scheduled development when it was the most expensive to fix. This resulted in huge delays and budget overruns for the project.

Customer and Market Check-in

Remember that a key aspect of Phase Zero was to understand the customer’s needs. That shouldn’t be the last time you check in on your direction. The market is always changing. You should be performing periodic “check-ins” of the market dynamics, especially if you are in a competitive sector. Periodic reviews can also help teams pivot more quickly when it’s clear the current product is not going to satisfy customers. Certainly, for long development cycles, the product team should be performing reviews on not only the status of the development but also the status of the market.

Daily Standups and Town Halls

Methods to enhance communication in a large product development project, with many teams working on multiple aspects of the system, help break down silos between the teams and facilitate ideas to solve problems coming from unexpected sources. Two proven methods we have seen used over the years to improve communication are daily stand-ups for individual teams and weekly or monthly town hall meetings with all of the teams for the project.

In a daily standup, usually at the beginning of the workday, each team member spends about a minute or two describing what they accomplished the previous day and what they intend to do that current day. Sometimes, they may report success or failure. Failure is always a learning experience, so it shouldn’t be avoided as something to report. Importantly, the daily standup is also an opportunity to communicate when an issue is blocking a team member’s work. The whole process should take about 30 minutes and is a good way to ensure a cadence in the project. 

In a town hall periodic meeting, the core team leader should prepare either a verbal or visual presentation of the status of the development since the last periodic meeting. The leader should then call on the respective sub-project or micro-project leaders to provide an update of their respective projects. The point here is to get dialog between different project teams to get cross-project insight for problem-solving and ideation.

Summary

Developing a new complex medical device involves considerable risks; organizing development as a series of micro projects can greatly reduce many of those risks. Micro projects also support early development of the supply chain and assembly procedures as well as test methods and test tools—all of which will speed up work in the final phases before product launch. A series of small hops is much more manageable than one big leap of faith. Don’t gamble your new product on a leap of faith.

MORE FROM THESE AUTHORS: The Power of a Common Vision in Developing Complex Medical Devices

Russ Singleton, principal consultant with Russ Singleton Consulting LLC, is based in California. He has extensive experience in VP R&D, general management, and C-suite roles in the semiconductor equipment and medtech sectors. He holds a Ph.D. and M.S. in electrical engineering from the University of Illinois and a Bachelor of Engineering from the Pratt Institute.

Aaron Joseph, principal consultant with Sunstone Pilot, is a biomedical engineer based in Waltham, Mass. With over 20 years of experience across a broad range of medical devices from surgical robotics to medical imaging to IOT and SaMD products, he helps clients efficiently tackle risk management and design controls for new product development.