A note on theory-driven analysis practice in doing an MBA dissertation project

A note on theory-driven analysis practice in doing an MBA dissertation project

 

Regarding doing an MBA dissertation project, a common qualitative data analysis is to employ theories to examine certain qualitative research method data, such as a semi-structured interview on a middle-manager about opinions on the product innovation competence of his/ her company, using deductive theory-driven analysis. Please offer 4 advices for conducting this kind of qualitative deductive exercises and 3 main pitfalls of this kind of exercise.

Deductive, theory-driven analysis is useful when your MBA dissertation asks how a middle manager’s account of product innovation competence maps onto an established framework—for example, dynamic capabilities, absorptive capacity, or resource-based view. The key is to make the theory operational, code systematically, and remain open to evidence that complicates the theory.

Four practical advices

1.    Operationalise the theory into a transparent codebook.
Convert the chosen theory into a small set of clearly defined codes—often about five to ten—each with a definition, inclusion/exclusion rules, and one or two illustrative interview excerpts. For instance, if using dynamic capabilities, separate “sensing market opportunities,” “seizing through resource allocation,” and “reconfiguring routines” rather than using one broad code such as “innovation capability.” A good deductive framework explicitly links theoretical concepts to observable evidence in the data.

2.    Read the whole transcript before coding.
Familiarise yourself with the full interview—its context, hesitations, examples, and contradictions—before assigning codes. This prevents you from treating isolated statements as evidence and helps you understand whether, for example, the manager’s claim that “we are innovative” is supported by concrete routines, resources, or outcomes.

3.    Use a hybrid coding process, not a rigid “fit-the-theory” exercise.
Begin with theory-based a priori codes, but allow new codes or refinements where the manager discusses issues the framework does not capture—such as internal political resistance, regulatory constraints, or customer co-creation. Deductive qualitative analysis is stronger when it evaluates, expands, and refines theory rather than merely confirming it.

4.    Actively search for negative and contradictory cases.
Look for passages where the manager’s account conflicts with the theory, with other parts of the same interview, or with organisational evidence. For example, a manager may describe strong innovation competence but admit that failed projects are never reviewed; this contradiction can yield a more nuanced finding. Documenting negative cases strengthens analytical credibility and guards against selective use of quotations.

Three main pitfalls

1.    Forcing data into theoretical categories.
The most common risk is “square-pegging”: labelling any remark about new products, R&D, or change as evidence of the chosen theory. This produces a superficially tidy but weak analysis, especially if the theory is not properly operationalised or if interview questions already embed the theory’s language.

2.    Ignoring data that fall outside the framework.
A tightly predefined coding frame can cause valuable insights to be missed—such as informal knowledge sharing, middle-manager sensemaking, or supplier collaboration—that may be central to product innovation competence. Even in a mainly deductive study, some open coding of early transcripts helps ensure important aspects of the data are not overlooked.

3.    Presenting coded extracts instead of an argument.
Collecting quotations under headings such as “innovation culture” or “resource allocation” is not sufficient analysis. You need to explain patterns, compare accounts, interpret meaning in context, and show how the evidence supports, qualifies, or challenges the theoretical proposition. A common weakness is a mismatch between the data extracts and the claims made about them.

 

A simple workflowA simple workflow

Stage	What to do
Stage		What to do
Theory selection		Justify one framework and link it directly to your research question
Codebook		Define each theoretical code, its boundaries, and example indicators
Familiarisation		Read each transcript in full before coding
Coding		Apply a priori codes; add inductive codes where needed
Verification		Check overlaps, contradictions, and negative cases
Interpretation		Explain how the pattern relates to the theory and research question

 

For a single middle-manager interview, be especially cautious about generalisation: the analysis can produce a rich, theory-informed case account, but it cannot establish that the whole company possesses—or lacks—product innovation competence without further interviews, documents, or observations.