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.
- 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 has set up an e-mail list for the team,
advisor, and liaison. Use the appropriate alias for
all communications so that we have a reliable record
and nobody is inadvertently omitted.
- Everyone should read their e-mail at least once a
day. Make sure your preferred email is on the team list.
It is your responsibility to ensure that
you read all Clinic-related e-mail promptly.
- Remember that the project may be confidential, and
respect that confidentiality. In particular, do not
use any cloud services for the project without asking
first.
- If the team uses any other services to communicate,
such as Slack, ensure that the sponsor is aware of
that fact, has approved it, and has a way to retrieve
a record of the your communications.
- 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.
- 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.
- Project managers should compile a weekly list of completed
project tasks and milestones, and of tasks still to be
done.
- 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
prior to
meetings and distribute 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 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.
- Complete final drafts of all proposals,
presentation and report outlines, and mid-year and final reports
at least one week 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 year, the team will prepare and deliver
presentations to members of the Clinic program.
Part of the point of these presentations is
to learn how to communicate technical information to diverse
audiences, so I expect
that you will try
to produce a good talk 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 with me 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. "Um, I'm going to
get around to that tomorrow" isn't a valid excuse in either
Clinic or the real world.
- 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.
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.
- 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.
- 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
final report.
- I expect that both individuals and Clinic teams will act in
conformance with the college's Honor Code.
Technical
- 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 Scholar, SciWeb, or DBLP is the
only source for
finding things; search engines are 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
project.
- 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.
- 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.
- 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.
© 2020, Geoff Kuenning
This page is maintained by Geoff
Kuenning.