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

1. Communication among team members, the faculty advisor, and the clinic liaison(s) is vitally important. Therefore:
   • You should immediately put together a list of the team, advisor and liaisons together with surface mail addresses, phone numbers, and e-mail addresses.
   • The department will set up an e-mail list for the team, advisor, and liaison. Use it extensively to ensure reliable and verifiable communication among the parties to the clinic project.
   • Everyone should read their e-mail at least once a day. If your primary e-mail isn't on Turing, either set up a .forward file or ask both me and the CS staff to change the list to point to your preferred account. (I keep my own alias list, so you must notify me as well as the staff.) It is your responsibility to ensure that you read all clinic-related e-mail promptly.
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 leader) must file a weekly status report with me and with the team leader. Failure to file regular reports will have a negative effect on your grade.
4. Team leaders should compile a weekly list of completed project tasks and milestones, and of tasks still to be done. The list should be maintained online so that it can be consulted by team members, and should be e-mailed to me weekly.
5. Prepare an agenda for every meeting. Take minutes of all meetings. Keep track of all major issues raised and their resolution. Distribute copies of the agendas prior to meetings and circulate a draft of the minutes within one day after each meeting, preferably by e-mail. The minutes should be complete and comprehensive, and not simply an edited agenda. The minutes are very important because:
   • Much--if not most--of the clinic work is done at these meetings.
   • The minutes form a current and (internally) permanent record of what's been learned, what's been decided, what's to be done, and how it's to be done.
   Keep the agendas and minutes in a well-known subdirectory of the team project directory for ready reference.
6. Complete final drafts of all proposals, presentation and report outlines, and mid-year and final reports at least seven 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 harm your grade.

   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 year, the team will make two presentations that are intended to be relatively informal, particularly in terms of (1) representing work in progress and (2) being presented to smaller audiences comprised largely of colleagues who are being asked to review and provide input about the progress of the team's work to date. These presentations are similar to the design reviews that are done in industry.

   However, because part of the point of clinic presentations is to get practice in giving technical talks to an audience of more than a few people, I also expect that effort will be given to producing a good presentation, and to learning presentation skills. In particular:

   • A practice presentation ("dry run") with me should be scheduled for at least two days before the actual presentation. The dry run is intended to work out problems with both the presentation and the way it is delivered. As such, there needs to be time allowed between the dry run and the presentation itself so that any necessary changes can be made.

     Outlines of the presentations and decisions about content and style should be completed at meetings separate from and before the dry runs. Remember, the practice presentations are to be used for practicing presentations, not for preparing them.

   • A draft of the presentation slides should be made available to me at least two days before the dry run. This is to allow time for changes in the general organization and content of the slides.
8. In the spring semester, each team will make a more formal presentation in McAlister. These presentations are held in cooperation with the Engineering clinic program, so you should plan for a somewhat less specialized audience. Since this presentation serves as preparation for the talks you will give during Project Days, you should try to make it more polished than the first two presentations. In particular, you should concentrate more on having figures and graphics that will help to explain your project to an intelligent person who knows little or nothing about computer science. Again, a dry run (or runs) should be scheduled ahead of time.
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 team leader immediately. Do not wait until the deadline to expose the problem.
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:

    • Explain why a project was undertaken;
    • Provide the technical justification for the work performed;
    • Describe the work that was done; and
    • Report and explain the results that were obtained
    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.
11. It is normally a good idea to designate one team member as the editor and final arbiter of all written materials so that a uniform style and nomenclature will be evident in the document that is being produced. At the same time, however, this does not mean that individually crafted pieces can be sloppy or incomplete because they place an unfair and unproductive burden on the team's designated editor. It also does not nullify the responsibility of every team member to review all materials. Remember that every team member's name appears on the cover page of all written documents, that is, every team member signs on to the team's products as representing his/her own work.

    When writing assignments are distributed among team members, it is also a good idea for every team member to use the same word processor, graphics programs, etc. It might be useful to explore software tools for supporting team writing.

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 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.
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 do 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.

© 2001, Geoff Kuenning

This page is maintained by Geoff Kuenning.