# Project Launch Protocols

At the beginning of every project teachers and students will spend roughly 5 class periods launching, ideating, and planning their projects. A Project Launch Week occurs only once at the beginning of each project.

### \[DAY 1] Initial Project Launch

This is one of the most exciting parts of every project - the Launch! You have one main goal - to get students excited about the project they are about to begin. You will want to spend the class period conveying three main points:

1. The theme students will create their project around.
2. The skills and requirements their project will need to include.
3. The general time frame they will be working with to complete the task.

You will have the opportunity to spend the rest of the week getting bogged down with the details of each of these points - so don’t spend too much time on them now.\


### \[DAY 1 + 2] Ideation Protocol

_This section borrows from the_[ _Ideation Protocol in our Interactive Web curriculum_](https://cs4all-icm.gitbook.io/js-the-interactive-web/unit-5-simple-websockets-and-final-project/course-final-project-guide#final-projects)_; we recommend alignment of process across as many courses as possible._

_\[MAY NEED TO COME BACK TO EDIT THIS SECTION]_

**Difficulty Rankings**

Students likely ideate their projects and features without a solid understanding of what exactly they're getting themselves into. Have students pitch their ideas, and then give them a difficulty ranking for the project they're about to undertake. This can go a long way to making sure students aren't walking into a project that will present a more significant challenge than they are prepared to or willing to face.

Here's an example ranking system:

* 🌶 - This project will require you to use a subset of the skills we've learned, and will not require you to stretch beyond that.
* 🌶🌶 - This project will require your group to learn at least one new thing independently.
* 🌶🌶🌶 - This project will require your group to learn multiple new things, and will be a challenge to complete within the existing time constraints.
* 🌶🌶🌶🌶 - This project will require entire new concepts that we haven't covered, and cannot likely be completed in the time we have. You will only be able to finish a more basic version of what you're envisioning. Your teacher may not be able to help if you get stuck, and you may have to compromise on the finished project.
* 🌶🌶🌶🌶🌶 - This project may not be possible with the tech that exists in the world currently. If you undertake this project, your teacher will not be able to support you along the way.

It's important to stress that a level 1 (🌶) project is a perfectly servicable goal - do not use it to communicate that a project is not ambitious enough. If a student has communicated a vision for something that is truly not ambitious enough for the current project (e.g. a Unit 2 project that does not use any JavaScript), this is an indication that the brainstorming launch could use fine-tuning, either in the examples shared, or in the way the project criteria is shared.

It's also important to be clear that you're actively discouraging that students tackle a level 4 or 5 project.

### \[DAY 2] Collaboration Form

_\[EDIT TO ADD WHICH PROJECTS SHOULD BE COLLABORATIVE]_

**Team projects are more powerful than independent projects.**

Teachers are strongly encouraged to run all the projects of this course in small groups of 2-4, rather than as individual projects. Group project mode outshines independent project mode for a number of reasons:

* They present a much closer parallel to real-world programming work.
* They leverage students' varied skillsets and reaffirm the idea that everyone has something to contribute.
* They facilitate some low-stakes, organic peer tutoring.
* They lower the project-to-teacher ratio, allowing a teacher to spend more time supporting each group.
* They fold in additional real-world skills, like division of labor, team communication, prioritization, and compromise.

These are features of a well-run project mode, and require more support than a simple "work in groups" direction. Refer to the[ project mode best practices](https://cs4all-icm.gitbook.io/js-the-interactive-web/unit-5-simple-websockets-and-final-project/course-final-project-guide#project-mode-best-practices) for tips on implementation.

**Ranked Choice Groupings**

Student-assigned groups can leave some students feeling left out, and can let good friends who don't work productively together end up paired.

Teacher-assigned groups can overindex on the "icebreaker" mentality and result in complete opposites working politely together on a project that doesn't actually interest either of them.

The strongest grouping mechanic is any variation of ranked choice. Ask students to rank their top 6 project partners, or do ideation before project groups are formed and have them rank their top 6 project ideas. With those student responses in hand, you can create groupings of 2-4 that ensure that everyone is working with someone they've consented to work with, while still having enough control to ensure that unproductive pairings aren't repeated.

You can also do fold some social-emotional learning by asking more precise questions like "Who is someone who you don't know well, but think you could learn from?" and "Who do you most enjoy working with?" followed by "Who do you work productively with?" - especially if you specify that students must provide a different name in each field, these pointed questions can help attune students to the fact that group formation is about more than working with their best friend.

**Flexible Grading**

The strongest project modes occur when you can take students' minds off of grading altogether.

While students should have a sense of what the expectations of project mode ought to be, using grades as the primary motivator for student work will lead to situations where students who are struggling to meet a specific standard feel tremendous stress, and students who meet the standard easily will have a defensible reason to say "we're done" and stop work.

Emphasize the core skills students need to meet in the planning phases, and de-ephasize it during the work phases.

Consider de-emphasizing demonstration of specific content knowledge, and emphasizing the following items in your rubric.

* Worked the whole time.
* Equitably divided the labor.
* Completed all planning documents, including mockups, design specs, MVP definition, and feature roadmap.
* Presented their work & completed corresponding presentation practice or planning.
* Learned at least one new thing, or demonstrated a skill from a lesson / lab that they struggled with earlier.

A student or student group that does all these things should receive an A on any given project.

If a teacher is using a mastery-based grading system, they should alert students to opportunities they have to demonstrate mastery of a skill they struggled with previously.

A good grading system should encourage student risk-taking and the decision to work outside your comfort zone, not reward it.

**✨Make Groups prior to Day 3 and on!✨**

### \[DAY 3 + 4 - EXTEND AS NEEDED] Initial Project Planning

Projects that have thoughtful and thorough planning always have stronger execution. Therefore, teachers should be empowered to extend and adjust Days 3 and 4 as needed if students require more time to plan and ideate - this will only help ensure the long term success of each group.\


_\[EDIT LATER: Does this get clarified in the design journals?_

* _MVPS \[Day 3]_
* _Wireframing or Flowcharting \[Day 4]_
* _Outline Roles (for group or partner work) \[Day 4]_
* _Calendaring \[Day 5]]_

**Planning and punting are the best ways to sustain student momentum.**

One of the most common challenges in any sustained project work is the temptation for a student to say "I'm done" as soon as they've created anything at all.

This can indicate that a student really has a fully realized vision, but more often indicates that a student simply isn't that interested in what they're doing, and would like your permission to stop working on it.

This can be addressed in part with an explicit expectation that students "work the whole time," but that places the onus on a teacher to decide what additional features a group should add to their project, and thus the vision is no longer the student's, and the motivation has shifted back to compliance.

Have your students spend a significant amount of time planning (up to 1/3 of the total work time) to ensure that they are fully invested in the project, and have them generate artifacts along the way. Pointing back to wireframes, mockups, and feature roadmaps can ensure that students are always executing on their vision, and not simply complying with a directive to keep working.

**Feature Roadmap**

As students begin brainstorming their projects, encourage them to break their project up into versions, and help them define the most basic version (the[ Minimum Viable Project or MVP](https://www.forbes.com/sites/theyec/2021/12/08/a-review-of-the-minimum-viable-product-approach/?sh=6b7be00f2e20)) of their idea before they begin building anything.

Here are some examples of how to scale down student ideas to more manageable prototypes:

* When a student wants to build a college matching site, encourage them to start with only three possible matches (instead of hundreds).
* When a student wants to create a lifestyle improvement app that addresses nutrition, exercise, mental wellness, and boundary setting, encourage them to identify which of these features is most core and build it out first.
* When a student wants to help a user pinpoint their nearest grocery store, start with the simplest location input (e.g. a zip code) and a hardcoded list of 5 grocery stores.

**Mockups, Design Guides, & Wireframes**

When working on a project with an HTML user interface (as is the case for all projects in this course), have students mock up their pages before they start work. These mockups will be an essential reference to ensure all members of the project group have a shared vision.

Mockups will also ensure that the teacher can help students with a specific element of the page with a holistic view for how it will be incorporated into the project as a whole. This lessens the likelihood that a teacher will advise students to do something one way in the early stages of a project and then advise students to completely redo that section of the page when it's placed in the larger context of the project.

Design guides can also help ensure that students are agreed on the creative choices and boundaries that will guide their front-end work. Design guides might include a list of pre-approved color codes, typefaces, font sizes, or even a mood board or bank of images.

✨ **TEACHERS: Make Learning Plans Now!** _We recommend one learning plan per student, even in group work, with learning plans based on the student project roles. You may want to also offer a generalized group learning plan, but this is optional._

