Team Definitions, Teamwork Definitions, Best-Fit Applications | ETM 5221, Study Guides, Projects, Research of Engineering

Download Team Definitions, Teamwork Definitions, Best-Fit Applications | ETM 5221 and more Study Guides, Projects, Research Engineering in PDF only on Docsity! ETM5221 Engineering Teaming Week 1 Taping - February 22, 2001 Responses to student bio questions: Topic or Question Page # Define team 1 Define teamwork 2 In your view, what type of projects or tasks are teams best suited for? 3 What tasks are they ill suited for? 5 Describe the BEST project team experience you’ve had to date 6 Describe the WORST project team experience you’ve had to date 9 Best and Worst All in One 12 What do you consider to be the causes or correlates of effective teamwork? 13 Do you think engineers (or technologists) in general like to work alone or would they rather work in teams? What do you see as the major barriers, if any, in getting an engineer (or technologist) to work in a team with other engineers? 16 What do you see as the major barriers, if any, when it comes to getting an engineer to work effectively with non-engineers? 19 What do you hope to learn from this course? 22 Team Definitions 1. A group of people using their varied knowledge/skills to reach a common goal 2. A group of two or more people working interdependently to achieve a common goal. 3. A group of people working together to achieve a common goal by using the talents of all. 4. A group of people who are dependent on each others’ capabilities and/or skills to meet a common goal. Individual self sufficiency leaves you with just a group of people working towards the common goal, not a team 5. One or more groups of people working together to achieve ultimate common pre- defined goals 6. A group of individuals that work to accomplish a common task. 7. An organized group of people performing different, but complementary tasks to achieve a common goal 8. A group of people, with specific skills and points of view, coming together to accomplish a specific task 9. A group of people with a common goal and individual responsibilities toward that goal 10. Group of individuals with unique skills working with a common purpose 11. Group of people with a common goal that requires the input of all to accomplish. Therefore a workgroup of people with identical skills, viewpoints, and responsibilities who could each accomplish the goal individually is not a team. 12. Group of people working together towards a common goal 13. A group of people with different abilities and expertise assembled for the purpose of accomplishing a single defined task 14. A group of individuals who work together to achieve a common goal 15. Group of people working towards the same goal 16. A group of people with various areas of expertise who come together for a common cause. 17. A group of people working together towards a common goal 18. Group of people working together for a common purpose with similar vision and value systems 19. A team is a group of people with a common task, goal, standard or objective 20. A group of people, with different backgrounds, brought together to achieve a common goal. 21. A group of people dedicated and synchronized to the same goal(s). 22. A group of individuals, each with different skills, who were brought together to perform an important task more efficiently and effectively than those individuals could have performed the task on their own 23. A team is a group of individuals who work together to accomplish a common goal. 1 18. Process designs, new product concept and implementation, Improvement initiatives. Big changes where buy-in is a MUST 19. Short duration ( < 1 year), single focus, clearly defined roles and responsibilities 20. Task or project that takes a variety of efforts to complete in a short amount of time 21. Determining process flows, problem solving, project planning, etc. 22. When the task, goal is complex or appears unattainable. 4 Worst-Fit Applications 1. Where a very especial and particular skill is needed to achieve the goals, often pointing to one or only very few individuals within the same area of an organization. 2. Leading crisis management 3. Tasks and projects that can be completed successfully by autonomous entities. If a job can be successfully completed by an individual (on time), and no team-related improvements are foreseeable or necessary, it makes little sense to use a team. Examples include supervision of employees, training functions, clerical work, etc 4. High-pressure situations where something “just needs getting done,” such as troubleshooting equipment on the plant floor, obtaining data for a customer’s needs, or anything else which is of the essence of someone’s core responsibilities 5. Work that can be efficiently accomplished by a single person, drawing on a single set of skills 6. Open-ended projects. 7. Making quick changes that impact them and their business. 8. Solving problems that are equation intensive, writing software code 9. Certain management or leadership type tasks, or in the case where something must be accomplished but cooperation is not assured a manager must make a command decision that is not open to debate 10. Projects that are more linear, steps one after the other, do not lend themselves well to teams. 11. Extremely small projects, one-dimensional projects 12. Short-term projects where it is obvious what course to pursue. In these situations, the additional communication required to keep team members informed can actually delay the project release. 13. Data analysis, Work rate development, Writing/Editing 14. Long duration (> 1 year), multiple focuses, generic roles and responsibilities 15. Tasks that call for singular individual tasks or projects. In other words, when there are too many hands in the pot 16. Deteriming individual departmental/group resource allocations 17. Simple problems where an expert or individual can do the job. 18. Tasks that involve daily operations. 19. Tasks that involve one skill area, but where consensus is desired. Many times we strive for consensus from a group on a task direction and implementation. A lot of times, however, consensus from many technical experts is very hard to get. A lot of times I think it would have been better if consensus was not sought and one person was allowed to go their separate way. The need for consensus is perceived many times instead of actually needed. 20. Projects or tasks that require only one type of expertise are much more difficult for effective teamwork. In this scenario, each individual can just as effectively do the other’s task. This usually leads to conflict over there being “more than one way to skin the cat”. 21. Projects/tasks that no longer have a specific goal 5 Best Experience 1. My best project team was the ARC (Automatic and Remote Control) team described above under the work experience for 1986 to 1990. During this time frame, all individuals were moved to one module of our technology center, had our phone numbers changed and given the authority to do whatever is required to achieve the task. There were no formal meetings, just informal discussions whenever we needed to make a change that would affect others in the team. I referenced that “individuals” were put together because a team is something that grows, not just happens. There were some of the “individuals” that were sent back to their original groups as they never became part of the team. This was also a good team because of good team leadership. The leader did not try to micromanage, but was more of a facilitator who worked to get whatever we needed to help us accomplish our task. The leader also ran interference for us on normal day to day company issues that could interfere with us accomplishing our task. 2. Chemical Engineering Senior Design Project. The instructors allowed the students to choose their own 3-member teams to compete in the national AIChE contest. Our team members were compatible with each other in every way imaginable (work ethic, intellectual potential, personal courtesy, etc.) while each also possessed individual skills that made their contribution unique (one member was "the big picture" and economics type, while another loved getting wrapped up in the technical simulations, while the final member thoroughly enjoyed doing the nuts and bolts research and technical writing tasks. We each made equal contributions to the team, albeit in different areas. In the end we succeeded in our goal of obtaining the highest score possible due to our commitment of maximizing our potential as a team. We completely "sold out" to the team concept! 3. The best project experience I experience was being on a team that had the resources, skilled people, and the authority to solve a problem. 4. Best team project experience was the ISO team – from the ground to registration with no observations or findings in nine months. 5. The best project team experience I had was in the context of a very small scope research project where I had to lead only a 5 people team with a defined goal and clear milestones. 6. A team involved with introducing our newest product. Everyone from his or her specific area of excellence, or core competency, contributed their part and did not question the implementation of the other areas of focus. 7. Best project allowed my fellow team members and I to perform our tasks freely with a manager who only offered direction, and advice. In the end, both projects were completed on time and within budget. The worst case left me with little or no satisfaction, whereas the best one made me eager to do more 8. The best project team I’ve had is the team that developed the plant floor layout for a new product in our facility. We met each week. The meetings followed this format: a) go over progress on last week’s action items, which people actually performed b) list the new problems c) brief brainstorming on those new problems d) determination of possible pitfalls in the plan, or, a subset of FMEA d) assignment of new action 6 Worst Team Experience 1. The worst project team experience I had was a result of several factors that went wrong from the beginning. Among others I can mention the following: not clearly defined ultimate goals and milestones, understaffed team, no full commitment of the team leader and bad communication 2. Burner Cost Reduction Project. The project team consisted of a small group of engineers and manufacturing types at my former employer, and was tasked with the goal of reducing the cost of many of the standard combustion product lines sold by the company. I was a latecomer to the team (the development and testing engineering representatives were added to the team after ~75% of the prototype of the cost- reduced re-design was complete). My specific role and contribution to the project involved testing and of the initial prototype. I was also responsible for analyzing the deficiencies of the prototype and making the necessary modifications required to meet the initial design goals. The primary failings of the team involved a strong lack of commitment and communication. I often felt that team members had no desire to achieve the stated goals. Many of the individuals involved with the design were also working on many other "high priority" projects (i.e. major multitasking), and were often unavailable to work on the cost reduction project. This lack of commitment also resulted in little effort to maintain good communication among all members of the group. Although this team accomplished most of the design goals, the problems stemming from lack of commitment and communication caused severe time delays and budget overruns. 3. The worst team experience was being on a team that lacked the necessary resources to complete the job. 4. The worst project team experience is currently developing. Recently after a reorganization, I was place under a micromanaging technical team leader. He and I are currently on a common project team that I am supposed to be leading. Since I report to the technical team leader administratively, he consistently gives me the “my way or the highway” speech in the project. He also takes credit for what others have done and blows smoke at upper management on how great a team player he is. I am currently working with his boss to either have him removed from the project team or have me transferred to another technical team 5. Worst team project experience was the work cell teams that were assigned to realign and reconfigure their work environment from a push to a pull inventory system. Complete failure due to lack of education, training, budget, management direction and support 6. Worst project team I ever experienced was led by a micro-manager that never allowed us to perform any task without looking over our shoulders and criticizing every step we made. He could have made the project himself 7. A team that was responsible for revamping statistical process control in our factory. This team could never agree on anything because too many software engineers would argue their point of view until the group submitted. 8. The worst project team that I have worked on was a data collection task team, assigned to develop and implement the database structure, the required information, tables, and fields. We also met weekly. We also followed the same basic format as 9 the previous team, except that action items were taken seriously and, therefore, were not completed. Because of that, the brainstorming session became the “do what we were supposed to do throughout the week” session. At that point, egos got thoroughly out of control, and the brainstorming was really just pontification. Needless to say, nothing came out of six months of meeting with this group, which was disbanded by the team leader after such frustration 9. The worst experience with a team was writing a mission and vision statement for our workgroup. 10. The worst team experience(s) I have had are when one person ends up doing most of the work because of lack of commitment from the other members 11. Joined a team partway through because they needed someone to represent engineering. Not only did I not know the issues and personalities but there seemed to be a lot of apathy about solving problems. It seemed the organization wasn’t supportive of the suggestions this team offered but it wasn’t a high enough priority to make the needed changes 12. Participated in a project that was run in a dictatorial fashion without a clear objective. 13. The worst team experience I had would be on the team I started with at [name withheld]. Initially the team was all right, it was a new team and everyone worked hard to accomplish the tasks assigned. As time progressed, the free loader syndrome became very prevalent. It was not a fun team to work on 14. I performed documentation work for a customer project at [name withheld]. The manager was very un-responsive, as well as the other team members, to my needs for input and information. This was largely due to the fact that they were behind schedule and felt that documentation and project management objectives were the first to go. This made my job very frustrating, and ultimately defeated the purpose of project management and documentation 15. I was the lead engineer for the development of a mini-split condensing unit product line. Our company had made an agreement with a foreign company so that we could copy their condensing unit design if we sold only their air handler design. The agreement itself caused several problems. First, we couldn’t get the information from the other company in a timely manner. Second, since the quality of their work was far inferior to what we normally produce, copying the condensing unit turned out to be a complete redesign. Third, their air handler performance was so low that we had to add a lot of cost to the condensing units to get the system ratings we needed. In my opinion, these problems should have been resolved by upper management before the team was ever assembled. The team assigned to complete the task was doomed from the beginning. The marketing representative had no interpersonal skills. Further, the figures he used to justify the project were obviously impossible, which caused the other members of the team not to trust him. It was a known fact that manufacturing didn’t want to produce this product, so their representative had to fight the battle on two fronts (project team and his department). The timeline for the project was so short that the development engineer (me) didn’t have time to develop the units properly and apply the least expensive components. The design was so expensive that the accounting representative wanted to cancel the project. Nevertheless, the project was finally released, but our annual sales volumes are so low that the company considers dropping that product line every year 10 16. I was elected by my manager to lead a team to improve a business process (accounting). Could not get anyone to share ideas (open up). Morale was low so I eventually gave up and so did the others. This “team” eventually dissolved. The accounting process is still a mess. 17. Last project meeting! Everyone had their own ideas of what the method should be and refused to allow other voices to be heard. They were the “experts” and I was just the facilitator so I should take their word as gospel. They actually voted on the best method without investigating other viable options. (Of course their way is the wrong way!) 18. The worst project experience was in an machinist environment, when we had a new manager take over. He kept saying we are a team, but the atmosphere and the way he treated and treats people was not anything close to a team atmosphere. 19. 1 engineer supporting an 80 person production team in high volume manufacturing environment, no support, no strategy other than keep the equipment running at all times, and on-call 24 hours/day, 7 days/week 20. Warhead development. This team was haphazardly put together from a team that had little to no experience in tactical nuclear operations. The project failed due to the project staff not supporting and listening the guys that were trained to assembly and fire this weapon properly. These two completely different operations were linked to teamwork and mutual interest by understanding what was required of the team 21. My current assignment on [name withheld]. Project engineering is located in [ ] while the rest of the division is located in [ ]. The collaboration between engineering and everybody else is very poor. 11 10. The two things that I have seen to be key to effective teamwork are buy-in to the group’s goal, which makes people take the team seriously, and mutual respect for the other’s responsibilities as they relate to the team’s goals. 11. Mutual respect between all members of the team, openness, and honesty. 12. Willingness of each member to let go of individual credit to benefit the team and team-based rewards to reinforce this willingness.; Diversity of knowledge, approach, etc. and conflict resolution skills to constructively use this diversity to fuel more creative solutions; Workable group problem solving and decision making processes 13. Open-mindedness, creative thinking, respect for other team members, participation, clearly defined problem statement, good cross-functional skill set, and complete understanding of what measurements of success are for the problem at hand. 14. Teams are effective when at least some on the team have a passion for what the team is working toward. This tends to be contagious and brings about enthusiasm and commitment from all on the team. The art is in making everyone feel like what they have to contribute is needed and valued. 15. The goal must be clearly understood by all team members. Also, team members should be carefully based on their skills and personality. Effective communication is also key. 16. I think a lot has to do with the personalities and values of the members of the team. Some people naturally work better together. 17. an effective project manager; a schedule that is known by all on the team, and is kept up-to-date; team meetings that stick to the agenda and to not lag on unnecessarily; people who are ready to contribute their fair share of work; people who are cooperative in nature 18. a common method for communication, so that there is less mis-communication 19. First and foremost, all members must be proficient at the skill sets for which they were selected. These skill sets provide the basic tools the team will need to complete the project. Second, each team member must respect the skills of the other team members. All members must trust that decisions made by other members are in the best interest of both the project and the company. Third, the team should have the time and resources necessary to complete the task properly. In addition to reducing stress, the team will have the satisfaction of knowing (in the end) that the project was a success. Finally, the team must be empowered by upper management to make the important decisions that affect the project. This will require upper management support, without micro-managing 20. Same goal. Sense that all will be rewarded if successful. 21. Open-mindedness. Willingness to recognize other points of view. Respect for various backgrounds represented. Team bonding opportunities. A certain level of fun 22. Shared vision, values and work ethics; good communication, strategy, ability to recognize strengths of team members and use those strengths to the best advantage of the project 23. Clear objectives, duties, responsibilities and the desired outcome. 24. Communication and Respect for your team. They are team for a reason. 14 25. When the entire team has an open mind and a willingness to change their ideas to incorporate other persons ideas or possibly scrap their own idea in favor of another persons idea. 15 Engineers’ Team Working Styles and Preferences 1. With few exceptions I think engineers or technologists would rather work in teams if the project and the team have been set properly. The major barriers for engineers to work in teams are when their responsibilities and deliverables are not clear enough, the project has not well defined goals and milestones and the team is understaffed 2. A poll of engineers and technologists would likely reveal that technical people claim to enjoy working alone on projects. However, I believe that when team dynamics are good and the proper coaching is made available, most technical people will enjoy working on teams. Major barriers to getting technical people to work with each other include: a. Pride - the stereotypical engineer possesses large amounts of personal pride with respect to their abilities (both technical and non-technical). Many A-type personalities often migrate into the technical fields. These folks are typically "my way or the highway" types that refuse to submit to the team concept. The competitiveness of the A-type personality is good, but it needs to be focused upon the true competition - not upon the other members of their team. b. Multitasking - in most of the engineering organizations that I have been associated with, the large majority of technical people are often juggling an excessively large number of projects, tasks, and functions. While multitasking is necessary and beneficial in many cases, excessive multitasking will preclude the individual from making any of their deadlines. Heavy multitaskers spend an inordinate amount of time in the "starting" and "stopping" modes as they move between project to project. 3. I think that today’s engineers and technologists must be able to work in teams or get left behind. Perception that a project is not important or will not promote their careers 4. In general, I would say most engineers/technologists like to work alone – not because they are data-crunchers but because teamwork requires an amount of trust that each member will perform his/her duty error-free. Few classes in engineering/technology require working on teams, so engineers/technologists are “trained” in effective teamwork. As stated above, the trust factor (or lack thereof) is a major barrier to working in a team. Another barrier is direction and goals. With several engineers, the team may lose track of the goal and simply come up with several scenarios rather than solving the problem. 5. I believe that most engineers and technologists generally like to work alone. The major barriers to be over come to get people to work as a team, is keeping an open mind to other ideas. A different perspective on a problem might just solve it. 6. Engineers like to work alone, of course the type of engineer seems to make a difference. Compensation for a engineers is on a individual basis and consequently the more on engineer knows the more valuable they are, i.e. no sharing of information. 7. They would rather work alone. The barrier is that engineers always think they have the best idea. And this nothing new, a lot of people are that way. But engineers come up with interesting arguments and data to support their idea and make it doubly tough to get anything accomplished. Engineers also hate process and documentation. We all want to be cowboys and not do a complete job. A team forces the complete job 16 Engineers’ Barriers Teaming with Non-Engineers 1. Communication is one of the major barriers. Engineers should eliminate the jargon they use so that the non-engineers will have a better understanding. 2. Possibly egos on the part of the engineers and distrust or skepticism on the part of the non-engineer. 3. One possible barrier to getting engineers to work well with non-engineers is their thought processes. Engineers tend to be very analytical and structured in their thought process. This can appear to very course to some people and cause personality conflicts. 4. Almost every engineer that I know prefers to work alone. First, most engineering students are exceptionally smart and have never needed assistance to complete a difficult assignment. Second, most engineering colleges do not emphasize the importance of teamwork in a corporate setting. Rather, they pit engineering students against each other for grades, while emphasizing the damage that can occur when engineers make mistakes (Tacoma Narrows Bridge, Hyatt Regency Walkway, Space Shuttle, etc.). Furthermore, all engineering colleges have strict policies regarding academic dishonesty that (intentionally or not) discourage students from working together. The way we are taught how to do engineering makes us extremely cautious. Every engineer I know double checks any numbers that he / she did not personally prepare – even when these numbers are prepared by other engineers. All of us know that if something goes wrong, the blame eventually ends up in engineering – whether it really was our fault or not. To keep from getting blamed for other peoples’ mistakes, many of us would rather do all of the work ourselves. At least that way, if we get in trouble, we know it really was our fault. 5. I think that most engineers/technologist do ultimately like to work in teams. I believe that they are smart enough to understand that working in teams is the most effective and reasonable way to succeed in large, important projects. However, it basically comes down to the individual's personality. This would be the major barrier to getting an engineer/technologist to work on a team -- that it is simply not congruent with their personality. The other major barrier would be the engineer/technologist's negative preconceptions based upon past experience working in teams 6. The major barrier I see is a language barrier because engineers are more technical- minded people and have a difficult time communicating with someone that isn’t from their same technical background. Also, engineers are more prone to suffer from “analysis paralysis” whcih can hinder them from being able to make an executive decision on some things. 7. It’s the same barrier that prevents non-believers from accepting the forgiveness of Christ. One must first recognize that one is lacking in some way, that forgiveness is needed (no proselytizing intended). Engineers want desperately to have the answers. All you have to do to send an engineer into ecstasy is present him/her with a problem to solve. Admitting to himself that he needs the other members of a team is emotionally repugnant. 8. A lot of the barriers seem to begin with the non-engineer. At our facility, I see a lot of non-technical employees in teams quickly ignoring anything an engineer says because they believe it to be over their heads, whether it actually was or not. 19 Subsequently, the engineers take this behavior as an indication that the non-technical people aren’t interested in solving the problem and are just leaving it up to the engineers to “fix everything.” 9. Major barriers are: a. Communication (too many techno words, acroynyms, etc.). Also, poor listening skills. b. Understand that non engineers have good ideas and can solve problems too. Having an engineering degree does not mean others do not “know” engineering c. Getting them to recognize others’ abilities and knowledge. Keeping them open-minded. d. Getting the non-engineers to not feel threatened by the engineer and to appreciate our different viewpoint. Communication (speaking different languages). 10. The communication level might be a little higher with the engineer and him breaking that barrier might be tough 11. Focus is primarily on the technical issues at hand, not the big picture; Failure to understand the social aspect of working together; Willingness to leave the comfort of the computer and desk 12. Sometimes you run into an engineer that has the same attitude as a doctor, they know it best and a non-engineer can’t possibly have a good idea. 13. First, the engineer has to trust the others in the team. Second, since most engineers have poor interpersonal skills, they must be able to communicate in a manner that isn’t offensive to other members of the group. Most engineers are realists. They are neither optimistic nor pessimistic – they just tell the facts. However, many times, people in a corporate setting want news to be reported optimistically. They don’t want to hear, “We can’t complete the project by the deadline with our current resource level.” They want to hear, “We will need to triple our R&D staff and apply them all to this project so we can meet our deadline.” The result is the same, but the delivery is different. Third, engineers need to know about the functions, goals, and objectives of the other departments. That way, they can better meet the overall requirements of the project. 14. The major barriers would be a. the engineer does not understand the person's role or possible contributions b. the engineer is not comfortable working with people that are not in the same field (doesn't understand their jargon, etc.) The engineer needs to understand and see the positive contributions that the non- engineer team members will bring. In my organization I am considered 'non- technical' because I am not a programmer or DBA, however I have usually felt welcomed on teams because the 'technical' people do not necessarily feel comfortable with the tasks that I would be performing, but they understand the importance of them. 15. Communicating in a language understood by both. 16. Communication barriers. Engineers a lot of times have problems addressing their audience properly. Speaking at the level of your audience. 20 17. Also, an engineer has to have respect for the contributions of everyone on the team, even if that contribution is non-technical. 18. Engineers have a tendency to become bored explaining what they are doing on a task, because they seem to have either a hard time expressing themselves in simpler terms, or they do not want to explain. 19. Understanding the similarities and respecting the differences 20. The major barriers in this case would be when the engineers are not provided with enough information and explanation of the perspectives, views, methods and “language” of the non-engineers. 21. The major barrier is recognition and acceptance that others can do certain things better than you. 22. The major barrier here is communication. Since engineers tend to be more analytical and task-oriented, it may be difficult for them to communicate effectively with non- engineers. The non-engineers may be more interested in the people aspect, which may frustrate the more task-oriented engineers 23. Aside from the barriers listed above, I would only state that non-technical people often lack the understanding of "how and why things work" (especially with regard to a company's technical products). Engineers working on a cross-disciplinary team involving non-engineers must realize and accept that some of the non-engineering job functions (marketing, project management, accounting, information systems, etc.) are essential to the success of the project and that the people executing these functions should have business insight that will be critical to the success of the team. At the same time, I do believe that the best business people are engineers who have made the investment to learn and fully understand the financial, economic, and marketing issues facing the business (that's why I'm pursuing the MSETM degree. 24. One major barrier is non-technical people will not be able to understand the abstract concept or terminology that technical people use to communicate ideas. 21