Anda di halaman 1dari 366

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only.

No part of this book may be reproduced or transmitted without


publisher's prior permission. Violators will be prosecuted.

Designing Engineers: An Introductory Textbook


McCahan, Anderson, Kortschot, Weiss, & Woodhouse

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Designing Engineers: An Introductory


Textbook

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Syed Imam

Copyright 2011 John Wiley & Sons, Inc. All rights reserved. No part of this publication may be reproduced,
stored in a retrieval system or t ransmitted in any form or by any means, electronic, mechanical, photocopying,
recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States
Copyright Act, without either the prior written permission of the Publisher, or authorization through payment
of the appropriate per-copy fee to the Copyright Clearance Center, Inc. 222 Rosewood Drive, Danvers, MA
01923, Web site: www.copyright.com. Requests to the Publisher for permission should be addressed to the
Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030-5774, (201)748-6011,
fax (201)748-6008, Web site: http://www.wiley.com/go/permissions.

To order books or for customer service please,


caii1-800-CALL WILEY (225-5945).
Printed in the United States of America 10 9 8 7 6 5 4 3 2 1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Designing Engineers
An Introductory Textbook
S. M cCahan, P. An derson, M . Kortschot, P. W eiss, and K. W ood house
Welcome to the Engineering Strategies and Practice I textbook for 2011/12: Designing Engineers. This
text is a work in progress. It was motivated by our experience teaching ESP (APS111 and APS112) and
the feedback we received from students about the textbooks we have used for ESP in the past. We have
tried a number of different textbooks for ESP over the years, but none has met our expectations, or our
students' expectation. So we have begun the process of developing a new text that will better support
our students' learning and will match the learning objectives of the many new design courses that are
being developed at engineering schools around the world. This year you will be using a partial
manuscript that better supports the material that is taught in ESP than any textbook currently available.
We will be asking for your feedback on the text to help improve it for future ESP students. The goal is to
have a complete and polished package ready for Fall 2012.
We call Designing Engineers a text rather than a t extbook because it is written to be an on-line
information package rather than a traditional linear book. It will be primarily hyperlinked text with
embedded multi-media elements, such as videos. You will find that there are many static link points
currently in the manuscript: link to xxxxx, and the videos aren't there yet. The bold, italic terms are
not yet linked to their glossary definitions. Some of the chapters and sections that are indicated in the
links w ill be posted with the manuscript text this year, and some are not yet ready. We have posted all
of the material that is necessary for APS111, but you will f ind many of the extra pieces are currently
missing. More text will be posted for ESP II in January. However, if you find that there are crucial pieces
missing, we would like to know. Please email Prof. McCahan if you have any comments or if there is a
piece o f text that is missing that would be particularly helpful.
Good luck with your fi rst year of engineering, and we look forward to working with you in APS111 and
APS112.

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Table of Contents
Fall 2011 APS111 custom text

Part 1- The Engineering Design Process


Chapter 1: Defining the Problem in Engineering Terms
Chapter 2: Generating Solutions for the Design Problem
Chapter 3: Concept Evaluation and Selection
Part 2- Support of the Design Process
Chapter 4: Design for the Environment and Community Considerations
Chapter 5: Critical Thinking
Chapter 6: Communicating in the Engineering Environment
Chapter 7: Working in a Team
Part 3- Cases and Tools
Chapter 8: Case studies
Chapter 9: Creativity Methods
Chapter 10: Decision Making Tools
Chapter 11: Design and Critical Analysis Techniques
Chapter 12: Documenting the Process
Chapter 13: Templates
Chapter 14: Glossary

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Part 1- The Engineering Design Process


Table of Contents for this chapter

1.

Design is an iterative process

2. The Phases of a Project


3. Variation of Design Processes
4.

How engineering design projects are initiated


4.1.

The inventor and entrepreneur

4. 2.

In-house projects

4.3.

Collaborative projects: design consultants, contractors and custom design projects

4.4.

Request for Proposa ls (RFP)

5.

Consulting Companies

6.

Other people in the design process

7.

Communicating throughout the process

Welcome to "Designing Engineers: An Introductory Textbook". This text covers an engineering design
process from developing an understanding of the problem to be solved, through idea generation,
develop ing a detailed design, and implementation. The emphasis is on the first stages of a design
process, in particular defining the project requirements, generating solution ideas, and eva luating the
ideas. You will cover more specifics of the design process and the design of discipline-specific
technologies in your upper year courses. In this text we will discuss some of the common aspects of the
design process across disciplines e.g. the iterative nature of the process, and the need for modeling and
testing. Also, we will compare and contrast the detailed design and implementation phases of the
design process across project types.
[Note: terms that are bold and italicized throughout the text are linked to definitions in the glossary]
There are many types of design. In this text we will be focusing on engineering design, which serves the
essential purpose of engineering: turning science into useable systems. Designing simple things
genera lly does not require any special process, and many people can design simple things without

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

Part l lntroduction- 1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

learning how to design. In fact, we humans ar e very good at finding creative solutions to simple
problems (picture 1).

-. lfl.(

need or idea

Design . . . . .
idea
....
Test

Design
process

Results: a design
and maybe a prototype or model
Picture 1. Na'ive design process. Replace the eli part with example photos, e.g. someone trying to carry a
heavy load

someone creating a wheelbarrow

However, as engineers you will generally be called upon to solve much more complex problems that
require consideration f rom multiple perspectives. The problems engineers are asked to solve often
involve specialized knowledge, regulations or codes, and the result ing technology can have far reaching
consequences including the health and safety of the public. Engineering work often involves finding
solutions that must function well from many different points of view; the design must function well for
the user, it must minimize impact on the envi ronment, it must be easy to construct and maintain. As
the complexity of these problems grows, it becomes increasingly difficult to organize all of the
information, balance the trade-offs successful ly, and still f ind creative effective solutions. As the
complexity grows there is also a need for larger design t eams.
A more formal engineering design process is used to help large teams manage the information that will
be part of complex engineering problems, and to help engineers develop solutions that have the best

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

Part l lntroduction- 2

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

chance of being effective from these many different perspectives. For example, the discipline of
formulating the problem as a full set of requirements gives designers a means for comparing and
prioritizing the different goals of the project. Requirements are a formal description of what is required
of the design. Formulating a complete set of requirements is a way of making sure that as the work
progresses, which may take years for a complex system, nothing essential to the proj ect is forgotten or
missed. Furthermore, engineers as a profession are required to carefully and fully document a project.
To document means to explain what has been done in writing, pictures (i.e. graphical communication
and drawings), and orally (in presentations, conversations, and meetings). The act of documenting the
work also helps engineers develop ideas and clarify their thinking. This documentation, and the work it
describes (the engineer's design work), will be the basis for decisions. People will decide whether to
fund a proj ect or not, whether to implement a design or not, based on the quality of the process that
was used and the credibility of the documentation developed (picture 2).
Picture 2. A photo or cartoon (or several pictures) of engineers communicating. E.g. a group examining
a draw ing, or doing a presentation, or writing.
It may not seem necessary to use a formal process for the relatively easy design problems you w ill be
given in the first few years of engineering school, or even for the more difficult term projects you will do
for your courses in upper years. However, like learning any skill, it is valuable to learn the process in the
context of simpler work so that as the complexity of the problems increases you have developed habits
and learned tools that help you to be successf ul. In this regard learning design is much like learning to
play a musical instrument or some other complex skill which combines thinking and doing. You start
with simpler pieces of music, learn the basic process and techniques, so that you can successfully tackle
increasingly complex works. Techniques for playing that might do for a simple piece of music will not
suffice for faster, more complex pieces later. The same approach applies to engineering problem solving
and design. Being a good engineering designer requires both knowledge and practice.
There is no single universal engineering design process. Design processes vary from discipline to
discipli ne and even from company to company. And design processes are changing as engineering tasks
become more complex and more finely tuned with evolving technologies. However, they all share some
basic similarit ies. In this text we will explain the common elements shared by virtually all strong
engineering design processes. In the upper years of your engineering program you will probably learn
about one or more design processes that are common in your discipline (civil, mechanical, electrical,

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

Part ! Introduction- 3

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

chemical, etc.). These discipline specific processes may use somewhat different terminology than what
we use here, but the basic principles and methods w ill be essentially the same. Learning the basic
techniques f rom this text will allow you to easily understand and adapt to the techniques prevalent in
your engineering field and place of employment.

1. Design is an iterative orocess


One of the essential similarities across all engineering design processes is the iterati11e nature of the
process. Iterative means that we repeat a process over and over, in a loop. Every time we iterate we
come closer to an ideal solution. In the design process iteration is used to enhance our understanding of
the problem we are trying to solve, to improve the proposed design, and to increase the quality and
quantit y of information we generate in the process. Design without iteration (illustrated in picture 1)
may sometimes produce a good design, but more often produces a mediocre result that could be
improved through iteration.

The iterations in the design process always stop before we get to an ideal solution. We could always
come up with a better design if we had more time, or more resources (people, money, space, materials).
And we could always find a better solution in the future, when science knowledge and improved
technology make ideas feasible that are now only fiction. Computers in the 1960's were huge machines
with relatively little computing power by today's standards, but they were not "bad" pieces of
technology designed by poor engineers. They were the best that was possible at the time with the
technology, f unds, time, and other resources available. In order to bring a new piece of technology into
being we must always stop our iterative design process, and move on to actual implementation before

the solution is the best it will ever, or could ever be.


Most of this text is about what goes on in these design process iterations, and how we decide when to
stop. Novice designers may chur n around in a hazy, fuzzy process exploring ideas randomly (picture 3,
top). This may result in a good design someti mes, but it is not time or resource efficient. And the
information that results from this type of process will be incomplete, and not always well organized.
After spending a month on an idea, for example, the novice designer may discover that the idea already
exists, and is patented. Professional design engineers, therefore, use tools and strategies along with
freeform creative and critical thinking to develop designs more efficiently (picture 3, bottom). A more

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

10

Part l lntroduction- 4

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

rigorous process also produces more complete, well organized information. This doesn't diminish the
importance of creativity or innovation; tools and strategies channel this energy and effort to enhance
the quality of the resu lt. Like an artist who is taught how to see light and perspective so they can use
these concepts intentionally (or choose to ignore them intentionally) in their work. The goal of
engineering design education is to teach you to become an intentional designer.

Client's need

get more

' test

info
No
Return t o designing with
a better understanding of

Results:
- better understanding
of the problem
Designs

Do'"m:otoUoo

thepmblem" Review
Check
Critique

Done?

.,

- Ready to move to implementation?


- Discard?
Leave the process with a more complete understanding of t he problem,
and potentially a better solution.

Using effective strategies and tools puts the design process in overdrive: Increasing speed, creativity,
and producing better results. Results from the design process can be measured in terms of quality and
quantit y of information.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011


11

Part ! Introduction- 5

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

think

tools and
strategies

ideas

No
Return to designing with a better
understanding of the problem

'-

Done?

...

- Full requirements
- Designs
- Credible documentation of
process

Review
Check
Critique

- Ready to move to implementation?


- Discard?
Leave the process with more complete requirements, credible documentation of the
process demonstrating quality, and potentially a better design solution.

Picture 3. Using tools and strategies to move from novice engineering design process to a more expert
process.
The formal engineering design process shown in the figure above relies on the use of tools and methods
to develop the results. The results from this process are a full set of requirements; a high quality design,
or set of designs; and clear and complete documentation of the design and of the design process. We
can envision this process as the activity that occurs in a design company (see picture 4). The engineering
design team gets a project to work on. They use investigation methods, creativity techniques, decision
processes, and other tools to develop a set of requirements and design ideas. The team uses the
requirements to test their ideas and choose between them. Then they bring their work to a manager or
a project client to review and critique. As a result of the review they may go back into the project space
to work on the design further, they may stop t he design activit ies and move to the implementation
phase, or they may stop the project altogether. Design requires iterating (looping) through these
activities usually multiple t imes.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

12

Part ! Introduction- 6

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Like levels in a video game, each time the team enters this project space they face new challenges. At
first the challenge is just learning a bout the project, trying to figure out all of the aspects of the problem
they have been asked to solve. As the team gathers more information about the design problem, they
gain an understanding of how to navigate the challenges presented by this particular project. The team
begins to find where the most intense challenges are going to be, and where there are already existing
pieces of technology available that they may be able to use in the solution. The team gathers this
information and organizes it into requirements. They can make use of creativity me thods and other
tools in their design toolbox to develop ideas for potential solutions. Each t ime the team completes a
level they leave the project space equipped w ith a better understanding of the proj ect requirements;
more or improved design ideas; more information about the project as a whole (e.g. new sources of
information, new contacts); and more tools in their toolbox - more experience, skills, and strategies to
use in t he next iteration.
In a video game you know your score at the end of each level, but in a design project the score is more
ambiguous. The measure of your success will come in the form of critiques from managers, client s,
users and others or the economic success of your design. No one has played this particular game
before, each project is unique. The challenges, adventures, and ending are never predictable. In a
single text we cannot provide a step-by-step walkthrough that wil l fit each and every design project and
help you through every challenge. And the controller you are using for this game, your brain, is far more
complex than a simple controller so we cannot teach you to use every action you can perform.
However, we can provide tutorials that will teach you tools and skills. And we can teach you strategies
to try that will help you to be more successf ul and more efficient in your design work. The goal of this
text is to help you walk out of every level with more loot (loot in the design process is information and
ideas) and experience points than you would have gotten using a na'ive approach so you can level up
faster.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

13

Part ! Introduction- 7

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Class room
(Tec hnical Knowledge)

Proj ect M anager's


Office
BoardRoom
Client meetings
Design critiques

Infor mation desk

The Sandbox

Picture 4. The Sandbox: the office space for "Designing Engineers", a fictional engineering design
company.

2. The Phases of a Project


One of the essential differences between na'ive design and expert design is the development of project
requirements. Design problems are open-ended problems that could be solved in many different ways.

In this respect they are different than closed-ended problems that have only one possible, correct
solution [link to problem solving chapter]. The development of project requirements which define the
problem to be solved is crucial in an engineering design process. It is possibly the most important
challenge in the process, and the one that is too often overlooked or treated superficially by novice
designers. To develop the requirements the design team must research and document all of the key
information that will guide and constrain the decisions that they make throughout the proj ect. This
phase of the process involves a lot of information gathering and analysis (i.e. going to the "information
center'' in The Sandbox). The requirements phase results in as complete a description of the problem as
the design team can formulate. These requirements will be used as the criteria for decision making
throughout the process. Your design team will return to the requirements development process

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

14

Part ! Introduction - 8

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

repeatedly throughout a project both to add to the definition of the problem and to remind themselves
of the project goals. The project requirements will be explained further in Chapter 1. Each time your
team makes a major revision to the project requirements you hit an important evaluation checkpoint
where you must decide what direction to go next. This will also be discussed in Chapter 1. The decision
whether to continue with the project, and if you continue what process to follow wil l depend on this
evaluation. Picture 5 shows the typical activity level for the different phases of a design project over
t ime.

Solution Generation

Q/

<:

tlLl

v;
Q/

Time

Picture 5. Typical design activities over t ime.


Once the problem begins to become defined the team will start generating ideas for possible solutions.
These ideas are called conceptual design alternatives. This requires creativity and engineering work
(picture 6). Successfully generating good ideas is not j ust a ta lent, it can be learned and like any ability
the more it is practiced the better you can get at it. Some methods for generating ideas and developing
solutions through engineering methods such as decomposit ion and lateral thinking w ill be discussed in
Chapter 2 (the creativity room in The Sandbox).

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

15

Part ! Introduction- 9

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Picture 6. Cartoon of person "thinking creatively", bubble overhead with interesting ideas floating
around in it. Or photo of an engineering group engaged in idea generation activity.
After generating a range of different possible solutions (conceptual designs) that the design team thinks
might solve the design problem, you need to evaluate these ideas and decide which one (or ones) to
pursue. This is a critical step in t he design process and can be made more effective using decision

making tools. It requires comparing the proposed solutions against all of t he design criteria you
documented in the project requirements. It also requires getting input from a variety of people w ith an
interest in the project, and using engineering tools and models to eva luate the possible solutions. We
will discuss this stage in Chapter 3 (the decision making room in The Sandbox). This step often requires
many it erations as you evaluate ideas, modify them, evaluate them again and continue to refine your
potential design solutions. Repeated reality checks are part of t his iterative process, to make sure that
the concepts you are proposing are actually feasible (picture 7). Generating and evaluating solutions
may expose unanswered quest ions and def icient requirements, and we may have to revisit rooms in The
Sandbox to deal with these. The project requirements, including t he definition of the design problem
and the goals, may be modif ied signif icant ly. If the first design ideas you test fail to meet the
requirements, you may need to return to the idea generation stage to develop more possible solutions.
Each time you iterate you bring an increased level of understanding and expertise to the problem
because of your experience with t he project. This deepens your knowledge base and may allow you t o
conceive of solutions that were not apparent when you first approached the problem.
Picture 7. Picture (cartoon or photo) of someone trying to do something " non-physical". The obvious
one would be trying to fit a big round block into a small square hole.
If the team is able to develop a feasible solution that sufficiently addresses the design problem then the
proj ect may move forward to the detailed design phase. The design may continue to evolve during this
phase as you move toward implementat ion, construction, or production of the f inal design. In this
stage, discussed in Chapter 4, the engineering team will continue to solve problems that arise as the
details of the design are worked out. If successful, the system, process, or product that you have
designed will be launched and ready for operation. However, the engineer's work does not stop there.
Engineers are often involved in the operation of technology, and the issues t hat arise when a technology
is decommissioned (i.e. disposed of). In Chapter 5 we will briefly discuss these "end of life" issues. In

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

16

Part 1 Introduction- 10

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

this chapter we will also look at some of the simi larities and differences in the design processes between
different engineering industries.

3. Variation of Design Processes


While the basic aspects of the general engineering design process described here are similar among the
various engineering disciplines (mechanical, electrical, civi l, chemical, etc.), there are also some
important differences between disciplines. Perhaps the most essential difference is in the types of
things t hat engineers design. Nearly all engineering design projects are multidisciplinary (involving
teams of engineers from various disciplines and people from outside the profession) but we can make
some simplistic generalizations about the types of projects that are most commonly associated with the
different types of engineering.
For example, Civil engineering is most commonly associated with the design and construction of
substantial structures and infrastructure such as water treatment and waste facilit ies, power plants,
buildings, and transportation systems (e.g. bridges, traffic systems, subways, ships, airports), whereas
Mechanica l, Electrical, and Computer engineers are more often associated with product or syst em
design (such as medical equipment or consumer electronics). Computer or Software engineers also
design software or algorithms. Chemical and Materials engineers may also be involved in the design of
products (such as pharmaceuticals or fertilizer, for example), and also the design of processes (e.g.
chemical refining or production) and the design of plants. A "plant" can mean anything from a small
production facility to a huge offshore oil platform . And Industrial engineers design processes, such as
manufacturing process, products, and systems such as information systems (e.g. fina ncial systems,
database systems, web based purchasing systems, etc.). Perhaps the most basic wor d we could use to
describe what engineers design is "technology''; understanding that technology is anything real or
virtual (e.g. a computer program) that does not occur naturally.

So technology includes very simple

products such as paper that were invented centuries ago, to high-tech processes under development
such as quantum encryption. Look at all of the systems and devices used in a modern hospital, and you
will see engineering of every kind in action. In this text you will find the things that engineers design
described variously as systems, plants, products, processes, materials, or technologies because all of
these describe types of things that can result rrom an engineering design process.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011


17

Part 1 Introduction - 11

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

What engineers design

Systems: A system is a set of organized components or elements that operate together as a unit. There
are natural systems, such as the solar system, and engineered systems, such as a subway system or a
communication network. The elements in an engineered system are chosen and arranged to perform a
specified set of functions.

Plants: A plant is a structure, and its internal equipment, that is designed to produce a specified
product. There are manufacturing plants that produce consumer or commercial products and power
plants t hat produce energy products such as electricity and heat. Other common types of plants
include water treatment plants that produce clean water for people, and waste water plants that clean
used water before it goes back into the environment.

Products: A product is a physical o r virtua l thing that is the result of a design process. There are
consumer products, such cell phones, shampoo, and software packages; commercial products such as
oil drilling equipment or supercomputers; energy products such as electricity or natural gas; and digital
products such as network services or on-line financial services. There are also agricultural products such
as corn, beef, or wheat that are the result of a natural process that has been engineered to enhance the
production of a desired product.

Materials: An engineered material is a substance that has been designed. Almost everything you have
is probably made of an engineered material w ith the exception of plants (wood, and natural food),
animals, water (oceans, rivers) and rocks. Engineers design all kinds of gases, liquids and solids including
alloys, ceramics, polymers (e.g. plastics) and combinations of substances. Engineers can also design and
produce some materials that are identical to natural products, such as diamonds or a cloned organism,
or materials that can replace natura l materials to some degree, such as artificial bone or skin.

Processes: A process is the sequence of operations needed to transform material, information, or


energy from one form to another. Processes are designed to transform substances such as ore into
useable forms such as metals. Processes are a lso designed to transform energy from one form such as
gasoline (where the energy is in the chemical bonds) to another form such as kinetic energy. And
engineers design information processes such as search engines. Process design generally involves not

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

18

Part 1 Introduction- 12

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

only the design of the operational steps of information, material or energy transformation, but also
consideration of the t iming and scheduling, logistics, supply chain, and quality control aspects of the
process.

Structures: A structure is an engineered product or system designed to support a load (i.e. counter a
force). Structures include built systems such as bridges or buildings. There are also virtual structures,
such as the structure of a network system, which are designed to support a virtual load, e.g. a large
amount of network traffic.

Technologies: A technology is any product, system, or process that is designed and made by people.

There is considerable overlap between the disciplines. In the design of a basic water treatment plant,
for example, you will find virtually every kind of engineer involved in one way or another (see Picture 8
below). There are electrical and mechanical sensors and software processes to design; chemical
reactions that need to be managed; information systems (i.e. Industrial engineering) that must be
designed so operators can effectively run the plant; unique materials such as f ilters to design; and
hydrology and geology are part of the design (i.e. Mining or Mineral engineering). The whole plant has
to be designed and the construction and commissioning managed (i.e. Civi l engineering).
Picture 8. Schematic of a water treatment system highlighting some of the key engineering elements.
In fact, many engineers find that a single discipline does not really describe their work. An engineer's
expertise is often better described by the industry they are in and the roles they have had (technical
designer, research & development, manufacturing engineer, safety engineer, quality assurance, or
project manager, as j ust a few examples). Your undergraduate degree will give you a good grounding in
one f ield of engineering and get you started in your career. However, your subsequent experience, and
continuing education throughout your career w ill take you into areas well beyond your first discipline
and ultimately define the type of engineer you become.
The differences in design across industries are in the design process itself, as well as the types of
technology systems that result. For example, if a company is asked to design a large water treatment
plant to be located in a big city, the project requirements stage comprises a large part of the design
process and may take years to complete (see picture 9). The proposed system will probably be

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

19

Part 1 Introduction- 13

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

thoroughly modelled and, as a public works project, go through an extensive review by the government
and other concerned organizations. However, there may be little really new technology that gets
developed specifically for this plant, so the concept generation stage may be shortened and consist
mostly of deciding between different configurations for locating the technology subsystems in the plant,
and sizing the components. In contrast, a sma ll product design company may decide to invent a new
product just because they think it will be marketable. The engineers may spend some t ime during the
project requirements stage satisfying themselves that there is no current product on the market that
fills the perceived market niche, and they may do some preliminary patent searches. But the
requirements stage of a project like this is likely to be short. The engineering team will spend much
more t ime on the concept generation step and may use a wide variety of creativity methods to develop
a broad set of design alternatives. This is very different than the design process for the water treatment
plant.

Solution Generation

Solution Gtntration

.,

<Z

"'

0?

..

..

"''!>

>

?:

>

?:

"

";;
.:;
c

I
Time

Time

Picture 9. A comparison of the design activities for a large water treatment plant versus an innovative
consumer product.
As we work our way through the design process in this text we will point out some of the differences so
you can get a feel for how the design process differs from one industry to another. By the end of Part 1
of the text you should have a much better sense of these differences and how the processes in other
fields relate to your discipline.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011


20

Part 1 Introduction - 14

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

4. How engineering design projects are initiated


To understand how engineering design projects come to be, you need to be aware o f the two primary
groups that are typically involved in a design project. One is t he design team which is made up of the
engineers and other relevant individuals who will be tasked with designing the t echnology. The other is
the client which may be an individual, a company, or some other organization. The client is the person
or organization which " commissions" the design; that is they give the task of designing the syst em to the
design team, and t he client typically funds t he process.
The following list describes some common modes for the initiation of a design project. The list is in
order based on the relationship bet ween the engineering design team and the client; f rom projects
where the client and the design team are very closely related or are the same people, to projects where
the client and design team have a distant relationship.

Request for Proposals

Collaborative Projects

In-House Proj ects

Picture 10. Types of projects based on the relationship between the client and t he design team.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

21

Part 1 Introduction- 15

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

4.1. The inventor and entrepreneur

An inventor is an individual, or sometimes a team of people, who acts as both the client and the
designer for a technology. They are people who identify a need for a new technology and they design it
themselves. Some inventors will bring a design through the design process to the point where it can be
patented, or where a working version has been built, and then look for a company to buy out or license
the technology. Others will take a more entrepreneurial route and go into business, marketing their
invention themselves and becoming the head of their own company. The initiation of a design project in
this case requires only a good idea, and lots, and lots of work.

4.2. In-house projects

Companies that specialize in technology development employ "in-house" design teams. These
companies serve both as the client and as the design company. The design team members are
employees of the company. Many of the "name brand" products and services you use are designed
primarily by in-house teams at the company whose name appears on the product or system.

4.3. Collaborative projects: design consultants, contractors and custom design projects

In collaborative projects the client uses an outside engineering design team or company to accomplish
the project. This is often done through a contract between the client and a design company or team.
The client again can be an individual, a company, or another type of organization. They choose the
engineering design company typically because the engineering group has a special expertise in the
relevant field. However, they may have other reasons including having worked with the engineering
team before and having had a good experience. Even clients that are engineering design companies
themselves often choose to contract, or sub-contract, some of their design work out to other
companies.

In large proj ects there may be dozens of design teams f rom many companies working on

the design of a system.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

22

Part 1 Introduction- 16

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

4.4. Request for Proposals (RFP)


A Request for Proposals (RFP) is issued by a client organization which is typically a company, some other
type of organization, or a government agency, but could be an individual person. The RFP will usually
state the purpose of the design project and explain the client's requirements. Anyone, or any company,
can respond to an RFP by submitting a proposal for a design. In this type of project there may be no
existing relationship between the client and t he design company prior to the start of the project. The
RFP will typically state what type of proposal is required; usually the proposal will need to be detailed
enough, including estimates of the cost of the design and estimate of time for completion (this is called
a "bid"), such that the client can make an informed decision about which proposal to choose. The
engineering design team, or company, does not get paid for submitting a proposal. They will only be
paid for their work if their proposal is accepted and a contract drawn up between the client and the
engineering company.
The RFP method is used when the client wants to get a variety of proposals so they have a wide range of
designs to choose from. Or, as is the case in most government work, the client is not allowed to
preferentially choose an engineering company or group based on a prior relationship or other factors.
An honest RFP system allows all engineering companies a fair chance at getting the contract.

5. Consulting Companies
One type of engineering company that works exclusively through collaborative proj ects, or RFP's, is an
engineering consulting company. A consulting company usually takes on numerous projects for a wide
variety of clients. They do not necessarily get involved in the full design process, or in the full
implementation of the design. They are contracted to provide a specific outcome or set of deliverables.
A deliv.erable is a piece of documentation or other result from the design process (e.g. a set of drawings,
a working model of the design, a report, a cost estimate, a set of operating instructions, or construction
of one part of the project, for example).
The role of a consulting company is similar to that of a contractor. A client may decide to split up a
project and contract out the work separately ifor each stage of the design and implementation of the
project. Often this is done to take advantage of the different areas of expertise offered by different
engineering design companies. For example, if Engineering Company 1 is designing a building for a

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

23

Part !Introduction- 17

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

client they may have one of their in-house teams do the structural design. However, they may subcontract the design of the elevators to a company, Engineering Company 2, that specializes in this type
of work. In this case Engineering Company 1 now plays the role of client for the design of the elevator
systems. Company 1 may also sub-contract out the design of the heating and air conditioning systems,
the design of the electrical and lighting systems, and the design of some of the other specific
components of the building. Complex engineering design projects may involve many different
engineering companies who act as contractors and sub-contractors and who all have to work together
collaboratively.
In addition, there will be other professionals involved in the design process. Engineering Company 1
may be an architectural firm (i.e. a group of ar chitects), for example, that employees an in-house
structural engineering group. In virtually every engineering design project of any magnitude there will
be many different types of people involved in the design process. Some may work for the same
company as the design team, and some may be contracted to work on a particular project.

6. Other people in the design process


In addition to the design team and the client, there are other groups of people that will be impacted by
the design process and who are often involved in it. First, there are the user group and the operators.
The users may be the operators (such as a person using and operating a laptop computer) or they may
be different groups, for example the users of clean water are a different group of people from the
operators of the water treatment plant. There are also other "stakeholders" in the design process.
Stakeholders are people or organizations who have an interest in the outcome of the design process.
Stakeholders may include members of the public, government agencies, companies, and other
organizations (which are called "non-governmental organizations" or NGO's). We w ill discuss
stakeholder involvement in the design process more in chapter 1.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

24

Part 1 Introduction- 18

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

7. Communicating throughout the process

The engineering design process is essentially an information process


A naTve design process produces only a few design ideas and little information (see Picture 1). Expert
designers produce many ideas and ext ensive information while they are designing. The value t hat is
produced is not j ust t he end result , the design, it is all of the information that is created, gathered, and
organized in t he process. It includes documentation of all the important decisions t hat are made. For
the engineer, the expert process results in information that enables significant learning and experience
that can you take wit h you to your next proj ect.
The en,gineering design process is essentially an information process. In the course o f a design project
you gather, organize and manage information; you create ideas, examine them critically, make decisions
and formulate all of t his int o information which needs to be shared, t ransferred, and ultimately applied
to implement your design. To be useful all of this infor mation has be put in a form that can be
understood and applied accurately both by yourself and others. It has to be communicated t hrough
documentation.

The documentation of the design process can take many forms: written, graphical (drawings, pictures),
and oral (presentations). It is an essential part of the design process and the documentation generally
forms the bulk of the results (Picture 11). This type of writing is quite different t han t he essays, text
messages, or other types of writing you may be used to. Engineers are required to write reports,
memos, instructions, and so on. It requires a very clear, precise, and concise style (see example below).
The pu rpose of the documentation, which must be honest and transparent, is to communicate
information in a way that is both credible and unambiguous. The quality of the documentation will
often determine whether a design project is successf ul or not. Certainly, in proposals (as in the RFP
process) and other key points of evaluation, the documentation will determine if a design is
implemented or if it is discarded. Throughout the text there will be links to the Documenting the
Process section to assist you with this part of the work. [link to Documenting the Process section]

Picture 11. Picture depicting some of the types of documentation

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

25

Part 1 Introduction- 19

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Example of how common instructions differ from engineering instructions


How you might ask a friend: "Could you pick me up a coffee?"
How an engineer might more formally specify the request:

1.

Could you go to the coffee shop at the south east corner of College Street and St. George Street,
Toronto, Canada

2.

Go to the service counter

3.

Request a medium size dark roast coffee

4.

Pay the cashier

5.

Go to the condiments counter and add 2 cc of whole milk and 1 gm of sugar

6.

Select correct size lid and snap lid into place

7.

Deliver coffee to me in 10 minutes or less from time of purchase with less than lee of spillage in
transit.

8.

Delivery location: Bahen building, 44 St. George Street, room 1007.

All values

10% unless otherwise specified.

This may seem like it overly complicates the instructions. However, the probability that you will get
your coffee exactly the way you want it (hot, with the right amount of milk and sugar) is drastically
improved by this type of communication style. With a cup of coffee this may not matter, but if you are
writing instructions for assembling a control system for an aircraft... it matters!

Communicating with yourself may seem easy and obvious. But when a design proj ect goes on for
months or years and involves thousands or mi llions of pieces of information, it is easy to forget facts and
ideas or remember them incorrectly (Picture 12). Documenting and organizing your work as you go is an
essential information management skill in this process. It can save you from redoing work that has
already been done, and keeps you from heading off in the w rong direction. The common method for
keeping track of design work is an engineering notebook. Your notebook is used like a journal to record
your work as it progresses. More information on keeping a good, effective notebook can be found in

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

26

Part 1 Introduction- 20

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

the Engineering Notebook section. link to Engineering Notebook section of the Documenting the

Process Starting an engineering notebook is the first step to beginning a new design project.
Picture 12. Cartoon of someone overwhelmed with disorganized information (lots of piles of papers,
etc.) And someone who has a nice neat set of notebooks, and f iles.

,..

{.;.1

_ __, e "''"''1\e< .-}

'

-.,

{:IF h

.:It ,

l::'c

-(.

1_

L.;;

z .....:.

""

,.

"> (

'-1

e.
I

"

!'-

,.
t.

')

tf

..

Picture 13. Example page f rom an engineering notebook [courtesy of M. Chang, University of Toronto] .

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

27

Part 1 Introduction - 21

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Learning Objectives for this section


By the end of this introduction, you should be able to:
Explain why, and in what ways, the engineering design process is an information process.
Describe the purpose of and the basic elements in an engineering design process.
Explain the concept of iteration and its purpose in the engineering design process.
Explain some of the differences between engineering f ields and some basic differences in
engineering design processes.
Explain the role of the client in the design process and the relationship between the client and
the engineering design team in different types of projects.
Identify several ways that a design project can be initiated and compare and contrast the
characteristics of these routes.
Describe the basic purpose and qualities of documentation in the engineering design process.

List of Key Terms


The key terms will be listed at the end of each chapter. Definitions for many of these terms can be
found i n the Glossary.
Discipli ne

Engineering design process

Requirements

To document

Documentation

Iterative

Creativity methods

Open-ended problems

Closed-ended problems

Conceptual design alternatives

Decision making tools

Plant

Reality check

System

Technology

Process

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

28

Part 1 Introduction - 22

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Product

Structure

Material

Client

Research & Development (R&D)

In-house

Request for Proposals (RFP)

Consulting company

Deliverables

Stakeholder

Non-governmental organization (NGO)

Users

Engineering notebook

Operators

List of pictures
(Note; for the pictures below that are (or could be) photos, any could be replaced w ith a short video clip
in the digital text, i.e. click on the photo and get a 10-30 second video clip)

1. The na'ive designer. Person putting a wheel on a wheelbarrow, or "inventing" some other
simple solution to a problem. Could be a cartoon or a photo
2. A photo or cartoon (or several pictures) of engineers communicating. E.g. a group examining a
drawing, or doing a presentation, or writing (I would really like to see a young engineer in a
"cool" setting, working on a piece of writing).
3.

Moving from novice design process to expert, intentional design process

4. The Sandbox: a fictional design company that illustrates the various activities that may take
place during an engineering design process.
5. The phases of design activities with time
6. Cartoon of person "thinking creatively", bubble overhead with weird ideas floating around in it.
Or photo of an engineering group engaged in idea generation activity. But try to make the
picture not specifically "mechanical product" oriented.
7.

Picture (cartoon or photo) of someone trying to do something "non-physical". The obvious one
would be trying to fit a big round block into a small square hole.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

29

Part 1 Introduction - 23

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

8.

Cartoon of a simple water treatment plant that highlights some of the key engineering systems,
e.g. sensors; control room; fluid flow systems; structure; machines and equipment; filtration
systems.

9.

A comparison of the design activities for a large water treatment plant versus an innovative
consumer product.

10. Diagram of relationship bet ween the design team and the client for different project types.
11. Picture depicting some of the types of documentation, maybe a cartoon or a photo of a person
with drawings, a report, etc.
12. Cartoon of someone overwhelmed with disorganized information (lot s of piles of papers, etc.)
And someone who has a nice neat set of notebooks, and files.
13. Example of a page from an engineering notebook.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

30

Part 1 Introduction - 24

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Chapter 1: Defining the Problem in Engineering Terms


Table of Contents for this chapter

1.1.
1.2.
1.3.

1.4.

1.5.
1.6.

1.7.

1.1.

Starting the Process- Overview


The Problem Statement
Developing the Requirements
1.3.1.
Functions
1.3.2.
Objectives
1.3.3.
Constraints
1.3.4.
Summary: requirements
Documenting the Proj ect Context
1.4.1.
Service Environment
1.4.2.
Users, Operators, and Client
Stakeholders
1.4.3.
1.4.4.
DFX considerations
Other considerations for defining the project: Marketing
1.4.5.
Design competitions and other types of engineering school proj ects
Reflecting on the Design Problem
1.6.1.
Characteristics of Good Requirements
1.<6.1.
Project scope
Evaluating the problem
1.6.2.
Conclusion
1.7.1.
Leaving this stage of the process you should have:

Starting the Process- Overview

People often solve the wrong design problem . When faced with a simple math or technical problem it is
easy to know what is being asked, and the kind of solution that is required. However, design is different.
Even simple design problems can involve multiple competing obj ectives (e.g. light weight, fast and low
cost). For every one product or technology that is successful there are dozens t hat never make it. Often
this is because the designers created a solution that did not f it the problem, or a solution for a problem
that doesn't exist at all.
Picture 1. A cartoon of an inventor with an interesting but totally useless device, e.g. a bicycle helmet
for a cat.

"The Gadget Failure Hall of Fame" by David Pogue, Scientific American, June 21, 2011:
http://www .scientifica merica n.com/ article .cfm'? id=pogue-t he-gadget-failure-hall-of -fame

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

31

1-1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

" Why Gadgets Flop", by David Pogue, Scientific American, June 21, 2011:
http://www.scientificamerica n.com/article .cfm? id=why-gadgets-flop

To be a successful design engineer it is essential that you understand the problem you are solving. In
this text we will call the documentation of the design problem the problem statement and project

requirements, however this information goes by other names in industry (see Table 1). The
requirements are one of the most important sets of information developed during the design process.
The requirements are a complete and organized documentation of the design problem and should be
updated at regular intervals during the design process. In some projects the requirements will form the
basis of the contract between your team (or company) and the client. In all cases they should describe
what the client can expect, and not expect, from your design.
In this chapter we introduce techniques for researching a problem and we take you through the process
of developing a full set of requirements. This process is beneficial not only for professional designers,
but you can use these methods for many of the projects you will work on during your undergraduate
program.
This chapter will be organized into four sections:
1.

The problem statement: A restatement of the design problem in terms of the need.

2.

Developing the requirements: Defining the design problem in engineering terms.

3.

Documenting the project context: Viewing the problem from multiple perspectives to more
fully define the design problem . Documentation of the context will generate additional
requirements.

4.

Reflecting on the design problem: Critically reviewing the requirements.

Table l!.. What the documentation of the design problem is called depends on the field. This material, or
parts of the material, are ca lled different things in different industries and sometimes different things in
different companies in the same industry. This table gives a few examples. Whatever it is called, this
information serves the essential purpose of describing the design problem that is to be solved.
Industry

Documentation of the design problem

Institutional building design

User specifications

Pharmaceutical industry

Discovery and screening

Software design

Requirements

U.S. Defense

Specifications

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

32

1-2

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Aerospace

System Requirements

Chem ical engineering

Seeping documentation

1.2.

The Problem Statement

Gathering the information you need to understand a design problem starts by researching existing
information. This type of research includes reading (both on-line and in print), but also will probably
require listening, testing, and observing link to information gathering. The goal of the research is
building your own information base. You will need to learn what the client wants; what the users need;
and the technical facts, concepts, and methods that will be important in this design project. A good
design team uses a wide variety of research methods, learns quickly and teaches each other, and they
become project experts. Good designers are good learners.
A design project often starts with a statement from a client, sometimes called a design brief. In some
cases a design team may seek out a problem to solve, but more often the team is given a problem to
solve by a client or their own company (i.e. an in-house project). As an engineering student, this design
brief will often come from your instructor in t he form of project instructions. The design brief may be
short, only a paragraph or two, and vague. Or it may be very long. Some requests for proposal (RFP's)
are thousands of pages long and can be confusing or contain conflicting information. If you are very
lucky you will get a clear and complete client statement, but you still have to work through it to
understand the problem. One of the first steps in the research process is digesting and investigating the
design brief (i.e. the client statement).
Digesti ng the client statement means making sure that your team understands the client's goals. When
dissecting a client statement you are trying to figure out what the client needs. Sometimes clients will
state what they want, not what they need. This is called a solution driven statement. The statement
tells you what the client thinks is the right solution. Part of your job is to analyze the statement to
uncover what the need is, and decide if the solution the client has stated is really the right way to go.
The engineer's job is to create a solution independent statement that preserves only the essential
characterist ics of the design problem and removes any unnecessary solution driven information. A
solution independent statement of the client' s need is called a problem statement.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

33

1-3

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

A want versus a need

Client: "I want a bag that attaches to my wheelchair so I can carry groceries home from the store
easily."
The engineer's job is to analyze this statement. The client statement can be broken into parts:

self

Picture 2. Example of separating out every part of a client statement for analysis.
Which part of the statement is the real need here? Does the client only want to get the groceries home,
or do t hey want to be able to carry other things? Do they want something they can operate alone, or
would it be acceptable to be dependent on others for help? Is the rea l need here a secure attachment
that can be used by the client, but will not allow theft? And how much volume and weight is the client
thinking they need to transport? Does it need to protect the things being carried from rain, heat, dust,
vibration and other environmental factors? The engineer needs to begin to investigate the statement
further to discover the need.
Engineer: "So what I am hearing is that you need a means for securely attaching things to your

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

34

1-4

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

wheelchai r. Is this correct? Or do you need a way to get your groceries home?"
Note: the client statement limits the solution to a narrow range of design ideas. The engineer's
questions open up the range of possible solutions while sti ll maintaining the essential function that
meets the client's need.
But what if the client really does want a bag for groceries and will not be happy with any other solution?
Then the engineering team needs to investigate this further with the client, if possible, to understand
the issues better. It is appropriate for the engineer to ask the client what it is about a bag that makes it
the solution of choice, and what features would this bag have beyond just attaching to the wheelchair.
The engineer might also tell the client about some other ideas (a delivery service, or a mini-trailer that
attaches to the wheelchair) to see if the client responds positively to other ideas, or what their
objections are. The engineer might observe the client shopping to measure the weight and size of a
typica l load of groceries. Part of an engineer's job is working with the client to explore alternatives and
investigate the problem to better understand the client and their needs. Note that after this process if
the engineering team does end up designing a bag, then they will be able to provide detailed
information about why they made this decision and why this is the design that best fits the needs of the
client.

In addition to implicit solutions, client statements may contain assumptions, conflicting information, or
even errors. It is important that you investigate the essential facts to conf irm what is presented in the
client statement. This may include repeating some of the measurements if data is given or doing
research on-line or in the library to confirm t he facts link to information gathering. In the case of
conflicting information it is appropriate to discuss the issue with the client so you are basing your design
on the correct set of information.
Examples:
I want a hole drilled

implicit solution. The hole is needed; drilling is a method (i.e. a means)

I want a motor and the cooling fluid should drain out the bottom

assumption - not all motors

require cooling fluid.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

35

1 -5

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

It must hold 100,000 ping pong balls and fit into a subcompact automobile trunk 7 conflicting
information
The camera must weigh no more than 2mg 7 likely a typo; the author meant 2g maybe?

Client
Statement

Problem

Project

Statement

Requirements

Infor mation
Gathering

Critical
Thinking

Figure 3. Moving from a client Statement to Project Requirements


By the t ime you are done researching the client statement you should understand the statement well
enough to be able to restate the problem in your own words. This is called a problem statement; see
Figure 3. The problem statement states what is missing or lacking in the world. It describes the gap or
hole in the current reality that is motivating this project, i.e. what the need is. The design solution will
fill this hole.
Your statement of the problem, at this stage in the process, will be incomplete. It might even be wrong
in some respects. This is because the client statement represents only one perspective on the problem.
The client statement has important information, but it is only a starting point. You will need to do more
research to continue to evolve a more accurate and complete understanding of all aspects of the design
problem. Your problem statement should evolve through the process as well; you may come back to
revise the problem statement even after your client has examined some first design ideas you put
forward. The problem statement is the first part of a complete set of requirements. It basically serves
as the introduction to and motivation for the project requirements.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

36

1-6

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

1.3.

Developing the Requirements

Developing a clear set of requirements w ill help keep your design project manageable. Design projects
are indeterminate (ill-structured, or ill-posed by nature) which means that design problems are
inherently complex. They have many possible solutions. They often involve ambiguous or unknowable
information. For example, what exactly do plant operators think about when sitting in the control room
of the plant? How exactly will they interpret the information displayed on the screens around them?
You could spend enormous amounts of time trying to get accurate information about every aspect of a
design project, and still not be able to get exact information about everything you might want to know
for the project. And designs must balance competing needs. For example, the needs of the plant
operators, the needs of the public who live near the plant, and the needs of the plant owners. For these
reasons design projects can easily get out of control. They can become infinite time sinks, and the
features that the client asks for as the project progresses can change and grow uncontrollably. Your
documentation of the project requirements will evolve with the project, and your understanding of the
problem. However, having a clear, organized set of requirements for your team to use, and to share
with your client at each phase of the project is going to help keep the whole project under control and
prevent you from becoming overwhelmed. Your team may never have all of the information you would
want to get before designing a solution, but at least the information you have w ill be organized, and as
complete as reasonably possible.

Picture 4. Engineer in a disorganized work space looking aimless, and an engineering team in an
organized work space looking focused.

The engineering design process is essentially an information process


Developing and documenting a clear set of project requirements is part of the work you do for your
client. This makes it part of the design. A professional engineering design is not just the thing you
create, it is all of the information and documentation that backs up the process you follow and the thing
you design. The requirements, and other documentation, are sometimes as valuable to the client as the

design itself.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

37

1 -7

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

For engineering projects you do in school, the documentation may be an important part of the work that
is graded. Your instructor is probably looking not just for a functioning design, but clear documentation
of the thinking process you used, and decisions that were made to arrive at the design. The quality of
the thinking process, methods you employed, and documentation of this process may be important for
your grade.
The project requirements can most easily be developed and managed by identifying categories of
information that are necessary to define a design problem. In many industrial proj ects the requirements
are complex and not neatly categorized. Or the headings in the requirements section are specified by
the contract with the client or convention in a particular industry. Generally the requirements can be
characterized as: functions, objectives, and constraints (1]. There will be overlap between these
categor ies, and some important information may not neatly fit into any one of them . However, this
structure wi ll help you to organize the information and use it effectively in the design process and can
help reveal major critical gaps in your understanding of the problem.
We will start by discussing some general strategies for developing the basic requirements. In addition to
these basic requirements, the definition of t he design project will necessitate examining the design
problem from multiple perspectives because the context in which the design will operate is important.
Examining the problem from these perspectives will result in additional functions, objectives and
constraints.

Problem
Stat ement

Critical
Thinking
& Research

Functions
Objectives
Const raints

Corntext for
the design

Figure 5. The requirements are developed based on the problem statement; the documentation of the
context in w hich the design will operate; and critical thinking and research by the design team.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

38

1 -8

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Research
Research involves both investigation of existing knowledge and the development of new knowledge. At
this stage of the design process most of the research your team will do is investigating existing
knowledge: finding written material, talking to people and listening, and learning what you can about
the project. You may also need to go to visit the site where the project will be installed (this is called a
site visit), and take some preliminary measurements to help you understand the project.
Later in the project you will develop new knowledge: build models and prototypes to test; develop test
methodologies; and collect and interpret data. Both of these research types are necessary in the design
process, but they generally happen at different stages in the process.

1.3.1. Functions
Definition: Functions are what the technology must do.
Basically any idea that meets the functional requirements could conceivably be a possible design
solution for the problem. So it is important to explain all of the functions that the technology must f ulfill
in order to minimally be considered a possible solution. See Picture 6.
A f unction is a statement of exactly what the design must do. Suppose a team of chemical engineers is
designi ng a new type of glue intended to be used for plastic parts, e.g. plexiglass. The function of this
product is to hold two or more parts together. How well the glue should perform this task will be
described as an objective, not a function. Note that the statement of the function "to hold two or more
parts together" is solution independent. It does not overly constrain (unnecessarily reduce) the set of
possible solutions that could be considered, but only rules out solutions that will in no way meet the
basic functional requirement. If the team includes this statement in the requirements then they are
ruling out solutions such as vegetable oil, talc powder, air, aluminum foil, and a wide variety of other
substances (and other technologies) that do not meet this basic functional requirement.
This is exactly what a statement of a function should do. It should draw a boundary around the set of all
possible solutions, and exclude ideas that do not function in a way that meets the needs of the design.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

39

1 -9

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Through discussion with the client, or within the design team, the engineers would have to decide
whether the requirements would explicitly include or exclude other types of fastening agents (e.g.
mechanical fasteners such as screws).

All possible ideas in t he


universe

Subset of ideas that do


what the design must do
to meet the needs of t he
user and client

Picture Ga. Functions draw the boundary between all possible ideas in the universe, and subset of ideas
that meet the minimum functional requirements of what the design must do to address the need.

A power drill

, '

AI foil

'<)0

Existing
glues

-,.0<:'<..:::;

Dried egg yolk

New ideas that

Talc powder

Vegetable oil

New ideas that do


not funct ion as glue

Any substance that


sticks to p lastic

A computer
chip

Double

A rock

Helium gas

A bicycle
A chair

Picture 6b. Example, the functional boundary between all possible ideas in the universe and the subset
of ideas that could, minimally, meet the functional requirements for a new type of glue for plastic
pieces. Some of the ideas in the function boundary (e.g. dried egg yolk) may be very bad ideas because
they are poor at gluing things together, but they minimally meet the functional requi rements. The
functions statements must describe the boundary, not the ideas contained inside or outside the
boundary.
In developing the requirements you are not yet trying to list or describe the ideas inside or outside the
function boundary. You are trying to describe the boundary itself: trying to describe the design

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

40

1 - 10

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

problem. Remember in your functions list to remove any mention of possible solutions, and just focus
on the definition of the problem you are being asked to solve. If you do think of a possible solution (and
you probably will) then t hink about the characteristics that make it a possible solution and write those
characteristics down as requirements.
An important aspect of developing the requirements is documenting the obvious. Let's consider
another example. Suppose a team is designing a new bicycle security system (i.e. a bike lock). At a
minimum
A bike lock must secure a bicycle.
However, we can break this primary function down into sub-functions, sometimes called secondary

functions, which describe what the design must do to enable the primary function.
The design must lock
And
The design must unlock.
This may seem obvious, but a bike lock that locks but won't unlock is an unacceptable solution. Also if
the design team neglects to take into account the work the user must do to unlock the bicycle they may
end up with a design that is awkward and difficult to use. You need to think through the user's need
step by step so you make sure you are intentionally considering each functional element in your design.
This process is called functional decomposition link to Creativity Tools and can be indicated
through use cases or task analysis link to Design and Critical Analysis Techniques and Human Factors
chapter.
Developing the requirements is a learning process, and intentionally considering every aspect of the
functionality of the design teaches you more about the problem you are working on. In thinking through
the bicycle lock example there are actually many secondary functions to consider. For instance, the
design requires user input in the form of information: when to lock the bike, when to unlock the bike,
where to lock the bike, who is allowed access to the bike. Therefore the lock must al low the user to
input this information. This may seem like way too much thinking for a simple bike lock, but considering
all of these aspects of the problem allows the design engineer to consider the design from a much more

creative perspective.

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

41

1 11

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Picture 7. A keyless bike lock. A person pointing a remote control at a bike locked to a bike stand or
using their cell phone to unlock the bike.

Functions and Means


The statement of a function, or any requirement, must be solution independent. That is, the statement
must not imply a specific solution because the requirements should define the problem not the answer.
A specific solution idea, or a means of solving the design problem, is called a means statement. Means
can also refer to the means of implementing a solution. So in the above example, the function is that
the bike lock must lock and unlock, or secure t he bicycle and release the bicycle. Using a key/lock
system for this purpose would be a means. So any mention of a key, or a physical lock, does not belong
in the requirements for this design problem.

Methods for generating functions


A variety of methods for generating functions are explained in the Creativity Tools section link to
creativity tools. Each entry in the Creativity Tools section will explain a method, what it can be used
for, (e.g. generating functions or generating solutions), and its advantages and disadvantages. There are
also examples given to help you understand how to apply each method. It is recommended that you try
using at least two or more of these methods to generate a robust list of functions, and to get some
practice using different techniques. Methods such as brainstorming and the black box method are often
used. Function/means trees, use cases and task analysis can also be employed to assist in the
generation of functions, helping you to understand the various human and non-hum an interactions with
the design. link to Design and Critical Analysis Techniques

Example: developing the functions for a bicycle lock system link to creativity methods.
Black box method: In this method you describe all of the mass, energy and information that is going into
the proposed design without actually describi ng the design itself. Then you describe all of the mass,
energy and information that you expect to result f rom the operation of the technology you are

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

42

1 - 12

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

designi ng. For a bicycle security system the inputs are the bicycle (secured or unsecured), and
information about when and where to lock the bicycle. There is also information about who is allowed
to lock or unlock the bicycle. There may also be energy input. We assume here that mechanical energy
provided by the user is available, and possibly electricity. The outputs are developed in the same why.
Note that energy is a likely output because any energy input has to either be stored or exit the system
(conservation of energy principle).

In put s

Outputs

M ass

M ass

bicycle secured
bicycle unsecured

bicycle secured
bicycle unsecured

Energy available
mechanical

Energy output
..,.

Design

resulting from input

elect rical (maybe)

Information
Information
when to lock
when to unlock
who can unlock

indication that bike is secured


indication that bike is unsecured

where to lock
This type of diagram suggests functions of the design; it helps you discover what expectations you have
for the functionality. In this example, we discover that we expect the bike lock will provide the user with
a clear indication of when the bike is secured and when it is unsecured. The means for doing this is not
specified; the lock cou ld indicate this information through visual, auditory, tactile, or other sensory
input. The lock could even send a text message to your phone telling you it is locked. Developing ideas
for this functionality will be part of the solution generation process. For the requirements we would
simply state:
The design will produce a secured bicycle
The design will produce a released bicycle
The design w ill indicate when the bicycle is secured and when it is unsecured

Additional pieces of information that are gleaned from this diagram will help us develop other
requirements notably objectives and constraints, e.g.
Objective: The design should allow the user to secure the bicycle in a wide range of locations.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

43

1 - 13

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Constraint: The design must only use available energy as input if it uses energy at all

Example: Aerial photography case study link to case studies

1.3.2. Objectives
Definition: Objectives are what the design solution should be.
Objectives are used to judge how well an idea solves the design problem. They are the evaluation

criteria. Some designers call objectives "measures of effectiveness" to emphasize this evaluative aspect
of objectives. Unlike closed-ended problems that have one, unique exact solution, design problems are
open-ended. Solutions to design problems are judged "better" if they do a better job at solving the
design problem, or "worse" if they do a poor job at solving the design problem. Another way of saying
this is that the quality of the design solution w ill be evaluated based on the criteria as documented in
the requirements: Does the solution perform the necessary functions and to what degree does it meet
the obj ectives? The objectives are the criteria that are used to make this judgement.
In the last section we said that the definition of the f unctions was the definition of a boundary that
separates functionally appropriate solutions from non-functional solutions. In this analogy the
objectives describe the landscape inside the f unctional boundary. The landscape has hills and valleys.
When you begin generating solutions for the p roblem and evaluating them, you will use this "landscape"
to judge whether a solution is near the top of a hill (meets the objectives for the design) or at the
bottom of a valley (is a poor solution because it does not meet the objectives for the design).

Picture 8. An island (labelled The Island of Functionally Acceptable Solutions) with hills and valleys and
the engineering team is surveying the island (i.e. mapping it) and naming the hills. Hill tops are labelled
with adjectives typically found in objectives such as strong, light, fast, or inexpensive. Valleys are
labelled with antonyms: weak, slow, expensiv e, etc. Design solutions are animals roaming around the
island.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

44

1 - 14

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Table 2. Some examples of obj ectives (more can be found in the case studies)
Design brief :

A few examples of objectives

Lipstick: design a new type of lip


t inting product

Long-lasting
Available in a wide variety of colors
Aesthetically pleasing
Won't come off on a glass, clothing, or another person
Won't chemically react with food or drinks

Building structure: design the support


structure for a new building with a
unique shape

Inexpensive
Durable
Stable
Enhances architectural design (or at least doesn't impair it)

Course selection system: on-line


system that allows university students
to register for their courses

Reliable
Easy to use
Easy access to information about the courses; such as
course content and scheduling

A few notes about these examples:

1. These are partial examples; the actual list of objectives could be much longer.
2.

Safety, and other crit ical aspects of the design problem, are not included here. Critical factors,
such as safety, will be listed in the constraints section of the requirements.

3.

Some of the examples (e.g. " reliable", "easy to use", "stable" ) are very general and could apply
to many different design problems. You will need to add more specific obj ectives that explain
what "easy to use" means for the specific design problem you are working on, and how it could
be evaluated (measured).

It is useful to set goals for the obj ectives. An objective goal is the minimum target level for an
objective. Obj ective goals often inherently give measurement methods for evaluating the obj ective. So
in the case of " Easy access to information" the measurement method could be the number of mouse
clicks to get to the content.
Table 3: A few example of objective goals

Objective

Example of a possible goal

A wide variety of colors

Goal: at least 10 colors

Inexpensive

Goal: less than $10 million dollars

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

45

1 - 15

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Easy access to information about the


courses

Goal: no more than two mouse clicks to the course content or


scheduling information from any point in the registration
process.

The full requirements will be given to the client to check over. The objective goals help the client assess
whether you are proposing to design a system that meets their needs, or whether your understanding of
the design problem is very different from their expectations. For example, suppose you are designing
the new type of lipstick and you set the goal for "wide variety of colors" at "<!:10" . The client may come
back to you and say "No, we were expecting more like a hundred different colors. You are off by an
order of magnitude on this." That information is really important to know because it may later cause
you to rule in or rule out some of the possible solutions that you devise for this problem.
However, objective goals are not absolute constraints. Suppose you develop an excellent lipstick
product that (for some strange reason) can only be manufactured in 95 different colors. The objective
goal you have listed in your revised list (e.g. "producible in at least 100 colors") wou ld not cause you to
throw out this design solution, even though it fa lls a little short of the goal. It would just motivate your
design team to strive for a product that is as good in every other respect and is producible in even more
colors. Or you might, in consultation with your client, settle for only 95 colors if the other attributes of
the lipstick product were really great. Objective goals are meant to motivate the improvement of the
design toward a higher peak in the landscape; set an approximate threshold for acceptable levels of
performance or characteristics of the design solution. They are not constraints.

Methods for generating and managing objectives:


Many of the creative processes listed in the Creativity Tools section can be used to generate a list of
objectives link to creativity tools. Examination of the design brief and team brainstorming are often
used to generate an initial list of objectives.
The most common method used to generate specific objectives and manage the list of objectives is an
objective tree. The picture below shows an example of a page from an engineer's notebook for the

aerial photography case study {link to case study).

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

46

1 - 16

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

OB}t:Cil\J E
!tEE

Qecvull''e-

0'<r

Use

l"'\i(livvtcJ.,

cwnowtb o+
Ia.

Picture 9. Picture of the page an engineering notebook showing an objective tree for the aerial
photography project. [courtesy of M. Chang, University of Toronto, 2011]

To build an objective tree, start with a list of objectives you have discovered through analysis of the
client statement and other research you have done. At the top of the tree put the most broad, genera l
objectives. These objectives often come from the basic needs the client has stated and f rom the DFX

(Design for X) considerations that are important in this project (see section 1.4 in this chapter). These
objectives are central to the project, but are often not directly measurable. An objective must be
measurable so that later in the process you can use it as the basis of comparison between two possible

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

47

1 - 17

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

design solutions. To make a fundamental, broad objective measurable you have to decompose it into
measurable pieces.
To build the tree further, define the more specific objectives that are measurable. Under each general
objectiv e list the specific measureable objectives that, in combination, add up to the general objective.
(see picture 10). So, for example, a general objective for this system is "easy to set up". How will you
know if the system is easy to set up? You can measure if it "requires few people to set up" with a goal of
2 people or fewer, and if it "requires a minimum amount of time to set up" with a goal of less than 10
minutes for set up. It will be easy to test a prototype (model of a design solution) against these
objectives. These specific objectives combine to allow the team to conclude which proposed system is
easiest to set up.
The objective tree shown on the example notebook page is not complete. This is clearly just a first draft.
There are many other objectives that should be added to this tree to fully define the problem. For
example, under "easy to set up" in this project you would probably want to include statements about
the number of operations that are needed for set up, fewer is better; the tools required, no specialized
tools is better; and the amount of force (normal force, and torque), energy necessary for set up, less is
better. As engineers we mean energy in the physics sense: the force t imes distance, or torque t imes
rotation, or energy of other kinds. This engineer would probably combine her work with the draft trees
develop ed by other members of her team. Then they would review their research, and brainstorm
further to create a more complete set of requirements.

How-Why Tree

An objective tree is an example of a how-why tree. The how arrow point down the tree: How will you
make the design easy to set up? By making it fast to set up and require only a few people for set up.
The why arrow point up the t ree: Why should you make it fast to set up and require only a few people?
Because this makes the system easy to set up. How-why trees are used in many fields including
business, education, and government: Basically, any field where the activities of the organization are
motivated by performance objectives. They are used to organize information from high level global
objectives, down to measureable loca l objectives.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

48

1 - 18

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Easy to set up

How

I
Requi res
p eople

Minimal
set up t ime

Minimal
number of
operations

No special
tools
required
Why

Picture 10. Example of one piece of a how-why t ree.

Picture 11. Picture of a business t eam asking questions such as "how are we going to make a profit this
year?" and "why are we developing a new marketing campaign?"
Lists of objectives for a project can be long, and are often in conflict. For example, fast and powerful are
often in conflict with light and inexpensive (think cars or computers). It would be terrif ic if engineers
could meet all of the obj ectives for a design perfect ly, but that is rarely possible. Therefore it is useful to
rank, or prioritize the objectives so the engineering design team can pick a solut ion that meets the most
important objectives to the greatest degree possible. The less important objectives w ill still be included
in t he decision making, but to a lesser degree.
The easiest method for prioritizing a long list of any kind is using a pairwise comparison process. This
allows you t o compare just one item to one other item at a t ime which reduces the complexity of
ordering a long list. A detailed explanation of using a pairwise comparison method can be found in
Decision Making Tools link to decision making tools. When using this method to order your
objective list make sure you use a list of objectives that are all at the same level on your t ree, i.e. don't
compare "easy to set up" to " requires no special tools for set up" . For the example tree shown in
Picture 9, the priorit ized list would rank f rom most important to least important: "easy to use", "low
cost", ''durable", "easy to set up", and "easy to maintain" along w ith the other essential obj ectives that
are added during the process of developing the requirements.

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

49

1 - 19

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

1.3.3. Constraints
Definition: Constraints are what the technology must be.
Constraints set absolute limits. If a potential solution violates a constraint, then it must be thrown out.
In the analogy, where functions set the boundary, and objectives describe the landscape, constraints
define "no-go" areas in the landscape. Constraints are areas of the landscape that are too hazardous,
too expensive, or are fenced-off for other reasons.
For example, constraints might result from:
Federal Aviation Laws
Maximum proj ect or product costs
Safety Codes
Inter-operation (connection) requirements, e.g. must connect to or operate with an existing
system.
In virtually every design project there will be constraints related to safety and reliability. Basically there
are consequences to the failure of systems, and in engineering these consequences carry considerable
risk to the health, saf ety and the security of people. Even if people are not physically hurt, if a design
fails there may be other damage to property or economic value. It is very important, therefore, to list in
the requirements the constraints the system must meet to effectively manage the risks.
Picture 12. Show the island again with areas fenced off and skull and cross bone signs, or "danger do not
enter" signs in the fenced off areas.

What is the difference between an objective goal and a constraint?


An obj ective goa l sets an approximate level for the acceptable performance or characteristics that you
want to achieve in your design. A constraint is an absolute limit. Any design that does not satisfy the
constraint, even by a little bit, will automatically be removed from consideration as a solution for the
design problem you have defined. Some constraints will not be related to an objectiv e, and you can
have objectives that don't relate to a constraint.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

50

1 - 20

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Table 4. Examples of constraints.


Objective

Objective Goal

Constraint

A wide variety of
colors

At least 100
(increased from 10 to 100 based
on client feedback)

Must be producible in at least 40 colors to


be acceptable to the client

Inexpensive

Less than $10 million

Shall cost no more than $15 mi llion


maximum

Easy access to
information about
the courses

No more than two mouse clicks


to the course content or
scheduling information from any
point in the registration process.

No particular constraint associated with


this objective

Examples of other constraints that may be


unconnected to the objectives:
Must meet all safety regulations
Shall conform to industry standards*
Must be legal to operate
* In some industries the use of the word "shall" is used exclusively to denote a constraint, the word
"must" is not acceptable in the statement of a constraint. In a contract between the designers and the
client the word "shall" indicates a contractual obligation that the design must meet. Sometimes the
word "will" is allowed, but it is generally avoided because it may not be legally binding.

Methods for generating and managing constraints:


Constraints are commonly generated in three ways:
1.

Consultation with the client


The client statement may contain some constraints that you can echo in your project requirements.
These include statements about the maximum cost of the design, or issues related to performance
and marketing. It is important to dissect the client statement to find constraints, but also to consult
with the client to uncover additional constraints that may not have been made explicit. Many times
the client is so fami liar with their own design problem that they forget to include basic assumed
ideas in their statement. To create a design that is going to be acceptable to the client it is
important to uncover these assumptions and make them explicit in the requirements.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

51

1 - 21

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

2.

Gathering information on regulations, codes and standards


Part of your job as an engineer is to identify the regulations, codes and standards that pertain to the
design problem you are working on. Findi ng the codes and standards and understanding them for
purposes of designing a system that meets these constraints is part of doing due diligence {doing
your work responsibly). For example; building designs must meet the local building code. The code
imposes constraints. Many of these codes, standards and other information relevant to constraints
can be found on-line, but you will probably need to also consult analog sources (i.e. paper). For a
new engineering student it can be difficult to figure out which codes apply, understand the technical
content of the code or standard, and figure out how to apply the code, standard or regulation to the
design problem. Not to worry. As your technical proficiency increases you will be able to grasp this
material and use it. Once you become an engineer you must use codes properly, and get help when
you are unsure of what to do. However, at the introductory level of engineering school you should
be able to identify the appropriate codes and cite them in your constraints list. You might, w ith
some help, also be able to apply these in your design process, but at the very least you should show
that you know which codes, standards and regulations might apply to your design project.

There may be instances when it is not initially obvious which codes pertain to the project until you
start developing some solution ideas. It is always worthwhile revisiting your requirements,
particularly the constraints section, as you continue through the design process. You may find that
it is necessary to add more information about codes, regulations, and other constraints to your
requirements section as new ideas arise.

3.

Stakeholder imposed constraints and broader considerations


Within the client organization there may be other people who have ideas about the constraints for
the project. This includes the marketing and legal departments. The client organ ization may
specify, for example, that the design should not make use of existing patented technologies because
usi ng this technology will require a license. Beyond the client there will be other stakeholders in
your proj ect that will suggest constraints (see section 1.4 in this chapter). Constraints from
stakeholders in the client organization and from outside the client organization often arise through

DFX (design for X) considerations (see section 1.4 in this chapter). Part 2 of this text will deal with
DFX considerations and will introduce methods of designing with these considerations in mind. It is
important, therefore, to think through the DFX considerations and to seek out consultation w ith

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

52

1 - 22

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

stakeholders beyond the client to uncover the requirements that arise from these people and
organizations.

Developing the lists of the functions, objectives and constraints for the design project are essential and
will form the basis for generating solution ideas, evaluating those ideas, and eventually choosing an idea
or ideas to develop into a detailed design. As with other parts of this process, the development of the
functions, objectives and constraints is highly iterative. These sets should be revisited and refined
throughout the design process. What these lists are called, the terminology used (i.e. functions,
objectives, and constraints), matters less than understanding the purpose that these statements serve.
They serve to clarify the problem as much as possible for the design team, the client and other
stakeholders in the process. They set a target that everyone can work toward. Requirements that are
ambiguous or incomplete can lead to inefficiency in the process and frustration, as people try to f igure
out what is being designed as they go along.

Picture 13. cartoon of a family leaving the house. Parent says "let's go get dinner". Each person leaves
the house prepared for a different activity: one with a picnic basket, one dressed up, for a nice
restaurant, one prepared to pick vegetables from a garden, etc. Caption: If the goal of the project isn't
clearly stated, the team may not all be working toward the same target.

Other ways to categorize requirements: Goals, constraints and criteria


The use of the categories "functions, objectives and constraints" is just one of many different ways to
organize the requirements. Another organization that is used in product design is: goals, constraints and
criteria [2]. In this framework constraints are defined in the same way as we have defined them here.
Goals includes both functions (called functional goals in this framework), but also can include aspects of
objectives (called non-functional goals). And criteria in the goals/constraints/criteria framework
describes the directionality of the goals, e.g. in cost less is usua lly better, but in speed higher is often
better (depending on what you are designing).

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

53

1 - 23

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

This is only one example. Different disciplines and industries will have their own way of categorizing the
requirements for a design project, and these categories are evolving. However, the purpose of the
requirements documentation is always the same: to clearly define the design problem.

It is worthwhile includ ing in your documentation the reasoning behind your stated requirements. At a
minimum, the reasoning should be recorded in your engineering notebook. It is our experience that
requirements may be dropped later as being unnecessary restrictions on the design if there is no
supporting documentation to remind the team why the requirement was included. This can result in the
failure of the design if, in fact, the dropped re,quirement was essential.

1.3.4. Summary: requirements

Table 5 Summary- Functions, Obj ectives, Constraints

Requirement

Definition

Notes

what the design

Active statement. Necessary for any acceptable design

must do

solution.

what the design

Descriptive statement. Objectives help differentiate and

should be

rank the various design solution ideas.

what the design

Properties demanded by society or by the client. Legal

must be

requirements. Cost requirements. Overall system or

Type
Function

Objective

Constraint

situation requirements (such as "must work with a


particular operating system"

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

54

1 - 24

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

1.4.

Documenting the Project Context

A substantial number of the functions, objectives, and constraints for a design project will result from
the context of the design project. Initially the list of requirements will come from the design brief and
your own thinking and research on the project topic. However, considering the project from multiple
perspectives will add to the requirements list. For instance; documenting information about the users
of the technology and the environment in which it will operate will give you addit ional insight into the
problem and the types of solutions that will be effective.
There are many perspectives that could be investigated for any design project. We suggest that
documenting a few essential aspects of the context will help you develop a more complete and
successful project:
Service Environment
Users and operators
Stakeholders

DFX considerations
This list is not meant to imply a sequence. The information can be developed in any order, and usually
development is highly iterative. As your team does research using a variety of sources you will generate
information for all of these categories. Your team will need to sort out the information and organize it
to create a meaningful documentation of the design problem context.

l.4.l. Servic:e Environment


Definition: the service environment is a description ofthe environment in which the technology will
operate.
The service environment describes the location where the design will operate. A location is more than
just a latitude and longitude on earth or a point in space. The description of a location includes a
description of all elements that might typically be present in that location. For example the amount of
rain, the typical temperature range, the presence or absence of cell phone coverage, the types of
animals and insects native to the environment, the noise level range, and the people. If the technology

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

55

1 - 25

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

you are designing will be mobile, or will be installed in a number of different locations, then you need to
describe the range of conditions typical for these different locations. If it will only operate outside, then
you need to describe the outside conditions. And if it will only operate inside, then you need to describe
the indoor conditions. You may t hink it is obvious what "indoor conditions" means, but indoor
conditions in a yurt in Mongolia are very different than the indoor conditions in a gym locker room in
Uruguay. Underwater, deep space, the Arctic and many other situations will bring even more service
environment factors into consideration if you are designing technology that must operate in these
environments.
The description of the service environment is important when the conditions can cause the technology
you are designing to fail for the user. Structural engineers always take into account the wind and
weather conditions of the location for the design of a building structure. This should be obvious.
However, service environment considerations are equally important for the design of a new type of
snow t ire that must operate in snow, but also safely on hot dry roads, or a new on-line banking system
that must operate in a virt ual environment accessed by people who speak a variety of languages and
people who want to try to hack the system .
It is sometimes easiest to develop this information as a diagram. Picture 14 shows some of the service
environment considerat ions for a marine buoy (or channel marker). Note that the service environment
should include installation and removal from service as makes sense.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

56

1 - 26

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Shipboard storage
container for
deployment &
removal

Animals

Seawater, sea
spray, ice,

currents, tides

Barnacles and
similar pests

Air
Temperature,
wind, fog, etc..

Monitoring /
Control Device
Boats
Ships

Operator

Flotsam
Jetsam

Picture 14. Service environment diagram for a marine buoy. This diagram shows where the buoy is
affected (arrows towards the buoy) and where it affects the environment (arrows away from buoy). The
picture of the buoy itself is not meant to imply any particular design solution.
The service environment documentation should not be written from the point of view of the design you
are creating. That is, it is not how the device wi ll be designed to operate within an environment, but
instead a basic description of what the environmental conditions are. In other words, not " The design
must be water-proof' but instead "The design will be used outdoors in Toronto Canada, in all weather.
Temperatures can be expected to range from 3.0 F to 85F [3]. Average rainfall is 684.6 mm and snow
is 115.4 em [4] ."

This statement about the service environment may then be t ranslated into a

constraint ("The design must be water-tight to a depth of Scm") and/or an objective and goal ("The
design should be as water-resistant as possible, preferably water-tight to a depth of lOcm").

Unfortunately, mixed units (51 and IP) are very common in engineering problems.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

57

1 - 27

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Identifying and describing the service environm ent:


There are many aspects of the service environment that could be investigated and described. You
should include all aspects that are potentially relevant for your design project, understanding that you
can return to update and add to the service environment as needed. Developing a complete service
environment description can prompt design ideas. For example, knowing that cell phone coverage
exists in a location may prompt you to consider a wireless communication system that would augment
your design in some way, or allow your users to use their smart phones with your system. However, it
makes no sense to include an aspect of the service environment that clearly has no conceivable bearing
on you r design. For example it makes no sense to specify the typical outdoor wind speed when you are
working on the design of a new type of food processor, even if you might imagine that some user might
ta ke their food processor outdoors.
We suggest that you init ially focus on three aspects that typically are important in many types of design
projects. You can always add more characteristics to this list.
Physical environment

Physical environment pertains to characteristics such as temperature range, pressure range, wind
velocity, rain, snow, ice and salt water spray, sun conditions, humidity, dirt and dust, corrosive
environments, shock loading, vibration, and noise level. Basically t his includes the extremes of physical
environment experienced where the design is operating. As a general rule, you don't need to choose
the most extreme extremes: e.g. the record low temperature or high temperature. Engineers typically
use ranges that are based on statistical percentages. For example ASHRAE tables (American Society of
Heating, Refrigeration, and Air-conditioning Engineers) and other environmental statistics will report the
99% low temperature or 1% high temperature for an environment which means that 99% of the time
the temperature is above this low and 1% of the t ime the temperature is above this high. That is
probably sufficient for many of the design projects you do, particularly in engineering school. If you are
working on a special design, such as the design of equipment for an arctic expedition or for inside a
tornado, then obviously you would adj ust your service envi ronment description (and associated
objectives and constraints) accordingly.
Some environmental factors work over t ime. Corrosion, such as rusting, is one of these. Other factors
are more subtle - for example, you might design a product that survives a very high temperature, but

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

58

1 - 28

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

will fail with repeated temperature cycles because parts are expanding, and contracting with every
cycle. Similarly bending a wire back and forth will break it. This is called fatigue. The reliability of a
design over time is an important consideration link to chapter on reliability.
A description of the physical environment would also acknowledge other elements that may be active in
the user's environment, including (but not limited to) appliances, machinery, or services (such as the
availability of clean water). It could describe any assumptions you are making about other systems that
the user has access to while using your design, e.g. the specifications of a computer necessary to run t he
software you are developing. Another example; you might state that you expect the environment will
include access to a table or other flat horizontal surface at an appropriate height. Again this may seem
like you are stating the obvious, until you try using your laptop computer standing up. Clearly the design
of most laptops makes the assumption that you have access to a table, or surface (like a lap) at an
appropriate height. There is nothing wrong with the design of your Ia ptop, but the requirements used
by the designers should have explicitly acknowledged the assumption that a surface would be available.
This is good design practice. Getting into the habit of explicitly acknowledging your assumptions about
the operating environment and other aspects of the design problem is part of developing a design
thinking perspective.
Picture 15. Someone trying to plug in a device such as a " camping TV" where there is no outlet
available. (box for the device says " use it anywhere, no additional equipment needed!" and has a
picture on the side showing a family enjoying a tv show next to their tent)
Living things

Your service environment description should include the people and other living things that are in the
environment. There wi ll be special attention given to describing the users and operators of the design
(see next section). In addit ion to the users there may be other people present in the service
environment. You should try to broadly describe these people. This may be very general, but at least
you are acknowledging the possible interaction between these other people and the design. For
example, the design of a vacuum cleaner for home use must take into account the possible presence of
children in the environment and should be, to the extent possible, child safe. Whereas, the design of a
vacuum cleaning system for an industrial machine shop would probably not mention children, and "child
safe" would not enter into the constraints list.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

59

1 - 29

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

In addition to people there are other living things in many environments. These include the possible
presence of pets, livestock, wi ld animals, insects, microbes, and plants. These should be described to
the extent that they may conceivably be important to the design project you are working on. In the
example of the design of a vacuum cleaner for home use, the possible presence of pets, insects, and
house p lants should be acknowledged. You might also want to describe some common household
microbes if you think you might want to design a system that removes these from indoor surfaces. You
would probably not mention livestock or wild animals in your service environment description for a
household vacuum cleaner project.
In addition to users, other people, and other living beings, who have a positive or neutral interaction
with your design, you need to also describe the presence of malevolent beings in the service
environment. These include people who could vanda lize the design or use it improperly; Insects or
animals that could damage the technology; and microbes, fungus, or mold that could grow in or on your
system (if it is a product or installation}. Many clients for technology that will be used in hostile
environments (such as the military} will specify that the design surfaces be anti-fungal, and that any
sensitive technology be enclosed in a vermin-p roof casing. For virtual technologies, your service
environment should mention the presence of hackers particularly if the system might be making use of
sensitive information (e.g. credit card numbers, banking information, or personal information).

Virtual environment
The last category that we suggest you include in your service environment is virtual environment. Many
design projects will not need to acknowledge or describe the virtual environment at all. If, for example,
you are designing a new type of shampoo bottle, it is unlikely that information about the virtual
environment will affect your design and you can leave this section out. However, if there is a good
possibility that your design could make use of existing virtual infrastructure, such as w ireless networks,
satellite coverage (e.g. GPS), or cell phone signals, then you should explicitly state what your
assumptions are. What type of access to these systems are you assuming will exist in the environment
where the design will be operating?
If you are not sure whether virtual systems wi ll be important to your design,
then leave this section out. You can always come back to add it if you find
that the design process is leading you toward a solution that requires the

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

60

1 - 30

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

existence and access to these types of systems. Remember not to describe the design solutions you are
considering, or how they will function. The service environment description should just describe the
characteristics ofthe environment where the system will be operating.
The reason for including all of these aspects in your service environment description is just to make sure
that you make your assumptions explicit. This process reminds your team to do thei r homework (i.e.
due diligence), research the environmental conditions, and gather information about the location of
operation. It is part of being intentional as a designer. Numerous technologies have failed because
designers have relied on the service environment having certain attributes, and their assumptions were
incorrect. But they may never have checked their assumptions because they never explicitly stated
them.

What about parts of the service environment that don't neatly fit into one of these categories?
There are plenty of characteristics of many environments that don't neatly fit into one of these
categor ies. You can always create an "other'' category for these or put them into one of the categories
that you think fits best. For example, the avai lability of electricity in the location where the design will
be operating, and the characteristics of the standard electrical service that is available (i.e. in North
America llOV). Is this a physical characteristic of the environment or a virtual characteristic? It doesn't
matter which category you place it in, as long as you list is somewhere. Again, if you are designing a
shampoo bottle you shouldn't state information about the electrical service anywhere in the service
environment, at least until you start down a solution path that requires electricity to operate your
shampoo bottle. But if you are designing a water pump system for a remote location, it is worth noting
that you are assuming e lectrica l service is available (or not) because this assumption would change the
constraints list for the design project. The categories we have suggested are only to help you get started
in your thinking process. Feel free to add a "miscellaneous" category or sort your service environment
information in any other way that makes sense for your project. The category names don't matter, it is
the information about the environment that is important, because it is this information that you will use
to shape your design process.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

61

1 - 31

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Using your service environment information


Once you have developed a clear description of the service environment, go back and revisit your
functions, objectives and constraints. Use your service environment information to create objectives
and constraints for your system. For example, if you have uncovered the fact that there is no reliable
access to electricity in this service environment, then you may want to add a constraint "the design must
operate without electricity input from a power grid". If you know that the design will require energy
input (because the design must do work, and work requires energy input) then you might add to the
functions list "design will use available energy sources as necessary to provide functionality", without
yet specifying the nature of the energy input (e.g. solar, manual, water power, wind). Or if, in the
develop ment of the service environment description, you have realized that the environment may
contain people who could vandalize your system, then you might want to add to your objectives list:
"the design should be difficult to vandalize" (the more difficult the better). This objective would have to
be further developed to make it properly testable.
1.4.2. Users, Operators, and Client

Definition: The users and operators describe the people who will be using and operating the technology
you are designing. The client describes the person or organization that commissioned the design.
The users, operators, and client for your design play an essential role in the design problem and should
be described explicitly. This is an especially sensitive section of the problem description because you
must describe the client back to themselves. The descriptions of the users, operators, and client must
have a tone of respect; this is an important as.pect of the professionalism exhibited in your work. As
much as possible, it should use the terms that the users and operators use to describe themselves.

Example:
Suppose you are designing an on-line system that is being used by an organization that provides
counselling for people being treated for cancer. They want to provide a confidential chat system for
their clients. If the organization refers to their clients (the users of your system) as 'cancer survivors'
then that is how you should describe them. Not, for example, as 'cancer victims'. It may seem like a
small difference to you, but for the organization who is reading your p roposal and deciding whether to

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

62

1 - 32

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

hire you to design their system, it is a big difference. Link to documenting the process, audience
analysis.

The users and operators


The description of the users and operators should describe, in as much detail as possible, the people (or
other beings) who will be using the design. This should not be overly narrow, focussi ng only on a single
culture for example. But also, it should be as detailed as possible. This is a difficult task, but try to think
about it in terms of what all of the users or operators have in common. Often the users and operators
are the same people, but sometimes they are different groups of people who should be described
separately.
For example: Consider a new piece of surgical equipment such as a new type of surgical staples used to
suture a laceration or incision. The medical staff (e.g. doctors and nurses), are operating the technology
and therefore using it. However, the patient is also a user and their perspective should be considered in
the design process.
The description of the users and operators should include physical, psychological, social, and
organizational factors [5] . You also must show respect for the users, no matter who they are or how you
personally feel about them. Consider the following questions:
Physical

Who are the users? What do they have in common?


What is their height range, mobility and other anthropogenic data. These data are available in
handbooks and on-line.
What are their physical characteristics? This is important because many designs rely on some
aspect of the users physical characteristics.

Picture 16. Picture of a sign at an amusement park: "To go on this ride you must be this tall."

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

63

1 - 33

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

You will need to comment on the assumed physical traits of your users and operators further once you
have begun to develop a design solution, but this information will come in your conceptual design
documentation.
Psychological

What languages do the users speak?


What level of education do they have (e.g. reading ability, computer or math skills if these might
play a role in your design project)
If your design will be operating in a special environment (such as an industrial workplace), do
the users have a special set of skills or special knowledge? Do they receive special training?
What is the cognitive ability range of your user group? This is particularly important if your
system is going to rely on the cognitive ability of the user or if the design is for a set of users
with different cognitive abilities from your own, (such as children).
What are some of the other "psychological norms" that may play an important role in the design
problem you are working on? Is there an expectation of a design based on the normal operating
environment, such as large buttons for equipment in a steel mill where the steel rolling
equipment is huge and heavy?
There is a temptation to send out a questionnaire or do a poll to get information about users. However,
designi ng questions to collect good information that do not introduce bias is difficult, and requires
specialized training. Except for simple cases, it is likely beyond the expertise of most students and most
engineers. The engineer should always be careful of any such information link to skeptical thinking
Keep in mind that psychological norms are often culturally specific. For example, in North America it
would be "normal" to design a switch where the up position is on and the down position is off. But in
other parts of the world up is off, and down is on. Imagine how frustrating it would be to use a device
that violates the basic psychological norms you are used to.
Social

What are the social norms of your user or operator group?

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

64

1 - 34

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Do they share a common culture? If so, what are some of the aspects of that culture? Keep in
mind that culture does not need to be based on the culture of a country or location, it can be
based on a community.
For example, there is the "culture" of university students around the world who share some
commonalities (e.g. exams, courses, dealing with professors, social norms). These things may be
somewhat different from place to place, but many of the aspects of the culture are common. In fact,
Face book is an example of a technology that was designed explicitly for the common social culture of
university students worldwide. The description of the social aspects of your user or operator group can
be essential to your design depending on the nature of your project.

Organizational
Do your users or operators all belong to the same organization? For example, do they all work
for the same company? Or are all citizens of the same country? Or belong to the same
profession?
What are the values and goals of this organization (if the design project is focused on users in a
particular organization)?
For example, suppose you are designing a syst em that will be used by doctors and nurses. You would
want to make sure that your design f its the values and goals of the medical profession. Here, in the
users section, you would briefly describe the organization from the perspective of the users. In this
example you would briefly describe the medical profession (values, cu lture, and ethics) from the
perspective of medical practitioners, i.e. doctors and nurses. This would help you keep in mind the
users' perspective when you begin to design the system.
These organizations do not have to be formal. For example, if you are designing a bicycle accessory, you
will be dealing with the biking community. In general their aims and attitudes may differ somewhat from
those of other users of the roadways, such as drivers and pedestrians. Your design choices may be
directed by those differing aims and attitudes.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

65

1 - 35

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

The client
If the client is different from the users then you need to also describe the client. That is if the client is an
individual or organization who is commissioning the design, but will not directly be using the design,
then you need to describe the client. The description of the client is typically briefer than the
description of the users and operators. It describes only the essential features of the client, and those
aspects that pertain directly to the project. We recommend that the client description include a
statement about the client's ethical beliefs and values in your own words. This is because what ever you
are designing must fit with the client's ethical beliefs and values to be adopted.
Examples: put in here 1 description of a client who is an individual, and 1 description of a company that
is the client. Try to include examples of physical (company size), psychological (client motivation), social
(culture or values), and organizational. Make it clear in both examples that the client described is not
the user.
Getting to know the users, operators, and client
Even for professional design engineers it is very difficult to design systems that will be used by people
different than themselves. And the more different the user and client are from the design engineer the
more difficult it is for the engineer to imagine how the user and client will perceive and make use of the
design. It is therefore critical for the design engineer to investigate who the users and client are and
take the time to get to know their needs. It is not unusual now, for example, to find engineers in the
operati ng room with surgeons observing how medical instrumentation is used; on the floor of a
manufacturing plant talking to assembly line workers; or working with development groups in rural
villages to understand the perspective of the people who will be using the technology.
Equally, it is easy for an engineer to misjudge a design project if the users are very similar to the
engineer. This is because the engineer might assume that all of the users wi ll approach the design, and
will perceive it, the same way they themselves do. They make the mistaken assumption that all of the
users are exactly identical to themselves.
To avoid these mistakes, the design team must take the time to understand the users, operators, and
client. There are several strategies for doing this:

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

66

1 - 36

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

1. Try it yourself: if you are designing a new system to replace an existing technology, try using the
old technology yourself. Become the user. Observe what you do and how you do it. Talk out
loud and make lots of observations about the experience. Sometimes an experienced operator
will neglect to tell you the lessons they learned when they first started using the system; habits
which are now routine for them.
2.

Gather information: use standard resources to gather information about the client and users.
(Link to information gathering)

3.

Live it: it helps if you have lived with the users and worked with them. A design f its into an
operational culture, and the better you know the culture, the better your design.

4.

Interviews: interview the client and users about their perception of the existing systems, and
the need for a new technology. And ask them about themselves. You need to know, however,
that many users will report that an existing technology is "just fine" but if you observe them
using it you might see a very different situation. Talk to the people that are very hands-on with
the technology. Maintenance people often will be able to tell you more about an existing design
than top-level managers (but don't tell the managers this, of course!)

5.

Observation: watch the user using an existing system and ask them to tell you about it while
they are using it: i.e. in situ observation. This is part of what is called task analysis. (Link to
human factors chapter). Be sure the user(s) know that you are not judging their operation or
jobs, just there to learn.

More methods for understanding the user's and operator's perspective:

Use cases, task analysis and benchmarking:


All three of these methods are discussed in more detail in the Design and Critical Analysis Techniques
section link to Design and Critical Analysis Techniques. Briefly:
A use case is a description of how a person or system achieves a goal using the technology you are
designi ng. A use case describes the interaction.
A task analysis is an analysis of the way a user performs a task. This is usually done by observing or
videoing a user performing a task. Then the engineer writes up an analysis of what the user did and how
they did it. This is especially usefu l if you are designing new technology to replace an old way of doing

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

67

1 - 37

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

something.

Benchmarking is the analysis of an existing technology. This involves the engineer, or others, using an
existing piece of technology that has similar functionality to the design project they are working on. The
engineer observes the interaction and analyzes it (like a task ana lysis); how long does it take to do
something, how difficult is it, what are the relevant performance features of the technology. Then the
engineering team dissects the existing technology to understand why and how it was designed the way
it was.
Increasingly companies that have a design focus are employing people who specialize in understanding
other people's perspective. These include psychologists and cultural anthropologists who might work
with the design team to help the team understand their users.

What you and your team experiences, measures and sees themselves is often more reliable and more
revealing than information that comes second or third hand, relayed (and interpreted) by others. This
list probably covers more than you might be expected to do for a design project early in your
engineering schooling. However, understanding the users, operators, and clients for your design is a
critical step to creating a technology that will be accepted and used.
As we said at the beginning of this chapter, many designs are unsuccessful because they solve the wrong

problem. Sometimes it is because the technology is designed for the engineer themselves rather than
the user. What engineers think is cool, usable, or necessary frequently isn't for other people. A good
design engineer listens to the client and the users, and constantly keeps their perspectives in mind while

working through the design process.


Often i nformation about the operators, users and clients is included in the design documentation. This
helps the reader understand why certain requirements were included. Inclusion of use cases, task
analysis, and benchmarking information can also help to deepen your understanding, and your client's
understanding, of the design problem.
Once you have described the users, operators and clients for the technology you are designing, you then
need to use this information to further develop your requirements. In particular, the information about
the people and organizations that will be interacting with the technology should enter into the

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

68

1 - 38

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

objectives and constraints for the design problem. Think through the technology from their perspective
and note what features and hazards are associated with the use, or misuse of the technology you are
designi ng. For example, if your user is a child (e.g. you are designing toys for children) then you need to
ta ke int o account that t he user may not be able to read warning labels, or be responsible for following a
warning. Therefore, your constraints list should require removal of all possible hazards (include a
specific list) and compliance with appropriate regulations regarding children's toys. In addition, the
psychological profile and developmental information about children should guide the development of
objectiv es that would improve the potential success of your design. You might also note unintended
uses ofthe toy (eating it, throwing it , pounding it, putting food into it) that need to be taken into
account in the design.

1.4.3. Stakeholders
Definition: A description of the stakeholders and their interests.
Defining the design problem also requires identifying the various stakeholders in t he project. We
mentioned stakeholders earlier in this chapter when we discussed constraints. Stakeholders are people
or organizations that have a stake or interest in the technology you are creating. A stakeholder interest
is an organization or person's real or implied connection to a design. It may be economic, physical or
psychological. An interest implies that there may be benefit or loss due to the design.
The three most obvious stakeholders are the client, the users (or operators), and the engineering design
team. In fact, users and client are so obvious, and so clearly discussed in other parts of the design
requirements, t hat we do not list them under stakeholders. This may seem odd, but it is a convention.
It waul d be redundant to list them again in the stakeholder section after describing them so thoroughly
in other sections of a design report. The engineering design team is also, obviously, a stakeholder. The
quality of the work they do wi ll impact their reputation, and possibly their pay check. However, the
design t eam is never listed as a stakeholder. Again, this is a matter of convention. Remember that the
requirements are specified to help you define the needs of the design proj ect explicitly and to articulate
an agreement between the engineers and client about what is being designed. It is expected that you
already know your own needs, and it isn't necessary to explain them to your client. So these most

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

69

1 - 39

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

obvious stakeholders are not actually listed in the stakeholder section of the requirements. This section
details the interests of the other people and organizations that have a stake in the project.
The kinds of interests that the stakeholders have in the project generally fa ll into categories related to
economics, ethics or morality, legality, human factors, social impact, and environmental impact. The
stakeholders can be individuals, organizations (companies, non-profit organizations, or professional
organizations) and government agencies. In this context non-prof it organizations (such as charities) are
often referred to as non-governmental-organizations (NGO's). The stakeholder section of the
requirements should list each of the stakeholders that should be taken into account in the design
process, and the interests that they represent. Plants, animals, and the environment are not
stakeholders, but are represented by NGO's w ith an interest in them (e.g. the Humane Society, World
Wildlife Fund, Sierra Club and similar organizations). The point of this list is to alert the client to the
existence of t hese interests and remind the design team that there are other perspectives and people
who will have an impact on the success, or failure, of a technology.
Certain disciplines of engineering are particularly sensitive to stakeholder concerns. Civil engineering,
for example, often deals with large infrastructure projects that will impact a whole community or region.
Often these types of projects require environmental impact statements and commun ity consultation
Link to chapter on design for the environment and communities. Insufficient attention to
stakeholder interests on these types of projects can result in the project being delayed for decades or
even cancelled (see H-1, Hawaii interstate, case study). Gathering information to develop a complete
list of the stakeholders early in the project, and following this up with on-going consu ltation with these
groups, can significantly improve the chances of success for projects of this nature.
Table 6. Exam pie of stakeholders and their interests for a municipal water treatment plant.
Example: A new water treatment plant is being planned. It will be located on a lake shore. The plant is

intended to deliver clean drinking water to a community of 30,000 people, replacing an aging plant that
is no longer able to meet the growing demand f rom the community.
Users: public that will be getting the clean drinking water
Operators: the people who will be r unning the plant
Client: The town or municipality if this is a public water system
Below is just a small sampling of some of the other people and organizations who would have an

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

70

1 - 40

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

interest in this project and wou ld probably want their concerns taken into account by the design
engineers.
Stakeholder

Interest

Community
organizations

There may be special interest groups in the town, (e.g. people whose homes
are located near the planned plant site), who will voice concern. Their
concerns may be:
- economic: impact on their house and land values
-economic and social: job opportunities as plant operators
- environmental: impact on their local natural environment
- ethical and social: concerns about impact on local historical sites,
proximity to religious sites (a nearby graveyard), impact on traditional sites
used for social activities (e.g. removal of a park and picnic area), and
aesthetic impact.

Regulatory agencies at
the state or federal level

Environmental NGO's

- environmental: concerns about the plant, business development and


population growth, and the pressures of these on the natural environment
around the community including flora and fauna

legal: compliance with state and federal regulations

-ethical: concerns about the trade off between environmental impact and
public health.
Local sporting clubs

- social and environmental: concerns about impact on fishing, hunting or


water sport activities

Chamber of commerce
or other local business
associations

- economic: interest in having clean water available for business


development and population growth.

Local hea lth agencies

-socia l and ethical: interest in the health and welfare of the community
which depends, in part, on the availability of clean drinking water.

Tim and Sara Murphy

- economic and human factors: Mr. and Ms. Murphy's house is going to be
seized by eminent domain because it sits on the planned site for the plant.
They wi ll be compensated. However, they obviously have an interest in fair
compensation, and the physical and psychological upheaval that will result
from having to move.

(link to case study: Cape Cod offshore wind turbine project)


Once you have identified the stakeholders and their interests, these can be used to add to the list of
functions, objectives and constraints in your project requirements. For example, the economic interests
voiced by the Chamber of Commerce may be used to create a requirement that the p lant be expandable
to handle additional load resulting from future demand. A requirement of this nature would require
consult ation with the client before including it Or the interests of the local community organizations

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

71

1 - 41

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

might result in the addition of an objective to maintain some park land area at the site with an improved
picnic area. Listening to the residents and taking their concerns into account can result in a set of
requirements that motivates a more innovative, and improved design solution than would have resulted
otherwise.
Having details about the stakeholders in your design documentation w ill help the readers understand
the sources of the various requirements you generate, and later the reasons behind the design choices
you make.

1.4.4. DFX considerations

Definition: Identification of the particular Design for X considerations that pertain to the design project.
The requirements are incomplete without taking into account DFX considerations. link to Part 2 of the
text, DFX chapters Like the stakeholders section, information about DFX considerations will feed back
into the lists of functions, objectives and constraints.
DFX means Design for X, where 'X' is a design consideration that is of particular importance to the
specific project you are working on. Some common DFX considerations are:
Design for human factors
Design for the environment and community considerations
Design for manufacturability
Design for safety
Design for durability
Design for maintainability
Design for intellectua l property
Design for aesthetics
Design for flexibility
(link this list to the relevant chapters)

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

72

1 - 42

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Look down this list carefully and identify if any of these DFX considerations particularly apply to the
design project you are working on. Think about any other DFX's not listed here that might be important
in your project. Explain briefly why each of the DFX's will apply particularly to this design problem.
Remember that at this point you are explaining how the DFX pertains to the design problem, not any
particu lar solution. If there is one DFX topic that is especially applicable to the project then you may
want to research this subject further to learn methods and standard practices that you can implement
to create a more effective design solution. You should also use the DFX topics you have identif ied to
add to your lists of objectives, functions, and constraints.
For example, suppose you are designing a new highway. Safety will probably be a key concern. You
would add "design should be safe" to your list of objectives, if it isn't already there, later expanding this
into testable requirements. There will also be a whole set of special codes and standards for the design
of a highway that must be followed to improve safety. However, in researching design for safety you
will also find that there are various common ways of approaching this DFX topic. You can remove
hazards; guard against hazards; and warn against hazards. Knowing this information, you might then
add further to the list of constraints: " specific exceptional hazards shall be removed, guarded, or warned
against" (followed by a list of the specific hazards). So identifying this DFX consideration allows you to
make your requirements list more complete and specific. It also reminds you later to specify the
addition of the "Beware, moose crossing ahead" sign in the appropriate location.

1.4.5. Other considerations for defining the project: Marketing

For projects in your first few years of engineering school the categories discussed in t his chapter are
probably sufficient for you to form an understanding of the problem and document it. However, for
advanced projects and projects in industry there will be additional areas that will need to be researched
and expressed to define the design problem.
One of the most common considerations that occurs in industry, but not often in university projects, is
marketing. The marketing department in a consumer or commercial product or services company will
play a significant role in the development of requirements for a new design. Typically the marketing
department wil l contribute objectives for the project. However, the marketing department may also
insist on the addition of functions, and may apply constraints. The most common constraints will be in

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

73

1 - 43

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

regard to cost, and the relation of the features of the technology you are designing relative to current
technology on the market. They may insist, for example that the new product or service be faster than
the competing technology already on the market. If your design does not meet this requirement, then
the marketing department may decide not to support the continuation of the design project. Marketing
can also be a major source of requests for design changes later in the design or implementation process.
This is one source of scope creep, which is when the requirements for a project are changed or the
functionalities increased while the engineers are in the process of designing or building a system. It is
easier to cope with these requests if your team has a clear set of requirements and uses some design for
flexibility strategies link to design for f lexibi lity chapter.

1.5.

Design competitions and other types of engineering school projects

Many design projects in the first few years of engineering school are not "real" proj ects for "real"
clients. The client is a professor who is asking you to design something for a course, or maybe to
produce a design for a design competition. The user of the design wil l be you, your classmates, or
maybe an instructor who will test the design once or twice to see if it works. The goal of this type of
project is to give you a first experience with design to see how the process works, and the effort that is
involved in getting something actually built and operating. The design work is very rea l, and the
experience is an excellent first step toward being an engineer, but the project probably doesn't require
fully documenting the project context (i.e. the previous section "1.4 Documenting the Context").
In these types of in-school design activities you usually do not need to spend effort on developing
detailed user, client, and stakeholder profiles. The emphasis in this type of course is on the build-test
part of the design process. However, it is important to clearly define the problem you are intending to
solve, and have an explicit statement of the requirements at hand. Many a design team has been
disqualified from a competition because their design solution didn't meet the instructor's requirements
exactly.
If you are asked to write up the requirements for any type of design project for a course, you should
always check the assignment instructions carefully to see which requirement sections are necessary.
Does the instructor want you to detail the stakeholder list and describe the client organization? Or is
this the type of project that requires only a short list of the functions, objectives and constraints? Make

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

74

1 - 44

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

sure you know what type of project you are working on. As you move up through engineering school
the projects will become increasingly authentic to real engineering practice. Eventually you will be a
part of engineering projects in the field. The names ofthe categories (e.g. functions, obj ectives, or
stakeholders) may change but the purpose of the requirements remains the same: to define the design
problem. You will also find that the requirements, which might take only a page or so for a student
assignment, will become chapters or volumes in a larger, complex proj ect.

1.6.

Reflecting on the Design Problem

Development of the project requirements involves researching information, analyzing and organizing it.
This process helps the team learn about the project and familiarize themselves w ith the specialized
knowledge t hey will need to solve the problem. This is essential because of the complex, and openended nature of design problems. It is also essential because the design process is an information and
communication process. As a design engineer you need to make sure that your whole team has a clear,
common understanding of the design problem; that you can communicate this understanding to other
teams that you will work with on the project; and that you are in agreement with the client about the
problem you are solving.
Once the requirements have been documented the design team should reflect on the design problem
before moving forward. This reflection is part of the critical thinking that goes into a design project. The
team needs to:
Come to agreement on the problem that is being solved, i.e. agree with the requirements and
that the requirements are sufficiently well formulated and sufficiently complete to move
forward; recognizing that the requirements will be revisited as the process continues.
Come to agreement on the scope of t he project.
Do a preliminary evaluation of the nature of the problem which wi ll help to determine the
solution methods that are used.

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

75

1 - 45

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

1.6.1. Characteristics of Good Requirements

Good requirements have many characteristics. They are clear and unambiguous. They are relevant to
the project. They have three essential characteristics that are evidence of good engineering practice:
Being complete, solution independent and being testable.
Completeness
The more complete your requirements are, the easier your solution process wi ll be. Ideally, you would
want perfectly complete requirements before moving to the generation of solution ideas. However, this
is not only impossible to achieve, the time it would take to reach this ideal is not worth it. At some point
there is diminishing return on the t ime invested in development of the requirements. You just need to
start working on the solution.
There are many things in engineering (and other fields) that seem to follow an approximate 80%- 20%
rule, and a compromise on ideal requirements is probably one of these things. This means that the last
20% of the work you could do to achieve ideal requirements (if this is even possible) would probably
take 80% of your t ime, i.e. 4 times longer than it takes to generate the first 80% of your requirements.
This is a lot of time and effort for marginal improvement. So make sure your requirements are as
complete and clear as possible, and rea lly push toward the ideal of completeness, but don't expect to
have a perfect set of requirements before you move on to idea generation.

Other examples of the 80/20 rule


In construction: the last 20% of the construction of a building will take 80% of the t ime
Working with people: 20% of the people you work with will cause 80% of your headaches
In fun d raising: 20% of donors give 80% of donations during a typical f und raising campaign

Solution independent

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

76

1 - 46

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

The definition of the design problem, i.e. the requirements, must be as solution independent as
possible. This means that the requirements should not imply a specif ic design solution, or be written
with any one solution in mind. The requirements must leave open the possibility of solving the problem
in as many different ways as possible. This is very difficult because in many ways defining the problem
defines the solution.

In fact, some engineers argue that the effort and thinking needed to solve

engineering problems well is often 80% defining a problem effectively and only 20% solving it (which is
another example of the 80/20 ru le). Creating solution independent requirements is a balance between
a strategy of least commitment and a need for determinacy.
The strategy of least commitment states that at any point in the design process you should only make
decisions that are "forced" upon you, which means don't be lazy in your decision making, be intentional.
The strategy of least commitment is a strategy of leaving every possible design idea on the table for
discussion until you rule it out through deliberate decision making. Good designers do not exclude an
idea because they assume it won't work; they think it through carefully. They ask themselves, "Why
not?" In the development of the requirements, the strategy of least commitment advises that you
carefully write the requirements to allow the w idest range of solutions possible.
Carefully examine each requirement you have written. What does the requirement assume? For
example, if the requirement states "the memory size must be at least 1MB (one mega-byte)", you
should be asking yourself:
Why 1MB? Why not less, or more? This is a specific number- what should be specified is what
the memory has to do- 1MB is an implementation decision, i.e. a means statement.
Why a memory is specified at all? Is this also a means statement?
However, there is also a need for determinacy. It has been said that: "the problem with being too open
minded is that your brain might fall out". The problem with leaving your requirements too broad or
genera l is that you may never converge on a solution. The requirements must be specific enough to
guide you toward a solution, preferably a really good solution. The point of defining the design problem
is to start to move an indeterminate, open-ended problem towards being determinate and closedended; that is to actually begin to converge toward a solution. The skill in defining a design problem is
putting together a thorough set of information about the problem that both clearly defines the problem,
but also leaves open a wide variety of potential solutions. A skilled design engineer balances the
strategy of least commitment with the need for determinacy.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

77

1 - 47

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Testable
Read through your list of requirements again and make sure that they are testable. If you have general
functions, objectives, or constraints make sure they are decomposed (detailed out) into a set of more
specific statements that are testable.
For example, what does "user friendly'' really mean? To an experienced photographer this may mean
that it is easy to precisely set the shutter speed, focus and aperture on a camera. To a less-experienced
or casual user, it may mean that all the settings on the camera are automatic; they can just press a
button to get a good picture. There are no specific camera attributes that are denoted by the term "user
friendly", nor are there for any other design. The general objective "user friendly" would need to be
broken up into a set of specific measurable objectives to be useful. (see section on objective trees)
On the other hand, the statement "the design should be blue" is easily to determine. Blue is a specific
wavelength of light. It can be measured. Requirements should have obvious, realistic methods of being
tested. Some examples are shown in the table below.
Table 7. Examples of requirements that are well formulated (good) and poorly formulated {bad)
Good/bad

Example

Reason

Good

The exterior should be yellow.

The color can be seen to be either yellow (pass) or


some other color (fail)

Mediocre

The gl ue should hold the plastic

How well? Double sided tape will hold the parts

parts together.

together, but not as well as most plastic glues. This


statement doesn't give the engineer much to
measure in terms of performance .

Bad

The interface should be user-

Some people's user friendly is other people's boring

friendly

and other people's frustrating. There is no method of


measuring 'user friendly'. See the comments
preceding.

Good

The filter shall pass signals above 3

An engineer can run tests or simulations on the f ilter

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

78

1 - 48

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

KHz with under 2% attenuation

that will check to see if it meets these criteria.

and reduce all signals 2 KHz and


lower by at least 10 dB
Bad

The design should respond quickly

Is this seconds, milliseconds or nanoseconds? How


quick is quickly? This is not testable.

Bad

Good

The product should be light and

Light is a relative term. Portable just means movable.

portable

There is no clear pass or fail.

The battery must perform for a

There is a simple test to see if the device meets this

minimum of 5 days when device is

requirement. The engineer can run the device on

in standby mode.

standby for 5 days on a battery and test if the device


is still operable.

Good

The system should be down for no

While there is no sim pie test for this, there is a hard

more than 4 hours in a year.

target given. Careful failure analysis done using a


method agreeable to the client would be needed to
determine if the system met this requirement.

1.6.1.

Project scope

One outcome of defining the design problem is the setting of the project scope. The scope is the
definition of the breadth and depth of the problem you are proposing to solve. It defines the limits or
boundaries of the problem. This is why defining a design problem is sometimes called a seeping activity,
and in some industries the project requirements document is called a scoping document. It is important
to review the requirements list you have written and make sure that the team agrees on the scope;
what is within the scope of the project, and what is beyond the scope of the project. In industry you
would also want your client, manager and some of the other departments at the company (e.g.
marketing) to sign-off on the scope before proceeding. This can help to defend against scope creep.
Example: Your project requirements indicate that you will be developing a design that will take aerial
photographs at social events (link to case study). You have worked up a list of functions, objectives, and

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

79

1 - 49

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

constraints for this project. A device that wi ll work with a Canon EOS-5D camera equipped w ith a
variety of lenses is within the scope of this project. This is explicitly written into the requirements.
2

However, designing a device that must be capable of taking pictures that cover 750m is beyond the
scope of the project. The requirements written up for this project make it clear that you are intending
2

to design a device that reliably works up to 500m , but you are not promising to design a device that
reliable works for areas greater than 500m

The scope sets the expectations for the project.

1.6.2. Evaluating the problem

Once your team has def ined the design problem you should stop and ask yourself some questions that
will help you decide where to go next. Going back to The Sandbox, the office space of our fictional
design company, you have just spent a lot of time in the library gathering information and in the
boardroom talking to the client. You have also been out of the office observing users, and talking to
operators and stakeholders. Now you have a much more thorough understanding of the project.

Class room
(Tee h nica I Knowledge)

Infor mation desk

The Sandbox

Picture 11. The Sandbox: the office space for "Designing Engineers", a design company.

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

80

1 - 50

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Your team should spend some time in the project space discussing the problem before you proceed.
The natural tendency at this point is to want to start right in on solving the problem. But you w ill save
yoursel f enormous amounts of time, effort, and frustration if you first reflect on the problem you are
solving, and critically analyze the nature of the project.

1.

Is this a routine design problem?

Routine design means that there is a common ly accepted method for solving the problem. Routine
design problems occur frequently in industry. As you take more courses in your disci pline you w ill be
introduced to the routine design methods typical in your field. Examples of routine design: structural
design for routine bui ldings (heavily driven by the building code and standard practices), minor
modifications to an existing design, or algorithmic design (e.g. layout of a printed circuit board;
components entered and computer software does the layout for you which may require minor tweaking
after the software completes the job). link to routine design in Design and Critical Analysis
Techniques for more information on routine design.
2.

Is there an off-the-shelf solution, or components that could be used?

Custom Off-the-Shelf (COTS) means a component or item that is already in production and available for
sale or license. "Don't re-invent the wheel" is a common cliche, but it is really true in engineering
design. In examining your design problem you may find that there are elements of the design that can
be satisfied using off-the-shelf technology. It is worthwhile familiarizing yourself with commercial
materials and components (hardware and software) that could be useful in your project. link to
routine design in Design and Critical Analysis Techniques for more information on COTS.
3.

Is this project feasible?

Before proceeding you should do a quick feasibility check; basically a reality check. It is easy to
say,"Anything is possible", but it isn't. If there are serious feasibility issues with the f unctions, objectives
and constraints that have been specified then this needs to be brought to the attention of the client and
your managers. As you gain more experience as an engineer you will be able to provide expert advice to
your company and your clients about the feasibility of a project. As an engineering student you should
begin getting into the habit of assessing feasibility at every step in the design process. link to routine
design in Design and Critical Analysis Techniques> for more information on feasibility checking.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

81

1 - 51

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

4.

What parts ofthe problem are closed, and what parts are open?

Most complex engineering design problems w ill have parts are that closed and parts that are open
link to problem solving chapter. Closed problems have one correct answer, and the goal of solving
this type of problem is to f ind that one answer, or an approximate solution that is close enough to the
right answer. Open problems have many possible answers, none of which is exactly right, but some
possible answers are better and some are worse. At this point it is useful to reflect upon which parts of
your design problem can be easily tackled first because they are closed problems requiring direct
calculations or estimates, and which parts will require creative design. In many design projects there is
no point in starting on the creative part of the process before taking the time to work through some of
the preliminary calculations that are needed.
The closed parts are sections of the problem that require a straight forward calculation process, or

sizing. Sizing means doing a calculation to det ermine the capacity of the equipment or system needed
for the job. For example, suppose you are designing a ventilation system for a building. You will need to
estimate the volume of the building for this project so you can appropriately size the fans and other
equipment that will be part of the ventilation system. Calculating the volume of the building is a closedended problem; it should have a correct answer, even if you are just making an estimate which isn't
exact. Estimating the volume is one of the close-ended parts of this design problem. Deciding where
the ducting shou ld go, the types of equipment to use, balancing the trade-off between duct size and
noise, and other aspects of the solution are open-ended problems. There are many p ossible choices and
no definitive solution. Some choices yield a better solution and some choices will produce a solution
that isn't as good. Once you have designed the duct system {this usually requires iteration and other
procedures typical of an open-ended design process), and selected the air exchange rate, then sizing the
fans is a straight-forward close-ended calculation. link to problem solving chapter
As you reflect on the 4 preceding questions, document your thinking in your engineering notebook. You

may think of ideas that are not immediately usefu l at this stage of the process, but w ill become useful
later. Make sure you also have adequate discussion with your team about the design problem; this is
called group processing, and it is essential for good team performance. link to teamwork chapter

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

82

1 - 52

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

1.7.

Conclusion

After working through this chapter you should have at least a f irst draft of a problem statement and
requirements for your project (see below). You and your team should have learned much of what you
will need to know to solve the design problem, and should have identified any additional knowledge you
will need to learn. Defining the problem is an essential step in the design process and it is an iterative
exercise. You will continue to revisit this definition repeatedly as you work through t he project both to
update the requirements and to remind yourself about the problem you are working to solve. A well
written set of requirements will communicate to your manager and your client the goals and scope of
the project. If this is a project for one of your engineering courses, the requirements document will
demonstrate to your instructor that you understand the problem you are working to solve. It will tell
your instructor or client what they can expect from the solution you are creating, and what not to
expect. It will give you and them a way of measuring your success. The requirements wi ll help keep your
whole team, and other professionals that you are working with, on track.
1.7 .1. Leaving this stage of the process you should have:
A well written problem statement
A list of requirements
with supporting documentation (see note below*) and explanations:
Functions: a well organized list
Objectives: a tree and a prioritized list
Constraints: a list with supporting references
Supporting documentation and explanations for the requirements are typically included in the
design reports you prepare for your instructor (and manager and client).

For projects that have a known context:


A complete description of the service environment
A clear description of the users, operators and client for your project
A list ofthe known stakeholders and their interests
A list of the DFX considerations

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

83

1 - 53

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Every element in the context should include supporting documentation. This supporting
documentation is typically included in the design reports you prepare for your instructor (and
manager and client).

Reflection on the pro ject:


Comments on the balance bet ween strategy of least commitment and determinacy in t he
definition of the problem.
Ideas on testability of the requirements
Notes-to-self about the nature of the design problem: the feasibility, sub-problems that need to
be solved, off-the-shelf materials, etc.
Notes-to-self about further research that needs to be done on the problem to enhance the
solution generation process.
The reflection on the project is typically not included in design reports. It takes the form of notes in
your engineering notebook, or other team documentation to remind yourself of things that will be
important as you move through the process, and for when you re-visit the requirements and
problem statement.

"'Note: Supporting documentation means the evidence or information that you have gathered that
supports your ideas. The explanation is an explanation of your thinking process. The logical steps you
took to get from the information to your ideas, i.e. your requirements and conclusions about t he
context.

Learning Objectives:
By the end of this chapter you should be able to:
Recall and define the important terms introduced in this chapter
Explain the essential concepts in the chapter and how they are utilized in, or relate to, the
engineering design process
Analyze a client statement, design brief, or RFP
Develop a problem statement that describes the design need.
Develop a full set of requirements that define the design problem.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

84

1 - 54

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Utilize several creativity methods to develop a list of functions

Utilize the objective tree method to develop a list of objectives

Research common types of constraints to develop a list of constraints

Create a description ofthe service environment in all aspects that are relevant to the
project.

Describe the characteristics of the users, operators and client that are relevant to the
project.

Explain the stakeholders and list their interests

Identify DFX considerations that are of particular importance in this project

Combine the requirements into a complete definition of the problem that demonstrates
understanding, identifies knowledge that needs to be learned, and defines t he scope.
Explain how to check the design problem for feasibility and identify if there are routine or offthe-shelf solutions that may be applicable.
We hope this chapter will enhance:
Your ability to document design problems such that you can explain and discuss them with
others
Your knowledge of how you incorporate new information into your work to enhance the quality
of your requirements documentation.
Your awareness of the responsibility our profession has to consider multiple perspectives in our
design work

Key Terms:
Problem statement

Constraints

Project requirements

Service Environment

Design brief

Users

Goals

Operators

Solution driven

St akeholders

Means

DFX (Design for X)

Solution independent

Iterative

Indeterminate

Primary functions

Ill-structured

Secondary functions

Ill- posed

Functional decomposition

Functions

Task analysis

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

85

1 - 55

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Use cases

Criteria

Means statement

Obj ective goals

Objectives

Prototype

Objective tree

Regulations

How-why tree

Standards

Codes

Virtual environment

Due diligence

Benchmarking

Stakeholder interest

Non-governmental organization (NGO)

Scope creep

Strategy of least commitment

Scope

Off-the-shelf

Routine design

Reality check

Intellectual property

Closed problem

Design review

Open problem

Sizing

Group processing

Pairwise comparison

List of Pictures:

1. A cartoon of the inventor of the bicycle helmet for a cat, or some other fairly useless invention.
2.

Example of separating out every part of a client statement for analysis.

3.

Moving from a client statement to project requirements

4.

Engineer in a disorganized work space looking aimless, and an engineering team in an organized
work space looking focused.

5.

The requirements are developed based on the problem statement; the document at ion of the
context in which the design will operate; and critical thinking by the design team.

6.

{a) and (b): Schematic which depicts the role of functions in the design process.

7.

A keyless bike lock. A person pointing a remote control at a bike locked to a bike st and or using
their cell phone to unlock the bike.

8.

An island with hills and valleys and the engineering team is surveying the island (i.e. mapping it).

9.

Picture of t he page from Maegan's notebook showing an objective t ree for the aerial
photography project.

10. Example of one piece of a how-why tree.


11. Picture of a business team asking quest ions such as "how are we going to make a prof it this
year?" and " why are we developing a new marketing campaign?".

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

86

1 - 56

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

12. Show the island again with areas fenced off and skull and crossbone signs, or "danger do not
enter" signs in the fenced off areas.
13. cartoon of a family leaving the house. Parent says " let's go get dinner" . Each person leaves the
house prepared for a different activity: one with a picnic basket, one dressed up for a nice
restaurant, one prepared to pick vegetables from a garden, etc. Caption: If t he goal of the
project isn't clearly stated, the team may not all be working toward the same target.
14. Diagram of the service environment for a marine buoy.
15. Someone trying to plug in a device such as a "camping TV" where there is no outlet available.
(box for the device says "use it anywhere, no additional equipment needed!" and has a picture
on the side showing a family enjoying a tv show next to their tent)
16. Photo of a "you must be this tall to go on this ride" sign.

References
[1) C.L. Dym and P. Little, Engineering Design: A Project-Based Introduction, 3rd Edition. Hoboken, NJ:
Wiley & Sons, Inc., 2009.
[2) P.H. Roe, G.N. Soulis and V.K. Handa, The discipline of design. Boston, MA: Allyn and Bacon, 1967.
[3) 2009 ASHRAE Handbook- Fundamentals, American Society of Heating, Refrigerating and AirConditioning Engineers, Inc., Knovel Publishing, 2009.
[4) Environment Canada (2011, May), National Climate Data and Information Archive. [Online) Accessed
August 21, 2011. Available: http://www.climate.weat heroffice.gc.ca/Welcome e.html
[5) K. Vicente, The Human Factor: Revolutionizing the Way We Live with Technology.. Toronto: Vintage
Canada, 2004.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

87

1 - 57

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Chapter 2: Generating Solutions for the Design Problem


Table of Contents for this chapter

2.1.

Introduction
2.1.1.
Building towards opt imal design
2.1.2.
Starting with a wel l-defined problem
2.1.3.
Building Skills in Solution Generation
2.2.
The State of the Art
2.2.1.
Finding the State-of-the-art
2.2.2.
Benchmarking: Reverse Engineering
2.2.3.
Prior Art in other domains
2.2.4.
Document what you learn
2.3.
Generating Design Solutions
2.3.1.
Functional and Structural Decomposition
2.3.2.
Putting the pieces together - morphological charts
2.4.
Techniques for enhancing your creative powers
2.4.1.
Brainstorming: Design thinking as a group exercise.
2.4.2.
Lateral Thinking
2.4.3.
Analogy
SCAMPER
2.4.4.
2.4.5.
A few other strategies
2.5.
The value of experience
2.6.
Reflection For Reducing and Checking Solutions
2.7.
Conclusions
2.7.1.
Leaving this stage of the process you should have:
2.8.
Learning Objectives
2.9.
List of Key Terms in t his chapter
2.10.
A Practice Challenge for Advanced Design Thinkers: Folding paper package inserts

2.1.

Introduction

Once the design problem is defined in sufficient detail (see chapter 1), the engineer can begin to
generate ideas for designs that satisfy the requirements. This is the heart of the design process, and for
many design engineers, it is also the fun part. It is a divergent process, where the design space is
deliberately expanded to provide the widest possible spectrum of solutions from which to choose. The
word "creativity" conj ures up images of artists and poets, but the invention of new and diverse ideas to
solve an engineering problem is very much a creative endeavour. In this chapter, we will discuss the
means by which engineers create solutions to both routine and innovative design challenges. We will
also discuss the importance of gathering information on existing designs, processes, materials, systems,
and components that may be of use in the design.
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

88

2-1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

The process of generating creative design solutions is fundamentally different than the familiar process
of findi ng a solution to a closed-ended analytica l problem. In a typical engineering exam question in a
university course, the goal is to understand the given problem, recall the pertinent equations (which
represent physical relationships), and to transform the given information into the required solution
using these equations. Such problems almost always have single correct solutions. A design problem is
characterized by many possible solutions, and a talented designer is one who develops the skill of
finding the optimal solution. It would be unusual if this were the first and only solution developed, so a
key to the process is an ability to generate many different solutions so that the optimal one can be
chosen. This is referred to as "populating the design space".

The Design Space


The design space is an abstract multi-dimensional space that encompasses all of the design solution
ideas that are being considered. Generating new solution ideas populates the space. Discarding ideas,
i.e. removing ideas from consideration, shrinks the design space.

Some people seem to be naturally gifted at developing creative solutions; Thomas Edison registered a
total of more than 1000 patents, including patents on improved incandescent light bulbs, and the first
sound recording and reproduction device, "the phonograph" [1). While very few people match the
creative genius of Edison, anyone can learn a few techniques and modes of thinking that improve their
odds of finding good or even optimal solutions to design problems.
Design solutions are generated with three levels of detail: the conceptual design, the embodiment
design, and the f inal design. In this chapter we will focus on generating good preliminary ideas and
generating a conceptual design based on these. This is a critical part of the design process. While
decisions made later on can cause a design to fail in service, it is often the early decisions that determine
how successful the design will be. The embodiment and f inal design stages involve making the basic
concept into a rea lity by choosing specific configurations, components and materials. These will be
discussed in Chapter 4.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

89

2-2

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

2.1.1.

Building towards optimal design

The purpose of generating lots of creative design solutions is to populate the design space and to ensure
that the optimal solution is found. In the next chapter, we will discuss the process of selecting the best
solution in great detail, but an understanding of what you are after will help streamline the process.
Engineers use the word "optima l" to denote a solution that is closest to ideal, given the circumstances
and the technologies available. There is no delusion that a perfect solution will be found, because it is
not likely to exist. If you have to solve a problem here and now, you cannot wait around for the best
solution that will ever exist. You must use technology that is available or can be invented now.
However you should take the time to select from the options available, rather than just picking
whatever is most obvious.
An optimal solution:
Meets functions: Does what it is supposed to do. Otherwise, it is not a solution at all.
Meets constraints: Meets all of the non-negotiable restrictions. Otherwise it is an unacceptable
solution.
Maximizes the objectives: It is as safe as possible, as cheap as possible, as durable as possible,
etc. where each objective carries a relative importance or weight.
Is feasible: It will be possible to implement. Doesn't violate laws of nature or practical
limitations on materials or processes.
Is comprehensive: Deals with all possible DFX considerations. Does not overlook anything
important, even issues that were not part ofthe original design brief, and properly incorporates
the concerns of all stakeholders.
Is as simple as possible: The design should be simple in implementation and use, not necessarily
in concept.

The last point is critical, and more difficult to i nternalize than the first five, but it is the key to really good
design. It is based on the premise that thinking is cheap, while implementation is expensive, so you
want to focus your energy and effort as ear ly as possible in the process to creating a simple, elegant
solution. In other words, you want the design to be as simple to build and operate as possible even if it
is harder to develop the design in the first place.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

90

2-3

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

2.1.2.

Starting with a well-defined problem

Chapter 1 provided a discussion of the process of creating a problem statement and requirements. It is
critical that you have the functions, objectives, and constraints determined before embarking on the
solution generation process. If you are asked to design a warehouse, for example, but you don't know
the constraints imposed by the fire code and building code in advance, it is possible t hat you will design
something that cannot be legally built. Similarly, if you are designing an automobile engine, you must
account for the fact that the oil needs to be checked and changed regularly. Otherwise, you might not
make these things easy to do, resulting in a very poor design.
Of course, the process of design is iterative. New considerations might come up during the process of
developing a solution for a problem, and the definition of the problem might need to be modified. Your
goal, as always, is to anticipate as much as possible by fully thinking through the problem, no matter
what stage of the development process you are in. Three areas are worth special attention.

1.

Consider the list of stakeholders you developed. Does your work on solutions reveal additional
stakeholders? Does it indicate interactions with the design that you hadn't already considered?

2.

Consider each of the DFX topics. Do the solutions you come up with reveal new information
about the applicability of these to your design problem?

3.

Consider the functions. Do the solutions reveal any unintended functions that may lead to
misuse or failure of the design?

Figure: Picture of a bicycle stand being used as a hitching post for a dog (or horse).

2.1.3.

Building Skills in Solution Generation

Can you learn to be more creative; to generate lots of creative and diverse solutions to a problem? Yes !
Most people, when faced with a design problem, immediately begin to dream up solutions. Weak
designers go with one of their first ideas and develop it without fully considering the alternatives.
Strong designers recognize that there are likely to be many solutions and that they w ill have to work
hard and use some structured thinking to generate a complete set of feasible solutions from which to
choose. Even very experienced, successful professional designers regularly use formal methods for idea
generation. In the remainder of this chapter, we will discuss the techniques used by strong designers.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

91

2-4

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Invention versus Design

Invention is the process of solving a problem i n a new way that would not be obvious to engineers
practic ing in the field. It is important to understand, however, that engineering design is often of a more
routine nature. The design of a ventilation system for a factory f loor is the work of an engineer, but this
doesn't mean that new types of air moving equipment are designed as part of this exercise. Instead, the
engineer consults code books to determine what the suitable airflows are, goes to the equipment
suppliers to find commercially available fans and ducting, and puts it all together to do the job. It is
engineering design because it is a technical j ob, and relies on the designer's knowledge of basic math
science and the technologies of heating/ventilation.
Because we are focusing on teaching design f rom first principles, much ofthis chapter focuses on
innovative design. However, the basic techniques of structured thinking introduced here can also be
applied to more routine design, which of course, can be done well or poorly, depending on the
knowledge, diligence and creativity of the designer. Engineers should aspire to good design, regardless
of how much true innovation is involved.

As solutions to the problem are generated, the engineer will often evaluate the ideas; quick evaluations

against some of the requirements, or more detailed evaluations in other cases. These evaluations can be
done formally or informally. More formal methods for evaluation are the subject of t he next chapter.
These evaluations will suggest new ideas, and may also cause the designer to revisit the requirements;
some o f these may be impossible to meet, for example. This iterative process is inherent in all complex
design exercises in the real world.
The dotted line " B" in Figure 1 shows a typical time in the design process, with requirements generation,
solution generation and evaluation occurring simultaneously. Of course these activities would not be
done actually simultaneously, but the iterative cycles between them could be quite short. Only towards
the end of the design period would formal work be done as the activities were dealt with for the last
t ime. Of particular interest is that time shown at dotted line "A", where the Problem Statement is being
generated, and the engineer is already thinking about some potential solutions, and doing some

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

92

2-5

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

prelimi nary cursory, often mental evaluations,, These are necessary for generating a good problem
stat ement, and for generating good requirements.

I
I

Solution Generation 1
I

....

OJ

cQD

v;
OJ

Cl

Time

Figure 1. Typical design activities over time in the real world. Note that this process is not accurately

2.2.

The State of the Art

As engineers, we want to do things as efficiently as possible. This includes the design process itself, so it
is important for engineers to know about existing solutions to all or part of the design problem. The
sum total of the existing knowledge is referred to as the state of the art. The common expression is
" don't reinvent the wheel".
There is some debate about the best t iming of a review of the literature and other sources of
information. You could argue that it is inefficient to generate design solutions that are already well
known by others. The design process can be difficult and t ime consuming, and since modern search
tools make it very easy to find information, why wouldn't you review the state of the art first?
The counter argument is that t he creativity process may be hindered by preconceived ideas based on
existing solutions to similar problems. As evidence of this, we observe that true innovation often comes

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

93

2-6

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

from outside an existing industry. For example, an outsider, James Dyson, invented a household
vacuum cleaner based on cyclones rather than the bags or f ilters used by the established vacuum
industry [2]. The design engineers working for the big vacuum companies did not develop this idea,
even though product innovation was their daily job. Apparently, the new design was extremely good:
Sir James Dyson manufactured and sold enough vacuums to become a billionaire [3].
Picture of a Dyson vacuum
Whether or not you should consult the literatu re before developing your own ideas depends on your
mental discipline. If you are able to recognize that there are many possible alternatives for most design
problems, and you are prepared to search for these in a systematic way, then you can save time by first
reviewi ng the state of the art. Novice designers without this discipline or experience might well benefit
from some blue sky thinking about the problem before doing the necessary homework. Searching for
existing solutions is a mandatory part of any design process, but the t iming should be chosen
strategically.

2.2.1.

Finding the State-of-the-art

To find out what is already known, you need to know where to look. The state-of-the-art is the sum
total of all information relevant to the design challenge at hand. This may take the form of commercial
products or services, patents, standard industry practices and codes, and the personal knowledge of
experienced engineers in the field.
Searches should always start with the most general sources, and then drill down to more and more
detail and specificity. If your task is to design a new filtering sequence in a chemical plant, you do not
start w ith a detailed scientific reference on the effect of pore size on membrane efficiency. Instead, you
would begin by using a general reference, such as an encyclopaedia article on filtration. If you are
working in an engineering firm, you might try to find a knowledgeable senior engineer to chat with
initially, just to get a feel for the general area. Talking to people is a very important part of information
searching. As you build up expertise of your own, you would move to more and more detailed and
specific sources of information.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

94

2-7

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Here is. a simple bullet list of some places you may wish to look for printed literature and a suggested
order (from general to more specific). If you are already familiar with the general details concerning
your design, it may be appropriate to start part way down the list. link to information gathering for
more information.
Technical Dictionaries
Encyclopedias
Handbooks

Increasing specif icity

Textbooks
Review Articles
Professional Journal Articles
Technical Journal Articles
Patents
Manufacturers Information
Brochures
Catalogues
Figure 2: Search priority when researching a design using printed material.
Note also that many industries in engineering have their own publications (magazines and handbooks)
which are often published by professional trade organizations (IEEE, ASME, CSME, AIChe, etc.). These
are usually available from libraries or can be borrowed from professionals in the field.
2.2.2.

Benchmarking: Reverse Engineering

A survey of existing designs is a crit ical part of investigating the state of the art. The process of
dissecting and understanding an existing design is known as benchmarking or reverse engineering. If
you want to design a new hair dryer, it would obviously be very instructive to buy a few of the better
ones already on the market and to disassemble them to discover how they are designed. It might even
be a good idea to buy some bad ones to find out what is wrong with them. Reverse engineering is
common practice in large industries such as the automotive and home appliance industries. link to
Design and Critical Analysis Techniques for more information.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

95

2-8

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

2.2.3.

Prior Art in other domains

It is worthwhile spending some effort to think about where you might f ind relevant background
information, aside f rom the obvious places. In particular, it is important to recognize that prior art may
not be restricted to the area of application of the current design. In other words, it is a good idea to
design your search !
For example, suppose you have to design a nozzle for a high-pressure steam jet to be used to remove
unwanted deposits inside an industrial furnace. You could reverse engineer all existing products, and
you could also find texts and articles on high-pressure nozzles used in the industry. But what if you
spent a moment to think about other types of high-speed airflow? Where should you look? Have other
engineers worked on this? The answer is yes: Sir Frank Whipple spent a great deal oftime on highspeed flow when he was designing the original jet engine in the 1930's and 40's. In fact, modern jet
engines have very efficient " nozzles" to direct high-velocity air in one direction. The high-efficiency
nozzles now widely used in industrial boilers in the pulp and paper industry are based on these
principles.

2.2.4.

Document what you learn

As you gather information it is very important to not only record the information, but to also record the

source of the information. Do not simply cut-and-paste material from the internet into a file to keep for
use later . You will eventually need to explain the information in your own words, so it is good to make
your own notes as you find information. If you don't understand the material well enough to rewrite it
in your own words, you shouldn't be using it in a document all ! Make sure that as you take notes on the
information from an information source you also write down, absolutely accurately, the citation

information for the source so you can properly cite the ideas when you use them in your design reports
and other documentation. Never concoct citation information. link to Documenting the Process

Figu re 3: Picture of US Patent 5553778 which improved the efficiency of high pressure steam nozzles
used in pulp and paper furnaces, resu lting in huge energy savings to the industry. Copied from the U.S.
Patent database.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

96

2-9

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

2.3.

Generating Design Solutions

You are already familiar with the most widely used method for finding creative solutions to a design
problem: just thinking about it. If you are presented with a design challenge, you are probably quite
capable of coming up with a variety of feasible solutions. But are you capable of coming up with the
optimal solution? Adding some discipline and strategies to your thinking can greatly enhance your
engineering creativity and chances of success.
The most important step you can take in your quest to think like a designer is to separate the process of
idea generation from the process of idea selection. Undisciplined thinkers perform these two processes
simultaneously. To illustrate this, let's recap the design brief from one of the case studies in this text: A
wedding photographer wants to distinguish herself from her competitors by offering aerial shots of the
bridal party and all the guests at a wedding in an open space. To do this, she needs to be able to lift her
2

camera to be able to get a wide angle shot (50m to 500m

).

She wants a solution that is inexpensive,

reliable, easy to operate in all sorts of weather, and portable so that she can carry it with her in her midsized car.
What is going on in your head as you read this problem? If you are like most creative engineers, you are
already spinning ideas: a telescoping pole, a helium balloon, and so on. You are also evaluating these
ideas as they occur to you. If you thought of a camera suspended from a helium balloon, you might
immediately spot the problems associated with this solution: What if it is windy? How does the
photographer control the motion? You may quickly discard this idea and never follow it up.

It is impossible to do a proper evaluation of an engineering solution in the few seconds that you allowed

for this task. This is where structured design t hinking differs from novice practice. While doing
prelimi nary design thinking, your job is to try to think of as many solutions to the general problem to be
solved as possible, without judging their value or even their feasibility! Give it a try for our wedding
photographer. Can you come up with ten or more solutions in two minutes?
Here's our quick list-- hidden until you click on it
Telescoping pole
Trained eagle or humming bird
Trained giraffe
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

97

2-10

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Powerf ul pogo stick


Hot air or helium balloon
Remote control helicopter or plane
Kite
Gyro stabilized toss
Anti-Gravity Machine
Stilts for photographer
Huge periscope
Magnetic levitation
Suspend on column of compressed air
Portable jet pack.
Parachute (either for you or j ust the camera)
Use an existing tree or building
And so on ...
Some of the ideas in this list are silly. Does a photographer really want to train and care for an eagle or
giraffe just to take photos? Some ideas are even impossible. The engineer is not going to find a way to
overcome gravity just to satisfy the needs of a wedding photographer. However, at this stage, you are
just generating ideas, not f iltering them . Even if eagles won't work, you may be able to combine parts of
many poor ideas to create good ones. For example, the telescoping pole is a likely solution, but perhaps
you should combine it with a gyro stabilizer to maintain a particular camera orientation. Perhaps you
could use a remote control (from the airplane) to control the camera. And so on... If you reject any of
the solutions through quick analysis, you also lose the possibility of combining and adapting them to find
a reasonable, possible optimal solution that you did not initially think of.
This exercise illustrates some general rules for disciplined design thinking. A variation of these was
described by Osborn for brainstorming (4] link to creativity methods:
Generate ideas but do not f ilter or judge them .
Try to generate lots of ideas, and don't worry about their quality.
Try to generate ideas that are widely different, not j ust variations on a theme.
Don't add constraints to your thinking. Don't worry about affordability, safety, or even
feasibility.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

98

2-11

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Record your ideas as they come to you.


You should end up with a long list of ideas, only some of which would fully satisfy the functions
objectives and constraints. When you move to a formal decision process, which will be introduced in
the next chapter, you will be comparing ideas that are feasible and do meet the constraints to find out
which of these best satisfies the various objectives set out in the problem definition. Hence it is
necessary to do some further work on the idea set now: There is no need to include the trained giraffe
in the f ormal decision process, but you also do not want to reject the idea at this early stage. After the
initial list-building exercise is well and truly exhausted, you would combine elements, examine the
nonsense answers to see if anything useful can be extracted from them, and generally try to build a few
more realistic design alternatives from which to choose.
You might want to go through this process several t imes, as you discover new areas ifor ideas while
working with the older ideas. The idea generation process will inevitably continue even as you move
toward converging on a single solution that w ill be implemented. This is the reality of the design
process.
Of course, like any activity that has commercial and practical significance, there have been many books,
articles and software programs written to promote and facilitate creative idea generation . Some useful
references are provided in the bibliography for this chapter. In the remainder of this chapter we will
briefly discuss some of the methods that are widely used in professional engineering design for creative
solution generation. A more complete description of each method, how to use it, and its strengths and
shortcomings can be found in the Creativity Methods section link to Creativity Methods. These
methods are not only used for generating creative solutions to the design problem, but can also be used
for other parts of the design process for example, generating the design requirements.
When you think you are ready, try our design cha llenge case studies at the end of the chapter.

2.3.1.

Functional and Structural Decomposit ion

Unfortunately, complex problems can overload our ability to generate comprehensive solutions. In our
wedding photographer example, you are simultaneously thinking about many different parts of the

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

99

2-12

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

problem, and trying to come up with an integrated solution all at once. Then we suggested that you
could combine various features of the differing solutions that you came up with.
You can do this process more efficiently by breaking the challenge into smaller parts before you start
looking for a solution. After the problem is decomposed you can then generate solution ideas for each
of the structural or functional elements. This produces a much wider range of ideas than you could
produce by considering the whole system all at once. Also, by disassociating each element from the
overall system you remove mental blocks or filters that might impede your thinking. You are better able
to divorce a single element from any preconceived notion you have about what the whole system
should be like, and consider a wider range of ideas.

Structural decomposition divides the problem up into the various structural elements, which are
discrete units in space. In our example, you would have the camera, the elevation device, and the
camera/photographer interface.

human interface
handle

electrical supply

power
conversion
device (motor)
Vacuum Cleaner
filtering device

dust and dirt


storage

friction reducing
means (wheels)

Fig. 4: Structural Decomposition of a vacuum cleaner.

Functional decomposition divides the problem up into its functional units, and this approach is generally
more useful than trying to solve the problem as a whole. You need to control the camera. You need to
aim the camera, provide a vertical force on the camera, stabilize the camera, and so on. A vacuum
cleaner needs to suck air and dirt from the ground, separate the air and dirt, store the dirt, exhaust the
air, and so on. By separating the various sub-f unctions, you can focus your attention on small subsets of

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

100

2-13

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

the problem, and examine these subsets at their most basic level. Let's work on the vacuum cleaner,
and focus on the key problem of separating dirt from air:

Figure 5: Two versions of t he functional decomposition for the function: "Separate dirt from air"
In Fig 5 a) a few different ways to separate dirt from air are identified. Until about 1990, the household
vacuum industry was entirely focussed on the use of a f ilt er medium. Vacuums all used bags or porous
filter plates. (A third method would be to pass the air through a loose medium such as sand. This is
used for swimming pool filters, but there are obvious problems in applying this to household vacuums.)
However, there are many other suggestions here. You could put the dirty air in a lar ge tower, and wait
for the dirt to settle out while removing clean air from the t op. Not very practical for a portable
vacuum cleaner that must be small and light, but this principle is used in large settling ponds created to
treat liquid wast e. You could speed up the settling process with a centrif uge. Or you could speed it up
using a cyclone, where air is impelled at high velocity around a cylinder or cone, and dirt is forced t o the
periphery and drops to the bottom. You coul d charge the particles with ions, and then get them to stick
to charged plates. You could blast the air against a piece of adhesive tape. And you could combine
these methods.
An even more fundamental way of doing t he functional decomposit ion in t his case is to think oft he
different types of forces that need to be applied to a particle of dirt to get it to move in a different

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

101

2 - 14

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

direction to the surrounding air, which is the heart of the problem. In Fig 5. b you may realize that we
missed the possibility of a magnetic force on our f irst pass through. Unfortunately, this is only going to
be helpful if you are vacuuming up iron f ilings in a steel mill but remember, you are j ust generating ideas
at th is point, so don't filter them. (No pun intended!)
As we mentioned earlier, James Dyson became a billionaire by realizing that there were other

possibilities for separating dirt from air in a household vacuum besides filtration. His two-stage cylone
system can spin cigarette smoke out of the air, and since there is no bag to become clogged, the
efficiency of the vacuum remains high all the time. Interestingly, this particular system has been
criticized for its design with respect to another functionality: removing the dirt from the machine.
Functional decomposition works well. However, even if you now believe that, it turns out to be
amazingly difficult to consistently use this met hod. You need to practice - take every day objects and
systems see if you can break them down and redesign the key element.
What are the main sub functions of :
a coffeemaker?
a public transport system?
the book stacks in the library?
a submarine sandwich shop?
an ATM system
hair dye

When you think you are ready, try our design challenge case studies at the end of the chapter.
2.3.2.

Putting the pieces together- morphological charts

A morphological chart is a simple graphical representation of the process of putting ideas together to
make some realistic integrated solutions for the whole problem. We have discussed the merits of
decomposition, but if you develop solution ideas for the individual sub-systems in your design then you
will need to build integrated solutions from the various pieces.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

102

2-15

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

In a morphological chart, or morph chart as it is commonly known, row headers represent the subfunctions, and columns containing means of accomplishing those (in no particular order). An integrated
design is represented by a "path" through all sub-functions from top to bottom.
For our wedding photographer, the chart might look like this.

Means

Means

Means

Elevate Camera

Means
Toss

Stabilize Camera

Small aperature -

Control Focus

Control Shutter

Trained spider
monkey

Fig. 6: Two different paths through the sub-functions are shown, each representing a complete solution
to the design problem. These are the solutions used for comparison in the evaluation of design
alternatives discussed in Chapter 3.
You can see that in fact there are a vast number of unique potential paths through the morph chart.
Each path is a unique solution to the problem. As a first step in eva luation, you will probably want to
pare these combinations to a manageable number before any detailed evaluation takes place.

2.4.

Techniques for enhancing vour creative oowers

Even naturally creative thinkers turn to tools and techniques to enhance their productivity. In this
section, we'll outline a few methods that have been developed for "forcing" creativity. These methods
are useful when you are stuck, but also as a set of standard tools to ensure that you have f ully populated
the design space. You can force yourself to generate new possibilities by deliberately employing
techniques such as SCAMPER and Synectics, even for problems that you feel you have " solved"
adequately. A truly innovative designer lives by the motto "There is always a better way." This is
obvious in everyday life as the systems and products available improve over t ime.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

103

2 - 16

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

All of these techniques are related. They are intended to force you to disrupt your pattern of thinking to
open up the possibility of new ideas. By trying them, you can learn to be more creative in your
engineering design work. Naturally creative people are most likely people who do some of these things
naturally!
2.4.1.

Brainstorming: Design thinking as a group exercise.

We introduced brainstorming earlier in this chapter. The term brainstorming is usually used to describe
the process in which a group of people have an intensive collaborative session of idea generation. The
concept was formalized by an advertising executive, Alex Osborn, and became widely used in the 1950's.
Osborn proposed rules for brainstorming to improve the effectiveness of the process, and much
research has been done on this idea generation method. link to creativity methods
The Creativity Methods section explains two different brainstorming techniques (free and structured
brainstorming) in more detail. link to Creativity Methods If your team is using brainstorming for
generating design solutions, requirements, or any other ideas, read through the section first so you get
the most out of the brainstorming work you do.
When conducting a session, it is useful to observe Osborn's rules; encouraging quantity, building on the
ideas of others and suppressing criticism. If you are running a face-to-face session production blocking
is likely to be an issue. For undergraduate design teams we recommend structured brainstorming
which helps to combat production blocking. Brainstorming should be one of the methods you use for
idea generation, but you should use more than just brainstorming.
2.4.2.

Lateral Thinking

Edward de Bono is a creativity guru who coined the term Lateral Thinking in 1967 [5]. The underlying
motivation for latera l thinking is summed up nicely in this quote: "You cannot dig a hole in a different
place by digging the same hole deeper"(6]. Thinking about a problem when you already have a solution
in mind is like standing in a hole with a shovel. The temptation is to keep digging down! This is why we
suggested that novice designers think of some ideas before reviewing the state-of-the-art since the
state-of-the-art is nothing more than a hole dug for you by someone else. Lateral thinking refers to the
process of jumping out of the hole you are in. The emphasis of latera l thinking is on creativity and the
generation of ideas. In the design context this corresponds closely to the divergent, creative solution
generation we talk about in this chapter .
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

104

2-17

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

De Bono presents a number of techniques for stimulating lateral thinking. Just a few are presented here.
Challenge assumptions: assumptions t hat are generally accepted may not be right, merely
passed on from person to person. "What if you don't need a filter to separate dirt from air?"
Asking " Why, why, why?" A child sometimes asks "Why?" over and over again. Doing this as an
adult can help you challenge your assumptions.
o

Why do people use money to buy things? Why do people carry several different credit
cards? Why doesn't the debit or credit card machine just know who someone is?

Why are drink bottles cylindrical?

Why can people make fuel f rom corn (ethanol) but not from other plants, like grass
{hay)?

Reversal method: reverse the direction or sequence of things. The reversal may not lead to a
valid solution, but will stimulate divergent thinking.
Random stimulation: Seeking some random word or idea and incorporating i t in your line of
thinking. What if your solution had to include a monkey? A brick? A triangle? Music?

2.4.3. Analogy
Analogy is a powerful inventive tool in which solutions to similar problems in other fields are used. It
has been discussed by De Bono and many others. In the section on reviewing the state-of-the-art, we
have already described a technical analogy: a technical solution to a different, but related problem. To
use a technical analogy, you must ask the question: "What other technical problems are similar to the
current problem, and how were they solved?"
Another type of analogy that has become an important field of academic and industrial research is the
analogy to the living world. The process of ad apting the solutions of the biological world to engineering
design problems is called biomimetics. It is based on the knowledge that evolution has, in many cases,
produced highly optimized solutions for problems similar to those that must also be solved by engineers
for manmade objects and systems. To make use of the biological analogy, you must simply ask: "How
does nat ure solve t his problem."

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

105

2 - 18

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Synectics is related to design by analogy. Synectics uses symbolic or fantastical analogy to develop
creative solutions. For example, there is an idiom "something is steady as a rock". In this idiom a rock is
used to symbolize the concept of "steady" . What features of a rock make it steady? Could you use
these same features to steady some ot her device, system, or technology?
link to Creat ivity Methods for more information on design by analogy and synectics.

2.4.4. SCAMPER
SCAMPER is an acronym proposed by Robert Eberle to trigger novel design ideas [7]. It is based on a
more detailed set of techniques discussed by Osborn.
SCAMPER stands for (Adapted from [7]):

S ubstitute: Remove one part or f unction and substitute something else in its place.
Combine: Replace two or more parts of a system with one.
A dapt: Find existing things that can be adapted to your needs
M odify: Change part of the design in some way.
P ut to other uses: Use components for other than their primary f unction
Eliminate: Remove a component and work around this loss.
R earrange: Rearrange the relative location or sequence of things in space or t ime.
SCAMPER can be used as a set of creativity cue cards, to help you generate new ideas when you are
stuck.

Additional techniques are discussed in the Creativity Methods section. link to creativity

methods

2.4.5. A few other strategies


Here are some other basic strategies used by professional designers when they are trying to generate
ideas:
Be a bit crazy, off-the-wal l, and absurd . Think about solutions to the problem that are not
feasible or practical- skyhooks, teleportation, thousands of insect slaves. Suspend judgement.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

106

2-19

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Be skeptical w henever anyone makes a statement about the project. Is the statement always
true? Can you think of any circumstance or part solution that will do the opposite of the
statement?
Remove the possibi lity of the standard solution. You need to t ie a horse to a tree, but can't use
the standard solution; a rope. How do you then solve the problem?
If one or more of the design conditions seems to be a sticking point, throw it or them out and
create solutions for the remaining problem. Then try to adapt the your ideas to cover the
removed conditions.
Understand, tolerate and encourage a ll of these behaviours in your teammat es.

2.5.

The value of experience

To be an effective designer, in addition to being creative, an engineer must have a broad knowledge
base. If you were the most experienced design engineer in the world, and you already knew all of the
ways in which various functions had been accomplished in the past you would obviously be in a superior
position when faced with a new problem. For example, if you need to create a system to raise a heavy
load using human power it is helpful to know all of the ways of obtaining mechanical advantage: levers,
pulleys, gears, wedges, hydraulics, pneumatics, toggles, and screws cans all be used to lift a car to
change a t ire. If you need to grease the wheels on a conveyer system in a high temperature f urnace, it
is useful to know that conventional petroleum greases will vaporize, but graphite powder can lubricate
witho ut melting.
In the appendices we provide some basic engineering resources to summarize some of this knowledge,
but unfortunately, there is just no substitute for paying attention and constantly learning. An
engineering undergraduate degree is a start, but the accumulation of technical knowledge is a lifetime
activity.

Dean Kamen, the famous inventor of the Segway self -balancing personal transporter, was the founder of
DEKA, which employees many engineers. Candidates for engineering jobs at DEKA were interviewed
with sim ple engineering questions to test their knowledge base and ability to apply it creatively: One

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

107

2 - 20

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

such question: " If you drink a soda with two hundred calories, how many stairs will it allow you to
climb." [8]

2.6.

Reflection For Reducing and Checking Solutions

Before moving on to formal concept evaluation you will need to perform a preliminary assessment of
the many design ideas your team has generated. Even for a fairly simple problem you could have
generated dozens of potential solutions. For complex problems you may have huge numbers of
variations based on a decomposition exercise. You want to reduce the numbers by removing potential
solutions that were helpful in brainstorming, but are not likely to be feasible (remember the giraffe??).
You also may have concepts that need f urther exploration.
There are two steps to the preliminary evaluation stage:

1.

Remove infeasible ideas: Go through your list of potential solutions. Remove the giraffes and
other ideas that show no promise as being optimal. Review the obj ectives list you have in your
requirements. Take out solutions that are obviously inferior to other ideas on all objectives.
Remove ideas that do not fulf ill the goal of the proj ect and could not be extended to do so in any
reasonable way. Remove magic ideas, i.e. ideas t hat defy physical laws of the universe.

2.

Look for ideas that require further exploration before deciding whether to keep them, or discard
them. These are ideas that contain a basic concept or concepts that you are not sure about, or
that you think may require some investigation. An inventive idea, even slightly outside the norm,
may contain untested science or t echnology or combinations of these. For example, you may
know how to make a power supply for a certain power. You may know how to make a power
supply of a certain size. Can you make one (or find one for sale) that has the power and size you
need? You might not be sure. You need to check this before keeping a solution that requires this
type of power supply.

To deal with this second step, the following techniques are available:

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

108

2 . 21

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Estimation: This is not guessing, but a developed engineering skill. It will allow you to produce quantities

with accuracy enough to make decisions. link to Design and Critical Analysis Techniques and link to
Estimation chapter
Modeling and Simulation: You can model the idea with appropriate mathematical models, or you can

often use specific computer models directed at the work you are doing. Some of these computer models
allow simulation, that is a model of the idea that wi ll show the effects of t ime. link to Design and
Critical Analysis Techniques
Prototyping: Often it is more revealing to produce a reduced version ofthe idea. This prototype will

often omit some (or many) of the characteristics of a final design, but will allow insights into the
characteristics that put the design choice under question. For instance, a smaller model of a car can be
tested in a wind tunnel for air resistance, and a mock-up of a user-interface can be tested for
completeness and for ease of use. link to Design and Critical Analysis Techniques
See Decision Making Tools for more infor mation on evaluation methods.
Creating a simple, effective model or prototype can help you quickly assess whether a design idea will be
feasible. Your team will continue to create more detailed models and prototypes as the design process
progresses, each one more completely approaching the characteristics of t he final design solution.
These models are a tool for thinking through and examining the way the actual design will work in
practice. As you test your model or prototype make sure that you document your observations and use
this activity as an opportunity to refine your ideas about the design problem.

2.7.

Conclusions

Invention and innovative design are the cornerstones of economic growth, and are important to both
companies and society as a whole. As a result, there have been massive amounts of research on the
process of creativity itself resulting in hundreds of books and research papers. There are also software
packages designed to facilitate brainstorming and other creative activities such as TRIZ link to
creativity methods. All of this work is based on the idea that creativity in design can be taught and
enhanced.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

109

2 - 22

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

In this chapter, we have described some structured thinking methods that can be used to increase your
ability to solve innovative design problems, and a more complete description ofthese techniques can be
found i n the Creativity Methods section. Simply thinking about a problem (or brainstorming) is a good
start, but is insufficient. It is often very helpful to decompose a problem into smaller pieces, derive a
variety of solutions for each piece, and then to build some integrated solutions using combinations of
these. When no ideas are f lowing, specific creativity initiators like SCAMPER or analogy can help to kick
start the creativity process. It is critical to recognize that the solution generation phase is one in which
you must withhold j udgement and try to generate as many ideas as possible, to increase your odds of
finding an optimal solution.
Insert Linus Pauling quote here: ...
To learn to be more creative and innovative, you must practice the techniques described here as well as
others that you learn through further reading. You can make such practice part of your daily activities by
looking at the designed systems and objects around you, deconstructing them (in your mind only please)
and searching for better means of accomplishing the same functions. This is how successful inventors
view the world every day. When they see shortcomings in the designed or natura l world, they imagine
new ways of overcoming these.
If a 100 million people worked on finding a new solution to a common problem, then even inconsistent
and unstructured thinking would eventually produce good answers. But if you, just one person, want
consistently good results, you need to work hard to develop your skills in this area.

2.7 .1.

Leaving this stage of the process you should have:

A long list of design solution ideas


And documentation of your idea generation activities:
Documentation of the creativity methods your team used to generate solutions
A much longer list ofthat includes all of the ideas you generated
Documentation of the preliminary evaluation methods you used to decrease the much longer
list down to a long, manageable list that you will evaluate further. This includes brief supporting
explanations (reasons) of why you discarded the ideas that you did.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

110

2. 23

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

2.8.

Learning Objectives

By the end of this chapter you should be able to:


Effectively look for existing solutions t o a design problem.
Document the state-of-the-art
Distinguish between conventional and innovative design
Apply a variety of techniques to generate creative solutions
Use lateral thinking methods to motivate new directions of creative thought
Explain the role of estimation, modeli ng, and prototyping in the iterative design process

2.9.

List of Key Terms in this chapter

Design space

Optimal solution

Unintended functions

Invention

Routine design

State-of-the-art

Blue sky thinking

Benchmarking

Reverse engineering

Citation information

Source

Brainstorming

Structural decomposit ion

Functional decomposition

Morphological chart (morph chart)

SCAMPER

Synectics

Production blocking

Lateral thinking

Technical analogy

biomimetics

Biological analogy

Estimat ion

Modeling

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

111

2 - 24

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Simulation

Prototyping

2.10. A Practice Challenge for Advanced Design Thinkers: Folding paper


package inserts
A small company needs to fold small pieces of paper into three panels, like a standard C-folded
brochu re. (See Fig. 1) The 100 mm x 75 mm paper instructions will be inserted in a package measuring
just 100 mm x 25 mm, and the printers have told the company that they cannot supply tri-folded
versions. Currently, it takes an employee several hours to manually fold 1000 package inserts that the
company needs each day.
Your job is to produce a conceptual design of an inexpensive machine or apparatus that will make it as
easy as possible for the company to fold 1000 sheets of paper (100 x 25 mm) into three panels.

Figure 1: Folding Challenge


This is an unusual design challenge. In this case, there is an unambiguous, unique solution that is vastly
superior to all the other possibilities. Can you find it? Follow the steps below to see if you benefit from
structure in your thinking. Don't try to look up a commercial solution, even though you might start this
way in a real-world situation.
Stop reading, pull out a blank sheet of paper, and spend 15 - 30 minutes thinking about
solutions to the problem. This t ime will be well worth the investment. Stop reading now.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

112

2-25

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

How far did you get? If you are like most novices, you will have immediately thought about some
version of the hand folding action, in which you use your fingers to bend each side panel over the center
panel and crease once you have it lined up. Mechanically, you could accomplish this by having rollers
feed the sheet under a 25 mm wide plate, then have two flaps on hinges swing 180 degrees to fold the
side panels over. See Fig. 2.
You might have recognized that a machine is not absolutely necessary. An intermediate solution would
be to build a "creasing machine" with two pizza-wheels spaced 25 mm apart to create creases that make
the hand folding process easier. See Fig. 3.
How did you approach the problem? If you are like most novices, you just "went for it " and started
sketchi ng solutions on a blank piece of paper right away. It is hard to avoid, since ideas come to you
even before you have finished reading the problem. Inexperienced designers take their first idea,
inevitably a variation on hand folding, and work at trying to mechanize it. This solution is based on a
very simple conceptual design - replication of the manual action. It is simple in concept (after all, it only
took you 10 seconds to come up with it!), but not in implementation or use. The final machine will have
lots of moving parts, electronic position sensors and a control system, and will be prone to jamming.
You want the opposite - conceptually complex if necessary, but operationally simple! Thinking is cheap.
Building, using, maintaining and repairing are expensive.
Let's try to do better by brainstorming. Come up with as many ways of solving the problem as possible.
Perhaps you could flip some functions around . How would you solve the problem if the paper moves
but the folding elements are f ixed?

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

113

2-26

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Figure 4: Belt Sander Folder


In Fig. 4, a slight improvement over basic hand folding is presented. Here we have combined the
creasing wheels with a set of fixed guides that fold the flaps as the paper moves with the moving rubber
belt. To implement this, a table-top belt sander was adapted by slowing the motor and substituting in a
rubber belt. Flat paper is fed f rom the right . The design works, but the output is a pile that has to be
stacked by hand. You can do better.
It turns out that free brainstorming just isn't good enough here. Instead, we will try to break t he
problem into more pieces using a functional decomposition. Take a new sheet of paper and do a
functional decomposition of the folding problem. Start with a stack of unfolded paper, and produce a
stack of folded inserts ready for the package. Take 10 minutes, and when you are done, turn the page.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

114

2 - 27

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

In this analysis, we have broken the overall process into 5 basic steps. As an example, we have
expanded the feed f unction with four basic means. Next, spend 10 minutes to come up with means of
implementing the other functions. "Creasing:' is the same as "scoring" and means "to create a line
where the fold will preferentially occur". "Double" is the action of folding over, so that the paper
moves f rom occupying a single plane to occupying stacked planes. Spend some t ime finding different
ways o f doing this.
How did you do? Did you find multiple ways of accomplishing each ofthe subfunctions? Did you notice
that it is easier to brainstorm solutions for small subfunctions than it is to work on the whole problem at
once?
For this problem, the key to the optimal solution is in the doubling. It is the folding flaps that create
mechan ical complexity in the original solution. To do away with these, we need to fi nd other ways of
doubling paper or making it move out of plane. Think about this for a few minutes. Break it down into
the fundamenta l forces that need to be applied to make a sheet of paper move out of its own plane.
Find two distinct alternatives before moving on.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

115

2 - 28

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

If you have been playing

you realize that there are basically two types of forces that can be

applied to double a sheet of paper: transverse forces, normal to the plane of the sheet, or in-plane
forces, causing the sheet to buckle. A third type of force, twisting forces, are not usef ul, but commercial
folders. make use of both in-plane and transverse forces. Our first solution involved transverse forces
applied by the f laps. How else could a normal force be applied?
This line of thought is interesting - and leads to a commercial knife folder. Instead of applying a
transverse force to the flap, you can apply it to the center of a sheet. By driving the sheet into a slot,
we could produce a fold. Better still, as illustrated below, the knife can be used to feed the sheet into a
running roll nip, which applies pressure as well.
As you can see from the diagram below, a knife folder is mechanically quite simple, although we have to
find a way to coordinate the movement of the knife with the position of the paper, which will require
some electronic sensors. Knife folders are used to package pharmaceutical impacts, which have to be
folded in two perpendicular director.
How could you build a folder based on buckling. Think it through for a few minutes.

To buckle a sheet of paper, we need to apply an in-plane compressive force. This could be done by
moving the two sides of the sheet towards each other. Or, we could simply hold one side of the sheet
against a stop, and move the other one towards it. This is simpler because it reduces the number of
parts. If we grab the buckled sheet with a roll nip (as in the knife folder), we are almost there.

Figure 6 depicts a commercial buckle folder. It is compact, robust, and incredibly simple to adj ust. It
rarely jams, and has no electronics. In action, it is almost magical: flat sheets are fed in at high speed,
and emerge folded in three in a fraction of section. Find a video on the internet to see for yourself or
click here.
Even if you are not fascinated by the simple elegance of the buckle folder, you must appreciate how
unlikely it would be for you to arrive at this solution by f ree brainstorming. There is also another lesson

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

116

2 - 29

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

here. Buckle folders date back to the mid-1800's. If this was a real job, and you didn't review the stateof-the-art early on in the process, your design process would not be efficient or perhaps even successful.

References

[1] http:Uwww.uspto.gov/news/pr/2002/02-13.jsp, Accessed August 14, 2011.


[2] Dyson, James, "Against the Odds, An autobiography", New York, Texere, 2003.
[3] http:Uwww.forbes.com/profile/james-dyson, Accessed August 12, 2011.
[4] Osborn, Alex, "Applied Imagination 3'd Ed.", New York, Charles Scribner's Sons, 1963
[5] De Bono, Edward, "The use of lateral thinking", London, Cape, 1970, 1967.
[6] http://www.edwdebono.com/lateral.htm, accessed July 13, 2011.
[7] R. Eberle, "SCAMPER: Games for Imagination Development", D.O.K. Press, Buffalo, NY 1990
[8] Kemper, S., "Reinventing the Wheel", HarperBusiness, New York, 2005, pp. 42.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

117

2-30

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Chapter 3: Concept Evaluation and Selection


Table of Contents for this chapter

3.1.

3.2.
3.3.

3.41.

3.5.
3.6.
3.7.
3.8.

3.1.

Introduction
3.1.1.
What you come to this process with
3.1.2.
Goal of the evaluation and selection process
3.1.3.
Inside the Evaluation and Selection Process
Stages of Evaluation
Step 1: Evaluating individual solutions
3.3.1.
Problem - No Proposed Solution passes Step 1
3.3.2.
Problem - Few Proposed Solutions pass step 1
Step 2: Comparit ive Evaluations
3.4.1.
Getting the Measures and Weightings
3.4.2.
Choosing Techniques for Solution Comparison and Selection
Evaluation possibi lities
3.4.3.
3.4.4.
Adjustments
Step 3: Reflection
Conclusion
3.6.1.
Leaving this stage of the process you should have:
Learning Objectives
List of Key Terms in this chapter

Introduction

In the evaluation and selection process yo u will examine pot ential solutions and det ermine their
suitability and relative merit. This is done by evaluating these potential solutions and comparing
the resu lts to the project requirements and to the results of other potential solutions. You will
use this process to determine which solution to move fo rward to detailed design and
implementation.
You can and should visit the evaluation and selection process many times. You generate
solutions and bring them into the testing area, leaving again to adj ust solutions and to generate
more solutions, then come back again. Ultimately you will leave the testing area with one
solution (usually). You can visit this process formally or informally, but it should be done
formally at least once at the t ime you select the solution that you will use in detail design and
implementation. Of the three major areas of work, requirement generation, solution generation
and solution selection, it should be t he last area visited before you proceed to f inal detailing and
implementation of the design.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

118

3-1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

3.1.1. What you come to this process with


You enter this process with the following:
A set of well constructed requirements.
A list of potential solutions. Ideally, many diverse potential solutions. These could be
solutions to the whole problem, or part of the problem. These potential solutions
should have enough detail such that implementation methods seem within the realm of
current practice, although it may require some extensions of current practice. This
means there are no "magic" in the solutions on your list, although there can be methods
that require analysis to determine if they actually will perform as required.

Magic solutions
Suppose your project includes the requirement to count red blood cells in a blood sample. A
sol ution with "magic" in it might say "somehow this device w ill do the red blood cell count" or
"red blood cells will be counted by getting the red blood cells to count off'.

Picture of red blood cells counting off


A potential solution without magic might be "the device will force the samples through
microchannels in a plastic substrate where a camera mounted on a microscope will relay a video
picture to a processor that wil l recognize and count the red blood cells." This method may or
may not work as described, but it is at least one possible idea that employees realistic
technology. Hopefully there would be several other non-magic solution ideas on your list.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

119

3-2

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Earlier you generated the the project requirements; your goa ls for the project. Your goals
should be solid at this point. These are your ultimate target and every decision you make during
this process will ref lect this. If the target is wrong, your analyses will be incorrect.
You may perform the evaluation and selection process with only one or a few potential
sol utions. This can be important as a test and generator of your project requirements, and to
test your selection methods. However, ultimately it is very important to explore the design

space well in the solution generation and evaluation processes. You do not want to miss good
potential solutions because you were trying to be quick, or you too quickly closed your mind
because you have a solution idea that you think "works".
However, if you found that there is a "standard solution" for your problem, then you do not
want to spend an undo amount of time, effort and f inances exploring ideas that w ill ultimately
be unused. Standard solutions are standar d because time and experience has determined that
they are frequently the best solutions for a given set of circumstances. link to routine design
in !Design and Critical Analysis Techniques Why might a standard solution not be correct?
Either the situation is not what the standard solution was designed for OR new technologies and
techniques have made the standard solution inferior to new solutions. It is always worth
spending some time in generation and evaluation, even ifthe standard solution is selected. If
nothing else, imagine the embarrassment and loss of credibility that would come if, after you'd
committed to another solution, a faster, simpler, less-costly solution was suggest ed (or worse,
used by the competition!).

3.1.2.

Goal of the evaluation and selection process

You exit the evaluation and selection process in one of three ways.

1.

One solution. If you feel you have generated an adequate set of solutions, have a
comprehensive set of requirements and have selected the optimal solution for these
requirements, then you can proceed to detailed design and implementation of the solution.

2.

No solution. None of the solution ideas you have generated will work or will meet the
requirements to an adequate degree. You need to decide if you can generate additional

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

120

3-3

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

solutions, change the requirements, or if you have exhausted the possibilities and should
terminate the proj ect.
3. You leave to revisit the solution generation process. This is actually the most usual result .
You may have eliminated some of the inferior, unsalvageable potential solutions. You take
with you the information you generated by eva luating some of the potential solutions. This
information may be essential for
Adjusting and combining the solution ideas to generate new, better solutions.
Adjusting and adding to the requi rements based on discoveries during the evaluations.
Often you will f ind that small adj ustments and additions are needed in the earlier work
on the requirements, and sometimes your discussions of potential solutions with the
client will reveal new f unctions and remove others.
Normally you will exit through choice 1 once, with the f inal design solution, but through choice 3
many t imes before t hat. When you leave this process for the last time you have selected the
sol ution you will work w ith.

Evaluation
and Selection

Results:
Evaluation of the alternatives
-against the requirements
- relative to each ot her

Process
3. Return to designing

Reflect
Check
Critique

1. Opt imal solution identified;


Ready to move to implementation?

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

121

2. No solut ion found


-Terminat e project?
-or ret urn to design process?

3 -4

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

The next steps, of detai led design and of implementation are very costly and take a considerable
amount of t ime. If you choose a solution that proves overly difficult or does not meet the goal
and proj ect requirements, you will have major problems to deal with.
Imagine it like a walk in the woods, as shown below. You are at an early stage in t he walk. Taking
an incorrect path means going considerably out of your way and having to come back almost to
your starting point when your mistake is discovered. Taking the wrong fork later on the trip will
only result in a small diversion, which is much more easily corrected.

A walk in the woods ....

3.1.3.

Inside the Evaluation and Selection Process

What is done inside the evaluation and selection process is conceptually fairly simple. The
potential solutions are compared to the f unctions, constraints and objectives, and to each other,
and (in the end) the best potential solution is selected. This is animated in Figure 1.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

122

3-5

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Figure 3. Selecting the Best Potential Solution [animated]

The evaluation ofthe potential solutions has two steps. The first is an evaluation against
functions and constraints, and against practical implementation limits. The functional boundary
is represented by the green line, and the constraint boundary is represented by the blue line in
the figure above. Any solution that falls outside the green boundary or the blue boundary is
discarded because it does not meet minimum requirements. The second step is an evaluation
against the objectives; at this stage you will compare the potential solutions against each other
to see which potential solution is closest to ideal.

3.2.

Stages of Evaluation

When you were generating solutions it was important not to evaluate the potential solutions
too closely and too soon. This allowed a wide range of potential solutions. It helped you to fully
populate the design space with a wide range of ideas that could inspire other ideas. Now you
need to change your perspective; you must judge your ideas.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

123

3-6

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

There are 3 steps in the evaluation stage:


Step 1: In the first step you will j udge each individual design idea against t he functions and
constraints in your requirements.
Step 2: In the second step you will use the objectives you developed to compare the design
ideas against each other and select the idea that best fits the objectives, i.e. t he optimal
solution
Step 3: In the third step you will reflect on your selected idea and the selection process. Does it
make sense? Are you happy with the selected solution? What questions need to be
answered about this solution before you can proceed to the next stage of t he process?
At each step you may need to stop the evaluation process and iterate: either to f urther develop
the requirements, or to generate more or better potential solutions.

3.3.

Steo 1: Evaluating individual solutions

To proceed to detailed design and implementation, a solution must conform to the required
functions and constraints, or must be adjusted so it conforms to these requirements. Each
potential solution (design idea) is compared against the function and constraint requirements.
Those that fit the functions and constraints will be kept and moved on to step 2. Those that fail
this step are discarded.
To accomplish step 1, each potential design must be well enough described that the design and
implementation can be evaluated. Any undetailed parts of the solution must be straightforward, standard practice or purchasable parts. For example, in the design of a new gasoline
engine, a solution may call for an "electronic ignition timing system" to determine when the
spark plugs will ignite the air/fuel mixture. This t iming is determined from the state of the
cylinder (the container) where the fuel is burned, the speed of the engine, the air/fuel mixture
and the static and dynamic characteristics of the engine.
When this design is refined, it could result in several proposed solutions for the electronic
ign1ition t iming system, for example: dedicated discrete electronics, a dedicated m icroprocessor,

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

124

3-7

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

a part of the processing time of another m icroprocessor or programmable hardware cell arrays
(called FPGAs), or a mechanical system. The proposed design solutions must be refined to this
level, because we must be able to determine if they are adequate (fast enough, temperature
tolerant enough, and so on) and whether they are feasible (are FPGAs made large enough to
perform this job for instance

).

In summary, for each proposed design idea, we determine:

1. Does it meet the functions? (will it be able to meet the timing limits required to run the
engine timing?)
2.

Does it meet the constraints? (will it allow the engine to satisfy government regulations
concerning pollutants result ing from ignition?)

3.

Is it feasible? In other words: Does current available technology exist to implement this
solution? (if we choose the FPGA, will there be enough logic on the circu its available to
form the circuits required in this problem7

Any proposed solutions that do not satisfy these basic evaluations are considered for
adjustments, as shown in Figure 1. If no adjustments are possible to make the solution work,
the solution is discarded.

All potential solutions

New Solution

No

Modify
solution if
possible

Discard

Figure xxxxx. " Must Satisfy" Evaluations: A potential solution must meet the functions and
constraints requirements, and be feasible, in order to move on to the next evaluation step.

1
2

And they are, by large margins.


FYI: Not true of early FPGAs, now easily w ithin t he scope of existing FPGAs.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

125

3-8

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Example: Modifying a design idea to move it inside the constraint boundary


Design for cutting fabric into custom shapes.
Suppose a cutting machine is proposed as a solution. The design fails a safety constraint as first
proposed, because there is a possibi lity t hat the operator could contact the cutting blade and be
inj ured. The proposal could be adjusted by adding an operator guard to the design. In this way
the design can be adj usted so that it meets the safety constraint. The increased costs and
complexity caused by the guard would be included in the design solution during the next steps
in evaluation.

Feasibility check
There are key points in the design process when you should perform a feasibility check; the
preliminary evaluation step is one of those points. Check your proposed solutions that meet the
function and constraint criteria to decide if these proposed solutions are also feasible.
There are many reasons a design solution could be infeasible; the three most common are
physical issues, ethical or legal issues, and economic issues. The section on feasibility and reality
checks in Design and Critical Analysis Techniques section has more information on this t opic.
link to Design and Critical Analysis Techniques
First, the project may be physically impossible. It is surprising how often engineers propose
designs that are physically impossible. It i s just very easy to imagine systems that seem like they
should work, but don't. So before you waste a lot of time t rying to design something that
violates the laws of physics, do a quick check to see if the requirements are feasible in this
respect.
Second, a proposed solution may be ethically or legally unworkable. As a person you are
required to act within the law, and as an engineer you are bound by a code of ethics. This is true
whether you are licensed as a professional engineer or not. Therefore it is worth examining the
sol utions you have proposed at this point t o see if there are ethical or legal issues that should
cause a solution to be discarded .

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

126

3 -9

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Thi rd, a proposed solution may be economically unworkable, or may be infeasible in the given
timeline. This is a very common situation. Think through a basic cost estimate and estimate an
implementation t imeline. Do you think the proposed solution will come in on t ime and on
budget? Or is it very unlikely that this idea, or a variation of this idea, will be feasible in terms of
economics and implementation time?
At this point; remove any infeasible design ideas from the list of proposed solutions or find a
way to modify the idea to make it feasible.

Example: removing a potential idea from consideration


Aer ial-view Camera Device
At the first level of eva luation, the team looks at the solution "bird with camera attached". They
quickly estimate the size of bird required t o hoist a photographer's camera, the advanced
training, the adverse temperature and weather conditions and the maintenance required for the
solution. The conclusion is that the potential solution is not feasible.

3.3.1.

Problem - No Proposed Solution passes Step 1

Sometimes none of your proposed solutions will pass the f irst step; that is none of the ideas are
feasible and satisfy t he functions and constraints. The estimated cost of the completed project
could be excessive, or the computing requirements beyond p resent technologies, or the time to
finish the project is unacceptable.
If the design team has spent considerable amounts of t ime looking at alternative solutions then
the project may have to be cancelled, but the following steps should be explored first:
Revisit idea generation. Now that you have had the experience of evaluating some ideas
against the functions and constraints perhaps you can use this experience to inspire new

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

127

3 - 10

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

ideas that avoid the problems encountered with your previous ideas (e.g. how can I avoid
this constraint?). See the H-1 Hawaii interstate case study for an example of this.
Talk to the client about relaxing or changing the functions or constraints. Possibly bring
solutions that almost but don't quite meet the existing requirements to the meeting with
the client. Shown them that a solution is close, but just outside the existing bounds. Be
prepared to back up your claims with a logical, well documented analysis of the situation.

3.3.2.

Problem - Few Proposed Solutions pass step 1

When selection is being done, having only a few proposed solutions is often an indicator that
ll. Adequate work was not done at the requirements or idea generation steps. Ideally you
want lots of ideas coming out of step 1.
2.

This is a highly constrained problem; possibly a routine design problem. You may want to
look for an off-the-shelf solution. However, this approach will short circuit the creative
aspect of the process, so you should probably try re-examining the requirements and idea
generation steps first. Make sure you have not unnecessarily constrained the design, and
make sure you have fully populated the design space.

It is sometimes worthwhile to evaluate a short list of prelimary solutions to understand the


problem more clearly. But in design projects having only one or a couple of solutions on your
list should be considered an indicator that more t ime needs to be spent in requirements and
solution generation.

3.4.

Step 2: Comparitive Evaluations

Proposed solutions that meet the feasibility, functions and constraints of the project can now be
compared against each other. This is done using the full set of objectives: the solution that best
fits the objectives, is the best solution.
Not all objectives will be met or maximized by any particular solution. The best solution is not an
ideal solution. There will be "trade-offs", and we will introduce methods to compare and

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

128

3-11

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

balance the choices. For example, consider choosing a material, such as a particular type of
metal, for a project; which metal is best depends on the situation. Steel is inexpensive, hard and
reacts to acid. Gold is expensive, soft and doesn't react with mi ld acids. Steel, protected by
pai nt, is a good choice for an automobile body . Gold is a good choice for switch contacts and
caps on teeth. Gold cars and steel teeth fillings would not be a good choice. However, there are
trade-offs. Steel rusts which is a problem for automobiles particularly in wet, salty conditions.
Generally no solution will work perfectly, it is up to the engineer to balance the trade-offs.
At the last pass through the process this step should result in the one (or more) proposed
sol utions to undergo detailed design and implementation.

All potential solutions

New Solution

No

Modify
solution if
possible

Discard

Compare to objectives

Determine best idea

Figure 4 Using Objectives to Compare Solutions

3.4.1.

Getting the Measures and Weightings

Comparing proposed solutions against each other requires that you have methods for
measuring the solutions with respect to each of the objectives. It should be clear at this point
why it is important to develop good project requirements and good objectives in particular.
Poorly formulated requirements are difficult to use for evaluation. It is hard to compare

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

129

3-12

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

sol utions against each other in relation to a vague objective. Well developed requirements will
have clear methods that can be used to generate the comparative measures needed for
assessment. Your objectives should also be prioritized; you should have a clear understanding
of which objectives are most important. You will use this information in the decision making
process.
Some objectives will be simple to measure. Size and weight, for example, are generally simple to
determine (depending on the accuracy required). Others, like reliability, may take more analysis
to determine. Any objectives, like "fun to drive", which are poorly formulated as engineering
measures are difficult or impractical to evaluate properly (leave this one for the people in the
Marketing Department who know how to run focus groups).
It is often useful to distribute the potential solutions among team members to further develop
and research. This will often reveal strengths and weaknesses in the idea that were not
immediately evident. As a byproduct of the exercise, it will get the team member(s) thinking in
a more concentrated way about the genera I methodology, which will he I p later during the
production of additional solutions. Concentrate on the key objectives when investigating each
design.
Important here are techniques for estimation link to chapter on estimation. You need not
determine exact values, particularly before detailed design is done. And at this stage developing
very accurate values is not time efficient. You should determine values to an accuracy and
confidence level that allows you to differentiate between various proposed solutions, which is
good enough for now. In the aerial photography example we did not do detailed analysis, only
enough analysis to differentiate the proposed solutions. <<link to case studies>> This inexact
analysis means any numerical results are also inexact and results should be critically considered
as a result. For example, suppose you find that the estimated weight of one solution is 3.2 kg
and the estimated weight of another is 3.5, is the f irst solution idea really lighter? Or is the
margin of error on your estimates such that effectively these two solutions are basically the
same in terms of weight? Probably, given the level of detail of your solutions at this stage and
your experience level, you should conclude that these solutions are basically equivalent in terms
of weight. A -10% difference in the results of an estimate is not sufficient to draw a definitive
conclusion. link to the Estimation chapter

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

130

3-13

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

1.

By design: If the design must be f lorescent orange, any proposed solution will have this
as part of the specification. This is a quick yes/no evaluation, in this case of color. (there
are actually industry standards for color, e.g. the International Color Consortium and ISO

15076-1:2005)
2.

By estimation: The weight of a proposed solution, for example, can be estimated by


summing the weights of the heaviest components, and adding some estimate of the rest
of the components. You can also estimate other quantities such as volume, distance,

cost, or energy requirements this way.


3.

By analytic or computer model: Mathematical models or computer ana lyses can be


used to determine measures -lift of an airplane wing for instance, stress on a
component, mixing of fluids, or volume of traffic that can be handled on a roadway.

4.

By prototyping: Building a small or full-sized model of part or all of the design will help
determine some of the measures we are unable to determine reasonably otherwise.
This is called a prototype. For more information on modeling and prototyping see
Design and Critical Analysis Techniques. link to Design and Critical Analysis Techniques
section

Note that some of these tools were also discussed in the previous chapter. In the previous
chapter the tools were used to check for basic feasibility or potential improvements to proposed
solutions. Now these tools are being used to compare solutions against each other. This will
probably require more accurate information gathered through estimation, modelling, or
prototyping.
In addition to the four methods we have listed here for determining engineering measures,
there are also a wide variety of methods that are used by other professionals for evaluating
suitablilty of a design solution. For example, many design companies will employ social
scientists (or hire specialized consulting companies) to run focus groups, do user or customer
surveys, or do other types of psychological testing o r branding work to determine the suitability
of a design solution. They may also hire business consultants, legal experts, and other
professionals to evaluate the feasibility of a design idea in greater detail before committing to a
sol ution. These other avenues of evaluation are not generally done by engineers, nor are you

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

131

3 - 14

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

generally expected to do these types of measures for an undergraduate design project.


However, it is useful to be aware that people from other professions will often be working with,
and sometimes on, engineering design teams. As an engineer, you need to be able to
communicate effectively with these other professionals and factor their opinions and results
into the design process.

3.4.2.

Choosing Techniques for Solution Comparison and Selection

At this point you should have enough information about each design alternative to eva luate
each idea with respect to the key objectives. In this section we wi ll consider the techniques that
can be used to compare the various proposed solutions against one another. Note that the
Decision Making Tools chapter describes these techniques for selection in greater detail. Link
to Decision Tools
Choosing a specific method depending on the problem at hand, and specifically
The time and resources needed to do any particular evaluation versus the time and
resources available. Very detailed evaluations will take time, and may not be justified.
The cost of a design failure. Sometimes the cost of a design failure is very low. If the
design fails, there is little impact on people (welfare, economics, or otherwise). Other
times the cost of failure is high: One would not want to f ind out that a bridge structure
was inadequate after a major bridge was built! A high cost of failure justifys spending
more t ime and resources on evaluation.
The likelihood of design failure. If this is a design problem that requires a risky solution,
then more effort should go into the evaluation stage before preceding to
implementation.
In terms of comparing solutions, there are many possible decision making methods to choose
from. We have provided a short list of techniques which are explained in greater detail in the
Decision Making Tools section. link to Decision Making Tools
Team based methods such as voting, and consensus
Pairwise comparison
Graphical decision chart

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

132

3-15

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Pugh matrix
Weighted matrix
You should turn to the Decision Making Tools chapter to see examples of the various
techniques, learn about the strengths and weaknesses of each method.
We suggest that you actually use several of these methods in concert to narrow the design
space (i.e. select a design idea for further work). This is because some of these methods (such

as multi-voting) work best for choosing a long list of design ideas from a much longer list of
design ideas, i.e. a first coarse selection process. Whereas others, such as a Pugh or weighted
matrix method, are better suited to worki ng with a shorter list of possibilities that require finer
differentiation. So if you are starting with a very good, long list of potential design solutions,
then we would suggest:

1. Use multi-voting to get your list down to a long, but more managible number of ideas
2. Use a graphical decision chart method next, particularly if your requirements have two
competing, important objectives that stand out from the other objectives.
3. Use a Pugh or Weighted decision matrix to differentiate amongst the remaining solution
ideas.
This may be more methods than are really needed for a design project in engineering school,
but it will give you experience working with the different methods. Make sure that you
document the decision making processes you use, in addition to the results, so you can explain
to your instructor (or client) how you decided which solution is the best, or optimal, solution.

Teams
When a decision has to be made, it is important that there is general agreement from your team
at least as to the process. This means that your team supports the evaluation process that is
being used. It is also important to have general buy-in on the design solution that will be move
forward to the detailed design and implementation phase. You may disagree wit h some parts,
or aspects, of the solution, but the whole team has to be willing to put in the work it is going to
take to detail out the design. This is difficult if people don't support the decision process or

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

133

3-16

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

result. Your team should have decided how decisions would be handled during the team
formation phase. link to Working in Teams chapter

3.4.3.

Modifications

Each time you visit the process of evaluation and selection you will increase the knowledge you
have of the design project. Often you will want to revisit your project requirements because of
new knowledge, and similarly you will often revisit the generation of proposed solutions, even
fleetingly, to make adjustments to solutions to make them feasible or better.
For example, you might realize that solutions are being generated that will result in hazards for
the operator of the technology you are designing. If operator safety is not explicit in your project
requirements, you might want to add these to your requirements. Similarly, a proposed design
that results in operator hazard may be adj usted to remove or guard against the hazard that will
increase operator safety and make the adjusted design better.
Your list of requirements should be complete. However, there are some objectives that are
often missed the f irst time through by novice design teams, or which do not come to light until
the evaluation stage. While not exhaustive, the following is a list of some attributes of the
design that might be evaluated, and that could greatly differentiate the potential solutions. You
should make sure all of these have been considered as you perform your evaluations. Many of
these are considered as "Design for X" possibilities.
1)

Installation and Training- designs often will need to be installed and operators trained.
These aspects should be evaluated for each potential solution in these cases.

2)

Maintenance- where a design must be maintained, this should be evaluated for each
design. Some designs will have reduced maintenance and, where maintenance is done,
some designs will offer easier access to areas requiring maintenance, less frequent
maintenance schedules, and less costly maintenance cycles.

3)

Breakdown I Repair- when breakage could occur there are two problems that should be
checked for each proposed solution: What damage will be caused by the breakdown and

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

134

3-17

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

what will be involved to effect the repair. Many of the concerns for making the repair are
similar to those for maintenance.
4)

COTS- This is commercial or custom off-the-shelf. It refers to those proposed designs that
use only parts, components and other facilities that are readily available. A version of this is
"design by inventory", which means you try to make your design from parts your company
already uses and resources your company already owns or obtains for other projects. link
to Design and Critical Analysis Techniques

5)

Measures against use cases - If you developed use cases or task analyses dur ing the design
process it is useful to work through them using each of your proposed solutions. This may
reveal deficiencies or advantages in each that was not initially apparent. link to Design
and Critical Analysis Techniques

If any of these issues seem to apply to your project, make sure they are reflected in the project
requirements. This is also a good time to have your client involved. You have just spent t ime
weighting objectives and looking at potential solutions. Your client may see things differently
than you do - attributes you saw as important could be less so to the client and similarly
attributes you do not think are important could be quite important to the client. Now is the time
to discover and to clarify these issues.

Put worked aerial photography example here- objectives and proposed solutions. This is
expected to be LARGE.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

135

3-18

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

3.5.

Step 3: Reflection

The methods in the last step will result in a proposed solution determined to be "best" among

those generated. It is very important that the engineering team pause at this stage and refl ect
carefully upon the selected solution. The final phrase of the last sentence emphasizes this- this
" best" solution may not be the best you can do. It might not be the optimal solution. Here are
some considerations:
The comparative evaluation methods have subjective elements in them. Does your team
have a bias towards a particular design that may be unfounded?
Does the chosen solution seem to cost more than it should?
Does the chosen solut ion seem to be less safe than it should be?
Was there enough range in the design space to explore a significant variety of options,
or were the differences between design ideas almost too small to matter ?
Was the final choice almost arbitrary? Could more analysis help the team make a better
informed and supported choice?
Does the final choice truly " make sense" for the situation, or does it seem like the
proj ect is being recast to fit the design that the team likes best?
Is the choice being made to be expedient, and is this a good decision?3
Often asking questions such as these will prevent a costly mistaken choice being made. As you
think through these reflection questions, document your thoughts in your notebook and discuss
these questions with your team. Your team needs to decide whether to go back to add to the
requirements, or explore more design solutions, or whether you have reached a sufficiently
solid solution decision and can move on to detailing and implementing the design.

In some situat ions, such as emergency response to a natural disaster, finishing a project quickly can take
precedence over ot her factors. Design t ime is part of the t ime-to-finish. In most cases however, engineers
want to be careful before continuing t o t he next stages of the design process.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

136

3 - 19

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

New Solut ion

All potential solutions

No

Modify
solution if
possible

Discard

Look for more solutions


& re-evaluate

Figure 5. The reflection step: Happy?

3.6.

Conclusion

In this chapter we have looked at evaluating potential solutions in order to reduce the number
to one solution or a few solutions that can be moved forward with into detailed design and
execution. We have examined specific techniques for doing this and the pitfalls associat ed with
those techniques. Most significantly, we have looked at the importance to the entire project of
doing this process well.

3.6.1.

Leaving this stage of the process you should have:

A decision a bout what to do next:


Eit her one solution (or a couple variations) t hat your team will work on further to det ail
and implement

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

137

3 - 20

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Or a decision to revisit one of the ot her design process stages before deciding on a
solution; and agreement on what to do next.
Or a decision to cancel the proj ect (unlikely for a design project you are doing for a
course in engineering school !)

Additional knowledge t hat will prepare you for t he next step:


From the evaluation process you should have a deepened understanding of the design problem,
and of the technical issues related to the solutions you have generated.
This knowledge is useful if you are revisit ing the requirements or idea generation phase.
If you have selected one design solution to move forward with, then you should have a
more solid understanding of t he technical implementation requirements for this
solution.

Documentation of your decision process:


Documentation should support the decision your team has made.

3. 7.

Learning Objectives

Know the relationship and importance of this st ep to the design process


Be able to apply a variety of techniques to evaluate and select solutions
Knowing and being able to implement techniques to compare and select potential solutions
from those generated during the creativity process
Understanding the need and methods of the st ages of evaluation
Realize that evaluation and selection are not j ust a final step in choosing a design with which
to go forward, but also a part of the process of generating requirements and potential
solutions.
Need more of t hese

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

138

3 - 21

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

3.8.

List of Key Terms in this chapter

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

139

3-22

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Part 2- Support of the design process


Part 2 of t his custom text covers methods that support the design process and can be used to improve
the outcomes achieved. The Chapters in Part 2 are:
Chapter 4: Design for the Environment and Community Considerations
Chapter 5: Critical Thinking
Chapter 6: Communicating in the Engineering Environment
Chapter 7: Working in a Team

Chapter 4: Design for the Environment and Community Considerations


Table of contents for this chapter

4.1.

4.2.

4.3.
4.4.
4.5.
4.6.
4.7.

Design for the Environment


4.1.1.
Conservation of Mass
4.1.2.
Conservation of Energy
4.1.3.
Designing for the environment: the three R's
Environmental Life Cycle Assessment (LCA)
4 ..2.1.
Easy LCA
4.2.2.
A Life Cycle Diagram
4.2.3.
Goal definition and seeping
4.2.4.
Applying a 3 R's analysis
4.2.5.
Inventory analysis, data gathering
4.2.6.
Impact analysis
4 ..2.7.
Improvement assessment
Services, software, and other virtual systems and products
Designing for Sustainability
4.4.1.
Introduction to the basic principles of industrial ecology
Understanding fully the service environment and stakeholders
Designing for the future
Innovation opportunities

This chapter addresses the dual issues of design for the community and design for the environment.
Both society and the environment are highly connected and complex systems. Both are also affected by
the design of technology, but are sometimes missed because they are not immediate or obvious
stakeholders: the impact of a design on the environment or the community might only be felt over a
long period oftime, or through a complex chain of cause and effect. However, it is often unanticipated
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

140

4-1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

effects on these hidden stakeholders that cause an otherwise excellent design to be considered a failure
in the long run. [Link to case study, e.g. recent hydro project MTK] Hence a good designer will
investigate the potential impact of the design on the community and environment, and if possible
involve representatives of these stakeholders in the process (politicians or environmental groups, for
example). Disregarding this important consideration can lead to rejection of a proj ect, poor
performance of a technology once it is in use, or environmental disaster. However, listening to issues
that arise from communities, and taking environmental concerns seriously can result not just in good
solutions, but in fact can be the motivation for truly innovative design ideas.
While it is easy to say that people and the environment are important to the design process, it is much
more difficult to actually implement this idea. Social and environmental systems are complex and far
reaching. It is difficult to see how an engineer can grasp the information in these systems and put it to
use when there is so much complexity and often conflicting opinions about what is best for a community
or for the environment. Listening and learning are the f irst steps, but engineers need methods to help
put the information they learn into a usable framework. In this chapter you will learn methods for
approaching these issues. The methods are taught here at a basic level that is appropriate for an
undergraduate design project, but these methods form the foundation for more comprehensive
techniques that are used in industry and government.

4.1.

Design for the Environment

There are, unfortunately, numerous examples of destructive environmental impacts that have resulted
from the implementation of technology. These often receive a lot of attention. Good design engineers
try to take the environment into consideration where it is appropriate. There are plenty of good
examples, but they often don't receive the same amount of attention as disasters. Engineers have the
opportunity to lessen the impact on the environment considerably by including "minimize
environmental impact" in their list of objectives when they are developing the proj ect requirements. In
addition, you may have to consider constraints imposed by environmental regulations and standards
that govern the project. It is important to not only do your own research on the environmental issues
that pertain to the project, but also to consult with environmental experts and organizations that
represent the interests of the environment.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

141

4-2

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

There are a few fundamental concepts for including design for the environment into the design process.
To begin with you need to know a few basic principles that govern the operation of environmental
systems.
[Case Studies- refrigerants, lead additives in gasoline, habitat loss or impairment, cars (one isn't much,
but aggregate is huge impact), electrical lighting effect on birds. And H-1 in Hawaii, and other "good"
environmental designs such as reduced mass or reduced waste, e.g. gypsum plants next to power
plants).

4.1.1. Conservation of Mass


The earth and its environment are governed by the laws of physics. One of the most basic of these is
the law of conservation of mass. As you know from physics and chemistry, mass is always conserved.

For an open system:

System
Mass stored in the
system
Mass going in

Mass leaving

Figure 1: Schematic of mass conservation for an open system

The mass accumulation in the system =mass going in - mass leaving


One example of an open system is the earth. Our planet gains about 200 Mg/day of mass from ice, dust,
and meteorites arriving from space, and the loss of mass from our atmosphere into space is negligible.

In the absence of a nuclear reaction such as nuclear f ission or fusion.


McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

142

4 -3

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

This net increase in mass is only a tiny fraction of the total mass of the planet so you can regard the
mass of t he planet as effectively constant.

Another example of an open system is you. Your body takes in 0 2, H20 and food. You excrete C0 21 H2 0
and other waste products. People often talk about weight loss in terms of calories expended (i.e.
"burned") in exercising, but in fact calories do not weigh anything. It is the molecules that are broken
apart to release energy from their chemical bonds that supply the energy you need when you exercise.
After t he energy is expended the waste products from this chemical reaction are expelled from your
body mostly as C0 2 and H20. This is the actual weight you lose when you lose weight. Unfortunately,
however, you can't lose weight faster by hyperventilating. When you gain weight it is because the
hydrogen, oxygen and carbon atoms from the foods you eat are not immediately tur ned into C0 2 and
H20 to exit your body. These atoms are stored as complex hydrocarbon molecules (e.g. fat) that carry
lots of energy in their bonds, ready for use the next t ime you walk up the stairs. You are a system and
the conservation of mass principle applies to you too.
All systems, including technologies and ecosystems, can be analyzed in this same way; the mass coming
into the system, the mass stored in the system, and the mass leaving the system can be characterized.
The molecules may change from input to o utput, but the atoms remain the same. And these atoms
leaving are still j ust as useable as when they entered the system. You may regard an out of date
computer as "junk" , but from a mass perspective it is essentially the same as the day you bought it! The
main point here: garbage is just mass that people have labelled as useless. If engineers can find
another use for " gar bage" it can become a valuable product.

Biodegradable: lfthe mass that makes up a product can be returned to an essentially natural state

through the action of living organisms (microbes, animals, fungi) then the product i s considered
biodegradable. Typically this term is used to describe products that can be transfor med back to their
natural state in a reasonable amount of time (on the order of days, months or years). A product that
takes hundreds or t housands of years to degrade is considered non-biodegradable.

The current mass of our planet is about 5.98x10

21

Mg

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

143

4-4

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

4.1.2.

Conservation of Energy

One of the other important laws that governs all systems is conservation of energy. For a given system:

System
Energy stored in the
system
Energy in

Energy out

Figure 2. Schematic of conservation of energy for an open system.

The energy stored in the system = energy in- energy out


The system will gain energy if the energy in exceeds the energy out. The system will lose energy if the
energy going out of the system exceeds the energy going in.
6

The energy into our planet is approximately 21x10 kJ/m -yr. This energy comes f rom the sun. There is
also a geotherma l contribution from the earth's core, but this is relatively minor compared to the solar
radiation our planet receives. Before people started using fossil fuels in large quantities to fuel our
technologies (e.g. vehicles, power plants) the earth was accumulating energy. Photosynthesis and the
food chain resulted in some of the energy from the sun being stored as biomass (plants and animals).
The energy was stored as high energy bonds in the complex hydrocarbon molecules that make up plants
and animals. Some of the energy accumulated in biomass, over t ime, became stored in the planet as
hydrocarbon fuels (e.g. natural gas, coal, and oil). People are now releasing the energy from these
stored reserves faster than it is accumulating. Dying plants and animals are still contributing to the
reserve of energy stored in the planet but the rate is very slow compared to the rate at which people are
extracting the energy and using it.
However, "using'' energy does not mean it is used up. Conservation of energy means that the energy

used still exists. All of the energy stored in the gasoline put into a car leaves the car as it is being driven.
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

144

4 -5

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

So it is all still there, in the environment. However, unlike mass, energy loses some of its "use-ability"
every t ime it is used. This property of energy is described by another basic law of physics, the "Second
Law of Thermodynamics". The Second Law of Thermodynamics governs all energy and applies to all
processes that involve energy.
For example; electricity goes into a microwave oven. The microwave turns the electricity into another
form of energy, microwave radiation, which turns into another form of energy, heat, when you heat up
a cup of tea. If you let your hot cup of tea sit on your desk it cools down. All of the electricity that went
into the microwave has now dissipated into the environment as " low grade" (i.e. room temperature)
heat. The energy is all still there, but it is now useless. You can not use the energy in the room (and
there is a lot of it !) to reheat your cup of tea. The Second Law of Thermodynamics says that there is no
technology that people can ever invent that will put that heat back into the tea without putting even
more low grade heat into the environment.
So energy does not cycle through the environment the way mass does. Energy cascades down a quality
gradient (picture 3). It becomes less useful every t ime it is used, and less useful spontaneously. To
create high qua lity energy products such as electricity (that is to "push" energy up this quality gradient)
costs resources. Large quantities of low grade heat are expelled into the environment to do it. In a
typica l fossil fuel power plant approximately 30-40% of the energy from the fuel will leave the plant as
electricity. The other 60-70% will leave the plant as low grade heat. So really power plants are primarily
heat plants that produce some electricity. The Second Law ofThermodynamics indicates that this is
about as well as a power plant can operate. Improving the technology improves these numbers, but
only incrementally. The basic laws of physics place a limit on the efficiency of such systems.
Ultimately, all energy used becomes low grade heat that is re-radiated out into space. However, energy
is conserved. And can be used at each point along the quality cascade. So the same energy that you use
to light your house will also help to heat your house once that light is absorbed into the walls and reradiated as heat. By being smart you can make use of the same energy over and over if you can match
the quality ofthe energy at each point in the cascade to the energy needs that you have in a technology
system. [Link to co-gen case study]

Renewable: Energy is considered renewable if it can be replaced relatively rapidly (on the order of days,
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

145

4-6

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

months or years). Examples include solar radiation, w i nd and biomass (e.g. wood or corn). A source of
energy that takes thousands of years (or longer) to replace is considered non-renewable. Examples of
non-renewable energy sources i nclude oil, gas, and coal.

4.1.3.

Designing for the environment: the three R's

Designi ng for the environment involves thi nking through both the mass cycle and the energy cascade in
the sys.tem you are designi ng. The three R's slogan, "reduce, reuse, and recycle", indicates the order of
preference in terms of a design.

Reduce: Try to design a system that requires a reduced amount of mass and energy.
Reduce the amount of mass and energy used in the production of the technology; reduce the
amount of mass and energy needed to operate the system; reduce the energy needed to
dispose of the system at the end of its life, and the mass that is disposed of. Example: reduce
packaging, e.g. package compact disks (CO's) in a paper sleeve instead of a plastic jewel case.

Reuse: Try to design a system that can be reused as many t imes as possible.
The material and equipment required for production (manufacturing, or installation) of the
technology should be reusable; the system should be reusable, or components of the system
should be reusable; at the end of its life the system should be designed to be easy to
disassemble so that components can b e easily harvested for reuse. Examples: refillable printer
ink cartri dges, reusable water bottles, or reusing water. (e.g. a grey water system) [Link to case

studies]

Recycle: Plan for the system to be recycled. Recycling means using the material (mass) in a
different form. Design the production of the technology such that the waste products produced
during manufacturing (or construction) can be recycled; design the system so that the waste
products produced during operation of the system can be recycled; at the end of its life the
system should be easy to disassemble so that the components materials can be easily recycled
using a minimum of energy. Examples: recycling plastic water bottles into artificial wood
products that can be used to build decks or park benches; recycli ng car tires into a soft mat
product that can be used on running tracks and playgrounds.
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

146

4 -7

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

The three R's approach is a basic thinking practice that can be applied during the design process. The
goal is to have these ideas in mind at each stage of the decision making process that goes into the
design of a system. Using this approach can result not only in an improved design for the environment,
but also a better economic return on the technology. Mass and energy cost money. By reducing,
reusing and recycling these valuable commodities you may be able to decrease costs and improve
revenues generated by the design. There are some excellent examples of this principle in action. [Link
to case studies]

Other R's:

In addition to the traditional three R's many waste management organizations now include other R' s in
their waste planning processes. These include ter ms such as "Recover", " Resell", "Restore", and
"Rethink".

4.2.

Environmental Life Cvcle Assessment (LCAJ

At the b eginning of this chapter, we described design for the environment as a difficult job because it
involves taking into account a very complex system, and this seems at odds with the simple
consideration of mass and energy and the three R's. Where is the complexity? Genuinely considering
environmental analysis usually requires deep thinking that goes beyond the three R's. For example, you
might assume that it is obvious that ceramic p lates are better for the environment than disposable
paper plates.

You might be right, but you can't be sure until you have carefully counted up the impact

of each stage of the production and use of these products on the environment. For example, to make
ceramic dishes requires substantial energy input to a kiln and heating the water to wash them every
t ime they are used. How does this energy compare to that used in the production and use of paper
plates? And what is the difference in the envi ronmental cost of disposal of these two alternatives? To
answer these types of quest ions, engineers employ Ufe Cycle Assessment.
Life Cycle Assessment (LCA), also called Life Cycle Analysis, is a more rigorous method for analyzing the
production, operating, and end of life environmental costs for a technology in terms of mass and energy.
In a ful l LCA all of the mass and energy that goes into, and results f rom, a system is quantified. It

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

147

4-8

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

includes all of the resources that go into producing the technology, operating the technology, and
disposing of the technology. This type of analysis allows engineers to investigate more thoroughly
opportunities to reduce the impact of a design on the environment. It also allows you to think through
the trade-off's inherent in design decisions and document the critical thinking process that goes into
these decisions. This work is essential for uncovering potential opportunities to reduce environmental
impact. It is also a means for demonstrating to project stakeholders the environmental costs that will be
incurred during the lifetime of the technology. Once these costs are exposed they can be discussed
among the stakeholders in the planning and design process.
The work of developing an LCA is worthwhile when:
The product or system will be produced in volume, i.e. in large enough numbers to have
a meaningful environmental impact.
A single unit or just a few units can have a meaningful environmental impact, for
example: a power plant, or an oil rig.
Or when you are learning how to do this type of analysis. In professional practice it may
not make sense to do a full LCA for a " one-off" item that has only a small impact; for
example the design of an assistive device, such as a walker, for one person. However,
when you are f irst learning how to do this type of complex ana lysis it is easier to start
with a simple, unique system to hone your skills.

4.2.1.

Easy LCA

Working out a full LCA can be a daunting task. Two approaches that can make this process easier are:

1.

Perform an LCA comparison between two design alternatives

2.

Shorten the process by performing a 3 R's analysis after defining the goal and scope

The easiest type of LCA to perform is a comparison between two or more alternative designs. We
recommend that the LCA be used as a comparison tool at this stage in your career. There are several
reasons why using LCA as a comparison tool is easier than performing an LCA for a single proposed
design. First, an analysis of this type is often very difficult to interpret. If you determine that the
proposed design will produce SOOkg of C0 2 over its lifetime, is this a lot, or a little? It is very difficult to

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

148

4 -9

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

form a judgement in the absence of experience or comparators. Second, comparing systems allows you
to focus on the specific processes in the life cycle that differ between the two systems. This allows you
to neglect, or at least simplify some of the other parts of the life cycle which can make the information
gathering you will need to do much more manageable. Also, related to both of these reasons, a
comparison of two LCA's makes it much easier for you to write about the results because is provides a
context (i.e. compare/contrast, similarities/differences) for what you can say. {Add link to tomato case

study here; Case study based on NYT article compares hot house tomatoes grown in greenhouses in
Maine in winter to tomatoes imported to Maine and Ontario from warm climates. Looks at comparison
of energy costs etc.]
Picture 4. Engineer comparing two systems
Another way to do an analysis that is better than a simple 3 R's analysis, but much less work than a full
LCA is t o combine the two methods. Use the LCA method to define the goal and scope of the life cycle,
and draw the life cycle diagram. Then use a 3 R's analysis for each process in the life cycle. This is not
actually an LCA, but it is a strategy for examining each stage of the life cycle for possible environmenta l
improvements.
Thoroughly documenting your work throughout the process is very important. The credibility of your
conclusions at the end of the analysis depends on how well you have explained and described your
decision processes at each step as you perform the analysis. A typical LCA requires that you make
assumptions, mix data of different types and qualities, and ma ke significant decisions about what to
include or exclude from the analysis. In these respects it is very typical of many engineering analyses
you will have to perform in your work as an engineer. A thorough documentation of the process
explains this to your audience as they work their way through your analysis; the docu mentation should
"teach" your reader through the LCA so by the end they understand what you have learned by doing the
analysis.

4.2.2.

A Life Cycle Diagram

An LCA starts by constructing a life cycle diagram. The life cycle for a technology includes all of the mass
and energy that go into, and results from, producing (constructing, or installing) the system. It also
includes all of t he mass and energy that go into the system during its operating life, and that results
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

149

4 - 10

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

from (comes out of) operating the technology. And finally it includes all of the mass and energy that go
into, and that result from, decommissioning, disassembling, and/or disposing of the system at the end of
its life.
Figure 5 shows a very simple generalized graphic of a life cycle for a product or system. The life cycle
starts w ith raw materials (RM) as they exist in or on the earth (ore, lumber, water, etc.) or as recycled
materials available for use. In this simple example raw materials undergo processes (Process 1 and
Process 2) which result in intermediate products (P1 and P2). To accomplish these processes energy is
required (E1;n and E2;n). During the processes some of the mass may be discarded as waste into the air
or water or as solid wastes. This is called a residual (Res 1 and Res2). There will also probably be some
energy that is discarded as well because (recalling conservation of energy) all of the energy entering
with the raw materials or added during the process must either exit with the products or leave as
discarded energy (E1out and E20 u1). The intermediate product may undergo f urther processing (Process
3) before it becomes a usable system or product. The result (P3) is then put into operation. As the
technology is operated (used) it continues to undergo a process of use (Process 4) until it is retired from
service. The result, at the end of the lifecycle is a product (P4) which needs to be disposed of. The last
process (Process 5) is the disposal process and results in a final waste product (Resendl

This diagram is

very basic. Most lifecycles will involve many more processes, e.g. the transportation of materials, and
intermediate products. An example of a simple life cycle diagram for a product is shown in figure 5. An
LCA diagram represents a method for tracking the energy and mass that flow through the life cycle of an
engineered product. This method can be applied to any product or system.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

150

4 - 11

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

@--

@--

@RM = raw materials (mass) in or on the earth


P = product (mass and/or energy)
E=energy
Res= residual (mass) , i.e. w ast e

@ --

Process 4

r::-1_ --

Figure 5. Generic schematic of a life cycle diagram

There are software packages that can be used to construct a life cycle diagram and analyze it for more
complex systems. Examples of LCA software include GaBi Software, and Sima Pro. For a simple system a
sketch of the lifecycle diagram and the use of a spreadsheet to manage the data w ill suffice.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

151

4 - 12

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Residuals

co1
S02

Suaar

"
Coal

/
Syrup
Plant

Caffeme
Water

Residuals
Wastewater

r
Residuals

Canof
ZipZap

1_ .

Water
User

Residuals

Energy

Residuals
Ore
Life Cycle Diagram
for ZipZap Soft Drink

Figure 6. Life cycle diagram for a carbonated drink product. Note that the LCA of this product includes both the
drink and the packaging. Courtesy of Prof . David Bagley, University of Wyoming, l!.aramie

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

152

4 - 13

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Drawing the life cycle diagram is the f irst step in the life cycle analysis. A standard LCA consists of 4
stages:

1.

Goal definition and scoping

2.

Inventory analysis, data gathering

3.

Impact analysis of the life cycle

4.

Improvement assessment

The LCA process discussed in this chapter is adapted from the process described in [1] .

4.2.3.

Goal definition and scoping

Scoping the life cycle means deciding which parts of the life cycle to include in the analysis. Because of
the interconnection between technologies it is virtually impossible to construct a comprehensive life
cycle for any system. For example, in the relatively simple life cycle example shown above should you
also include the trucks that transport the bauxite ore to the smelting plant? You could try to take into
account all of the energy and materials needed to construct and operate these trucks. And what about
the ink used to label the cans of ZipZap? The labelling ink is also a product that must be manufactured
and supplied to the beverage canning plant. It quickly becomes obvious that it is impossible to trace
every aspect of the life cycle for this one simple product. In rea lity to make a life cycle analysis useful
an engi neer must choose to focus on the important aspects of the life cycle, and ignore the relatively
trivial components. This is called scoping, or specifying a scope. For example, if one truckload of ink
satisfies printing needs for the factory for the whole year and t here are 50 trucks full of product leaving
the factory each day, it is probably reasonable to ignore the ink transportation in the LCA. Another way
to reduce the complexity in a comparative LCA is to omit steps common to both alternatives (shipping
the final product, for example).

Step 1. Goal and Scope


This step requires that the engineer make decisions about what parts of the life cycle they will focus on,
and which to ignore. Scoping the life cycle is one of the most difficult parts of the LCA process, and the
choice of scope will depend on the goal of the analysis. An LCA can have as a goal [1]:

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

153

4 - 14

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

To help guide design decisions. The goal is to use the LCA to compare and contrast alternatives
in the design process or production ofthe design on the basis of environmental impact.
To identify the steps or processes in the life cycle that contribute most significantly to
environmental impact. The goal is to identify these steps so that alternatives can be found or
researched.
To support product or process certif ication. The goal is to produce a credible LCA that will
convince a certifying organization that the process or product is deserving of a special
designation for environmental f riendliness (e.g. a "green" certification)
There are other possible goals, but these three are the most common. Start the documentation of your
LCA by stating your goal.
Next choose what processes to include in the lifecycle. Some guidelines for selecting processes to
include when drawing the life cycle diagram:
Start with the operation of the system, structure or product. This process is the foundation of
the life cycle (in the example, this process is the user purchasing and drinking the ZipZap).
Identify all mass and energy inputs that are needed for this operation, and al l of the outputs
from this process.
Add the "downstream" processes. These are the processes that must occur to dispose of or
decommission the system when it has reached the end of its life. Add the energy and mass
flows that occur during this phase.
Now choose the " upstream" processes to include. What you choose will depend on the goal of
the LCA. However the upstream processes should go far enough back in the lifecycle to include
the extraction or recovery of the primary raw materials needed for the production of the system
or product. The raw material could be a substance in its natu ral form in the environment, or a
recycled substance.
At this point you also need to decide what to leave out of the lifecycle. The processes in a lifecycle can
be categorized as primary, secondary, tertiary, and so on. The primary processes are those that are
necessary for the primary mass and energy streams needed to produce the technology. For example, in
the case of ZipZap the syrup, the water, the aluminum for the cans and the carbon dioxide are all
primary mass f lows required for the production of this product and should be included in the lifecycle.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

154

4 - 15

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

The secondary processes would include the ink for labelling the cans, and the production of the sugar or
flavoring for the syrup. These are processes t hat are secondary contributors to the lifecycle. You have
to decide whether these secondary processes,, such as the production of the flavoring, should be
included in the analysis, or left out. An example of a tertiary process in this example would be the
production of packaging for the f lavoring, i.e. the production of the bags or barrels used to transport the
flavoring ingredient to the syrup plant.
If possible, use the purpose or goal ofthe LCA to make these decisions. In addition to going back to the
LCA goal for guidance on what to include and what to leave out, you can also run a brief sensitivity

analysis to estimate the contribution of the secondary processes. If you find that a secondary process
contributes only a small percentage to the primary mass or energy flow, then it is probably reasonable
to leave it out. All decisions about what to include and what processes to exclude should be caref ully
documented (i.e. explained). You may also want to come back and review your decisions about scope
once you have worked through the other stages of the LCA.

Example: if the goal of the LCA is to compare two alternative drink ideas for ZipZap, one that involves
using brown sugar and the other involves using refined white sugar, then the sugar production process
is an important point of comparison and should be included. However, if the LCA is being used to
compare two drink ideas for ZipZap that both use the same amount and type of sugar, then the sugar
production process can be left out because it will not affect the conclusions of the LCA in terms of
contrasting the environmental impact of the two design ideas. It should be noted that leaving out the
sugar production process will remove it from consideration. Thus improvements to the environmental
impact of the design based on a better sugar production process will also be removed from
consideration with this decision. This should be documented so you and your client are aware that
through this decision, improvements in this area of sugar production are not being considered in your
analysis.

One class of contributions that is typically excluded from an LCA is the capital equipment required for
the production of the design. For example, in the lifecycle of a building the impact o f manufacturing the
dump truck or excavator used during the construction process would be excluded from the

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

155

4 - 16

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

environmental impact analysis. The analysis should include the fuel the truck uses, but not the
manufacture ofthe truck itself . The impact of constructing the equipment which will be used again for
other projects is really tertiary to the project's lifecycle and therefore can be excluded. In the ZipZap
example you would exclude the impact of constructing or manufacturing the aluminum smelt ing
equipment, the equipment in the canning plant, and the equipment in the carbon dioxide plant, and
other capital equipment. However, you would include the energy used by this equipment during the
production process because the energy used in the manufacturing process is primary to the product.

Step 2. Specifying foreground and background


Once you have drawn a first draft of your life cycle diagram and decided which processes to include or
exclude from consideration, then you need to decide which processes to place in the foreground and
which to treat as background [1]. The processes in the foreground are processes that are unique to the
lifecycle being analyzed. The data for these processes will be specific to the technology you are
analyzing. The processes in the background are common, generic processes for which you will gather
average data. For example: in the production of ZipZap the electricity production is in the background.
The power plants are there already and not specifically dedicated to the production of ZipZap. You
would gather data on electricity production for the analysis that is typical (average) for the region in
which the plant is located. The same would be true for the aluminum smelter, assuming that ZipZap is
getting its aluminum from general sources and not developing a unique manufactu ring facility just for
the production of this beverage. The foreground processes for the ZipZap lifecycle are the syrup plant,
the canning plant, the distribution of ZipZap to stores, the using of ZipZap (i.e. the user drinking the
product), and the disposal process. The aluminum can plant may be foreground if its only function is the
production of ZipZap cans, or in the background if the company are acquiring the cans from a general
source (i.e. getting cans f rom several can factories that make cans for lots of drink producers).
Foreground processes
Background processes

individual, unique data for the process or plant


data, e.g. regional data or values that are typical for a

particular industry

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

156

4 - 17

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Step 3. Choose a functional unit


When comparing two or more possible design alternatives it is important to choose a comparable

functional unit. A functional unit is an amount that has an equiva lent function to another system. For
example, you could compare the environmental impact of 2000 250L cans of ZipZap to 1000 SOOL
bottles of another drink. These units are functionally equivalent because they carry the same amount of
fluid. A more complex comparison would be the comparison of disposal plastic water bottles that are
used once to reusable metal water bottles. To carry out this comparison you need to estimate how
many t imes the metal bottle could be reused (maybe 500 t imes) and compare this to the equivalent
number of disposable plastic bottles of the same size. Whatever functional unit is chosen, the amount
should be large enough so the data represent the typical average energy and mass requirements for the
processes. So you could assess the environmental impact of manufacturing, using and disposing of 1000
metal bottles, and compare this to the environmental impact of manufacturing, using, and disposing of
500,000 plastic bottles, the functional unit equivalent.

Estimat ing a functional equivalent:


It would be reasonable to guess that a typica l person might buy a plastic bottle of water and refill it a
few t imes during a day before disposing of it. So to determine a functionally equivalent usage for a
metal water bottle you need to estimate how many days a metal water might be in use during its
lifetime. [link to estimation chapter]
You could get this information from:
An independent research study by a university, government, or NGO - which is
considered to be credible
A study carried out by industry, i.e. the plastics industry or the metallurgical industry which is considered to be less credible because of the inherent conflict of interest
Other sources of information
An educated guess - "educated" means that we have some experience or knowledge
that helps to inform the guess.

[link to the gathering information back page]


McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

157

4 - 18

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

If you use an educated guess, based on your own experience with water bottles, you might guess that a
metal water bottle would typica lly be in use for 1 to 3 years, or about 365 to 1095 days. So you might
pick 500 days initially to get started on your analysis, and then refine this number later through
additional research if necessary. You would document your reasoning to show how you selected 500
plastic water bottles to be the functional equivalent of 1 metal bottle.

Summary of goal definition and scoping steps:


Select a goal
Include all primary processes from materials extraction through to disposal.
Decide on secondary processes to include. Use your stated goal, and a brief sensitivity
analysis to make your decisions.
Recal l that capital equipment is generally left out of the lifecycle assessment.
Draw out a clear lifecycle diagram for your assessment
Identify which processes are foreground and which are background, and document
these choices (i.e. write this down with an explanation).
Choose the functional unit, and document your choice.

4.2.4.

Applying a 3 R's analysis

At this point you could continue with the LCA methodology and proceed to inventory analysis.
Alternatively you can exit the LCA methodology and use a 3 R's approach to analyze each of the
processes in the life cycle. This will not produce an LCA, but is better than a simplistic 3 R's approach
that only considers a small part of the life cycle. For example, in the ZipZap life cycle you could identify
that the environmental impact of the product could be reduced by using recycled aluminum for the cans
instead of freshly mined material. You could support it by finding a source that compares the
environmental costs of recycled aluminum to the use of freshly extracted metal. This is a qualitative
statement that you have not supported with data, so it is less credible than a full analysis. However, if
environmental analysis is only a small part of your design project, then you may want to take this short

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

158

4 - 19

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

cut. However, if your instructor is expecting a more complete and in-depth LCA then continue to
inventory analysis.
4.2.5.

Inventory analysis, data gathering

Once t he life cycle has been scoped you wil l need to perform an inventory ana lysis. This means
quantifying all of the energy and mass inputs and outputs for each process. It is sometimes easy to find
good quality data to use by doing some searching. However, more often it is necessary to estimate the
amounts of mass, and energy going in and out at each stage of the life cycle. The quality of the LCA
depends on the quality of the data and estimates that are used. Therefore it is important to use best
practices in the estimating procedure and gather credible information. [Link to estimation chapter and

gathering information back page] When developing the inventory, keep in mind the laws of
conservation of mass and energy: What goes in must come out at each process step.
Step 1. Start your spreadsheet
In order to keep all of the data you will collect for your inventory organized you should use a
spreadsheet. The spreadsheet will help you keep track of all of the data making sure you do not have
overlapping data or gaps in your lists. It will also help you convert units, and convert your raw data to
the correct amount for the functional unit you have chosen. Ultimately it will make it easier to add up
the impacts of different design alternatives and compare the results.
Start your spreadsheet by grouping and listing all of the processes in your lifecycle. Include descriptions
of the processes. Grouping means grouping together individual processes that all occur at the same
t ime or in the same location. For example, t here are numerous processes that go int o creating an
aluminum can, but you would group these together into an "aluminum can production" process in your
spreadsheet. A description would explain the type of process used. This is especially important if there
are a number of different competing processes that are commonly used in industry f or this type of
production or construction activity.
Step 2. List and describe the inputs and outputs
For each process, enter into the spreadsheet all of the inputs and outputs. The mass inputs and outputs
should include all gases, liquids, and solids. It is also useful to add a column to your spreadsheet that
characterizes the output mass flows. The output mass can be described as a:
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

159

4 - 20

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

product that is the intended useful output of the process

co-product that is a useful, but unintended, output of the process


waste (production or post-consumer) that is an unintended and not useful output of the
process
All waste and co-products (i.e. residuals) should be listed in the spreadsheet for each process. This
includes waste going into the ground, into a body of water, or released into the atmosphere. Carbon
dioxide and other greenhouse gas emissions should be included in the inventory. A column in your
spreadsheet should be used to describe each residual output. The description should indicate whether
the output is a co-product, or waste. If it is waste it should be characterized as non-hazardous, or
hazardous with a brief description of the hazard it represents. The waste that results from the
operation of a system or technology or at the end of the useable life of the design should also be
designated post-consumer waste and it is of particular importance because your lifecycle analysis must
include the disposal of this type of waste as part of the assessment.
Water represents a common input and output mass flow from many industrial processes. If the water is
used, treated, and returned to the environment in essentially original condition (i.e. clean) then the
water doesn't need to be included in the inventory. However, the treatment process must be included
in the lifecycle to accurately count the cost of remediating this important resource. If the water is " used
up" in the process (through evaporation, incorporation into the product, or polluted without treatment)
then the water must be listed in the inventory both in its input form and as an output with a description
of its condition when it exits the process. You need to include the disposal of polluted water in your LCA
if it constitutes a potentially significant environmental impact that results from your design.
The energy inputs should also be categorized. The energy used in a process can be heat, electricity, or
transportation (i.e. energy required to transport mass from one location to another) .. The energy
outputs should also be categorized (i.e. described as heat, electricity, potential energy, or other types of
energy).[link here to basic concepts back page] Fuel going into a process represents inherent energy

that may be converted to heat or electricity. The fuel going into a process as a mass f low should be
described both in terms of its mass description (e.g. m 3 natural gas, kg coal, or L oil) and in terms of its
energy content (which is called the heating value). The description of the energy will be important
when you try to quantify the energy going into and out of each process.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

160

4 - 21

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Step. 3 Quantify the inputs and outputs


You now need to quantify each input and output of energy and mass for each process. As you gather
the data and put it into your spreadsheet make sure you note in the spreadsheet the source of the data.
The data should be put in the spreadsheet as it appears in the source to make it easy for you (and your
reader) to see where the data came from. Then convert the values in another column, as necessary,
into the units you are using or convert to reflect the functional unit you are analyzing. The quality of
the data should also be noted. Is this piece of data an estimate? Does it come f rom research, or f rom
an industrial measurement? Is it specific to a particular type of equipment or is it a general average?
The qua lity and credibility of the LCA depends on the quality of the data and the documentation of the
data.
Remember that for foreground processes you are trying to find specific data that ref lects as exactly as
possible the process that you are proposing for this part of the lifecycle. The data for mass should be
expressed in units of mass or weight. Energy units tend to be more mixed (KJ, KW, Btu). [link here to
basic concepts back page] Be careful in converting these units, and do not add them together. Adding

a KJ of heat to a KJ of electricity is like adding a kg of apples to kg of arsenic. A KJ of heat is not


equivalent to a KJ of electricity because the environmental cost of producing one is quite different from
the other Oust as the environmental cost of disposing of arsenic is very different than disposing of
apples).
For the background processes you can gather average data. For example the p roduction of electricity in
a region generally involves a mix of different technologies. It probably involves burning fossil fuels,
some electricity production using nuclear power plants or hydroelectric plants, and perhaps some other
power generating technologies such as wind turbines. The environmental cost of this electricity
production will depend on this local mix of technologies. For example, as of 2006 the U.S. average was
approximately 11.3 M J of energy input for eve ry KWh of electricity produced [1]. This takes into
account the energy used to extract the fossil fuels, transport them, and the energy inherent in the fuel
that is "used up" when they are burned to create electricity. This type of data is often available through
government sources, such as the U.S. Department of Energy. [link to DOE website]
Data for background processes should reflect common practice in the region where the process will
occur. You should not assume either the best practices will be used (unless this is specified as part of
your design) or the worst, such as illegal disposal.
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

161

4 - 22

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

When quantifying the residuals from each process it is useful to characterize the location of the outputs.
Is the mass f low collected and stored? Or is it emitted into the environment? If it is emitted, is the
impact local (for example into the local soil), or national, or international (such as carbon dioxide gas)?
This inf ormation will help you later in the LCA process when you try to characterize the impact of the
lifecycle.
What if you can't find or even estimate all of the data?
It may not be possible to f ind all of the data you would want to have for your LCA. Some of the data
may be proprietary (not in the public domain) . Or it may take months of searching to f ind it, which is
not feasible for an undergraduate project. It may not even be possible at this stage of your career, with
limited experience, to create a meaningful estimate or educated guess for all of the values you need.
Consulting with your instructor or a reference librarian may help you track down some of the
information. [link to back page on gathering information] However, where no information is available,
you need to note this in your spreadsheet. Clearly indicate the data that is missing, and discuss this in
your report.
When can you neglect data?
You can ignore input or output data when the contribution is less than the error in the data for the
substantial contributing mass and energy f lows in the lifecycle. Be careful that you document such
omissions and that you have compared the data correctly before excluding them. Also, you should not
ignore waste mass flows if the waste is potentially hazardous even in small quantities. Such emissions
should be noted even if they are small.
Summary of inventory analysis and data gathering steps:
Setup your spreadsheet
List all ofthe processes in your lifecycle
List and describe all of the mass and energy flows for each process
Categorize the mass and energy inputs and outputs (e.g. heat, transport, or electricity;
waste, product, or co-product )
Collect and compile data for all of the mass and energy inputs and outputs

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

162

4-23

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Carefully document all of this data in your spreadsheet including the source for each
piece of information
Convert data to a common set of units, and to reflect your functiona I unit equivalents

4.2.6.

Impact analysis

By the t ime you have finished collecting and organizing the data for the inventory you probably already
have some idea of what the most significant contributors are to the environmental impact of your
proposed design. In the Impact Analysis stage you will aggregate your data based on scientif ic principles
and begin the process of formulating conclusions based on the data. In the impact st age you will be
describing the relative stressors on the environment that may cause impact based on the data you
compiled in the inventory.
Step 1. Define your impact categories
You will be organizing your inventory data into categories that describe the potential impact of the mass
or energy flow. Typical impact categories include human health, environmental health, and resource
depletion. However, you can define other categories, or break these major categories down into
subcategories, if there are specific impact issues that you want to consider in this analysis.
Step 2. Organizing your data into the categories
All of the data you have collected in your inventory will now be organized into one or more of the
categor ies you have defined: e.g. human health, environmental health, resource depletion. We suggest
doing this on a new worksheet, or in a new file. Your data will now be organized in two ways:
1

1' sheet: During the inventory analysis stage you organized the data by process
according to the lifecycle diagram

2"d sheet: During the impact analysis stage you will organized the data by impact
category
You may find that the data f it into more than one of these categories, and the data should be copied
into all of the categories that are relevant because the data in each category will be used to derive a
conclusion about a different sort of potential i mpact. For example nitrogen dioxide (N0 2 ) can both
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

163

4 - 24

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

contribute to environmental degradation through the acidification of water {lakes, or ponds) and also
affect human health because it is a respiratory irritant so it should be included in both categories. Make
sure that you identify, in the new spreadsheet, the origin of the data, i.e. with which life cycle process
the data is associated. [Link to example in case studies]

Advanced Material

Step 3. Determining equivalencies


You might want to aggregate the data in the inventory so you can do a deeper comparison between two
alternative designs. To do this you need a scientifically based method for comparing the potentia l
impacts of different chemicals or other impact types. Engineers use the concept of equivalencies for
this purpose. An equivalency is a way of converting data into a common set of units that can be added
and compared. For example, methane {CH4 ) is about 30 t imes more effective as a greenhouse gas
(GHG) than carbon dioxide {C02). Therefore, every mol of methane can be considered the GHG

equivalent of 30 mols of C0 2 You can use this fact as an equivalency to convert a mass flow of methane
into the atmosphere into a C0 2 equivalent. You can use this information to identify the processes in the
lifecycle which have the most significant impact in this category. It is important at t h is point to
document your observations. Note the processes which are potentially the most impactful and consider
whether there are alternatives that could reduce these impacts. For example, you m ight decide based
on your analysis to concentrate your efforts on eliminating the emission of CH 4 f rom the design lifecycle
rather than tackling the C0 2 emissions first.

Step 4. Aggregate the data


Once the data has been categorized, and equivalencies have been used to convert the data into the
same units, you can add up the impact in each category. This gives you a picture of the total impact of
the lifecycle in each of the key categories. It also allows you to compare the totals of one lifecycle to
another possible design to help you decide which one may represent a better choice in terms of
environmental impact. Be careful not to add things together that are not equivalent. You may not be
able to find equivalencies for everything, so some mass flows and energy flows will need to be left as is
and not aggregated.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

164

4 - 25

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

At this point you may want to perform a brief sensitivity analysis. Save your spreadsheet to a new file
so you don't lose your original data set. Then try changing one of the significant inventory data values.
How does the aggregate data change? Reset the data and try changing another input. You will probably
find that the results are very insensitive to some of the data, which means that even if this data is not
very accurate, the inaccuracy does not have a meaningful or significant impact on your results.
However, you wi ll probably also find that the results are very sensitive to a few key pieces of data. Go
back and check on the accuracy of these key data . Doing a little more work to get better quality data for
these key sensitive numbers will improve the quality of your LCA. Make sure you describe the sensitivity
of the data to your audience so they understand it. You may also want to examine whether there are
alternative processes that could be used to improve the impact of your design based on your knowledge
of the key sensitive data points.

You will be using the outcome of the impact analysis to state conclusions. In drawing conclusions based
on this analysis it is useful to use the concept of midpoint assessment. In midpoint assessment you
quantify and characterize the potential impact of the technology or system, but do not try to predict the
precise consequences of this impact. For example, you could say that based on your lifecycle
assessments design A results in a overall release of toxic material into the loca l water that would be the
equivalent of half the toxic material released by an alternative, design B. And you can characterize the
type of chemicals that are released and the known effect of these chemicals on marine animals.
However, you do not try to predict what the actual impact is on the water (e.g. number of fish that will
be killed). A specific "endpoint" conclusion, such as the number of fish that might be killed, is really not
possible based on your data and your analysis. The conclusions you can reach are limited. A specific
conclusion like the exact number of fish affected overreaches the validity of the information you have
available, whereas a midpoint assessment that simply states and characterizes what is going into the
environment is justif ied, credible and valid.

Picture 7. Cartoon illustrating midpoint assessment concept.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

165

4 - 26

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Summary of impact analysis steps:


Define your impact categories
Using a new worksheet, or spreadsheet file, organized your data by impact category,
make sure you identify with which process the data is associated.
Characterize the nature of the materials and energy being extracted from environment,
and going into the environment as a result of this lifecycle, i.e. midpoint assessment.

4.2.7.

Improvement assessment

After completing the impact analysis you are ready to state the conclusions of the LCA. This is ca lled the
Improvement Assessment. Start by summarizing the analysis. This summary should
remind the audience (i.e. reader) of the goal ofthe analysis
briefly remind your audience of the major processes in the lifecycle diagram
recall the maj or decisions and assumptions that went into seeping the lifecycle
describe the overall qua lity of the data used in the inventory, and note the consistency (or
inconsistency) in the quality of the data
note any major estimations you had to make
summarize the results from the impact analysis
Now you can discuss the overall results and state your major conclusions. If you are comparing two
alternative designs then it would be appropriate to have a section in your Improvement Assessment that
compares and contrasts the results of the LCA's for the two or more design alternatives you are
comparing. What are the advantages and disadvantages of each relative to the other? It may be clear
that one design is much better, but usually the comparison demonstrates that all design choices have
some advantages and some disadvantages (i.e. pros and cons). You need to weigh these results and
decide what recommendations to make.
It is also important to note the limitations of your LCA. The quality of the data, the scope and the
assumptions and estimations you had to make in the analysis affect the value of the LCA. It is important
to explain your level of confidence in the results and to acknowledge gaps in the analysis; for example,
where data is missing from the inventory.
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

166

4 -27

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

It is also worth noting that an LCA does not fully capture all of the potential environmental impact. For
example, a typical LCA does not include disruption to sensitive habitats. It can quantify depletion of a
resource, but it does not by itself indicate the importance of that resource for the people, plants, and
animals that also depend on it. However, you can use the improvement assessment to point out some
of these other issues and suggest changes to the location, or changes to the processes in the lifecycle
that could potentially lessen the impact.
The improvement analysis should emphasize this last point: based on what you have learned through
doing the LCA, what changes could or should be made to the design and the lifecycle ofthe design.
Summarv of improvement assessment steps:
summarize the analysis and the results
explain limitations of the analysis
compare and contrast the two alternatives on the basis of the LCA results
make recommendations

4.3.

Services, software, and other virtual svstems and products

Virtual systems and services do not have a lifecycle that is comparable to a product. There is no need for
the steady flow through of raw materials, and the disposal of mass at the end of the lifecycle for a
service or software package (if it is downloaded). In fact some service companies were founded on this
premise: that replacing a product with a service will reduce environmental impact.
Examples:
diaper services that replace disposal diapers.
Zipcar that allows consumers to drive a big car when they need one, or a small car when they
don't.
There are also examples of environmentally conscience companies and organizations that provide
services and virtua l products that are interested in reducing their environmental footprint. One
approach that can be used is LCA applied to the facility where their employees are working.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

167

4-28

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Two examples of organizations that have taken this approach are Google, and the Audubon Society.
Google headquarters is in Mountain View, California. The office complex includes on-site electricity
generation using photovoltaic panels, which supply about 30% of their electricity needs. They also grow
on site some of the food that is served in the cafeterias. This particular company claims that t hey
actively looks for ways to reduce their load on the environment as part of their corporate culture.
Similarly the Audubon Society has considered the environmental impact of their office building. The
Audubon Society is a non-profit Non-Governmental Organization (NGO) that works on nature
conservancy issues. They intentionally located their headquarters in a re-modeled building in New York
City. First, by remodelling instead of building a new facility they reduced the waste output of the
proj ect. The remodelled building is designed to make the most of natural light, reducing t he need for
artificial lighting. And because t he building is located in an urban area employees have easy access to a
public t ransit system. These are just two examples, there are many more.
One additional example that you might consider is your college or university. Schools are service
oriented, usually non-profit, businesses. Does your school have a policy on sustainability or
environmental impact? How is this policy incorporated int o t he facilities design and services on the
campus?
The fundamental conclusion here is that whether you are working on an engineering design project for a
product, facility, service, or any other type of technology, LCA provides a useful approach to evaluating
the environmental impact of the technology. And LCA is particularly useful if you are trying to
distinguish between two possible alternative solutions based on " environmental friendliness" or a
similar type of objective.

4.4.

Designing tor Sustainabilitv

A sustainable design is one " that meet s the needs of the present without compromising the ability of
future generations to meet their own needs" [2).
Designing for sustaina bility means taking a longer view of the impact of a design. In part this is assessing
the potential environmental impact of a project, and working to develop a design that minimizes this
impact. However, designing for sustainability also means considering t he impact on f uture generations

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

168

4 - 29

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

and including this in the design process. The results can not only be advantageous for the environment,
but can also result in innovations that are more economically, and socially effective.

4.4.1.

Introduction to the basic principles of industrial ecology

Industrial ecology is one approach to sustainable design. It is a variation on the lifecycle assessment
method that looks at the lifecycle of a product or technology as an ecological system analogous to
natural ecological systems. Engineers use this perspective to try to f ind better, less environmental ly
impactf ul, approaches to the construction (fabrication) of a technology, its use, and its disposal. This
approach is based on the principles of conservation of mass and conservation of energy. You will recall
from an earlier section in this chapter that mass is cycled through the planet, almost always maintaining
its original form (at the atomic level), whereas energy cascades through our planetary system. It arrives
from the sun as electromagnetic radiation, and undergoes conversions from one form to another
gradua lly losing its usability until it exits into space as low grade heat.
Consider the waste products and post-consumer waste that are discarded in a typicallifecycle for a
technology. The waste materials are only considered "waste" because people haven't found a use for
them. If people recycle or reuse this waste then it becomes a co-product that has va lue. In nature,
nothing goes to waste. All mass is recycled in one way or another. For example, leaves that fall from a
tree are recycled into soil and the nutrients are returned to a state that the tree can use again. Or
oxygen, a waste product from a tree, is used as a valued input product by animals. So you can look at
your proposed lifecycle and think about whether you can f ind a method for remediat ing the waste into a
useable, or at least less toxic, material. The idea is to create technologies that are all part of a closed
ecologic system where all mass is recycled. This is consistent with the 3 R's: reduce, reuse, recycle.
People can also improve the use of energy by matching the use of the energy to the source. For
example, the generation of electricity from fossil fuels results in a large quantity of heat being
discharged to the environment. However, this heat can be used before it is discharged. It can be used
to warm greenhouses in winter for growing vegetables, or to heat other types of buildings. Using an
industria l ecology perspective you can examine your lifecycle for opportunities to make use of energy
multiple times before it is discharged to the environment.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

169

4 - 30

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

From an industrial ecology perspective engineers look at the design of a technology for use and reuse,
rather than taking a "use it up" approach. In its purest form, all processes in the life cycle of a
technology should only result in co-products or remediated waste that is environmentally benign. And
all of the costs associated with energy production (e.g. remediation of coal mines, recapturing and
sequestering the resulting C0 2 ) should be included in the lifecycle. By making sure that all of the "costs"
of creating, using, and disposing of a technology (current and future costs) are explicitly included the
true cost of the system can be accurately evaluated. This allows engineers to authentically compare all
of the costs of one proposed design to another.
One criticism of the industrial ecology approach is that it does not actively promote reduction of waste.
Industrial ecology might suggest that if you are able to turn all of the waste products in a lifecycle into
co-products then producing more residuals is better. Industrial ecology does not acknowledge explicitly
that all production comes at a cost; a cost of energy and an opportunity cost, meaning the opportunity
to leave the raw materials in their natural state, or for future use. A different approach is Preventative
Engineering which makes this distinction and emphasizes reduce as the first key principle ahead of

design for reuse or recyclability.

4.5.

Understanding fullv the service environment and stakeholders

In addition to the natural environment, an engineering project or design can impact human society. In
particu lar, the local community may be affected by the construction or implementation of a technology.
This is especially the case for infrastructure, plants, and facilities development projects (e.g. roads,
power stations, pipelines). While technology can bring positive changes to a community, it can also
have negative impacts and generally there are trade-offs associated with every project. It is ethically
appropriate to inform people about plans that may impact their community, and it is advisable to
involve the community in the planning process when the project will directly impact the local
environment. In many countries, a lack of community involvement can resu lt in a project being delayed
by legal action, or cancelled. This is because many jurisdictions require community consultation as part
of the engineering process for projects that have the potential for impact.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

170

4 - 31

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Community consultation is also called public or stakeholder participation, or community involvement.


There are a number of organizations that offer guidelines and practical advice on community
consult ation:
International Association for Impact Assessment (IAIA): http:ljwww.iaia.org/publications/
The International Association for Public Participation's (IAP2): http://www.iap2.org/
Codes of practice can also be found at government websites (the Environmental Prot ection Agency, or

Ministries of the Environment).


The stakeholders that may be interested in participating in the decision making process that goes into
the design and implementation of a project can include the public, local companies and organizations,
government agencies, and non-governmental organizations (NGO's). All of these groups should have
the opportunity to both learn about the project as it goes through the design process, and also have
their views and perspectives on the project heard and used as input to the design process. Public
consult ation can help the engineering team gather information about the service environment and
other aspects of the problem requirements. Consultation can also help them identify policies,
standards, licences, permits, and other approval processes that they will need to complete the project.
Community input can aid in the development of impact plans, and improve the quality and effectiveness
of a design.
Working with the community through all stages of the project may improve the community support of
the project. However, even if full consensus is not achieved, an open, honest, and t r ansparent process
can assist in the building of trust and improve understanding on al l sides of the issues involved.
Communication with the public should begin early in the design process, and continue through

commissioning of the technology. Commissioning means getting a plant or system up and running after
it has been constructed. Idea lly the engineering team will follow up with the stakeholders after the
design is implemented to assess the impact and address any lingering issues. In a sense, the community,
especially in public work projects or plants, should be part of your team.
Some best practices for community consultation (adapted f rom [3) and [4]):
Welcome and encourage appropriate community participation

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

171

4 - 32

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Consultation is a two-way communication process; it involves teaching and learning, telling and
listening
Consultation is useful at every step in the design process
Consultation should be open to everyone and honest
The more significant the potentia l impact, the greater the need for more frequent, and deeper
participation
Don't "dumb down" information for people, but communicate at a level and in terms that are
understandable and respectful of your audience
Address conflicts early and use mediation if possible to resolve these
Include the cost and time for consultation in your project plan

Advanced Material

Methods for encouraging participation (adapted from [3) and (4)):


Open house or exposition: show posters and exhibits, have information flyers or brochures
available, and people there to answer questions, listen and take notes, and explain the project.
This can be a simple as a table set up i n an effective location (e.g. near the site of the planned
design installation or at a local gathering place such as a shopping center).
Public forum or meeting: usually involves a presentation by the project team followed by a
question and answer period.
Discussion groups: opportunity for a smaller group of people to sit down together and discuss
some aspects of the project in more depth. Types of discussion groups can include: advisory
groups, task forces, consultation groups, focus groups, etc.
Workshop: a short course that also actively involves the participants in the planning process
Surveys and interviews: These are particularly useful in the post-implementation phase to get
feedback on how well (or not) the technology is functioning for people. Surveys and interviews
are usually carried out by professionals in the social sciences and business, not by engineers.
Newsletters
Newspaper stories, public notices, and websites
Bargaining, mediation, or negotiations: generally used to resolve conflicts or disputes.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

172

4 - 33

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

To be effective, a combination of methods should be used. Also, if it is feasible, they should be repeated
more than once to reach and get feedback from as many people as possible.

4.6.

Desianinq for the future

Considering the environment and communities in our design process is not just the right thing to do.
The consequences of neglecting these important considerations can have serious consequences both in
the near term and into the future. Neglecting potential impacts of this nature can result in lawsuits now
and on-going liability in the future. In addition, it can impact negatively on the reputation of the
company and your personal professional reputation as an engineer. Technical failures and
environmental disasters can also result in substantial public disapproval which is sometimes translated
into intensive legal regulation of an industry. While the intention of regulations is generally positive, to
protect the environment and public health and welfare, the implementation of regulations or an
overreaction in the wake of a disaster, can constrain technical enterprise significantly. Although these
negative consequences may be important motivators for engineers to consider the environment in the
design process, there are also some extremely positive reasons for including this in your thinking.
There are many positive reasons for taking broader issues into account in the design process. First, it
adds value to what you do in the world as an engineer. Not only are you creating a technology that w ill
have use, but you are also doing it in a way that you know will have the minimum possible negative
impact on the earth. Some companies actually choose to reduce their profits in order to adhere to a
corporate dedication to environmental ideals. This is not because they are economically inept. They
have done the projections and realize that sacrificing some profits in this way has an overall positive
impact on the company's reputation which they believe will have a positive benefit on their sales. This
is another example of a reason for designing for sustainability. And there is a growing sector of for

benefit companies that seek to maximize benefits for society, the environment, and economics rather
than being driven by profit motives alone.
The potential payoffs for thinking though the long term consequences of a design can be substantial. It
was estimated, for example, that Toyota was losing about $10,000 on every new Prius they sold when

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

173

4 - 34

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

they first marketed this hybrid vehicle. However, the result was that Toyota was the f irst company to
grab a large share of a potentially very lucrative market in hybrid vehicles. Their strategy counted on
increasing energy prices and growing regulations on C0 2 emissions that would lead to increased
consumer interest in fuel efficient, low carbon emission transportation. Their push into this technology
led to other companies bringing hybrids to market, and now consumers have a variety of hybrid vehicles
to choose from. In this case the economics incentivized a design alternative with a lower environmental
impact.
Sometimes a good design alternative from an economic perspective is also a good choice for the planet.
However, whether the "greenest'' alternative is the best economic choice or not, environmental impact
is always an important aspect of the design process. As a profession, engineers have an obligation to
examine the long-term environmental, social, and human consequences of design projects and factor
these considerations into decision making because future generations will have to live with the
outcomes of what is being designed now.

4.7.

Innovation opportunities

Taking into account environmental and societal issues in design can be difficult because there are
competing stakeholder interests to consider. A business which is renovating their offices may want to
use a recycled f looring material to reduce environmental impact, but ifthe material costs much more
than standard flooring they may decide that it isn't worth it to go with the "green" product. As
engineers you will face these types of decisions frequently and you will need to balance the competing
interes.t s ofthe stakeholders on a project. It can feel like environmental considerations, and issues

brought forward from a local community are j ust adding more constraints to already difficult technical
problems.
However, if you view these issues not as negative constraints, but rather as opportunities for innovation
then you have the opportunity to conceive of creative solutions that you might not otherwise look for.
An example of this is H-1 in Hawaii, a highway that cuts across the island of Oahu. The construction of
this highway was delayed by decades because of the impact it would have had on the natural
environment and because of community concerns. Only after the highway was re-conceptualized was
the project continued. Instead of trying to push through a plan that would have substantially impacted

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

174

4 - 35

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

the land, an innovative design was developed that re-conceptualized the highway as a bridge spanning
the sensitive areas.
By listening to the communities that are impacted by a design, and by including sustainability in your
thinking process, you have the opportunity to develop innovative solutions that work better from
multiple perspectives. When this is possible you are doing a better job as an engineer for your clients,
for the planet, and for future generations.

Learning Objectives:
By the end of this chapter you should be able to:
Recall and define the important terms introduced in this chapter
Explain the essential concepts in the chapter and how they are utilized in, or relate to, the
engineering design process
Given two alternative design solutions, compare and contrast the solutions using:
o

A simple "three R's" approach

A basic lifecycle assessment method

Describe, compare, and contrast, at a basic level, alternative approaches to design for the
environment
Explain the circumstances when community consultation is important in a design project and
why
Identify best practices in community consultation, and methods for implementing these
practices
Summarize the advantages and the challenges of taking the environment and community
considerations into account in design
We hope this chapter will enhance:
Your interest in the impact of your professional work on the environment and communities
Your ability to document the potential impacts of a design such that you can explain and
discuss them with others
Your knowledge of how you incorporate new information into your work to enhance the
quality of an environmental impact analysis
Your awareness of the responsibility our profession has to consider the environment and
communities in our design work
Key Terms:
Conservation of mass

Biodegradable

Conservation of energy

Renewable

Reduce

Reuse

Recycle

Life cycle assessment

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

175

4 - 36

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Life cycle diagram

Goal definition and scoping

Inventory analysis

Impact analysis

Improvement analysis

Functional unit

Midpoint assessment

Sustainable

Industrial ecology

Ecological system

Preventative engineering

Three R's

Scope

List of Pictures
1.

Conservation of mass

2.

Conservation of energy

3.

Schematic of the energy cascade showing electricity or chemical energy cascading down a water
fall to high temperature heat and then to low temperature heat.

4.

Cartoon of an engineer comparing two systems.

5.

Generic life cycle diagram

6.

Life cycle diagram for ZipZap soda

7.

Cartoon illustrating midpoint assessment concept

References
[1) Scientific Applications International Corporation. Life Cycle Assessment: Principles and Practice.
National Risk Management Research Laboratory, Office of Research and Development. Cincinnati, Ohio:
U.S. Environmental Protection Agency, 2006.
[2) The World Commission on Environment and Development, Our Common Future. Oxford University
Press, 1987.
[3) International Association for Impact Assessment (IAIA) {2009), publications [Online) Accessed August
22, 2011. Available: http://www.iaia.org/publications/
[4] The International Association for Public Participation's {IAP2), homepage [Online) Accessed August
22, 2011. Available: http://www.iap2.org/

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

176

4-37

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Chapter 5: Critical Thinking


Table of Contents for this chapter

5.1.
5.2.
5.3.

Learning Objectives for this chapter


Introduction to Critical Thinking in Design Engineering
Useful Critical Thinking Concepts
5.3.1.
Understanding frame of reference, bias and purpose
5.3.2.
Skeptical thinking
5.3.3.
How to evaluate a source of inf ormation
5.3.4.
Obstacles to Objectivity
5.4.
Critical Thinking and your Design Documents
5.4.1.
Project Requirements show a clear and detailed understanding of the problem itself
5.4.2.
Multiple solutions and criteria f or evaluating them in the Conceptual Design Specification
5.4.3.
Committing to a solution: the Final Design Specification (FDS)
5.5.
Reflecting on this chapter: assessing yourself and planning improvement

5.1.

Learning Objectives for this chapter

This chapter will begin by introducing some basic concepts of Critical Thinking that relate to Design
Engineering. It will then track those concepts through the design process and some sample documents.
By time you complete this chapter, you should be able to
Analyze a problem from multiple perspectives
Identify and represent multiple perspectives in an engineering design problem
Evaluate information and its sources in order to use it effectively
Identify bias in both in both information sources and your own communication
Generate a number of equally valid solutions to a design problem and assess them according to
criteria you define in relation to design processes
Commit to a solution whi le identifying its benefits and challenges
Evaluate your own process and predict strategies for improvement

5.2.

Introduction to Critical Thinking in Design Engineering

Simply put, Critical Thinking (CT) is the ability analyze a situation, idea or problem for yourself: to come
up with your own unique ideas about it. It is important to develop this abi lity in order to deal with
situations in which there is no single right answer, even though there are, in fact, wrong answers. It is an

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

177

5-1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

ability you need, i n addition, for situations in which there is no set procedure and you cannot just
" follow the rules."

Critical thinking and engineeri ng design are natural partners. There is no perfect template or procedure
that generat es the perfect design, any more than there is a single design solution . Because even simple
design problems can i nvolve multiple competi ng obj ectives (e.g. high quality, fast and low cost), the use
of critical thought at every design step will increase the li kelihood that you select the best of your
alternatives and maintain the credibi lity of yourself and your team . Fortunately, the d esign pr ocess has
many established techniques that actually provide a structure for critical thinking, so that it helps you
simultaneously develop your critical thinki ng skills along w ith your design skills. Just as critica l thi nking
considers a problem from multiple perspectives, engi neeri ng design takes into account stakeholders,
thei r concerns, service environment and human factors, as well as economic, environmental and social
i mpacts. Both critical thi nking and engi neering design generate a number of alternative solutions to
choose from, and both determine objective criteria w ith to choose from the alternative solutions.
In critical thinki ng, you personally take responsi bility for a process in which you consi der a problem f rom
several perspectives, develop several alternative solutions and come up with an "evaluative judgment."
An "evaluative judgment" is not a "right answer." Rather, it is judgment based on criteria that you
develop . These criteria then help you support or j ustify your recommendations.
So, the purpose of this chapter is to i ntroduce critical thinking and show how engi neering design helps
to build this skill. While critical thi nking contri butes to sound design decisions, t he engineering design
process has decision making strategies that, in turn, develop critical thinking skills. It is a cycle that gives
as double benefit to engi neering students in d eveloping two sets of skills at once.

Contribute to good decisions in

Critical Thinking skills

The Design Process

.-------_
Which has strategies that help develop

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

17B

5- 2

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Figure 1: Critical Thinking skills and the Engineering Design Process


Because the relationship between critical thinking and the design process shows up in design
documents, this chapter will discuss the topic in relation to those documents. The chapter is divided into
two main sections:
An introduction to useful critical thinking concepts
How those concepts relate to engineering design
Finally, it shows how engineers use reflective practice, a part of critica l thinking, to p lan their own
constant improvement.

5.3.

Useful Critical Thinking Concepts

Critical thinking is a form of independent judgment which incorporates fair-minded ness, awareness,
objectivity and freedom from prej udice. You might agree that these seem to be very desirable qualities,
but how can you be sure that you are using them when making design decisions? The keys include:
becoming aware of personal values affect decisions by understanding frame of reference, bias
and purpose
using skeptical thinking tools to question and analyze information
evaluating sources of information
understanding the obstacles to objectivity that we all face
5.3.1.

Understanding frame of reference, bias and purpose

Frame of reference, bias and purpose are related concepts since they affect the objectivity of
information in similar ways. You may know the term "frame of reference" from physics: the perspective
of a viewer will affect the viewer's observations. It is also used, however, in a psychological way to
identify the coordinates of the perspective with which each of us views, and judges, the world. Your
frame of reference is how you, consciously and unconsciously, put together everything you learned from
others, observed and felt. This frame affects how you perceive the world, how you connect new ideas
and experiences to what you have previously seen, felt and known, in order to help you understand and
respond appropriately in your present life. Although a person's frame

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

179

of reference is connected to her

5- 3

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

or his sense of community, family, country and profession, each frame of reference is unique. The same
fact may be interpreted differently by different people because of each of their frames of reference.
Understanding your own frame of reference, and getting a sense of those of others, will allow you to
examine facts and ideas separately from their sources and evaluate them more objectively.
Frame of reference gives rise to another quality that affects objectivity and understanding and that is

bias. Bias specifically refers to the tendency to judge things in a certain way, due to the values a person
brings to the situation rather than due to the details of the situation itself. At its worst, bias is
recognizable as prejudice: it is the judgment of a person or their idea based on factors such as gender,
age, race or religion. No one is entirely free of bias, however, since we all have a frame of reference.
Therefore, we all have to work to minimize the interference of bias on objectivity. Being open-minded,
or reserving judgment, is a way of preventing: bias from interfering with an objective evaluation. Your
ultimate decision may agree with your bias, but good judgment comes from examining the situation
carefully and as objectively as possible before coming to a conclusion. Bias an impediment to that
process.
Finally, in addition to frame of reference and bias, a person's purpose will affect thei r objectivity.
Purpose can be defined as what you want to happen as a result of some action. Purpose can be
conscious but it can also be unconscious. We are not always completely aware of everything we want
and when we're not, our own actions may confuse us. So, being aware of what you want is a good thing
because it allows you to be in control of what you do. Being aware of what others want is a key to
understanding why they behave the way they do and why they give the information that they give.
A good example of purpose and information can be found in a website for a car manufacturer. The
purpose of the website is most likely to sell cars. Therefore, much of the information given will have a
bias. It will tend to emphasize the positive aspects of the car and minimize - or ignore - the negative.

However, some of the information will be useful, because it will be less likely to be affected by bias.
Therefore, if you are using the website for information, you have to determine which information will
more affected by the purpose and which information will be less likely to be affected. Some
specifications are likely to be quite dependable. They are measurements and are easily tested for
validity. Other kinds of information - exciting descriptions of performance - are much more difficult to
verify and much less likely to provide objective information. If a carmaker says an engine is a 4-cylinder,

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

180

5-4

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

16 valve design with 148 horsepower, then that information is far more trustworthy than the statement
that the car represents a new dimension in driving pleasure.
At least the purpose of an advertising site is obvious: to sell you something. Other sites may not be so
obvious but their purposes will still affect the validity and usefulness of their information. So the
question "what is the purpose of this piece of information" becomes more important the more difficult
the purpose is to determine. Critical thinking helps you overcome the problems of frame of reference,
bias and purpose in that it promotes taking many different perspectives into account. This is precisely
what you do, in fact, in considering stakeholders' concerns in a design problem. Thus, critical thinking
and the design processes work together to help you come up with objective solutions to design
problems.

5.3.2.

Skeptical thinking

Briefly, "skeptical thinking" is a process of questioning information. However, while skeptical thinkers
do not accept information without question, they do not reject it either. As a scientific thinker, you are
expected to be skeptical. Dr. Carl Sagan, a respected astrophysicist and science writer, considers
skepticism and wonder to be "central to the scientific method" [1). In science, he writes, ideas are
accepted with the understanding of their limits, margins for error and the possibility that they will be
disproved. Therefore, even accepted ideas are subject to question, challenge and testing.
You have probably heard the expression, "Don't believe everything that you hear'' or "Don't believe
everything that you read." At a time when we have an unprecedented ability to access more information
than ever before - information provided by an enormous variety of sources - it is good advice not to
believe everything you hear or read. Skeptical thinking is not only a valuable tool when doing research. It
applies in other areas as well. It is often important in generating and evaluating ideas, where it prevents
the premature rejection of a good idea or the acceptance of a bad one.
Skepticism is not about negativity or being disrespectful. It is not about using questioning to disprove
ideas just because you may not like them -or the person who suggests them. It is also not about
rejecting authority. In fact, questioning an idea and coming to a deeper understanding of it may help
you develop a deeper appreciation of the decisions of people you respect.
Skeptical thinking is a term that goes back to the mathematician/philosopher Rene Descartes. He
formulated the idea of "systematic doubt." Systematic doubt means that you do not accept an idea as

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

181

5-5

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

valid without testing and retesting it - a process familiar to anyone in science. A skeptical thinker
accepts that an argument or hypothesis is true when there is sufficient evidence to support it . However,
if new and contradictory evidence is found, true skeptics are prepared to change their minds. When
asked what it would take to change his mind about the validity of the theory of evolution, the famous
biologist J.B.S. Haldane reportedly responded that the discovery of a single rabbit fossil in the
PreCambrian strata would be enough [2).
Some people confuse the word "skeptic" with the word "cynic." A cynic is someone who has a generally
negative view of the world and is unwilling to accept new ideas. In the absence of good evidence,
however, a skeptic merely withholds j udgment. The famous astronomer Ca rl Sagan reports that he was
often pressed to give his " gut feeling" about the possibility of life on other planets. He says he
responded: " But I try not to think with my gut... lt's really okay to withhold judgment until the evidence
is in." [1)
The reason people have difficulty making sound j udgments during the design process, and indeed in
everyday life, is that they are conf used about the difference between an argument and evidence. So if
someon e says that you should drink 4 1itres of pure water per day because it is critical to hydrate your
body t issues, you might mistake the plausibility of the argument for evidence that it is true. But an
argument is merely a hypothesis - a statement of belief that must be supported with testing. If you
really want to know if drinking 4L or water a day is healthy, you must compare a large group of people
that do this against an otherwise identical group of people that do not. This should be completely
obvious to anyone with even a hint of scientif ic training, but it is amazing that well-ed ucated people
often fail to make the critical distinction between a plausible hypothesis, and the actual evidence
needed to support it. Proof requires evidence, preferably from a number of sources or through strong
mathematical or experimental work.
Your f r iends will probably find you irritating if you get into the habit of requiring evidence for every
single thing they say. However, using critical j udgment and skeptical thinking is important when
important decisions are to be made. Here are a few techniques you can use to evaluate ideas and
information:

1.

Triangulate - find two or more sources that support the original source. Findings that are confirmed
by three or more sources are more reliable and credible than f indings in only one source. [see How
to Evaluate a Source of Information - next section).

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

182

5- 6

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

2.

Look for a counter-example - finding a contradiction to the information or idea you want to use
might seem counter-productive, but in fact, it isn't. A counter-example can show flaws or
weaknesses in ideas and lead you to much more productive research. Skeptics value this sort of
exploration since they are interested in testing all ideas as rigorously as possible.

3.

Be aware of inadequate or incorrect kinds of proof. Four frequent ones to watch for are:
a.

Confusing "correlation" with "cause and effect." Correlation refers to two variables that appear
and change together. For example, snow correlates w ith cold temperatures. However,
correlation is different than cause and effect. Certainly, it is clear that snow, though it appears
along with cold temperatures, does not cause the cold temperatures. If you're thinking, "But
wait a minute - cold temperatures cause the snow - you changed the order to prove your
point" then consider that cold temperatures can occur without the presence of snow. The cause
of snow is more complex than just col d temperatures.
{an often used example of this is the correlation between the number of religious organizations
in a town (churches, mosques, temples, synagogues, etc.) and crime (i.e. number of robberies,
assaults, etc.); they rise and fa ll synchronously. Why? Hint: The statistics look like cause and
effect, but it isn't.}

b.

Confusing "examples" for "evidence." A single example does not represent a proof. Moreover,
even a number of examples may not really prove something to be true. A scientifically minded
person should not be satisfied with any kinds of proofs that are not objective, repeatable and
statistically significant. ref prob&stats chapter

c.

Creating false dichotomies. A dichotomy is a two-sided idea. You create a dichotomy when you
organize a concept into two sides- right or wrong, for example. Dichotomies are often
expressed with the words "either-or." Dividing a situation into two choices si mplifies matters
considerably - but may over-simplify to the point that truth is compromised. Open-ended
problems generally do not lend themselves to this way of thinking. There isn't one right and one
wrong answer and thinking in those terms will lead you away from - not towards - sound
thinking!

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

183

5-7

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

5.3.3.

How to evaluate a source of information

You may not be used to questioning research material. That is, up until now, you may have searched for
a piece of information you needed for a project you were working on and when you found something
that seemed to fit, you used it . Critical thinkers, however, do not utilize information w ithout analyzing it
f irst. Just as they try to be aware of the factors that affect t heir own objectivity and credibility, they also
actively examine information f rom others. It is a best practice to analyze any information before
accept ing it. [Link to Research Worksheet ] The best way to do this is to formulate a series of questions
and try to answer t hem before using the information. Questions you might want t o consider include:

1. What is the authority of the source of information? If it is a person, on what basis does the person
know about what they are telling you?
a.

Is the person an expert? Expertise can be determined by


a professional designation. A doctor, p rescribing a
medication, for example, is more authoritative t han
your seven year-old cousin telling you how to cure

Of course one would not quickly


accept a doctor's opinion on how to
shingle a roof. You might not accept
an engineer's opinion either -like

warts. The authority, in this case, is not purely persona l.

doctors, engineers have

Doctors, like engineers and lawyers, a re a regulated

specializations and opinions outside

profession. They cannot practice medicine unless they

that specialization might be suspect.

are authorized to do so by a Medical Association.


Professional associations, job designat ions (such as professor, counselor) are external
designations of aut hority.
b.

Expertise can also be determined by other, less obvious factors. One is experience; a person
who has used a particular program for a long t ime probably has some good information about it.
For example, in a camera review, the w riter might say she has been a photographer for ten
years. This is an internal statement of authority; it is not, of course, 100% dependable, but
assuming that it occu rs in a sit uation in which there is no apparent benefit fo r the w riter in lying,
it would differentiate this review f rom one that has no internal statement of authority. In all,
though, when dealing with less obvious measures of aut hority, you must be aware of bias and
purpose.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

184

5- 8

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

c.

Sources of information in print or on t he web can also be examined for authority. There are
sources that use panels of obj ective experts to review their material. These tend to be scholarly,
academic j ourna ls t hat important researchers use to show t heir f indings. Many encyclopedias,

too, have boards of scholarly editors. But encyclopedias, such as Wikipedia, which invite the
democratic participation of the public, must be much more closely evaluated for bias and
validity. Fortunately, Wikipedia, for one, is self-regulating and posts warnings when information
lacks sufficient referencing. It also publishes a history of the development of each page. Other
information sources which lack external authorities include blogs and on-line reviews. These are
not bad places to get information, but t he authority of the information (the lack of an external
confirmation of expertise) must be taken into account.
2.

Is there evidence of bias? Can you tell, from the details chosen or from t he tone, what kind of values
the writer or organization may have? Sometimes newspapers, for example, are known for t heir
political viewpoint. Some are known to be conservative, while others have a liberal point of view.
Some newsletters include this information in t heir t itles - socialist newsletters frequently do this. A
communication from an organization with a particular political viewpoint as part of its name is
certain to have a particular point of view or bias. Clearly a source that announces its bias does not
represent an objective view, but the source may still be valuable because of its point of view. Bias
does not invalidate information; it only decreases t he obj ectivity of information. Understanding the
bias of a source of information allows you to use the information appropriately.
Here is another way you may be able to see the bias: if you know the topic is not one-sided, but the
info rmation given supports only one side- then, by definition, there is bias. Unbiased reporting of a
two-sided question would give both sides. With complex, or many-sided questions, a source of
info rmation will oft en identify their bias or point of view, because they cannot possibly represent all
sides fairly. Again, bias does not invalidate information.
It affects its objectivity.

Advertisements for electronic


components w ill often indicate their

3. What is purpose of the information? In some sources,


such as encyclopedias, the purpose is to give the reader
a basic introduction t o a topic. Textbooks are similar.
The purpose of certain handbooks may be to ensure
that a procedure can be followed successf ully and

performance under optimal


conditions. On the other hand, their
specification sheets will indicate
performance under specific
conditions which the manufacturer
w ill guarantee.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

185

5- 9

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

safely. Other kinds of purpose, however, can considerably affect the usefulness of information.
Take advertising, for instance. The goal of advertising is to get someone to buy something- it
therefore must interest and excite the buyer. It cannot lie in doing this; there are organizations that
ensure it does not. However, advertising often operates in a way that allows it to excite without
lying - it uses emotional language and emotional situations that excite the buyer without actually
saying anything about the product. Restaurants will show happy families but not discuss the health
value or fat content of their food.
Car advertisements are another example. They use color, speed and exquisite scenery to make the
potential buyer feel good about the prospect of driving the car. Further, they can present facts that
are only from one side or that seem to indicate more significance than they may actually have.
Consider the following claim: "Most fuel-efficient North American car in its class." What about other
car manufacturers outside North America? Who decides "class"?
Bear in mind, however, that selling is a slightly different purpose than advertising. Catalogues,
brochures, or websites that are set up to sell certain products often have less advertising and more
factual specifications, such as size, weight, color, or amount of memory. Specifications have to be
accurate or else the seller is going to have the items returned. So, purpose, like bias, does not
invalidate information. Understanding purpose allows you to use the information appropriately.
4.

Who is intended audience? The intended audience will affect the degree of complexity and the type
of the information. Only certain things will be reported to certain audiences. Factors to consider,
when answering this question, are: age of audience, amount of education expected, political
viewpoint. Ask yourself how well you match up with the intended audience or how well it matches
up with the audience you are writing for or speaking to. Often, in order to understand a concept, we
will begin with an article in Wikipedia. The article may be intended for an audience with far less
education than we have; the concept will be explained fairly simply. If we stop there, though, we
may be underestimating our needs as well as our audience's needs.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

186

5-10

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Fast!

Intended audience?
Economical!

5.

What are both the explicit and the implied meanings in the language used? This final question is
related to bias and to purpose. Language communicates in two distinct ways - explicitly and
implicitly. The first term refers to the obvious meaning of the words themselves. The statement ''To
get out of f ull screen view, press the 'Esc' key" has a simple, clear and obvious - or explicit meaning. If something is enlarged on your screen and the program allows you to use " Esc" to reduce
it , then pressing the key marked "Esc" will have the expected result. That's it. There is no ot her
" hidden" meaning.
Implicit meanings, on the other hand, are not so obvious - they are not on the surface of the words
and cannot be grasped easily or with intellectual certainty. Rather, they are felt or intuited. They
may be embedded in the particular words chosen. They carry double meanings - take for example
the sentence "You deserve some credit" on a credit application in a car ad
(http://www.ford.ca/app/fo/en/cars/focus.do#). The explicit meaning is that you can apply for a
loan. The implied meaning comes from the nor mal use for this sentence - it refers to someone
getting recognition for some achievement. Thus, the idea of taking out a loan is equated with
deserving something because of a particu lar achievement, as if a loan is an achievement to be proud
of.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

187

5- 11

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

People are becoming increasingly sensitized to the effect of the implied meanings of words and so it
is important to be aware of them in order not to inadvertently insult your audience, especially when
the implied meanings carry value judgments. These are not always obvious. For example, certain
terms for disability have fallen out of favor: these include the words " cripple," "handicapped" and
even "blind." In many cases, these have less to do with the words themselves than with ways they
have been used over t ime. Take "blind" for instance. It literally refers to fairly complete vision
impairment, but it has also been used to refer to ignorance or neglect, as in "the politician was blind
to the needs of his constituents." In such uses, it became derogatory and that negative feeling then
transferred back to people with impaired vision. Becoming aware of the implied value judgments in
language allow you to understand information in all its dimensions.
Implied meanings can actually directly contradict explicit meanings. A good example can be found
when a tone of voice is used to change the intention of the words, as when someone says "That's a
great idea!" in a way that indicates the person really feels the idea is worthless. This extreme
example shows how important it is to ask "what are the implied meanings?" If they contradict the
explicit meaning, and you are not aware of it, you may end up using information that says
something other than, or even the exact opposite of, what you intend.
This is particularly important if you are dealing with people from a different cultural or religious
background than your own. An acceptable phrase or mannerism in one culture can be derogatory or
insulting in another.

5.3.4. Obstacles to Objectivity


Hard as we try, we cannot always be as objective as we'd like. Some attitudes that get in our way
include:
the belief that there is a right answer and that someone knows it;
the feeling that it is rude or disrespectful to question authority;
the feeling that you will betray your own values if you consider an idea that is contrary to deeply
held beliefs;
dislike of the person or source of the information;
the dislike of bad news or information that is hard to accept;
fear of asking a "silly question", or one that is perceived by others as being silly.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

188

5-12

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

There is no right answer. Your task, in design and critical thinking, is to examine a problem in depth,

generate alternative solutions and consider them according to criteria. You must make a choice and
then justify it. There is no single correct answer. Developing critical thinking is not like learning a formula
and applying it to a given problem. Open-ended problems have no such certainty and looking to the
professor, supervisor, teaching assistant or client, to give or confirm a correct answer defeats the
purpose of the exercise, which is to generate o riginal but feasible solutions to problems. Even clients
who seem to have a solution in mind will benefit if you are able to increase their understanding of their
problem and appreciation of alternative solutions.
If you feel it is disrespectful to contradict the client or question authority, then consider the following:

Simply repeating what the client says because you feel it is the right answer is not very helpful. It
is not giving the client anything new.
Not asking questions may lead you to making mistakes because you do not truly understand
something. So, while you might be trying to be respectf ul, you might also be underestimating an
authority who wants to help you to understand and welcomes questions that will increase your
knowledge.
So, ask yourself, when dealing with information from authority:
1.

Do I believe this j ust because it comes from an authority (or the client) or can I f ind some
evidence to independently back it up?

2.

When I repeat something I have been told, do I really understand it? Can I put it in my own
words, relate it to my own sense of the world? Am I adding something to it by considering it
critically?

Of course, it is possible to ask a question in a disrespectf ul way and that is why you must develop
professionalism. [Link to Developing a Professional Voice and Creating Trust with your Client, Supervisor
and Team]
While it is important to have personal values, you have to understand that not everyone's values agree
and seeing a design problem only through the lens of your own values may prevent you from
underst anding the way others see the problem. This, in turn, may result in you coming up wit h a
solution t hat does not work for all who are affected by it - and may even be damaging for some.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

189

5- 13

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

So, when dealing with ideas that you either agree with or disagree with, due to your own values, ask
yourself:
1.

What objective evidence is there to support or contradict this idea?

2.

How can I see this from another person' s point of view? What values of theirs would lead to an
idea such as this? Is there a context where the different ideas make sense, and is t hat context
part of the environment for which the ideas were intended?

3.

If, for the purpose of argument, I accepted the other person's values, how would this idea be
useful to me and to the world? What advantages are gained? What advantages are lost?

Disliking another person is a common reason for not accepting their ideas. But f inding a way to get
around this tendency will not only help you become more open-minded and respectf u l, it will also help
you see more ideas than you could have come to on your own.
There may be an idea that would make you feel badly if it were true and so you may choose to deny it.
In personal relationships, you may have had the experience of someone you t rusted or cared for doing
something t hat hurt you in some way. You may have said, at the time, "I can't believe it" or "It j ust
couldn't be true." Some ideas take some getting used to, because they feel bad. Separating an idea from
the feelings it causes will enable you to more objectively evaluate its truth.
You can combat the fear of asking a "silly'' question by considering the consequences of not asking the
question and not knowing the answer. Going ahead when you do not understand something can cost
you marks on an assignment, and can cause real damage in professional life.

5.4.

Critical Thinking and your Design Documents

Critical thinking has a natural place in the sequence of design documents:


Your ability to look at a problem f rom multiple perspectives is shown in Project Requirements
Your ability to generate a number of solutions and criteria for choosing among them is shown in
the Conceptual Design Specification
Your ability to commit to a solution and justify your choice is shown in the Final Design
Specification

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

190

5- 14

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

5.4.1.

Project Requirements show a clear and detailed understanding of the problem itself

Engineering design begins with critical thinking. The engineer is presented with a problem to solve. It
may be in the form of a Client Statement or Design Brief. This is only a starting point, however. The
engineer has to analyze the statement and do research to evolve a more accurate and complete
understanding of all aspects of the problem. [link to Design Process] The engineer uses crit ical thinking
to ask, and answer, a series of questions, beginning with, "If this is what I know about the situation,
what else do I need to know?" Fortunately, engineering design has a structured approach to answering
this question. Engineers ask a series of related questions:

1.

Has the client expressed the wants and needs ofthe project completely and with technical
accuracy? Clients often are so familiar with the situation that they do not fully express the
problem details. Sometimes they are unfamiliar with the possible solutions and may have
already decided, based on inadequate knowledge, what the solution should be. It is up to the
design engineers to determine how well the problem is posed.

2.

If this is one perspective on the problem, what are some other perspectives? [Link to
Stakeholders] Answering this question is a way to overcome the effects of bias in solving a
design problem. By taking into account multiple perspectives, including their biases, you cancel
out some of the effect of your own and your client's biases.

3.

What "gap" is the client trying to fill? What exactly is missing in the world or, if there are existing
solutions to the client's problem, what is wrong with them? What is the client trying to achieve
that existing solutions do not do?

4.

What has to happen, in engineering terms, for the client to get what they want? [Link to
Functions, Objectives and Constraints] This question has many related questions that should be
answered. What exactly is the engineering in this design? What will it do? What are the qualities
it will have to have in order to be working effectively? How will we test it to know that it works?
Might the design have problematic side effects?

5.

What kinds of environments will the design operate in and how will those environments affect
it? [Link to Service Environment]

6.

What rules and regulations apply in this kind of situation? [Link to constraints and Regulations,
Standards and Intellectual Property]

7.

Finally, how can I ensure that this design works well for people, society and the environment,
increasing benefits and limiting damage? [Link to Human Factors, Environment, Economics]

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

191

5-15

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Once you have answered these questions, you can reformulate the Client Statement or respond to the
conditions of a Request for Proposal with new and fresh ideas that add value to what you were given. In
fact, the final questions you should ask yourself, when submitting a Proposal or Project Requirement is,
"Have I added value'? How much value'? What kinds of value'?"
5.4.2.

Multiple solutions and criteria for evaluating them in the Conceptual Design Specification

As well as looking at a problem f rom multiple perspectives, critical thinkers come up with a variety of

solutions and create criteria for choosing among them. Once again, the engineering design process
Concept Generation and Concept Selection techniques help develop and improve your critical thinking
skills. [Link to Concept Generation and Concept Selection] In presenting your process to your TA,
supervisor, Proj ect Manager or client, you show your degree of critical thinking by making clear how you

adapted the technique to the specific situation at hand.


The first step in generating a number of valid solutions requires creative thinking [Link to
Brainstorming]. Each idea, however seemingly inappropriate or strange, should be carefully recorded in
your engineering notebook. It might be tempting to have one person do all the note-taking, but you
should always make a few persona l notes as well. You can never tell when a small detail that only you
noted wil l become very important. It is always valuable to record your own impressions.
Once the ideas have been generated, they have to be organized into coherent design solutions [Link to
Design Selection Processes]. Just as a Critical Thinker would look for many different solutions to a
problem, a design document Link to CDS provides multiple, valid designs. Each design should
represent a different approach to the problem, a different trade-off between obj ectives. Each solution
should therefore provide the reader (supervisor and client) with unique information about how the
problem could be solved. The information created by the development of multiple designs can be
extremely valuable to the client and may cause the client to change some basic elements or constraints.
To ensure t hat your solutions give the client good information, ask yourself:
1.

Do these solutions give value to the client'? What unique information does each provide'?

2.

What are the unique trade-offs of each solution'? What are its benefits'? What are its challenges'?

If all of your designs are, in fact, equally valid, then the decision about which to implement is not going
to depend on an absolute value - one being "best" in all ways - but rather on agreement between the
design team and client about which trade-off between objectives works best for the client at this

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

192

5- 16

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

particu lar time. The success of your decision making process will depend on how well you defined
functions and objectives (designs that do not meet constraints are automatically eliminated) and how
well you measured the way each design solution meets those criteria. Be aware that you may have bias
that is not shared by your client and you will have to take responsibility for that. For example, as
engineers, you may consider safety of paramount importance, but your client might consider cost more
important than safety. You will have to convince your client that a design that costs more but is safer is a
better idea than one that is cheap but more dangerous. (You may use evidence from actual cases
showing how, due to costly recalls, the safer solution is also the less expensive one over t ime.)
Do not be surprised if, when your client reads the document associated with design generation and
selection (Link to CDS], she or he gets new ideas and modifies some earlier decisions. This means that
you have provided new information with your design alternatives and have illuminated aspects of the
problem your client had not considered before. This is a valuable contribution you make to your client. It
can be very appreciated and make for an exciting design process. It also shows that you understand the
problem well; the client will understand this and increasingly trust your work.

5.4.3. Committing to a solution: the Final Design Specification (FDS)


Committing to a solution results not from having found "the right answer," but from determining the
solution that best balances the needs of the client, society and environment. You have reached this
solution through thorough understanding of the problem, the development of appropriate criteria for
judgment, examination of a number of alternatives in terms of these criteria and consultation with the
client, as well as your supervisors.
Once you are committed to a solution, and you have the agreement of your client, you can detail as
objectively as possible what it will require for implementation and any consequences that
implementation will have, economically, socially, politically and environmentally. The two key questions
are: what are all the issues the client must be aware of and what am I telling the client to do about each
of these issues? You should also ask, and answer, questions about the economic, environmental and
social consequences of the design.
Economics - what are the costs and when will the client have to pay those costs? [Link to
Economics Section]

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

193

5-17

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Environment - over the lifetime of the solution, when and how does it damage the environment
and when and how does it benefit the environment? Can the negative effects be lessened and
the positive effects increased? How? [ Link to Chapter on Environment]
Social Impacts - your ability to write this section will be enha need by broad reading in such
subjects as sociology, psychology, and history, particularly the history of technology. Even
fiction, newspapers and blogs can give you valuable insights about how humans and human
organizations respond to change. Understanding, and being able to clearly explain, social
impacts will help you, as an engineer, to take an effective leadership role in society. Two
questions you might ask, to help you think about your solution's social impact, are
How does this solution change its stakeholders' lives or business practices?
What kind of change would occur if this solution was adapted to a different situation?
One example that might help show social impact is the automated voice message, a telephone
message that use a pre-recorded voice or a computer generated voice. These are most frequent
when you phone a large organization, such as a service centre for computer hardware or
software. Your call is answered by a voice that sounds human and gives a number of options.
Depending on the situation, you may be able to get the information you require or complete the
action you wish to do without ever speaking to a living human. The voice on the other side of
the line only responds to predetermined inputs, something you press on the keypad or a word
you say clearly.
The benefit of automated telephone services is that they often provide information more
quickly and efficiently to a large number of callers than a limited number of h uman operators
could. But changes in behavior result from the fact that the automated voice is not human and
does not respond to unexpected variations, anger or rudeness. People who get used to speaking
to pre-recorded or computer generated voices may come to feel that what they say on the
phone is not heard or does not matter. " Manners" or rules of behavior are not reinforced in
these situations. Does that mean that everyone will become rude, swearing at the phone
whether it is a recorded or live voice on the other side? The effects may not be that dramatic,
but clearly an automated human voice does dehumanize human interactions. And that is a
social consequence.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

194

5- 18

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

5.5.

Reflecting on this chapter: assessing yourself and planning improvement

Critical Thinkers question themselves as much as they question others. They seek to view themselves as
objectively as possible in order to improve their chances of achieving worthwhile goals in life. They ask
themselves questions about what they have done and create personal documents which they might call
something like Lessons Learned. This kind of activity is called reflective practice or reflective learning. It
is not used to make yourself feel bad and so it should not be looked at as a way of just identifying
mistakes or blaming yourself. Rather, reflective practice takes events from the past and uses them to
plan the future. ref Project Management>Project Lifecycle>Project Closure
A Lessons Learned document asks the following kinds of questions:

1.

What was the situation?

2.

What were we trying to achieve?

3.

How well did we do? With this question, you have to determine the measure you are using. If
your goal was to do as well as possible on an assignment, then a reasonable measure might be

the grade you received. But if your goal is to overcome a particular problem from a past
assignment, then the measure might be the comments of the marker.
4.

What did we do that was effective in achieving our goal?

5.

What problems did we have? These may have to do with not achieving the goal or with sideeffects. For example, you might have achieved your goal of getting a high grade in an
assignment one course, but at the expense of studying for a midterm in another course. When
describing problems, it is important to use objective, value-free language so that you can
identify the problem in a way that is both accurate and allows you to develop a strategy. It is

more useful, for example, to write that you had problems with time management or that you
had a lot of resistance to working on this project than to write " I was just so lazy." It is a lot
easier to develop strategies to improve time management or overcome resistance than it is to
fix a character flaw such as laziness. Besides, it probably wasn't even true that you were lazy.
Engineers and engineering students tend to be very hard working, but they may have too much
to do or put off things they do not like to do or be ineffective in their use of time.
6.

What could we have done better? This question does not address problems, but rather, it also
addresses aspects of the situation that worked pretty well. However, with the aim of constant
improvement, you can try to identify areas to work on. This kind of question is important for

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

195

5-19

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

programmers or manufacturers responsible for developing new versions or models. The o ld


version may work well. How could it work better?
7.

What strategies can we use in the future to overcome the kinds of problems we had or to
improve even further on our success? Strategies can be short term or long term. You may
choose to examine a strategy using design principles, looking at it in terms oif what you want to
achieve and the factors that might affect your success. You might develop a variety of strategies
and choose the most likely from them.

Key terms:
Bias

Prejudice

Critical thinking

Purpose

Dichotomy

Reserving judgment

Frame of reference

Skeptical Thinking

Personal values

Triangulate

References:
[1] C. Sagan, The Demon-Haunted World: Science as a Candle in the Dark. NY: Ballantine Books,

1996.
[2] C. Wallis, "The Evolution Wars," Time Magazine, Aug. 7, 2005.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

196

5-20

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Chapter 6: Communicating in the Engineering Environment


Table of Contents for this chapter

6.1.
6.2.
6.3.
6.4.

6.5.

6.6.

6.7.
6.8.

6.9.

6.1.

Learning Objectives for this chapter


Introduction to Communicating in the Engineering Environment
Gathering and analyzing information
Developing a professional voice and creating trust
6.4.1.
Efficient plain language writing:
6.4.2.
Figurative or "advertising language" and how to avoid it
6.4.3.
Bias free language
6.4.4.
Making and Supporting Statements Effectively
Three categories of statement
6.5.1.
State your idea
6.5.2.
Explain your idea
6.5.3.
Support your idea with evidence
Organizing your thoughts
6.6.1.
Organizing a document
6.6.2.
Basics of organized paragraphs
6.6.3.
Using Lists
Basics of effective sentences
Person-to-person Interactions and Oral Presentations
6.8.1.
Professional demeanor
6.8.2.
How to organize presentation as a whole
6.8.3.
Audience and purpose in presentations
6.8.4.
Effective slides
Reflecting on this chapter

Learning Objectives for this chapter

This chapter discusses engineering communication in relation to design documents and presentations. It
discusses the kind of objective language and logic engineers value in documents and presentations. By
t ime you complete this chapter, you should be able to
Gather, evaluate and utilize appropriately information from a variety of sour ces
Explain design your process clearly and concisely to a variety of readers at different technical
levels, using language that is clear, explicit, objective and free of bias
Support statements with explanations and evidence that makes use of appropriate scientif ic
principles or published research
o

Recognize legitimate versus il legitimate uses of intellectua l property

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

197

6-1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Document research appropriately

Organize a document in a logical manner appropriate to engineering

6.2.

Organize a document or presentation overall

Organize logically at the section level

Organize logically at the paragraph level

Organize logically at the sentence level

Introduction to Communicating in the Engineering Environment

Good engineering design depends on your ability to think through a problem and generate and present
a high quality solution when there are numerous right and provably wrong answers. Your ideas and the
thinking behind them are only as good as your ability to express them to others. Like showing your work
on a calculus exam, communicating not just the solution, but also how you arrived at the solutionevidence, methods and reasoning - enables the reader (client or supervisor) to agree that you have
provided the best possible solution for the situation.
Communicating your evidence, methods and reasoning draws upon qualities you already have and are
continuing to develop in your engineering program:
a problem-solving approach that makes sense,
a method for gathering, analyzing, choosing and integrating information,
a tendency to assess yourself and try to improve your methods.
Your problem solving approach started naturally, with the kind of intellectual curiosity you probably take
for granted. Adding in fair-mindedness, objectivity and respect for the ideas of others allows you to
widen the scope of your curiosity from small solitary endeavors to larger projects in the world, projects
dependent on group collaboration for success. These will test your ability to be reasonable, separate
truth from deception and cope with complex p roblems. Solving complex problems, in turn, will require
your persistence and tolerance for ambiguity, or situations without clear definitions. All of these
characteristics will help you develop a systematic, analytical way of thinking through and communicating
information.
The purposes of a design document are:

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

198

6-2

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

to attain trust and agreement on the nature of the problem


to enable others to understand and appreciate your ideas
to persuade others to agree to your proposed solutions
to record your reasoning for later
The clients must agree with your definition of the problem, its scope, the time that it w ill take to
complete and its cost. If the document fails to give them what they need to know in order to agree to
allow you to continue to the next step of your project, then the document has failed. If they do agree,
but the document has caused them some discomfort or doubt, then it is unsatisfactory. If it convinces
the reader to continue with the project conf idently, then it is successf ul. If the document creates the
reader confidence in you, as an engineer, and also excitement about the project and the ingenuity you
are showing in your approach, then your document is as you should intend.
The ability to convincingly present your ideas to your client is critical to your success as a design
engineer. Yet, as an engineer, you will be limited as to the tools you can use to prove to your reader or
audience the validity of your ideas: you are expected to show you are logical, objective, scientific,
mathematical and, most of all, absolutely honest and reliable. You may not use figurative, f lowery or
ambiguous language. Your writing and speaking must always be as clear, explicit and objective as
possible. They must engage and persuade at an intellectual level, not an emotional level. In order to
display this, your documents and presentations must reveal clarity of thinking, depth of analysis and
great perception about the problem to be solved, not only in its technical aspects but also in its human,
social, economic and environmental aspects.
Effectively communicating a design process breaks down into f ive stages:

1.

Gathering and analyzing information

2.

Developing a professional voice and creating trust with your client, supervisor and team

3.

Using objective language

4.

Making and supporting statements effectively

5.

Organizing your thought so that ideas f low in a way that the reader can easi ly follow

This chapter considers these five stages in written documents and then, in the final section of the
chapter, in oral presentations.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

199

6-3

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

6.3.

Gathering and analyzing information

The key point here is that you have to ask questions. When you are doing research, you have to ask
questions about the source of information and about the information itself. Gathering and analyzing
information is probably more challenging today than it ever has been - given the amount of information
that is now available - and when you are assessing information it is important to remember the key
concepts of frame of reference, bias and purpose discussed in the chapter on critical thinking. The web
gives you access to hundreds of websites all over the world, including personal websites, blogs, social
networks and organizational, industrial and institutional websites. Your university library gives you
access to millions of books and often allows you to download articles from important journals without
having to leave your home. Sorting through and choosing the most valid information can be difficult.
Critical thinking, however, develops tools that enable you to evaluate information and use information
appropriately. (Link to "How to evaluate a source of information"]
For the purpose of creating a rigorous process of validating information you use in support of your
claims, let's first assume there is no such thing as "general knowledge." Falling back on "general
knowledge" or facts "everybody knows" may seem convenient and easier than doing actual research but
it does not support your statements as credib ly as properly documented research does. Besides, if
"everybody knows" something, then your client already knows it and your repeating it does not give
your client anything new or valuable. Therefore, to support your claims you have to use data you have
generated in a reliable manner or located from reliable sources. The next challenge is to show that this
data and its sources are worth believing.
Information types range from personal information to general information, from advertising to selling,
from being aimed at the general public to being aimed at experts in a particular f ield . Each type of
information has its own, particular usefulness. In the following list, sources of information are ordered
by degree of authority and detail, from least to most:
Blogs or personal reviews
Websites
Encyclopaedias, Dictionaries or other common reference tools, (online or in p rint form)
Handbooks

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

200

6-4

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Textbooks and monographs


Bibliographies
Technical and professional journals
Technical reports
Patent s
Catalogues and manufact urers' brochures
Blogs, personal reviews, websites and online encyclopedias give good introductions to topics you may
be encountering for the first time. But they may not go into the subject deeply and, depending on the
source, may contain personal biases. Handbooks, textbooks and monographs go more deeply into
subj ects and are generally fairly objective. Bib liographies are compilations of sources for the more
detailed technical information you will f ind in technical and professional journals. Engineering has
hundreds of such journals with articles written by top researchers and practitioners. These articles are
intended for others in the field and can be technically extremely complex. However, journals that are
peer reviewed - that is, the articles are accept ed on ly after being reviewed by other experts in the field
- have a high degree of authority.
Finally, technical reports, patents and catalogues are rich sources of information. They provide
descriptions and specifications, accompanied by drawings and/or photographs, of existing engineering
systems, devices, tools, materials. They often provide information that is not available anywhere else.
Applying Critical Thinking is also important, since even catalogues and manufacturer's brochures could
have misprints or qualified information that might not apply to your design. In the latter case, you must
understand your design in order to determine if the information is relevant to it.

6.4.

Developing a professional voice and creating trust

Developing a professional voice means learning how to communicate appropriately i n the working world
- with business people, engineers and other professionals. Taking part in a design proj ect during your
university education is a way of practicing this. It is a preparation, or a rehearsal, for what you will
become as an engineer. You already have the tools for developing your professional voice and
demeanor; all you need is to become aware of the particular expectations of engineers.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

201

6-5

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

For engineering design projects, you will have to draw on your most businesslike personas. You will have
to dress and speak appropriately for different distinct situations: client interactions, supervisor or
project manager meetings, instructional situations with Teaching Assistants or professors and, finally,
meetings with team members. The number one rule in all these situations is respect. You show respect
be consistently being polite, ensuring that your language and your tone are not insulting in some way.
In order to develop your professional voice:

1.

Make yourself aware of the principles and rules around each particular kind of communication
task. Make sure you understand the rules and follow them. A business email, for example, [link
to email assignment] is not the same as a persona I email and if you do not appreciate the
difference and use language that is too informal, you may offend your client or the person you
are writing to.

2.

Use style guides [link to style guide]. If your course does not provide you with a style guide,
purchase a writer's handbook and refer to it frequently. There are appropriate ways of doing
everything, from writ ing a business email to formatting a slide for a presentation. Your client,
supervisor and grader will expect these as the basis of your communication. Knowing and
following appropriate engineering and business communication practices, as well as the
particular forms required by your course or company, are minimum requirements.

3.

Use tools such as agendas, notes, minutes, and your engineering notebook in order to keep
yourself on track. It is great to be spontaneous when you are out having a good time with
friends or family. But in professional situations, t ime is limited and you must accomplish what
you set out to accomplish as efficiently as possible.

4.

Be aware of your personal biases and do not rely on them for your decision-making. This is
almost the same as saying, "Always keep an open mind." In practice, it means ensuring that you
always separate ideas from the people or situation that generated the ideas so that you can
evaluate the ideas as objectively as possible.

5.

Avoid slang in all professional situations. Slang, or conversational English, uses popular
expressions that make language f un and colorful. The problem of such slang is that it is a way of
being extremely informal and the implied meanings of some slang expressions may be insulting
to certain groups. Since you do not want to accidentally insult someone, you should always use
plain, business-like language, whether writing or speaking.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

202

6-6

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

6.

Always ensure that your writing is grammatically correct, your sentences are logical ly structured
and that your spelling is correct. These details are almost never taught but al most always
expected. Poor grammar, sentence structure and spelling have a surprisingly negative effect on
your credibility- they give the reader the impression that you are careless, you do not feel that
the task at hand was worth the time to do properly or that you are unintelligent because you do
not know the basics of the language. If none of these things are true, then you do not want to
give the reader this impression.

Dressing appropriately is part of professional communication. You do not want to be dressed in a way
that is seen as unprofessional or disrespectful in professional situations. If you are not sure:
Ask. Often you can ask administrative assistants at the place you are going. Oo this respectfully
and thank them politely. (Since people depend highly on their administrative help, it never hurts
to be on good terms with the client's help, and with your own!) Regardless of whom you ask,
people will appreciate that you are making the effort to be respectfu l.
Overdress. For men, you can wear a jacket at tie. If you find you are overdressed, take off the
jacket. Still overdressed? Take off the t ie. Still overdressed? Roll up your sleeves. For women
dress in business attire with layers, or pack a work jacket in your bag to slip over what you are
wearing. People will generally be pleased that you showed respect by dressing better than you
needed to; they will take note if you did not dress well enough.

6.4.1.

Efficient plain language writing

In a report or an oral presentation, the engineer's purpose is to convince the reader or audience, as
objectively as possible, to follow a recommended course of action. It is not the engineer's purpose to
"sell" the reader or audience on the solution. The fundamental difference is this: the engineer's
argument must appeal to the reader or audience's mind. It is not an emotional argument. It is scientific
and objective. The engineer's argument appeals to, and promotes, sound judgment. In contrast, "selling"
or a "sale's pitch," as can be seen in much advertising, appea ls to the reader or audience's emotions.
Emotions, excitement, impulses can erode sound judgment and therefore eliciting them is contrary to
the obj ective of thinking clearly and thinking clearly is the key to developing and evaluating the best
solutions for engineering problems.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

203

6-7

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

6.4.2.

Figurative or "advertising language" and how to avoid it

If plain language is language in which the explicit meaning has far more effect than the implied meaning
[Link to Evaluating information-" What are t he explicit and implicit meanings?"], then figurative
language is the opposite. What it is implying is more important than what it is saying directly. Poetry is
an example of figurative language. When the p oet Robert Burns writes, " My love is like a red, red rose"
he does not mean that he is in love with a f lower. He intends readers to summon up all of their personal,
positive associations with roses - their beauty, fragrance, elegance, delicate textures - and imagine a
person who embodies these characteristics.
In this example, Burns is using a simile. It is a figure of speech that compares one thing with another, by
using the word "like." In many cases the two things are completely unalike - a human and a flower.
Another figure of speech is a metaphor - this compares two things more directly, by describing one as
the other. A common example of a metaphor is "user friendly" or "environmentally friendly." In fact,
since friendliness is a quality only found in living creatures- a friendly person, a friendly dog, a friendly
dolphin - this figure of speech cannot possibly be literal ly true. "User friendly" implies that something is
easy to use - perhaps intuit ive or familiar in some way. "Environmentally friendly" implies that
something will not harm the environment or perhaps will help it. Because these terms are vague and
imprecise, they are of no use to the design engineer. So, similes and metaphors are discouraged in
engineering writing.
What is more, the purpose of similes, metaphors or other kinds of figures of speech, is to create a
feeling. "My love is like a red, red rose" or "Environmentally friendly" are ideas that make the audience

feel good. That is why figurative language is so useful in advertising. It appeals to the emotions and
facilitates emotional decision making. Making decisions based on emotion, rather than intellect and
reason, is the opposite of good critica l thinking and sound practice in engineering. So, language that
appeals to the emotion is characterized as "advertising language" and, like figurative language, is
emphatically discouraged.
6.4.3.

Bias free language

Avoiding figurative language - metaphors and similes - and being aware of the implicit meanings of
words w ill do a great deal toward making your language objective and bias free. You will also increase

the acceptability of your language if you pay attention to, and use, the words that you r client or

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

204

6-8

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

supervisor uses in relation to social or political conditions with which you do not have a personal
familiarity. Finally, become aware of your own values and how they affect the way you talk or write
about topics such as religion, politics and economic conditions. Ask yourself if the words you use are
clear to others who have other beliefs or political positions or who do not agree with your beliefs.
6.4.4.

Making and Supporting Statements Effectively

In addition to ensuring that your language is objective, explicit, non-figurative and free from bias, you
must be certain that any statement you make is complete. That is, the statement give the reader or
listener enough information to both understand it and appreciate the evidence that supports it. The
explanation and evidence are what differentiates a "complete" statement from an opinion. Both are
original and unique to you, but a complete statement is supported by evi dence. An opinion comes from
feelings or experience. Until you have enough experience to be an expert, feelings are not as credible as
objective evidence. So, making a complete statement has three steps:

1.

State your idea

2.

Explain it

3.

Support it with evidence

These fundamental three steps form the foundation of effective communication. Once you have
established them, you can build complex understanding. However, if these three step s are not taken- if
the idea is not stated clearly, explained and supported, then no matter how complex, interesting or
worthwhile the rest of your message is, your reader or listener will find it difficult to follow and/or
appreciate.

Religious students who take religious studies courses in university are often surprised when they are not allowed
to use the Bible or Quran as a source for some assignments, even though they have studied those books in their
own lives. Rather, they must restrict their sources to what commentators have written about the great religious

books. The reason for this is that the students are expected to consider topics objectively from points of view other
than their own.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

205

6-9

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

6.5.

Three categories of statement

Let us consider three categories of statement, . There may be many more such categories, but these
three are relevant to your w riting:
1) Opinion
2)

Fact

3)

Claim

Opinions are of two sorts: (1) a statement of evaluation made by an expert and (2) a statement of a
personal feeling, value or judgment made by anybody. Obviously, in t ime, as a professional engineer
with experience and accomplishment, you will be asked for your opinion and your opinion will be
respected. Even then, you w ill know that, as an authority, your opinion is something for which you are
lega lly liable should it prove wrong. In the meantime, your opinions will be based on your personal
experience and/or frame of reference and therefore wi ll not be as objective or useful as facts or wellsupported claims. Therefore, you should avoid personal opinion when writing design documents or

making presentations: until you have finished your training and have professional experience, your
opinion does not have the credibility of an expert and personal opinion, based on individual values and
beliefs, cannot apply to situations in which those values and beliefs are not explicitly shared.
Facts are statements of truth. Like opinions, they have two basic varieties. Scientific f acts, laws, axioms
and principles are generally accepted and are supported by formulas or other well-known identifiers.
For example, if you are explaining the speed and direction of an object, you may refer to Newton's
Second Law of Motion or F=ma. It is expected that, at this point, you are well enough acquainted w ith
Newtonian physics that you do not need to look up Newton's Second Law of Motion.
The second kind of fact is one that is supported by research. That is, it is a "fact," something that
happened in history (such as the names of the w inners of the 1923 Nobel Prize in Medicine) but is not
part of your general knowledge. You find this information from web-sites, books, journals, magazines,
newspapers, unpublished theses or from interviews with people. Though you may make use of this kind
of information, it does not actually belong to you and unless you clearly identify its source, you will be
committing a form of misrepresentation very similar to lying. All disciplines, including the disciplines of
engineering, have their own standards for identifying sources. [link to References in Style Guide in Back
Pages] You will have to follow one of these standards when writing design documents. Over the course

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

206

6 - 10

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

of your career, you will likely have to follow several different standards, depending on the situation,
organization or journal you are writing for.

Claims are statements that require support. They are not opinions- that is, they are statements that are
not based in personal belief but rather result r rom an objective process or evidence. They are not true in
the way that facts are, because they do not directly result from the application of a scientific law or
mathematical formula. They are not events that actually occurred in history and for which there is
undisputed evidence. Rather, claims are statements that use science, mathematics and other evidence
to come to a conclusion or supposition. The better they are explained and supported, the more useful
they become.
Most ofthe statements that we make are "claims." We generally use facts to support our claims and
even if we are called upon to give our opinions, we usually treat those opinions like claims, explaining
them and supporting them with evidence. Therefore, learning how to make a credible claim - or a
"complete stat ement" is central to becoming an effective communicator.

6.5.1.

State your idea

State your idea right away, f irst thing, even if it is a technically complex idea. Writing or speaking this
way may be different than what you have learned or practiced; it is absolutely concise and gets right to
2

the poi nt Many writers or speakers don't want to make their point right away. They believe that the
audience won't understand it without background. They don't realize that t hey do have a short margin
to explain a difficult concept immediately after introducing it. So they launch into a long, detailed
background and the only reaction they get is that the audience asks, either out loud or in their head,
"Why are you telling me all this?" Worse, they may be repeating information the audience or reader
already knows; that will make the audience or reader bored and irritable reducing the effectiveness of
the communication. On the other hand, if the audience or reader knows where you are going before you
start filling in the background, then at least they know why you are telling them what you are telling
them.

Compare this, for example, to a mystery story or other f ictional work that tends to keep things secret, building to
a climax near the end of the piece.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

207

6-11

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

6.5.2.

Explain your idea

Once you have stated your idea, you have to explain it. You must define terms and fill out the details of
the ideas. Doing this has a double benefit- it reduces misunderstanding in your readers and allows you
to identify- and fill in- any gaps in your own understanding. If the statement of the idea takes one
sentence, then you will likely take two or three to explain it in more detail.
Graphs, diagrams, charts and other graphical objects can be used to help explain your idea. Often these
will be clearer to an engineer than textual explanations, although some text should always be used to
refer to and to draw attention to specific details in these objects.
6.5.3.

Support your idea with evidence

The difference between an opinion and a claim is that a claim can backed up with objective data . There
are three kinds of objective data that you will likely use, as an engineering student or engineer:

1.

Scientific method or principle

2. Your own data


3.

Other people's data or information gathered from research

The first category of proof needs little explanation. As an undergraduate or graduate student in
engineering, you are gaining an enormous amount of technical, scientific and mathematical knowledge.
This knowledge is characterized by well-known laws, axioms and formulas. As you progress, you will be
expected to know these and apply them naturally.
In time, you will do your own research and develop your own data. You will be able to use this data to
back up claims. But, even when you are generating your own data, you will have to d o some research
and this can be challenging. There are two key ru les you must adhere to:

1.

When using someone else's ideas, whether published in print or on a website, you must name
that person or organization. There are standard forms, in each discipline, for doing this and you
must learn those forms and use them as required [link to References in Style Guide in Back
Pages]. Any time you even quickly look at a website to clarify an idea, you must acknowledge it.
Not to do so can have devastating consequences in your school record or career; it is looked on

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

208

6 - 12

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

as plagiarism, a form of cheating in which someone tries to take undeserved credit for an idea
that really came from somebody else.
2.

The words that other people use belong to them in the same way as their ideas do. If you use
their words, you have to go beyond just naming who they are. You have to indicate to the
reader, genera lly with quotation marks"", that you are directly quoting the source. Once again,
not to do so can cause serious problems for you. This too is considered a form of plagiarism - in
this case the cheating lies in taking credit for someone else's ability: the ability to express
something well. Of course, a direct quote can be used if it is identif ied and documented
correctly [link to References in Style Guide in Back Pages). In engineering, however, direct
quotes are rarely used, since the words themselves are not as important as the ideas. Also, since
engineers take ideas and use them in new and original ways, they have to reword the ideas for
themselves. 3

6.6.

Organizing vour thoughts

In addition to clear, objective language and well explained and supported statements, your writing has
to be organized so that your readers can follow your ideas easily. Your documents must make sense as a
whole; they must contain all the relevant and expected sections. Within the sections, the paragraphs
must be written in a way that allows a reader to find information quickly and easily. Sentences, as well,
must have a logical structure so that, no matter how long and complex, the reader is. always clear on
what is happening in the sentence and who, or what, is causing the action to occur.

6.6.1.

Organizing a document

In many situations you will be given a template for organizing your documents. However, there may be
t imes when you have to work without a temp late or have to develop a template for your organization.
Any such template will have to deal, in one way or another, with the four basic issues related to proving

Another benefit of putting ideas into your own words is that this ensures you understand t hem or at least
accurately represent your understanding. Simply cutting and pasting a definition of "dynamic data storage" would
not guarantee that I actually understood what this concept means, much less how to incorporate it int o a software
program.

McCahan, Anderson, Kartschot, Weiss, and Woodhouse, 2011

209

6-13

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

that a decision is a good one - problem/context, alternative solutions, decision-making process, details
of implementation.
In this course we provide a model for a design document using numbered sections. [Link to Organization
in Back Pages] . The value of numbered sections is that they impose a hierarchy on the information in the
document and they also allow your supervisor to impose limitations on the level of detail, forcing you
find relationships between smaller details so t hat they can j oin together to support larger statements.
These "relationships" are the "thinking glue" that allows pieces of data to come together to become
large, effective ideas. Your ability to identify these relationships and show them clear ly is an indication
of another dimension of your intelligence, extending beyond your ability to solve a problem. They show
that you are not only able to solve the problem, but that you have a good understanding of why the
solution works and, by implication, how other, varied problems m ight be solved.
Generally, no more than three levels of subsection are permitted. This avoids situations where you get a
subsection with a number that runs to six or seven digits and has only a single sentence. Documents that
go to those extremes really benefit by a revision that combines these tiny sections into larger units that
show relationship between ideas.
Using this numbered format, begin by organizing the headings of your document. Make sure that the
headings and subheadings contain full ideas so that your outline not only tells you what the sections of
your document are but also what the content of that section is going to be. So, do not simply write " 1.0
Introduction." Write something that has real information in it, such as "1.0 Introduction - Increasing
Security of Financial Data at Cyberbank Canada ." Many engineering students are used to beginning with
an outline and find that it helps to keep them organized. Others prefer to start at the beginning and
write to the end, in a more intuitive process. The problem with the second, intuitive p rocess, especia lly
in group work, is that it makes planning more difficult and if you do not build in significant amounts of
t ime (and, at some point, an outline to organize what you have written) the coherence of your
document and intelligibility of your ideas will be compromised.
Specialized tools are available for organization, such as link to Freemind and link to
MindManager. You may want to use one of these if you f ind that you are constantly reorganizing your
ideas as the document structure evolves.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

210

6-14

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

6.6.2.

Basics of organized paragraphs

Your goal, when writing, should be to produce documents that can be read once, quickly, and grasped.
That is, though complex technical concepts may need some explanation, the paragraphs and sentences
should be, in themselves, straightforward. When you are writing, imagine that your reader is in a hurry,
is only looking for specific pieces of information and does not want to read the whole document, from
beginning to end. Write in a way that takes care of this kind of reader.
Paragraph size and structure helps. It is more difficult to find specific ideas in long paragraphs that have
many ideas mixed up together. Shorter paragraphs that deal with one idea at a time and announce the
idea at the start of the paragraph are much easier to search through for desired information.
You may have been taught two pieces of contradictory advice. One is that every paragraph must identify
and explore a single idea and the other is that essays should have f ive paragraphs. This form is used to
ensure that essays have more than one idea - hopefully, three ideas: one per paragraph, plus an
introduction and a conclusion. Applying the five paragraph essay form to a longer document will require
you to combine more than one idea or sub-idea into a longer paragraph so that the number of
paragraphs comes out right. This does not create an easy document to search through for a busy reader.
Thus, writing a f ive-paragraph essay is a practice you should now abandon unless specifically instructed.
Well, an organized, logical paragraph for a reader in the 21'1 century should be short, have only one idea

and fully develop it. An essay - or any other document- should not be limited by numbers of
paragraphs. It should have as many paragraphs as are required to fully identify every claim that supports
your main ideas.
You probably know about topic sentences, but here is another way of looking at them. If you adopt the
three-step approach to writing (statement-exp lanation-evidence), you will always put your main
statement in your first sentence. That will clearly identify to the reader what idea you are developing in
the paragraph. The reader, looking through the document for a single piece of information, will be very
grateful if you provide this handy road mark. Next, you explain your idea. That will take at least a couple
of sentences. Fina lly, you include the support. That can take one or more sentences. This means that no
paragraph can have only a single sentence because it will not have enough information in it to be a
complete statement. It also means that if you have sentences that do not either state the main idea,
explain it or support it, and, instead, talk about something else, then you will know that these sentences

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

211

6 - 15

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

are not in the right place. You will have an intelligible pattern for all paragraphs and this wi ll be easy to
follow.

6.6.3.

Using Lists

Some people may consider paragraphs to be better "writing" than lists, but in engineering writing, the
goal is to provide information as quickly and clearly as possible. Much of the time, lists are the best way
to do this. The choice of whether to use paragraphs or lists will depend on the kind of information being
given. If you are expressing an idea that requires explanation and support, then generally speaking a
paragraph is the best choice. The sentences, in that case, will build on one another to develop the
particu lar topic identified in the f irst line of the paragraph.
But if you are giving a number of different, individual facts - functions, objectives or constraints, for
example - then a list is best. Again, always keep in mind the reader looking for particular information
and introduce your list with a clear sentence identifying what the list is about. Make the sentence as
specific to the document as possible. "The design has the following functions" is only minimally
informative and not at all unique, whereas "To enable users to drink or f ill water bottles at the same
fountains, the design must have the following three primary functions."
Lists should be revised. You may draft a list as items come to mind, but you should go back to it and give
some thought to the best order for those items before you submit the document. Should they go from
least to most important, or the reverse? Should they go from most to least expensive? It does not
actually matter what kind of organizational idea you use; there is not one that is better than another,
but making a decision creates better writing t han not making a decision. You should try to determine
what would be best for the situation; often the information most supporting your idea should come
first.
You might find that there is a sequence implied in the list, in which case you might use a numbered list.
Numbered lists are familiar f rom instructions o r lab reports. They are an efficient mode of organization.
Even if the list is not numbered, however, you can indicate the number of items in it, as in the example
given above, for the water fountain: "To enable users to drink or fill water bottles at the same fountains,
the design must have the following three primary functions." Alerting your readers to what is coming up
is a way of helping them to process infor mation sooner, and to read faster.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

212

6-16

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

6.7.

Basics of effective sentences

An effective sentence has its own kind of logic and you must master that logic so that when you are
expressing difficult concepts, your sentence structure helps, rather than hinders, the reader's
understanding. In addition, your sentences should be quick to read and unambiguous. So, beyond using
plain language, as discussed above, your sentences have to follow expected patterns of development so
that your meaning is delivered to the reader in a way that the reader is comfortable with, due to the
reader's experience. Fortunately, it is easy to define the two key pieces of information the reader needs
to have in order to understand a sentence: 1) who or what is doing something and 2} the action that the
person or system or entity is performing. The first is often called the "subject" and can be represented
as a name, a noun or a pronoun. The second is often ca lled the "action" and is represented by a verb.
Many sentences have a third component, an object or complement. This the part of the sentence that
receives o r finishes the action.
In the English language, there are two basic sentence patterns: active and passive. The active is the
more logical and easy to follow - it puts the subject first and the action second. That is, it identifies who
is doing the action and what the action is: this is the easiest order possible for a reader to take in
meaning in the English language. A simple sentence is one that has only a single action or idea. The
following sentence is a simple, active sentence:" A design project often starts with a statement from a
client."
But not all sentences can be active. In scientific writing, in order to maintain the idea of objectivity, the
subject of the action cannot be so easily identified. Consider the case of a lab report. In an experiment, it
is the experimenter who is doing the action, but if you are the experimenter, you wil l almost certainly

agree that you could not write up your experiment with a bunch of sentences starting with the word "I"
- "I put the liquid in the beaker," or " I mixed i n some sodium chloride". So, you often end up using the
passive voice: "The liquid was placed in t he beaker," or "Sodium chloride was added to the beaker."
The passive voice creates writing challenges, especially when you are writing compound sentences or

complex sentences. Often the subject is hidden. In the sentence "The hypothesis was not verified by the
results", the action is being performed by the researcher, but the researcher has no place in the idea.
The idea should exist, according to scientific practice, separately from any individual involved. You can
make objective active sentences if you really work at it. For example, the sentence "The hypothesis was

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

213

6 17

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

not verified by the results" can be rewritten as "The results did not verify the hypothesis" without losing
any obj ectivity but gaining the value of an active sentence. That value becomes important when
combining simple sentences to create compound or complex sentences.
So, the sentence "The results did not verify the hypothesis" is a simple, active sentence. It has one idea
and has a subject, action and object in a conventional, easy to understand order. If you add another
sentence to it - say the sentence - "There was a high degree of error'' then you can have a compound

senten.ce: "There was a high degree of error and the results did not verify the hypothesis." A compound
sentence is made up of two simple sentences joined with the word "and." It is perhaps the easiest long
sentence form to use, but it has two conditions. The units joined with the "and" have to be of fairly
equal importance and they have to no special relation to one another.
A special relationship between ideas creates "dependencies" in sentences. This kind of sentence is called
a "complex sentence." One group of words, or clause, is "dependent" on another in order to be
understood fully. You can turn the compound sentence above into a complex sentence by turning it
around: "The results did not verify the hypothesis but there was a high degree of error." Now, the word
that is combining the two ideas is "but", which indicates a contradiction or change in direction. The
second way of writing the sentence brings out the idea that the error might have been the reason the
results did not verify the hypothesis. This idea is implied in the compound sentence, but made more
explicit in a complex sentence.
Because you can have compound, complex an d even compound/complex sentences, which combine the
two forms, and these sentences can go on for quite a while, you have to have ways of ensuring that the
reader does not get lost. The best way to ensure this is to consider the sentence like a road and ask
yourself where the road markers are. Remember, the reader is looking for the subject and the action. So
track those first. Let's take the compound/complex sentence that begins this paragraph. First we'll t rack
it for the subject and mark it in red.
Because you can have compound, complex an d even compound/complex sentences, which combine the
two forms, and t hese sentences can go on for quite a whi le, you have to have ways of ensuring that the
reader does not get lost.
Now, we'll add the actions in green.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

214

6-18

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Because you can have compound, complex and even compound/complex sentences, which combine the
two forms, and these sentences can go on for quite a while, you have to have ways of ensuring that the
reader does not get lost.
Notice you can break this long sentence into four short sentences:
You can have compound, complex and even compound/complex sentences.
Compound/complex sentences combine the two forms.
These sentences can go on for quite a while.
You have to have ways of ensuring that the reader does not get lost.
These are simple sentences on their own and, if we have to, we can locate their subjects and actions.
The phrase "compound, complex and even compound/complex sentences" is the object of the first
clause and "compound/complex sentences" the subject of the second, but the word "which" allows the
writer to combine these two ideas and eliminate the repetition of the words "compound/complex
sentences". After the words "two forms," the word "and" allows the writer to include another simple
sentence "These sentences can go on for a while."
However, the word "because" begins the long sentence. "Because" turns any clause that follows it into
what is known as a dependent clause. That is a clause that cannot stand on its own, but requires
another clause to complete it. The reason for this is that "because" means that there is a cause and
effect. Strangely, we are used to putting the effect first and the cause second, but in this case, the writer
didn't. She or he put the effect clause at the end of the sentence: " you have to have ways of ensuring
that the reader does not get lost." Once again, this is basically a simple sentence and it could stand on
its own. Moreover, we are used to seeing the clause beginning with "because" after the one on which it
depends - mostly because we are told in grade school "never begin a sentence with 'because'!" This is
not a grammatical rule, but it is easier than trying to teach children the difference between a dependent
and an independent clause. The real rule is "Any sentence with 'because' in it must have two clauses,
one which sets up the effect and the other which sets up the cause."
The central complex sentence here is: "Because you can have compound, complex and even
compound/complex sentences, you have to have ways of ensuring that the reader does not get lost."
The matter in the middle is all just further explanation. But the writer ensures that the reader does not
get lost by making the road signs of the sentence, the subject and action, clear and easy to find. Also,

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

215

6-19

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

the action is right next to the subject, making it easier for the reader to connect them. When you are
writing long, complex sentences, the way to ensure that they are clear, is to locate their subjects and
actions. See if you can get the actions as close to the subjects as possible. This will help ensure the logic
of your sentences and really help your reader.

6.8.

Person-to-oerson Interactions and Oral Presentations

Person to person interactions are key to developing trust. Whi le the written word, especially when
carefully done, can provide extensive detail and explanation, in person communication is flexible,
allowing you to focus on particular areas where understanding is difficult to achieve. The key to success
in person-to-person interactions is in developing professionalism.

6.8.1.

Professional demeanor

You can still be yourself and develop professionalism. You are not taking on a "fake" role or pretending
to be more expert than you are. The best way to understand professiona lism is to compare it to
formality. It is like putting a business suit on your behavior - you are still doing things as yourself, but
with a slightly different tone. In fact, one of the best ways to practice professionalism when rehearsing a
presentation is to put on your best business clothes - a shirt, tie and jacket or suit, or a skirt and jacket
with a good blouse. You will find yourself standing or sitting a little straighter, taking a little more care
than when you are just in jeans and a sweatshirt.
The characteristics of professional demeanor change from culture to culture and you have to be aware
of the particular codes of conduct where you are having your meeting. Part of global business today
requires that you understand this concept and behave appropriately for the situation in which you find
yoursel f. For example, in North America looking directly at the person or people you talking to and
shaking hands are considered primary ways of establishing trust. However, in other places in the world,
looking directly at someone may be considered disrespectful and shaking hands may actually violate a
religious or cultural practice! Things can be even more complicated if you come from one culture and
must do business in a place where the practices contravene yours.
Therefore, f irst of all, you must apply some cr itical thinking to the question of how to present yourself.
Ask:

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

216

6-20

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

What is the cultural practice where I will be having my meeting?


Is the cultural practice different than behaviour that I am used to? If so, can I practice
behaving in a way that is more appropriate so that I can feel more natural in my meeting?
Does this practice violate a religious restriction? If so, can I figure out a way of explaining my
restriction politely so that the other person understands?
You may have to do some research in order to create a list of behaviors that are appropriate to the
business culture in which you are engaging. Once you have created that list, you can ask yourself some
more personal questions about which of the expected behaviors will pose challenges to you. For
example, eye contact may be difficult if you are shy. If so, try to figure out a strategy to deal with your
shyness but still make enough contact to create trust. For example, you can change the focus of your
anxiety. Rather than worry about eye contact, you can ensure that you are listening carefully and taking
notes at meetings. That might give a good impression. Certainly, in a North American context, not
making eye contact and not taking notes gives the impression of lack of engagement. Create a list of
strategies you think would work best for you i n the particular context. Practice techniques in less
stressful situations, when buying groceries or when getting onto a bus.

6.8.2.

How to organize presentation as a whole

Presentations are a bout taking person-to-person interactions, the development of trust between two
parties, to a second level, in which the interaction is one-to-many and the development of trust is
genera l. The group of listeners must develop trust in the speaker or team of speakers. A successful
presentation is one which ends with listeners feeling more confident that the speakers have been
successful in achieving what they said they achieved or are going to be successful in what they set out to
achieve. Good questions to ask at the end of any presentation, therefore, are:
Did we clearly identify ourselves and what we intend (or intended) to achieve?
Did we adequately prove that we achieved it or will achieve it?
The two primary steps in effective presentations are:

1.

Introduce yourself

2.

Introduce your presentation

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

217

6-21

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

So, first of all, identify yourself and your project completely in two ways: give the t itle of the project and
list all participant names, both first and last, on the title slide. Then, clearly and carefully, announce the
name of your project and introduce yourselves at the beginning of the presentation. Give your names
slowly and clearly- since engineering teams and audiences may come from all over the world, names
can be unfamiliar. Hearing them and seeing them in writing at the same time is a great way for the
audience to get comfortable with them.
Next show a slide that gives the main message of the presentation and an outline of its parts. The main
message is a full sentence that goes at the top of what is often known as the "outline" slide. It predicts
what you are going to prove, pulls the presentation together at the start, and makes each of the points
in the presentation mean something unique. While certainly it is not "wrong" to create a slide that slide
that says "Outline" or "Agenda" and then gives a list like " Introduction; Design; Conclusion," it also does
not take much thought to create such a slide and it most certainly does not give a unique or lasting
impression.
On the contrary, a slide that has a t itle such as "Improving Flow of Movement in Occupational Therapy
clinic" is going to catch the audience's attention and get them to start thinking of questions - how are
they doing that? How is it possible? What is the cost? How complicated is the refit? Then, such
conventional sections as " Introduction, Design, Conclusion" can become
Current situation - room dimensions, required equipment per bed, number of beds
Desired increase in numbers of beds - space challenges associated with goal
Models of layout and workflow
Optimal balance of space and workflow
Making your points specific and unique to your project make your presentation far more interesting.
There i s a hidden challenge to this, however. Choosing conventional headings and an old "tried and
true" recipe for a presentation might feel more comfortable because you or your team members will
feel that you are not making an mistakes, that such an approach is not "wrong." However, just because
it is not wrong, does not mean it is right. It certainly does not guarantee it is either good, effective or
memorable.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

218

6-22

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

6.8.3.

Audience and purpose in presentations

Because a presentation cannot have as much detail as a written document, you must select particular
details and the credibility of your presentation will be determined by the logic of your selection. Your
audience has to understand why you are telling them what you are telling them (and therefore why you
are leaving out what you are leaving out).
A main message is related to the purpose of your presentation. The purpose of your presentation, in

turn, is related to an understanding of the needs of your audience in this particular situation.
Remember! Audience needs are both individual and situationa l! The same audience -your supervisor,
for example - wi ll have very different needs at different stages of the design process. Early on, she or he
might be most concerned with your preparati on, vision and planning. When hearing a progress report,
she or he might be worried about how you have resolved a problem - or plan to resolve it. At the end of
a project, your supervisor will want to know how feasible the next steps are going to be, how well you
have tested and proven your design.

So, a first step in planning is to ask these questions:

1.

Who is my audience?

2.

What is their level of involvement with the project? How much do they know at a high level?
How much do they know about current details?

3.

What does my audience need to know NOW?

4.

What is the level or range of technical knowledge in my audience? What is their technica l
interest or enthusiasm? How much time do I need to set aside for particular, technical
explanations?

Technical explanations are valuable both for audience members who do not have a high technical
knowledge and for those that do. The first, less technical group, will be eager to understand what
they do not already understand; the second, highly technical group, are enthusiasts. They w ill want
a lot of details because they enjoy the subject area. The nature of the details may be different for
each group - or you may have an audience comprising both groups and have to carefully determine
the best selection of details to satisfy all.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

219

6-23

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Once you have determined audience, a second step is to determine purpose and main message. Input
the main message at the top of the outline slide and then add in the points you feel best explain and
support the message. Once you have completed this step, you have done the overview of the
presentation and can work on each of its parts.
The final part of the presentation is often called the " Take-Away." This is the "last impression" or what
people will remember. Whether you say something memorable or not, this is what people carry away.
Reiterating your main message is a good way to consolidate the presentation. Not having a main
message and just presenting details from your report will have the opposite effect. What people will
remember is that they had nothing to remember, that the presentation was dull and not informative,
lots of details but nothing to grasp. So, simple keys in creating an effective presentation;
Determine a main idea that takes into account the situation of the project and the needs of
the audience
Figure out the points that best explain and support the idea
Develop each point
Reiterate the main point to sum up

6.8.4.

Effective slides

As presentation slide programs have evolved, over the last twenty years or so, there has been a great
deal of controversy over their use, best slide design and even whether or not the use of these kinds of
slides reduced the intellectual value of the information being presented. While the slide design
programs have generally adhered to best practices in overhead projections, the availability of
animations, videos and other visual elements sometimes created distractions. Further, and more
problematic, distributing slide-handouts rather than reports can reduce the complexity of information
and that can cause problems. Slides cannot substitute for a detailed, well-written report.
Michael Alley, a leader in slide design thinking, has proposed a way of creating slides that overcome
some o f the weaknesses of previous designs [1]. The slide has basically three elements:

1. A clear title in the form of a brief sentence giving a complete idea


2.

A set of bullet points that use enough words to give the idea in some depth

3.

A visual element that helps to exemplify the idea.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

220

6-24

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

A title that is in the form of a sentence, at the top of the slide


A list of bullet points that are f ully developed ideas
These are below the title and to the left
The bullet points still adhere to familiar principles
such as
o

Clear, readable and good size font

Avoidance of overly dense, or text heavy slides

_..

.,..,.,_,...

A graphic element in the lower right

Figure 1. Example of the slide design described by Michael Alley (1].


This slide design maintains simplicity, but gives enough detail so that the ideas of the presentation do
not become trivial. The main point here, though, is that the slides contain whole, unique ideas as
opposed to topics or general titles, such as "Introduction." Also, the visual element is used to support
and build understanding. It is not j ust decorative. In fact, you should avoid decorative images, clip-art,
photographs that are not making a direct point related to the presentation.
So, good slides, very briefly, should be clean, uncluttered. They may use whole sentences and full ideas,
but are still only a selection of the details given in the full report. The selection should be made carefully,
according to the main message you and your team want to present - the message that will express the
best of what you can do. If this is supported by objective, tangible evidence (tests, measures, principles)
then you will have achieved important goals of effective, engineering communication.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

221

6 - 25

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

6.9.

Reflecting on this chapter

This chapter is only going to start you on the way to becoming a good report writer or speaker. Many
texts exist for helping you with these skills. Organizations such as Toastmasters can give you
opportunities to practice your speaking and provide good advice in a comfortable atmosphere. Having
your work examined by others is another good way to improve. Many universities have writing centers
with tutors available to advise you on documents and presentations. An engineer will recognize the
importance of writing and speaking well, and will seek means to improve those skills.
Key terms:
Action
Active sentence
Bullet list
Claim
Clause
Complement
Complete statement
Complex sentence
Compound sentence
Compound/complex
sentence

Dependencies in sentences
Dependent clause
Fact
Figurative language
Metaphor
Noun
Numbered list
Numbered sections
Object
Opinion
Paragraph

Passive sentence
Plagiarism
Plain language
Professional voice
Professionalism
Pronoun
Simile
Simple sentence
Subject
Topic sentences
Verb

References:
[1] M. A lley, The Craft of Scientific Presentations. NY: Springer-Verlag, 2003.

A primary source for the information in this chapter is:


Rob Irish and Peter Eliot Weiss, Engineering Communication: From Principles to Practice. Toronto:
Oxford University Press, 2008.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

222

6 - 26

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Chapter 7: Working in a Team


Table of Contents for this chapter

7.1.
7.2.

7.3.
7.4.
7.5.
7.6.
7.7.
7.8.

7.1.

Introduction
Teams
7 ..2.1.
Forming
7 ..2.2.
Storming
7 ..2.3.
Norming
Performing
7 ..2.4.
7 ..2.5.
Adjourning
Team leadership
Managing Tasks
Managing People
Strategies for dealing with task and people problems
Conclusion
Team Strategies
7.8.1.
Negotiating conflict
7.8.2.
Deciding how to decide
7.8.3.
Using an Attribution Table or St atement
7.8.4.
Sharing your work
7.8.5.
Warning and/or f iring a team member
7.8.6.
Quitting a team

Introduction

Today it is very rare for design to occur through only one person and as an engineer you will f ind that
you work extensively in teams. Effective teams bring diverse perspectives to design and generally
provide better solutions than individuals working alone. This is often because problems are solved more
quickly, more and better new ideas can be generated, and ideas are implemented more efficiently by
teams than by individuals. However, as powerful as teams are in the design process, they are not
without difficulties. Understanding how teams work, how to be part of and lead effective teams and
how to dea l with the issues encountered is an important pa rt of what you need to learn when working
as an engineer or indeed in any work environment. Team centered organizations are becoming more
and more common as the value of teams to solve complex problems, enhance competit iveness and
improve business systems continues to be recognized. This means that no matter what career path you
chose, whether it is in engineering, another profession, understanding teams will help you be successful.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

223

7-1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

A team is a group of people who come together to work in an interrelated manner towards a common
goal. There are cross functional teams, across disciplines and skills, and within function teams (Picture
1}. For example a design team may have members from civil, mechanical, electrical and other
engineering disciplines, financial personnel and architects working together to design a large facility.
This would be a cross functional team. Parts of this same project, for example the structure of the
building, may be designed by a team of specialized civil engineers. This would be a within function
team.

Picturel. Cartoon illustrating cross functional and within function teams


The key difference between a group of people and a team is the common purpose an d the reliance on
the skills of all the members to complete the task [1]. A group of people who come together to make
independent decisions to reach a goal do not form a team. Put another way, team decisions are not
simply a sum of independent decisions made by individual people. And the work that a team
accomplishes is not a set of individual isolated pieces that are tacked together. Teams operate as an
entity and often develop characteristics (almost personalities) apart from their members.
The definition of team can be taken one step further. Teams can be considered in terms of their
performance rather than the function of the individual members [2,3).

Pseudo teams-- perform below the level of the average member. Pseudo teams work as a set of
isolated individuals. This type of "team" is characterized by poor communication, and a lack of
commitment to a team purpose.

Potential teams - perform at or slightly above the average team member. Potential teams
communicate better than pseudo teams. There are some synergistic work habits in this type of team.

Real teams-- perform well. Real teams communicate actively and have developed cooperative,
synergistic work habits.

High performance teams-- go well beyond the capability of the individual members. High
performance teams are highly communicating, cooperative, and synergistic. They fully actualize the
potential of every team member.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

224

7-2

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Unfortunately, you may not know which of these types of teams you are working w ith until the project
is already in progress. But you can take steps at the beginning of a project to try to ensure a better
result, and use effective team practices during the project to keep your team moving toward a high
performance outcome. Research on highly effective teams has shown that there are 5 underlying
common themes that make these teams highly successful [1-5):

1. A common goal or purpose


2.

Both individual and group accountability

3.

Real work is undertaken

4.

Processes, skills and mechanisms are in place to deal with both task and people issues

5.

Group processing i.e the group reflects on their work, celebrates together and resolves issues
together.

Simply stated, a team needs to have a clear pu rpose that is understood by everyone and the team itself
must have methods it will use to keep itself on track, resolve issues between people and to resolve
problems associated with getting the work done. People are seen as equally important as the tasks.
These concepts are illustrated in the figure below (picture 2). As your team develops, it w ill need to
have process skills such as decision making tools and agendas, and people skills and strategies such as
what the team will do in situations of conflict to become a successfully producing team. This is
challenging.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

225

7-3

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

The High ly Perfo rming Team

People

Tasks

toolsandJ
strategies
\

Results:

Purpose

Return w ith a better


understanding of the problem

No
Done?
Yes

Review
Check
Critique

Adjourning
-Documentation

Tools and strat egies can put the process into overdrive:
Increase speed, creativity,
improve out puts. Tools and strat egies are
needed for bot h people and tasks.

Picture 2. The high performing team process

Working effectively in a team or as a leader, perhaps more than any other activity in the design process,
has to be practiced. Understanding the theories and models of team work is helpful, but no substitute
for actual experience. You need to actually engage repeatedly in different teams, and learn from each
of these experiences to get better at teamwork and leadership.
Part of this learning process is reflection. This means reflecting on an experience and intentionally
thinking through what you learned from it. In business there are formal methods for reflection of this
type, they are called lessons learned activities. At the end of a project the team spends some t ime
discussing and documenting the lessons learned during the project.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

226

7-4

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Reflection (lessons learned):


Think about the best team you have ever been on. It could be a sports team, a band, your theatre group
or a club. What were its characteristics? How did it contrast to the worst team you have ever been on.
If you haven't yet been involved with a club or team, now is the t ime to start! Get involved. This is an
important part of your learning process in engineering school.

7.2.

Teams

There are many different models of how teams form and ultimately work effectively together. Many are
based on a set of linear stages while others model team development on systems theory [6]. The models
all have stages, some more, some fewer. One of the most commonly used is the model developed by
Bruce Tuckman in 1965 as a four stage model and later expanded to five stages [4,5]: Forming,

Storming, Norming, Performing and Adjourning. While we will focus on this simple linear model it is
important to emphasize that the focus of the team on tasks must be in balance with its focus on people
as it moves through the stages. In addition, whi le the model below appears linear, it is really iterative.
The addition of a new team member, a major change in the project, or other disruptions will cause the
team to go back to forming or some other stage, such as storming. Some key features of this model are
illustrated in figure 3.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

227

7-5

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Typical Team Development Model


:tviE

WE

f?[f[o)[[uuuo ITU@

or

..

al11

prod

@[?lli/ilD

Figure 3. Modified version ofTuckman's team development model, (adapted from [4] and [5])
The first three phases of team development, forming, storming, and norming, can by categorized as
"organizing". During these phases it is particularly important that your team define the roles and

responsibilities of its members; chooses a team leader; sets team rules; and gains a clear understanding
of its purpose. If these things do not happen, then the team will stall and will not move into phases four
and five which can be categorized as producing.

7.2.1.

Forming

In the forming stage, the team is coming together but still operating as a set of individuals. This stage is
dominated by indivi dual team members thinking more about themselves than about the team. Think of
how you feel each time you start in a new team. Do you ask: What is my role? Why did I end up in a
team with that person? How will I f it in to this group? Will i still be able to get the grade I want? Who
will be team leader? We have illustrated this with the ME written above the forming stage. All these
feelings are natural in the forming stage which is dominated by the team getting to know and trust each

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

228

7-6

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

other. In this stage, if you are the team leader you may find that you will need to be directive and focus
the team on the tasks that need to be accomplished. The team must start to define the project they are
working on.
Forming is often a comfortable stage because team members are being careful with each other as they
get to know one another. You will also be focused on yourself. How you fit into the team will be more
important to you than the team itself.
If you are observing a team in this stage you m ight see:
Polite conversation
People being quiet or tentative
Focus on task definition
Exchange of limited personal information
Use of the word "me" and " I"
Very little expression of strong opinions
These behaviors are a natural part of team formation. It is important to let people get used to each
other, .and gain trust in each other. During this phase you should exchange contact information and
define the purpose for your team, i.e. the design project.
Tools and strategies for forming
It is helpful to put in place team rules, sometimes called team beliefs or a team charter. This is a set of
behaviors that the team members agree will govern their interactions with each other. This may seem
silly, but these "rules of the road" will help the team members and team leader define how they w ill
behave. Such rules often include items like; come prepared to meetings, don't be late, no cell phones
on during team meetings. The rules can be used to deal with behavior that is getting in the way of
achieving the task.
You should start to use agendas for team meetings and keep minutes. [Link here to documentation and

templates back page sections on agendas and minutes.] Using agendas and minutes is not for the
purpose of being more bureaucratic or pretending to be more professional. They are used routinely in
business for a reason. These documents are going to help keep your team on track and moving forward.
It is easy to forget who told what to who, who is doing which part when, and what your team did just a

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

229

7-7

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

few weeks ago. Agendas and minutes are part of documenting the process and will be invaluable once
the project starts accelerating.
Examples of constructive team rules
Do not answer cell phones, play games, or work off topic (e.g. facebook) during team meetings
Treat teammates with respect
Show up on time {the team should decide what "on time" means)
Give each other the benefit of the doubt, unless proven otherwise (especially in email and other
written communication)
If a member breaks the rules, call them on it . This means immediately bringing it to their
attention respectf ully and directly.
Let people know if you are in trouble, e.g. getting overwhelmed, unable to deliver work on time.
Decide how the team will communicate and how the members will collaborate on documents.
(examples: Google docs, Dropbox, Sharepoint)
Answer em ails, texts, and phone calls from teammates - decide what is a reasonable response
t ime
A problem with a member is a team problem. Everyone needs to take responsibility for doing
things differently to make the team work. Don't play the blame game: i.e. it is their problem
they need to fix it. Instead say "it is our problem we need to fix it".
Team should discuss expectations for work as deadlines approach. This rule w ill ensure that
people are clear on what they are being asked to deliver and when. If a team member is
responsible for section D of the report and they think this means two paragraphs, but everyone
else t hinks it means two pages, t here is going to be conflict.
If work isn't delivered on time, at what point does the rest of the team take on the job of doing
the person's work for them (and removing their name from the author list)?
How much warning needs to be given before a team member who is not responding is cut out of
the process?
What are the team's expectations for quality of work? Is everyone striving fo r the highest grade
possible, or would people be happy j ust to pass?

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

230

7-8

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Examples of destructive team rules*


If you are late for a team meeting you have to buy everyone a treat
You can play on your laptop during team meetings if you agree to do more of the work
People who don't get their work done have to wear a hat that says " I'm a loser who let my team
down"
If you are 5 minutes late even once for a meeting you have to leave, you are not allowed to
attend the meeting.
Team members should tell each other exactly what they think of them at the end of each
meeting, (or on their facebook page).
If a team member delivers inadequate work for one report, they have to do more of the work on
the next report.
The team leader is responsible for cleaning up any team messes and rewrit ing anything that is
poorly written.
If a member doesn't deliver their work at least two hours before a deadline, then the rest of the
team is responsible for writing the missing sections. (This is a bad rule because 2 hours is not
nearly enough time for the team to remediate the situation. It isn't fair to the team)
Team meetings are optional for people who finish their part of the work early.
*adapted from actual team rules that we have seen undergraduate design teams try to use.

7.2.2. Storming
In the storming phase the team is in conflict. This is the least comfortable stage of team development
but is a very important one. Teams can get stuck here all the way through the proj ect if they are not
careful. In this phase different ideas come out as team members get more comfortable with each other.
Opinions are expressed, work habits are revealed, and expectations come to the surface. One of the
most common points of conflict in storming is related to assumptions. You assume that your teammates
will behave the way you want them to, and they don't. (If you have ever had a roommate then you are
probably familiar with storming.) Resolving these issues requires discussion, agreement, disagreement

and compromise. Roles and responsibilities should be made clear and assigned to people. The

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

231

7-9

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

leadership pattern for the team will emerge. Resistance to the leader may start to occur and
resentment towards the project itself. Conflict can occur as the design problem is elucidated and the
direction of the team made clearer. If you are the team leader, you will again need to be directive to
keep the team on track and to avoid getting st uck in this stage. Be prepared for team members to
resent any exercise of authority in this phase.
If you were observing a team in this stage you might see:
Conflict
Resistance to decisions
Intolerance
Focus on little details
Frustration with the behavior of teammates
Teams can get stuck in this stage and may revert to individual decision making and the project work
returns to a strategy of tacking together individual pieces. If this happens your team members will do
what they individually think needs to get done, rather than what the team has decided needs doing.
The team reverts to a pseudo team. The work quality wi ll suffer. To get through this stage it is helpful
to have picked an assertive team leader (not aggressive, and not timid) and to stay focused on the task
rather than personalities. Team leaders that are too aggressive or t imid during this phase of team
develop ment will lose the support and trust of their team (see sections on hijackers and enablers
below). It will be difficult for them to effectively manage the team moving forward.
Tools and strategies for storming
Storming is where your team rules become really important. During this phase review your rules
frequently, and address issues as soon as they arise. Don't wait until things get terrible. If the rules
aren't working for the team, then revise them to be more effective. The sections on managing tasks and
managing people later in this chapter explain more strategies that will help you get through this difficult
period. A few brief tips:
During the storming phase a lot of time will need to be spent on resolving people issues, leaving
less time for tasks. Make sure you account for this in your project planning.
Recognize that you have f laws too

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

232

7 - 10

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Remind yourself of what you value about each team member. There has to be something.
Discuss the issues with a positive sense of humor and working toward positive goals
Do not wait until people are really angry to resolve a conflict
If your team has to resolve a major conflict close to a deadline, be especially calm, responsive,
and professional (pick your words and actions carefully) to combat the tension.
Reaffirm your commitment to making this team work
Recognize that even the most wonderful teams will go through storming periods
Keep communicating
See Team Strategies (section 21.8) for more strategies to deal with storming

7.2.3.

Norming

In the norming stage of team development, the team has essentially "got its act together". It has
determined its common goal, in your case the design project has been defined and p lanned out. While
team members will still have their own ideas, they will be willing to compromise in order to make the
team work effectively. Team members are taking responsibility for team decisions. The team has
agreed on how to work together, what the standards for the team are, and roles have been defined.
This phase of team is characterized by:
Agreement on how the team will behave
Agreement on deciding how to decide
A leadership style that is less directive and more supportive
General consensus on the team goals and activities
Processes and procedures are agreed on
Members begin to trust each other and appreciate every member's contribut ions more fully
Greater focus on tasks rather than resolving people issues
It is important to note in the model that there is a thick line between the first three phases, forming,
storming and norming and the second two, performing and adjourning. Key to moving to a high
performance team is deciding how to decide. It is critica l that you have a decision making process in

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

233

7-11

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

place by the norming stage or your team will not move forward into the performing stage. Productivity
will be difficult. Tasks will not get completed because decisions will not be made in a t imely manner.
Tools and strategies for norming

Deciding how to decide- the team must decide how to make decisions. Two of the more
common methods are consensus and voting. A list of typical decision methods used by
undergraduate design teams are given below in Team Strategies (section 21.8). You can also
find decision making tools for specific situations in the Decision Making Tools section. link to
Decision Making Tools

Developing performance measures - In the norming phase your team should develop effective
process strategies, such as the effective use of agendas, minutes and status reports. These,
used in conjunction with your project plan will help you formulate performance measures,
indicators of how well your team is performing. To effectively norm, make use of these
performance measures to monitor the team activities, and use this information to continue to
improve team performance. See the Team Strategies (section 21.8) below for more information
on this.

7.2.4.

Performing

When a team enters this stage it is strategic and clearly understands what it is doing. The team
members will have a shared understanding of the problem, project or design and their focus is generally
on the goals. The members also look out for each other. The team has achieved the balance between
focus on tasks and focus on people.
This phase of team development is characterized by:
Clear roles
The team organizes itself, every member takes responsibi lity for involvement
An understanding of each team members strength and weaknesses
Strengths are celebrated
Weaknesses are supported

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

234

7-12

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

The members are interdependent and individually accountable and responsible


The team leader is required to provide limited direction
Tools and strategies for performing
To perf orm well and continue performing well throughout the remainder of the project the team needs
to:
Continue monitoring performance and feed this information back to the team members
Continue using this information to f ind new ways of improving performance
Not become complacent; continue communicating actively
Recognize that the team may occasionally re-storm andre-norm
Regularly reassert expectations, and discuss process
Make sure everyone is listened to and everyone is engaged
Enjoy the project; not every team you work on will get to the performing stage, so enjoy
working on a well performing team, and reflect on how you got here.

7.2.5. Adjourning
This is often when the team breaks up but may also occur with a permanent team if a member leaves or
there is significant change in the team structure or purpose. In the case of an engineering design project
it is usually marked by the submission of the finished design project. The team will feel good about
what it has accomplished but team members, who will have become closely bonded, may also feel some
sense of loss.
This phase of team development is characterized by:
Sometimes a lack of energy as members resist the change
Evaluation of the team efforts
Tools and strategies for Adjourning
Celebrate you achievements
Thank your teammates

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

235

7-13

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Reflect on what you have learned from working with this team

Not every group will become a high performing team. Understanding this team model, and the tools
and strategies for the different phases, can help you achieve a better level of performance. However,
much of what differentiates a poor team from an excellent team is attitude. We will discuss people
issues later in this chapter, but you can do your part by bringing a good attitude and level of
commitment to the projects you work on. There is a saying in industry "companies hire for attitude, and
train for skills". This may not be 100% true (your grades do matter), but it makes a point. Your attitude
matters and it will affect what you get out of this experience. You may not be fully satisfied with the
results when the team adjourns. However, this experience will be an important part of your engineering
education.
Reflection
Take a moment to think about what you want a team leader to do. You should discuss what you want
your leader to do as a group before the selection of that leader. Then take some time to think about the
characteristics that would make a good leader based on what your group has decided the team leader is
to do. Do you want the person who is the most technically able; the person with the best marks; the
person with the best organizational skills; or the relaxed person on the team7

7.3.

Team Leadership

One of the most important decisions that you will make as a team will be the selection of the team
leader. In undergraduate engineering design teams, your leader should have several duties. He or she
will be the member of the team whose role is the closest to that of a project manager found in
engineering companies. They will often assign tasks to team members, keep track of where your team is
in the project, deal with issues that arise relating to people and wi ll likely bear the responsibility of
communicating with the instructor if issues become critical and cannot be resolved by the team without
help. Team leaders certain ly can and should do some of the technical work and writing but will be
overloaded iftheytryto too much and also lead the team.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

236

7-14

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

There is generally one key difference between the teams that you are part of when you are in school
and those when you are working in either an engineering firm or in business. The team leader in the
work environment is often, but not always, someone who has the responsibility and the authority to
assign tasks and to discipline team members. They are frequently at least one level higher in
responsibility than the other team members. It is somewhat unusual to be in a team of only peers
however this is a growing trend. In university or college design teams, you are all peers. This means
that it w ill be important to involve the instructor if team conflict becomes too difficult for the team or
team leader to solve.
Being on a team of peers adds complexity to the role of team leader. The leader must provide the
direction and guidance to the team when all the members are equal. They must be highly persuasive
and respected by the team. That being said, high functioning teams ultimately become self managing
with little guidance from the leader regardless of whether or not the team leader is a person in authority
or a peer. It is not unusual for student project teams to reach this level of sophistication very quickly if
the members are committed to making it work.

7.4.

Managing Tasks

Things can go wrong with tasks within a team. We will emphasize the ones that we have found occur
most commonly in student design teams and suggest ways to avoid or resolve these issues in your team.
One of the most common challenges that teams face in engineering design courses is having difficulty
conducting focused meetings. Too often meetings are used j ust to exchange information, not to get
work done. YOU DON'T HAVE TIME FOR THIS! The solution is to set an agenda and keep minutes so
you do not repeat tasks and get work done in your team meetings. There is a simple technique for
saving time by linking your agenda with your minutes. The minutes should simply be a list of tasks
assigned including deadlines and a review of those tasks, including progress against deadlines. The
minutes from the last meeting becomes the agenda for the next meeting. Information that needs to be
recorded in the minutes can be put in a separate area of the agenda document and should be kept to a
minimum. When done this way, your agenda and minutes become very closely linked to your project
plan. Your minutes document progress and become your next agenda. Using agendas and minutes in
this way can also help you manage the problem of a hijacker (see below).

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

237

7-15

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Add meeting agenda and minutes example here. Link to templates for these (back pages)

Another common issue that teams face is underestimating how long it takes to do things which results
in an inability to complete tasks on t ime. This is basically a lack of effective planning. In order to prevent
this, engineering design teams use project planning tools. Two of the simplest and most frequently used
are a PERT charts or Gantt charts. [link to project management chapter] A Gantt chart is a list of tasks
illustrated as a bar graph on a calendar. (At some point in time all your tasks should show up
somewhere on an agenda). If you are using a project planning program try not to get bogged down in
trying to use all the complex features it has for tracking your project. A simple Gantt chart is really
enough for an undergraduate design project and indeed for many projects.

The secret to using a

scheduling tool is to be sure that you have listed all the tasks that are needed to complete the project
and then start from the project completion date and work backwards. This tool will not only help you
keep on schedule but will provide you with the agendas for your meetings and will show when certain
tasks have to be completed before others can be started.
Design teams frequently find that they do not have enough time in team meetings to get everything
done. Regular team meetings should be no more than an hour or two. This is assuming that these
meetings are primarily for work sessions with decisions being made and work being completed. To keep
meetings on track make sure they do not become information sessions unless the transfer of the
information requires a meeting and it cannot be provided through email or other methods outside the
regular meeting t imes. In addition, make sure the agenda is not too long. Assign a person to chair the
meeting and keep it on track. The chairperson does not have to be the team leader and the position
should rotate so that all team members have an opportunity to manage a meeting, and provide the
agenda. Someone other than the chairperson should keep the minutes. Rotating the chairperson helps
to invo lve isolationists (see below) and control hijackers.

Tip: Put estimated times next to each item on the agenda to keep meetings on track
lO:OOam update f rom team leader

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

238

7-16

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

10:10 brainstorming solution ideas


ll:OOam conclude brainstorming and break into groups to discuss ideas

7.5.

Managing People

In an undergraduate design team, there is a general expectation that everyone is going to contribute
equally. Unfortunately, things do not always work out this way. Because you are all peers, dealing with
people issues can be particularly problematic. You will generally not have available to you the kinds of
levers that are often used in industry (threat of a poor performance review, or f iring). Some instructors
will allow you to warn or fire a team member (Team Strategies (section 21.8)), but generally you will
have to find other strategies for coping with these situat ions. It helps to first identify the type of
problem behavior you are dealing with. We have found that there are a few types of situations involving
team members that come up most frequently. Four of the major issues are hitchhikers, hijackers,
isolationists and enablers. These are particularly problematic because the behavior effects multiple
aspects of their contribution to the team.
Hitchhikers [7] :
Hitchhikers are people who contribute significantly less to a project than everyone else. They seem to
always have an excuse, ("too busy", "test tomorrow so I couldn't make the meeting", " I forgot", " I didn't
know that was assigned to me because I wasn't at the meeting", etc.) Or they just go silent. Don't
return emails, ca lls, or texts, and they often miss meetings. However, they expect to get the same credit

for the work as everyone else on the team.


If you have a hitchhiker on the team and there seems to be a legitimate reason for their nonperformance (they have to work a lot of hours outside school, they have health issues, etc.) then
encourage the person to seek help. There may be a part-time option, or other types, of assistance that
could help to meet the person's needs, but simply putting the work over onto their teammates is not an
acceptable option. This overloads the other team members and is unfair.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

239

7-17

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Hijackers
Hijackers are people who tend to be very anxious about their own grade in the course. They want to
make sure everyone on the team does work that is up to their standards. Often they will disagree
about what the standard of the work should be and if work is substandard in their opinion, they will
often redo it themselves; i.e. "if you want something done right, do it yourself' is their motto. They will
often volunteer to be the team leader so they can have control of the team. And they will use this
leadership position to tell the team what to do and how to do it. While direction from a team leader can
be very important, particularly in the early stages of team development (forming and storming), too
much control exerted by a team leader is abusive and can destroy team motivation.
Hijackers tend to have very little trust in other people's abilities. Hijacked team members often lose
interest in the project, and feel little sense of ownership. Hijacked teams often do well initially when the
hijacker has enough time to redo work but as the pressure builds these teams tend not to function well.
The hijacker is overwhelmed with work, or has some personal crisis, and no one else in the team is in a
position to step in to help because they have been so left out of the decisions and the tasks they don't
know what's going on or what to do. They have little motivation to fix the problem. In the end, work will
not be completed and the team generally does poorly. Interestingly, team members of hijacked teams
frequently "sit back and enjoy the ride" if the hijacker appears to be able to do most of the project
themselves. Those team members will focus on other courses overloading the hijacker further until the
situation implodes and everyone ends up hurt and angry. Teams should be very careful that they do not
place a person with a high need for this kind of control in the position of team leader .

Isolationists
Isolationists are willing to get the work done, usually competently, but don't want to interact with the
team more than minimally necessary. They are the "just tell me what to do, and I'll do it" people. The
work they deliver, while generally acceptable may not f it very well with the rest of the project because
they have not adequately communicated with the rest of the team. They are not involved in team
decisions and do not want to take the time to listen to other teammates. Generally they do not value
input from others. Isolationists tend to cause the formation of subgroups within a team. They cause the
other team members to spend time and energy trying to make the isolationist a happy team member by

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

240

7-18

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

accommodating that person's behavior. The balance between tasks and people will be moved too far
toward the people side as the other team members try to draw this person in. For example, one team
member, who may be an enabler (see below) may offer to call the isolationist after every team meeting
to update them on what went on if the isolationist doesn't want to bother attending these "waste of
t ime" team activities. In this case the team leader should ensure that the isolationist has a role at team
meetings and is required to attend. Strategies that you can use include having them be the chair of
team meetings and a reporting and updating requirement on their tasks. Basically this mechanizes their
team involvement, rather than relying on a good attitude that doesn't exist.

Enablers
Enablers help everyone out. They want to be good helpers and citizens and can end up getting too much
work handed to them because they do not say no. If everyone else is "too busy" they will volunteer for
tasks, and more tasks. They don't mean to take over the project, they are often not the team leader,
and they are not behaving this way because t hey want to control things, they are just trying to make
sure everyone else on the team is happy. As a result, they become overwhelmed and are unable to
deliver on their promises The likely consequence of this behavior is that the team does not meet its
goals. The team and team leader need to be very careful that tasks are assigned evenly and that they do
not overload enablers simply because the person keeps agreeing to take on more work. When tests and
other course assignments loom they will let the team down. While it may be tempting to take
advantage of an enabler, in the end the proj ect generally suffers.

It is a sad fact that hitchhikers, hijackers, isolationists and enablers will be a persistent presence in your
professional career. You might think that people with these destructive work habits would learn and
evolve or fail out. However, this is not the case. This means that strategies you learn now and the
experience you gain from working with these people will serve you well in your career. So if you have a
difficult team member, you may at least take some comfort in knowing that this is an excellent learning
experience.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

241

7 - 19

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

If you have some hitchhiker, hijacker, isolationist or ena bier behaviors, now is the time to stop. You
need to reassess your work habits. These behaviors will not serve you well now, and they will affect
your career. Finding ways to cope with your need for control (if you are a hijacker) or your need to
make people happy (if you are an enabler) in a manner that is effective for you and better for the people
you work with is essential.
Having a good decision making strategy helps avoid a number of these people issues as does having a
clear task list. A task list will help to define roles and responsibilities and the team and team leader and
can make sure the work is distributed evenly. Isolationists and hijackers are two of the most difficult
issues t o deal with and it may be necessary to deal more directly with the problem if it continues.
If you have a team problem then a team mem ber or more usually the team leader must speak to the
person IN PRIVATE and clearly set out what needs to change and why. This is not easy. You must at all
t imes speak objectively to the behavior, not to the person's character. Do not wait too long. If not dealt
with, both the team and the person involved are going to struggle as the workload within the year
increases and all team members are becoming more stressed as they try to meet deadlines and
commitments. If the behavior continues, then move to other resolution strategies. You may want to
involve the instructor to help you deal with the issue. Everyone will have times when they miss
deadlines, disagree or do not get along with the other team members. If this is repeated behavior then
it needs to be addressed.

What if my teammate is in crisis?


You may find that a teammate is having difficulty coping with university or college life (e.g. they are
having hea lth issues, or a personal crisis). Encourage the person to talk to an instructor, administrator,
or school counsellor, or bring it to the attention of your instructor yourself. Virtually all university
campuses will have resources to help a student in crisis. You should not take on the role of councillor
for your teammate; you are not trained for this role. Also you should not just pick up their share of the
work. This may temporarily relieve some of their stress but it does not solve the problem, and it is not
fair to you. Encourage your teammate to get the help they need to rebalance their life.
University of Toronto Engineering: Go to the First Year Office, GB157, to speak with a counsellor.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

242

7-20

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

7. 6.

Strategies tor dealing with task and people problems

Problem: Everyone is responsible for everythi ng, and nothing is getting done!
Strategy: Avoid the "6-year-olds-playing-soccer" problem, i.e. everyone running for the ball. Play
positions. Make sure you have a clear task list and each task has a lead person who is responsible.
Others may help with a task, but you should have one person who is assigned to deliver on each task.
When you develop your action items for agendas think of them not j ust as assignment of tasks, but
assignment of responsibility. Avoid task lists that read:
1)

Researching the problem - everyone

2)

Writing the report -- everyone

Divide up these large tasks and rna ke sure everyone has a defined piece to contribute.
Problem : Work delivered late.
Strategy: What to do if one (or more) of the team is delivering their work so close to a deadline that the
team leader (or whoever is assigned to compile the document for submission) doesn't have time to do a
good job? The most effective strategy is to move up internal deadlines. Everyone on the team needs to
deliver their work even earlier. This gives time for remediation of the situation. Consider the two
scenarios below:
Scenario #1: the team agrees to get their document together at 5:00pm the day befo re the deadline so
they can edit and proofread t he report before submission.

However, one person is running late with

their work. Their part took longer to write tha n expected and when their piece shows up 5 hours late it
is not well written. The team is now in crisis. Arguments erupt over whether to rewrite this section, or
j ust leave it as is. Everyone is t ired, angry and resentf ul. The problem was not with this one team
member, the problem was the plan. The team's plan was overly optimistic. It left no room for delays or
problems.
Scenario #2: the team agrees to get t heir document together at 5:00pm two days before the deadline
so they can edit and proofread the report before submission. However, one person is running late wit h
their work. The team rules say that the team will give the person a "final notice", i.e. a warning that the

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

243

7 - 21

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

work must come in now or the rest of the team will begin writing up the missing sections. The final
notice is sent at ll:OOpm. The person responds by sending a piece of work that is not well written.
Now the team has at least 30 hours to decide what to do and remediate the situation. There is t ime to
ask the person to rewrite their section, working with them to support the effort. Or implement another
remediation plan.
It is important that the whole team take responsibility for putting together their work earlier, not just
the person who is "always late". Everyone has things that go wrong in their lives from time to time.
There will be a t ime when you are running late with your work too. It is important that you build in
some buffering to your team schedule to account for the realities of life.
Problem: Poor quality work.
Strategy: We have two suggested strategies for coping with poor quality work. Both revolve around the
philosophy that the person who delivered the poor quality work shou ld not be rewar ded. In an
engineering program, one of your most valuable resources is time; you never have enough to do
everything. A person who delivers poor quality work is hoping to save some of their time, at the cost of
your t ime (if you are the person who is expected to "fix up" their work).
Strategy #1 - time blocking. Arrange team work sessions that are 3 or 4 hours in duration. Hold them in
a location where people can have access to computers, or can plug in their laptops. There is a set of
fixed goals for the session, e.g. everyone needs to finish a f irst draft of their section. If the team all
meets the goal early, trade around work, start editing, and then reward yourselves w ith a little t ime out.
Strategy #2 - out-loud editing. Team member Alice gives her work to team member Bob for editing.
Both sit together and Bob starts going through the work explaining, out loud, what his impression of the
work is and what needs to be fixed. Bob must do this in a respectful and constructive way. Bob makes
changes to the first few paragraphs to demonstrate the process for Alice. After a couple paragraphs Bob
hands the work back to Alice. Alice now knows what Bob " sees" as the problems with her work. She is
given some t ime to fix it up before the next out loud edit session. Bob should also have his work out
loud edited by someone else. Overall this process improves both the writing, and the edit ing skills of
everyone on the team .

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

244

7-22

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Notice that in both of these strategies people who produce poor quality work are neither rewarded
(with more free time) nor punished. They are given support to help them accomplish the team goal, and
treated with respect. All of us will need support of this kind at one t ime or another i n our careers.
Engineers are constantly teaching each other and learning from each other; it is an important part of the
profession.
If you have a teammate who is not the best colleague or writer but who is really t rying, give them credit
for their effort. Make sure you praise your team mates for what they are doing, and f or the energy they
are putting into the project. You will work with plenty of people who have a poor attitude and don't
make an effort, so make sure you show your appreciation when you work with good people. All of us
have areas of strength and weakness, but bringing a good attitude and a willingness to work to a project
should be supported.

7.7.

Conclusion

Remember, a team is not simply the sum of its parts. Highly successful teams are able to leverage the
differences in people's abilities and styles to be productive. Working in teams can be a challenge but
they can also be a fun and effective way to produce high quality work. The tools and strategies provided
in this chapter should help you and your teammates to form a strong highly effective design team.
Learning team skills will provide you with valuable knowledge for success in university or college and in
your career.

Learning Objectives:
By the end of this chapter you should be able to:
Recall and define the important terms introduced in this chapter
Explain the essential concepts in the chapter and how they are utilized in, or relate to, effective
teaming and the engineering design process
Apply the strategies discussed to form, and manage an effective team
Analyze team problems and suggest remediation strategies to deal with them
Utilize tools such as agendas, minutes, and a project plan, to keep a team on t rack

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

245

7 - 23

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Key Terms:
Team

Performing

Cross functional team

Adjourning

Within function team

Organizing

Pseudo team

Producing

Potent ial team

Purpose

Real team

Team rules

High performance team

Team beliefs

Reflection

Team charter

Forming

Agenda

Storming

Minutes

Norming

Compromise

Consensus

Project manager

Deciding how to decide

PERT chart

Performance measures

Gantt chart

strategic

hitchhikers

Hijackers

Isolationists

enablers

Summary Table

This table will have three columns: The stage, what should be happening in that stage, the tools.

References
[1] M. Hensey, Collective Excellence, Building Effective Teams, 2"d Edition, Reston, VA: ASCE Press, 2001.
[2] K.A. Smith, Teamwork and Project Management, McGraw Hill Higher Education, 2004.
[3] J.R. Katzenbach and D.K. Smith, The wisdom of teams: Creating the high-performance organization,
Boston, MA: Harvard Business School Press, 1993.
[4] B. Tuckman, Developmental sequence in small groups, Psychological Bu lliten 63 ('6): 384-99, 1965.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

246

7-24

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

[5) B.W. Tuckman and M.C. Jensen, Stages of Small-Group Development Revisited, Group &

Organization Studies (pre-1986); Dec 1977, pg 419.


[6) J. Syer and C. Connolly, How teamwork works: the dynamics of effective team development, McGrawHill, 1996.
[7) B. Oakley, It Takes Two to Tango: How 'Good' Students Enable Problematic Behavior in Teams,

Journal of Student Centered Learning, Volume 1, Issue 1, Fall, 2002, pp. 19-27.
[8] R.F. Fisher and W. Ury, Getting to Yes: Negotiating agreement without giving in, New York, NY:
Penguin Books, 1991.

7.8.
7.8.1.

Team Strategies
Negotiating conflict

In, Getting to Yes, Roger Fisher and William Ury define a system for mediation that is highly applicable to
the storming and norming phases of team development [8). They claim that there is little to be gained
by arguing over "positions." A "position" or a "stand" is a statement of a belief that something is true or
right. It might be your position, for example, that the people who work harder should get the greater
reward and that people who do not work hard should be punished. The problem is t hat you can waste a
lot of t ime arguing about whether one person's "position" is more valid than another's. Below, Fisher
and Ury's four-step process is adapted for Engineering Design Teams:

1. Separate the "people" from the "problem.'' It is easy, when you are having a conflict, to get
emotional and blame a person for the problem. But if you can back away from that, perhaps by
allowing time to "cool off' a bit, you can start to see the problem as separate from the person or
people involved and turn your attention away from " blaming" and onto "solving." In other
words, it's not really going to help to figure out whose fault a problem is and then punish or
humiliate the person. While it might seem like some kind of justice, the problem will still be
there and have to be solved anyway. Try to turn your attention to defining the problem itself
and away from "blaming" the parties responsible.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

247

7-25

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

2.

Focus on "interests," not "positions." Instead of arguing about who is right and who is wrong,

ask one another what do you actually want? The best solution to a problem is not a matter of
rewarding the right people and punishing the wrong people. The best solution gets people most
of what they want.
3.

Develop solutions that will benefit everyone. Once you have achieved step 2, start to generate

ideas that will achieve it. This is much like generating alternative solutions to a design problem
and you can use many of the same tools, such as brainstorming.
4.

Define effective performance measures. After you have agreement on beneficial solutions, you

have to come up with a systematic way to put them into practice and monitor them. Some
Project Management tools would be effective here. As with Team Rules, these methods have to
be both efficient and effective, but as opposed to the Forming stage, you now know the team
fairly well and have an idea of processes that will not work. Defining the processes that do work
enable you to move onto the next stage, Performing.

7.8.2.

Deciding how to decide

As a team you must decide how to decide. It m ay come as a surprise that tools that are often associated
with creativity can also be used for decision making and critical thinking. These tools tend to come in
two fo rms: tools which help you generate ideas and those that help you select them. The selection
tools help you decide. [link to decision making tools].
For design process decisions there are many tools that can be used. However, most simple team
decisions do not require anything more comp lex than voting or consensus. Decision making can be a
considerable source of frustration for many teams. Decision making is one of the most difficult parts of
team work because you will need to live with, and support, decisions that you don't agree with. This is
part of being a good team player. So what is t he best way of deciding? There are many choices,
consensus, voting, let the team leader decide, and so on. We have found that undergraduate design
teams typica lly choose consensus or voting for decision making. There are pros and cons to each of
these strategies. You should also probably have in place a "crisis" decision making strategy.
Voting: Team decisions can be made by a simple majority vote. Voting can be done secretly, but more
typically is done through a public declaration (e.g. raising hands). If your team has an even number of
people then you will need to decide how a t ie will be broken.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

248

7 - 26

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Advantages: Voting is quick and definitive.


Disadvantages: Voting may cut short discussion, i.e. group processing. In the design process, discussion
is one of the most important activities. Listening to everyone's perspective and valuing t heir ideas is an
essential step in moving from a pseudo team or potential team to a real team. If you choose voting,
then you should also put in place a strategy to make sure that there is adequate discussion, and that
everyone has a chance to express their opinion before a vote takes place.
Consensus: Team decisions can be made by consensus. Consensus is formed through discussion.
Consensus does not mean that everyone agrees with a decision. It means that everyone agrees that
they can live with a decision. Some members of the team may disagree with a choice, but agree to go
along w ith, and support, the choice. This is consensus. If you choose consensus then every member of
the team must agree to support decisions once they have been made.
Advantages: consensus generally requires discussion, which is an important part of the design process.
Teams that are good at consensus will make sure that every member has an opportunity to express their
opinion, and be listened to, before a choice is made. This process can build team coherence and lead to
decisions that are better thought through.
Disadvantages: Consensus can take longer than a simple voting process. Or teams can get stuck, going
around in circles trying to reach consensus and never make difficult decisions.

If you choose to use

consensus it is important to also have a strategy for moving forward if consensus fails on an important
decision that has to be made.
Crisis decision making: There will be t imes when you do not have time for consensus and not all of the
team members are available for a vote. For example, 15 minutes before a deadline when you rea lize
that your report is missing a key figure. Your team needs to have a process for making decisions in
these tight situations. This may never be needed, but it is useful to have in place just in case. The
typica l strategy is to empower the person in charge to make an "executive decision" on the spot. So if
you have tasked one person to submit the report and they find the error, then they are empowered to
decide what to do; include a rough hand drawn sketch, leave the page out, add in a note, or wait for a
print out of the figure and get a late penalty on the report. Crisis decision making is very stressful and
difficult, unless you have a lot of practice at it (e.g. emergency room doctors). Everyone has to agree
that whatever the person decides to do, you all will do your best to support the decision.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

249

7-27

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

7.8.3.

Using an Attribution Table or Statement

An attribution table or statement can be used to show which team member contributed to a document
and what they contributed. [link to the template back page] The attribution table should be reviewed
by all of the team members prior to submission to make sure that all members agree on the information
given in the table. The information must be fair and accurate. Instructors may use this type of table to
assess the quality of the contributions made by each team member.

An attribution table, or a

statement of attribution, is a useful way to help your instructor understand the qual ity of the teamwork
that went into a project, and identify if there are issues with one of the team members.

7.8.4.

Sharing your work

The comments written on a team document by an instructor or teaching assistant belong to the entire
team. It is not acceptable for a member of the team to ref use to share these comments. Also, it is the
responsibility of each team member to make available to their teammates the written work they have
prepared for the shared project. This includes meeting minutes, notes from client int erviews, drafts of
reports, etc. Withholding work that pertains to the team project, or instructor feedback, f rom your
teammates is considered academic dishonesty and demonstrates poor team skills.
If you are f rustrated by the dynamics within your team, and/or your teammates' behaviour, it is
import.ant to address this in an appropriate, effective, and professional way. Team discussion, or
discussion with your instructor can help you resolve these issues and help you, as a team, develop
strategies for working successfully with each other. Remember: most projects do NOT fail for technical
reasons; they fail because of planning and team problems. Get help early; don't let things boil over
before bringing problems forward.

7.8.5.

Warning and/or firing a team member

Not all instructors wi ll allow you to fire a team member. However, if they do then f iring a team member
is a strategy of last resort. All fair and reasonable attempts should be made to keep the team

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

250

7 - 28

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

functioning and keep all of the members actively participating. However, if remediation fails and a team
concludes that a member is causing substantial difficulty or repeatedly not cont ributing, that member
can be fired. Typically firing can only occur with the approval of the instructor and must follow a specific
procedure. The procedure we recommend:

1. The team will issue a warning letter to the person informing him or her of the situation, i.e. that
the person will be f ired from the team unless change occurs. This letter should be reviewed by
the instructor before being sent to the team member. The letter must use a professional tone
and cite specif ic behaviours t hat the person must change in order to remain part of the team.
2. After the warning letter is sent, the instructor will meet with the team together and, if
appropriate, separately with the person who is under warning. The goal of these meetings is to:
a.

Determine what, at a minimum, t he team member must change to be retained. The


instructor will act as a mediator in this discussion, but will also be allowed to veto requested
behaviour changes if he/she feels the request by the team is excessive or inappropriate (i.e.
vindictive).

b. Work with the person under warning to develop strategies to allow him/her to meet this
minimum (and preferably exceed the minimum) requirements necessary t o remain in the
team. lndentify if there are underlying problems (personal crisis, health problems) that are
affecting the person, and help them to connect with appropriate services on campus.
c.

Determine if the person does not intend to change their behavior which is causing the
problem.

3.

If the person refuses to meet with the instructor, or ignores requests for a meeting, the team
may proceed with the f iring procedure subj ect to approval by the instructor.

4.

If the situation persists, or if the person has ref used (or ignored) the request to change their
behaviour, the instructor may approve the f iring. This approval shall be in w r iting and shall be
copied to other administrators if necessary.

5. The team may then inform the person that he or she is fired. This is done in a letter copied to
the instructor. The letter shall be reviewed with the instructor prior to sending it. The letter
must have a professional tone, and should be short and to the point. The lett er shall state the
specific date on which the team member is officially fired. The letter shall briefly cite t he reasons
for the dismissal.
Note: for the purposes of this procedure a " letter" may be a properly formatted email.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

251

7 - 29

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

A student who is f ired from a team can be hired by another team and finish out the course with the new
team. lrlowever, it is the responsibility of the student to f ind a team willing to hire him/her. The student
will receive a zero for any assignments that were not accomplished because the student was not part of
a design team after being fired . Work submitted for a team assignment that has been developed solely
by the fired student, in the absence of the team's contribution, will not be acceptable.
We have found that a clear, well written warning letter is often sufficient to get a person back on track
and contributing, at least minimally, to the project.

7.8.6. Quitting a team


Not all instructors wi ll allow you to quit your team . However, if they do then quitting a team is a
strategy of last resort. All fair and reasonable attempts should be made to keep the team functioning
and keep all of the members actively participating. However, if remediation fails and you have
substantial cause, you can quit your team. You can only quit with the approva l of the instructor and
must follow a specific procedure.

1. You will issue a warning letter to your team informing them of the situation, i.e. that you are
ready to quit the team unless change occurs. This letter shall be reviewed with the instructor
before it is sent. The letter must use a professional tone and cite specific behaviours that the
team must change in order for you to stay.
2.

After the warning letter is sent the instructor will meet w ith the team together and, if
appropriate, separately with the person who is considering quitting. The goal of these meetings
is to:
a.

Determine what, at a minimum, t he team must change to retain the team member. The
instructor will act as a mediator in this discussion but will also be allowed to veto requested
behaviour changes if he/she feels the request is excessive or inappropriate (i.e. the
instructor will act as the judge of what is reasonable).

b. Work with the person who is considering quitting to develop strategies that allow him/her
to have their needs met within their team.
c.

Determine if the team does not intend to change their behaviour which is causing the
problem.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

252

7-30

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

d. If the team is unwilling to change to retain the team member, the team member may quit
subject to approval by the instructor.
3.

The approval from the instructor shall be in writing and shall be copied to oth er administrators if
necessary.

4.

The team member may then inform the team that he or she is quitting and give a specific date
when this w ill occur. This is done in a letter copied to the instr uctor. The letter shall be reviewed
with the instructor prior to sending it. The letter must have a professional tone, and should be
short and to the point. The letter shall briefly cite the reasons for the departure.

Note: for the purposes of this procedure a "letter" may be a properly formatted email.

A student who has quit a team can be hired by another team and finish out the course with the new
team. However, it is the responsibility of the student to find a team willing to hire him/her. The student
will receive a zero for any assignments that were not accomplished because the student was not part of
a design team at the time of the assignment due date. Also, the quitting student must leave copies of
any work developed for the project up until their departure date with their team to use.
Work submitted for a team assignment that has been developed solely by an individual student, in the
absence of the team's contribution, will not be acceptable.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

253

7-31

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Part 3- Cases and Tools


The chapters in Part 3 present case studies and tools. The case studies are used as examples in the text
and for use by the instructor in lecture. The tools chapters describe methods that are commonly used in
the design process such as idea generation methods and decision making techniques. In the final
version of the text these chapters will be hyperlinked into the main chapters where appropriate.
Chapter 8: Case Studies
Chapter 9: Creativity Methods
Chapter 10: Decision Making Tools
Chapter 11: Design and Critical Analysis Techniques
Chapter 12: Templates
Chapter 13: Glossary

Chapter 8: Case Studies


Table of Contents for this chapter

1.1.

Aerial
1.1.1.
1.1.2.
1.1.3.
1.1.4.

Photography Case Study


Client Statement
Comments on the client statement
Problem Statement
Problem Definition

We intend to include a wide variety of case studies that cover both historica l cases an d simple, but
authentic cases. The historical cases are used to illustrate concepts developed in the text and can be
used by the instructor as the basis for more extensive research projects. The simple cases are drawn
from authentic situations and are situated in contexts that are more familiar to students. Most of the
cases wil l not be given as complete examples, but instead can be used as the basis for class projects, test
questions, homework, or classroom demonstrations to illustrate application of the concepts discussed in
the text. For this custom version of the text we have j ust included the one case study that is used
extensively as an example in the main chapters.
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

254

8 -1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

1.1.

Aerial Photography Case Study

1.1.1. Client Statement

The following is the client statement from Tori Noir, a Toronto photographer.
I am the owner and head photographer of Noir Photography a small photography studio serving Toronto
and the GTA. We specialize in wedding and event photography, and also work on portraits and fashion
photography.
A client has recently asked me to take a photograph of all 400 of the guests at her wedding and I have
realized that I have no way to do this. I cannot take a group photograph of all of those people without
taking it from high above the ground. I would like to provide my client with the option of aerial
photography and so I am requesting that you design for me something that will allow me to take photos
of parties from above. In the future I plan on making this an option for all of my clients. I think this will
be most popular at weddings and other large parties, though we also take photos of smaller events.
Like I mentioned, we cover parties and weddings throughout the year, both indoor and outdoor. Usually
there are 100 or more guests at these events. When I shoot an event I will normally have my
photography assistant with me to help with the shots. The camera I use is a Canon EOS-SD with an EF
24-70mm f/2.8 L USM lens and so the device will have to allow me to lift it up high enough to take
pictures of the guests, this is probably only be about 10-lSft. However, for my convenience it needs to
be collapsible so it can fit in my car.
In addition to f itting all of the guests in, I must also maintain a certain quality of photo because this is,
after all, my profession. I need to be able to adjust my camera to get the best shot possible. An
extremely tall tripod could do it, but it is essential that I have a way to control the camera.
In terms of cost, we're a fairly small business and so I don't want to spend a fortune on this device
unless I know for sure it is worth it and will last long enough so that the cost is justified.
I hope you will be able to help me with this project. You may contact me at peter@noirphotography.ca
if you need anything else.

Tori Noir

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

255

8-2

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

1.1.2. Comments on the client statement


Comments written by M. Chang, third year student at the University ofToronto, 2011
Clients often provide statements to engineers providing them with information on the problem they
wish for the engineer to solve. When first looking at this client statement it looks short, however it does
a good j ob at giving context to the problem and explaining from where the problem has arisen. There
are various problems that may be found in this statement including ambiguous and i rrelevant
information, solution driven statements, and erroneous information.
In this client statement there are various cases of ambiguous information. In the second paragraph the
client says that he takes photos at both large and small events. This is an example of ambiguous
information because there is no specific description of how many guests are present at a small wedding
or a large event. In the fourth paragraph, the reference to being able to adj ust the camera is vague. It
does not disclose what kind of adjustments are required, like how much movement is needed and if this
includes zooming and focusing. In the fifth paragraph, the client says he does not want to spend too
much on the solution, but he does not give a specific number as to what would be too much. If you are
able to contact the client again you can clarify what these numbers and adjustments are. If you are not
able to contact the client, you can do research on the topics.
When analyzing a client statement you must also be able to pick out what information is useable and
what is irrelevant. In the third paragraph the number of guests at these events is mentioned again. The
client says that most of his events have 100 or more guests. This number may seem helpful at first but
when you really look into it this information does not provide anything at all. It would be much more
helpful if he had provided a range of guests, for example: "The events that I attend have at a minimum
50 guests, and at a maximum 500 guests. If a range like that had been provided you would have more
solid information to base any calculations off of. It is important to be able to distinguish between useful
information and information that is just cluttering the client statement. This ability will allow you to
properly define your problem.
Solution driven statements are also often found in client statements. In the third paragraph the
reference to being able to lift the camera up high enough to take the photo is a solution driven
statement. While there may be solutions in which lifting the camera is required, there may also be
solutions in which the camera does not have t o be raised in order to take an aerial photo. In addition,

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

256

8-3

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

another solution driven statement is the declaration that the solution must be collapsible. This
statement was made on the assumption that the solution will be too large to fit in a car if it is not
collapsible. An objective that can be derived from this that is not solution driven is that the solution
must be portable. Solution driven statements are something that you must look out for to ensure that
you stay solution independent.
Clients are also prone to include erroneous information in their statements. The reference to the
solution resulting in a photograph being taken from 10-15ft above the ground is most likely erroneous.
There is no way of knowing where the client has gotten these numbers from, they could be carefully
calculated or they could be completely arbitrary. It is best to assume that this information is an error
and do your own calculations to ensure that you have the correct information.

1.1.3. Problem Statement


This case study was written by M. Chang, third year student at the University of Toronto, 2011. It is a
first draft; the requirements are still incomplete and the research done on the problem is limited. It has
not been vetted by the course instructors. However, it should give you an idea of the type of work
required to develop the definition of a design problem.
The client, Peter Noir, is the owner of a small photography studio that specializes in providing wedding
and event photography to Toronto and the GTA. He has approached the design team requesting a way
to take aerial photographs of the guests at the events he shoots. In addition to providing this main
function the solution should also be easy to use, low cost, and able to accommodate different types of
cameras other than the DSLR he uses primarily. In addition to these objectives there are some
constraints that must be met. The solution is required to be operated with the aid of at most 2 people,
2

take photos of areas of 50m to 500m , and accommodate the Canon EOS-5D and a wide variety of
lenses. This solution will be used at both indoor and outdoor events, as such, the physical, and virtual
characteristics will be taken into consideration a long with the characteristics of any people or animate
beings to come in contact with it. The users and operators ofthe solution are the client and any other
photographers employed under Nair Photography. As such, their concerns, along with other
stakeholders of the proj ect, will play a large role in design decisions. In addition, human, safety, and
environmental factors will be considered throughout the design process.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

257

8-4

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

1.1.4.

Problem Definition

Functions
Functions are what the design must accomplish to solve the client's problem. The primary function is
the overall function of the solution, while the secondary functions are sub-functions required to
accomplish the primary function.
Primary Function

The primary function is what the design must do in order to meet the needs ofthe client. The primary
function of this design is:
To allow the client to take a professional aeria I photograph of people at an event
Secondary Functions

The secondary functions are what the design must do in order to accomplish the primary function. The
secondary functions are:
Allow the camera to view a subject from above
Frame the image
Adjust zoom
Adjust aperture
Adjust shutter speed
Focus the image
Take the photograph
Return the camera to the photographer

Objectives
Objectives are what the client would like the design to be, but are not necessary to accomplish the
primary function. The obj ectives for this design are outlined in Table 1 below with specific goals for
each objective. The objectives are ranked from top to bottom f rom most important to least important
as determined by a pairwise comparison (Appendix A).

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

258

8-5

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Table 1: Objectives

Rank

Objective

Description

Goal

Durable

Maximizing the solution's

Minimum 5 years or 100

lifetime

uses

Requiring 2 or fewer people to

Less than 2 uses to fully

use and obvious operation

understand solution

Easy to use

requiring a minimal amount of


time to learn

Low Cost

Imposing minimal expense to

Less than $500

the client
4

Easy to Set Up

Requiring 2 or fewer people to

Less than 10 minutes

assemble in a minimal amount


of t ime
5

Easy to Maintain

Using standard spare parts in as

No custom parts are

many cases as possible

required

Constraints
Constraints are what the design must be. If the constraints are not met the design w ill not be accepted
by the client. The constraints for this design are that it must be:
Able to be operated by at most 2 people
Able to be used in any setting
Safe to all users and surrounding bystanders
2

Able to take photos of areas of 50m to 500m

Non-damaging to the camera


Portable - able to fit within a space of 1m

Able to accommodate daytime and night-t ime shooting


Compliant with all applicable Ontario, Toronto, and Canadian laws, bylaws, and regulations
Accommodating to the Canon EOS-5D
Accommodating to standard, wide angle, zoom, and telephoto lenses

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

259

8-6

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Service Environment
Physical Environment

The physical environment is a description of the physical characteristics of the location in which the
design is expected to be used. Based on the client's needs the design will be required to function both
indoors and outdoors. Indoor events will most often be taking place inside of banquet halls, churches or
restaurants. These environments will have average room temperatures of around 21c and no more
than 26.C[l]. In addition, indoors there are height restrictions depending on the height of any ceilings.
Weddings and events often take place outside where the weather plays a large role in the environment.
Weddings can be scheduled for any time of the year and as such the client may be required to take
outdoor aerial photos in any weather condition possible in the Toronto and Greater Toronto Area. This
includes sunshine, clouds, rain, snow, wind, and hail. The average temperature range ofthis area is
17.6 c to 26SC in the summer and -1.3c to -7.9c in the winter [2). Average rainfall is 7l.Omm in the
summer and 22.7mm in the winter [2] . Average snowfall is 35.5cm in the winter [2]. In addition, the
landscape of the outdoor environment may include grassy, muddy, or paved areas and uneven ground.
The average wind speed in Toronto and the GTA is 9 knots [3].
People and Animate Beings

People and animate beings refer to people and other living things in the environment that may
potentially affect the design. The main users of this design are the photographer and his assistant. Both
are adults. There will be many crowds present at the weddings and events that the photographer will
be attending. The sizes of these crowds range f rom 50-500 guests. These guests will include a diverse
range of individuals. The ages of the guests can range from newborn babies and young children to
elderly seniors (ages 0 to 100+).
Virtual Environment

The virtual envi ronment is a description of all of the virtual systems that may affect the design. As the
environment in which the device is being used changes from venue to venue, cell phone service,
wireless networks, and satellite networks are unpredictable and thus unreliable. In addition, the
availability of electricity is unreliable as well, due to some venues being located outdoors, while others
are indoors.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

260

8-7

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Users and Operators


The users and operators of this design are the client, Peter Nair and any other photographers and
photography assistants associated with Nair Photography.

Physical
The physical description ofthe users and operators include the physical characteristics that should be
taken into consideration during the design process. The users and operators are assumed to be all
photographers and photography assistants in the age of adulthood. They may be either male or female.
The height of an average North American male is 69.4 inches, and the height of an average North
American female is 63.8 inches [4]. There is a possibility that for the photographer or assistant to be
using a wheelchair due to disability as well.

Psychological
The psychological description ofthe users and operators include languages spoken, level of education,
along w ith any significant psychological norms. It is assumed that all users w ill have the ability to read
and speak English. As the users are primarily photographers it will not be assumed t hat they have all
received a post-secondary degree or even a secondary school degree, as there is mandatory level of
schooling required to be a photographer. As for special skills and knowledge, it is assumed that each
user and operat or has an expert knowledge of photography. This leads to some psychological norms
involving the use of photography equipment like cameras, lenses, lighting, and tripods.

Social
The social description includes any social norms or cultural commonalities exhibited by the users and
operators. As the users and operators are all photographers, or photography assistants, a common
social norm between them would be the belief in the value of t ime. Taking photos is all about capturing
the correct moment at the right time. As such, they highly value not wasting time on things that distract
from their photo capturing t ime.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

261

8 -8

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Organi.zational
The organizational description includes any organizational ethics or values shared by all users and
operators. Each of the users and operators are employees of Nair Photography. As it is a professional
photography studio, the employees want to portray this image to their clients and make a good
impression. In addition, it is their highest priority to deliver high quality photographs to their clients in
order to continue the growth of t he business. Much like most companies, they wish to maximize their
income and minimize their expenses.

Stakeholders
Stakeholders are parties outside of the client,

users, and design team that have a stake in the design

decisions. The interests of each of the stakeholders have been categorized into either economic, social
impact, ethics and morality, legality, or environmental impact concerns in table 2 below.
Table 2: Stakeholders

Stakeholder

Int erests

Client of Nair Photography

Economic:
concerned with the cost of the service which will be
relative to cost of the aerial photography solution
wants the best quality of service for the event
does not want to waste t ime while paying the client
Social Impact
concerned with keeping the guests happy

wou ld like minimal disruptions during the event


Guests of client's event

Social Impact
Concerned with the professionalism and quality of
photography
Do not want to be disrupted
Do not want their time to be wasted

Venue coordinators

Economics
Do not want any aerial photography solution to cause
harm to the venue

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

262

8-9

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Patent Regulators

Legality
Do not want any patents to be infringed

Environmental NGOs

Legality
Concerned that the solution may violate loca I bylaws,
laws, and regulations
Environmental Impact
Do not want any solution to have a negative impact on
the environment either by use of materials or damage to
the earth

Design for Human Factors


Designi ng for human factors involves taking into account how the solution will interact with the humans
physically, psychologically, socially, and organizationally in order to fit the design to humans, rather than
making humans fit to the design. For this design proj ect, the user is a human, and so it is beneficial to
both the client and the user to have the design compliment the human form.

Design for Safety


Designing for safety involves considering the safety of all the design's stakeholders during the design
process and addressing all safety concerns. As the solution is to be used at large events with many
people, it is important to consider safety in order to ensure no one is harmed.
References
[!]"Property Standards." Internet: http://www.toronto.ca/legdocs/municode/1184 629.pdf, [Jul. 7,
2011].
[2] City ofToronto. "Toronto's Climate." Internet:
http://www.toronto.ca/toront o overview/climate.htm, [Jul. 7, 2011].
[3] Weatherfinder. "Wind & weather statistic Toronto Island." Internet:
http://www.windfinder.com/windst ats/windstatistic toronto island.htm, May 2011 [Jul. 7, 2011]
[4] Centers for Disease Control and Prevention. "Body Measurements." Internet:
http://www.cdc.gov/nchs/fastats/bodymeas.htm, April 2, 2009 [Jul. 7, 2011].
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

263

8 - 10

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Chapter 9: Creativity Methods


Table of Contents for this chapter

9.1.

Brainstorming

9.1.1.

Free Brainstorming

9.1.2.

Structured Brainstorming

9.2.

Nominal Group Technique

9.3.

SCAMPER

9.4.

Black Box method

9.5.

Decomposition

9.5.1.

Function-Means trees

9.6.

Morphologica l Charts

9.7.

ANALOGY

9.8.

TRIZ

The following sections describe some creativity methods that can be used to generat e ideas. These can
be used for design projects, but also for other creative activities. The production of new ideas is usefu l
at every stage of the design process: generating requirements, developing new solution ideas, and
creating evaluation and implementation methods. Different tools will be useful at different points in the
process.

9.1.

Brainstorming

The term brainstorming is usually used to describe the process in which a group of people have an
intensive session of idea generation. Brainstorming is used to generate a large number of ideas, and if
successful, unusual ideas, in a relatively short t ime. The concept of brainstorming was developed by
Alex Osborn and is used to generate ideas to address a specific question or defined problem [1]. The
main focus of this technique is to generate a large quantity of ideas without worrying about their
quality.

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

264

9-1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Many people have come to believe that the quantity and qua lity of ideas generated in a group is much
better than what would be generated by the individuals in the group operating alone. In fact, extensive
experimental research demonstrates that the opposite is true: individuals significantly outperform
groups [2] . Osborn himself recognized that "The creative power of the individual counts most" [3] and
recommended group brainstorming "solely as a supplement to individual ideation." [4] Stroebe et al.
discussed three possible reasons for the relatively poor performance of groups [2]:

Free riding (some members don't participate)


Social Inhibition (members afraid to put forward their ideas)
Production blocking (time waiting for others to speak is unproductive and ideas are lost)
Of these three, research suggests that production blocking is the primary cause of the loss in
productivity in a group session [3]. The necessity to wait for others to speak reduces the productivity of
an individual in a group setting. The longer the average wait time is, the greater the effect.
There are a number of variations on ru les and variations devised for brainstorming which attempt to
mitigate these issues. We will focus on two br ainstorming methods. One is often ca ll "free
brainstorming" and the other is referred to as "structured brainstorming" . Free brainstorming may be
the concept that you are most familiar with. In free brainstorming, all the participants generate ideas as
a group and someone records the ideas. People often talk across one another, and shout out their
ideas. It is fast paced but sometimes quieter people or people who need to take a little more time are
left out in this type of brainstorming (this is referred to as production blocking) . Structured
brainstorming offers an alternative and can be done in a number of ways. The underlying premise is to
provide a method where people can sit quietly for 5-10 minutes and generate ideas on their own before
they suggest them to the group. The details of the two methods are provided below.
In order for brainstorming of any type (and indeed most idea generation techniques) to be successful,
there are some basic guidelines to follow. These were origina lly described by Osborn and have been
modified somewhat since that first publication.

1.

Seek quantity: The idea here is that by generating a large number of ideas, high quality

innovative solutions will come through.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

265

9-2

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

2.

No criticism: When t here is no criticism people feel freer to generate more ideas. You should

not make either positive or negative comments about the ideas. Even positive ideas indicated
j udgment.
3.

Get all the ideas out: Encourage unusual ideas and freewheeling. Team members should not be

inhibited about providing a " wild" or "unrealistic" idea. These ideas often form the basis for
very original solutions. They can also provide a trigger for another new idea f rom someone else.
Every ideas counts and when you are generating your list, duplicates are allowed. You will
remove them later.
4.

Combine and improve ideas: Good ideas may be combined to form a single better idea. It is

helpful to pick up on the ideas of others and to look at combinations or associations. This helps
build more ideas.
The ability to bui ld on others' ideas is an obvious advantage to the group setting. It is possible for an
individual to miss an entire line of thinking if working on his or her own, and yet still have useful
contributions to that line once exposed to it. One method of combining the advantages of the group
and individual modes is to link participants anonymously by computer. This eliminat es social inhibition,
and if more than one person can post to the communal board at the same time, production blocking is
also eliminated. Gallupe et al. found that the production of electronically linked groups increased with
group size, whereas the production of physical groups did not [5]. Surprisingly, in an anonymous
comput er based platform, studies have shown that critical comments were actually b enef icial and
improved the production of the group [6].
What does all this mean for your brainstorming activities? Obviously, you need to be careful in
depending solely on group brainstorming. When conducting a session, it is usef ul to observe Osborn's
rules; encouraging quantity, building on the ideas of others and suppressing criticism. If you are running
a face-to-face session where production blocking is going to be an issue, you could try a dual recording
system, in which participants record thei r own ideas individually, then pass them along to the group
when the opportunity arises. You could also use the structured brainstorming approach, in which you
do some individual work prior to coming together as a group. Finally, you could t ry an online
collaboration system, preferably one that is anonymous.
You should always add time pressure when brainstorming. People will respond if you limit their time and
a bit of competition to the brainstorming sess,ion. Groups that are highly practiced in brainstorming can

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

266

9 -3

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

generate hundreds of ideas in less than 15-20 minutes (groups of 5 or so). Many of the ideas will not be
appropriate but some will inevitably be useful and creative.
Post-it Notes

Post-It notes can be used to great advantage in brainstorming. There are generally two techniques that
are used and in both cases use large 4" by 6" notes. Use only one colour so that no i ndividual person' s
ideas can be identif ied. In the first method, people write their ideas on the notes and as they write they
read out their idea (this is closer to "free" brainstorming) and in the second, the team members write on
their post-it notes and then at the end of the idea generation come up and place the notes on f lip charts
or on the wall (this is more like structured brainstorming).
Post it notes can also be very useful for moving to idea selection. You can group the ideas under
themes, eliminate duplicates and use the notes for ranking as well. In addition, placing the notes on f lip
charts or a wall helps to get people up and moving. This helps the creativity and the team building.
link t o video of Google team brainstorming

9.1.1.

Free Brainstorming

W hen t o use:

You use brainstorming to generate a large number of ideas for requirements or concept generation.
Brainstorming should be used with a well defined question or problem. It is strictly for uninhibited idea
generation, not for selection. Free brainstorming generally works well if the team knows each other and
is comfortable with one another. If you start t o free brainstorm and find that one or two people are
dominating, then it is a good idea to move to a more structured style so that all members ofthe team
can participate.
How to use:

In order to free brainstorm, you will need someone to lead the session and to record and show the ideas
generated. You may wish to use f lip charts or a computer and projector. In free brainstorming, one
person records the ideas as they are generated by the group and leads or facilitates the brainstorming.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

267

9-4

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

The person who is recording will need to be able to record quickly and to respond when the ideas start
to slow down. Your brainstorming sessions should always have a set time limit and the leader should
indicate the time to add some competitive pressure to provide more ideas. The first round of
brainstorming should be about 15-20 minutes. You should then brainstorm again on the same topic
after a break. When people are required to brainstorm more ideas, they become more creative.

Steps
1) Set up a comfortable atmosphere for the brainstorming.
2)

lfthe team does not know each other use a fun 5-minute "warm-up" and brainstorming around
something silly, for example all the uses of brick or of a pink balloon. Remember laughter is
helpful for the creative process.

3) Generate ideas out loud in a group for 15-20 minutes, recording all ideas
4)

Eliminate the duplicates and then move to narrow the number of ideas through multi-voting
link to decision making tools

If you have time:


5) After step 4, take a break
6)

Generate ideas for 5-10 more minutes

7)

Collect all the ideas and go back to step 4.

Strengths
Free brainstorming allows the team members, to build on each others' ideas and to generate a large
number of creative ideas in a relatively short space of time.

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

268

9 -5

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Challenges

The chaos of free brainstorming can make some members of the team uncomfortable. They may be
quieter, or think in a less lateral fashion, or may be less practiced than other members ofthe group. If
this is the case then you can end up in a situation where only a few members of the team are generating
the ideas, while others do not participate. It is important to change the style at this point. Everyone has
good ideas and they need to be able to express them.
If you are not brainstorming around a relatively well defined problem, free brainstorming can
someti mes be so unfocused it is useless.
9.1.2.

Structured Brainstorming

When to use:

Structured brainstorming can be used for requirements or concept generation. Structured


brainstorming is often used when the team is new and people don't know each other, when there is the
potential for conflict and when it is difficult to get ideas from all the team members. It is a technique
that reduces production blocking and free riding. It is often also used as part of the nominal group
technique (NGT) which combines idea generation with idea selection or decision making.
How to use

In structure brainstorming, you follow all the same concepts as for free brainstorming but you make a
sma ll modification.
Steps

1) Set up a comfortable atmosphere for the brainstorming.


2)

If the team does not know each other use a fun 5-minute "warm-up" and brainstorming around
something silly, for example all the uses of brick or of a pink balloon. Remember laughter is
helpful for the creative process.

3)

Provide 15-20 minutes for everyone to generate ideas on their own by recording their ideas on a
piece of paper or post-it notes.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

269

9 -6

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

4) The leader then goes around to each member of the group and asks for the persons first two
ideas. This is repeated until all the ideas that people have recorded are up on one list.
Duplicates will be automatically eliminated.
5)

Move to narrow the number of ideas through the techniques described under idea selection

If you have time:


6) After step 4, take a break
7) Generate ideas for 5-10 more minutes
8)

Collect all the ideas and go to step 5 again.

Strengths

Structured brainstorming eliminates the chaos of free brainstorming and it is therefore generally easier
for everyone to take part, particularly ifthe team is relatively new and the team members do not know
each other very well. It is also effective when the topic may cause conflict.

Challenges

Structured brainstorming makes it more difficult to use build on other people's ideas. This is why it is
recommended that you do several rounds of structured brainstorming in a session; t his gives people an
opportunity to build on each other's ideas.

9.2.

Nominal Group Technique

When to use:

The nominal group technique (NGT) combines idea generation with decision making and is used, like
brainstorming, to generate ideas to solve a well defined problem or question and by a team that wants
to make their decision quickly but does not want to simply vote.

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

270

9 -7

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

How to use

In NGT you first generate the ideas using the structured brainstorming steps and then move to decision
making.
Steps

1) Set up a comfortable atmosphere for the brainstorming.


2)

If the team does not know each other use a f un 5-minute " warm-up" and brainstorming around
something silly, for example all t he uses of brick or of a pink balloon. Remember laughter is
helpful for the creative process.

3)

Provide 15-20 minutes for everyone to generate ideas on their own by recording their ideas on a
piece of paper or post-its.

4) The leader then goes around to each member of the group and asks for the persons first two
ideas. This is repeated until all the ideas that people have recorded are up on one list.
Duplicates will be automatically eliminated.
5)

After all the ideas are up, the ideas are then discussed amongst the team. Explanations ofthe
ideas are provided and more detail is added.

6)

Now the ideas are ranked. This is the decision making step. If there are a small number of
choices, say 6, then each person would rank the ideas f rom 1-6 and the highest score is the
team's first choice. If there are less than a larger number of ideas then you would use the " 1/2
plus 1" strategy to rank. If for exam pie you had 22 ideas, then each person would rank the top
12 ideas and the idea with the highest combine score would be chosen. If the there is a large
number of ideas, multivoting would be used f irst.

Strengths

This method has the strengths of structured brainstorming for idea generation: it works for people who
are quieter; does not allow one or two members to dominate; works for new teams. It can also save
t ime. The decision making process is efficient.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

271

9-8

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Challenges

The decision making part ofthis method does, not allow for a full discussion of the ideas and if
multivoting is used, can result in the elimination of new and creative ideas. We tend not to use this
method in engineering because it can lead to rapid decisions that have not be fully expanded and is why
we also discourage multivoting for more than simply reducing a large number of ideas.

9.3.

SCAMPER

SCAMPER is an acronym for a set of suggestions proposed by Robert Eberle to trigger novel design ideas

[7).
When to use:

SCAMPER (Substitute, Combine, Adapt, (Modify, Magnify, minify), Put to other uses, Eliminate,
Rearrange or Reverse) is also used to generate a large number of ideas around a well-defined problem
and is really an aid to brainstorming. It is most often used for developing design solution ideas. It tends
to appeal to groups that like more structure by providing a list of trigger words. It is one of the
techniques referred to as force-fitting. These t echniques force the mind to make creative jumps and
they are frequently used when teams have become stuck because the SCAMPER terms act as "triggers".
How to use:

adapted from R. Eberle, [7)


Substitute: What might you replace or exchange for something else. What if you used a different
person, place, material, ingredient, process or approach?
Combine: What could you put together to solve your design or problem? Can you combine material,
products, or purposes?
Adapt: How might you change a part of the design or problem to solve it? What might you do
differently. What can you copy? What other idea is it like?

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

272

9 -9

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Modify, Magnify, Minify: Can you add or subtract something to solve your design question, can you
make something larger, smaller or increase or reduce something?
Put to other uses: How might you use something in a different way to solve the design or improve it?
Change the context of the problem.
Eliminate: What might you remove to improve or solve your design problem? Can you remove a
function or a unit without affecting the result or would it improve it?
Rearrange or Reverse: Can you interchange components within the design? Could you reverse it, turn it
upside down or look at backwards.

Steps

1. Set up a comfortable atmosphere.


2.

Read the SCAMPER question out loud in your team (you can go in any order)

3.

Write down the ideas that are generated by the team {this can be done as a group or
individually)

4.

Continue to apply the questions until no ideas flow. Note that some questions may not be
applicable to your problem or design and therefore no ideas will flow. Just move on.

Strengths
SCAMPER questions act as triggers for brainstorming and can expand the ideas. The use of the SCAMPER
list also brings structure to the idea generation.

Challenges
Some design problems may need an expanded list of potential solutions to generate ideas using this
method because you need to start with potential solutions that fit the SCAMPER structure. For some
projects you may need to create your own trigger words, again because the SCAMPER terms may not be
applicable to a particular project. Using the SCAMPER structure can also sometimes limit the creative
energy that comes from the free flow of ideas.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

273

9 - 10

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

9.4.

Black Box method

The Black Box Method is a method for exploring the function space of a design problem. It can also be
used to generate objectives and constraints, and trigger design solution ideas. This method can be used
as a first step in the decomposition process (see section below for more information on decomposition).
When to use

In this method you describe all of the mass, energy and information that is going into the proposed
design without actually describing the design itself. Then you describe all of the mass, energy and
information that you expect to result from the operation of the technology you are designing. The
design solution is treated as a "black box". Th is allows you create ideas for what the design will do, or
should be, without specifying a solution (i.e. creating solution independent requirement statements).
How to use

In this method you create statements that connect the input to the output. In the example below for a
bicycle security system, the design takes an unsecured bicycle as an input and produces a secured
bicycle as an output, or takes a secured bicycle as an input and produces an unsecured bicycle as an
output. The primary function of the design is to change the state of the bicycle. As a secondary function
the design takes information as an input and utilizes this information in its operation. We also expect
the design to produce information.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

274

9 - 11

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Inputs
Mass

Outputs
Mass

bicycle secured
bicycle unsecured

bicycle secured
bicycle unsecured

Energy available

.....

m echanical

.,.

Energy output
Design

resulting from input

electrical (maybe)

Information
Infor mation

indication that bike is secured

when to lock

indication that bike is unsecured

when to unlock
who can unlock
where to lock
Figure 1: Black Box method
This type of diagram decomposes the f unctions of the design; it helps you discover what expectations
you have for the functionality. In this example, we discover that we expect the bike lock will provide the
user w ith a clear indication of when the bike is secured and when it is unsecured. The means for doing
this are not specified; the lock could indicate this infor mation through visual, auditory, tactile, or other
sensory input (Smell? Taste?). The lock could even send a text message to your phone telling you it is
locked. Developing ideas for this f unctionality will be part of the solution generation process. For the
requirements we would simply state:
The design w ill indicate when the bicycle is secured and when it is unsecured
The design will produce a secured the bicycle
The design will produce a released the bicycle

Additional pieces of information that are gleaned from this diagram will help us develop other
requirements notably objectives and constraints, e.g.
Objective: The design should allow the user to secure the bicycle in a wide range of locations
Constraint: The design must only use available energy as input if it uses energy at all.

If you use the black box method for solution generation, then after constructing the diagram you would
use brainstorming to develop a long list of means for each of the f unctions, and sub-functions revealed
by the diagram.

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

275

9 - 12

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

9.5.

Decomposition

Unfortunately, complex problems can overload our ability to generate comprehensive solutions. In our
wedding photographer example, you are simultaneously thinking about many different parts of the
problem, and trying to come up with an integrated solution all at once. Then we suggested that you
could combine various features of the differing solutions that you came up with.
You can do this process more efficiently by breaking the challenge into smaller parts before you start
looking for a solution. After the problem is decomposed you can then generate solution ideas for each
of the structural or functional elements. This produces a much wider range of ideas than you could
produce by considering the whole system all at once. Also, by disassociating each element from the
overall system you remove mental blocks or filters that might impede your thinking. You are better able
to divorce a single element from any preconceived notion you have about what the whole system
should be like, and consider a wider range of ideas.

Structural decomposition divides the problem up into the various structural elements, which are
discrete units in space. In our example, we would have the camera, the elevation device, and the
camera/photographer interface.

human interfacehandle

electrical supply

power
conversion
device (motor)
Vacuum Cleaner
filtering device

dust and dirt


storage

friction reducing
means (wheels)

Fig. 2: Structural Decomposition of a vacuum cleaner.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

276

9 - 13

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Functional decomposition divides the problem up into its functional units, and this approach is genera lly
more useful than trying to solve the problem otherwise. We need to control the camera. We need to
aim the camera, provide a vertical force on the camera, stabilize the camera, and so on. A vacuum
cleaner needs to suck air and dirt from the ground, separate the air and dirt, store the dirt, exhaust t he
air, and so on. By separating the various sub-functions, we can focus our attention on small subsets of
the problem, and examine these subsets at their most basic level. Let's work on the vacuum cleaner,
and focus on the key problem of separating dirt from air:

Figure 3: Two versions of the functional decomposition for the function: "Separate d irt from air"
In Fig 3 a) We have identified a few different ways we could separate dirt from air. Until about 1990, the
household vacuum industry was entirely focussed on the use of a filter medium. Vacuums all used bags
or porous filter plates. (A third method would be to pass the air through a loose medium such as sand.
This is used for swimming pool f ilters, but the re are obvious problems in applying this to household
vacuums.)
However, there are many other suggestions here. We could put the dirty air in a large tower, and wait
for the dirt to settle out while removing clean ai r from t he top. Not very practical for a portable
vacuum cleaner t hat must be small and light, b ut this principle is used in large settling ponds created to
t reat liquid waste. We could speed up the settling process with a centrifuge. Or we could speed it up
using a cyclone, where air is pumped at high velocity around a cylinder or cone, and dirt is fo rced to the

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

277

9 - 14

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

periphery and drops to the bottom. We could charge the particles with ions, and then get them to stick
to charged plates. We could blast the air against a piece of adhesive tape. And we could combine these
methods.
An even more fundamental way of doing t he functional decomposition in t his case is to think ofthe
different types of forces that need to be applied to a particle of dirt to get it to move in a different
direction to the surrounding air, which is the heart of the problem. In Fig x.x. b we realize that we
missed the possibility of a magnetic force on our f irst pass through. Unfortunately, this is only going to
be helpful if we are vacuuming up iron filings in a steel mill, but remember, we just generate ideas at
this point, we don't f ilter them. (No pun intended !)
As we mentioned earlier, James Dyson became a billionaire based on this simple functional

decomposition, realizing that there were other possibilities for of separating dirt from air in a household
vacuum besides f iltration.

9.5.1.

Function-Means trees

One variation on f unctional decomposition is a function means tree. This can be used to discover, or
generate additional functions, objectives or constraints to add to a requirements list. To build a
function-means tree you decompose the problem into sub-functions then you generate as many ideas
as possible for that satisfy one of the functions, see f igure x.x above (vacuum cleaner example). This
tree has f unctions at one level and means (solution ideas) at the next level. Now examine the means;
are there any commonalities among these solutions? Functions that all ofthe solutions have in common
are probably integral to the design problem.
In this part icular example all of the means require the user to remove the dirt from the machine, so the
functional requirements must allow dirt to be moved to a location chosen by the user (typically the
trash). The means shown also all presuppose the movement of air with the dirt through the machine. In
this case the designer has discarded the idea that the machine could pick up just the dirt without any air.
All of the methods require the machine to move air into and out of the device. This suggests functions
for the design and also objectives, e.g. the design should effectively remove dirt f rom the air and use a
minimum amount of energy. The solution ideas might also motivate a specif ication of the minimum size
dust particle, and maximum mass particle, that could be effectively removed by this device.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

278

9 - 15

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

By iterating between f unctional decomposit ion and requirements generation using this method you can
improve the quality and quantity of both.

9.6.

Moroholoqical Charts

A morphological chart is a simple graphical representation of t he process of putting ideas together to


make some realistic integrat ed solutions for the whole problem. We have discussed two different ways
of creating design solutions: brainstorming (either as a group or individually), and decomposition
(structural and functional). If you are brainstorming fully integrated solutions, we suggested that you
might be able to combine elements ofthose solutions to make better combinations. Decomposition is
just a more structured and effective way of thinking about t he design. Regardless of which method you
used, you need to build integrated solutions f rom the various pieces.
In a morphological chart, or morph chart as it is commonly known, row headers represent the subfunctions, and columns contain means of accomplishing the sub-functions. Ideas are added to the rows

in no particular order. An integrated design is represented by a "path" through all sub-functions from
top to bottom.
When to use:

Morphological matrices, as they are sometimes called, or morph charts are used to ifind new
combinations of functions and means. They can, therefore, be used to help populate the design space.
They are used after the functions and specifications have been determined and you are now looking at
generating alternative designs.
How to use:

In using a morph chart for generating alternative designs or solutions, you list the sub-functions or
features in the left column of a chart and then the possible ways in which the functions or features can
be implemented across the rows. See example below. You then "mix it all up" to get multiple designs or
solutions. The easiest way to do this is to number the ideas across a row and then random ly put them
together. You can use dice or a random number generator to force you to think about unusual
combinations.

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

279

9 - 16

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Steps

1.

List your sub-functions or features down the left hand column

2.

List all the means or methods of achieving each sub-functions across each row.

3.

Now connect the means or methods in different patterns randomly.

4.

Continue until you have explored a wide variety of combinations.

Strengths
Morphologica l charts expand the design space and can lead to creative solutions to well defined
problems.

Challenges
These charts can get very large and unwieldy very quickly.

Means

Means

Elevate Camera

Means

Means

Helium balloon

Toss

Stab ilize Camera

Control Focus

Control Shutter

Trained spider

Small aperature -

Trained spider
monkey

Example of a morphological chart

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

280

9 - 17

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

9.7.

ANALOGY

Analog,y is a powerful inventive tool in which solutions to similar problems in other fields are used. It
has been discussed by De Bono and many others. In the section in chapter 2 on reviewing the state of
the art, we described a technical analogy: a technical solution to a different, but related problem.
To use a technical analogy, you must ask the question: "What other technical problems are similar to the
current problem, and how were they solved?"
In Chapter 2, we discussed the adaptation of jet engine technology to high-speed steam nozzles used for
cleaning industrial boilers. Dyson (the inventor of the cyclone vacuum cleaner) also developed a new
commercial hand dryer known as the Dyson Airblade . We don't know how the solution was
develop ed, but it might have been by technical analogy. Conventional washroom hand dryers use hot
air to evaporate the water from hands, a very energy intensive method. To use analogy, we ask "What
other things are dried industrially, and how is it done?" In a car wash, there is no way to economically
evaporate all the water used. Instead, the water is blown off with an air knife. The Dyson Airblade uses

this idea to dry hands.


Another type of analogy that has become an important field of academic and industrial research is
analogy to the living world. The process of adapting solutions of from the biological world to
engineering design problems is called biomimetics. It is based on the knowledge that evolution has, in
many cases, produced highly optimized solutions for problems similar to those that must also be solved
by engineers for manmade objects and systems.
Scientists routinely study the structure of materials such as spider silk, rams horns, and oyster shells for
clues a bout how to make strong and tough materials. They study the many chemica I processes used by
life to process food. They study the decision- making processes underlying the behaviour of a flock of
birds or school of fish to create simple swarmi ng robots for large-scale tasks such as cleaning up oil
spills. Many f ields of technology have a biological analogy.
To make use of the biological analogy, you must simply ask: "How does nature solve this problem."
As an example, assume that your task is to come up with an adhesive that will stick with high adhesive
force, but can be removed and reused many t imes. There are many biological solutions to the adhesion
problem, and some of these have been adapted for use by humans. Velcro is an early example, and

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

281

9 - 18

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

was developed by a Swiss engineer, George de Mestral, based on his observation of b urrs (a type of
seed pod) that stuck to the f ur of his dog on a country walk. More recently, scientists have been
studying the remarkable ability of geckos to stick to practically anything, while also being able to run
across surfaces at high speed. This is accomplished with a sophisticated structure of tiny hairs with
sma ll pads on the ends, creating a huge contact surface for van der Waals forces to work on. Scientists
and engineers are searching for ways to recreate this micro-structured surface to make super adhesives.
A football wide-receiver with "gecko gloves" would have a serious advantage.

9.8.

TRIZ

TRIZ is an acronym for the Russian phrase "Theory of Inventive Design". developed by Russian inventor
and author, Genrich Altshuller [8]. Altshuller spent a great deal oftime reviewing patents for the Navy,
and in 1946 began to develop a system of invention based on the recurring elements he found. He
came to the conclusion that the need for an inventive design arose when there were technical

contradictions inherent in a problem. For example, if you need to create a perforated rubber hose to
water a garden, you need a hose that is flexible for use, but is not f lexible so that you can drill holes in it
[8]. A typical engineering compromise would be to make a hose with intermediate flexibility. In
contrast, an inventive solution for this problem is to freeze the hose before drilling t he holes.
"Changing the state of the physical property" is one of the 40 inventive principles that Altshuller
identified as appearing over and over in the solution of inventive problems. It is this repetition that
allows technical analogies, described earlier, to be extremely useful. Other principles include things
like: Separate in time or space, or nesting one thing inside another. For a list of all40 key inventive

principles with examples, refer to http://www .triz-journal.com/archives/1997/07/b/index.html


TRIZ is focussed primarily on mechanical design, although he underlying idea of an invention involving
the resolution of a technical contradiction is completely general.

McCahan, Anderson, Kortschot, Weiss, ond Woodhouse, 2011

282

9 - 19

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

References
[1] Osborn, A. F., "Applied imagination: Principles and procedures of creative problem solving (Third
Revised Edition". New York, NY: Charles Scribner's Sons, 1963
[2] Stroebe, W, Nijstad, B.A., Rietzschel, E.F., "Beyond Productivity Loss in Brainstorming Groups: The
Evoluti on of a Question", in Advances in Experimental Social Psychology, V43, San Diego, Elsevier, pp.
157 - 203, 2010.
[3]1bid; Osborn, page 139.
[4]1bid ; Osborn, page 142.
[5] Gallupe, R.B.; Dennis, A.R.; Cooper, W.H.; Valacich, J.S.; Bastianutti, L.M.; and Nunamaker, Jr., J.F.
"Electronic brainstorming and group size". Academy of Management Journal, 35, 2 (June 1992), 350369.
[6] Connolly, T.; Jessup, L.M.; and Va lacich, J.S. "Effects of anonymity and evaluative tone on idea
generation in computer-mediated groups". Management Science, 36, 6 (June 1990) 689-703.

[7] R. Eberle, "SCAMPER: Games for Imagination Development", D.O.K. Press, Buffalo, NY 1990
[8] Altshuller, Genrich, "And suddenly the inventor appeared", Worcester, MA, Tehnical lnnovation

Centre, 1996.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

283

9 - 20

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Chapter 10: Decision Making Tools


Table of Contents for this chapter

10.1.
10.2.

Introduction and General Comments


Team and Client Methods
10.2.1. Consensus
10.2.2. Voting
10.2.3. Multi-voting
10.2.4. Technical guru decides
10.2.5. Client decides
10.2.6. Knock out the worst idea
10.3. Algorithmic Methods
10.4. Simple Models
10.4.1. Pairwise Comparison
10.4.2. Graphical decision chart
10.4.3. Pugh Method
10.5. Weighted Models
10.5.1. Weighted Decision Matrix
10.6.
Risk-Based Models

10.1. Introduction and General Comments


In the following we will look at a number of decision-making tools. These tools can be used for a great
number of purposes, f rom determining a " best" solution out of a set of proposed sol utions, to making
hiring and firing decisions, to things as trivial as what movie to see. Decision making tools can also be
used as critical thinking methods.
The term "decision making tools" is a misnomer, that is to say the term is misleading. It is not the tool
that makes the decision; it is the engineer or the engineering team. Any tool can give results that are
unreliable. Particularly ifthe tool is used in a situation it was not designed for. Tools will also give poor
results if they are not used with good information; software people have a term for this: GIGO Garbage In, Garbage Out. The engineering team must evaluate the tools used and the inputs used as
closely as they do the design requirements. However, when used well decision making tools can help to
eliminate the bias that comes from your f rame of reference. link to the critical thi nking chapter
In the following sections we will look at a number of different methods. These are not the only decision-

making tools, but are representatives of many strategies that are used. Often the design team will want

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

284

10 - 1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

to adapt tools to their own situation to make them more appropriate and more reliable, and often the
tools w ill be used together. We will look at this in the last section.

10.2. Team and Client Methods


When a decision has to be made, it is important that there is general agreement from your team at least
as to the process and that there be team support for the final decision.

10.2.1. Consensus
Consensus means that all team members agree to a choice. This only works if there is an obviously
superior choice. However, the team can often have consensus on the decision making method, and
agree to abide by and to support the resu lts of that method.
Consensus works best when there are only a few alternatives to choose from because it can take a long
t ime to discuss each choice. It can also be overly influenced by one team member who is persuasive, or
domineering. However, consensus can result in more cohesive support for the resu lt ing choice if used
well. link to working in a team chapter for more information

10.2.2. Voting
Voting can be done in many ways.
The voting can be secret or not
The voting can be done once, or it can be done repeatedly, eliminating only clearly unpopular
choices in each repetition until only two choices remain.
A detai led analysis of the alternatives should be part of the voting procedure. link to working in a
team chapter for more information

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

285

10 - 2

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

10.2.3. Multi-voting
Multi-voting is a good method for reducing a very long list down to a more manageable long list and it is
used extensively by professional design teams. If you have had a good idea generation session, for
example, you will have many ideas. If the team is good at this process there may be several hundred
ideas g,enerated in a 30-40 minute session. A simple way to reduce this list so it is more manageable
before you get into more detailed idea selection is to multi-vote.

Multi-voting is often used as a

ranking method. When multi-voting is combined with structured brainstorming to reduce the ideas
through multiple rounds of idea generation and voting the method is referred to the Nominal Group
Technique. link to Creativity Methods for more information While multi-voting can be used to
rank, there are other idea selection methods that are more powerful, so instead we suggest that multivoting be used early in the idea selection process to narrow the design space to a long, but manageable
list of potential solutions for a design problem.
How to use

1.

Make a clear list of the alternatives, and make sure there are no duplicate ideas on the list

2.

Each person then receives a number of votes, usually about 25-30% of the total number of
ideas. So if there are 50 ideas, each person gets 10 to 15 votes.

3.

Provide a coloured pen, marker or stickers to each team member.

4.

Each person puts a check mark, or sticker next to their top choices

5.

Each person can only vote for each idea once. You can't put lots of your votes next to your
favourite idea. And everyone has to use up all of their votes each round.

6.

Remove those ideas with no votes or the lowest number of votes

7.

Repeat the process until you have reduced the number of ideas to a short lis.t of favorites that
will be evaluated in more depth.

8.

Then move to another decision making tool to evaluate the short list more t horoughly.

10.2.4. Technical guru decides


Here a team member or an outside expert makes the decision. This has the risk that the individual has a
bias towards one of the choices, perhaps because of experience with one of the choices. This experience
could be positive or negative. There is a natural tendency for a team to let the technica lly strong team

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

286

10 - 3

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

member decide. However, studies show that while individuals create concepts more effectively than a
group, group evaluation is superior. So use this strategy carefully.

10.2.5. Client decides


Letting the client decide has the advantage that the designer then takes less responsibility for failures to
perform as expected. However, an engineer is usually hired as an expert in the technologies, and is
trusted to guide the design to a good solution. Often the client wi ll not have the expertise to properly
evaluate the choices. Getting the client involved, however, will often reveal previously unreported
objectives, or objectives with more weight than was first indicated. You should also try to keep the
client informed of the design solutions under consideration as the design proceeds.
We suggest that you document several "best" choices well, discuss these (and your recommendation) to
your client, and let the client make the f inal choice from these. The client may not like any of your
choices in this circumstance, indicating that there may be no acceptable solution, or that the project
requirements need further work.

10.2.6. Knock out the worst idea


Sometimes a team will spend a lot of time trying to deal with a large number of potential solutions;
frequently too much t ime. Reducing the list by eliminating solutions that are clearly inferior can help. By
agreeing to eliminate at least one possibility every time through the list, the list wi ll soon become a
more manageable size. Multi-voting is a fast way of doing this.

10.3. Algorithmic Methods


Here we are going to look at some more formal methods of comparing potential solutions. Like any
methods, they have strengths and weaknesses, and it is important that the engineer and the
engineering team know these and be cautious where the results may not have significance.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011


2B7

10 - 4

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

The methods used fall roughly into three categories, as shown in figure 1. Simple models are relatively
easy to construct and thus appropriate in some conditions where a quick decision is to be made, or
where the decisions are not very damaging if made incorrectly. Weighted models require more work,
but the results are more reliable. Risk-based models add the effects of probability to a decision, and thus
are more difficult to use, however the results will give more insight into the decision.. You may decide to
use a simple method to eliminate some clearly inferior choices, then a more complex method to make a
final decision.

Complexity

Simple
Models

Weighted
Models

...

Risk-based
Models

Figure 1. Algorithmic method categories

10.4. Simple Models


10.4.1. Pairwise Comparison

Pairwise comparison is a simple method for ranking a list. Ranking a list can be difficult because you are
trying to compare many items to many others at the same t ime. A pairwise comparison simplifies the
task by breaking one complex decision up into a set of decisions; each decision compares just one item
to one other on the list. In each cell of the table (see below) you only need to compare one item on the
list to one other and decide which is better, has a higher priority or is more important. This can be used
for ranking, or prioritizing any list of items: objectives, design solutions, items you want to buy, things
you need to do, etc. For this method you put your list along both the first row of a table, and repeat the
list down the f irst column (see figure below). Then you compare each item in the first column to the
each item in the top row, one at a time. Each decision results in a 1 or a 0; 1 if the item in the column is
ranked higher and 0 if it is ranked lower than the item in the top row. See the example below.
In this example the team has decided that item #1 (for example objective #1) is more important than
item #2, item #3, and item #5, but less important than item #4. Overa ll item #1 gets a score of 3 by
adding up the score across the row.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

288

10 - 5

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Item #1

Item #2

Item #3

It em #4

It em #5

score

Item #1

----------

Item #2

---------------

Item #3

------------

Item #4

-------------

Item #5

--------------

In this example items #1 and #4 have tied for high score and would be moved to the top of t he list
because t hey appear to be the most important, or top choices. Items #2 and #3 have t he lowest scores
and would be moved to the bottom of the list. You could then use team discussion to decide which item
(#1 or #4) should be put at the top of the list, and whether to drop items #2 and #3 off your list.
Pairwise comparison obviously yields approximate results. The scores do not mean that item #1 is three
t imes as good or more important than item #2. The results should always be discussed . Also, even if an
item receives a score of zero it does not mean that it has no importance. It just means t hat it has a
lower relative priority.
Specific example of pairwise comparison: you are given $100 to spend for your birthday, what do you
buy?
Evening out
wit h friends
Evening out
with friends
Books
Music

Books

Music or
gadget

Clothes or
accessories

Food

score

--------------------- - ------ ------

------------

Clothes or
accessories

--------------

Food

Try filli ng in the table to see what your priorit ies are, or add you own items to the list and then fill it out.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

289

10 - 6

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

10.4.2. Graphical decision chart


A graphical decision chart (also called a graphical decision matrix or method) is used to compare ideas to
two criteria; for example to compare design solution ideas to the top t wo obj ectives on your objectives
list. This method works particularly well if there are two obj ectives, or criteria, that are clearly more
important than the other evaluation criteria for the project.
How to use:
Put the top criteria (objective #1) on the X axis of a graph and put the second most important

1.

criteria (objective #2) on theY axis, see example below.


2. Through discussion score each design idea relative to obj ective #1 and objective #2. This is an
approximate method and is on ly meant to compare the ideas qualitatively, but having a basic
scoring system can help with discussion. For example: 1=poor, 2=satisfactory, 3=good,
4=excellent
In the example below design idea #6 is clearly inferior. It scores poorly on both objectives. Design idea
#9 is very good with respect to objective #1 but is poor with respect to objective #2. Similarly design
idea #1!. meets objective #2 well, but fails to meet objective #1. The design ideas in t he top right
quadrant of the chart (ideas 10, 11, 12, 13, and 14) are clearly superior to the other ideas with respect to
the top two objectives. Your team might decide through this process to eliminate ideas 1 to 9 from
consideration and j ust focus on these top f ive .

>
.;::;

12

10

11

N
(])

. 4

---------------

(])

'B
0

.5

. 14

__ __ __ _8 __ ___ ___

1
1

13

Objective #1

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

290

10 - 7

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

10.4.3. Pugh Method


The Pugh method is a variation on a pairwise comparison that compares alternatives against a standard
solution. It is generally used for comparing potential design solutions against an existing technology, or
a standard set of goals using the objectives for the project.
What it Does
The Pugh method allows the comparison of multiple potential solutions against a selected standard
solution.
How to Use

1. Select a number of the objectives to be considered. All of the significant objectives should be
included if the met hod is being used for selection and not just comparative evaluation.
2.

Select one of the potential solutions, or an existing solution, as a standard. To make the method
work well, select a solution that seems "around the middle" of several of the objectives selected in
the first step. There is no penalty if the selected solution is not "around the middle", the method
may j ust generate less useful information. [The standard selected is often called the "datum".]

3.

Create a table (or matrix) where the rows correspond to the objectives and t he columns correspond
to the potential solutions. Put the standard, selected in the second step, into the second column.

4.

Now you go through the process of evaluating each potential solution against the standard with
respect to each objective. If the potential solution is about as good as the standard on a particular
objective, put a " 0" in the cell. If the potential solution is worse than the standard, put a " -1" in the
cell. If the potential solution is better than the standard, put a " 1" in the cell. Each cell running down
a column should have a -1, 0, or +1. The column for the standard will be f illed with S, denoting
standa rd, or with the value 0.

5.

Sum up the entries in each column and enter the total in the last row. These sums will give a relative
indication of how each proposal compares to the standard, and to some extent to each other. The
sum for the standard will be 0.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

291

10 - 8

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Table for the Pugh Method

Solutions
Standard

Alternate Solution
1

Alternate Solution

Alternate Solution
3

Objectives

s
s
s
s
0

SUM

Example
This example considers can openers, with the objectives of safety, operation time, cost and counter

space as objectives. In this case, solutions that are more safe, require less time to open a can,
and use less counter space than the standard will receive a "1" in every cell in the column. We would
create the Pugh Matrix shown below, using a manual two-handle can opener as the standard.

<!J
--

Electric can
opener
Safety

Operation
t ime

Cost

Counter
Space

SUM

1
(safer)

1
(f aster)

-1
(more expensive)

-1
(uses more space)

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

292

Jackknife with a can


opener blade

Metal shears

-1

-1

-1

-1

-1

-2

-3

10 - 9

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

By this rating, the two-handle manual can opener and the electric can opener are about the same, the
jackknife can opener is third and the shears are last.
Advantages
Quick and simple to use. This allows the quick rejection of poor alternatives, like the shears in
the example.
Disadvantages
Selections are often not differentiated by the sums
The significance of each of the objectives is considered the same. In the example safety and
counter space are considered equivalent in importance in the sum. In reality this is probably not
true; one ofthese objectives (i.e. safety) would be more important.
Variations
Instead of j ust assigning +1, 0 and -1, assign larger ranging numbers (say +5 to -5) to further
differentiate the options.
Use the method to eliminate only one or two choices, then reevaluate

10.5. Weighted Models


10.5.1. Weighted Decision Matrix
What it Does
The weighted decision matrix method (also called a numerical decision matrix method) includes weights
for each objective. Weights are numerical values. Important objectives are weighted higher (valued
more) and less important objectives are weighted lower (valued less). This affects the decision giving
more priority to solutions that better f it the most important objectives.
This method can be used in any decision making process where you are trying to make a decision,
among a set of alternatives, based on a set of objectives. For example:

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

293

10 - 10

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Deciding which design solution to pick, i.e. which one best f its the requirements, specifically t he
objectives
Deciding which project to fund; if you have many projects to choose from and you want to pick
the one that best f its your organization's objectives
Deciding which homework assignment to work on first; if you have many courses and competing
objectives (want to do well , homework assignments each carry a different weight and value,
etc.)
Deciding which outfit to wear; if you have many possibilities and competing objectives (comfort,
style, etc.)
How to Use

1. Do a pairwise comparison, or use another method, to rank the objectives: 0 1, 02, 03, etc. where 01
is most important.
2. Through discussion choose a weight for each of these objectives. 01 should receive the highest
weight. The weights are assigned as a percentage and the percentages of all the obj ectives should
add up to 100. See Table below for an example (note; weights shown are only to illustrate, your
weight s will be different).

Obj ective

Rank
(from pairwise comparison)

Weight
(determined through discussion)

01

35%

02

30%

03

20%

04

10%

05

5%

Total

100%

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

294

10 - 11

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

3. Compare your alternatives against the objectives. Through discussion decide how well each choice
meets each objective. See suggested scale and table below for illustration.
Suggested Scale: any value between 0% and 100% can be used
0%

Does not meet objective at all

20%

Meets obj ective very weakly

40%

Meets objective somewhat

60%

Mostly meets objective

80%

Meets the objective strongly

100%

Outstanding with respect to the objective

Example of rating design alternatives against objectives. Question asked: How well does this design idea
meet th is particular objective? Numbers do not need to add up to 100%.
Alternative #1

Alternative #2

Alternative #3

01

10%

50%

5%

02

10%

30%

90%

03

50%

70%

20%

04

90%

80%

5%

05

5%

40%

25%

4. Combine these two tables and add up the score in each column. Example of comb ined table:
Alternative #1

Alternative #2

Alternative #3

01

.35 X .10 ::: 3.5%

.35 X .50 ::: 17.5%

.35 X .05 ::: 1.75%

02

.30 X .10 ::: 3.0%

.30 X .30 ::: 9.0%

.30 X .90 ::: 27%

03

.20 X .50 ::: 25%

.20 X .70::: 14%

.20

04

.10 X .90 ::: 9.0%

.10 X .80:::8.0%

.10 X .05 ::: 0.5%

05

.05 X .05 ::: 0.25%

.05 X .40 = 2.0%

.05 X .25 ::: 1.2.5%

totals

40.75%

50.5%

34.5%

Objectives

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

295

.20 ::: 4.0%

10 - 12

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Advantages
This method gives a much stronger indication of what is the "best" solution than the Pugh
method
This method can give you an idea of comparative strengths of each proposal .
Forces ranking of the objectives. It is important that the team agrees to the ranking, otherwise
there will not be consensus on the solution that results from this method .
Disadvantages
Deciding on the relative weightings of the objectives can take time and be problematic: The
weightings may not reflect the wishes or needs of the client.
There is sensitivity to the "strengths" assigned. If, upon further research, you found that one
idea is actually much, much more expensive than you expected, this information would could
substantially impact your weightings.
Only the selected objectives are tested. In our example the jackknife will not only open cans, but
will also cut other things, tighten screws and open pop bottles. These are attributes that may
have value and could change the choice, despite what is indicated in the table. This type of
situation is, in fact, quite common at this stage of the design process.
Variations
Weights can have different scales

Other Notes
One should never use a tool like this without looking carefully at the results. Do the results make sense?
If they don't then perhaps you need to re-examine your objective weightings. But when you starting
changing the weights it can sometimes feel like you are "f ixing'' the weights to get the answer you want.
This is not the right way to use the method. And you have to be careful that dominant team members
are not trying to use the weights to get the solution they prefer. This process requires team discussion,
i.e. group processing. However, when used well the weight decision matrix method can not only
provide a good justification for selecting a design, it can also give you insight into why your choice is
good.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

296

10 - 13

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

10.6. Risk-Based Models


In our examples thus f ar we have considered only fully-formed design ideas. Sometimes the
develop ment of an idea has risk of non-success, or risk of increased cost or t ime. Risk-based models can
be used to account for these risks in the decision process.
We will not explain these methods here. Many of these involve management decisions ref proj
management chapter and al l will involve probability and statistics ref probability chapter. You
may encounter these types of decision making tools later in your engineering career, particularly if you
take courses in project management or operations research.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

297

10 - 14

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Chapter 11: Design and Critical Analysis Techniques


Table of Contents for this chapter

11.1.

Routine Design

11.2.

Custom Off the Shelf (COTS)

11.2.1.

Design by Inventory

11.3.

Reality or Feasibility Check

11.4.

Modeling and Prototyping

11.4.1.

Estimation

11.4.2.

Modelling

11.4.3.

Prototyping

11.5.

Benchmarking

11.6.

Concept of Operation {ConOps)

11.7.

The Use Case

This chapter describes a set of techniques frequently used in engineering design projects. These
methods are used to define design problems and solve them. But perhaps more importantly, these are
techniques for implementing critical thinking and analysis in design to enable better, more effective
solutions. Most of these methods are used in every engineering discipline. However, a few are specific
to particular disciplines, and this will be noted in the description.

11.1. Routine Design


Routine design means that there is a common ly accepted method for solving the problem. Some types
of design problems occur so frequently in a particular industry that engineers have developed a routine
process for developing solutions for this type of problem. It would be unusual for a routine design
problem to be assigned to you for a project in one of your design courses in school because most
instructors want you to work on your innovation skills. You will be trained in routine problem solutions
in your other engineering courses, because in industry it is crucial that you recognize routine design
problems in your field and solve them using standard processes, at least unti l you become expert

enough to critically assess the quality of the standard process. Note that in some cases you are not

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

298

11-1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

allowed, even as an expert, to change the routine design solution process without permission from
authorities because of safety issues and regulations. Routine designs are also frequently easier to
implement than novel designs. So if there is a really good existing solution or solution type or process
then "go with what you know" (engineering saying).
Examples of routine design: structural design for routine buildings (heavily driven by the building code
and standard practices), minor modifications to an existing design, or algorithmic design (e.g. layout of a
printed circuit board; components entered and computer software does the layout for you which may
require minor tweaking after the software completes the job).

11.2. Custom Oft the Shelf (COTS}


"Off-the shelf' means a component or item t hat is already in production and available for sale or
license. "Don't re-invent the wheel" is a common cliche, but it is really true in engineering design. Reinventing the wheel, so to speak, isn't just a huge waste of your t ime, it is hugely expensive. A simple
#10, Yz" screw from a hardware store costs a few cents at most. However, if you decide to design your
own screw with a unique threading and diameter, the manufacturing of that item will cost hundreds or
possibly thousands of dollars (not including the cost of your time and effort). This is no exaggeration.
This is j ust how much it costs to custom manufacture one item as simple as a screw. Imagine what it
costs to manufacture more complex unique systems!
For this reason it is always a good idea to see if there are off-the-shelf parts or units that can be used in
your design. Off-the-shelf items are produced in large quantities. The cost of design and production are
spread over the number of units sold. This drastically reduces the cost of the units. This principle
applies to everything; screws at the hardware store, your textbooks for your courses, music you buy online, steel beams, chemicals, computer chips, subroutines and pieces of software, everything.
In addition to being less expensive, off-the-shelf items often have already been tested and certified. If
an item has undergone rigorous testing and certif ication, then you can trust that it wi ll operate as
specified as long as you are using it in the approved way. This saves you time, and the cost of testing.
Many engineering designs are the result of putting together off-the-shelf technologies in a new and
unique way. There may be a few unique custom parts that are developed for the design, but generally it

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

299

11 - 2

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

is preferable to use as many existing pieces as possible. So before starting in on the development of a
unique solution it is usef ul to reflect on the problem and identify if there are existing technologies that
might be applicable to this proj ect. This means doing a bit of research to f ind out what is already on the
market, and familiarizing yourself with the f unctionality and variety of existing components.
Examples include: subroutine libraries, operating systems and standard protocols; standard materials
such as alloys, chemicals, gases (e.g. standard purity level) or concrete mixtures; standard electrical,
mechan ical, and construction components such as pressu re vessels, 1-beams, wire gauges and computer
chips.
You may discover that there is an existing product or system t hat will solve the entire design problem. If
this is the case, then you want to make sure to thoroughly research this existing solution. It may meet
some o f the design requirements you have specified, but not all of them perfectly. You then need to
decide whether the existing solution is good enough and can just be purchased or licensed for the client,
or whether a new and improved design is needed. If you decide to pursue a new design, it is important
to benchmark the existing system (see benchmarking section below). This means analyzing the existing
system to understand how it works, what functions and features it has, and how well it performs so you
can use this understanding when creating you r new design. You will also need to know which parts of
the existing technology are protected intellectual property (link to IP chapter).

11.2.1. Design by Inventory

There is a variation on COTS, "Design by Inventory", which means you consider strongly designs that use
parts already in use by the manufacturing facility, i.e. parts t hat the manufacturing p lant already has in
stock. This will result in lower inventories, and the potential of larger volume purchases of the parts at a
lower price.

11.3. Reality or Feasibility Check


Throughout the design process you should do feasibility checks. It is easy to say, "Anything is possible",
but really it isn't. Serious feasibility issues need to be dealt with: if the requirements are infeasible this
needs to be brought to the attention of managers or your client; if design solutions are infeasible they
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

300

11 - 3

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

need to be discarded. There are many things which can make a project or a solution idea infeasible, but
we w ill just discuss a few of the more common ones here.
First, the project or a solution idea may be physically impossible. For example, suppose the client is
asking you to design a lift ing system that will use an existing lhp motor to lift weights up to SOOkg, and
they want the weight lifted 10m up in 1 minut e or less. This is physically impossible. A 1 hp motor can
only produce about 44.7 kJ of energy in a minute and the energy needed to lift a SOD kg weight through
10m is 49 kJ (assuming standard gravity on earth). Even without taking into account all of the frictional
loses in the system, it is easy to quickly calculate that this just won't work. It is surprising how often
engineers are asked to design systems, or evaluate design ideas, that are physically impossible. So
before you waste a lot of t ime trying to design something that violates the laws of physics, do a quick
estimate (link to estimation chapter) to see if the idea or requirements are feasible in this respect. This
is called doing a reality check.
Second, the project or solution idea may be et hically or legally unworkable. The requirements may be
such that any solution will violate a law, or be unethical. Or a particular solution idea may be illegal or
unethical. You have a duty to point this out to the client, or eliminate solution ideas that have this issue.
As a person you are required to act within the law, even if you are ordered not to by your manager. And
as an engineer you are bound by a code of ethics. This is true whether you are licensed as a professional
engineer or not. You can find yourself in a lot of trouble if you design a system explicitly for illegal
purposes or which you know will be used primarily for unethical or illegal purposes. Technology
designed for legal, ethical purposes can be misused by others, but you should never knowingly engage in
a project in which the primary purpose is creating a design for illegal or unethical use. Bringing this to
the attention of your manager, and client becomes increasingly difficult the further you get into a
proj ect. Therefore it is worth examining the problem you have specified to see if there are ethical or
lega l issues that should be brought to light. Later in the project you need to check solution ideas to
make sure they comply with the legal and ethical guidelines.
Third, the proj ect may be economically unwor kable, or may be infeasible in the given time line. This is a
very common situation. The client wants a system that costs less than what is possible, and is finished
sooner than is possible. They may specify a budget and t imeline that are simply not viable. Don't just
accept the client's budget and t imeline as fact. Do a quick feasibility analysis. Work up a basic cost
estimate and a preliminary t imeline yourself to see if you basically agree with the client's requirements,

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

301

11 - 4

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

or to see if you think they are way off (link to chapters on economics and project management). If you
find that your estimates are reasonably close to the client's then leave it, and move on to the next task.
But if you find that your estimate is 2, 3 or more t imes what is written up in the requirements then you
should bring this to the attention of the client and your manager. Better to have this discussion now
then to deal with the anger and conflict that w ill result when the project starts going way over time and
budget. Similarly, you need to check your solution ideas for economic and t imeline feasibility. You may
have a really great solution idea, but the client will not be happy with it if the project comes in way over
cost or over time.
There are a number of ways of dealing with projects that seem to be too big for the time and budget
allocated. You can negotiate a change in scope: negotiate to reduce the number or complexity of the
features or functions in the requirements. You can negotiate an increase in the budget or timeline. Or
you can propose a gated project under some circumstances. In a gated project the project is divided up
into more manageable chunks. After each chunk of work you put a gate. The gate is a milestone or
point in time when you, your company, and the client decide whether to move to the next gate (through
the next chunk of work) and whether any changes to the terms (budget, t imeline) are needed. At each
gate the timeline, budget and scope of the project can be re-negotiated to some extent. Gates of some
kind are used in almost all large engineering projects. In industry gates often correspond to design
reviews with the client, deadlines for deliverables, or other types of milestones in the process.
Feasibi lity issues related to physics, ethics and legality, and budget and t imeline are three of the most
common situations you will come across on projects. However, there are others such as political
feasibility, opportunity cost, or assessment of future technologies that may come into the decision of
whether a design problem can be, or should be, solved right now. As you gain more experience as an
engineer you wi ll be able to provide expert advice to your company and your clients about the feasibility
of a project. As an engineering student you shou ld begin getting into the habit of assessing feasibility at
every step in the design process.

11.4. Modeling and Prototvoinq


Prototyping, modelling and testing are essential components of the iterative design process. While we
present the basic design process in a linear fashion - Problem Definition, Solution Generation, Selection

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

302

11-5

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

of Optimum Solution, Implementation - what happens in The Sandbox, our f ictional design company
offices, is closer to reality. In a real design process, engineers are frequently forced to iterate as new
information becomes avai lable. The engineering team goes back to revisit the library, back to talk to
stakeholders, and back to generate new solutions (or pieces of solutions) frequently. Since thinking is
cheap, perfect designers would work out everything on paper or in a computer in advance of any
physical work. Imperfect designers (i.e. all engineers in the real world) don't generally achieve this ideal.
In fact, it is often necessary to test design ideas during the process of conceptual design. And the more
innovative the technology, the more testing t hat is necessary because it is harder to predict how
something really new will perform.
Imagine that you have been tasked to design a water steri lization system for a Mount Kilimanjaro base
camp. The water can be boiled, but this is energy intensive, and the boiling temperature is low at
altitude. You know that water can also be sterilized using ultraviolet (UV} light. There are commercial
units w ith UV lamps, but you are not sure if a viable system can be configured to supply the camp with
clean water using the power of the sun only. You are not ready to compare UV to boiling; you don't
even know if UV can be made to work. What would an experienced design engineer do to take this idea
to a point where it could be realistically evaluated against alternatives? She would most likely follow the
sequence described below.

11.4.1. Estimation
An abil ity to make quick estimations of things such as part sizes, cycle times, and energy consumption is
a critical skill during the iterative conceptua l design phase.link to estimation chapter For your
proposed solar UV system, before you expend time and energy on detailed calculations, you need to
know if it the idea has any merit at all. To do this, you would look up the UV intensity at the base camp
and the dose/sterilization response curve for the bacteria in question. Then you could do a quick
estimation of how much t ime each bit of water must be exposed to the sun and hence the length of
plastic pipe needed to expose the water to sufficient UV for the f low rate required.
This is a typical engineering example, well within the abilities of a f irst year student in chemical
engineering. If we add in some flow dynamics, and the knowledge that UV decays as it passes through
the water, it becomes a job for a fourth year student. Regardless, you can see how important
estimation could be in a technical design of this natu re. link to estimation chapter

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

303

11-6

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

11.4.2. Modelling
Even when the calculations needed to establish feasibility are too complex, it is often possible to use a
numerical model to answer the question. For UV sterilization, you might use rows in a spreadsheet to
represent discrete volumes of water as they journey along the pipe, and columns to represent time and
UV dose. You could then include the idea of mixing between adj acent cells that would be present in
turbulent flow, building in more complexity than could be handled with a pencil and paper.
There are commercial software packages to model things like stress distribution, thermal dynamics, f luid
flows, complex scheduling, and chemical process design. These are used to validate the final design, but
are also used extensively as part of the idea generation process.
You should ask the question: what simulation software could I buy or write to shed light on the design
problem.

11.4.3. Prototyping
A prototype is a specially built one-off example of the proposed design or a subcomponent of it. It is
typically built with just enough care that it realistically represents the proposed design at minimum cost.
For the UV example, a sample section of pipe could be built, dosed with bacteria, and exposed to UV.
Experiments would then be done to determine if the estimates and models corresponded with reality.
Many designs are complex enough that calculations and modelling just aren't sufficient. In Chapter

xxxx, on design for appeal, we discuss the design of the ICON AS Light Sport Aircraft. This has an
integrated V hu ll for amphibious operation, and the ICON engineers tested the hull configuration for
buoyancy and stability using a cheap model built from plywood. It was made by one person in a couple
of weeks, and was just good enough to last the few hours they needed to confirm their basic design
assumptions. This is a very typical prototyping situation: to model the stability ofthe hull using
equations or a numerical model would have been difficult.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

304

11-7

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Fig x: Early stability prototype for ICON AS.


Prototyping is used in all branches of engineering. In software design for example, a prototype is a

simplified version of an algorithm used to see if the code behaves as expected.


The prototyping of physical objects has benefited greatly from the maturing field of rapid prototyping.
There are various methods of "printing" a solid object directly from a digital file desc.ribing its geometry.
If you were designing a new kitchen gadget for removing seeds from watermelons, you could bui ld the
structure in a computer aided design (CAD) program, and then simply print it . One type of printer,
known as a fused deposition printer, is essentia lly a plastic glue gun mounted on a computer controlled
x-y stage. One thin layer is printed in 20, then the support platform moves down (away from the gun)
and the next layer is printed. In a matter of hours, it is possible to "print" a fu lly functional coffee cup, a
set of functioning mechanical parts, or a replica of a bone from MRI data. Prototyping is also used for
validating more complete versions of the design prior to committing funds to the final design and
construction.

The process of engineering design is analogous to the process of writing a computer program . In a
perfect world, the full algorithm would be designed on paper in a very structured way. It would then be

coded, and would work as expected on the first run. Is this how your programs are written?

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

305

11-8

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

In the 1970's, engineering students had to code their programs on punch cards, and often had to line up
at the card feeder just to submit the program to the single mainframe computer. In these cases, the
cost of implementation (a test run) was high, since any error, no matter how tiny, resulted in the need
to create one or more new punch cards, and line up again. Because of this cost, students put more
emphasis on the preliminary design. Now that the cost of testing the program is almost zero, students
tend to write programs with less care, since they know that they can endlessly iterate. Does this save
t ime?
Designi ng physical objects and complex systems is more like programming in the 1970's. It is simply
much cheaper to think things through than it is to build or implement them and find problems later.

11.5. Benchmarking
A survey of existing designs is a crit ical part of investigating the state of the art. The process of
dissecting and understanding an existing design is known as benchmarking or reverse engineering. If
you want to design a new hair dryer, it would obviously be very instructive to buy a f ew of the better
ones already on the market and to disassemble them to discover how they are designed. It might even
be a good idea to buy some bad ones to f ind out what is wrong with them. Reverse engineering is
common practice in large industries such as the automotive and home appliance industries.

11.6. Conceot of Operation (ConOpsJ


Add more here

11.7. The Use Case


Add here

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

306

11 - 9

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Chapter 12: Documenting the Process


Table of Contents for this chapter
12.1.
Introduction
12.2.
Engineering Notebook Instructions
12.2.1. What to Purchase
12.2.2. Requirements
12.2.3. Recommendations
12.2.4. Layout
12.2.5. Content
12.3.
Contacting the Client
12.3.1. Contacting the client by phone
12.3.2. Contacting the Client by Email
12.4.
Design Documents:
12.4.1. Project Requirements and Project Management Plan
12.4.2. Conceptual Design Specification
12.4.3. Final Design Specification
12.5.
Detailed Instructions
12.5.1. Cover Page (template in appendix I)
12.5.2. Disclaimer (For Final Design Specification)
12.5.3. Executive Summary
12.5.4. Project Requirements
12.5.5. Alternatives
12.5.6. Proposed Conceptual Design
12.5.7. Metrics
12.5.8. Client Ethics and Values
12.5.9. Detailed Design
12.5.10.
Updated Project Plan
12.5.11.
Conclusion/Recommendation
12.5.12.
Reference List
12.5.13.
Appendices
12.5.14.
Audience Analysis (template available in the next chapter)
12.6.
Document Style Requirements
12.6.1. Overall
12.6.2. Cover page
12.6.3. Executive Summary
12.6.4. Headings and Sub-headings
12.6.5. Paragraphs
12.6.6. Abbreviations
12.6.7. Tables
12.6.8. Figures
12.6.9. Appendices
12.6.10.
References
12.6.11.
Sample References
12.7.
Email Style Sheet
12.8.
Writing-Up Problem Solutions

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

307

12-1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

12.8.1.
12.8.2.
12.8.3.
12.8.4.
12.8.5.

Problem setup
Optional Strategies: Explore and Plan
Solution
Answer
Evaluation (opt ional)

12.1. Introduction
This section will give practical instruction on documenting each stage of the design process. It will
include instructions on how to keep a good engineering notebook (also called an engineering journal)
and how to effectively write up a problem solut ion so other readers can evaluate the quality of the
answer. It will also include instructions for w riting documents at different stages of the design process.

Design Stage

Documentation I Communication discussed in this appendix

Gathering information,

An engineering notebook to keep records of visits, research, thoughts

recording ideas, reflecting

and other information pertaining to the project. A somewhat formal


method of maintaining this notebook is suggested, much like they are
likely to encounter in the workplace.

Contacting t he client

Telephone Script and an Email - eit her of these may be used to set up an
initial meeting w ith the client.

Establishing the project

Project Requirements/Project Management Plan (PR/PMP)- this

goal and project

document clearly defines the problem to be addressed and the schedule

requirements

for the project.

Creating the f irst

Conceptual Design Specification (CDS) - this document defines multiple

reasonably complete

perspectives and different approaches to solving a design problem. It

design solutions

also defines the criteria by which the t eam choses between the possible
solutions in order to recommend one.

Putting together the final

Final Design Specification (FDS) - after agreement with the client on a

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

308

12 - 2

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

details of the selected

solution to implement, the team uses this document to provide details of

design

the technical requirements for implementation and also revisits the


context set up in the Project Requirements in order to describe
economic, environmental and social consequences of this specific design.

To the student:
This chapter has a set of instructions for different types of engineering documentation. They are
based on a design project that involves an actual client (i.e. service learning), which you will have in
APS112. However, they can also be used for an "in-house" project.
Each section below instructs you on how to document each phase of the design process. Document
instructions are presented in two parts: an initial section which provides details for submission and an
outline of the required components. Component headings then link to the second section of the
instructions, which contains detailed instructions for each of the document components. Students are
also expected to adhere to the general writing guidelines presented in the Document Style Guide
found in a later section in this appendix. The Document Style Guide is based on the formatting that is
typically required for engineering documentation in industry.

12.2. Engineering Notebook Instructions


Your engineering notebook is your personal record of a project design activity. It is a legal document
when used in companies and so should be carefully maintained.
Starting an engineering notebook is the f irst step in beginning a design project. Your engineering
notebook is where you will keep track of your work as you progress through the design process. This
should include plans considered but not pursued, analytical calculations, records of experimental data,
information found, and any other "significant thinking" you did while working on the project. It is the
chronological documentation of your work.
Notebooks of this type are used in many comp anies and the rules will be different in each type of
industry. The rules we have set out here are typical ofthe " best practices" found in industry. When you
work for a company, your notebook belongs to the company and they keep it when you leave your job.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

309

12 - 3

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

However, in engineering school your the notebook belongs to you and you can keep it after the
completion of the course.
Of course, most design work is done using word processors, spreadsheets and CAD/CAM systems on a
computer. These records can be modified at any time, so they cannot be relied upon in the same way
that a hardbound design notebook can. If you want to prove that you did the appropriate calculations
before a bridge cable was selected and installed, a computer file will not be as effective as a notebook
entry unless the record is made using special digital notebook software, where entries are encrypted
and dated in such a way that they cannot subsequently be altered by the user. Such software does exist
and is used in large research labs and industry. However, many engineers still use a pen and a paper
notebook extensively in their work.
If you follow the requirements below your design notebook will be treated as an accurate chronological
record of the design process. If a particularly important safety decision is being made, or a new and
patentable idea is described, you can take the additional precaution of having the page witnessed by
having a co-worker sign and date the page. This should also include a brief statement saying that they
have read and understood the contents of the page. If you are an engineering student, you may want to
ask a professor or professional engineer to serve this function if you believe you have a patentable idea.

12.2.1. What to Purchase


The notebook must be a standard bound lab notebook. We recommend a physics or chemistry lab
book, commonly found in many university bookstores. Pages should not be removable or able to be
torn or cut out without leaving traces. A loose-leaf binder or spiral bound notebook is not acceptable.
The size, color, and/or page format (ruled or quad) does not matter.

12.2.2. Requirements
You must put the date next to each new entry. It should be clear when each item was entered
into your notebook. Never change or alter the date of an entry.
Include reference information for every entry that you do not generate. Any copied material or
links should include reference information along with the date.
Never erase or white-out entries; cross out things if you want to indicate deletion. However, the
original should still be legible.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

310

12-4

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Include descriptive titles before each entry. This helps organization and allows you to retrieve
ideas quicker when writing reports.
Never remove pages from your notebook. This is a legal document; missing pages could imply an
attempt to hide facts or could be a result of stolen information.
The entries in your notebook should be written in indelible ink. Never use pencil.
Do not leave blank pages between entries. Draw a diagonal line across pages or parts of pages
that have not been used. If you want to add information later, add it as a new entry.
Never "adj ust" or add to entries after the date of the entry unless you can clearly indicate the
date of the change and the extent of the change (for example, checking things off a list where
you give the date of the checkma rk). Copy the original and change it in a new entry in most
cases.
Your notebook must be brought t o all class sessions and team meetings. Your notebook should
be w ith you w henever you are working on your design project.

12.2.3.

Recommendations
Number the pages
Create an index at the f ront or back of the notebook.
Include descriptive titles before each entry . This helps organization and allows you to retrieve
ideas quicker when writing reports.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

311

12 - 5

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

IA

.-.r t\Ni.G -t<.e..il

1..

,LI.lla:\iu1

o.C ..,, v.u


1t6-"'

''urfau

cf

EF 6l4 70rrJih

/tn'ik cl Vie(u :.
LYtl'f'l1ti.C
-Yt"
I
1'1 - :J1 '
',"
.S 3 c -/'!".'fi
\

Jp;_op't

Ct.Vfa. (o\ed!

.f/;;J.<b

05l1.\ i:ev1.s

l(;'-\.L<;:.\:::

7'i
So 0
\

.tn 1

rae\---

oOj'..&\'vQ.-S,

-.3;1 (\N1.':>U-V'a. \c-?lo

&
w1

'(\J"'t'(C

f, '\"t \l,j '1\l\CUJ s

-'9

aiv \ "C<.Ct

'v"\ '"1_.,o

f'-

r v.e.t-0
,,, '\"'
\,

") v ':.

(.A

'

-,Q

Example page from a notebook (courtesy of M. Chang, University ofToronto, 2011)

12.2.4.

Layout

Make sure your entries are legible, clear and understandable. Anyone should be able to it read and
understand the entries.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

312

12 .. 6

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

When attaching documents, such as agendas or scraps of paper, into your notebook make sure you
avoid covering any writing. It is best to tape or staple documents scraps of paper over blank pages, and
keep a separate binder of print-outs, date the pages in the binder and refer to them in the notebook,
e.g. "see project binder for agenda of the Febr uary 23 team meeting." Ideal ly, sign and date the writing
across the edge of the paper, so that the signature is partly in the notebook and partly on the page. This
will help confirm that the attachment was inserted on the date specified and was not changed.
picture of edge of a inserted page

12.2.5. Content
In the following list, you will find the kind of content that would be expected in an Engineering
Notebook. You may f ind that you have other items you wish to include as well.
Contact information for each of your team members.
Team rules must be well documented and easily found within the notebook.
Minutes, task delegations, and comments must be noted after each meeting. Notes during
group discussions must also be included with appropriate headings.
All ideas generated during creativity activities such as brainstorming.
Important information you find and all sources researched must be recorded. This includes
bibliographical details such web links, book names, page numbers, and dates of publication.
Diagrams, schematics, sketches, flow charts, product prices, and other details must be entered
or attached.
Notes in preparation for writing documents such as draft outlines.
Tasks you perform and the results of team activities and decisions.
Your own working notes on your project and sketches.
Insights you have and ideas you develop.
Reflections on what you have learned (figured out).
Organization of your thoughts and tracking of your project status.
Documentation of the searches you have run and keywords used.
When you put printouts in a binder they should be annotated to indicate: date printed, how the
information was found (search words used, or link), what on the page is of interest and why (briefly).
Make sure you include all pertinent information for your reference list as well (author, publication date,

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

313

12-7

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

t itle, URL, date accessed) . Printouts can be kept in a binder separate from your notebook, but have a
system (by date, or number pages) of filing them so you can reference the information in your
notebook.
A well documented project will help to keep you on schedule, moving forward, and working effectively.
It will keep you from re-treading over ideas already discarded, decisions already made, and searches
already done. When working with your notebook ask yourself:
Could someone else quickly pick up the project where you left off by reading your notebook if
you were suddenly called away to work on another project?
If you had to put this project aside for a year and then pick it up again, could you quickly get
back up to speed by reading your notebook?
These are common situations in industry. You want to develop work habits now (such as the ability to
keep a clear, complete, well organized notebook), that will make you a more effective engineer later in
your career. Often you will later look at a decision you made and wonder why you made it, or you will
wonder where you spent the months on your project when asked to justify your time. Your notebook
should remind you of your work and where you spent your t ime.
Note that a "good" notebook will not be pretty. It wi ll have all sorts of quick sketches, pictures of
whiteboards, printouts, si de notes and so on. Do NOT keep information elsewhere then transfer it
where the only purpose is to make it neat and tidy. Put it in your notebook, then make it neat and tidy
somewhere else!

12.3. Contacting the Client


Your first contact with your client may be to ask a few preliminary questions to clarify the client
statement or it may be to set up a meeting. You may do this by telephone or by email.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

314

12-8

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

12.3.1. Contacting the client by phone


If you have an actual client, you may have to phone to set up an initial meeting. In order to do this in an
efficient and business-like way, ensuring that you are organized and ask get all the i nformation that you
need, it is a good practice to create a script that ensures your initial contact with the client has a

professional tone, makes a good f irst impression, and achieves its purpose in setting up a meeting
between the team and the client.
Before contacting your client, you must create a script for the telephone call.
The team should select one person to make the phone call, but the team should work on the script
together.
Decide how long your first meeting with the client should be. 1 hour is typical.
If the client offers a tour of their facility, make sure you know if your team is available for an extra
hour (in addition to the interview time) to take advantage of the opportunity while you are there.
Make sure you factor in adequate travel time when proposing a set of times/days for the initial
meeting. You do not want to arrive late for your f irst meeting.
It may take several tries to get hold of your client. Keep trying. If absolutely necessary, you can email
the client to set up the meeting.
Make your phone call when you have a little time (10 minutes or so) so you won't feel rushed.

Content
The telephone script should be polite and have a professional tone. It must have the following elements:

1.

Greeting: in which the caller identifies her/himself and addresses the contact person by name,
using the appropriate title (Mr., Ms., Dr., Professor).

2.

Context: in which the caller clearly identifies the design course and university and makes
reference to the design project submitted by the client organization.

3.

Polite request for a meeting; the caller shou ld give a selection of t imes during which the entire
team is available. Make sure you have the t imes and days written on your script, and some back
up suggestions ifthe client is busy dur ing those t imes.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

315

12 - 9

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

4.

Confirmation of the address of the location where the meeting will be taking place and, if
necessary, request travel directions.

5.

Contact Information: Give the client contact information for you (the caller) so he or she can get
hold of you if there is need to change the plan.
It is useful to give the client your name, again, at this point in the conversation. Pronounce
your name slowly and clearly.
Give your client your university email address, and a phone number where they can leave a
message. Note: If your client calls you, it will generally be during business hours {9:00-5:00)
when you are likely to be in class. Therefore, it is important that they have a way of leaving
you a message (phone or email) during the day.

6.

Signoff: A polite signoff thanking the client, reconfirming the meeting t ime.

Answering Machine:

Create a mini-script, based on the content from your complete script, to use in case you get the client's
answering machine. It should include: the greeting, context, purpose of t he call (request for a meeting),
contact information, and signoff.

12.3.2.

Contacting the Client by Email

You may have an assignment in which you cannot phone your client and arrange an initial meeting in
person . Therefore, you may have to gain your information by email. The following is an example of an
Email Assignment.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

316

12 - 10

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Assignment: Email to Client


Due Date: Submission details go here.

Instructions

Using your client statement and the Audience Analysis form, develop a profile of your client as your
ta rget audience. As is often the case in professional work, you do not have direct access to detailed
information about your client, but you can and must work out a profile of the client based on what
information you have and your best thinking on the subject. Some research will help- if an actual
organization is involved, they may have a web-page. Alternately, employment advertisements for the
kind of position your client has will give you valuable information about their level of education and
experience.
The assignment has two parts:
The Audience Analysis you have completed on the contact person.
The Email to Client.
The Email must conform to the Email Style Sheet and include the following:
From: insert name <email address>
To: insert contact person name here
Date: insert date here
Subject: insert subject line here
Text of your message as it would be for an actual email including a salutation and a closing. The email
will ask appropriate questions to clarify the project and will have three sections:
Introduction
Problem Statement
A series of open and closed questions to help you clarify the qualities the client is
looking for in a possible design.
The Problem Statement describes the problem in your own words, as a problem that can be addressed
through design engineering. It is not a simple word-for-word repetition of the client statement, nor
should it state or imply a solution. (See the sections of the textbook related to defining a problem.)
To develop the Problem Statement, you will have to:

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

317

12-11

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Analyse the Client Statement;


Gather information that might help you to choose important questions.

12.4. Design Documents:


The following three assignments show typical stages in the design process- project requirements and
creating a project plan (PR/PMP); generating multiple possible solutions, criteria for choosing between
them and recommending one (CDS); describing technical requirements involved in implementing a
particular solution and describing its economic, environmental and social impacts (FDS).

12.4.1.

Project Requirements and Project Management Plan

This first document is the design problem setup: the project requirements and project management
plan. See section xxxxx for the detailed instructions for each section. This document defines the scope
of the project. It is used to confirm with your client the project you are agreeing to complete and the
t imeline for completion.

Assignment: Project Requirements/Project Management Plan (PR/PMP)


Due Dates: Submission requirements are detailed here.

This is an initial document that confirms the scope of the project. It covers the following aspects of the
Design Process:
Problem Definition
Project Management Plan

Required content (see etailed Instructions for information on each section)


Cover Page
Executive Summary
1.

Project Requirements
1.1. Problem Statement
1.2. Identif ication of Stakeholders

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

318

12-12

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

1.3. Functions
1.4. Objectives
1.5. Constraints
1.6. Service Environment
1.7. Cl ient Ethics and Values

2. Project Management Plan


3. Conclusion
Reference List
Appendices - including Gantt Chart
Audience Analysis
Attribution Table
Format
No more than 1500 words excluding the Cover Page, Executive Summary, References,

Appendices, and other back matter


For formatting information, see Document Style Requirements.

12.4.2.

Conceptual Design Specification

This second document documents the design process you have followed, including key decisions, and
gives the range of possible solutions you have generated at this point in the project: the conceptual
design specification.

It concludes with a recommendation for next steps. See section xxxxx for the

detailed instructions for each section.

Assignment: Conceptual Design Specification (CDS}


Due Date: Su bmissio n requirements d et ailed here ..
This report is to cover the conceptual design stage, including the following:
Project Requirements
Methods used to generate alternatives
Alternatives considered
Methods used to choose recommended design

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

319

12-13

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Relevant details about recommended design


Recommendations for the testing phase
Conclusion
The CDS, once fully developed, should indicate a number of viable options for solving the problem, a
way of choosing between those options and enough detail about one, recommended solution such that
the client can make an initial assessment of whether the plan, if it is implemented as. shown, w ill lead to
a design that meets their needs.
Required content (see

Detailed Instructions for information on each section)

Cover Page
Executive Summary

1.0 Project Requirements


l.l!. Problem Statement
1.2 Identification of Stakeholders
1.3 Functions
1.4 Objectives
1.5 Constraints
1.6 Service Environment
1.7 Client Ethics and Values

2.0 Alternative Designs, including the one to be presented as Proposed Conceptual Design
2.1!. Idea Generation
2.2 Alternative Design Selection - there may be a number of sections here, from 2.2 to 2.x,
depending on the number of alternative designs

3.0 Proposed Conceptual Design


3.1!. Proposed design
3.2 Plan for detailed Design
3.3 Outstanding Decisions
3.4 Preliminary Implementation Requirements
3.5 Preliminary Life Cycle and Environmental Impact
3.6 Preliminary Human Factors
3.7 Preliminary Social Impact
3.8 Preliminary Economics

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

320

12-14

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

3.9 Preliminary Metrics

4.0 Updated Project Management Plan


5.0 Conclusion/Recommendation
Reference List (following IEEE format)
Appendices- with graphica l material related to the design
Attribution Page
Format: No more than 4000 words excluding the Cover Page, Executive Summary, List of References,
and Appendices. For formatting information, see Document Style Requirements

12.4.3.

Final Design Specification

This third document describes the design process you followed and the final design you have developed:
the final design specification. See section xxxxx for the detailed instructions for each section.
Assignment: Final Design Specification {FDS}

Due Dates:

Submission requirements are detai led here.

The Final Design Specification should clearly describe and explain the detailed design.

Required content (see Detailed Instructions for information on each section)


Cover Page
Disclaimer
Executive Summary

1.0 Project Requirements including:


1.1!. Problem Statement
1.2 Identification of Stakeholders
1.3 Functions
1.4 Objectives
1.5 Constraints
1.6 Service Environment
1.7 Client Ethics and Values

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

321

12-15

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

2.0 Detailed Design


2.1!. Regulations, Standards, and Intellectual Property
2.2 Testing
2.3 Market Issues
2.4 Implementation Requirements
2.5 Life Cycle and Environmenta l Impact
2.6 Huma n Factors
2.7 Social Impact
2.8 Economics

3.0 Updated Project Plan


4.0 Conclusion
Reference List
Appendices
Attribution Table

Format
The main body of the document (excluding the Cover Page, Executive Summary, Reference List,
Appendices, and other back material) shall be no more than 4500 words maximum . For formatting
information, see

12.5. Detailed Instructions


12.5.1.

Cover Page (template in appendix I)

Project title, date, client information, design team names. All fields MUST be f illed in. Ensure you
identify yourselves fully, with both first and last names and that all names are spelled correctly,
including Client organization, Client contact person, TA and Communication Instructor.
12.5.2.

Disclaimer (For Final Design Specification)

All Final Design Reports must have clearly noted on the Cover Page, the following disclaimer:

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

322

12 - 16

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

This Final Design Specification (the "Report") has been prepared by engineering
students at the University of

(the " Students") and does not present a

Professional Engineering design. A Professional Engineer has not reviewed the


Report for technical accuracy or adequacy. The recommendations of the Report,
and any other oral or written communications from the Students, may not be
implemented in any way unless reviewed and approved by a licensed Professional
Engineer where such review and approval is required by professional or legal
standards, it being understood that it is the responsibility ofthe recipient of the
Report to assess whether such a requirement exists.

12.5.3.

Executive Summary

An Executive Summary is a short, information-packed synopsis of your report. The final version
should not exceed one page. The purpose of the Executive Summary is to condense the entire report
such that a reader should f inish it knowing the basic information about the project. Only an
interested reader needs to read more. Many people, in addition to your contact person, may read
the Executive Summary and make important decisions about your project based on the Executive
Summary alone. Therefore, it must be complete, clearly and precisely written, and cover the most
important points made in the most relevant sections of your report. It will also, normally, discuss
schedule, budget and key recommendations. Write the Executive Summary after you have finished
the rest of the report.
Executive Summaries are genera lly written in paragraph form, but may contain bullet and/or
numbered lists. The opening, however, should be in paragraph form. An Executive Summary is an
independent document attached to a report; therefore, it should not have a page number or a
header number.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

323

12-17

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

12.5.4.

Project Requirements

This section gives a distilled report of the background for the project. It establishes the
specifications that must be considered by the proposed design. It must be solution independent
and clearly define the scope of the design, project.
Problem Statement
This is not the statement the client gives you; this is the problem in the design team's own words,
indicating the scope of the problem. This statement identifies the client, clearly states the client's
need, and includes any relevant background information that you have discovered through
research, such as additional understanding of user needs and the service environment. The problem
statement states what is missing or lacking in the world. It describes the gap or hole in the current
reality that is motivating this project, i.e. what the need is. The design solution will fill this hole.
Identification of Stakeholders
This should include all stakeholders, and their respective concerns; that is, it should show how the
person, organization or what the organization represents will be affected positively or negatively by
the design. The effect may be economic, environmental or social. The effect of the design, on the
stakeholder, should be relevant and non-trivial. However, "interest" is not what the stakeholder is
interested in the design doing or being. For example, it is not correct to identify the stakeholder
interest as follows: "the stakeholder is interested in the design being efficient." The Design Team is
not a stakeholder.
Functions
Basic functions define what the design is to perform; what it will do. Secondary functions are those
means that allow the basic function or result f rom it.
Unintended functions/uses refer to things that might be done with the design but are not what it is
actually designed to do. For example, a screwdriver may be used to pry off a bottle cap, but that
was not its intention.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

324

12-18

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Objectives
These are the qualities that a design will possess. They are frequently performance qualities,
physical, f inancial, environmental, socia l and performance objectives for the design as well as
specified goals for these objectives. An objective is identified by "should be" coupled with an
adjective or descriptive phrase. For example: The product should be less than 5 kg. for portability. In
this case, "less than 5 kg." is not a constraint (i.e. requirement), but rather a goal set for the
objective.
Constraints
Constraint statements identify mandatory requirements that the design must meet and commit the
designer to meeting the specification. If the constraint is not met, the system may have to be redesigned at the expense of the designer to meet the tolerance. They:
May be functional, physical, financial, environmental, social or other as would be relevant to the
proj ect
Must be identified by "shall" coupled with a definit ive and testable limit . For example: The
product shall weigh less than 5 kg.
Service Environment
This section described the total environment that the design must operate in. It is divided into
Physical, Virtual and Human Environment sections. Service environment should not be written from
the point of view of the device or design. That is, it is not how the device will be designed to operate
within an environment, but what the environmental concerns are in the first place. In other words,
NOT "The design must be water-proof' but " The design will be used outdoors, in all weather.
Temperatures can be expected to range from -32"C to +40"C. Average rainfall is 709 mm and snow is
138 mm [1]." Remember not to describe the design solutions you are considering, or how they will
function. The service environment description should just describe the characteristics of the
environment where the system w ill be operating.
Physical environment

Such as range of temperature, pressure range, wind velocity, rain and salt spray,
humidity, dirt and dust, corrosive environments, shock loading, vibration, noise level,
and insect or other pest damage.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

325

12 - 19

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

May be based on the extremes of weather experienced in the user's environment, for
example.
May also acknowledge other elements that may be active in the user's environment,
including (but not limited to) appliances or machinery.

Virtual environment
Any virtual systems that may exist within the physical environment. If there is a good
possibility that your design could make use of existing virtual infr astructure, such as
wireless networks, satellite coverage (e.g. GPS), or cell phone signa ls, then you should
explicitly state what your assumptions are. If you are not sure whether virtual systems
will be important to your design, then leave this section out. You can always come back
to add it if you find that the design process is leading you toward a solution that
requires the existence and access to these types of systems.

Living things
Any people or other living organisms that may interact with the design or need to be
considered when developing the design. If the living things are people, consider factors
such as culture, age, language, physical attributes, and education. Other than people,
you should consider pets, livestock, wild animals, insects, microbes, and plants.

12.5.5. Alternatives
The purpose of this part of the report is to give your client valuable information about the different ways
that the design problem could have been solved. It shows the client how your team determined the
criteria by which to choose a solution. Finally, it makes a recommendation.
Idea Generation
Present the methods your team used to generate the alternative designs. Direct your reader to
appendices for any tables or charts. Explain, in detail, how criteria were determined and how they
were used to make a decision between the alternatives.
Alternative Design Selection
There should be five alternatives and all must be feasible. You may not have one clearly superior
design and four clearly inferior designs. Each should represent a distinctively different approach to

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

326

12-20

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

solving the design. Give a short description and explanation of each alternative design and then
review its advantages and disadvantages with respect to, in particular, identified requirements, such
as (though not restricted to) objectives and service environment. Provide sketches or drawings for
all designs and include these in the appendices. Refer your reader to these appendices clearly in the
body of the report, identifying appendices by alphabetical designation and title- e.g. Appendix A:
Design Option 1- Rolodex Toastmaster.

12.5.6.

Proposed Conceptual Design

Identify the alternative design chosen for the conceptual design. Refer to your team's decisionmaking process and appropriate material in the appendices.
Provide detailed information about your recommended solution. There must be enough
information about your proposed design t o give the client a reasonable sense of how this design will
function and how it will meet the objectives of the project. In appendices, you should include
graphic material: simple sketches, drawings, or flowcharts to communicate to the client how you
envision the design at this point. This design, if agreed to by the client, would be the approach you
evolve toward the final detailed design. It is not necessary, or expected, that you w ill have a fully
detailed design at this point.

12.5.7.

Metrics

For the CDS, the preliminary metrics give the client an idea of some measurable tests you would use
to assess a prototype, its functionality, and how well it meets the design objectives. Given the
relatively short development time available, the metrics you propose should test only the most
critical objectives in your project and should be kept as simple and easy to implement as possible.
You are not expected to perform these tests. The results from the metrics would, in an actual
project, be used to shape the development of the design until it satisfied the client. In the FDS, you
will be able to expand upon these tests.

12.5.8. Client Ethics and Values


The client may have specific ethical policies that will impact cost or implementation. Additionally,
the client may have values that will influence a design choice. These values may relate to labour

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

327

12-21

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

practices, aesthetics, cultural perception, or be environmental, social, or political. They must be


written in clear language that is free of bias or implied value judgments.

12.5.9. Detailed Design


This section should clearly describe the proposed solution. Tell the client as much as you know in as
much concrete detail as possible. This description should now include all specifications (e.g.,
physical measurements, memory requirements, power requirements) and provide your client with a
clear sense of what the design will look like, how it will operate, and how it will meet his or her
needs. While every project will be different, the general expectation is that this section will:
Describe the design in detail
Explain how t he design meets the functions, key objectives, and constraints identified in the
Problem Definition.

Note: include any "Design for X" factors (e.g., safety, reliability,

affordability) that you have included in your Problem Definition.


Include at least two diagrams (such as technical drawings or f low charts). Note: drawings,
and/or diagrams may be placed in appendices
May also discuss a model or prototype to be delivered to the client
Regulations, Standards, and Intellectual Property
Identify the safety and environmental regulations and standards that apply to your proj ect
Identify building codes that apply to your project
Identify any patented technologies or processes that are relevant to this project. It is not
likely that you wi ll be infringing on patents, but you should make the client aware of the
licensing fees for patented or copyrighted material (e.g., software packages) if applicable.

Indicate how you would test your proposed design to ensure that it meets the top three design
objectives. Most teams will not be able to perform the actual tests, so identify here three tests you
would conduct and how you would conduct the tests. These tests should be feasible and include
metrics (units of measurements) where appropriate. Note: Section 2.1 has already identified safety
and environmental regulations, so do not repeat that information in this section.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

328

12-22

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Market Issues (if applicable)


This section is not applicable to all designs, but if your client has asked you to consider
manufacturing and/or distribution, then you should be able to answer the following questions:
What is the intended market?
What types of existing systems wi ll this design compete against and who makes them?
How is this design different from existing systems?
What is the estimated retail price, if applicable, and/or return on investment?
What is the time to market? How long will it take to implement this design?
Implementation Requirements
What will be required to implement your design?

Does it require the client to purchase new

equipment or software? Will your client need to change their organizational structure? Will they
need to hire people to install the design? There may be other questions to consider, depending on
your project. In this section, include a detai led breakdown of capital costs.
Environmental Impact
Using a life-cycle ana lysis, identify the potential environmenta l impacts of your proposed design,
and explain how the design tries to lessen the negative impacts and increase the positive ones.
Include a life-cycle diagram in an appendix.
Human Factors
Explain how your proposed design addresses the key human factors at each level of the Human-tech
ladder. Many factors you identify may be at the physical level, but use a systems approach to show
how your design accounts for the other levels as wel l. If one or more of the levels of the Humantech ladder are irrelevant to your project, you may omit these levels.
Social Impact
Examine the key socia l impacts associated with your proposed design, and explai n how your design
tries to lessen negative impacts and increase positive ones. Social impacts are difficult to predict, but
if t hey are considered at the design stage may ensure a much more positive result. Consider the
various stakeholders and how they will be affected by the design. Some effects may be inevitable -

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

329

12 - 23

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

can they be mitigated? For example, residents may have a concern for property values if a waste
treatment plant is planned for their vicinity. Ensuring that the plant incorporates aesthetic
considerations in its architecture and landscape planning may reduce its negative impact on the
neighbourhood.
Economics
This section has a different focus than Implementation Requirements. That section focused on the
costs for materials and installation. This, section looks at the design from a broader perspective.
While you should summarize capital expenditures and installation costs, this is where you identify
operating costs including energy, materials, labour and maintenance, as well as the costs for
disposal and decommissioning. Also identify any external costs (costs to society) arising from the
design's life- cycle.
12.5.10. Updated Project Plan

In this section of the report, concisely describe the project plan, providing greatest detail for the
f inal project milestones and dates that may require a client action. This overview will be presented
in greater detail in your Gantt chart.
The Gantt chart you develop in MS Project should be included in an appendix. The schedule should
be very detailed and complete.
12.5.11. Conclusion/Recommendation

Summarize the key points and bring the document to a close in a way that fully defines what the
reader may expect, at this point, from the project. The reader should therefore have reaffirmed any
action they are being asked to take as well as those you are taking. This is not a word-for-word
repetition of earlier material, but rather a way of bringing the document together and consolidating
its main message(s).
In this section, you must repeat your recommendation and j ustify it. The justification should allow
the client to understand a degree of flexibility regarding the recommendation so that the client's
comfort level is assured. You must give the client some idea of how the process will continue.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

330

12-24

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

12.5.12. Reference List

It is an academic offense to represent the ideas of others as your own. In order to ensure that you
are properly identifying your sources, you must follow two steps (based on IEEE referencing):
1.

In the body of your report, wherever you have used information in any form from anyone
other than yourself, you must identify the source with a citation, that is, a number in square
brackets (1]. These numbers are sequential: each new reference gets the next number. An
already cited reference keeps the number that it had.

2.

You must list all cited sources at the end of your document in a Reference List. This list is not
alphabetical. Works are listed in the order that they appear in the document. For each
source, you must give the authors' names, the date of publication, title of the document and
all publication and/or electronic access information.

A f ull explanation of how to cite a source is in the Document Sty le Requirements.


12.5.13. Appendices

In the appendices, put material that does not fit in the flow of the document either because it is too
extensive or because only a part of it is relevant; however, you have included the whole to give an
interested reader a complete, detailed understanding of your subject. Examples are: manufacturers'
data sheets, relevant research documents, or details of alternate designs.
It is vital to include in the appendices all drawings, plans or sketches relevant to your project. Add
measurements if possible. Also, include any sketches that you have generated of alternative
solutions.
Any information included in the appendices must be mentioned in the body of the report.
Moreover, all material in the appendices, including published material such as manufacturers'
specifications, must have a short introduction written by your team showing the relevance of this
material. Material should be divided appropriately into individual appendices, each of which should
be clearly labeled and titled: eg, Appendix F: Drawings of Alternate Designs.
Sources for all material included in appendices must be documented in the Reference List. You do

this by putting a number in a square bracket (#] next to the discussion of the appendix in the body of

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

331

12 - 25

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

the report. Then you add to the reference list, as you would any reference material, the full
bibliographic information in correct form, as explained in the Document Style Requirements.
An attribution table needs to be filled out for group assignments. The attribution table describes
who in the team was responsible for each section of the submitted document, and the nature of
their contribution. All members of the team must sign off on this table. The table must be attached
to the back of your document.

12.5.14. Audience Analysis (template available in the next chapter)


The primary purpose of the audience analysis is to develop your thinking about your
communication f rom the recipient's viewpoint. You should not be just "guessing/ ' but instead
thinking through each point in the analysis and researching where possible. Include observations
made when you met with the client. List factors that might influence your client's attitude towards
the communication. Consider what your client may need to know that they do not yet know about
the project, communication, or design. In considering how to best take care of your reader or
listener, avoid vague generalizations such as "good writing." Ensure that your recommendations
give you precise values to check for as you are revising and editing your document.

12.6. Document Style Requirements


Style requirements are defined differently in various situations. For engineers publishing their research,
style requirements are defined by the j ournals in which their articles are published. In industry, an
individual company or division will define the requirements for documents and presentations given by
employees. Templates may also be provided.
The following style requirements were developed for introductory design projects. They apply to all
documents referred to in this textbook; style requirements for em ails follow, in a separate section.

12.6.1. Overall
8W' by 11" paper size
Body text: 12 point Times New Roman font, or 11 point Calibri font, single spaced 2.5 em (or 1")
margin all around

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

332

12-26

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Do not number the Cover Page, Executive Summary or Table of Contents if the assignment

includes these.
Page numbers should appear centered on the bottom of each page in the footer.
Staple the report in the upper left hand corner.
Do not use plastic or cardboard folders, unless specifically instructed to do so.

12.6.2. Cover page


A template for the cover page is provided in the Templates chapter (next chapter). All fields must be
filled in.
Identify yourself fully, with f irst name and surname as well as student number or other identifying
code.
The complete name of your instructor or teaching assistant.
Make sure your team and client are accurately identified.
Spelling of all names must be correct.

12.6.3. Executive Summary


The Executive Summary is on a separate page (or, in some instances, pages). It generally appears
immediately after the Title Page and immediately before a Table of Contents or, for short documents
without Tables of Contents, immediately before the Introduction or first section of the document itself.
Do not number either the heading or page for the executive summary.

12.6.4. Headings and Sub-headings


Headings should be numbered, and titled; e.g.,
1. Problem Statement
1.1 Stakeholders
1.2 Functions
1.2.1 Primary Functions
1.2.2 Secondary Functions

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

333

12-27

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Use no more than three levels of subheading; therefore, 1.1.1 is allowable, but not 1.1.1.2.
Use no fewer t han one subheading per section. If you cannot divide the section into more than
two separate subsections, keep it as a si ngle unit .
Sections divided into subsections must have at least one introductory paragraph before the first
subsection.
Do not follow a section header with a subsection header without any introduction.
Headings can use a larger font, be italicized, or bold so they stand out. It is recommended,

however, that they keep to the same font as the body text.
12.6.5. Paragraphs
Do not indent the first lines of paragraphs.
Skip one full space between paragraphs.

12.6.6. Abbreviations
All terms should be written in f ull at their first mention. The full term or name can be followed by an
abbreviation or acronym in brackets: for example, Final Design Specification (FDS). After it has been
spelled out once, the abbreviation or acronym can generally be used in place of the f ull term throughout
the res.t of the document. Some acronyms (e.g. laser, radar) have become part of everyday language
and need not be spelled out.

12.6.7. Tables
All tables must be numbered and descriptively titled, (e.g. Table 1. Annual consumption of oil in
thousand barrels daily f rom 1993 to 2003 by region).
The table t itle must appear just above t he table, left j ustified.
The title font should be the same as the body text
Tables must be separated from the body text by at least one f ull space above and below.

12.6.8. Figures
All figures must be numbered and descriptively captioned (e.g. Figure 1. Global refinery utilization
from 1980 to 2003).
The f igure caption must appear directly under the f igure and should be centered (if less than 1
line) or j ustified, with a margin of 1.5 inches or 3-4 em on the left and right.
The f igure caption font should be the same as the body text

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

334

12 - 28

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Text within figures must be clear and legible. Ideally the text in the figure will be the same size
and font as the body text, but this may be difficult to achieve so try to get it close, but don't spend
a lot of t ime on this.
The f igure and caption together must be separated from the body text by at least one full space
above and below.
All relevant dimensions must be included for a floor plan or drawing of an object.
Hand drawn sketches are acceptable, but should be high quality and clear (not fuzzy due to low
resolution scanning).
Iif the f igure is not original, the source it was taken from must be clearly referenced; in the figure
caption and followed up with a reference in the Reference section; e.g. "Taken f rom [3]", or
"Adapted f rom [5]".

12.6.9. Appendices
Each appendix must be given an alphabetical designation and t itled, e.g. Appendix A: Ground
Plan.
All material in an appendix must be referred to somewhere in the body of the document.
Every appendix must include an introduction describing the content of the appendix. This can be
brief, just a few lines, or several paragraphs.

12.6.10. References
In the past, you may have cut and pasted material f rom a website into an essay, or copied some
information from a book into a report. Now you are entering a profession that takes credit for
intellectual property very seriously! You must now abide by professional practices in using information
from the internet, books or non-published sources.
Referencing also adds to the validity and credibility of your work. There are four main reasons for
carefully referencing ideas in your document:

1.

It gives credit to the person or organization that developed the idea or stated the fact. Even a
collaboratively developed idea (e.g. W ikipedia) deserves credit.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

335

12 - 29

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

2.

It adds credibility to your document. Using high quality sources of information, and including the
reference, builds confidence. Your reader has more reason to believe your statements and
conclusions, which adds t o the credibility of your document.

3.

It supports your claims. It gives t he reader the source for the information so they can go and
look at it for themselves to verify your claims or get more information about the topic. This also
supports the credibility of your writing.

4.

It is an offence not to do so and can get you in serious trouble. As an engineer you can be fired,
and/or lose your license to practice, for falsifying document ation.

It is an academic and professional offence to represent the ideas of others as your own. In every
document you w rite you must acknowledge all sources of information. If your information sources are
not correctly identified - both with citations w ithin the text and in a reference list at the end of the
document - then this is plagiarism. You should refer to your college or university documentation for
the exact regulations guiding your work. Ignoring these regulations can have severe consequences!
To ensure t hat you are properly identifying your sources, you must follow two steps.

1.

In the body of your report, wherever you have used information in any form f rom anyone other
than yourself (or a member of your design team for team written assignments), you must
identify the source wit h an internal cit ation. This is a number in a square bracket [1] right next to
the information taken from an outside source, whether that information is quoted directly or
paraphrased.

2.

You must also have, at the end of the report, a section entitled " References", in which you must
include a list of all sources, referenced correctly according to a standard reference system.

It is also an academic offence to identify as your own the words someone else has used to express an
idea. It is best, when using someone's idea, to paraphrase it or put it in your own words and then to
reference it properly, as indicated above. In fact, engineers rarely quote, word for word. This is a
practice that is f requently used in essays in the arts, but is discouraged in engineering writing. If, for
some extremely important reason you must use someone else's words, then you must put quotation
marks around them and make sure that the reference to them is very precise. For example,
Shakespeare's character Hamlet said t he famous words, "To be or not to be, that is the question." [3,

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

336

12 - 30

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

lll.i] Note: it is unusual to use direct quotes in engineering writing and it is a practice to be avoided. Get
in the habit of reformulating all research into your own words.
This textbook bases its documentation on the IEEE citation system. While IEEE is used by many
engineering disciplines, it is not used by all. Other frequently used systems are Council of Science Editors
[CSE], a lso known as Council of Biology Editors [CBE], and American Psychological Association [APA). A
standar d must be used exactly as it is defined by a standards organization. If you are unsure how to
reference something, research the proper way. Do not "make up" your own system. Incorrect
references are always questionable and may lead to charges of plagiarism.
In your document, sources are referenced consecutively, no matter the alphabetical order of their
authors or titles - that is, [1) is the first, followed by [2]. If a source is used repeatedly, it is always
identified by the number it was given when it first appeared in the report. That means the numbers may
go from [2) to [3) to [1), if [1) was previously cited in the report. However, the next new source would
follow the last number; in the case of this example, it would be [4). It is not necessary to name the
authors or titles of sources. It is perfectly acceptable to write, "In [5], a concern was expressed about the
performance of a-rings at temperatures lower than 10"C." However, you may never begin a sentence
with a number in square brackets.
In the Reference section at the end of your document, you must list all sources cited .. These are cited in
the order they appear in the document, NOT in alphabetical order. Each entry is preceded by the
number with which it is identified in the report. References are listed in a simple numbered list, without
being o rganized by type; that organization and those subheadings (e.g. "Book, single author" ) are only
given below, in the Sample Reference section here, for your instruction. Such subheadings DO NOT
belong in your Reference List.
The style guide below has two requirements which are different than the IEEE citation standard. First,
when using information derived from personal interview or unpublished material, you must give the
interviewee's name, date of interview and email address or phone number. Secondly, when referencing
an online source, you must note the date you accessed it.
The following citations given are for commonly used sources. They are taken from the Proceedings
Template for the 2005 International Conference of the Professional Communication Society of the
Institute of Electrical and Electronic Engineers.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

337

12-31

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

12.6.11. Sample References


Book, single author (this heading, as well as the others in italics, is only to identify the kind of reference
being described. DO NOT USE this kind of heading in your Reference section.):
[1) M. S. MacNealy, Strategies for Empirical Research in Writing. Boston, MA: Allyn & Bacon, 1999.
Article or chapter in a book, multiple authors:
[2) J. W. DuBois, S. Schuetze-Coburn, S. Cumming, and D. Paolino, "Outline of discourse transcription/' in
Talking Data: Transcription and Coding in Discourse Research. J. A. Edwards and M.D. Lampert, Eds.
Hillsdale, NJ: Lawrence Erlbaum Associates, 1993, pp. 45-89.
Journal article, single author:
[3) R. C. Carter, "Search time with a color display: Analysis of distribution functions," Human Factors, vol.
24, no.3,pp.302-304,1982.

Article in conference proceedings, multiple authors:


[4) P. Leone, D. L. Gillihan, and T. L. Rauch, "Web-based prototyping for user sessions: Medium-fidelity
prototyping," in Proc. 44th Int. Technical Communication Conf. Toronto, Canada: Soc. Tech. Commun.
1997, pp. 231-234.
Unpublished thesis:
[5) D. Daly. Direct GMSK Generation Using Sigma-delta Modulation. B.A.Sc. thesis, Div. Engineering

Science, University ofToronto, 2003.


Standard or manual without author:
[6) Recommendation ITU-R BT.601, Encoding Parameters of Digital Television for Studios, lnt'l
Telecommunications Union, 1992.
[7]1EEE Std. 1596-1992, Scalable Coherent Interface {SCI}, IEEE, 1992.
[8) Unix System V Interface Definition, no. 2, vol. 2, AT&T, Murray Hill, N.J., 1986.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

338

12-32

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Patent with information about patentee:


[9) M. Hoff, S. Mazor, and F. Faggin, Memory System for Multi-Chip Digital Computer, US patent
3,821,715, to Intel Corp., Patent and Trademark Office, 1974.

Patent without patentee information:


[10) Digital-to-Analog Converting Unit with Improved Linearity, US patent 5,162,800, Patent and
Trademark Office, Washington, D.C., 1992.

Article in electronic journal, single author:


[11) R. J. Vidmar (1992, Aug.), "On the use of atmospheric plasmas," IEEE Trans. Plasma Sci. [Online].
21(3), pp. 876-880. Accessed February 4, 2005. Available:
http://www.halcyon.com/pub/journals/21ps03-vidmar

Company web page:

[12] Biopure Investor Relations (2005, February), Biopure announces 2005 first quarter financial results.
[Online) Accessed February 4, 2005. Available: http:ljwww.corporateir.net/ireye/ir site.zhtml?ticker=bpur&script=418&1ayout=O&item id=676172

Personal interview or unpublished information:


[13) S. Retep, Personal interview. January 15, 2005. Email: s.retep@utoronto.ca.

12.7. Email Style Sheet


The following requirements pertain to all emails in this course, whether they are assignments, emails
sent to your client or emails sent to the course staff.
Always use a neutral email address (preferably your university email) rather than something
that tries to be funny or provocative.
Always fill in the Subject field and make the subject descriptive, clear, and concise.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

339

12-33

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Beware of putting in any words in the subject line that might cause your email to be
automatically deleted; spam and viruses are a major problem and people use filters to remove
any email that seems suspicious
Use an appropriate opening such as " Hello Prof. X" or "Dear Mr. Y"
Keep messages concise; use a format and style that promote readability.
Ensure your messages are sent to the intended recipient.
Always be polite and NEVER send a message written in anger.
Do not attach foreign character sets that require downloading.
Do not include "cute" pictures, backgrounds, or emoticons in your email.
End the message with an appropriate closing: "Regards", "Sincerely", etc. and then put your
name
At the end of your message provide an alternate way you may be contacted - generally your full
name, and a phone number or street address rather than j ust a different email account.
Format and style:

Use proper grammar, spelling, capitalization and punctuation as would be appropriate in a


formal business letter.
Format as simply as possible - use spaces rather than the tab key.
Set your lines to a standard length; do not send e-mails with lines that run off the screen.
If replying to a message, include enough of the previous message so that the recipient is clearly
reminded of the issues at stake.
Keep paragraphs short.
Use words - no emoticons or unusual abbreviations.
It is preferable to deal with no more than one issue in an email. If there are two or more, clearly
indicate so at be beginning, and number the issues.
This style sheet was created using the following reference:
Susan Stevenson & Steve Whitmore, Strategies for Engineering Communication (New York: John Wiley,
2002) pp. 295-301.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

340

12-34

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

12.8. Writing-Up Problem Solutions


Your problem solutions should teach your reader through your work. Writing up technical problem
solutions occurs in many engineering undergraduate situations including design. The following general
instructions develop the skill of presenting a solution that the reader can follow logically. If you assume
that the reader, whether they are the client, Project Manager, Professor or Teaching Assistant, is
familiar with the problem you might leave out steps. You won't show your unique un derstanding of, and
approach to, the problem and its solution, and you won't receive maximum credit for what you know.
Remember: your instructor, or client, wants to see your understanding of the problem and the solution.
The obj ective of the problem solution is to get the reader to clearly understand the process of your
thinking.
In addition, and equally importantly, a well wr itten problem solution developed for a problem set is an
invaluable study guide when you are preparing for a test.

12.8.1. Problem setup


1.

Restate the problem in your own words. Simply repeating the problem or, worse, cutting and
pasting it f rom an electronic source into your answer, does not give the reader any access to
your particu lar understanding. Moreover, putting the problem in your own words will help you
understand it if you do not already; it will help you identify the particular details about which
you need more information.

2.

State the goal or purpose of the problem; what are you being asked to solve for; what should be
stated in your answer. Be specific and concise.
Example:
find the rate of heat transfer through the window in BTU/hr.
explicitly state the direction of transfer.

3.

Sketch, diagram or otherwise graphically describe the problem. This is

important element

of the write-up. Almost all problem write-ups in engineering should include a sketch, diagram,
schematic, flow chart or some other graphica l representation of the problem (the possible
exception being pure math problems). The graphic should include all important information,
but should not include superfluous details.
McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

341

12 - 35

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

4.

Explicitly state the following:


knowns,
unknowns
assumptions, with brief explanations about why you feel justified in making each
assumption
information that needs to be gathered from other sources, and what sources you used.
You won't find this very often in freshman problem sets, but it becomes more common
in upper years.

12.8.2.

Optional Strategies: Explore and Plan

The following strategies will help you both raise the quality of your work and make it useful in multiple
ways. For example, you can write up a problem set so that it is also a useful study aid. This is highly
recommended because it improves learning, and turns your problem sets into a set of high quality study
materials.
State for yourself (and the instructor) the knowledge and methods that you think w ill be
important for this problem. You might explain, briefly, why you are choosing these
methods especially if there are other methods that you could have used. You might also
note the page number in the textbook where the method can be fou nd to make it easy
to study from later.
Show a brief plan, or list of steps you plan to follow to solve the problem. If your
solution method in a later part of the problem depends on a preliminary result, put this
in your plan.

Example

1. Calculate the Reynolds number for the f low


2a. If the Reynolds number is below 2300, use a laminar f low model to f ind the velocity profile.
2b. If the Reynolds number is above 2300, use a turbulent flow model to find the velocity
profile.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

342

12-36

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

12.8.3. Solution
Make sure you take the reader step-by-step through the solution. Some key strategies:
Solve in equation form first, put numbers in at the end.
Use neat writing so it is easy for your instructor to give you credit
Format your work neatly; space out your work so your work reads easily and doesn't
look cluttered or disorganized. This also leave space for your instructor to put
comments on the page.
Comment your equations; explain (briefly) to your reader what you are doing

Example of commenting: "use 1' law for a steady state, steady flow system", then state
the equation. [add a longer example here]
Bonus step: to improve the learning va lue of your problem sets, start with a general form of an
equation and then simplify it using the information and assumptions stated in the setup section of your
work. Many courses boil down to only a few key equations, by starting with the general form and
cancelling out terms based on the specifics of a given problem, you will learn much more from your
problem solving work.

12.8.4. Answer
Clearly state the answer
Make sure it matches the statement of goal or purpose you have in t he problem setup,
including the correct units, format, etc.
It is usef ul to "mark" the answer to make it easier for the instructor to identify. For
example, you might underline the answer, draw a box around it, mark it with a star in
the margin, use a different color pen to write the answer or draw an arrow to bring
attention to it.
It is usef ul to turn your numerical answer into a statement to show that you know the
context of the answer.

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

343

12 - 37

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Example: instead of "Ans: 50 BTU/hr"


write, "Ans: The heat transfer through the window is 50 BTU/hr into the building."

12.8.5.

Evaluation (optional)

Many instructors aren't looking for this in the problem write-up so you probably won't get
additiona l credit for it unless the instructor has explicitly asked for this step. However, it is very
valuable to include in terms of getting the most learning out of the problem solving work you have
done.

Following the solution, write a brief reflection (bullet points or sentences) on the fol lowing:
Check your solution. Write a sentence or two about the quality of the result
o

Does it pass a "reality check"'? Or does it seem way too high, too low, or maybe have
the wrong sign (e.g. negative when it should be positive)

If the resu It is an equation, does it seem to give reasonable results at the "limits" (when
this variable or that one goes to zero or infinity).

How accurate is the result? Make a brief statement about the "quality" of the solution
based on the data and model sused in the solution.

Reflect on the solution process; what were some key things you figured out? This is like
notes to your future self. When you get back this problem set and you are using it to study,
what do you want to remember about the insights you had, or the tricky things you figured
out whi le doing this problem?
Evaluate solution method; are there other methods you could have used? What are the
advantages or disadvantages of the method you chose?

Keywor ds used in this section


This is a glossary of terms relevant to documenting the design process. They are linked to the Glossary in
the back pages, where you can find the definitions.
Action item

Audience analysis

Agenda

Body text

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

344

12-38

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Client statement

Honorific

Deliverables

Memo

Digital Copy

Minutes

Executive Summary

Plagiarism

Hard copy

Rubric

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

345

12 - 39

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Chapter 13: Templates


The following templates were created to help you work through the steps to developing an effective
piece o f communication, such as a design report, memo, or presentation. Fill-able copies are linked to
the text. Example templates included here are:
Audience Analysis
Report Attribution Table
Cover Page
Status report

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

346

13 - 1

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Audience Analysis Worksheet


Author(s), _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _Date_ _ _ _ _ _ _ __

Communication (Assignment and p u r p o s e ) - - - - - - - - - - - - - - - - - - - - - - - - - - - Audience (person or group communication is going to) - - - - - - - - - - - - - - - - - - - - -- - -

The purpose of an Audience Analysis is to ensure that you take care of your reader or listener. In order to do this success1
understand the reader/listener's frame of reference, interests and needs. The f irst column lists factors you should consid
communication with this particular person or group. In the second column, identify the factor in relation to the audience
are writing to a professor and you think she has a PhD, you would write PhD under Identification. In the third column, ind
this information- for example, for the professor, you might have gotten it from the University website. Put in the referer
Finally, under Draft, put in how you would address the person in the email - e.g. Hello, Professor Lin or Hello, Dr. Lin.

Factor

Identification

Validation

Draft

Education

Address as

Familiarity with the project

Backgroun1
Backgroun1

What does the person or group not yet


know that they need to know?

Technical level - how much technical


knowledge can I assume and how much
should I explain?

Terms to b
Terms toe:

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

347

13 - 2

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Interest - how will the project benefit or


disadvantage this person or group?

What bene
emphasize,
What disac
clearly ider

Bias - what aspects of the project might


this person already have predetermined
judgments about?

How can I<

Background and languages - how does


the audience's background affect your
tone? What is their idea of being polite?
How direct should you be?

What is thE
communic;

Audience conditions - is the reader busy


and having to read quickly? How long is
the presentation? Is it taking up time in
a very busy day?

How do au
totallengtt
or sentenc1

Response to communication- if
positive, how can I move to the next
step? If negative, how can I overcome
problems?

McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

348

13 - 3

PRINTED BY: Kristian Petrounov <kriss.petrounov@gmail.com>. Printing is for personal, private use only. No part of this book may be reproduced or transmitted without
publisher's prior permission. Violators will be prosecuted.

Report Attribution Table

Team Number: _ _ _ _ _ _ _ __

Date: _ _ _ _ __

Assignment N a m e : - - - - - - - - - - - - - - - - - - - - This table allows you to t rack the contributions of each team member to a document. It will help you
manage a team project and make sure that everyone has a role in developing the document. It should
accurately reflect who contributed to each section of the document and what they contributed. If your
instructor requires that you submit this table w ith an assignment you should also keep a copy for the
team. This is an important piece of information that you can use in a team debriefing discussion
following the submission of a deliverable.
Student Names
Section

All
Fill in abbreviations for roles for each of the required content elements. You do not have to f ill in every
cell. The "all" row refers to the complete report and should indicate who was responsible for the final
compilation and final read through of the completed document.
RS - responsible for research of information
RD- wrote the first draft
MR - responsible for major revision
ET- edited for grammar, spelling, and expression
OR - other
"All" row abbreviations:
FP - final read through of complete document for f low and consistency
CM - responsible for compiling the elements into the complete document
OR- other
If you put OR {other) in a cell please put it in as ORl, OR2, etc. Explain briefl