Team Charter

What do we want to accomplish? What skills do we want to develop or refine?

• Manage / stay on top of deadlines by outlining HW assignments in the Slack / Doc, using a calendar. 
• Value all team members, their ideas, and experiences they bring.
  • Use bi-weekly check-ins to gauge member satisfaction and evaluate whether individual/personal metrics/goals are being met to gauge member satisfaction and evaluate whether individual/personal metrics/goals are being met.
• A final prototype is achieved.
• Submit a design.
• Be better educated on the chosen field of study / market as well as bioengineering as a whole.
• Improve skills such as:
  • Team dynamics/Communication/Collaboration
  • Stakeholder interviewing
  • Problem discovery 
  • Large dataset analysis
  • Teamwork strategies
  • Project management skills
  • Device fabrication
  • Device testing/analysis
• Become friends 🙂
• Get a good grade.
• Be passionate about the project.
• Write a research paper if time allows.

• Come to group having looked at the agenda for the upcoming meeting
• Team meetings must be focused on action items that need to be completed as a team using something similar to a Gantt Chart and priority rankings.
• Minimum # of hours for each member to spend outside of class for every 2 weeks: 8 hours 
• Be thoughtful and respectful in presentations of ideas and of team member time 
  • Respectfully “call-out” folks who may be speaking for too long / provide opportunity for more-reserved members to articulate their opinions 
  • All team members must speak at least once in each discussion and will be moderated by the assistant facilitator 
• Everyone should speak/present their thoughts on EACH discussion at least once
• Participate in team working meetings outside of class during lunch on Wednesdays  
  • discuss schedules for the week ahead and communicate any foreseeable issues
• If at a design block or are stuck, use the slack channel specific for design/technical issues (MATLAB, code issues, difficult diff eq) to reach out for help
  • Slack channels for subteams and/or project sub-groups
• Deadline renegotiations, for when a member knows in advance of a deadline that they cannot complete a task → A week notice
  • Academic or athletic exceptions and conflicts (exams, projects) should be discussed at the time of setting the deadline
  • Consequences for repeated failures to meet deadlines

• Order of priority for decision making:
  • Majority rules
  • Consent-based
  • Ranked choice

• Before every meeting the scribe for that week provides a quick bulleted agenda for the day

Goal / Objective for Tuesday meetings: Discussion and Planning 

Assign tasks and goals for the intraweek period

Present a brief overview of progress made in lab, compare work accomplished with goals set in the previous week

Goal / Objective for Thursday meetings: Grunt work

• Build sessions
• Sub-team work
  • Make sure sub-groups are working on distinct modules of the same project. Either a point person or the team as a whole, lets sub-groups know what they should focus on during that week.
  • Point person of the sub-team must write documentation outlining work completed, work-in-progress, and next steps. Can be used for the purpose of helping folks catch up / stay up-to-date on what that subgroup is working on. 
    • Include documentation of both successful and developed ideas in addition to ideas discussed but not developed/cut
  • Rather than forced sub-team rotation, provide an opportunity for team members to rotate sub-teams should they choose
    • Rotating members take primary responsibility to catch themselves up on existing material using common documentation, meeting minutes, and records of design history
• Group problem solving 
• Discuss sub team challenges/problems if needed

Goal / Objective for Friday – Monday Period: 

• Sub-groups and sub-systems must check-in during the interweek time 
  • If issues arise / are discovered in the sub-teams -> communicate to general Slack to get feedback before the weekend

Quality of work standard policy

• Rushed work and poorly planned work can lead to poor quality work, but poor quality can also just occur during prototyping. Have members of sub-system work to address issues raised (issues will likely be brought up by members of the sub-system or of another sub-system whose function is affected). 
  • If a part is unable to be made to the necessary quality, adapt/re-design (limitation of hardware, supplies, financial limitations,etc)
  • If a proposal/document is not to the expected quality, it should be discussed and revised before its final deadline. It is the responsibility of all of the sub-group to ensure that any work coming from their members should be of agreeable quality.
  • Define metrics for quality assurance: determine environmental hazards, create simulations and physical models; report probability of failure, safety factor, min/max forces or other stimuli acceptable
    • set goals for what metrics we want to achieve
      • example: IP Code, or Ingress Protection Code is defined in IEC standard 60529 (waterproof rating commonly used in electronic devices)

• An internal discussion, followed by a peer-mediated discussion, followed by a professor-mediated discussion
• A consensus building approach, where common areas of agreement are identified and built upon until the conflict is resolved
• Conflict will be resolved by a dance-off 

• Donuts

Layers of consequences – Start with an oral warning, peer & self-evaluations to help Professor Rosario understand who is contributing / not contributing.