In the first article of this series (May 2011), the foundation for successful projects was explored, which includes having great people, a supportive company structure and a culture of collaboration to create fertile ground for innovation. Even with this foundation in place, projects constantly are threatened by the enemies of innovation, creating challenges for even the most seasoned development professionals.
This installment discusses how to build the organizational skills to recognize and understand these threats and how they impact development progress, which is critical to avoiding failure and maintaining a high level of project performance.
Classic Pitfalls and Red Flags
Most development efforts—especially those that have truly innovative goals—start with a high degree of uncertainty and ambiguity. This degree of challenge is intrinsic in the effort when creating something novel of high value. Even with a realistic understanding of the challenges ahead, it is not unusual for teams to have optimistic expectations of the results and the probability for success. These expectations are established at project start and rarely accommodate the very real ambiguity of the effort about to be undertaken. And, these expectations often cancreate immovable attributes within a project that set up numerous pitfalls throughout the development process.
Specific performance endpoints, marketing data, competitive actions, shifting demographics, and the dynamics of organizational shuffling all combine to create high variability throughout the process.
Development inputs are not static and could be represented as a quadratic equation for uncertainty that changes constantly throughout the lifecycle. Pitfalls typically are understood in retrospect.
However, if a team can recognize red flags indicating a crisis in the making, these threats to success can be avoided.
Overly Optimistic Expectations
All great development projects start with highly optimistic expectations by the stakeholders. An optimistic outlook is absolutely necessary. Without it, projects would never get off the launch pad. There are expectations of how well the team will perform, how well the company will do in the market and how the product will improve the quality of care or save lives. Inherent in these expectations are assumptions about the realities of product development. At inception of a program, expectations seem to get set in stone and are based on incomplete, ambiguous and highly variable information without consideration of many of these realities.
Typically, the biggest concern or attention is given to the endpoint connected to these expectations, not necessarily what happens between inception and completion. Without intermediate checkpoints to re-evaluate or adjust expectations on how development has evolved, expectations can become misaligned. For example, most projects start late or gain momentum slowly and simply take longer to complete than expected. Without checkpoints, it is easy for key milestone expectations—such as release to clinical testing or market launch—to become misaligned. This can result in extreme pressure on resources to make up for a late start or limit the opportunity for innovation and optimization to naturally mature within the project scope.
Requirements release is another point in the process that absolutely is critical. Requirements drive all scale and scope of the project. Expectations set prior to requirements completion are bound to be misaligned and/or overly optimistic in what can be accomplished within available resources and time. Collaborative participation by all stakeholders during this critical part of the process help ensure good requirements elaboration but also mutually shared expectations.
Finally, integration testing is a highly non-deterministic activity with complex and novel solution sets, making it another common driver of expectation misalignment. For example, simply determining if a system error during integration is related to a hardware or software bug can be laborious and relatively unpredictable. Even when identified, the correction to fix the issue once implemented may have unintended consequences that need further evaluation. The uncertainty related to this process can challenge prior expectations around the level of effort and time needed to verify functionality.
Optimism is necessary by everyone on the team, but expectations need to be tempered with an understanding that they may be built on incomplete information and with an awareness of actual progress at critical checkpoints. Creating a checkpoint-driven process—along with active executive management engagement—will help create realistic expectations that can be met at program launch.
Immature Technology
Creating a competitive advantage for most medical device companies requires the predictable introduction of new products into the marketplace. Large untapped markets or competitive pressures ensure the constant research and development of unique technology-based products to address unmet or underserved needs. The pressure to bring these innovative new products to market requires today’s medical device companies to be skilled evaluators and incorporators of new technology.
There are myriad examples of failed commercialization efforts that were perpetually hung up or crashed because the technology didn’t work as advertised or was never reduced to practice appropriately to validate the utility of a patented idea. Many times, it is assumed that the basic science is ready for “productization” or that if the application worked for one particular purpose, it should work for another. Plenty of development dollars have been ineffectively invested only to find that the core functionality fell short of what was anticipated. One should carefully scrutinize development efforts that have parallel proof-of-concept and commercialization efforts.
Additionally, programs that dependon reusing a technology currently underdevelopment on another project should be on guard. Implementation of an iterative validation-of-technology-readiness effort should be considered to ensure the technology can be applied in a commercialformat. Early breadboarding of the technology in the envisioned commercial configuration—along with rigorous early testing of high-risk-critical subsystems—also should be incorporated into programs with a new or complex technology embodiment. This iterative approach not only avoids all out downstream failure, but also supports truly innovative product development and design solution optimization.
Poor Requirements Management
Disciplined medical device development mandates that requirements be determined in advance of formal design activities. However, there is little guidance about how to create a good requirements document and how to best manageongoing variability throughout the development process. This is particularly challenging with software development where features can be implemented a dozen different and interdependent ways, chewing up schedule and resources and hanging up integration.
There are appropriate points in the development continuum for requirements to be re-evaluated and one can always make changes, but there can be significant negative consequences for doing so continuously or late in the development cycle. Reluctance to adjust schedule, costs or reduce other requirements or features as a trade-off in order to make these changes is a red flag that trouble is coming.
It may be prudent to build in a visible schedule contingency to absorb some changes and allow for typical requirement variances. Poor controls or lack of a mechanism to manage changes due to market, user or competitor inputs will drive the program off the rails or, best case, limit the potential performance of the product.
It is extremely helpful to implement a formal feature or functional comparative trade-off study as part of product architecture, in parallel with requirements development, to create a stable program. This study also provides the opportunity to prioritize features for inclusion or incremental release such that an order can be used to indicate what is possible given resource and schedule constraints. Prioritization also can serve as a tool to provide management visibility on what they may have to sacrifice given a trade-off opportunity between two configurations or a late requirement implementation. This prioritization can even provide options on what additional features could be included with an increased investment of budget or time.
Finally, in addition to avoiding development crisis, implementing such a process can become a strategic tool for late or changing marketing input or to counter a new competitive product offering.
Resource Silos & Reorganizations
Development of truly great products requires that the process be fully informed by all stakeholders. These stakeholders must be a stable team of very capable people able to provide critical input and timely guidance during the entire project. Successful projects exhibit this characteristic with a focused and dedicated team representing all of the major functions of the business. Projects that receive late input from one or several functional areas of the organization, or are under-represented in the process, typically suffer severe, expensive and avoidable course changes. Many times these issues arise when the team is unstable due to a lack of—or changes in—key contributors due to reorganizations, resource structures, poor allocation management or cultural issues associated with functional silos.
Resources applied to form a matrix or lightweight team can be problematic if not outright dysfunctional.
Rather, creating heavyweight teams that only are focused on that particular project is a key to optimal innovation and project success.
A change in project ownership, program management or executive sponsorship is a clear red flag that issues soon will arise. There is a tempo that a team achieves once underway, and a major change to a core team member can completely change the cadence of the project. Additionally, this can be tied back to expectations and requirement management issues identified above. Different ownership or sponsorship of the project certainly will manifest different expectations and priorities, which will effect execution and momentum. Teams need to be aware of these issues and make provisions in the event there is a change of project ownership or if a key contributing function is missing from the process due to organizational issues.
Next Step: High-Performance Advanced Development
Now that the organizational skills to recognize and understand pitfalls and red flags have been built, one can counter these threats and maintain successful performance. Additionally, once this development maturity is consistently achieved, more advanced methodologies can be used effectively to take development to new levels of innovation. In combination with the strong foundation discussed in article one and with skills to insulate from threats as discussed above, high-performance advanced development activities (to be discussedin the next column) will create optimal innovation, product excellence and ultimate success in the marketplace.
With more than 20 years of experience as a business manager and engineer, Sean MacLeod is an expert in systems engineering, product strategy, new product development and venture starts. He is an evangelist of progressive product management practices. After holding positions in engineering, business development and marketing, Sean was appointed president of Stratos in 2004. He holds an MBA from the Foster School of Business at the University of Washington and a B.S. in Mechanical Engineering from the University of Massachusetts, Amherst. He regularly lectures for business and engineering programs including those at the University of Washington, the University of Oregon and the Rochester Institute of Technology. Prior to joining Stratos in 1994, MacLeod worked as a consultant in the aerospace industry and was an engineer with United Technologies Corporation.