Is Working in Teams Necessary to use the Engineering Design Process to Solve Clinical Problems?
Biomedical Engineering, USA
Submission: November 21, 2017; Published: December 11, 2017
*Corresponding author: Dale Feldman, Biomedical Engineering, USA, Email: email@example.com
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.
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 . 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  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 . 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 .
A quick summary of the logic is as follows :
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
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  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 . Interestingly, the idea of brainstorming to throw
out ideas without critiquing them is supposed to reduce or
eliminate anxiety, but it doesn’t really . 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 .
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 . 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 .
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
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.