A Schedule for
Research Projects


Introduction

No one can forecast exactly how a research project will proceed -- not even the most seasoned researcher. But we can and should try to guide the process along a path that has been successful in the past.

The outline of tasks presented here is adapted from an outline used by Dr. Dave Brown at the Worcester Polytechnic Institute. I have borrowed his schedule and added a few touches based on my experiences and preferences as a faculty advisor.

You and I will use it as a starting point for organizing and monitoring your project. We will also make changes to it whenever the features of your project or your situation make it necessary.

This schedule best describes the process of a multiple-semester project. For a one-semester undergraduate project, the first two steps -- problem definition and project proposal -- will be essentially done at the time we agree to work together on the project. You may need to do a bit more research in preparation for developing a solution, though.

The first thing you should do is to create a web page for your project. This will facilitate communication between the two of us and will make your project available to other faculty members interested in your work. Also, having to put documents up will get you into the habit of writing about your work, which is essential to the completion of a good project.

Here is the top-level outline. More information on each topic is available by clicking on the link.

  1. Define your problem.
  2. Write a proposal.
  3. Develop your solution.
  4. Implement your solution.
  5. Present your solution.
  6. Move on with your life.


1. Define your problem.

At this point, you have a short proposal for your project, either one I wrote or one you wrote. This is just the beginning. Now, you need to really define your project, in enough detail that you can move forward.

Meet with me to discuss your problem. Try to get a feel for what has been done by others on this and related topics. Try to get a feel for techniques that may be useful in attacking the problem.

Read conference papers, journal articles, and book chapters on your topic. For an undergraduate project, I will provide specific items for you to read. For a graduate project, I will merely "jump start" your reading, leaving you to dig deeper.

Once you have narrowed your problem description, try to write about it. [ A one-instruction recipe for your project might be: Repeat until done. :-) ] Build a bibliographic file of complete references on-line. Take lots of notes! Use the web, but do not try to use only the web.

Develop a simple example on which you can work out your ideas. Such an example will focus your reading, focus your development of a solution, and perhaps serve as a starting point for your implementation.

Refine your goal for the project. Do you intend to completely solve a problem? Do you intend to explore an area, getting as far as you can into the problem? Do you intend to evaluate alternatives, such as alternative solutions that have been proposed by you or others?


2. Write a proposal.

Now you are ready to write your project proposal. If done properly, a proposal is an important element of any research project. It serves as a "contract" between student and supervisor, specifying what is to be done and how the results will be evaluated. It also serves to jump start the project by forcing the student to think, write about, and critiques the research problem.

A good proposal will ordinarily contain most or all of the following:

Discuss your ideas with me. (I hope to have some sample proposals on-line soon.) Write a draft and have me read it. Meet with me again to discuss your ideas.

If you are doing a graduate project, now is the time to assemble your project or thesis committee. I will serve as chair of the committee, and you will need at least one more CS faculty member and at least one non-CS faculty member. Discuss your choices with me, and I will try to help you assemble the most useful committee possible.

Construct a rough weekly timetable for your work. (For a multi-term project, a monthly timetable may be more appropriate.) Be realistic. Some advisors recommend adding 30% to your original estimates. Allow approximately 10% of your project time for writing the final report and preparing your final presentation.

Put your proposal on your project web page.


3. Develop your solution.

Develop a model or a theory or a design (whatever is appropriate to your project). Write your ideas on paper. Draw diagrams; create tables. Discuss your ideas with me, with other faculty members, and with fellow students. Inspiration can come from anywhere!

Begin to develop specification for your solution. State how you will test and evaluate it. Do not worry about how you will implement your solution just yet; focus on what you will do, not how you will implement it.

Record the decisions you make about your solution and your reasons for making them. This record will make it easier to make changes during your project and to write your final report.

Present your solution to me and any others who will listen. Refine it. "You don't know it unless you can teach it." Besides, other people may see things that you don't see -- even if they are relatively unfamiliar with your problem area.

Post the solution to your project web page.

At this point, revise your project timetable, if necessary.


4. Implement your solution.

Design your implementation. Select software tools for coding. Develop any additional tools that you may need.

Develop a prototype system. Decide what you need to implement now, in order to achieve your goals, and what you can leave for "later" (in the project, or beyond).

Begin to document your code and how to use the system.

Again, revise your project timetable, if necessary.

Complete your implementation. Test it thoroughly. Evaluate its results.

You can begin to write parts of your final report as convenient, but do not let attempts to do the final report interfere with achieving the results that your wish to report!!

Make the implementation available from your project web page in an appropriate form (source files, demos, tarred and gzipped directory, etc.).


5. Present your solution.

Write your final report. Read my Writing Tips, paying special attention to the format for your final report.

Give copies of your thesis to members of your committee, if you have one. Allow them sufficient time to read it, then meet with them to discuss it. Make changes where appropriate.

Make the report available from your project web page, either in HTML or some print format (PostScript, PDF, ...).

Give your public presentation. Check with me to select a good time, and I will then contact the department secretary to schedule it. You may prepare your talk before you finish writing your report.

For each simple overhead you create, allow 2-5 minutes for presentation. Allow 10 minutes for questions, either at the end or interspersed throughout your talk.

When you're done, put your slides on the project web page (say, in PostScript format). Give me a print-out of your slides.

Present your work to the world. Is your research strong enough to submit to the local Sigma Xi student research conference? To the Argonne student research conference? To a student journal, such as ACM Crossroads? To a research or R&D journal?


6. Move on with your life.

Get a challenging job. Or go to graduate school. I'm usually happy to write a letter of reference to help you do either.

And keep in touch!


Eugene Wallingford ==== wallingf@cs.uni.edu ==== August 13, 1997