Proposal (Fall 2017)
Due: Sunday, October 8th, 2017, 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, your teammates (if you’re in a team), and your mentor regarding what you will do for the rest of the semester. You’ll submit a draft of your proposal, but there may be 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 should propose a 100-hour project, while a team of five should propose a 500-hour project.
As part of your project, you’ll also deliver a number of related deliverables. You’ll submit:
- Eight weekly status reports, detailing your progress the past week, the challenges you’ve encountered, and any revised expectations for the final project.
- Two intermediate milestones, such as video presentations or prototypes to solicit feedback from your classmates and mentor.
- A final paper and presentation, reporting on your project.
- The final project itself (such as the data and research methods for the research track, or the tool itself for the development track, or the course material for the content track).
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. 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:
- 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 intermediate milestones and final paper.
- A calendar describing weekly milestones from the start of Week 7 through the end of Week 16.
- Descriptions for your two intermediate milestones. You should consult the assignment page for those for a better idea of what to include.
Additionally, all team projects should include the following:
- The members of your project team.
- A division of responsibilities among the members of the project team. This division will help support the proposal as an agreement not only with your mentor, but also with the other members of your team.
Research track 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 background literature in the area that leads to your research question.
- A description of the research methodology that will be used, including the independent and dependent variables, internal and external validity, and the connection between these details and the research question.
- A description of the data that will be needed or obtained, including spring-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.)
Development track 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 spring-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.)
Content track proposals should also cover the following information:
- A description of the content to be taught.
- A description of the tools that will be used or developed for the teaching of that content (such as the platform on which the content will be hosted).
- An overview of other resources currently available for this content, and why your addition is needed.
- An outline of the content and its structure.
- A description of the nature of the development (e.g. video, text, interactive examples).
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 assignment submission page 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 links to or otherwise describes how to access that material.
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 such an emergency, please contact the Dean of Students.
As with all assignments in this class, this assignment 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 may revise and resubmit it once within two weeks of the original due date or one week of receiving a grade, whichever is later. Note that this should not be treated as a de facto free pass to submit sorely lacking work initially; we reserve the right to deny resubmission or grade a resubmission more harshly if we perceive the original submission was lacking in earnest effort.
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. You receive 1.5 participation points for completing a peer review by the end of the day Thursday; 1.0 for completing a peer review by the end of the day Sunday; and 0.5 for completing it after Sunday but before the end of the semester. For more details, see the participation policy.