I got 99 problems but the problem statement ain’t one! – part 1

Research question, hypothesis, thesis question or problem statement. They are all essentially the same thing. Students are asked to write them all the time, but do you really know a good way of writing those important, but quirky statements?

Did you know that your are probably starting at the wrong end if you are trying to grab a problem statement out of thin air? In this episode, Kyrre will run you through his method for not only nailing the problem statement, but the whole introduction chapter! It even involves a game!

Note to the listener:

If you are listening to the episode, but need a text verion of the method and the example we are using here they are:

Part 1: The scaffolding

Step one: Define the problem domain.

Step two: Write the problematization in several statements.

ANYTHING CAN BE A PROBLEM:

• Lack of tool
• Lack of method
• Lack of knowledge from data
• Lack of data

Stop at the “pebble in the shoe», where you will do your work.

Step three: Dream about the potential impact.

Step Four: Write the problem statement!

You propose an activity by which you will somehow address the problem. YOU DO NOT WANT TO FIX THE PROBLEM!

Part 2: Quality assurance

Step 1: Quality assuring the problem domain:

Test it out on others, maybe your supervisor, or relative or someone else who is only partially informed.

Step 2: We need to make sure that the problematization is coherent:

There is a logical thread that can be traced backward. Play the interview game. It is like the “five whys” to solve a root problem.

Step 3: Break down the problem statement

First, circle all your nouns in the problem statement. Write down how you define heach of them. Is there any ambiguity?

Second: Write down all the verbs: These are the actual activities you will do. Make sure you are sure that this corresponds with your plan and your resources. In short: The verbs dictate the approach / method chapter later. It also defines your deliverables, which is the light at the end of the tunnel!

Third: Circle all the adjectives. This is what you will evaluate. Avoid ambiguity, like “better”. The adjectives dictate the analysis.

Part 3: Write the document

Step 1: Write the introduction

Write a paragraph for the problem domain. For each statement in the problematization: Write a paragraph. Keep the statement as a hidden comment.

Step 2: write the problem statement

For the potential impact: Write a paragraph. Then, present your problem statement with some visual space surrounding it.

Step 3: Write the operationalization

After the problem statement comes the operationalization. With All the nouns, verbs and adjectives. (it usually does not have a title, that’s just the text)

There you are!!

Our example (please not that the names used for the researchers and software are fictional):

Problem domain: HIV / AIDS

1. Every year 1.1 million people die due to AIDS related illnesses
2. AIDS / HIV has an enourmus detrimental effect on peoples lives as well as grave socioeconomic effects
3. Treatment methods for people with HIV/AIDS are still being discovered and investigated, but no cure has been found so far
4. One of the challenges for medical research is the ability to properly test their newly discovered medications due to the practical difficulties of conducting human trials
5. Computer simulations can provide an additional source of insight into how medication works, but currently we lack the ability to properly represent how the HIV virus spreads in the human body.
6. The work of Spitzfein and Marcus has proposed a working computer simulation design that closely represents how viruses spread in the human body, and has now been adapted for HIV, but the application developed, SPEKTRUM, is run as a single thread, which means simulation times normally take days and therefore become impractical.

[impact]

If we were able to port SPEKTRUM developed by Spitzfein and Marcus as a distributed workload, suitable for cloud environments, we could leverage the globally available cloud resources in order to dramatically reduce simulation times. Shorter simulations would allow medical research to progress faster in their search for HIV/AIDS treatments.

Problem statement:

Design and develop a multithread version of SPEKTRUM in order to achieve reduced simulation times

• Category: Podcast episode