PhD Problem and Proposal

An old truism is that the first step is the hardest, and many PhD students learn this when the try to write their PhD dissertation proposal. And the hardest part of that is often clearly articulating the problem. Here is the concise and very useful advice I was given as a student:

A proposal has only three important parts:

  1. Clear problem statement.
  2. Thesis statement that articulates how the problem will be solved.
  3. Validation plan that measures whether the solution in the thesis statement solves the problem.

The rest is window dressing.

The biggest problem that many students have is with the problem statement. The most common mistake is stating the problem in a way that it is not testable. Why? I believe it is because we teach computing student to be problem solvers and the proposal is often the first time they need to be problem definers. It turns out that most students have a very clear idea what they want to do, but are not so clear on why. The problem to solve is the most direct answer to why do you want to do this work. Consider the following diagram of a research proposal.

proposal diagram

The numbers on the diagram's bubbles are not the order of presentation in the proposal, but the order in which the student articulates the research project. Most students know "what they want to do" first. But the proposal needs to emphasize the problem that will be solved (or at least, "addressed"). Then the proposal should suggest a solution, and then talk about what will be done.

If the problem is stated well, then the "Validation" will have a direct connection to the problem. And the outcome of the validation will be whether the proposed solution solves the problem. If they don't match, then either the problem statement or the validation needs to be modified.

The "Why do it?" is all the preliminary motivation, including the literature review.

Here is an example that may look simplistic, but is actually quite useful. Many students start a research proposal by saying "I plan to eat lunch."

This is a planned action, not a problem. Why eat lunch? What problem is being solved? This indicates the student knows what to do, but has not articulated why. Just like a 3 year old who does not know why her belly hurts.

A proper problem statement in this example is "My belly hurts." Then we have to think about WHY the belly hurts. What is the root cause?

Cause 1: I'm hungry.
Solution: Eat

Cause 1: Ate too much lunch.
Solution: Relax, go to the toilet.

Cause 1: I'm nervous about an upcoming presentation.
Solution: Deep breathing, relaxation exercises.

From a design perspective, clearly articulating the problem in a way that is separate from the solution is very powerful. It lets readers focus on what they care about instead of what the student cares about. And it allows the student to consider alternative solutions! Perhaps most importantly, it allows the student to then propose a validation that can actually help.

But before the PhD committee can agree that the research plan is sound, they have to know why. They need a clear, unambiguous, and measurable definition of your problem ... preferably in one sentence.

Jeff Offutt