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
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 refers to all issues of team coordination and
organization. ALL team members are responsible for
management issues, not jsut the project manager, although the project
manager is the focal point for organization.
- 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
(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.
- The project wiki will serve as a record of all team
activity. Use it for status reports, agendas,
minutes, and other organizational items as well as for
project code and documentation.
- Some items should be distributed by e-mail as well as
being placed on the wiki, to make it more likely that
they will be read promptly. This includes status
reports, meeting agendas, and meeting minutes.
- 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
- 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.
- 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.
- Project managers should prepare an agenda for every
meeting. Someone 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:
- Much--if not most--of the clinic work is done at
- 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.
- 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 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.
- During the fall, the team will
make two presentations, which
are intended to be highly
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.
- 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, 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.
- 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.
- 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:
normally include clear and concise abstracts, a complete table
of all symbols or acronyms used, and a complete and accurate list of
- 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
- It is normally a good idea to designate one team member as
the team editor for written materials so that the style is
At the same time, however,
this does not mean that you can be
sloppy or incomplete and expect that the editor will fix
member must still review all materials. Remember
that your name appears on the cover page of all
written documents: it is your work.
- 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.
- 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
- I expect that both individuals and clinic teams will act in
conformance with the college's Honor Code.
- 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 Citeseer is the only source for
finding things; it's often incomplete.
- 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
- 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
- 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.
- 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
© 2003, Geoff Kuenning
This page is maintained by Geoff