Your DBA is meant to be embedded in your own organisation, and eighteen months in, that is exactly the problem: the case-study chapter still reads like a consultancy report about your employer, not like doctoral research. A DBA thesis built around a single organisation has to do something a management consulting deliverable never has to — generalise a theoretical contribution beyond the one case it studied. Here is how to build that chapter so it survives a viva.
Your organisation is the case, not the client
The single most common failure in an industry-embedded DBA is writing the empirical chapters as if the reader is a client stakeholder who wants recommendations, rather than an examiner who wants to know what the case reveals about a theoretical question that applies beyond your organisation. Every finding needs to answer two questions in sequence: what happened in this specific organisation, and what does that tell us about the broader theoretical proposition the thesis is testing or building. A results section that describes your employer’s restructuring process in rich detail but never steps back to state what that process reveals about, say, middle-management resistance to organisational change as a general phenomenon, has produced a case history, not a doctoral contribution. A useful test to apply to every empirical paragraph you draft: could this sentence appear unchanged in an internal report to your line manager? If the answer is yes, the paragraph has not yet done the theoretical work a thesis requires, and needs a further sentence connecting the observation back to the literature your thesis is built on.
Case-study design: single case, embedded case, or comparative?
Decide explicitly, and state in the methodology chapter, which case-study architecture your thesis actually uses. A single holistic case study treats the whole organisation as one unit of analysis around one central research question. An embedded single-case design studies multiple units within the same organisation — several departments, several project teams, several regional offices — allowing within-case comparison while still situating everything inside one organisational boundary. A comparative multiple-case design extends the study to a second organisation, typically to test whether a finding from your own employer generalises or is specific to that context. Access constraints usually decide this for a DBA candidate more than methodological preference does — you very likely have privileged access to your own organisation and none to a competitor — so an embedded single-case design, rather than a comparative one requiring a second organisation’s cooperation, is the realistic default, and a good methodology chapter says so explicitly rather than apologising for a single-case design as a compromise. Name the specific units studied within the embedded design — which departments, which project teams, over what period — because “the organisation” as a single undifferentiated unit of analysis is rarely what a DBA candidate actually studied, and specifying the embedded units gives the case-selection logic something concrete to justify, in the same way a small-N comparative study in another field has to justify why its specific cases were chosen and not others.
The insider-researcher problem: your dual role has to be managed on paper, not just in practice
As an employee researching your own organisation, you hold two roles simultaneously — practitioner and researcher — and a DBA methodology chapter has to address this explicitly rather than hoping the examiner does not notice. State how you managed role conflicts during data collection: whether colleagues consented to being research participants specifically, distinct from their normal working relationship with you; how you handled information you learned through your employee role that was not offered as research data; and what you did when your professional judgement as a practitioner and your neutral stance as a researcher pulled in different directions. Positionality is not a confessional paragraph tacked onto the methodology chapter — it is a design feature that shapes what data you could access and what a reader should weigh when interpreting your findings, and examiners specifically probe whether a candidate has thought about it as such. Keep a reflexive research log throughout the candidature, separate from your data collection notes, recording moments where your practitioner role and your researcher role visibly pulled in different directions — this log becomes the primary evidence for the positionality section, and reconstructing it retrospectively in the final writing-up year is far harder and less credible than writing it as events actually occurred.
Ethics approval for research on your own colleagues
An ethics application for insider research at your own employer has to address a specific power-imbalance question a standard external-organisation study does not face in the same form: can a colleague who reports to you, or whose career prospects you might influence, genuinely give free and uncoerced consent to participate. State explicitly in the ethics application how you mitigated this — commonly, by excluding direct reports from the participant pool, by having a third party handle recruitment and consent so participation decisions never pass through you directly, or by making unmistakably clear that non-participation carries no professional consequence, and by whom that assurance is credibly given. An ethics committee reviewing an insider-research DBA application will look specifically for this mitigation; its absence is one of the most common reasons such applications are sent back for revision.
Generalisability: theoretical, not statistical
A DBA case study of one organisation cannot claim statistical generalisability — there is no population of organisations it was sampled from in the survey-research sense. What it can claim is analytic or theoretical generalisability: that the findings extend or refine an existing theoretical proposition in a way that should apply to organisations sharing the relevant characteristics of the case, even though the sample size is one. State explicitly, in the discussion chapter, which theoretical proposition your case extends, contradicts, or refines, and be precise about the boundary conditions — what kind of organisation, in what kind of context, the finding should reasonably be expected to travel to. A discussion chapter that simply restates “further research is needed to generalise this finding” without specifying the theoretical claim being extended has skipped the actual intellectual work a DBA thesis exists to do. A worked illustration, invented for this example and not a real submitted thesis: a candidate whose organisation successfully embedded a new performance-management system might frame the theoretical contribution not as “this system works,” which is an organisation-specific operational claim, but as a refinement to an existing change-management theory — for instance, specifying a boundary condition under which a particular implementation mechanism succeeds where prior studies predicted it would fail, and naming the organisational characteristics that boundary condition depends on.
Managing gatekeeper access and organisational politics as an ongoing methodological issue
Access to your own organisation is not a one-time ethics approval that, once granted, removes the issue — it is an ongoing methodological condition that can change as the research progresses. A change in your own role, a change of senior sponsor, or a shift in organisational politics can restrict access to data or participants partway through a multi-year candidature, and a strong methodology chapter states the access arrangement explicitly (who granted it, on what terms, what data it does and does not cover) rather than treating access as an unremarkable background fact. Where access changed during the study, report that change and its effect on the design honestly — examiners read an undisclosed gap in the data far more critically than an explained one.
A change of employer partway through candidature is the most severe version of this problem, and it is more common than DBA programmes always acknowledge upfront — sponsorship priorities shift, restructures happen, and a candidate who leaves the organisation their thesis is embedded in faces a genuinely difficult design decision about whether continued access can be negotiated as an alumnus or former employee, or whether the case boundary has to be redrawn around the period of employment that was actually studied. Raise this risk explicitly with your supervisory team at the proposal stage, not only if and when it happens — professional and industry-embedded doctoral routes generally carry this access dependency more heavily than a traditional, university-based PhD does, in the same way an integrated or industry-embedded PhD route differs from a traditional university-based one in its dependency on an external partner remaining engaged for the full candidature.
Writing the case-study chapter examiners actually credit
Structure the case-study findings chapter around the theoretical proposition, not around a chronological narrative of what happened at the organisation — a chronological account is easy to write and satisfying to read as a story, but it defers the analytical work of connecting evidence to theory, which is exactly the connection an examiner is checking for. This mirrors the same connect-evidence-to-claim discipline a management PhD’s hypothesis chapter needs — see how a management doctorate builds its research problem into testable hypotheses with named variables — the case-study route substitutes rich qualitative evidence for statistical variables, but the underlying requirement to state exactly what is being claimed and on what evidential basis is identical.
Remember, too, that a DBA is examined as a doctorate, not as a shorter or lesser PhD — see how a professional doctorate differs from a PhD in assessment architecture rather than only in word count. The organisational embeddedness that defines a DBA is a design strength to be argued for explicitly, not a limitation to apologise for relative to a traditional PhD’s typically broader, less situated evidence base.
FAQ
Can a DBA thesis be based on a single organisation?
Yes, and this is the standard, expected design for an industry-embedded DBA — the methodological requirement is to state the case-study architecture explicitly and to claim theoretical rather than statistical generalisability.
What is the difference between a holistic and an embedded single-case design?
A holistic design treats the whole organisation as one unit of analysis; an embedded design studies multiple units within the same organisation, such as several departments or teams, allowing within-case comparison.
How do I handle being both an employee and a researcher in my own organisation?
Address it explicitly in the methodology chapter — how colleagues consented as research participants distinct from their working relationship with you, how you handled non-research information from your employee role, and how you managed conflicts between your practitioner and researcher stances.
Can a single-organisation DBA case study be generalised?
Not statistically, but theoretically — state which theoretical proposition the case extends or refines, and specify the boundary conditions for which kinds of organisations the finding should reasonably apply to.
What should I do if my access to the organisation changes during the DBA?
Report the change and its effect on the research design explicitly in the methodology chapter — an examiner treats a disclosed and explained access change far more favourably than an unexplained gap in the data.
Should the case-study findings chapter be written chronologically?
No. Structure it around the theoretical proposition being tested or built, using chronology only where the sequence of events itself is analytically relevant, rather than defaulting to a narrative account of what happened.
Do DBA examiners expect a comparative multiple-case design?
Not by default — access constraints make an embedded single-case design realistic for most industry-embedded candidates, and this is an accepted, common architecture provided it is stated and justified explicitly.
How does an ethics committee address the power imbalance in insider research on colleagues?
By requiring explicit mitigation stated in the ethics application — commonly excluding direct reports from the participant pool, using a third party for recruitment and consent, or making clear that non-participation carries no professional consequence, with a credible source for that assurance.
What happens if I leave my employer partway through a DBA?
Raise the risk with your supervisory team at the proposal stage; if it occurs, you may need to negotiate continued access as a former employee or redraw the case boundary around the period you were actually employed there.
Turn your organisational access into a defensible thesis
The access you have to your own organisation is the DBA’s central asset, but only once the case-study architecture, positionality and generalisability claims are stated as explicitly as the findings themselves. Tesify’s thesis writing workspace helps you draft that methodology chapter against your specific organisational context, so the case-study design decision is made deliberately rather than defended retrospectively at viva.