concurrent engineering - k. n. toosi university of technologykntu.ac.ir › ... › kazerooni2 ›...

Concurrent Engineering

[ Home | Links ] Updated 2003-10-06


Vincent Chan and Filippo A. Salustri

Introduction

Traditionally, design and manufacturing have been separate engineering departments. The trend today has been to combine these functions and form design teams. This systems approach to product design has led to reduced lead times and reduced problems in manufacturing.

One of the resulting major changes to manufacturing philosophy in embodied in a process called concurrent engineering. The design stage of concurrent engineering is sometimes called concurrent design. Concurrent engineering may be defined as:

A systematic approach to integrated, simultaneous design of products and their related processes, including manufacturing and support.

Thus, concurrent engineering is a paradigm shift away from serial or sequential engineering, to a process where all relevant departments are involved in the design process from the very beginning. This interaction should compress the development cycle and reduce the time-to-market for a new product.

Factors such as global competition and ever-faster-changing consumer demands have placed new challenges on manufacturers.

Some of the benefits that can be gained from concurrent engineering are:

● customers are consulted during and throughout the design process; their expectations will more likely be met.

● improved design quality, leading to fewer changes after manufacturing starts.● reduced product development and design times.● reduced production costs due to fewer design changes and faster product

development.● reduced delays that often lead to loss of market share.

http://deed.ryerson.ca/~fil/t/dfmce.html (1 of 11)2004/07/30 12:36:06 •.•

http://deed.ryerson.ca/~fil/welcome.html

http://deed.ryerson.ca/cgi-bin/serf/search


● quicker product turnover.● increased reliability and customer turnover.

The four pillars of concurrent engineering

Obviously, the key element of concurrent design is the co-ordinated activities between all the stakeholders in the process. Beyond this, four areas have been identified upon which the success of any concurrent design rests.

Organisation

People must be motivated to change their traditional work habits to share ideas, offer ideas, and accept the ideas of others. There must be an unhindered exchange of ideas and information. This challenges the way companies have been organised in the past, i.e. into discipline-based departments (mechanical, electrical, software, hardware, manufacturing, quality assurance, etc.)

Management must be flexible enough to build teams with representation from all departments. The organisation of a company that implements concurrent practices is such that conventional departments are subservient to project-based teams.

Communication

Not only must the different groups be able to understand each other (e.g. marketing and engineering), but the infrastructure, such as computer hardware and software to support them, must be compatible. There must be an easy transfer of information relating to the product's development. For example, designers must be able to access marketing data, and CAD and CAM formats must be compatible. Workflows within departments must account for workflows in other departments to ensure that individual workers can participate in the project, not in the department's activities.

Product design specification

This is the "formal" description of the problem to be solved. Most importantly, it represents an agreement between the product developers and the clients/users on what exactly is needed of the product. It provides a goal towards which the whole team must work. Although in real life, requirements can and do change, by having everyone working towards a "goal post" the number of design changes and iterations before production is reduced.



Product development

Product development is the process used to get from the PDS to the total design of the product, ready for production. Refer to the section on the design process for details.

Concluding remarks

Implementing concurrent engineering is not easy, especially if not everyone in a company agrees that it is necessary. Consider the following article (reprinted without permission for teaching purposes).

A Bet Chrysler Can't Afford to Lose

by Doron P. Levin, New York Times, 26 August, 1991.

AUBURN HILLS, Mich. Designing a car from scratch is an immense financial bet, and one an auto maker must be strong enough to lose. The Chrysler Corporation may not have that luxury with its latest car project, which is being hurried toward completion next summer. Chrysler's new family of midsize cars, which have been given the code name L/H, will sell for $15,000 to $20,000. The cars will contain Chrysler's first all-new configuration of body and chassis since the plucky K-car of a decade ago, when the company was near bankruptcy.

The L/H project is important for Chrysler not just because it may be a last chance for the company to recapture some of its shrinking market share, but because the 744-member design team is modeled on a Japanese project team. Its success or failure will be crucial for Chrysler in finding out whether it can produce vehicles that can compete with Japanese models.

Japanese auto makers appoint engineers and planners with diverse skills to work in close-knit project teams. typically, top executives interfere very little after a car's size, shape and target buyers are decided upon.

In the United States, however, auto makers have done the opposite. Planners and engineers are borrowed from larger departments, like those dealing with brakes or engines. These employees usually maintain their loyalty to department bosses instead of to their design


http://deed.ryerson.ca/~fil/t/dfmdp.html


teams, and their decisions may often be overruled by any number of top executives outside the design teams. At Chrysler, new models often embodied the compromises, mistakes and delays that resulted from such a system.

To maintain a health distance from meddling executives and to keep their own lines of communication short, L/H team members were assigned to a small, one-story office building here in Detroit's northern suburbs, 20 miles from Chrysler's engineering headquarters. Eventually, the team will have a separate floor of the $1 billion Chrysler Technology Center under construction nearby.

On most days, those team members who are not lcoked in continuous meetings, which start as early as 7 A.M., are hunched before the color monitors of computer work stations or scurrying about with scrolled drawings. A small mock-up room is crammed with steel, plastic, or wood prototypes, known as "bucks."

Struck by the importance of the L/H to Chrysler's future and their own jobs, people here often work on Saturdays and Sundays - voluntarily, for there is little money for over-time pay.

Stretching the Resources

Chrysler will barely have the resources to complete the project, a situation emphasized by its recently proposed equity offering, meant to raise $500 million. Chrysler would not be selling stock at severely depressed prices unless it was desperate, many financial analysts say.

But even a wirthy design may fail to generate adequate sales. The L/H cars, representing an investment of more than $1 billion to replace poorly selling models like the Eagle Premier, Chrysler New Yorker and Dodge Dynassty, might still flop in a weak economy.

The L/H models (said to be named the Chrysler Concorde and Eagle Vision, with the new Dodge as yet unnamed) could also flounder if the civiously competitive midsize car market becomes so crowded with Toyota Camrys, Ford Tauruses and Chevrolet Luminas that prices collapse and profit margins evaporate. In either case, most experts say Chrysler would have to seek a financial rescue or a merger.

But if the L/H stumbles because the cars are panned by reviewers of



scorned by consumers, Chrysler's fundamental design and engineering competence would fall under such harsh scrutiny from suppliers, lenders and shareholders that new loans or investments would be more difficult to obtain.

A Spunky Optimism

Bucking those grim possibilities is Chrysler's spunky optimism, fueled by glowing preliminary reviews of L/H prototypes, which have been examined and driven in recent months by automotive writers, suppliers and analysts.

The L/H is notable for a chassis design that provides exceptional interior space for a car of its size. The performance, styling and comfort represent vast improvements over current models, many people in the industry say.

Talal el-Awad, who supervises development of interior trim parts like armrests and door locks for the L/H, said the doom-saying that had resulted from Chrysler's recent poor performance does not faze him. "What you read isn't that important," he said. "People inside know we are going to make it."

Cutting Development Time

Mr. Awad's upbeat assessment is shared widely by his colleagues, especially G. Glenn Gardner, head of the L/H team. Mr. Gardner and Fransis Castaing, vice president of engineering, helped persuade Chrysler's top management to try a project-team system. Mr. Gardner had first seen it in action in 1989 after serving nearly five years as chairman of Diamond-Star Motors, Chrysler's joint venture with the Mitsubishi Motor Corporation.

Mr. Gardner's goal was to cut the normal 51-month development cycle to 42 months or less, and to authorize relatively junior engineers and planners to determine precisely what characteristics the L/H cars would have. Mr Gardner is said to have exceeded the goal by three months.

By compressing deadlines for production of prototypes, L/H engineers gained more time for testing actual vehicles in the real world, he said. Tests of the engines and transmissions, in particular, have been made longer and more rigorous. Defects in Ultradrive transmissions of



Chrysler's 1991 mini-vans, though ultimately resolved, threatened to destry the vehicle's popularity.

Example for the Future

Chrysler's approach to designing the L/H - where the development team's relative autonomy is meant to avoid the turf battles, bureaucratic dithering and hassles with suppliers - is not new to American auto making. The General Motors Corporation's Saturn project and the Ford Motor Company's highly successful Taurus program drew on similar inspirations. Chrysler's own mini-van, in fact, was an innovative team project carried out during a dire financial crisis. Its success saved Chrysler.

The L/H team's example is meant to change how Chrysler designs all its new vehicles. The team is already beginning work on a new subcompact.

"From the beginning one fo theprimary objectives in this program was to take senior management out of the day-to-day development loop as much as possible," Mr. Gardner said.

At a recent meeting of L/H managers, Mr. Gardner and his top 15 managers snickered over a Chrysler executive's suggestion of a slight change in the shelf above the L/H's rear seat.

"Lutz said leave it alone," Mr. Gardner replied with a laugh. Robert A. Lutz, Chrysler's president and a strong contender foor succeed Lee A. Iacocca as chairman, has been a strong supporter of the new team's approach.

Devoted Student of Japan

While automakers have learned a great deal about the benefits of teamwork among factory workers, managements have been slow to grasp that Japanese engineers and executives live by the same principles.

Mr. Gardner's experience at Diamond-Star made him a devoted student of japanese auto development. On his credenza sits a copy of "The Machine that Changed the World," a book based on the Massachusetts Institute of Technology's five year study of the gloabl



automotive industry. The book argues that Japanese companies are beating the Americans because the Japanese are more efficiently organized. "It's required reading for all my managers," Mr. Gardner said.

The tiniest change in a car's design becomes geometrically more expensive and time-consuming to closer it is made to the start of production, he explained. "That's why Janaese car makers spend so much time early testing and testing and talking and talking," Mr. Gardner said. "The Japanese call it nemawashi, or literally, stimulating the small shoots to grow. Once everything is decided, there are very few changes. But in all, the time expended is much shorter."

Arthur H. Little Inc. recently concluded that reducing product development time does much more than merely help beat competitors to the market. According to a tire automotive consulting firm's study of 24 auto makers worldwide, reducing development time by 20 percent raises profitability by 15 percent.

"Western culture encourages individual success and leadership, not team success," the study said. "It is very clear that with Japan's successful use of the team approach, they are getting more for their money out of their engineering departments."

Implementing concurrent engineering

The basis of concurrent engineering is the formation of a multi-disciplinary team. The best team members are not narrow specialists, but people with a good combination of breadth of knowledge and also a depth of some pertinent specialisation. In addition to a constant core membership, individual specialists may be brought into the team from time to time to treat specific issues.

Historical note: before the second world war, most product development was done by generalists. These were people who were knowledgeable in many areas but experts in none. For example, Henry Ford knew about design, manufacturing, management, and marketing. In this kind of setting, an "over the wall" approach to engineering is reasonable, because each engineer can expect his colleagues to have a good general background.

However, as the technologies being used and the products being developed became more complex, the need for technical specialists grew. This resulted in segmented companies where many cloistered groups of experts worked in



isolation of each other. In this setting, the over the wall approach doesn't work anymore because one cannot expect one's colleagues to have a reasonable understanding of anything except their own speciality. It is in order to address this problem that the concepts of concurrent engineering and team-based product development came into being.

In general, a member of a design team must:

● understand the product requirements.● have close and constant communications with other team members.● be able to make decisions independently.

Depending on the size and complexity of the design project, "team" can refer to teams of teams of teams. For example, in a new car design, there might be a team responsible for each major system (engine, suspension, interior, etc.) and a single core team composed of one representative of each subteam charged with coordinating all the work. For another example, the Boeing 777 employed some 5,000 engineers, arranged in four tiers of teams. Although for complex products there may be hundreds or thousands of team members, it is rare to have more than 20 workers in a single team - otherwise, one must resort to hierarchies of teams. Typically, teams have 5 or 6 members.

"Group think"

Unfortunately, teams can go wrong, with disastrous results. Team members can develop a strong desire to please each other, to demonstrate their "loyalty" to the team, at the expense of the product. This group think pressures people with doubts to keep silent, to give in to the emerging group consensus, and to focus on the opoular option only.

Overcoming these problems is not easy. It helps if members are aware of these hurdles, but often these problems can only be resolved by a good team leader.

Some principles of successful teams include:

1. Team members must try to like and respect other team members.2. Teams should have diverse areas of expertise.3. Teams must have a common vision.4. All team members must understand and should accept the solution.5. Teams should promote open-minded thinking, and should avoid premature

consensus.6. Teams should maintain a balance between individual and group work.


http://deed.ryerson.ca/~fil/t/kickoff.html#vis


7. Teams must be systematic in their work.8. Team members must communicate.9. Some members should be comfortable working with conceptual ideas, others

with specific details.10. A good team leader empowers the team, he doesn't stifle or micro-manage it.

Team leaders

Oddly, strong leadership is a key to successful teams. Leadership is not about management, but rather about guidance and balance. A good team leader:

● has a broad scope of knowledge and responsibilities● assumes responsibility for ensuring that the concept is accurately translated

into technical detail.● communicates well with both team members as well as clients and users.● actively seeks to manage conflicts as they arise.● circulates among the team members informally.

More information about teams is available here.

If your team is having difficulties, check this web page.

A more detailed list of concurrent engineering rules is available.

The changing roles of team members

CONCEPT DEVELOP

DETAIL DESIGN TESTING PRODUCTION

MARKETING client surveys focus groups advertising & promotion follow-up surveys

DESIGN conceptual design

detail & systems design

design revisions assist mfg

MANUFACTURING rough costingparts suppliers, machinery

conduct tests mfg @ prod rates

Reasons for resisting concurrent engineering



● basic conservatism and cautiousness of management.● fear of the unknown.● lack of defined job responsibilities.● loss of authority or status.● change in existing work relationships.● fear of lower salary rate or job loss.● loss of job satisfaction.● need to learn new job skills.

The risks of concurrent engineering

● teams are more difficult to manage than individuals.● not all engineers are team players.● cost of bringing team members together.● cost of removing team members from "home" departments.● resistance to change.

Example: Xerox

The Xerox Document Centre 265 was the first product to emerge from the company's new product development process based on concurrent engineering principles. It was developed in response to a perceived need for an extensible, modular, digital platform that would serve as the basis for an entire family of new products. Though motivated essentially by business and corporate needs, this new system was developed as a technical rather than a business system, for achieving goals of market superiority. As such, the product development process had to be based on engineering needs - what the engineers needed to achieve the corporate goals - and not just marketing or business plans. The design facility was developed to have no doors and lots of windows. This encouraged the sense of 'team' that is needed for successful concurrent engineering projects. Also, product goals were established by the engineers in the teams, rather than having the goals dictated by management. This helps give the engineers the control they need to execute concurrent processes well. They moved away from metrics that measured defects (i.e. negative measures), to metrics that measured functionality (i.e. positive measures). This encouraged engineers to exceed design expectations rather than just minimise the things that can go wrong. Benchmarking of competitors' equipment was also used to identify opportunities to beat competing products. "Know your enemy." All corporate measures indicated a substantive success of this approach, in some cases by a factor of 2.



Example: Mars Pathfinder mission

The Mars Pathfinder mission had a three year development cycle and a cost cap of $150M (FY 92). This was a very tight schedule and budget. In order to meet these constraints, small teams were established around key issues, rather than based on conventional disciplines. Some of these teams included: a wheel abrasion team, a material adherence team, and a landing systems team. New teams were created in response to new issues as they arose. This flexibility was key to meeting the goals of the program.

© 2003 Vincent Chan - ([email protected]) and Filippo A. Salustri - ([email protected])


http://www.ryerson.ca/~v7chan/

mailto:[email protected]

http://deed.megan.ryerson.ca/~fil/



Design Teams and Collaboration


Design Teams & Collaboration

Filippo A. Salustri, Ph.D., P.Eng.

Most design engineering occurs in teams so it is very

important that students learn how to act and design

in team environments

Contents

● Why do team-based projects?● How are design teams formed?● What can be done when a team has difficulties?● How do teams grow and mature?● Communications● Project Management

© 2002-2003 Filippo A. Salustri - ([email protected])

http://deed.ryerson.ca/~fil/t/teamformation.html2004/07/30 12:36:28 •.•





Why do Team-Based Design Projects?


Why do Team-Based Design Projects?


The goal of the term long design project is to expose students to a semi-realistic design situation involving an open-ended design problem that must be solved by working together in groups.

When you enter the workforce, your employer will not ask you who your favorite co-workers are. You will be told who to work with, and your future with the company will depend significantly on your ability to get along with your colleagues and behave professionally. In order to give you some experience in this, you will be put into teams by the instructors.

Design teams will be formed by the second week of class. In order to be assigned to a team, each student must take a personality indicator test.

In a recent survey of 33 engineering companies across North America, teamwork was identified as one of the top three skills needed by graduating engineers [Var95].

Once a design team has been established, it will not be changed as a result of friction or other personality problems among its members. The members themselves will have to find ways to resolve their difficulties, just as would happen in real life.

Of course, the instructors will be available to help overcome such problems - something that is almost never possible in real life.

Finally, the people skills you develop by interacting with your classmates will better enable you to handle various other social interactions outside your profession. Teamwork is more of a life skill than just an engineering skill.

© 2002-2003 by Filippo A. Salustri

http://deed.ryerson.ca/~fil/t/whyprojects.html2004/07/30 12:36:39 •.•




Personality Type Indicator




A personality type indicator (PTI) is an instrument intended to assess characteristics of personality. It is often used to facilitate group-based activities, including the formation of teams. I have developed a small, web-based PTI that I use to build student teams for courses I teach. Since I have had good experiences with this tool, I've opened up its availability to others.

This particular PTI uses a short MBTI-style indicator. It categorises individuals into one of 16 different personality types.

The algorithm that creates the teams is based on trying to ensure that each major personality type is represented in a given team. The algorithm is not perfect, though, so you may find one or two people at the end of the teams listings on their own. You can pretty much add them to any team.

I know the algorithm work well when building teams of between 4 and 7. No guarantees of what happens otherwise.

If you are an instructor interested in using this tool, click on the INSTRUCTORS link, below. If you are a student who has been told to use this tool as part of a course, click on the STUDENTS link, below.

All information regarding PTI results is confidential.

PLEASE NOTE:I offer this service voluntarily and free of charge. But I cannot guarantee that I'll be able to handle MANY requests. Your understanding in this regard is greatly appreciated.

INSTRUCTORS STUDENTS

http://deed.ryerson.ca/pti/welcome.html (1 of 2)2004/07/30 12:36:47 •.•

http://deed.ryerson.ca/~fil/


http://deed.ryerson.ca/cgi-bin/pti/start.pl


© 2001 Filippo A. Salustri - ([email protected])

http://deed.ryerson.ca/pti/welcome.html (2 of 2)2004/07/30 12:36:47 •.•



Bibliographic Search Results

Searchable BibliographyReferences on: Engineering Design, CS, AI, and programming languages and the World

Wide Web

Keywords:

References matching at least one key phrase will be returned. A key phrase is a list of words delimited by commas from other key phrases. Keywords match only the beginning of words.

Authors:

References matching all authors will be returned. Author names are separated by commas. Authors must match whole words. Do not search for first/given names.

[Var95]Various. Integrating the product realization process (prp) into the undergraduate curriculum. Curriculum Development Project ISBN 0-7918-0126-8, ASME, ASME, New York, 1995.

Filippo A. Salustri ( [email protected] ) Database: http://deed.megan.ryerson.ca/~fil/Research/Bibliographies/Fil.html 1316 references, last updated Wed Jun 9 10:48:02 Canada/Eastern 2004

http://deed.ryerson.ca/cgi-bin/bibsearch?k=Var952004/07/30 12:36:55 •.•



http://deed.megan.ryerson.ca/~fil/Research/Bibliographies/Fil.html

Information for Instructors


Information for Instructors


In order to use this test to build teams in your course, here's what needs to be done.

1. send me email ([email protected]) with the following information

❍ your name, address, email address, and phone number❍ the course number and title for which you wish to use

the PTI❍ The number of sections in the course. For example, say

you teach one couse (call it DES100) that is divided in two sections. Say also that you want no teams to span the two sections, tell me there are two sections.

❍ your prefered administrative password (so you can trigger the group formation software yourself).

2. I will reply with a list of course IDs, one per section. For the example above, you might get the IDs DES100-1 and DES100-2. I will also create a web account that will let you run the group formation software.

3. Tell your students to go to the web site http://deed.ryerson.ca/pti/ and follow the STUDENTS link. You will need to give them the right IDs too.

4. When you're convinced all your students have taken the test, come back to this page and follow the instructions below to create your teams.

In order to create teams, you will need to choose the link below and follow the instructions that are given you.

[ CREATE TEAMS ]

© 2001 Filippo A. Salustri - ([email protected])

http://deed.ryerson.ca/pti/instructors.html2004/07/30 12:37:15 •.•

http://deed.ryerson.ca/~fil/



http://deed.ryerson.ca/pti/

http://deed.ryerson.ca/pti/

http://deed.ryerson.ca/pti/p/create.html



Concurrent Design and Development


Concurrent Design & Development


What is Concurrent Design?

Concurrent design is design that occurs in concurrent engineering environments.

In a very general way, engineering occurs in a sequential manner. Design must occur largely before manufacturing; testing must occur after manufacturing has started but before full scale production is undertaken.

Since engineering (including design) occurs this way, people thought (long ago) that expertise for each stage was only needed at that stage: manufacturing expertise was only needed during the manufacturing stages, and design expertise was only needed during design.

However, concurrent engineering is based on the observation that there is no necessary condition forcing that expertise to occur only at the required stage. Following this line of thought, one can then ask Are there other stages of product development during which expertise in X is useful? The answer is a resounding YES.

Indeed, it is often the case that all kinds of expertise are absolutely essential at almost every stage of product development. So we identify a need to provide a variety of expertise concurrently in each stage of a sequential process.

How do we ensure the required expertise is available? By creating a team, the members of which each have some of the required expertise. Thus arose the notion of the Tiger Team, the multidisciplinary group that guide a project from beginning to end.

Once we accept the notion of a team, and of team-based engineering, we must also consider that all these experts are not only consultants. For example, now that we can expect manufacturing engineers to be present during design stages, there is no reason to stop the manufacturing engineers from starting their own work as soon as the designers can provide them with even preliminary information.

Therefore, because of concurrent expertise, we can begin to parallelise tasks. Doing engineering tasks in parallel tends to shorten lead-times, which improves the overall efficiency of the product development process.

http://deed.ryerson.ca/~fil/t/cdnd0.html (1 of 4)2004/07/30 12:37:51 •.•

http://deed.ryerson.ca/welcome.html



Now, if a Tiger Team exists during each stage of the product development process, then it is also present during the design stages of that process. So now, the kinds of tasks that need to be carried out during the design phases must account for the needs of the concurrent engineering process. Design that occurs in this way is called concurrent design.

Generic Product Development Processes

In order to understand how design and development fit into the engineering process, consider the following chart of how different functional areas have to act and interact in order develop a product. The following table indicates a generic product development process and the roles played by the key stakeholders within the engineering enterprise.

A generic development process (based on [UE95])

ConceptDevelopment

SystemsDesign

DetailDesign

Testing &Refinement

ProductionRamp-up

Marketing Define market segments

Identify lead users

Identify competitors

Develop plan for product options and family

Develop marketing plan

Develop promotion & launch materials

Facilitate field testing

Place early production with key customers

Design Study product concept feasibility

Develop industrial design concepts

Build/test experimental prototypes

Generate alternative product architectures

Define major subsystems and interfaces

Refine industrial design

Define part geometry

Choose materials

Assign tolerances

Complete industrial design

Test for reliability, life, performance

Obtarin regulatory approvals

Implement design changes

Evaluate early production output


http://deed.ryerson.ca/cgi-bin/bibsearch?k=UE95


Mfg Estimate manufacturing cost

Assess production feasibility

Identify suppliers for key components

Perform make/buy analysis

Define final assembly scheme

Define piece/part production processes

Design tooling

Define quality assurance processes

Begin procurement of long-lead tooling

Facilitate supplier ramp-up

Redine fabrication & assembly processes

Train workers

Refine QA system

Begin operation of entire production system

OtherFunctions

Finance: facilitate economic analysis

Legal: investigate patent issues

Finance: facilitate make/buy analysis

Service: identify service issues

Sales: develop sales plan

This process will vary significantly from one kind of industry and company to another. In the following table, some of the variants are described.

Some variants of a generic development process

MarketDriven

TechnologyDriven

PlatformDriven

ProcessDriven

CustomerDriven

Description

Begin with market opportunity, then find appropriate technology

Begin with a new technology, then find appropriate market

Assume new product built around existing product's technologies

Product characteristics highly constrained by production processes

New products are slight variations of existing configurations



DistinguishingFeatures

Additional initial activity matching technology to market

Concept development assumes a technology platform

Both product & process developed together from outset, or an existing process must be specified at the outset

Similarity of projects allows for highly structured development process

Examples

Sporting goods, furniture, tools

Gore-Tex rainwear, Tyvek envelopes

Consumer electronics, computers, printers

Snack foods, cereal, chemicals, semiconductors

Switches, motors, batteries, containers

Nonetheless, and no matter what process is used in any given industry, design always plays a key role in product development and in keeping the project itself organised.

© 2002-2003 by Filippo A. Salustri - [email protected]




The Structure of Design Teams




A typical structure of a Tiger Team is presented below. This is the sort of team one might expect to need for a product of modest complexity contracted by an external client, and covering both design and manufacture.

Individuals with specific kinds of expertise are in the inner circle; this is the Core Team. The Core Team should follow the project from beginning to end. The grey ovals in the Extended Team circle denote other specialties that are needed, but only occasionally, by the Core Team. Sales, Finance, Standards, and Legal experts are usually the kinds of people that occupy positions on the Extended Team.

http://deed.ryerson.ca/~fil/t/tiger0.html (1 of 2)2004/07/30 12:38:13 •.•




For very small design projects, there might not be need for a Team at all. If one person can be found with the experience needed to design the (small) product, then the Core Team collapses to a single person. The Extended Team, however, remains in existence, as a group of consultants to the designer.

For very large design projects, added rings may be added. In this case, the Core Team consists of systems specialists, each charged with a particular major system or component/assembly of the product. For example in aerospace design of large aircraft, the core team would typically include Project Leader, plus a Wing Group Leader, a Fuselage Leader, and Tail Leader, etc. Each of these leaders would lead a sub-team structured as in the figure above.

© 2002-2003 by Filippo A. Salustri - [email protected]

http://deed.ryerson.ca/~fil/t/tiger0.html (2 of 2)2004/07/30 12:38:13 •.•



How are Design Teams Formed?


How are Design Teams Formed?


Design teams will be formed by the second week of class. In order to be assigned to a team, each student must take a personality indicator test.

These kinds of tests are quite common in industry. They are not tests in the conventional sense - no one can fail a personality test. Rather, these tests identify the basic personality characteristics of an individual. Having those characteristics in hand allow managers to build teams composed of complementary members.

Because these kinds of tests have been shown to lead to teams that work better together, we use one such test to build design teams.

Once a design team has been established, it will not be changed as a result of friction or other personality problems among its members. The members themselves will have to find ways to resolve their difficulties, just as would happen in real life.

Of course, the instructors will be available to help overcome such problems - something that is almost never possible in real life.


http://deed.ryerson.ca/~fil/t/teamcreating.html2004/07/30 12:38:46 •.•




If Your Team is Having Difficulties



If your team is having difficulties getting along, or if some team members aren't participating, or if you are falling behind in your schedule, consider the items discussed below. Do any of them apply to your team? Sit down with your team, and discuss all the various topics below, and look for possible solutions. Every member of the team will benefit if the team as a whole functions better.

This material is adapted from [ DDL+01 ].

Dominant Team Members

You know you tend to dominate if you:

● interrupt frequently to interject your opinions;● restate your opinions often;● state your opinions forcefully;● speak often, preventing others from having a chance to participate;● criticize the ideas of others too quickly.

Steps you can take to reduce your tendency to dominate:

● resist the urge to interrupt;● limit the number of times you state the same opinion unless specifically

asked to repeat it;● start your statements with "I think," not "Everyone knows" or "It's so

obvious."● be aware of the proportion of the time that you spend speaking compared

with others in the group; if you are using more time than others, give them a chance;

● refrain from hasty judgement;● ask open-ended questions that will encourage others to participate.

http://deed.ryerson.ca/~fil/t/teamremediation.html (1 of 5)2004/07/30 12:38:57 •.•




Encourage others to express contrary opinions by:

● waiting until others finish speaking, even if you are sure you understand their argument;

● restating the main points of the other person's point of view to ensure you fully understand their perspective;

● asking the person to verify the accuracy of your restatement and clarify it if necessary;

● identifying the points about which you agree;● stating the points you disagree with and why, if appropriate at the time;● not engaging in side conversation while someone else is giving an opinion;● focusing your attention on the speaker.

Ensuring Fair Decision-Making Process

Designing in groups is a decision-making process. Here are some characteristics of good group decision-making processes and how you might achieve them.

Ensure opportunity for participationmake sure every member has a chance to speak

Enforce consistent rulesget all team members to agree on basic criteria; all ideas are evaluated against those criteria

Stop bias from being a factor in making decisionsall team members have an equal chance to participate in both idea generation and evaluation of ideas

Ensure correct information only is usedmake sure alternatives are fully understood by all team members before making decisions

Leave opportunities to reconsider decisionsdo not ignore new evidence that suggests a decision could have been wrong

Managing Conflict

Here are some basic rules for managing conflict.

Acknowledge that conflict is normal and is to be expected



build time for debate into your schedule; and for feedback and discussionAcknowledge personal biases

judge content, not delivery; use others as sounding boards for your ideasUnderstand project definition and constraints

review tasks to be done; assess resources needed to complete tasks; determine who does what and when

Encourage open participationAsk others to contribute; listen to all alternatives

Acknowledge that participants are new to a tasktake the time to know your tasks, and to get to know the strengths and weaknesse of your team members

Seek to understand the ideas of othersbefore getting those around you to understand your perspective, try to understand theirs - you might realize you are closer to theirs than you thought

Don't always be rightacknowledge that others have good ideas - don't immediately correct others and tolerate imperfection

Simple Quiz to Assess your Team's Conflict Management Style

Answer yes or no to each of the following questions:

1. Do you or your team members accept solutions and ideas without thoroughly discussing the pros and cons?

2. Do you leave team meetings without fully understanding what is to be done next or why?

3. Does your team keep having to deal with the same problems?4. Do team meetings stay focused on the task at hand?5. Do you or your teammates present a position and then immediately back

down?6. Do you sense that you or others feel uncomfortable saying what you really

think or feel?7. Do you or a few others on the team tend to dominate discussions and

planning?8. Do you or your team members believe that keeping everyone happy is more

important than finding the best solution?9. Do you or your team members blame others when things do not go as

planned?



10. Are you part of a clique that sticks together, regardless of the issue?11. Do you or your team members show reluctance in considering alternatives

that you did not contribute?12. Do you or your teammates interrupt, or talk over, others?13. Do you or your teammates lecture others in order to convince them you are

correct?14. Does your team decide major issues by voting?15. Does your team attempt to satisfy everyone by incorporating everyone's

suggestions, even if they weaken the solution?16. Do you believe that most of the decisions your team makes are less than

ideal?

If you answered YES to any of questions 1 to 4, your team may be avoiding conflicts. You can try to:

● decide to explore fully the pros and cons of each issue that comes up, even if it means and extra-long meeting or some extra stress on the group for a while

● before the meeting closes, have team members summarize the next steps for which they are responsible as well as the rationale for those steps

● start meetings on time● create an agenda of the issues to be covered for each meeting● appoint a team member to be responsible for keeping the discussion on track

If you answered YES to any of questions 5 to 8, your team may be too quick to accomodate. You can try to:

● have team members who present an argument for or against an issue fully explain their rationale and defend it against counter arguments

● start discussions about the pros and cons of an issue by having team members write dow their support or argument on paper, and then have each contribution read aloud and discussed

● appoint a different person for each meeting to act as facilitator - this person should ask for each person's inputs

● evaluate each idea against the criteria for a good decision and not just because it was suggested

If you answered YES to any of questions 9 to 13, your team may be in a fighting mode. You can try to:

● refrain from passing judgement or assessing blame if things do not go right● divide cliques and meet in different subgroups to discuss issues, so everyone



sees different sides● ask members to defend an idea they disagree with in an effort to get them

to see the positive sides of an alternative they did not consider● spend one meeting reviewing the principles of active listening.● remind team members that each idea needs to be evaluated against the

criteria of the best solution and not genesis of the idea

If you answered YES to any of questions 14 to 16, your team may be too quick to compromise. You can try to:

● refrain from taking a vote to decide an issue, even if it increases the discussion time

● appoint a team member to the role of results checker - after a decision is made, this member walks the team through the evaluation and compares the decision to these criteria

● encourage debate by having each team member state the pros and cons of one alternative, and have the rest of the team respond



http://crs.uvm.edu/gopher/nerl/personal/comm/e.html


Bibliographic Search Results

Searchable BibliographyReferences on: Engineering Design, CS, AI, and programming languages and the World

Wide Web

Keywords:

References matching at least one key phrase will be returned. A key phrase is a list of words delimited by commas from other key phrases. Keywords match only the beginning of words.

Authors:

References matching all authors will be returned. Author names are separated by commas. Authors must match whole words. Do not search for first/given names.

No matches found.

Filippo A. Salustri ( [email protected] ) Database: http://deed.megan.ryerson.ca/~fil/Research/Bibliographies/Fil.html 1316 references, last updated Wed Jun 9 10:48:02 Canada/Eastern 2004

http://deed.ryerson.ca/cgi-bin/bibsearch?k=DDL%2B012004/07/30 12:39:06 •.•



http://deed.megan.ryerson.ca/~fil/Research/Bibliographies/Fil.html

How Do Teams Grow and Mature


How Do Teams Grow & Mature?


Stages of a Team's Growth

You may feel strange when you first meet with your team. This is perfectly natural. In fact, there are generally 4 stages through which any team passes before really fitting together. It helps to know what those stages are, so that you know there's a light at the end of the tunnel.

Stage 1: Formative StageYou may feel anticipation, confusion, anxiety, impatience, fear, and lack of confidence; after all, this is a new situation. Relax: this will pass.

Stage 2: Challenging StageYou may feel resistant, rebellious, defensive, frustrated, angry, suspicious, and overconfident. This is a reaction to Stage 1 - the pendulum has swung to the other extreme. Resist the temptation to believe things will never improve. They will.

Stage 3: Acceptance StageYou may feel an increasing tendency to identify yourself with the team, cooperation, enthusiasm, relief, and you may feel your confidence begin to grow. You are starting to work well together, but you must remain vigilant of problems that may come in the future.

Stage 4: Collaborative StageYou may feel satisfaction, more energetic and motivated, a close affinity to the team, realistic confidence in your teammates abilities, a sense of fulfillment, trust, and self-confidence. No matter what happens now, your team will be able to work it through.

Many teams in real life conditions never survive Stage 2. The instructors are available to make sure you can overcome any hurdles that come your way.

Characteristics of a Good Team

http://deed.ryerson.ca/~fil/t/teammaturity.html (1 of 3)2004/07/30 12:39:28 •.•




A good team is one in which:

● every team member contributes equally and to the fullest extent of their abilities.

● individual successes are recognised as successes of the team as a whole.● each team member uses personal skills that complement those of the other

team members.

Certain kinds of behavior are expected, professional, and extremely productive during collaborative work meetings. These include:

● have specific and clear goals, milestones, and deadlines;● try to learn from one another;● everyone understands what is expected of each team member;● try to remain relaxed and in good cheer;● leadership is shared - elect a different chairperson for each meeting you

have;● always consider several substantially different alternatives before making a

decision;● prefer asking open-ended questions (e.g. "What do you think about...?",

"How could we do this...?", "Why is ... important?");● treat each other with respect, especially when you disagree;● value differing opinions - this is where new ideas can come from;● when problems arise, try to deal with people directly and not behind their

backs;● start and end meetings on time, and stick to the agenda;● create and review checklists of topics that need to be covered and criteria

that need to be met● specifically ask for participation from any team member who has not

contributed during a previous meeting● leave time during meetings to summarize what each person has said and

ensure that feedback is given on each suggestion● establish specific work roles whenever possible, and make sure people know

what is expected of them from one meeting to the next● work each item of the agenda until it has been thoroughly handled;● always have a last agenda item for "new issues";● focus on problems, not people;● if you don't like an idea, offer an alternative;● if you're not sure you understand something, rephrase or paraphrase what

was said and seek confirmation;● solicit input and participation from each other;● everyone has an obligation to participate;● try to reach consensus on important decisions; and last but not least



● try to have fun.




Team Communications


Team Communications


Good communications requires a design engineer to keep good notes, in order to be able to track his/her own thoughts on a design project. Students are expected to keep a design journal for this.

from Project Management, 6th Ed., by Harold Kerzner, ITP, 1997, p. 350


http://deed.ryerson.ca/~fil/t/teamcom.html2004/07/30 12:39:51 •.•



http://deed.ryerson.ca/~fil/t/designjournal.html


Project Management


Project Management


Project management is an essential skill needed by engineers, especially those who will

lead product development and engineering teams.

Introduction

Project management is the discipline of planning, specifying, coordinating, organising, facilitating, supervising, monitoring and verifying all the tasks that must be performed to carry out a project (i.e. reaching an identified goal).

Design usually occurs in teams, and there are always multiple stakeholders in any product develop process. So the social aspect of design - how the stakeholders interact with one another - is very important. Project management often has to account for the social interactions and relationships that exist among stakeholders.

Characteristics & Purposes of Project Management

Project management is:

● is a major component of any long-term, non-trivial task or process;● has a definite start and end;● is a framework for the quantitative evaluation of work performed on tasks &

processes (e.g. via Gantt and Pert charts)

Project management must ensure that a project meets:

● all customer requirements;● budget contraints;● time constraints;● performance constraints (on the project workers; efficiency, effectiveness,

etc.)● ensures proper documentation of the project is prepared and kept.

Project Management Tasks

http://deed.ryerson.ca/~fil/t/projmgmt.html (1 of 4)2004/07/30 12:40:01 •.•



Project Management

There are 4 primary tasks of project management:

Planningdefining objectives, listing tasks, estimating work and duration, determining interdependent tasks, scheduling tasks & resources

This can easily be done with a Gantt Chart.

Directingassigning tasks, reviewing criteria for successful task completion

Controllingreviewing and reporting progress, replanning in light of problems, reviewing completed work, resolving issues, closing projects.

Administeringdeveloping and implementing policies and processures for project management

SMART Goals

Every project must have a goal: a point toward which the effort of the project is directed.

All goals should be SMART goals:

Specificwell-defined; all stakeholders must have a basic knowledge of the whole project.

Measurableknow when you've reached the goal; have the means to measure how close to the goal you are and how far you've "travelled" to get there.

Agreed Uponall stakeholders must agree on the goals before the project kicks off.

Realisticcan the goals be achieved with the available resources?

Time-framedalways track and know how much time you've spent and how much time is left.

When Project Management Fails....

When PM fails, one of the requirements above will fail - usually the budget or the


Project Management

time constraints will be violated. Some of the reasons that PM can fail include:

Poor definition of requirements and objectivesHave you and your teammates clearly articulated what you must accomplish and what is required to accomplish it?

Poor planning and review effortsAre you using a planning technique (e.g. Gantt) and are you systematically reviewing progress in relation to this plan?

Poor communicationsIf a team member doesn't understand what the rest of the team is doing, it's unlikely that he'll be able to do his own job. The communication problem might be technical (mail server failures, lost memos, etc.) but they easily be human interaction problems.

Lack of consensusAll stakeholders must agree on the goals of a project and the means of achieving those goals. Disagreements must be treated quickly, fairly, and without prejudice. This doesn't mean everyone must accept the project manager's decisions. It means that (a) the project manager must listen carefully to all the stakeholders, and facilitate reaching a consensus, and (b) stakeholders who disagree must be willing to set their problems aside for the good of the project (depending on the severity of the disagreement).

Inadequate work breakdown structureHave you clearly articulated the tasks and activities that need to be performed? Ideally try to break down tasks so that they are manageable and specific responsibility can be assigned and accomplished independent of other ongoing activities but at the same time can be integrated back into the total project and measurable in terms of progress.

Starting/completing activities out of sequenceHave you carefully prioritized your work and associated activities? Does the sequencing make sense and can you see how one step will lead to the next?

Unforseen technical - or other - problemsAre you confident that you have done the background research necessary to know the technical challenges posed by your project? Do you know which problems people have encountered on similar projects? Will there be a Union strike? What effect will a snowstorm have on meeting project deadlines?

Scheduling

Scheduling deals with making, maintaining, and sticking to a schedule of how and when particular parts of your project will be done. Scheduling evolves over time. You will not be able to write out a perfect - or even complete - schedule at the beginning of a project. You will only be able to block out major tasks for your


Project Management

project until you study enough about the design process.

For example, you might only start the term with three major tasks: study the problem, design a solution, and write up the final report. That's fine. As the project progresses, you will be able to break each of these tasks into smaller subtasks.

In order to keep track of your schedule, you can use a Ganttt Chart.

Notes on Gantt Charts

Here are some web sites that explain how Gantt Charts work:

● Brief Tutorial on Gantt Charts● Using Excel to make gantt charts● Gantt Charts, Definitions & Examples

You will have to read and understand the information on these pages in order to use Gantt Charts.

Finally, you may prepare and maintain your Gantt Charts using pen and paper, however you are strongly encouraged to use some computer-based tool to create and maintain your Chart. If you have access to Microsoft Project, you may choose to use that. However, there is a freely available add-in for Microsoft Excel, called ProjeX, that lets you build Gantt Charts with Excel.

Other available tools for Gantt Charts include Gantt2, and APlan (but no promises on the robustness of these packages).

You should revisit your Gantt Chart every two weeks, and make sure (a) it is still accurate and modify it as appropriate if not, and (b) that you are sticking to the schedule.

© 2002-2003 Filippo A. Salustri - ([email protected])


http://www.me.umn.edu/courses/me4054/assignments/gantt.html

http://pw.english.purdue.edu/resources/doc/gantt/index.shtml

http://www.cs.utexas.edu/users/almstrum/cs373/general/gantt.html

http://www.microsoft.com/project

http://waa-inc.tripod.com/projex/index.htm

http://jansfreeware.com/gantt2.zip

http://jansfreeware.com/aplan.zip



Rules for Concurrent Engineering




Based on various sources, here are some general rules for concurrent engineering.

Note that these rules are not necessarily all consistent with one another. An example of how these rules can contradict with one another is available.

1. Ensure that parts most likely to require maintenance are easily accessible.2. Ensure that the degree of maintenance of your product is consistent with

your company's policy on making, stocking, and supplying spare parts.3. Ensure tools needed for installation and maintenance are as inexpensive and

common as possible.4. The decisions made in the first 15% of a product development process fix

85% of the downstream quality and cost of the product.5. include all experts actively6. resist making irreversible decisions7. continually optimize the designed product and the design process8. prefer concepts that are easy to manufacture9. prefer concepts that are easy to assemble

10. integrate design and manufacturing11. do not overconstrain or underconstrain the design12. look ahead of the current state of the design to forsee problems13. reduce the number of parts14. increase interchangeability of parts; standardize parts; minimize variation in

parts15. modularize functions and subassemblies16. design multi-functional and multiple-use parts17. avoid flexible components18. avoid separate fasteners19. improve robustness20. allocate time/man-power based on cost/benefit analysis of a proposed action21. maximize yield of existing equipment22. keep assemblies/components as independent as possible23. maximize tolerances

http://deed.ryerson.ca/~fil/t/ce-rules.html (1 of 2)2004/07/30 12:41:09 •.•




24. test only what can be quantified; actively search for testable aspects of a design

25. minimize machining set-ups and re-orientations26. design parts for feeding and insertion into machines27. perform functional analysis28. tailor the manufacturing process to the character of the product29. study producibility and usability30. design the fabrication process31. design the assembly seequence for top-down assembly32. minimize assembly instructions33. use known/proven vendors and suppliers34. use new technologies only when necessary35. identify subassemblies as soon as possible in the design process36. do engineering changes in batches37. integrate quality control with assembly38. match assembly processes to tolerances39. operate on a minimum inventory

© 2001-2003 Filippo A. Salustri

http://deed.ryerson.ca/~fil/t/ce-rules.html (2 of 2)2004/07/30 12:41:09 •.•


Contradictions between DFM and DFA


Contradictions between Design for Manufacturability and Design for Assemblability


Two of the rules of concurrent engineering are:

● make a product as easy as possible to manufacture, and● make a product as easy as possible to assemble.

In the general case, these rules contradict one another.

Consider a single product, say a coffee maker. Now consider two designs for this product such that both designs satisfy exactly the same set of requirements, characteristics, contraints, and performance metrics. The only difference between them is that one design was created using the first rule (so-called design for manufacturability - DFM) and the other was designed using the second rule (so-called Design for Assembly - DFA).

In order to make something easy to manufacture, one would make its parts easy to manufacture. Simple parts are typically easy to manufacture, but tend to provide relatively low functionality. Thus, to attain all the functionality needed for the coffee maker, many simple parts would be needed. But if there are many parts, then assembly will be complex.

On the other hand, in order to make something easy to assemble, one would make its parts easy to assemble. Simple assembly means few parts. But to maintain all the required functionality, each part would have to be complex (because there are few of them to share the functionality). Thus, to attain the all the functionality needed for the coffee maker, a few complex parts would be needed. But if the parts are complex, then the manufacture of those parts will be difficult.

So it would appear that you cannot win, and therein is the contradiction.

http://deed.ryerson.ca/~fil/t/cs-dfma-contradiction.html (1 of 2)2004/07/30 12:41:19 •.•



Contradictions between DFM and DFA

As it happens, this general case almost never occurs in reality. The particular requirements of a particular product specification, carried out by a particular company, in a particular (economic, technological, cultural, etc.) context virtually guarantee that one or the other of the DFM and DFA approaches will be best.

Therefore, the key is NOT to know the rules of concurrent engineering, but rather HOW and WHEN to use them. This requires designers to be reflective and to think not only about the design problem, but also about the environment in which they work and their own capabilities. Reflective designers will have much more success than designers who just plow through a problem assuming that there is a "cookbook" answer available.

© 2001 by Filippo A. Salustri - [email protected]

http://deed.ryerson.ca/~fil/t/cs-dfma-contradiction.html (2 of 2)2004/07/30 12:41:19 •.•



concurrent engineering - k. n. toosi university of technologykntu.ac.ir › ... › kazerooni2 ›...

Documents