Project Proposal (Spring 2016)
Due Sunday, February 21st, 2016, 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 ten weeks and will need to be scoped down, while others will be too small to take up ten weeks 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 for the final ten weeks will be spent on the project. As such, projects should likely be scoped to demand ~100 hours of work from each individual (note that estimated numbers of hours to spend on each task in the Full Calendar). A single individual could propose a 100-hour project, while a team of five could propose a 500-hour project.
As part of your project, you’ll also deliver a number of related deliverables. You’ll submit:
- Nine weekly status reports, detailing your progress the past week, the challenges you’ve encountered, and any revised expectations for the final project.
- Four intermediate milestones, such as video presentations, prototypes, or progress reports, to solicit feedback from your classmates and mentor.
- A final paper and presentation, reporting on your project.
- The final project itself.
You should make sure to include these deliverables in your proposal as well.
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 February 22nd to May 1st.
- Descriptions of your four intermediate milestones. You should consult the assignment page for those for a better idea of what to include.
- 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, intermediate milestones, 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. Note that your mentor may request revisions or modifications to your proposal after it is submitted, but these likely will not affect the very early work you’ll be performing. If this occurs, you should make these revisions and resubmit the proposal to your mentor.
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. Team proposals are expected to be a bit longer.
Assignments should be submitted to the corresponding Milestone assignment on T-Square in accordance with the Assignment Submission Instructions. Most importantly, you should submit a single PDF for each assignment. This PDF will be ported over to Peer Feedback for peer review by your classmates. If your assignment involves things (like videos, working software prototypes, etc.) that cannot be provided in PDF, you should provide them separately (either through the class Resources folder or your own upload destination) and submit a PDF that describes how to access the assignment.
If you are working on your project on a team, only one person needs to submit each assignment. Make sure to coordinate who is submitting each, however.
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.
As with all assignments in this class, each milestone will be graded on a traditional A-F scale based on the extent to which your deliverable met expectations. If your deliverable receives below an A, you must revise and resubmit it within one week of receiving a grade. Note that this differs from other assignments: whereas revision is usually optional, for the proposal, your mentor must accept your proposal to indicate agreement on what your final project will be. An A indicates acceptance, and thus you must revise the proposal until your mentor accepts it. Due to T-Square restrictions, your grade will be provided on a 5-point scale: a ‘5’ is an A, a ‘4’ is a B, a ‘3’ is a C, a ‘2’ is a D, a ‘1’ is an F, and a ‘0’ is a failure-to-submit.
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.