Development programs are becoming more complex than ever, and advances in technology, scientific breakthroughs, regulatory change, globalization, and myriad other factors contribute to these complexities. These complexities too often compromise the ability of an organization to deliver a product as planned. For most product development programs, corporate capability is rarely aligned with the complexity of the program. Therefore, companies need to implement a structure designed to respond to factors (known as risks) that may harm delivery of a product as those factors are recognized.

The nature of a medical device under development contributes to program complexity. OEMs can contain their product's complexity by identifying and adhering to well-defined deliverables and comprehensive specifications. Doing so can constrain scope creep, which can delay product delivery. Scope creep is the natural tendency of a product's objectives to broaden as the program unfolds. The demanding environment faced by many medical device companies places pressure on program delivery. Successful execution requires a coherent and disciplined organization. Even the most experienced and skilled device companies encounter problems with their development programs.

Relentless identification, pursuit, and mitigation of risks at all stages of the program can reduce uncertainty and improve success. To bring a faltering program back on track, device companies should diagnose the situation, understand program failure modes, implement a structure that allows for effective decision making, and prevent future risks from becoming problems.

Signs of Trouble

Regardless of whether the program is device development, process improvement, or regulatory compliance, commonly encountered warning signs of a problematic program include the following:

• The 95% Complete Phenomena. The project team regularly reports that the project is close to completion but final delivery remains elusive. Confidence erodes as each milestone slips. It becomes clear that the company has no real idea when, or even whether, the program will deliver.

• Internal Friction. Team members differ about the root causes of identified risks and how to solve them. Disagreement and disunity build as people pull in different directions.

• Disengagement. Support wanes as people and their functions distance themselves from a program that has become associated with uncertainty. Disengagement by non-R&D functions means that even if the program delivers a viable product, commercialization will be hampered by reduced involvement and preparation.

• Lack of Clarity. Progress stalls as decision makers lack adequate information to support rational decision making or fail to communicate in an effective and timely manner.

Many other issues slow program delivery, but the result is always the same: internal stress, delayed deadlines, postponed launches, delayed or reduced commercial benefit, and a loss of confidence among customers and investors alike.

Device Development and Launch: What Can Be Done?

Program managers were interviewed during workshops at various industry conferences run by Cambridge Health Institute and Frost & Sullivan. They were asked about root causes for failing to deliver development programs on target. Regardless of program size or industry, leading causes of failure listed were organizational problems such as poor decision making, lack of clarity, scope creep, and poor prioritization. Technical and scientific reasons were rarely blamed.

Therefore, organizations must have the operational infrastructure and maturity commensurate with the complexity of the development program to achieve their business goals. However, it is important to note that is impossible to anticipate all twists and turns of a program. Development program risks are more dynamic in nature than engineering risks, necessitating a continuous vigilance and an appropriate infrastructure.

A Risk-Based Approach

Tackling risks early on is both more time-effective and cost-effective than responding to problems. To understand why early risk management is sensible, it is important to understand why traditional approaches are prone to delay.

During the planning stage, technical and management challenges are easily underestimated. From inception, development program plans often carry more risk than anticipated. As a program unfolds, new risks arise, and they become problems if not identified and acted on immediately. Program risks may stem from decision making, technical challenges, new regulatory constraints, resource reallocation, misalignment of deliverables between subteams, and many other factors. Ultimately, by the time a program is under way, managers are forced into a reactive stance, responding to each threat as it emerges. This reactive stance results in perpetual firefighting with little chance of regaining control.

To be effective, program managers must identify, evaluate, communicate, and prioritize risks on the basis of likelihood and severity of effect on the development program (see Table I). A risk-based approach relies on teams understanding their missions and a relentless focus on preventing problems. The program plan needs to continuously adapt as reality unfolds. Preventing problems wherever possible reduces the odds of mounting delays or setbacks.

Prevention requires identification, evaluation, documentation, and communication of risks, potential solutions, and timely decisions. This is done through a risk register, which combines failure mode and effects analysis (FMEA) principles with the following program management practices:

• Identification of program risks. Program risks need to be identified on an ongoing basis. The FMEA approach is applied to program management rather than technology implementation. Failure modes are associated with the delivery of the program. Examples of failure modes include having sufficient field staff hired to support infancy or overcoming a divide between functional groups. Because program risks tend to be more fluid than technical risks, functional team leaders should set time aside on a weekly basis to update the risk register as new situations arise.

• Evaluation of risks. The evaluation is based on scoring the likelihood of and effect of the risks on the program, similar to FMEA already in use by most medical device organizations. One challenge is that OEMs must be able to come to consistent ratings outside the technical disciplines. It is important to establish rules to rate technical, clinical, regulatory, or marketing risks in a consistent manner.

• Communication of risks is a continuous process. Teams and departments should update their risk profiles and communicate them as part of their weekly updates to the program management office. The office in turn should assemble and communicate the highest-ranking issues to management. The risk owners will then be asked to present their case. Management should always be intimately familiar with at least the dozen top-scoring risks a development program faces.

• Because the risk register combines FMEA with responsibility and proposed solutions, ownership of resolution is inherent with reporting a risk. Management should provide the risk owner with the authority to act, or it should reassign the risk to the proper owner. The organization must be equipped with the communication tools to elevate and act on risks before they become problems.

With the risk register in place, task management can be deemphasized in favor of risk management using a simple tool set. This is not to deny that task management has an important place when managing development projects. However, as long as the teams understand their missions, program management can spend their energy helping maintain clarity and facilitating decision making. Note that tasks not completed on time rapidly become risks to the program and thus should come back into focus.

For example, consider a medical systems provider that needs to accelerate the launch of a complex system to select customers in order to maintain good standing with the shareholders. Unfortunately, not all reliability problems can be resolved prior to launch. The company could either delay launch or launch with a system of limited reliability. Brainstorming identifies weekly preventive maintenance at each customer site as a temporary solution. This requires increased in-field service coverage, but the instrument gains a positive reputation because the customers did not suffer unanticipated downtime.

Compliance

Scope creep, decision making, and communication are often mentioned as reasons for program failure. These issues also have a significant effect on a company's regulatory risk profile.

Scope creep takes a development program beyond documented deliverables and specifications. At a minimum, scope creep requires a rework of documentation. Any rework of documentation, process, or product increases the chance for error. For example, in one company's case, scope was partially driven by regulatory strategy. A predicate device dictated the maximum acceptable flow rate requirement for a drug-delivery device. The predicate device was a continuous-flow device, whereas the drug-delivery device delivered small-volume batches. Staying within the flow rate limits avoided costly and time-consuming clinical safety studies. Imagine what would have happened to the program if scope creep had resulted in a faster device.

When responding to regulatory audit observations, it is equally important to understand how to set things right. This cannot be done solely by the regulatory or quality departments. Cross-functional teamwork, correct casting of scope, communicating risks, and measurable goals will help deliver full benefits.

One medical device manufacturer was under FDA scrutiny for its calibration program. A year after the FDA audit, management became aware that the proclaimed solutions were not effective, largely because of an inadequate management model, lack of dedicated quality assurance support, and a number of other factors. Mapping the risks to the department, implementing appropriate performance metrics, and a dedicated cross-functional task team that leaned on experts from sister organizations allowed the department to pass an internal audit three months later.

Compliance does not need to be viewed as a business cost. However, it can enhance progress when properly positioned within the program management framework.

Diagnosis is the first step in implementing risk-based program management (see Figure 1). A small but highly experienced team can diagnose and implement the approach with the goal of having the delivery team regain efficiency as quickly as possible. The independent team needs to perform a holistic review of the program, assessing its health at both detailed and summary levels. The team should also quantify existing risks to its success. The holistic nature of this view is crucial; all functional stakeholders need to be involved.

The result is a first-pass delivery strategy, complete with well-prioritized tactics and prioritized risk register. Activities and a risks that have little or no effect on key themes can be deferred.

Imagine a small biotech and drug-delivery company in Phase II clinical trials. The diagnosis identifies that outside of the development, clinical, and regulatory departments, the organization is not prepared for commercialization. Analysis reveals that the lack of readiness is a result of the product development being ahead of schedule. Identifying risks enables the organization to implement a program management process that allows the client to achieve readiness in time for launch.

The key is to implement thorough remediation initiatives as soon as possible. Medical device companies cannot place development programs on hold while they wait for a full diagnosis to be completed. From day one, the delivery team must be provided with meaningful direction to sustain momentum and commitment.

After diagnosis, the risk-based approach centers on creating a fit for program management infrastructure to establish clear communications and effective decision making throughout the organization. Although the primary task of the program management office is risk mitigation, the office also plays a key role in keeping the teams focused. Because the approach drives responsibility back to the task owners, the program management office requires relatively modest resources.

In many organizations, program management tools are based on a combination of Microsoft Excel and Microsoft Project applications. Communication and program and risk management tools should be kept simple, using applications that all team members are familiar and comfortable with.

A company developing a next-generation production process for a cardiac implant decided to implement an elaborate Gantt chart program with all interdependencies linked and stored in the e-room. The result was that only one person could work on the plan at a time, and ultimately ownership and commitment were lost. In all cases, clarity should trump sophistication, and the right level of abstraction must be found.

The goal is to incorporate risk-based management techniques into daily operations at all levels (see Figure 2). This drives the implementation of a reliable, unambiguous plan, where objectives and responsibilities are directly attached to the delivery strategy. Implementing open and clear communication methods, such as dashboards and metrics, allows for identification, quantification, and communication of information through the program management office.

One strategy is to post the same graphical summary of the delivery plan in locations from the boardroom to the assembly floor. That way, everyone understands and refers to the same plan as part of their daily activities. Each team also understands how their deliverables affect other parts of the program. The teams may be able to stay off the critical path by recognizing and communicating potential setbacks, and received the empowerment needed to take corrective actions. The string of events that determines the shortest duration to delivery is known as the critical path. If an item on the critical path takes longer than expected to complete, the program will be delayed. An activity not on the critical path can take longer, but it will not affect the delivery date.

This approach can help achieve companywide readiness, meaning that the business as a whole makes timely preparations for launch. To achieve complete readiness, however, companies should institute cross-functional teams, incorporating commercial, technical, scientific, and organizational disciplines. To keep the program on track, all functional groups should be rated on their readiness for launch, identifying resource and knowledge gaps that must be addressed before they affect the critical path.

The Importance of Communication

A prerequisite for achieving clear communications and improved decision making is the implementation of a framework that allows risks to be quantified objectively. Effective communications tools include the action-oriented and metrics-driven dashboards mentioned earlier. Tools used should enable fact-based decision making, promoting a continuous focus on risk recognition and reduction. Communications should be aimed at the intended audience and should clearly state what action is requested. Effective communications result in clear and verifiable action.

Applying the Risk-Based Approach

This methodology cannot be applied mechanistically. To gain rapid benefit, an organization's internal best practices should be retained as long as possible. New tools and techniques that strengthen familiar approaches should be applied.

A program management office's integrity and independence are key for effective implementation. An impartial diagnostic view across departments removes the optimistic cast that results from internal best intentions.

Effective risk management requires natural optimism to be challenged by a healthy dose of realism. An optimistic worldview may hide substantial risks to the program. The program management office must maintain an impartial, if skeptical role. It should be continuously challenging the subteams while also providing recognition for achievements.

Counting the Benefits

Even deeply troubled product development programs can be put back on track by using a risk-based approach.

Rigorous focus on high-risk areas that are critical to success areas enables this kind of breakthrough. Because the approach draws on an entire organization rather than just the R&D team, it ensures that when the product is ready, the remainder of the company is also ready. In addition to securing the involvement of internal functions, such as marketing and regulatory, companies need to take into account external stakeholders such as regulatory agents and customers. Doing so can ensure that the transition from R&D to manufacturing and launch is smooth in every respect.

Risk-based program management makes it possible to gain control and confidence even when the development process is starting from apparent chaos. Once the program is in control, it must be kept on course by continuing to actively manage risk. There are a number of ways risk can be managed. Continuous management of program risks allows organizations to more-effectively respond to unfolding reality. Integrating FMEA methods via a risk register allows management to keep track of all risks to the program. Knowing the likelihood of the risk and the severity of its potential effect helps determine how and at what level of the organization decisions need to be made. However, the leadership team must be knowledgeable about the top risks faced by the program. Open communication of risks and clearly communicated decisions can help ensure that they do.

Hein Smit Sibinga is a principal consultant for PA Consulting Group (Cambridge, MA). Reach him via e-mail at [email protected].

Copyright ©2006 Medical Device & Diagnostic Industry