Is Working in Teams Necessary to use the Engineering Design Process to Solve Clinical Problems?
Dale Feldman*
Biomedical Engineering, USA
Submission: November 21, 2017; Published: December 11, 2017
*Corresponding author: Dale Feldman, Biomedical Engineering, USA, Email: dfeldman@uab.edu
How to cite this article: Dale F. Is Working in Teams Necessary to use the Engineering Design Process to Solve Clinical Problems?. Curr Trends Biomedical Eng & Biosci. 2017; 10(4): 555791. DOI: 10.19080/CTBEB.2017.10.555791.
Opinion
The scope of this Journal includes “the development and dissemination of knowledge [particularly to] coalesce the design and problem solving skills of engineering with medical and biological sciences.” The subject this paper will address is “the value of the use of teams in the engineering design process to solve problems”. First let’s address the value of the engineering design process vs. the scientific method in biomedical research. In the scientific method, the standard to use in biomedical research, a hypothesis is generated as a potential answer to an important question. An experiment is set up and carried out to prove or disprove the hypotheses. The results are looked at in terms of how they compare and follow from previous studies, what are the ramifications related to the original question and what needs to be examined next; further test the hypothesis or test a different hypothesis.
For the engineering design process, instead of a question there is a problem or need. Instead of a hypothesis there is a design constraint(s) of what the solution has to be able to do. Experiments are done to determine if the solution meets the design constraint(s), which is similar to testing a hypothesis; in fact a design constraint can be written as a hypothesis. The big difference is that design constraints are quantitative and hypotheses are typically not. Also hypotheses are typically proven or not proven based on statistics and whether something leads to a statistically significant difference. A statistical difference, however, does not mean the difference is significant enough to matter; with hypotheses also not normally quantifying how big a difference is required. Essentially, the difference between the two is clinical significance. In the engineering design process, implicit in the problem is that it is a significant problem. Further, implicit in the design constraint(s) is that meeting it will have a significant impact on the problem. Currently, medical schools have determined one of the most important skills a clinician should have is the ability to apply math and science to physiological systems (to clinical medicine once they graduate); which is the definition of bioengineering. If asked, it would be an understanding of the scientific method (as well as math and science) in order to choose the best treatment for a given situation through their own interpretation of research studies. The skill they are actually looking for is to be able to use the engineering design process (at least the first few steps) in order to choose a treatment that meets or exceeds the required clinical performance constraints. This leads to the main topic of this paper: Is doing the design process as a team beneficial? ABET the accreditation agency for engineering requires that each approved program prove that the students can go through the design process plus have other skills that includes the ability to work in multidisciplinary teams. Although little guidance is given on what the ‘working in teams’ means or how to assess it, it most likely comes from the environment most likely encountered in the workplace.
A big push in education is working in teams with TBL (team based learning) a popular model [1]. The typical structure, for TBL, is to have reading before class, with an individual test (in class), followed by a group test of the same material (with immediate feedback); with both to assure a good working knowledge of the material. This is followed by one or more open-ended questions that are discussed and answered (usually multiple choice) within each group and then there is discussion between groups with emphasis on understanding and/or resolving differences of opinions. This approach does many things well including: making students more responsible for their own learning; with more frequent incentives than the normal 2-4 tests per term. It also encourages discussion within groups and between groups to understand the correct answer (first two tests) or possible answers (the third test). Further, it assures that everyone in the group knows answers to factual questions and have multiple examples where the factual knowledge is applied; with rationale on why some choices are better than others. In addition, it helps students to hone their ‘working in teams’ skill. There are some drawbacks, however, even if the TBL is done properly. Although the majority of classes can use this strategy at least in some parts, if the requirements of TBL are not strictly adhered to, many of the benefits are not realized. Also it purports to assure that everyone in the group learns and are assessed based on their own achievements. This is true of the first two factual tests, but not necessarily the applied part. I have added a second applied individual test at times to really assess individual learning within the group and have used these individual grades as part of the group grade to motivate the group to make sure everyone learned how to apply the information. The system works best also when the first two factual tests have only one correct answer and the applied questions only have a few possible answers, which are already known by the instructor. It is therefore not really designed to handle open ended problems such as in the design process or in essence to use the design and problem solving skills of engineering to create new knowledge; i.e. to develop (or choose between) better clinical treatments.
The book Quiet [2] gives a nice discussion on why we thought teams were a good idea and why they are used frequently in companies, research groups, and academia. Also why the perceived benefits of teams was misapplied in the workplace and even in the face of mounting contradictory evidence, it has not been changed in most cases [2]. The case in the book Quiet is well researched, but the rationale is oversimplified to make the concepts easier to understand; which however does not take away from the message and is readily admitted in the book [2].
A quick summary of the logic is as follows [2]:
A. The development on the internet, in teams, Wikipedia and Linux (an open source operating system) fostered in the notion of working in teams not only produces an additive effect but also a synergistic effect.
B. Companies moved toward an open-plan that made interactions unavoidable.
C. The problem is that team interactions on the internet are not the same as “face-to-face, politically charged, acoustically noisy interactions in an open-plan office.”
As this became the norm in industry (both on the development and research side) it became important to train students to work in teams to be employable as well as thrive in the “real world”.
The book Quiet [2] is mostly about introverts, which is where the simplifications comes in:
A. There are many examples of how most of the creative and/or inventive people are introverts and they do their best work with long periods of un-interrupted time working alone.
B. Wikipedia and Linux worked because the introverts could work on their part alone and then present it to the group.
C. Face-to-face meetings instead of being a meritocracy; value extrovert qualities such as ‘playing well with others’, making contributions to the group, good social skills, etc.
D. Presented examples showing the relationship between skill level and percent of time practicing alone. One of the most relevant was musicians who spent similar amounts of time honing their craft. The best ones where the ones who spent a higher percentage practicing alone (working on the things that were most challenging for them) vs. in groups.
E. Studies were also presented about brainstorming (which is part of the engineering design process) and developing computer code. In these cases, those teams that had the most individual alone time and/or worked for companies without open-plan offices (or had places to be alone) produced the best quality work in the shortest amount of time.
There also was a discussion on why brainstorming in a group is less effective; similar to why groups in general are less productive [2]. Interestingly, the idea of brainstorming to throw out ideas without critiquing them is supposed to reduce or eliminate anxiety, but it doesn’t really [2]. In brainstorming in a group, the extroverts still tend to take over, only one person can talk at once (sort of like an interruption), and there still is the fear of looking bad in front of others. The author gave the example of basketball teams performing better when no fans were present [2].
In non-brainstorming activities, ‘group-think’ can also takeover; related to not looking bad in front of others In a study, where normally individuals would get all the questions correct, if placed in a group with the majority of the students giving the wrong answer (purposely placed there); three-fourths of the students will give at least one wrong answer [2]. One study further indicated that those who went along with the group had more activity in the perception part of the brain versus the decision making part of the brain [2].
Since we are not likely to get away from groups any time soon and groups do have some advantages, how does all of this relate to the original question? It appears groups are best for agreeing on factual information as well as setting timetables and assessing progress. They should, however, limit the amount of creative work that goes on. There may be no ‘I’ in team, but there is little creativity there either. The team meetings should divide up the work and the individuals then go off and work on their part alone (although collaboration can still be helpful if individuals are working on overlapping parts) and then report back to the group (the group can then make suggestions or ask for clarification, but limit the amount of creativity done as a group).
It gets a little more difficult because bioengineering is by definition multidisciplinary. In a medical device company there might only be one engineer on the team (which actually makes it easier). Getting the initial factual information together to determine the problem and need can be done partly in group meetings, especially with critical stakeholders such as the clinicians. Anything that requires time (literature search, marketing analysis, design constraints, design specifications, etc.) is best broken into parts and divided up; worked on outside of the group; and then brought back to the group.
References
- Michaelsen LK, Davidson N, Major C (2014) Team based learning practices and principles in comparison with cooperative learning and problem based learning. Journal of Excellence in College Teachingol 25(4): 57-84.
- Susan C (2012) Quiet: the Power of Extroverts in a World that Can’t Stop Talking. New York, USA.