Theory Methodological reflection on Case Study 2

projects, without any restriction in terms of geography, economic sec- tor, time, etc. Testing the theory for this large domain, therefore, would require a vast number of replications. Later in Case Study 2 it was suggested that the domain must be restricted to physical products and may not apply to software products. In Case Study 2, the concept “success” was defined relative to the pro- ject’s aims and expectations. It was defined as a result that is as expected, or better. Therefore, success is relative to the level of expectations or ambitions at the start of the project. Having a low level of expectations increases the chance of success. Test results are, therefore, only valid for this specific type of success. In order to avoid misunderstandings regard- ing the claims of the theory and the interpretation of test results, another label for this concept could be “satisfaction with result”.

5.5.2 Research objective

The objective of the research was to test a new theory. The proposition to be tested was new and had never been tested before. Hence the study could be characterized as initial theory-testing research.

5.5.3 Research strategy

The proposition specified necessary conditions for success. The pre- ferred research strategy for testing necessary conditions is the experi- ment. The second-best research strategy is the single case study. The preferred replication strategy is a serial one in which each proposition is tested before the next case is selected. The study presented in section 5.4 Case Study 2 was a combined single case study and parallel case study see below under “case selection” for explanation. See 5.3.3 for a discussion of the parallel single case study.

5.5.4 Candidate cases

News articles, website, and key industry participants, such as all Dutch mobile network operators, were used to identify projects in a sub- domain of the universe, i.e. in the mobile telecommunications indus- try in the Netherlands in two years 2002 and 2003. A set of 30 candidate cases was created in this way.

5.5.5 Case selection

From the pool of 30 candidate cases, 15 projects were successful and could therefore be included in the case study to test the necessary condition proposition. It further turned out that these cases were divided unequally amongst the six types of innovation projects Table 5.6. Table 5.6 Number of selected cases by product innovation type Type of innovation Number of cases Incremental innovation for core components 1 Incremental innovation for peripheral components 4 Modular innovation 3 Architectural innovation for core components 1 Architectural innovation for peripheral components 1 Radical innovation 5 The result of this case selection procedure was that this study was partly a single case study namely for projects aiming at products with incremental core component change as well as for projects aim- ing at architectural innovation of core or peripheral components, and partly a parallel case study for the other three types of product innovation.

5.5.6 Hypothesis

Because the proposition in this study specified necessary conditions and the selection was done on the basis of the presence of the dependent concept, the hypothesis was that the condition was present in each case that was studied.

5.5.7 Measurement

In order to select and classify cases, first the type of innovation was determined, and then the success of each case. Next, the organiza- tional configuration was determined in order to compare the observed configuration with the expected ideal type.