Regulation and Technology Innovation: A Comparison of Stated and Formal Regulatory Barriers throughout the Technology Innovation Process

Regulation is often mentioned as a barrier to technology innovation in various industries. Delayed market entry, stifled creativity, added activities and resource requirements are some frequently mentioned barriers. The study presented here explored various claims of regulation acting as a barrier to technology innovation. The findings suggest that formal statutory requirements only partly explain why regulation is perceived as a technology innovation barrier. Findings further indicate several discrepancies between stated and formal regulatory barriers and suggest that the majority of the stated barriers emerge within the organization during operationalization and the technology innovation process.


Introduction
Many firms conduct their technology innovation activities in a regulatory environment affected by various rules and directives maintained and upheld by an authority.The impact of these regulations on a firm's technology innovation activities can be both positive as well as negative depending on various industry and firm characteristics (Dodgson, Gann, & Salter, 2008), as well as technological characteristics (Ashford & Heaton, 1983).
Although clear that regulation can negatively impact technology innovation in a wide range of industries (Rothwell, 1980;Ashford & Heaton, 1983), the reason why it does so is less clear.Findings suggest that the negative impact on technology innovation is most noticeable in industries with standards for minimum quality, safety, and efficacy (Maxwell, 1998;Hall & Bagchi-Sen, 2002), especially when regulation is too rigidly imposed or administratively complicated (Pearce & Turner, 1984), or when it limits and encumbers technology related activities and outcomes (Garud & Rappa, 1994).
However, findings showing that regulation stifles technology innovation often relies on perceptual measures (e.g.Hauptman & Roberts, 1987).Little concrete evidence exists in support of the widespread perception within certain industries that regulation negatively impacts technology innovation (Ashford & Heaton, 1983).Furthermore, a closer examination of the perceptual measures reveal that statements of regulation as a barrier to technology innovation tends to diminish over time within individual firms (Hauptman & Roberts, 1987).Increasingly, investigations have suggested that regulation in itself does not stifle technology innovation, but rather attempts of its operationalization (Ashford & Heaton, 1983;Georg, Røpke, & Jørgensen, 1992;Hadjimanolis, 2003;Herzlinger, 2006).To this background, the study presented in this paper investigates how well stated regulatory barriers coincide with formal regulatory requirements during the technology development process.Of principal interest is to increase our understanding of underlying causes regarding possible discrepancies.Relying on an insider-outsider research approach (see Louis & Bartunek, 1992) we conducted an indepth case study at a large multinational medical device company.Our case is suitable for four reasons.First, the medical device industry is characteristic of an industry where regulation is often reported as a key barrier to technology innovation (Eisenberg, 2007;Kaplan et al., 2004).Second, the case is situated in a low-velocity industry environment thus mitigating the risk of regulatory barriers stemming from outdated regulations.Third, the case company was recently subjected to regulatory inspection and risked restrictions on key markets.Finally, one of the authors has worked with technology innovation within the case company since 2006.

Method
Our investigation is based on desk research, interviews, and an in-depth case study.One author (hereafter called the insider) has nine years of experience in various roles related to technology development and quality management at the case company, a multinational with USD 3.2 billion in turnover and nearly 16,000 employees in 2015 (upon request, all information pertaining to the company is made anonymous).The insider's vocational experiences include but are not limited to: the development of a new quality system, participation in several technology innovation projects, as well as involvement in several regulatory audits conducted at the case company.This ensured contextual knowledge related to the handling, understanding, and operationalization of regulatory frameworks deemed necessary for the aim of this study.
The second stage involved interviews.We selected the following representatives from functional areas associated with technology innovation and regulation: 1) R&D manager, 2) technical manager, 3) site manager, 4) regulatory and quality assurance manager, 5) project manager, 6) three new product development (NPD) engineers, 7) and a former FDA inspector.These interviews were transcribed and analyzed to identify statements related to regulation inhibiting technology innovation.Statements were initially identified in terms of impacting the outcome or the process of technology innovation, and then grouped into categories that we coded based on the statements.For example, a statement regarding submittal time would be coded under 'time to market' .Statements could include examples of impact and individual opinions and beliefs about their own work and the work of others.The aim was not to collect evidence for the inhibitors found during the previous desk research stage, but to collect data on the various ways individuals reported regulation as a barrier.
Finally, we compared and contrasted the findings from the two previous stages by sorting the ways regulation reportedly inhibited technical innovation, i.e. stated barriers, as well as assess the degree of concrete mention in regulatory text, i.e. regulatory requirements.We relied on the stage gate model of technology innovation to guide us in this effort to compare stated and concrete examples of formal regulatory requirements.

Regulation and the technology innovation process
According to the 2003 PDMA study, firms increasingly rely on formal product development processes (Barczak, Griffin, & Kahn, 2009).One commonly used method is to treat technology development as occurring in several stages.The exact nature of what these stages looks like is industry and firm specific, but generally they include: discovery, scoping, build business case, development, testing and validation, followed by launch and post-launch review (Cooper, 2008;Cooper, Edgett, & Kleinschmidt, 2002).
In industries where regulation has a high impact on technology development, e.g. the clean technology industry (Pearce & Turner, 1984), the chemical industry (Ashford & Heaton, 1983), and the medical devices industry (Eisenberg, 2007;Kaplan et al., 2004), these stages and gates consider regulation to a higher degree (for an example see Pietzsch, Shluzas, Paté-Cornell, Yock, & Linehan, 2009).For industries sharing a focus on minimum quality standards, safety and efficacy, the regulatory barriers are quite similar.Minimum quality standards are enforced through quality management systems and/or directly on products, and necessitate steps for how to establish evidence of safety, efficacy and quality controls during the product lifecycle.
Regulation can thus directly limit technology innovation outcomes as well as the processes involved in providing evidence of safety and efficacy claims.These processes are often both costly and time consuming and increase risks associated with technology innovation (Kaplan et al., 2004).Similarly, regulatory compliance often requires manufacturers and developers to ensure that the manufacturing outputs in question, as well as associated activities, are compliant with statutes.Furthermore, given the vast amount of manufacturing outputs covered by regulatory frameworks, manufacturers often have problems navigating the regulatory text.Also, the applicability of a statute normally varies throughout the technology innovation process.In order to facilitate further reading, we now present the case-specific context of medical devices development.
Medical devices that are marketed in the U.S. are regulated by the FDA.In the case of the FDA, quality standards, safety, and efficacy are ensured through four main statutes: 1) Premarket Notification, otherwise known as the 510(k), 2) Premarket Approval (PMA), 3) Investigational Device Exemption (IDE), and 4) Quality System Regulation (QSR).The 510(k) and the PMA achieve their purpose of ensuring product safety and efficacy by requiring medical device manufacturers to demonstrate that a new device is substantially equivalent to an already approved device, or by using for instance clinical studies to demonstrate that the new device is safe and effective for intended use.Finally, the QSR dictates requirements on the quality management system (QMS) that requires various organizational activities, such as documentation, as well as by provides specifications for technology innovation activities and outcomes.The relevance of a certain statute depends on two things: 1) the risk classification of the medical device (ranging from 1-4 on major markets) where larger numbers signify greater risk, and correspondingly more rigorous regulatory requirements, and 2) the stage of the medical device development process.
To this background, we will adopt the adaptation of Pietzsch et al. (2009) of the stage-gate process consisting of five major stages: I) initiation, opportunity, and risk analysis, II) formulation, concept, and feasibility, III) design and development, and verification and validation, IV) final validation and launch preparation, and V) launch and post-launch assessment.Given that Stage III contains regulatory submission, we omit the last two stages given that the majority of technology development takes place in the first three.In the next section, we present our case findings.

Case findings
Below we account for our case findings by describing each of the three stages in terms of their formal regulatory requirements as well as the stated barriers.

Stage I and regulatory requirements
Stage I involves activities focused on user need identification and idea screening activities such as intellectual property (IP) reviews, preliminary market analysis, and estimations of clinical impact.To ensure efficacy, needs need to be verified.Such a verification process may involve talking to physicians, patients and technology users, as well as direct observation in clinical settings.Stage I also involves a review of existing solutions as well as continued activities aimed at market assessment.Finally, Stage I contains initial assessments of technology risks as well as potential regulatory paths.Formally, he FDA does not impact any of the activities in Stage I, but later regulatory steps depend on applicants being able to show documentation of need verification and risk assessment (see Stage II).

Stage I and stated barriers
Stage I mostly lacks formal regulatory requirements.However, a quality and regulatory assurance manager told us that "people complain about for instance design control limiting their work during phases when it does not even apply".Similarly, a former FDA inspector told us that "much of the impact is due to work being done that the FDA does not specifically require".One example of such unnecessary work is found during the early product concept development.NPD engineers were complaining that "the design control limits early creativity" in terms of product design.Formally, design control starts with Stage II.
The only formal requirement impacting Stage I is associated with documentation of need verification and risk assessment.The FDA does not specify steps for conducting such a need verification and risk assessment.Instead, companies rely on tools such as quality function deployment to map customer expectations and needs into processes and parameters that will fulfill them, and basic failure effect mode analysis to assess the risk of product concepts.
Finally, firms normally consider the radicalness of the proposed technology and the preferred market entry model during Stage I. Depending on a company's R&D strategy and product portfolio, developers focus on certain risk classes when developing medical devices.Such a focus was mentioned by the R&D manager to be "a barrier to more radical innovation".But the statutes do not limit a company's development efforts per se, but rather detail what the regulatory process looks like leading to approval.The choice of preferred class is determined by various functional strategies.

Stage II and regulatory requirements
Stage II includes development activities that start once the development project is approved.The main focus is on concept formulation and feasibility assessment.These activities are the first to be subject to regulation in the form of design controls and are formally regulated by 21 CFR 820.30.One specific requirement is the creation and maintenance of a design history file (DHF) indicating that the device is developed in accordance to a previously approved design plan.One important step is to document user inputs that impact design choices.Common sources for such input are existing product complaints or meetings with potential end users such as doctors, technicians and nurses.Furthermore, user input can also include information related to the intended use, testing requirements, biocompatibility requirements, and requirements related to the physical aspects of the final device.The purpose is to verify user needs as inputs to the design process and to ensure that these are secured by design choices.
As with most technology development, medical devices development is marked by iterations and frequent changes.Computational models (such as finite element analysis), although not formally required, are often used in this development stage to ensure that verified needs are met and that risks are controlled.Formally, the FDA requires that the DHF is maintained to ensure that such changes do not compromise the ability to satisfy an identified need, or affect the risk of the product.In addition, the FDA requires continuous design reviews throughout the design process.Finally, the FDA requires a risk analysis where risks are identified and mitigated to the level that corresponds or improves upon existing products used for the same purpose.
In sum, Stage II marks the beginning of formal requirements.Although requirements, such as risk analysis, are not specified in terms of process steps, there exist industry standards for how such a risk analysis should be conducted (e.g.ISO 14971).Several tools, such as Failure Mode Effect Analysis (FMEA) and Fault Tree Analysis (FTA), are commonly adopted to conduct and manage risk analysis during Stage II.

Stage II and stated barriers
Our findings suggest that this stage is perceived to be quite problematic.Issues related to encumbering activities, bothersome quality systems, and limitations to product designs were examples mentioned.We will now elaborate on each.
As for encumbering activities, NPD engineers reported that the documentation associated with Stage II is cumbersome and ties up important resources from other value-adding tasks.One NPD engineer reported that "the documentation has been drafted from scratch three times" when referring to documentation during early design related activities.Another stated that "we spend a lot of time documenting why we did not have time to do things.Ironically, we did not have the time to do them because we were documenting".Similar sentiments were expressed by others as well and it was not only the rework that was seen as problematic, but also the amount of work done.
However, the FDA does not specify documentation amount or procedures.Both the former FDA inspector and a regulatory and quality assurance manager argued that rework can be avoided by doing things correctly from the start and that the need for such rework and amounts of documentation stemmed from a lack of regulatory knowledge and not from any statute.In fact, the guidelines and procedures for documentation are directly governed by the organization's quality system and not the FDA, thus suggesting that regulatory barriers might emerge during the translation of FDA requirements into the QMS.
As for statements related to a bothersome QMS, NPD engineers reported that "the quality system is in the way of NPD".Much of this relates to the various encumbering activities mentioned above.However, when asked about this statement, the project manager argued that "the problem is that many people working here do not really understand what the regulations are for and they only see it as a big problem".The former FDA inspector added that "people in R&D do not understand the regulation [and] are reluctant to have controls enforced upon them".Both suggest that such a lack of knowledge may further lead to a negative attitude towards regulation.
However, whilst such a lack of knowledge may explain the NPD engineers needing to redraft documents based on an existing QMS procedure, it does not adequately explain why the QMS itself changed during the medical device development process.When asked about the three redrafts as mentioned by the NPD engineer, the regulatory and quality assurance manager stated that "of course we change our processes and templates if something is not working, it is a continuous quest of improvement" and more generally that "we try to develop foolproof procedures and templates, but we are always lagging behind the projects".Such statements suggest that the barrier may not solely reside in the lack of regulatory knowledge among NPD engineers, but also in a lack of knowledge around the NPD process among regulatory and quality function staff.
Finally, issues were also mentioned in relation to product design limitations.The choice of preferred regulatory pathway limits product development outputs to certain classes of medical devices.During one product development meeting, a number of technical alterations were suggested in order to improve the product.The technical manager responded that "those alterations should be avoided since they may have an impact on the intended use, and then we need to submit a new 510(k)".However, no further inquiry was conducted to investigate whether or not the alterations would, in fact, impact on intended use or if they would require a new 510(k) submittal.The insider argues that similar cases are common and that there is a tendency to try to stay on the safe side, thus exacerbating any regulatory barrier that may actually exist.

Stage III and regulatory requirements
Stage III starts after the formulation of a product concept and several rounds of prototyping.Activities during this stage are aimed at design and development, and verification and validation.The FDA requires documentation of all verification and validation activities to the extent that they are reproducible.Design verification involves activities that ensure that design outputs satisfy design inputs, that it is compliant with the QMS, and that it is suitable given associated activities such as packaging, shipping, cleaning etc. Design validation activities aim to ensure that user needs are met.These activities include use tests and the investigation of human factors and user interfaces to assess potential issues that arise during everyday usage.Finally, design control deliverables, such as product FMEA is updated during Stage III, as is the addition of process FMEA to satisfy QSR requirements of Good Manufacturing Practices.Stage III, and our study, ends with a decision to no longer alter the product design prior to launch, and a submission of test and design data to the FDA for regulatory approval.

Stage III and stated barriers
Based on statutes, Stage III requirements are rather similar to the Stage II ones.One additional concrete barrier is the submittal time.However, the R&D manager stated that "submittal processing time is a well-known fact and easy to plan around" suggesting that it may not be perceived as a substantial barrier.However, the amount of documentation needed for the DHF is considered more problematic.One NPD engineer pointed at two shelves of binders and told us "look at that, that is for one project".Furthermore, as argued by both the NPD engineer as well as the project manager, the provided resources are not enough to match the additional demands from such activities.
However, the site manager stated that "it cannot be required by a sound quality system to generate this amount of documentation when developing these products".The FDA itself does not specify the amount of documentation; rather it is during the establishment of the QMS that the specifications and routines for documentation are developed.In the following section, we synthesize our findings of stated and formal regulatory demands.

Discussion
In Figure 1, we present our adaptation of the stage-gate (see Cooper, Edgett, & Kleinschmidt, 2002) model of technology innovation to more specifically focus on regulation as a barrier.The model shows how product development, formal regulatory requirements, and stated regulatory barriers unfold over the tree stages included in our study.
Although differences are expected to exist between different technology types, we argue that our findings are generally applicable to a variety of industries where regulation is perceived as a barrier to technology innovation.Our findings are not meant to generalize the regulatory barriers themselves, but rather to examine why regulation is perceived as a barrier, and to what extent the stated barriers correspond with formal regulatory requirements.As such, we believe that insights of this kind are more broadly applicable to a wide range of industries where regulation aims to ensure safety, quality and efficacy of technology innovation outputs.
Our findings regarding barriers can be divided into three categories based on requirement source: 1. Formal requirement: the majority of stated barriers did not correspond to formal regulatory requirements.The only one we identified was the submittal processing time, which was mentioned as "a well-known fact and easy to plan around".2. Derived requirement: several stated barriers may be derived from formal regulatory requirements.These are: documentation amount, substantial equivalence limits design choices, and difficulties with the QMS.
3. No requirement: the majority of stated barriers could not be linked to any formal regulatory requirement.These stated barrier include: redrafting documents, design controls limiting early creativity, lack of understanding and knowledge, that the QMS and regulatory experts are in the way of NPD, people in R&D actively rejecting rule bound work environments, and that regulation necessitates unnecessary rework.
In addition, our findings can also be grouped into four categories based on the underlying cause of the stated barrier (Table 1): a) impacting activities, b) limiting design choices, c) knowledge requirements, and d) role assumptions and attitudes.Whilst it is possible to argue for overlaps, we treat them as separate for the sake of parsimony.So, what can managers do?Below we will provide recommendations based on the underlying cause as well as the specific stage of the development process.
The first, impacting activities, mainly impacts Stage II and III.In order to overcome stated barriers of this type, we provide the following advice: • Project evaluations.Solely relying on cost and timing metrics is not enough.Instead, continuous evaluations should be performed of regulatory compliance status using internal audits and assessments of project documentation.Resulting feedback should be presented to all those involved in the development project.This way, an early lack of documentation, e.g.need verification, may be addressed timely and without incurring additional costs further down the process.

•
Underperforming projects.Remedial actions should always consider regulatory consequences.Whilst it may be tempting to let projects pass a decision point without adequate regulatory groundwork, things may eventually get out of order.
• Prevention and planning.Ensure that applicable QMS procedures as well as the design plan are compliant with regulations whilst remaining as lean as possible before moving into Stage III.
To achieve this, the various functional representatives all need to understand and accept the QMS and the design plan.If they do not, it is a sign to be taken seriously.Finally, it is important that the development team continuously revisits design plans and relevant QMS procedures during development.
The second, limiting design choices, mainly impacts Stage I and II.
In order to overcome stated barriers of this type, we provide the following advice: • Do not constrain idea generation too early.Early on, it is important to encourage conceptual and creative thinking.In order to allow for such thinking, and to avoid limiting design choices early on, developers should decide on the regulatory path towards the end of Stage I. On a related note, it is equally important that once limitations are imposed, they fall within the regulatory pathway without being over-engineered.
The third, knowledge requirements, seems to impact all stages.In order to overcome stated barriers of this type, we provide the following advice: • Training and development.Employees must have sufficient understanding of regulations in order to perform their work.This applies to both development-oriented staff in terms of regulatory compliance, as well as for regulatory and quality assurance staff in terms of technology innovation processes.The aim is to detail procedures that comply with regulations, whilst at the same time being as lean as possible.The use of cross-functional teams is particularly encouraged.Regulatory requirements may then hopefully be viewed as common sense practices rather than encumbering activities.
• Know the boundaries.Regulatory compliance should not be encumbered and complicated through stricter than necessary control practices.This is especially important during the development and implementation of the QMS.
The fourth and final, role assumptions and attitudes, seems to impact all stages.In order to overcome stated barriers of this type, we provide the following advice: • Promote a quality culture.Senior management needs to promote a quality culture where employees can embrace regulation as a means to ensure safe and high-quality products.This involves for instance setting up a suitable forum for quality concerns to be voiced where employees can speak out freely.It also involves letting everyone know that quality is key and aligning incentives accordingly.
• Cross-functional teams.Including regulatory and quality assurance staff in development teams from the start facilitates compliance and turns regulatory and quality assurance into a supporting partner rather than a final approving body.This promotes the aforementioned quality culture and ensures that regulatory compliance is seen as supportive for good work practices rather than as a barrier.
• Shared assumptions.Be vary of shared assumptions that emerge during early periods when knowledge is low.Various functional representatives will develop shared assumptions about the QMS and regulation in general.These shared assumptions may surface as taken for granted truths about for instance degree of documentation, that rework is a natural part of the process, or how evaluation systems look like.Unless dealt with, these shared assumptions may potentially underlie many of stated barriers.
Given the limitations of single case studies, the degree to which the above-stated recommendations are generally applicable may vary.However, on a general level, we urge managers to become more aware of the perceived nature of regulation as a barrier to innovation.Furthermore, in light of our findings we argue that the impact of regulation on innovation may also be determined by the extent to which the regulatory guidelines are general or specific.Our findings suggest that when the aim is to provide a general framework, as in the case of FDA, then barriers may be constructed during the translation of such a general framework into firm-specific activities.

Conclusions
The perception that regulation is a barrier to technology innovation is widespread in some industries.In order to stay competitive, firms operating in such industries must overcome the barriers associated with regulation.By investigating an organization recently subject to a regulatory inspection with costly outcomes, we found a large discrepancy between stated barriers and formal regulatory requirements.Therefore, it is important not to interpret regulation as solely a barrier external to the organization, but rather to focus on how the organization interprets and translates regulatory requirements during their operationalization.

Submitted
June 22th 2015 / Approved October 7th 2015 1 Department of Innovation Management, School of Business, Engineering and Science, Halmstad University, Halmstad, Sweden 2 Department of Technology Management and Economics, Chalmers University of Technology, Gothenburg, Sweden.*Corresponding author: peter.altmann@chalmers.se

Figure 1 .
Figure 1.An overview of product development activities, formal regulatory requirements, and stated barriers.