Designing Engineers Textbook (2012)

PRINTED BY: Kristian Petrounov . Printing is 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


Designing Engineers: An Introductory Textbook


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



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.

5


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

6


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

7

Part l lntroduction- 1


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


8



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,


9

Part ! Introduction- 3


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


10



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



think

tools and strategies

l

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.


12



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.


13



Class room (Tec hnical Knowledge)

f

M

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


14

Part ! Introduction - 8


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/

0

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).


15



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


16

Part 1 Introduction- 10


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.


Part 1 Introduction - 11


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


18



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


19



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

.,

"'

0?

..

..

"''!>

>

?:

>

?:

i

"

";; .:; 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.




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.


21



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.


22



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


23

Part !Introduction- 17


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.


24



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


25



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


26



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< .-}

'

-.,

I

{:IF h

-

.:It ,

l::'c

-(.

1_

L.;;

z .....:.

{

1

""

,.

"> (

'-1

·e. I

"

-

!'-

,. t.·

')

• «tf

•

c

..

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


27



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


28



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.


29



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.


30



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


" 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


32

1-2


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.


33

1-3


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


34

1-4


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.


35

1 -5


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.


36

1-6


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.


37

1 -7


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.


38

1 -8


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.


39

1 -9


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


40

1 - 10


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.


41

1 · 11


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


42

1 - 12


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


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.


43

1 - 13


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.


44

1 - 14


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


45

1 - 15


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 "
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).


46

1 - 16


OB}t:Cil\J E !tEE

Qecvull''e-

@

J

0'
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


47

1 - 17


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.


48

1 - 18


I

Easy to set up

How

I

I

I Requi res p eople

I

I

I

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.


49

1 - 19


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.


50

1 - 20


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.


51

1 - 21


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


52

1 - 22


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).


53

1 - 23


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"


54

1 - 24


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


55

1 - 25


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.


56

1 - 26


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 85°F [3]. Average rainfall is 684.6 mm and snow is 115.4 em [4] ."

1

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").

1

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


57

1 - 27


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


58

1 - 28


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.


59

1 - 29


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


60

1 - 30


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.


61

1 - 31


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


62

1 - 32


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."


63

1 - 33


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?


64

1 - 34


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.


65

1 - 35


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:


66

1 - 36


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


67

1 - 37


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


68

1 - 38


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


69

1 - 39


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


70

1 - 40


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


71

1 - 41


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)


72

1 - 42


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


73

1 - 43


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


74

1 - 44


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.


75

1 - 45


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


76

1 - 46


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.


77

1 - 47


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


78

1 - 48


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


79

1 - 49


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

2 •

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.


80

1 - 50


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.


81

1 - 51


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»


82

1 - 52


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


83

1 - 53


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.


84

1 - 54


o

Utilize several creativity methods to develop a list of functions

o

Utilize the objective tree method to develop a list of objectives

o

Research common types of constraints to develop a list of constraints

o

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

o

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

o

Explain the stakeholders and list their interests

o

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


85

1 - 55


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?".


86

1 - 56


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.


87

1 - 57


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


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.


89

2-2


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.


90

2-3


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.


91

2-4


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


92

2-5


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

B

A

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


93

2-6


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.


94

2-7


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.


95

2-8


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.


96

2-9


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

2

).

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


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.


98

2-11


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


99

2-12


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


100

2-13


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


101

2 - 14


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.


102

2-15


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.


103

2 - 16


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


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?

o

Why are drink bottles cylindrical?

o

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."


105

2 - 18


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.


106

2-19


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


107

2 - 20


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:


108

2 . 21


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.


109

2 - 22


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.


110

2. 23


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


111

2 - 24


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.


112

2-25


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?


113

2-26


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.


114

2 - 27


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.


115

2 - 28


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


116

2 - 29


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.


117

2-30


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.


118

3-1


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.


119

3-2


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


120

3-3


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?


121

2. No solut ion found -Terminat e project? -or ret urn to design process?

3 -4


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.


122

3-5


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.


123

3-6


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,


124

3-7


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

1

).

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

2

)

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.


125

3-8


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 .


126

3 -9


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


127

3 - 10


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


128

3-11


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.


New Solution

No


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


129

3-12


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. <> 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»


130

3-13


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


131

3 - 14


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


132

3-15


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


133

3-16


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


134

3-17


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.


135

3-18


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.

3

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.


136

3 - 19


New Solut ion


No


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


137

3 - 20


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


138

3 - 21


3.8.

List of Key Terms in this chapter


139

3-22


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


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.


141

4-2


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.

1

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.

1

In the absence of a nuclear reaction such as nuclear f ission or fusion. McCahan, Anderson, Kortschot, Weiss, and Woodhouse, 2011

142

4 -3


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.

2

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.

2

The current mass of our planet is about 5.98x10

21

Mg


143

4-4


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

2

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


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


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


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


147

4-8


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


148

4 -9


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


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.


150

4 - 11


@--

@--

@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.


151

4 - 12


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


152

4 - 13


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.


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]:


153

4 - 14


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.


154

4 - 15


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


155

4 - 16


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


156

4 - 17


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


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


158

4 - 19


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


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.


160

4 - 21


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


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


162

4-23


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


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.


164

4 - 25


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.


165

4 - 26


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


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.


167

4-28


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


168

4 - 29


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.


169

4 - 30


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.


170

4 - 31


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


171

4 - 32


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.


172

4 - 33


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


173

4 - 34


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


174

4 - 35


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

o

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


175

4 - 36


Life cycle diagram


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/


176

4-37


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


177

5-1


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

0

The Design Process

.-------_ Which has strategies that help develop


17B

5- 2


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


179

of reference is connected to her

5- 3


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,


180

5-4


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


181

5-5


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).


182

5- 6


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!


183

5-7


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.


184

5- 8


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.


185

5- 9


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.


186

5-10


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.


187

5- 11


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.


188

5-12


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.


189

5- 13


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


190

5- 14


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]


191

5-15


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


192

5- 16


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]


193

5-17


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.


194

5- 18


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


195

5-19


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.


196

5-20


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


197

6-1


o

Document research appropriately

Organize a document in a logical manner appropriate to engineering

6.2.

o

Organize a document or presentation overall

o

Organize logically at the section level

o

Organize logically at the paragraph level

o

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:


198

6-2


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.


199

6-3


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


200

6-4


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.


201

6-5


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.


202

6-6


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.


203

6-7


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


204

6-8


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.

1

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.

1

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.


205

6-9


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


206

6 - 10


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.

2

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.


207

6-11


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


208

6 - 12


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

3

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


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.


210

6-14


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


211

6 - 15


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.


212

6-16


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


213

6 ·17


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.


214

6-18


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,


215

6-19


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:


216

6-20


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


217

6-21


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.


218

6-22


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.


219

6-23


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.


220

6-24


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

o

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.


221

6 - 25


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.


222

6 - 26


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.


223

7-1


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.


224

7-2


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.


225

7-3


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.


226

7-4


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.


227

7-5


Typical Team Development Model :tviE

WE

f?®[f[o)[[uuuo ITU@

o

or

..

o

al11

prod

0

@[?lli/ilD

0

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


228

7-6


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


229

7-7


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?


230

7-8


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


231

7-9


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


232

7 - 10


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


233

7-11


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


234

7-12


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


235

7-13


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.


236

7-14


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).


237

7-15


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


238

7-16


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.


239

7-17


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


240

7-18


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.


241

7 - 19


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.


242

7-20


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


243

7 - 21


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 .


244

7-22


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


245

7 - 23


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.


246

7-24


[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.


247

7-25


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.


248

7 - 26


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.


249

7-27


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


250

7 - 28


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.


251

7 - 29


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.


252

7-30


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.


253

7-31


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


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 [email protected] if you need anything else.

Tori Noir


255

8-2


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,


256

8-3


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

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.


257

8-4


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).


258

8-5


Table 1: Objectives

Rank

Objective

Description

Goal

1

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

2

Easy to use

requiring a minimal amount of time to learn

3

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

2

Non-damaging to the camera Portable - able to fit within a space of 1m

3

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


259

8-6


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 21•c 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.3·c to -7.9·c 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.


260

8-7


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.


261

8 -8


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


262

8-9


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


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.


264

9-1


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.


265

9-2


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


266

9 -3


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 an·d 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.


267

9-4


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.


268

9 -5


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.


269

9 -6


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.


270

9 -7


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.


271

9-8


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?


272

9 -9


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.


273

9 - 10


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.


274

9 - 11


Inputs Mass

Outputs Mass



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.


275

9 - 12


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.


276

9 - 13


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


277

9 - 14


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.


278

9 - 15


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.


279

9 - 16


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


280

9 - 17


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


281

9 - 18


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.


282

9 - 19


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.


283

9 - 20


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


284

10 - 1


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»


285

10 - 2


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


286

10 - 3


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


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.


288

10 - 5


Item #1

Item #2

Item #3

It em #4

It em #5

score

Item #1

----------

1

1

0

1

3

Item #2

0

---------·----·--

1

0

0

1

Item #3

0

0

------------

1

0

1

Item #4

1

1

0

-------------

1

3

Item #5

0

1

1

0

-·-------------

2

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.


289

10 - 6


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 .

4

#

> ·.;::;

•

12

•

10

11

•

• 3

N (])

2 •

• 1

. 4

3

---------------

u

(])

'B 0

.5

2

. 14

__ __ __ _8 __ ___ ___

• •

7

1 1

2

•

13

•

9

3

4

Objective #1


290

10 - 7


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.


291

10 - 8


Table for the Pugh Method

Solutions Standard

Alternate Solution 1

Alternate Solution

2

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.

Electric can opener Safety

s

Operation t ime

s

Cost

s

Counter Space

s

SUM

0

1 (safer)

1 (f aster)

-1 (more expensive)

-1 (uses more space)

0


292

Jackknife with a can opener blade

Metal shears

-1

-1

-1

-1

0

-1

0

0

-2

-3

10 - 9


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:


293

10 - 10


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

1

35%

02

2

30%

03

3

20%

04

4

10%

05

5

5%

Total

100%


294

10 - 11


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


295

X

.20 ::: 4.0%

10 - 12


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.


296

10 - 13


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.


297

10 - 14


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


298

11-1


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


299

11 - 2


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


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,


301

11 - 4


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


302

11-5


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»


303

11-6


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.


304

11-7


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?


305

11-8


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


306

11 - 9


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


307

12-1


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


308

12 - 2


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.


309

12 - 3


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.


310

12-4


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.


311

12 - 5


··IA· ·

.-.r t\Ni.G -t<.e..il

1..·£

,LI.lla:\iu1

d

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.
05l1.\ i:ev1.s

L

f

l(;'-\.L<;:.\:::

7'i • So 0 \

.tn 1

rae\---

k

oOj'..&\'vQ.-S,

-.3;1 (\N£1.':>U-V'a. \c-?lo

& w1

'(\J"'t'(C

f, '\"·t \l,j '1\l\CUJ s

-'9

aiv \ "C<.Ct

'v"\ '"1_.,o

l

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.


312

12 .. 6


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,


313

12-7


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.


314

12-8


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.


315

12 - 9


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.


316

12 - 10


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 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:


317

12-11


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


318

12-12


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


319

12-13


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 desig·n 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


320

12-14


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


321

12-15


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:


322

12 - 16


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.


323

12-17


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.


324

12-18


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.


325

12 - 19


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


326

12-20


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


327

12-21


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.


328

12-22


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 -


329

12 - 23


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 lifecycle. 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.


330

12-24


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


331

12 - 25


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


332

12-26


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


333

12-27


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


334

12 - 28


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.


335

12 - 29


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,


336

12 - 30


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.


337

12-31


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.


338

12-32


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: [email protected].

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.


339

12-33


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.


340

12-34


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


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.


342

12-36


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

1

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.


343

12 - 37


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)

o

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).

o

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


344

12-38


Client statement

Honorific

Deliverables

Memo

Digital Copy

Minutes

Executive Summary

Plagiarism

Hard copy

Rubric


345

12 - 39


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


346

13 - 1


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:


347

13 - 2


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?


348

13 - 3


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 briefly below the role referred to: ORl: enter brief description here OR2: enter brief description here Verif ication: By signing below, you verify that you have read the attribution table and agree that it accurately reflects your contribution to this document. Print Name: Signature_ _ _ _ _ _ _ _ _ _ _ _ __ Print Name: _ _ _ _ _ _ _ _ _ _ _ _Signature_ _ _ _ _ _ _ _ _ _ _ _ __ Print Name: Signature_ _ _ _ _ _ _ _ _ _ _ _ __ Print Name: Signature_ _ _ _ _ _ _ _ _ _ _ _ __


349

13 - 4


Cover Page Template

Name of University Department or School Course Number- Course Name Title of Document

Project Title

Client Client Contact Teaching Assistant Prepared by: (Names and Student I D's)

Date


350

13 -5


Weekly Status Report DateofReport ------------------------------------------------------------Report Prepared by ___________________________________________________________ Project# _ _ _ _ Client __________________________________________________ Project Title ________________________________________________________________ Project Manager----------------------------------------------------------Team Leader _______________________________________________________________ Team Members _____________________________________________________________

Activities since the last report, i.e. progress to date: Specific Task

Person Assigned

Date Due

Date Completed

1

2 3 4

5 6 7

8 9

Problems Encountered ------------------------------------------------------

Lessons Learned & Strategies to address Problems _____________________________________

Team Decisions-------------------------------------------------------------


351

13 - 6


Plans for the next work period (1-2 weeks) Task

Person Assigned

Date Due

Comment

1 2 3 4 5

6 7

8 9

Write Next Status Report

ADDITIONAL COMMENTS (items to discuss du ring tutorial: documents, client meetings, up-coming due dates and activities, etc.):

ATIACH GANTI CHART (one week past, two weeks forward only) The report may be written by one team member (as delegated by the team), but it is that reporter's responsibility to ensure that the report reflect s correctly all work performed by each team member.


352

13 - 7


Chapter 14: Glossary This chapter provides definitions for the terms highlighted throughout the text. This list is still incomplete. A more complete version will likely be available for APS112 in January. You are not expected to know every term on this list.


353

14 - 1

Ei

:::rCl ,=>

Terminology for design phases A variety of terms are used for t he different phases and documents produced in the design process. These terms are often industry or company specific. Here are a few genera l examples:

:t> =>

Cl.

"'

iil 0 ,=>

Purpose

US Defense

Define the project fSCOpe

Report

ij'

Institutiona l Buildings

Pharmaceuticals

User specification

Discovery and fSCreening

eric erminology

a f")

...:::r-

,0

;;:;·

Requirements

Requirements

Project Requirements

-"'Cl =>

Cl.

0

§: 0

w

C11

.j>.

Alternatives, on direction

& echnology

Preliminary {30%) Pre-clinical

Proof of concept

Design

<::

"'

,rb

"'........0

Design fu lly detailed, ready for production pr produced

Post release support

,_. .Po

"'

&

Iteration and testing

Production &

support

!engineering, 90%

& om mission

&

& clinica l rials

esting, Debugging

validation, Release Regulatory approva l

Post submission

echnical support

Preliminary

design

Preliminary Design

Final Design

support

are many other types of documents produced during the design process and these will go by a variety of names depending on the mdustry. Examples include: crit ical design review reports, human engineering design documents, electromagnetic compatibility seeping reports, etc.


f")


14.1. List of Key Terms Acceptable Risk Action item-- A task assigned to a team member at a meeting. In the minutes of the meeting, action items identify who is responsible for a task, what the task is and when it will be completed. Adjourning Agenda -- The list of items that wi ll be addressed during a meeting. Often a certain amount of time is budgeted for each item and this is also noted in the agenda. Angel Investor Assignment Audience analysis -- A structured method to determine characteristics of the person receiving a communication. The audience analysis enables the writer or speaker to design the communication for greatest effectiveness. An audience analysis is useful in preparing any type of communication, including written, oral and graphical {drawings, illustrations). Benchmarking Biodegradable Body text- Body text describes the primary font and paragraph style in the document, which is the style of the "normal" paragraphs in the document. This is in contrast to other types of text in a document such as, figure captions, references, footnotes, etc. which may use a different formatting. Claims Classification Number Client statement-- The initial written statement, submitted by the client, that describes the design problem. In industry this may be in the form of a request for proposals {RFP). Closed-ended problems


355

14 - 3


Code Compromise Conceptual design alternatives Confidentiality Agreement Consensus Consequence Conservation of energy Conservation of mass Constraints Consulting company Conventions-- Certain practically accepted practices- similar to a standard. These practices are not necessarily monitored by anyone. For example, the color red and hexagonal shape are " conventionally'' associated with stop signs. Copyright Corrosion Creep Cross functional team Deciding how to decide Deliverables - Something that has to be submitted. In a course, the deliverables are submitted to the course staff (eg: the instructor or teaching assistant). For an actual industrial project, the deliverables would generally go to the client and could include reports, drawings, code, schematics,


356

14 - 4


or prototypes. These would be specified in the agreement between the company performing the design work and the client or customer. Design brief Design Patent Design review DFX (Design for X) Digital Copy-- Also called an electronic copy, it is a document in digital form. The most commonly used system for transmitting documents in digital form is "pdf" (i.e. Adobe Acrobat). This format is preferred over a word processor f ile because it retains formatting better across different computer system platforms, and it is more difficult to alter the original document, i.e. it preserves the integrity of the information better than other file formats. Discipli ne Documentation Due diligence Ecological system Employed to invent Enablers Engineering design process Engineering notebook Entrepreneur Ergonomics - The applied science of design in relation to the human user. It is intended to reduce operator fatigue and discomfort. Ergonomics is also referred to as biotechnology, human

engineering, and human factors engineering.


357

14 - 5


Erosion Executive Summary -- An Executive Summary is a brief summation of all the most important points mentioned in a document. Its purpose is to give a busy reader a complete understanding of the most significant aspects of a project so that the reader may make a reasonably informed decisions, perhaps about funding, continuation, mitigation or cancellation of a project. An Executive Summary may not contain any information that is not also in the document, but it may repeat sentences word for word f rom the document. This is a stand alone summary; the reader should understand all essential information, conclusions, recommendations, time lines and budget issues f rom this summary. Failsafe Fatigue Feasibi lity analysis-- An analysis ofthe preliminary design to make sure that it meets all the functions and constraints, including economic constraints, and significantly addresses the objectives. The design is also analyzed to make sure that it is safe and can be implemented. FMEA Forming FTA Functional decomposition Functional unit Functions Gantt chart Gated project Goal definition and seeping Goals


358

14 - 6


Guard Hard copy - A copy of a document printed on paper. Hazard HAZOP High performance team Hijackers Hitchhikers Honorific -- A term placed before a proper name to signify respect - e.g. Mr., Ms., Dr. Professor (Prof.) is the honorific used for university instructors, both male and female. How-why tree Ill- posed 111-structu red Impact analysis Implied solution-- The client may specify a sol ution to a design problem in the client statement. This is called an implied solution. This is often not the best solution and does not fully describe what the client actually needs in genera l t erms. Improvement analysis Indeterminate Industrial ecology Infringement In-house


359

14 - 7


Intellectual property Interest-- 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. Interlock Inventive step Inventory analysis Isolationists Iterative Licensing Life cycle assessment Life cycle diagram Lockout Material Memo --A short written message used in busi ness to convey a simple concept, e.g., details about an upcoming meeting or notification of issues that need to be further addressed in a project. Metrics - A measurement method used to determine how successfully a proposed design meets the criteria defined by an objective. Midpoint assessment Mi lestone Minutes-- Notes taken during a meeting. Like notes taken during a lecture, these are not an exact reproduction of everything said at the meeting; instead they record what decisions were made and the action items coming out of the meeting, e.g., who will do what by when.


360

14 - 8


MSDS Non-Disclosure Agreement (NDA) Non-Governmental Organization (NGO) -- Typically a not-for-profit agency with a particular political, social, humanitarian or environmental mission. Non-obvious Norming Novelt y Objective goals Objective tree Objectives Off-the-shelf Open-ended problems Operators Organizing Patent Examiner Performance measures Performing PERT chart Plagiarism Plant Plant Patent


361

14 - 9


Potential team Preventative engineering Primary functions Prior Art Problem statement-- This is a re-statement or that describes the gap in technology that the design will fill. Key to a successful problem statement is a clear definition of the client's need. It serves as an introduction to the project requirements. Process Producing Product Project manager Project requirements --This is a full definition of the design problem including the problem statement, functions, objectives, constraints, service environment, and important information that has been gathered that describe the design problem. The documentation of the design problem goes by various names in different industries. The project requirements documentation may sometimes be called the Problem Definition, Scope or Seeping Document or Specification document. Proof test Prototype Prototyping Provisional Patent Pseudo team Public domain


362

14 - 10


Purpose Real team Reality check Recycle Reduce Redundancy Reflection Regulations Renewable Request for Proposals (RFP) Requirements Research & Development (R&D) Reuse Risk Routine design Royalty Rubric - An assessment and feedback tool used for evaluating assignments. The feedback given on a rubric is intended to provide helpf ul, specific information that can be used on subsequent assignments to improve performance. Safety Factor


363

14 - 11


Scope-- The breadth and depth of a project. Typically the project requirements (sometimes called the seeping document) define the scope of the project. The scope specifies what a design team will do for the client and what they will not do, i.e. the boundaries of the project. Scope Creep-- Common project management issue in which additional client requests or new research cause the project to expand as it progresses. Secondary funct ions Service Environment Service mark Severity Solution driven-- A problem statement that has already begun to limit the type of solut ions being considered, rat her than focus on the fun damental needs. Instead of relying on t he functions, objectives and constraints, a solution driven problem st atement focuses on the f inal design or implementation method. For example, a solution driven problem statement would be one that defines the problem as a requirement for "a better door lock" rather than a needs focused problem of a requirement for "improved building security." Solution independent Specification Stakeholder interest - see Interests Stakeholders- Anyone who has an interest in the design (ex: client, government or regulatory bodies, end users, companies involved, NGO's concerned with the social, human, or envi ronmental impact of the design, etc). Standards Storming Strategic


364

14 - 12


Strategy of least commitment Structure Sustainable System Team Team beliefs Team charter Team rules -- A set of rules agreed upon by your team to deal with various issues such as expectations for behavior, decision making, how to deal with problem behavior by members, etc. Team ru les should also include consequences for failure to adhere to the team rules. Technology Three R's To document Trade Secret Trademark Users Utility patent Venture Capital Virtual environment Warning Label Wear


365

14 - 13


Within function team Workaround


366

14 - 14

Designing Engineers Textbook (2012)

Recommend Documents