Back to Table of
ContentsABSTRACT
The capstone design course contained in most engineering curricula is a multifaceted educational tool. This course's primary aim is to allow students to synthesize solutions to real, open ended engineering problems. However, the course also provides a laboratory for the learning, development, and practice of leadership skills. This paper deals with materials that can be presented, and some results obtained, when leadership-management training is brought into an engineering design course. This use of an engineering design course deals with the need for leadership in all of our technical graduates, rather than focusing on specialized training for those individuals whose goal is only technical management. The course provides a real life look at how to turn a group of individuals into a team, define and gain consensus as to the true project definition, break the project into manageable tasks, develop good team communication, resolve conflicts, compare alternative solutions to problems, conduct realistic design reviews, and present interim and final project results in a concise and accurate manner.
INTRODUCTION
This paper looks at non technical aspects of design projects. These tend to be the things that keep project/design groups from working smoothly, and from being successful. Many of the topics discussed are part of classic leadership training courses. The premise for including these topics in a design course is that leadership skills developed by students, in any setting, can be a large step toward guaranteeing success both academically and in the work place. Another strong motivation is that we don't know who will become Managers and CEO's, but we do know that almost all engineers will be leaders of a task force, or design group at some time in their career. I don't mean to slight technical knowledge as a necessary prerequisite for good design. The assumption here is that the students have gained the requisite technical skills necessary to solve complex technical problems.
The model for this paper is a full year Electrical Engineering senior design course. The students select from available projects early in the first term and continue to work in groups of two to four throughout the academic year. It is required that their project have a well defined customer from within or outside of the academic community and a faculty advisor from within the EE department. The projects generally require a finished piece of hardware (a few projects are strictly software). The course consists of two hours of laboratory credit (structured as the students and their customer desire) plus two class hours per week (one credit) that addresses the issues discussed in this paper.
The non technical skills discussed in the classroom are:
Each of the above topics could be a course in itself, but this design course is an ideal place to discuss and exhibit these leadership skills. These discussions sow the seeds that will allow our graduates to perform at a higher level as they move from academia into their life work, whether that work be design, manufacturing, marketing, management, or some combination of all of these and more. This paper describes what is meant by each of the above, and then looks at how each of the above topics are presented in the design course.
The question that must be answered during this phase of the design project is "How will we know when we are done?" A very good reference book for this and other aspects of project planning and execution is "Getting the Job Done" [1]. Success in this phase of the project will not insure the success of the project, but doing a poor job will insure some degree of failure or at least much wasted effort. This process takes much time and energy and is typically thought of as non productive work by the students and many practicing engineers. A primary complication is that customers almost never know precisely what they want. The project team must therefore define a proposed solution to what they believe is the problem and consult with the customer to insure that they are addressing the correct problem. The process proceeds in an iterative fashion until there is genuine agreement on the project definition. The final project description must be written down and the definition signed off by the customer, supporting faculty, and all student members of the design team. This sign off procedure guarantees the "buy in" of all parties. Good leaders understand the vital importance of this initial project effort. One caveat is that even the best project definitions change with time. This is normal and expected. When it happens, update the project definition and get sign off again.
This is the stage where the project is broken down into manageable tasks. Each task must be functionally defined and the definition must include a description of the resources necessary to complete the task (time, money, equipment, knowledge). The task definition will also specify who is responsible for the task. This responsible individual should write and sign the task definition document acknowledging their responsibility. Task dependencies must be determined at this time (i. e. which tasks must be completed before others can begin). The overall schedule and cost of the project can then be determined.
This project phase is again looked at as a waste of time (or at least not much fun) by engineering students and practicing engineers. Students/engineers "know" what they need to do to solve their part of the problem and they immediately start working on their technical solution. The fact that it doesn't fit with what the other students in their team are doing, or solve the real problem, is perceived as someone else's problem. The maturity to appreciate the true value of planning takes time. However, the recounting of problems created by the lack of planning (case studies) can perhaps speed up the process.
The definition and planning phases are standard project planning procedures and can be supported by any of the many good project planning software packages. It is useful to have the students use project management software so that they can easily determine project costs and the time frame for the total project in terms of the individual project task definitions. The software will also be of great help in understanding the impact of project changes as they come along, and in providing professional looking reports and graphs that will help communicate and sell the student's ideas.
DESIGN OPTIMIZATION
Design review meetings must be held. These are meetings where the design team's proposed technical solutions are presented to "experts" for their review. It is a forum for comparing alternative solutions and for looking at technical "what ifs". The experts for these reviews should be individuals with expertise in all areas of the project. The customer, industrial experts, and appropriate faculty serve as the panel of experts for the senior design course. These design reviews are not part of project status review meetings that will be discussed later. They should begin as soon as the design group has come up with a proposed solution to their problem and continue until there is consensus among the design group and the experts that a reasonable technical solution has been defined. These discussions insure that multiple solutions are proposed. The premise here is that the first solution thought of is seldom the best and that two heads are better than one.
Just holding design reviews does not insure that the best solution is chosen. It is the formal analysis and comparison of the ideas generated during the design reviews based on a prioritized set of attributes that provides the best solution. A spread sheet listing the needed design features with relative rankings for the effectiveness of each proposed solution (as seen by the review team) and weighting factors as to the importance of each feature is quite useful. An introduction to the Quality Function Deployment procedure is appropriate [2]. This helps the students understand the complex relationships between customer requirements and technical requirements. A critical point that must be understood is that optimization of one part of the problem solution may adversely affect other parts of the solution. As a minimum, it should be pointed out that all of the following must be considered:
Good design requires good judgment and no analytic tool can replace that. The primary goal here is to convince the students that all of the above facets (and many more) must be considered for design excellence. An elegant design that can't be built or tested is not a good design!
Introducing the Boothroyd-Dewhurst design for manufacturing and assembly procedures [3] is a good way to demonstrate that there are well developed procedures for helping in the comparison of different designs. Providing the class with samples of industrial design checklists also helps to reinforce the necessity to evaluate designs from many points of view.
The first aspect of this is how to keep the students, faculty coordinator, the project customer, and other support personnel up to date as the project progresses.
Have regular meetings! These meetings should be scheduled at an agreed upon time at the beginning of the project so that everyone can have them on their calendar and schedule other events around them. All members of the team, including the customer, should attend. These are status meetings. Every team member should report on things that they should have accomplished since the last meeting, tasks which they are responsible for that are ongoing, and the status of tasks that they should be starting before the next review meeting. These are not technical problem solving or design review meetings, they are to make the group aware of any project progress problems and for the assignment of responsibility to get the project back on schedule. These meetings should be documented and this documentation distributed for approval by all parties. For a year long design project these review meetings could be on a weekly to monthly basis. How to hold effective meetings should be discussed as part of the design course. A good workbook for development of effective meetings is "Effective Meeting Skills" [4].
Email is nice and it provides a way of communicating information to the group efficiently. However, it does not replace face to face meetings. This is particularly true at the beginning of a project when the participants do not know each other well or do not know their specific role in the project or within the team. Meetings of part of the team can be counter productive. It will lead to team members having different definitions of the project. A good video that looks at communication issues within a small project group is "You Know What I Mean" [5].
The second part of communication skills, as it applies to the senior design course, is personal development for the students. The capstone design course is a great place for students to practice their oral and written presentation skills. Hopefully they have already had some formal training in speech and technical writing courses. All students in all design groups must be required to prepare written status reports and make status and design review presentations. These presentations should be reviewed by the student's peers, communications experts (we are fortunate to be able to call on faculty from our technical writing faculty for support here), and practicing engineers. This is a low risk opportunity for practicing presentation skills. When these students leave school their abilities in these areas can truly define their success or failure.
The students need to become aware of audience differences, and they need to learn to convey the essence of the problem and their solution at an appropriate level of detail. For example, a panel of investment bankers requires a different presentation than a panel of IEEE Fellows. A general audience requires a presentation that allows all listeners to feel they learned something from the event. The students should make a presentation to their customer when they have formulated a proposed solution. This presentation should be to sell the idea and should be presented as though the students are trying to obtain risk capital for their project, which may actually be the case. They should be required to prepare and present descriptive project information to a non technical audience. Technical students and practicing engineers find this a difficult exercise. We engineers like to talk about technical issues and use technical jargon. The design course is a wonderful opportunity to role play in the presentation arena.
Take time to discuss the stages of team development and how the team members can work toward a high performance team rather than just a group of individuals working on a project. Good references for this material are "Group Dynamics" [6] and "The Wisdom of Teams" [7]. Key things that each design group should understand are: 1) All new groups must work through group behavioral phases, 2) Any change in the make up of the group will cause the group to go through some of the start up phases again, 3) When a group becomes a high performance team it is fun to be a member, 4) The results obtained by a high performance team represent true serendipity.
This is a very important part of the capstone design course, and in the training of effective leaders. It is important that leaders and members of project groups understand that a group of people assigned a common task does not automatically represent a team. It takes conscious effort to build and maintain a team of people focused on a common task. The instructor of the design course must not only talk about, but also demonstrate, team building skills in dealing with the total class and the individual project teams.
Sociologists or social psychologists tend to categorize people by their level of assertiveness and responsiveness. Using these parameters they give names (and define typical behavior) for individuals with high and low amounts of these two characteristics. I like the names used by Wilson Learning [8] for individuals with all possible combinations of high or low assertiveness and responsiveness. Their titles (social styles) are, 1) Analytic, 2) Driver, 3) Expressive, 4) Amiable. The titles are not important. The fact that people are different is! The students should be made aware of what every good salesman knows and uses every day. That is, you must treat different people differently to gain their support. The golden rule here is treat people the way they want to be treated not the way you would like to be treated. Discussion of the above social styles will help students understand why Bob and Mary don't respond in the same way to the same set of circumstances, and that gaining support from different people takes different tactics.
Be sure the students understand that there should be some conflict in a good design group. The absence of conflict means that nobody cares. However, major conflicts must be resolved. The toughest concept for technical students is that conflict resolution is almost never successful when conducted on a rational basis. Conflict resolution is an emotional experience. The goal is to find enough common ground so that the resolution leaves all parties feeling they have won (the win-win situation). A key aspect of conflict resolution, that should be discussed, is that conflicts, in any situation, must not be personalized. If they are the conflict will probably never be resolved. A video I have found useful in this area is "From No to Yes" [9].
The material described in this paper has been presented for the past three years. It is difficult to assess its true success, but some anecdotal data seems appropriate. The project customers and the electrical engineering faculty have commented that the written and oral presentations for senior design projects have improved markedly during this period. Graduates of the program have responded that they are now seeing the purpose of the "strange" material presented in the senior design course and stating that it is helping them in their jobs. One graduate was given responsibility for an off shore engineering project, after less than a year on the job, and has communicated his thanks for our presenting this type of material.
SUMMARY
The capstone design course is not just about finding a technical solution to a particular problem. It is about problem/project definition, project planning, design selection and optimization, team building, communication within the team, presentation skills, interpersonal skills, meeting skills, and conflict resolution. It is a forum where the non technical as well as the technical aspects of success in an engineering career can be highlighted. If we can challenge our students to develop this full range of skills, they will be better engineers/leaders. One of the keys to making this happen, as in all cases where we want to guide behavior and learning, is reward the students for excelling in all aspects of the course and not just grading their technical solution. The reward system must match the wanted behavior!
1. Randolph, W. Alan, Posner, Barry Z., "Getting the Job Done," Prentice Hall, 1992.
2. Sullivan, L. P., "Quality Function Deployment," Quality Progress, June 1986,
pp. 39-50.
3. Boothroyd, G, Dewhurst, P., "Design for Assembly," Penton Publishing, Inc., 1991.
4. Hayes, Marion E., "Effective Meeting Skills," Crisp Publications, Inc., Los Altos, CA.
5. "You Know What I Mean," CRM films, 2233 Faraday Avenue, Carlsbad CA.
6. Forsyth, D., "Group Dynamics," Brooks/Cole Publishing Company, 1990.
7. Katzenbach, J. R., Smith, D. K., "The Wisdom of Teams," HarperBusiness, 1994.
8. "Managing Interpersonal Relationships," Wilson Learning Corporation, Eden Prairie, MI.
9. "From No to Yes," Video Arts Incorporated, 8614 West Catalpa, Chicago, IL.