Proposed Capstone Proposal

Trying to come up with a new document that indicates the capstone requirements. It can be found beneath the fold, and also on a wiki page, for editing.

After putting together a draft (yes, backwards) I looked on the web for similar kinds of assignments. Turns out they tend to be substantially similar. I looked at:

* SUNY IT’s telecom program capstone proposal. Here’s an example: pdf.
* The capstone proposal for Marlboro College’s Graduate Center has some interesting sections not included in our draft.
* CalState Moneterey Bay’s Earth Systems Science & Policy capstone proposal makes some specific suggestions for consideration.
* Interesting Power Point presentation (ppt) explaining both the thesis and capstone process for Oregon Health & Science University’s Dept of Medical Informatics & Clinical Epidemiology

Also interesting is IU’s web form for companies to propose capstone projects for the informatics undergraduate students, and a one-page description of UW’s i-school “capstone experience” (doc). Our students might also be inspired by some of IU’s undergraduate capstone projects.

Capstone Project Proposal

Submissions and Deadline

The capstone project proposal is due roughly one month before the beginning of the Summer, Fall, and Spring semesters. The exact deadline will appear on the Informatics advising site. The proposal must be submitted to the Informatics advising electronic dropbox before that deadline. It must be submitted either as an Adobe Acrobat file or in a plain text format, with the submitter’s last and first names, along with the current semester and year, as the title. For example, Bruce Lee would submit an Acrobat file named

LeeBruce-Spring2004.pdf

The core proposal should be no longer than 5 pages, single spaced, with 1.5 inch margins, using Times New Roman or a similar serif font at 12pt. Additional supporting material may be included, as may hyperlinks to other data, but it must all be delivered in a single file.

Required Sections

Each of the following sections should appear in the proposal, and no others.

Abstract. In 250 words or less, clearly indicate what form your project will take, what problem it will solve, and how. Although it appears first, it is probably best if you write this section after having written the rest of the proposal. The committee should, in reading this summary, know why your challenge is important, that it is substantial enough to demonstrate your expertise, and that it is doable.

Problem statement. As concisely as possible indicate what the problem or research question is. If you are creating a system, you should say why such a system is needed, and how it might improve upon existing workflows, available information, etc. If you are doing research, indicate what the research question is and what conceptual framework you are taking. Justify the relevance of the topic or problem.

Envisioned final deliverable. What will the final project or document look like? What will it consist of? What is the scope of the solution? This section specifies what the evaluators should expect from you when they see your final capstone materials. When your capstone is complete, you will have two opportunities for presenting it, and you must complete both forms of presentation for your capstone to be complete. First, you will make a short presentation to the Capstone Committee and the public, providing an overview of your project, and a demonstration, where appropriate. Second, you will submit an electronic record of your work. In some cases, this electronic submission may simply be a document: the report, for example, of a study, along with supporting documents. In others, it will be a recorded demonstration of a system, again, along with supporting documentation. No matter what form your final project will take, you should be clear here about the expectations the Capstone Committee should hold you to. The more specific and precise you are, the better.

Method or approach. How is it that you propose to find a solution to the problem? What are the tools you will be using? What are established best practices for the kind of work you will be doing? If these do not exist, how will you ensure that your work is of high quality. What is the relevant research or the key references? Also, what resources will be required and how will you access these? Finally, for work that makes use of human subjects, indicate that an IRB protocol has been submitted, and attach this as supporting information. (Note that any proposal that uses human subjects will not be accepted unless the IRB proposal has been made. However, acceptance by the IRB is not a prerequisite of acceptance by the Capstone Committee of the project—submission of a protocol is sufficient.)

Previous work. What have you already done toward this project? Is this the extension of class work? Did you work on earlier versions alone or with others? You should, in this section, indicate both that you have done some preliminary work on the problem, and that the project will represent substantial work beyond that which you have already completed as part of your coursework. (You should attach as supporting material an earlier document that shows work you have already done.)

Project schedule. What are the steps needed for completing the project? How long will each of these steps take? When do you envision completing each of these milestones?

Qualifications. What skills do you have that qualify you for doing this work? Cite your coursework, where appropriate, as well as experience outside of the program. Demonstrate that the plan you have suggested is something that you can reasonably expect to complete. Obviously, we prefer that you work at the edge of your expertise, so you should feel free to take on a challenging project. But if you require expertise that you do not already have, you should indicate how you will accomplish this. If you like, you can attach supporting information (e.g., a resume, course schedule, etc.).

Evaluation

The capstone committee will want to see enough detail in the proposal that it seems likely that the student will be able to accomplish the project. The most likely reasons for a project proposal to be rejected are:

Proposal is too ambiguous. While it is impossible to be completely detailed, and there are always likely to be unanticipated problems, your proposal should be specific enough that the committee will be able to anticipate the form of the final project and judge whether you have met the requirements spelled out here. If the project is not specified in enough detail, it will be impossible for the committee to evaluate whether the final project meets the requirements indicated in the proposal. Be as concrete and specific as you possibly can. Leave as little “up in the air” as possible.

Proposal is not ambitious enough. The project should represent a clear indication of your skills and of your abilities. If it is something that, in the judgment of the committee, does not demonstrate the abilities of a professional informaticist, it is unlikely that it will be approved. You need to show that this will be a project that we, as a community, are proud of, and that represents a substantial (semester-long) amount of work.

Proposal seems ill-informed or over-ambitious. Do not promise world peace. If you suggest something that seems as if it would be unlikely that you will be able to complete it within the schedule you outline, it will not be accepted.

Proposal is badly formed. Spelling and grammar reflect your careful attention to detail, and significant variations from the norm on these accounts are likely to reflect badly on the proposal as a whole.

Lack of citation to the literature. You should cite relevant literature, to indicate that you are aware of previous research and professional standards.

Lack of autonomy. You are expected to work on your capstone in an autonomous fashion. That does not mean that your capstone may not interlock with other students’ capstones, or the work of others in the field, but your contribution must be clearly indicated as separate and not dependent upon the successful completion of work by others. The student must perform the work to the requirements of the program, and it is therefore unlikely that work that is also required as part of a student’s regular employment will be accepted.

There are other possible problems, but the above are likely to be the most frequent reasons a proposal may be rejected. If a proposal is rejected, the student must submit a new proposal during a later semester. Approval of the capstone is required before the student may advance to the capstone seminar.

Please note that the capstone proposal, like the capstone itself, is part of a public process, and you should expect your proposal to be available to the public for some time to come, if it is approved. Please take care in its preparation.

This entry was posted in Uncategorized and tagged . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

3 Comments

  1. Posted 11/11/2004 at 11:17 am | Permalink

    Your list of all of the ways a proposal could be rejected made me laugh, for I realized that I had only accomplished a couple of them while trying to get a proposal approved in one of my classes this semester. It’s good to know that I’m not a complete failure!

  2. Posted 11/11/2004 at 1:32 pm | Permalink

    Oh, I regularly hit all of those and quite a few more. I think the methods of failure are one of my strong suits :).

  3. Posted 11/13/2004 at 1:38 pm | Permalink

    thought you may find this interesting: it seems bioinformatics will converge with medical informatics: with this, the consumer technology will reflect an increase in monitoring personal health. Perhaps this the narcism reflex that the technology will tap into. Perhaps we will collectively become more of do it your selfer with health care, and at the same time become more hypocondriacal.

    Towards health care blogging

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>