DEV Community: daniel

Can You Use Case Study Research in an MBA Dissertation?

daniel — Mon, 26 Oct 2026 10:58:43 +0000

If you are working on your MBA dissertation, one of the first big decisions is how you will collect and analyse your evidence. Many students assume a dissertation needs a large survey with hundreds of responses, so a study built around one company feels risky. The good news is that case study research is accepted on most MBA programmes, and when it is done properly it can score very well. If you are looking for MBA dissertation help to decide on your approach, this guide explains when a case study works, when it does not, and how to build one your supervisor will respect.

The Short Answer

Yes, you can. A case study is a recognised research strategy in business and management. Your university may have preferences, so check your programme handbook and talk to your supervisor early. But the method itself is well established, and many MBA students choose it because it lets them study a real organisation in real depth.

What Case Study Research Actually Means

A case study is an in-depth investigation of one organisation, a small group of organisations, a project, a decision or a process, inside its real setting. You are not trying to count how many people agree with a statement. You are trying to understand how and why something happened.

Examples that suit an MBA level:

How a retail company changed its supply chain after a major disruption
Why a digital transformation project in a hospital trust stalled
How a family business handled leadership succession

Notice that each one asks "how" or "why". That is the signal that a case study may fit.

Why Business Schools Accept It

Business problems rarely happen in a lab. They happen inside companies, with real people, budgets, politics and deadlines. A case study lets you look at all of that together. It also matches how MBA programmes teach, since most of your coursework already uses cases.

The method also has a strong academic base. Robert Yin's work on case study design is the most cited starting point, and Kathleen Eisenhardt's paper on building theory from case studies is widely used in management research. Citing sources like these in your methodology chapter shows you did not just pick the method because it looked easy.

Single Case or Multiple Cases

Single case. You go deep into one organisation. This works well when the case is unusual, very typical, or gives you access to something few people can see.

Multiple cases. You compare two to four organisations. This gives you stronger evidence for patterns, but it takes more time and more access, so be realistic about your timeline.

For most MBA dissertations, one well-chosen case or a small comparison of two or three is enough. Going wider usually means going thinner.

Case Study vs Survey: A Quick Comparison

Point	Case Study	Survey
Main question type	How and why	How many and how much
Sample	One to a few organisations	Large group of respondents
Data	Interviews, documents, observation	Questionnaire responses
Strength	Depth and context	Breadth and statistical testing
Main weakness	Hard to generalise	Limited depth
Best for	Understanding a process or decision	Testing relationships between variables

Neither is better in every situation. The right choice depends on your research question.

When a Case Study Is a Good Fit

Your question starts with "how" or "why"
You can get access to an organisation or enough public information about one
The topic is hard to measure with numbers alone
You want to understand a process, not just an outcome

When You Should Think Twice

You want to prove a cause and effect relationship with statistics
You cannot get any access to people or internal documents
Your question is really about a whole industry or country
You only plan to describe a company without any analysis

If your plan is just "I will write about Company X," that is a company profile, not a case study. A case study needs a clear question, a method and an argument.

How to Build a Strong Case Study Step by Step

1. Write a focused research question. Keep it narrow. "How did Company X manage change during its ERP rollout?" is workable. "How do companies manage change?" is too wide.

2. Choose your case and explain why. Do not pick a company only because it is famous or easy. State your selection logic. For example, it may be a typical example, an extreme example, or the only one you can access.

3. Plan your data sources. Strong case studies use more than one source. Common options are:

Semi-structured interviews with managers or staff
Annual reports, internal policies and meeting records
Public sources such as press releases and regulator filings
Direct observation, if you are allowed on site

4. Triangulate. This means checking one source against another. If a manager says a project went smoothly but the documents show repeated delays, that difference is worth discussing. Triangulation is one of the best ways to show your findings are credible.

5. Choose your analysis method before you collect data. Thematic analysis is common for interview data. Pattern matching, where you compare your findings with a theory you set out in advance, is also widely used. For multiple cases, you can add a cross-case comparison.

6. Link back to theory. Your case should talk to the literature. Show where your findings agree with existing models, where they differ and what that might mean.

Ethics and Access

This is where many case study plans fall apart. Before you contact anyone, check your university's ethics process. You will usually need:

Permission from a gatekeeper at the organisation
A participant information sheet and consent form
A plan for anonymity and secure data storage

Some companies will agree to talk only if their name is hidden. That is fine. Many dissertations use a pseudonym and describe the sector and size instead. Just make sure the organisation cannot be easily identified if you promised anonymity.

How to Write the Methodology Chapter

Your supervisor will look for justification, not just description. Cover these points:

Your research philosophy and approach, for example the layers in Saunders' research onion
Why a case study fits your question better than other strategies
Your case selection logic
Data collection methods and sample details
Your analysis steps
Validity, reliability and limitations
Ethical approval

Write it in the past tense if your university expects it, and keep your language plain. A methodology chapter that is clear and honest usually scores better than one filled with heavy terms.

Dealing With the Generalisability Problem

The most common criticism of case studies is that you cannot generalise from one organisation. Do not hide from this. Address it directly in your limitations section.

A good answer is that case studies aim for analytic generalisation, not statistical generalisation. You are not claiming that every company will behave the same way. You are using the case to test, refine or extend a theory, and you explain what other organisations in similar conditions might learn from it.

Common Mistakes to Avoid

Choosing a case with no clear link to the research question
Relying on a single interview and calling it a case study
Using only company websites as evidence
Describing events without analysing them
Skipping the ethics process until the last minute
Writing a findings chapter that is just a long quote dump

Quick Checklist Before You Commit

Is my question a "how" or "why" question?
Do I have realistic access to the case?
Have I planned at least two data sources?
Do I know how I will analyse the data?
Has my supervisor seen and agreed with the plan?
Have I started the ethics form?

If you can answer yes to most of these, a case study is likely a safe and strong choice for your MBA dissertation.

Final Thoughts

Case study research is a valid and respected option for an MBA dissertation. It rewards students who ask clear questions, collect evidence carefully and explain their choices honestly. It does not reward shortcuts. If you plan it well, it can also give you something useful beyond the grade, which is a detailed understanding of how a real business works. For students who want guided support with planning, structure and referencing, Prime Assignment Help offers academic guidance for UK university work, and you stay the author of your own dissertation.

Java OOP Concepts Explained with Simple Examples

daniel — Mon, 19 Oct 2026 07:54:35 +0000

Most students meet object-oriented programming in week three or four of a Java module, right after they've finally got comfortable with loops and arrays. Then the lecturer uses the words class, object, inheritance and polymorphism in a single breath, the slides fill up with diagrams of dogs and cars, and a good part of the room quietly decides that OOP is something they'll understand later. The catch is that later usually arrives as a coursework brief. A big share of first and second year Java tasks are OOP tasks in disguise: design a small system, split it into classes, make those classes work together, and explain why you built it that way. When people go looking for Java assignment help at that point, the gap they find is rarely syntax. It's that nobody showed them how to think in objects first and write code second. So instead of four unrelated animal examples, this post uses one small library system that grows a little in each section, which is closer to how a real assignment feels.

Classes and objects

A class is a template. An object is one thing built from that template. A book is a good place to start because everyone knows what one looks like.

public class Book {
    String title;
    String author;
}

public class Main {
    public static void main(String[] args) {
        Book first = new Book();
        first.title = "Clean Code";
        first.author = "Robert C. Martin";

        Book second = new Book();
        second.title = "Effective Java";
        second.author = "Joshua Bloch";
    }
}

first and second come from the same class but hold their own data. Change one title and the other doesn't move. That's all "object" really means in practice.

One thing worth getting right early: writing Book third; does not create a book. It creates a reference that points at nothing. Call a method on it and you get a NullPointerException in Java, one of the most common crashes in early coursework. The new keyword is what actually builds the object.

Encapsulation

The Book above has a problem. Anyone can write first.title = "" and nothing stops them. Encapsulation fixes that by making the fields private and allowing changes only through methods you control.

public class Book {
    private final String title;
    private final String author;
    private boolean onLoan;

    public Book(String title, String author) {
        this.title = title;
        this.author = author;
    }

    public String getTitle() { return title; }
    public boolean isOnLoan() { return onLoan; }

    public void checkOut() {
        if (onLoan) {
            throw new IllegalStateException(title + " is already on loan");
        }
        onLoan = true;
    }

    public void giveBack() {
        onLoan = false;
    }
}

There is no setOnLoan(boolean) here, and that's deliberate. A book can only become unavailable through checkOut(), which refuses to run twice. If you let the IDE generate a setter for every field, anyone can flip the flag directly and the check is pointless. A getter and setter on every field is just a public field with extra typing.

Inheritance

Libraries don't only lend books. There are DVDs, magazines, audiobooks. Copying the title and loan logic into each class is how the same bug ends up in four places, so the shared part moves into a parent class.

public class LibraryItem {
    private final String title;
    private boolean onLoan;

    public LibraryItem(String title) {
        this.title = title;
    }

    public String getTitle() { return title; }
    public boolean isOnLoan() { return onLoan; }

    public void checkOut() {
        if (onLoan) {
            throw new IllegalStateException(title + " is already on loan");
        }
        onLoan = true;
    }

    public void giveBack() { onLoan = false; }

    public double lateFee(int daysLate) {
        return daysLate * 0.10;
    }
}

The Book class now shrinks to what is specific to books:

public class Book extends LibraryItem {
    private final String author;

    public Book(String title, String author) {
        super(title);
        this.author = author;
    }

    public String getAuthor() { return author; }
}

extends is what links the two, and super(title) hands the title up to the parent constructor. It has to be the first line of the child constructor, which catches a lot of people out. A Book never had to write checkOut() itself, it just has it.

A quick test before using extends: say "a Book is a LibraryItem" out loud. If the sentence sounds wrong, inheritance is probably the wrong tool.

Polymorphism

DVDs usually have heavier late fees, so the Dvd class changes that one method and leaves everything else alone.

public class Dvd extends LibraryItem {
    private final int minutes;

    public Dvd(String title, int minutes) {
        super(title);
        this.minutes = minutes;
    }

    public int getMinutes() { return minutes; }

    @Override
    public double lateFee(int daysLate) {
        return daysLate * 0.50;
    }
}

Now the interesting part:

LibraryItem[] returned = {
    new Book("Clean Code", "Robert C. Martin"),
    new Dvd("The Social Network", 120)
};

for (LibraryItem item : returned) {
    System.out.println(item.getTitle() + " late fee: " + item.lateFee(4));
}

Clean Code late fee: 0.4
The Social Network late fee: 2.0

The variable type is LibraryItem, but Java decides which lateFee to run by looking at the actual object at runtime. The loop has no idea which kind of item it's holding and doesn't need to. Add a Magazine class next month and this loop doesn't change at all. (Using double for money is fine for a demo. In anything real, use BigDecimal.)

Abstraction

Nobody walks into a library and borrows a generic "item". LibraryItem only exists so the real things can share it, so it shouldn't be possible to create one directly. That's what abstract is for.

public abstract class LibraryItem {
    // fields, constructor, checkOut and giveBack stay as they were

    public abstract double lateFee(int daysLate);
}

Now new LibraryItem("x") won't compile, and every subclass has to supply its own fee rule:

public class Book extends LibraryItem {
    // author field and constructor as before

    @Override
    public double lateFee(int daysLate) {
        return daysLate * 0.10;
    }
}

Interfaces are the other half of abstraction. Use an abstract class when the subclasses share state and code. Use an interface when you only want to promise a behaviour.

public interface Reservable {
    void reserve(String memberName);
}

A Dvd could implement Reservable while a reference-only Book doesn't. A class can only extend one parent, but it can implement as many interfaces as it needs, which is usually the deciding factor.

Quick reference

Concept	Problem it solves	Where you see it
Encapsulation	Outside code breaking an object's rules	`private`, constructors, getters
Inheritance	Same code copied into several classes	`extends`, `super`
Polymorphism	Code that has to check what type it's holding	`@Override`, parent type variables
Abstraction	Modelling things that shouldn't exist on their own	`abstract`, `interface`

Mistakes that cost marks

Public fields because it was quicker. It stays quicker until validation has to be added in twelve places.
Generating setters for everything, which quietly undoes encapsulation.
Using extends just to borrow methods. A Member that holds a list of items should have an ArrayList as a field, not extend one. A member isn't a list.
Long if and instanceof chains where an overridden method would do the job.
Leaving out @Override. Misspell lateFee as latefee and Java happily treats it as a brand new method, so the parent version keeps running and you spend an hour wondering why. With the annotation the compiler tells you immediately.

The library here is small on purpose. Try extending it with a Member class that can hold at most three items and a Magazine that can't be reserved, then check how many of your earlier classes you had to touch. If the answer is none, the design is doing its job. Real coursework briefs are messier, with file input, a menu loop and marking criteria that reward design choices you can justify in writing, and sketching the classes before writing any code is the same approach the Java walkthroughs on Prime Assignment Help follow.