Advice on teaching senior design classes

In response to a post on Engineer Blogs (T-minus 1 month and counting) about a new professor who has been assigned to teach a senior design class, I put together some observations.  Although I commented directly on the original blog, I’ve expanded on those comments for this post.  I’m on sabbatical this year, so this post also serves as a way of passing on advice to the faculty member who will be teaching the course this year.

I have taught a senior engineering design class for the past 2 years, jointly with an instructor who has done it for many years.  I also taught VLSI design project classes for first-year grad students for the first 10 years of my career as a professor.  My comments here are a distillation of the slightly different approaches of these experiences.

A senior design project should not have much technical content to the lectures—otherwise there is no time for doing a real project. It is assumed that the students have (or can acquire) the technical skills needed for their projects, but have not had opportunities to learn the communication and management skills needed to pull off a real group project.

As much as possible, the projects the students do for senior design classes should be student-directed.  It is not the point of such a class to provide cheap labor to local companies (a mistake our administration is aiming for in order to raise funds) or to university research labs (a common mistake in science departments), but about making the transition from learning stuff that other people already know to discovering new things (in science) or making new designs (in engineering).

A senior design project course should not be like first-year chem, with a lot of new material to be learned and practiced.  Thus lecture should be limited to non-science, non-engineering stuff (Gantt charts, group charters, oral presentation, team formation, proposal writing, selecting research topics, lab safety, library research skills, … ). What our senior design class has for “lectures” is instruction on team formation and engineering management and a lot of practice at writing reports and doing presentations. As much as possible, the students should be presenting material to each other, to get more comfortable being the sources of information, rather than just sinks.

If the projects are all individual, not group, then you could probably drop a lot of the team-building management stuff (though Gantt charts can be useful even for single-person projects) and replace it with students presenting proposals and tutorials.

Don’t assume that because students have had group projects in every class since grade school that they have any idea how to run a group—most group projects in school and college are toy projects that can most efficiently be done by a single person, so students have learned that a group project consists of the smartest or hardest-working person doing all the work while the rest chat about their weekends.  No matter what noises their instructors have made about group work, that really is the most efficient way to do most high-school and undergrad “group” projects and students have learned that lesson very thoroughly. (See my blog post about group work.) A real group project, one big enough and with tight enough time constraints that one person can’t do it, fails with that approach.

There are sometimes a few holes in the prior engineering education that have been identified by the instructors over the years—stumbling blocks that the instructors know many groups will have trouble with.  (For example, EE projects nearly always have problems with power-supply design and thermal design, and computer engineering students usually don’t spend enough time thinking about choosing the right microprocessor.) It is very tempting to put together lectures covering these topics to ease the path for the students.  Bad idea.

We used to do lectures on key topics, but students still made the same mistakes.  Last year, we switched things around. We told the students about some of the common stumbling blocks, and scheduled lectures about them.  But we did not give the lectures.  Instead, we required the students to sign up in groups to do some library research and present tutorials on these subjects to their fellow students.  Note that this serves several of the goals of the class: organizing group work, library research, becoming an information source, practicing presentations, and covering the stumbling block.  The resulting lectures are not as polished as if a lecturer with 30 years of experience gave them, but they are usually adequate, and the students who prepare the lectures learn far more than they would have listening to a lecture.

Some advice (like making sure that you have a source with parts in stock for any part you hope to use) can be given in lecture form, as anecdotal reports of disasters that occurred (or were narrowly averted), but those lessons are generally only learned first hand.  Despite years of giving such advice, I recently designed a printed-circuit board around a part that has not been available for almost a year (see H-bridge not available and Possibly salvage the boards).  In my defense, I thought I had checked, but I must have mistyped the part number, since a similar part  with the same name but with one digit different was available. Of course, I’ve taught students for years to double-check such things, and failed to do it myself.

We also used to allow project sponsors (faculty or outside sponsors) to pitch projects to students to try to recruit them.  After one terrible quarter, in which almost every project pitch was terrible (professors pitching ideas for designs that were available off the shelf from Amazon for $50, others waffling on for a long time content-free, …), we stopped allowing that.  Now project sponsors can put up a few paragraphs about their project ideas and contact information, and it is up to the students to find or create projects that interest them.  Outside speakers only present if specifically invited to do so by a project team—most project pitches come from students trying to recruit team members with specific skills for a project.

Having students prepare lectures does not save time for the professor. It takes much more time to meet with a group, make sure that they have covered all the important points, helped them find reliable information sources, and given them feedback on their slides, than it does to prepare a lecture on material you are familiar with.  On topics I’ve taught recently, it may take me as little as half an hour to prepare for a 70-minute lecture.  (Though if I have to prepare slides, it may take much longer—I gave a 90-minute talk yesterday to high-school students, but spent about 10 hours updating the slides from previous years, and an invited talk at a conference may take me 40 hours to prepare.)

A good design class requires a lot of time from the professor, just not in lecture prep. The time is spent providing detailed feedback on written drafts, meeting individually with students or teams, and hanging around the lab to help students debug their projects.

We do a 2-quarter sequence for our senior design project.  The first quarter is spent on team formation, scoping projects, and writing detailed proposals (including allocation of tasks to individuals, Gantt charts, budgets, and funding sources).  The second quarter is spent on doing the project and writing it up.

The first quarter uses a text (Teamwork and Project Management, 3rd edition by Karl A. Smith and P.K. Imbrie), but we do not lecture from it.  Instead, we do one lecture from the first chapter as an example, then assign student groups to present each of the remaining chapters.  These student groups are arbitrary groupings, not the final project teams.  We form the presentation groups to make sure that there is a mix of different personality types, and the groups choose which chapters to present—there are lots of different ways to do this, and we play around with different approaches.  The final teams are formed by accretion around projects—students have to form their own teams, making sure that they have all the skills needed for their project, that the group can work together, and that everyone has a task that they are primarily responsible for.

Incidentally, I don’t like that text much—I find the writing awful.  But it has a good collection of pointers to other sources (in fact, that is about all it is), so we warn the students to treat it more like an annotated bibliography than as a textbook, and to get their content from other sources.  Some students do better at this than others, but generally the student presentations are more coherent than the book.

In addition to the presentations during the quarter, the students have a number of assignments that amount to portions of the final project proposal (an initial intro describing the goals of the project, a team charter, a block diagram, division of labor, Gannt chart, budget).  At the end of the quarter they have to have folded all these components into a complete project proposal, which they present in writing and orally.  We usually schedule the oral presentations either just before finals week or during the final exam slot for the course, and we invite faculty and students to come.  Audience attendance varies.

The second quarter is all project time, and there are different approaches used by different instructors.  I’ve found it useful to concentrate on improving the students’ communication skills both written and oral.

I require a complete draft of the final report every 2 weeks and provide extensive feedback on it.  For many of the students, this is the first time they’ve written technical material and gotten meaningful feedback (though a technical writing class is a prerequisite to the senior design course).  To reduce my workload a little, I split the class into 2 parts, and alternate which weekend I’m providing feedback to each part.

In addition to the written reports, I meet with each group for half and hour to an hour a week.  I require these meetings to start with the students presenting a 2-minute description of their project, as if to someone that had never heard of it.  This serves two purposes: to let me do a context switch to the right project and to have them practice summarizing their work.  Initially, they are mostly really bad at it, but by the tenth time doing it, they generally have a smooth, clear presentation of the gist of their project—just what they need for job interviews.  At the weekly meetings, I talk with them about the technical content of the projects, help them debug problems they are encountering, and help them find sources of information.  I sometimes have to fall into a managerial role (chiding them about schedule slippage), but as much as possible I try to have them solve their own managerial problems.

In addition to the individual meetings,  I have a whole class meeting once a week, where students present informal progress reports to each other (and sometimes get good advice from each other on solving particular design problems).  We also cover some topics that could have been in the first quarter but weren’t (like poster design for conferences). In the middle of the term, I have the students practice more formal presentation to the whole group, and provide feedback on presentation style.

At the end of the second quarter, the students present their work in 3 formats: a detailed engineering design report, a poster summarizing the design, and an oral presentation.  The oral presentations are 5 minutes per project plus an extra 5 minutes for each group member (so a 1-person project gets 10 minutes, but an 8-person project gets 45 minutes).  All group presentations in both quarters require that everyone in the group speak, for roughly equal amounts of time, but the group decides how to divvy up the material, how to manage the transitions, and how to make combined slide sets.

By the end of the two-quarter sequence, each student has participated in at least 4 formal presentations, 8 informal progress reports to the group, 10 2-minute talks, a proposal, 5 drafts of a design report, and a poster, all centered around an intensive engineering design task that they have chosen for themselves.

Related articles

• Skills at the center (gasstationwithoutpumps.wordpress.com)