Project Proposal (Fall 2015)
- First Draft: Saturday, September 26th, 2015, by 11:59PM UTC-12 (Anywhere on Earth).
- Final Draft: Saturday, October 3rd, 2015, by 11:59PM UTC-12 (Anywhere on Earth).
The time has come to propose your project. The project proposal is effectively an agreement between you and your mentor regarding what you will do for the rest of the semester. You’ll submit a draft of your proposal, but we explicitly plan for a bit of back-and-forth between you and your mentor to reach a proposal on which you can agree. A major part of this will be scope: we want to make sure the project you propose and attempt is feasible within the time and resources available for the class. Certain projects will not be feasible in two months and will need to be scoped down, while others will be too small to take up two months and should be scoped up.
Although there will still be weekly discussions and conversations about general EdTech topics on Piazza, the vast majority (>90%) of the time you spend in the class from October 5th to December 5th will be spent on the project. As such, projects should likely be scoped to demand ~100 hours of work from each individual. A single individual could propose a 100-hour project, while a team of five could propose a 500-hour project. Make sure to include the time required to deliver certain required project milestones (the progress report, trailer, paper, and final presentation), although these should not represent more than 10% of the time you spend on the project. We recommend planning no more than 5 hours for the final paper, 3 hours for the final presentation, and 1 hour each for the progress report and trailer.
You do not need to wait until the proposal is accepted to begin work on your project. Some projects will actually need work to begin sooner. For example, if your work involves human subjects testing, you will need to obtain IRB permission earlier than the project final draft deadline. If you need to coordinate with outside organizations or individuals, you likely will want to initiate those conversations earlier. The proposal acceptance will check the scope of the overall deliverable, but it likely will not affect the fundamental design of the project, and so these foundational steps can be taken earlier.
All project proposals you should cover the following information:
- The members of your project team (if you’re doing the project as a group).
- A task list of the tasks that must be completed to execute and deliver your project. Make sure to include the required tasks as well, such as the trailer, progress report, and final paper.
- A calendar describing weekly milestones from September 27th to December 5th.
- A division of responsibilities among the members of the project team (if you’re doing the project as a group).
Research-oriented project proposals should also cover the following information:
- A description of the phenomenon to be investigated, including the research question to be answered.
- A description of the research methodology that will be used to investigate the phenomenon.
- A description of the research basics associated with the methodology, such as independent and dependent variables, internal and external validity, and the connection between these details and the research question.
- A description of the plan for the research regarding IRB, including fall-back plans in case IRB rejects portions of the research design or takes too long to deliver approval. (For example, if IRB ultimately takes too long to approve the full study, you could have a partial study that can be executed more quickly.)
- A description of the data that will be needed or obtained, including fall-back plans if the data cannot be obtained. (For example, if the Registrar refuses to provide complete student information necessary for some research, you could instead plan for how to research only a subset of that data.)
Tool-oriented project proposals should also cover the following information:
- A description of the problem to be solved.
- A description of existing solutions for that problem, specifically to contextualize why your solution is needed.
- A description of the design of the tool you will create.
- A technical description of the tools, languages, and other resources that will be used.
- A description of the integrations or external resources that will need to be obtained, as well as fall-back plans in case portions of these details cannot be completed. (For example, if OIT refuses to provide integration with T-Square, you could instead plan for how to handle standalone student registration in a streamlined and simple way.)
Writing the Proposal
The proposal will be used along with your weekly status checks, progress report, and final deliverables to ensure that you are on track for success throughout the semester, and to ensure everyone has contributed to the final contribution.
Because there is some back-and-forth expected on the project proposal, the due date for the final draft is not as binding as other dates. Depending on how quickly your mentor gets feedback to you and the scope of the feedback, more revision may be necessary. Generally, however, we expect most proposals to be accepted by the due date specified above.
Your proposal should be approximately 1500 words long. This is neither a minimum nor a maximum, but rather a heuristic to simply describe the level of depth we would like to see. Feel free to write more, or if you believe you can complete the assignment in fewer words, feel free to write less.
Please submit your assignment as a PDF file via T-Square. You can find the assignment submission page by going to T-Square, clicking CS6460, clicking Assignments, and then clicking the assignment title. Resubmission is allowed any number of times up to the due date.
If you are working on your project on a team, only one person needs to submit this assignment. Make sure to coordinate who is submitting it, however. Group project proposals should likely be longer to cover larger projects with more information about the division of responsibilities.
Late work is not accepted without advanced agreement except in cases of medical or family emergencies. In the case of an emergency, please contact the Dean of Students. This applies to final proposal drafts as well; you should not assume you can submit the final draft after the due date without first consulting with your mentor.
Your assignment will be evaluated on the extent to which it follows the directions and achieves the learning goal on a simple rubric: Does Not Meet Expectations, Meets Expectations, and Exceeds Expectations. Any assignments graded as Does Not Meet Expectations will have the opportunity to revise and resubmit once.
After submission, your assignment will be ported to Peer Feedback for review by your mentor and classmates. Grading is not the primary function of this peer review process; the primary function is simply to give you the opportunity to read and comment on your classmates’ ideas. All grades will come from the graders alone.
You will typically be assigned four classmates to review. Peer reviews are due one week after the due date of the assignment, and count towards your participation grade.