Meetings and Progress Reports
We use periodic meetings (typically weekly) to keep track of the
progress to date and then adjust the remaining plan as needed. The
plan may be adjusted both due to time issues (delays or advances) as
well as newly learned material (e.g. tool problems).
Meetings can contain topics from various categories:
- a) Design and Implementation (or theory) progress reports. These items
describe progress to date, next steps, and anticipated
problems. Design interfaces are also presented: application
programming interface, device drivers, data structures, etc. These
interfaces are presented to enable other team members to recommend
improvements or identify constraints, and eventually use the
interfaces in their own work (for team work). Most of all, they should
related to milestones in reaching some long-term goal.
- b) Research and concept-framing reports. These are the looser, more
research-oriented tasks, with the goal of identifying the problem and
presenting it in a clear understandable way. For example, consider
identifying issues involved using hardware feature X to support
software feature Y. What related research work has been done? Are
there corollaries in other fields? What are some approaches (feasible
or not) to an implementation? What are the implications of such an
implementation?
At least 24 hours before the meeting you will need to submit a
progress report to your adviser (and your team members). In this
report, you will identify the following
- Current progress on project: tasks completed, tasks under way.
- Technical content of tasks completed or under way (for working
meetings): by presenting this work, the rest of the team stays up to
date with the latest results.
- Tasks to complete before next meeting.
- Issues that will obstruct current or upcoming tasks: anticipated
problems, software or hardware needed, etc. Be sure to include
sufficient background information so that other team members can offer
practical solutions. The report must be submitted well before the
meeting to allow the other members to find solutions.
- Metrics on completed tasks: actual hours needed to perform task
(with breakdown), areas which deviate from estimates, causes of
deviation. This enables you to improve estimates for future tasks to
make them more accurate.
This report must be in a PDF format. (I would suggest PowerPoint or so
to create it so that you may include figures and reuse it for
presentations.) Depending upon the type of meeting, you might give a
presentation, or else merely discuss issues.
I may grade your report in the following categories. I may also ask
all team members to grade their colleagues' reports. The reason is to
provide feedback for how to improve it.
- Conciseness - get to the point as quickly as possible, but no
quicker. Use diagrams when useful.
- Background - provide enough context for everyone in the meeting to
understand the issues.
- Delivery (for oral presentations) - speak clearly, let us know you
care about the material and are proud of your presentation.
- Appearance - make the report look good. Structure the report well, use
white space appropriately, use color to simplify the interpretation of
data or diagrams.
- Relevance - leave out things which don't matter.
Meetings and reports are structured this way to help you work more
efficiently, learn how to monitor your performance, develop more
efficient working methods and estimation skills, improve your
communication skills - in short, to make you a more effective engineer
and to get you promoted faster after you start working in industry.
Thanks to Alex Dean for these guidelines.