Expectations and Guidelines for Clinic Teams

(Note: this document is adapted from one written by Prof. Mary Cardenas of the HMC Engineering Department, who in turn adapted it from a memorandum written by Profs. Clive Dym and Philip Cha. Many thanks to those people for their contributions).

The purpose of this document is to state my expectations relating to your work on your clinic project. These can be divided, roughly, into two major components: management and technical. The management expectations focus particularly on ways to successfully meet deadlines with maximum efficiency and input; the technical expectations are concerned with styles of doing good technical work. Experience suggests that good engineering work requires both technical and management competence.

Please note that these expectations and guidelines are intended to help you and your fellow team members do your work. Remember that after all is said and done, the project you will complete this year is your work, not mine. That is, I are am here to coach, advise, offer suggestions and provide support. You are here to do a job, namely the work of the clinic project.

Management

Management refers to all issues of team coordination and organization. ALL team members are responsible for management issues, not just the project manager, although the project manager is the focal point for organization.

  1. Communication among team members, the faculty advisor, and the clinic liaison(s) is vitally important. Therefore:
  2. Attend all team meetings. Inconsistent or poor attendance will affect your ability to work harmoniously with your team. It will certainly affect your performance and perceptions of your performance. It will also affect your grade.
  3. All team members (including the project manager) must e-mail a weekly status report to me and to the project manager. Failure to file regular reports will have a negative effect on your grade. Status reports should also be placed on the Wiki.
  4. Project managers should compile a weekly list of completed project tasks and milestones, and of tasks still to be done. The list should be maintained on the project Wiki so that it can be consulted by everyone in the project.
  5. Project managers should prepare an agenda for every meeting. A team member should be assigned to take minutes of all meetings, keeping track of all major issues raised and their resolution. Distribute copies of the agendas via e-mail or on the Wiki prior to meetings and post a draft of the minutes within one day after each meeting. The minutes should be complete and comprehensive, and not simply an edited agenda. The minutes are very important because:
  6. Complete final drafts of all proposals, presentation and report outlines, and mid-year and final reports at least three days before their due dates. These drafts should be complete. It is not acceptable for a paragraph, slide, page, or section is marked "to be completed later," because then it is impossible for me to provide the review and guidance that is my part of the bargain. Submission of incomplete drafts will seriously harm the entire team's grades.

    There is no justification for waiting until the last minute to complete deliverables whose due dates are known long in advance. On the other hand, early completion reduces the stress level associated with major deadlines. Even more important, timely completion also leaves a margin for error, for making last-minute changes, etc. This is important because all presentations and reports require iterations before their final versions are attained.

  7. During the fall, the team will make two presentations, which are intended to be informal design reviews. Your preparation for them should involve preparing a short discussion of the problem and possible approaches to a solution. You can use either projected slides or the chalkboard for that purpose. You should plan on a lot of interaction with the audience.
  8. In the spring, you will make one semi-formal presentation to an audience that includes Engineering clinic students. Part of the point of this presentation is to learn how to give good technical talks, so I expect that you will try to produce a good presentation and to learn presentation skills. In particular, you should plan to spend a fair amount of time preparing the presentation, including getting my approval of the outline, and on doing a "dry run" at least two days before the actual presentation. The presentation must be complete before the dry run begins.
  9. Except under extraordinary circumstances, you will lose points (major points) for missing meetings and for failing to complete assigned tasks when they are due. If you become aware of a possible problem you may have completing an assignment, notify your project manager immediately. Do not wait until the deadline to expose the problem. "Um, I'm going to get around to that tomorrow" isn't a valid excuse in either clinic or the real world.
  10. Remember that proposals and reports constitute a permanent record of what you are proposing and reporting. These written documents also constitute your presentation of your work to the "outside world," e.g., the clinic sponsor, your faculty advisor, other faculty, etc.

    Thus, all reports must be written in prose that is clear and grammatically correct. All nomenclature, notation, symbols, etc., must be uniform throughout each report. Allow adequate time (at least two days) for fellow team members to read sections of the report that you have drafted. Further, make sure that every team member reviews all materials before they are submitted to me, the clinic office, or the clinic sponsor. (Further advice and support for writing may be obtained from the college's Writing Center.)

    Also remember that clinic reports are not chronologies. They are technical reports that:

    Technical reports normally include clear and concise abstracts, a complete table of all symbols or acronyms used, and a complete and accurate list of references.

    Over the years, I have found that there are many writing errors that show up repeatedly. To help you avoid them, visit my handy and brief Writing Guidelines page.

  11. It is normally a good idea to designate one team member as the team editor for written materials so that the style is uniform. At the same time, however, this does not mean that you can be sloppy or incomplete and expect that the editor will fix things. Nor does it mean that one team member does all the writing. Every team member must review all materials. Remember that your name appears on the cover page of all written documents: it is your work.
  12. As advisor, I will review your reports for technical correctness, fluency and style. Although I will often catch spelling or grammar errors, you should not depend on me to do so, since proofreading is not my primary job. Try to provide me with a perfect document, so that if you make a small human error there's a chance I can catch it. If your document is riddled with errors, I reserve the right to return it to you unread, or to adjust your grade(s) accordingly.
  13. Remember also that your work on a clinic project is course work. Consequently, you must satisfy not only your clinic sponsor and liaison, but your faculty advisor (me) as well.

    In particular, turning in a draft report to your advisor does not mean your work is done. Your work is considered complete only when I have accepted your final report.

  14. I expect that both individuals and clinic teams will act in conformance with the college's Honor Code.

Technical

  1. First, do a very thorough literature search, using the college library and its human resources as well as the Web, to see what's "out there." Find out what has already been done and what is already known in areas related to your project; there is no need to reinvent the wheel. Don't limit your searching to the Web; there is still a lot of printed literature that hasn't been indexed or isn't online. Don't believe that Google, Citeseer, or OdySci is the only source for finding things; search engines are often incomplete.
  2. Second, resist the temptation to start coding too soon. As a rule of thumb, every hour spent on design will save you 5-10 hours of coding and debugging time. Be sure you thoroughly understand your approach before you attack the project.
  3. Notwithstanding the above, remember the value of quick tests and prototypes. If you're not sure whether a particular approach will work, slap together something easy (shell scripts, ugly little test programs, measurements, etc.) to give it a try. When you start the real system, you should have a fair amount of confidence that you know what you are doing.
  4. Measurement is a difficult and tricky art. If you need to measure something to finalize a design choice, consult with me about your measurement plans. Do not just write the first test program you think of and time it once, or even 100 times, because you will almost certainly get invalid results unless you design your experiment carefully.
  5. Above all, remember that this is a professional project, and you are expected to produce professional results. That means you need to produce full documentation of what you have done. It also means that you must follow good style guidelines. If the sponsor has a style guide, you must adhere to it. If not, you must agree on a project-wide style guide that everyone will follow.

© 2011, Geoff Kuenning

This page is maintained by Geoff Kuenning.