The Development Process as a Complex and Interdisciplinary Team Based Challenge

The book "New Technologies - Trends, Innovations and Research" presents contributions made by researchers from the entire world and from some modern fields of technology, serving as a valuable tool for scientists, researchers, graduate students and professionals. Some practical applications in particular areas are presented, offering the capability to solve problems resulted from economic needs and to perform specific functions. The book will make possible for scientists and engineers to get familiar with the ideas from researchers from some modern fields of activity. It will provide interesting examples of practical applications of knowledge, assist in the designing process, as well as bring changes to their research areas. A collection of techniques, that combine scientific resources, is provided to make necessary products with the desired quality criteria. Strong mathematical and scientific concepts were used in the applications. They meet the requirements of utility, usability and safety. Technological applications presented in the book have appropriate functions and they may be exploited with competitive advantages. The book has 17 chapters, covering the following subjects: manufacturing technologies, nanotechnologies, robotics, telecommunications, physics, dental medical technologies, smart homes, speech technologies, agriculture technologies management. following:


Introduction
When looking at current development processes of technical products, general trends can be observed. These trends do not only influence the development process itself, but also make specific demands on the developers. These trends are for example the reduction of development times due to the increasing pressure to put products on the marked before the competitor, the globalization of the market and the partially high degree of specialization of the enterprises while productcomplexity increases.
Hence interdisciplinary knowledge and experience are fundamental requirements for efficient and effective work in the development project. Aside from technical competence special social skills are an important requirement for the development team.
Therefore it is increasingly important to come back to the collaboration with experts or specialized organizations in innovation projects. This means -especially for small and medium enterprises (SMEs) -that one has to leave his own company and organization in order to fully use the know-how of others. Quite often, the cooperation with research facilities such as universities is being sought. This chapter will focus on the collaboration of the participating parties during the development process of technical products. Special emphasis will be put on design-projects while long-term research cooperation is not subject of this publication.
Due to the authors' experience with research and development projects realized at a technical university, the statements made in this chapter hold universal validity when applied to the collaboration of SMEs and research institutions. This also applies to development and redesign projects ordered by SMEs, especially when these do not have much experience with research-and development processes as well as the cooperation with research facilities. www.intechopen.com

Current state
The classic methods of development are widely spread and have -depending on discipline, corporate culture and other influencing factors -adapted to the above listed, changed requirements. Thereby, not only problem-oriented analytic and abstracting methods, which need to be followed step by step, but also creative-synthetic methods are applied.
As a matter of principle, a methodological procedure should not leave the finding of solutions to pure luck but consider and assess all possible options.
A methodic-systematic approach will help to reach the goal of a development-and design process more efficiently. Furthermore, it will ensure that the finished product meets all the user's expectations.
Some methods are universally applicable while others are limited to the individual phases of the project.
Exemplarily some methods like ABC-analysis, value-analysis, TRIZ, SWOT-Analysis, morphological matrix, various creativity techniques, the abstraction and compilation of function and effect structures, basic design rules, principles and guidelines are mentioned.
In project management (as well as product development) methods like simultaneous or concurrent engineering and systems engineering are well established and successfully used.
Especially SMEs quite often act as producers and sellers, but not so much as developers of products. In many cases the limited resources and the focus on production rather than development does not leave the possibility to work analytically and methodically on new product development. This is why methods of development quite often can't be exploited to their full potential or sometimes are not beneficial at all. Due to the limited manpower it is sometimes impossible for SMEs to analyze competing products and markets with sufficient depth in order to take over good existing solutions. Quite often the SME has to rely on solutions that are customary within the industry, or even the company. These solutions may be well understood, but examined closely they may not represent the optimal solution.
When faced with a concrete problem, one tends to intuitively make the first steps before getting in touch with a professional development team, such as the institute of a technical university. Consequently no performance specifications are defined, but one starts to think in solutions right away. (I.e. a few, specific solutions because a holistic view of the problem with all its possibilities may not be possible).
It can be witnessed very often that the early phases of the development projects are neglected, don't receive sufficient resources (time, money, degrees of freedom) or that there is a significant lack of open-mindedness towards new, untypical approaches.  (Ehrlenspiel et al., 2007) shows very well how low the relative effort for changes in an early stage is compared to later in the lifecycle of a product. The development process has enormous influence on the overall costs, but in this phase just a small fraction is invested.
www.intechopen.com Even though the early development phases have a significant influence on the quality and the costs of the final product, they typically do not receive enough attention and resources; this can be seen in Fig. 2.   Fig. 3 (Reinhart et al, 1996) shows how costs for fault correction increase, depending on the state of development. The graph also represents how serious consequences can be when know-how from additional contributors is included too late in the design process. Fig. 3. "Rule of ten" of the costs for fault correction over time (cp.: Reinhart et al., 1996) For several decades methods of development and design have tried to lead away from an isolated technical design process towards a systematic approach for the development of technical products.
The acceptance standard VDI 2221 -Methods for the development and design of technical systems and products -serves as a guideline during the development process and divides it into four phases: Definition of the task, Finding a rough concept, designing and elaboration of the actual solution. These four phases contain seven design states, each generating its own work result. While going through this process a flexible advancement and iterative steps back and forth into different design phases are recommended. This can be helpful to answer interdisciplinary questions and requires working in interdisciplinary teams. Aside from professional competence, the employee and its socials skills are of great importance. In order to successfully go through a project it is therefore necessary to understand the terminology and problems/objectives of other disciplines. Only then an ideal solution according to all aspects -the best compromise -can be achieved.
A lack of subject-specific competence and poor communication can easily lead to wrong estimates on the potential and the required effort of problems that cannot be solved with business-internal knowledge. It is imperative to not only include specialists into the team, but also generalists who keep an overview. The weighting of the individual disciplines during the distribution of resources and decisions-making is of great importance.

www.intechopen.com
The Development Process as a Complex and Interdisciplinary Team Based Challenge 331 Fig. 4. systematic process model (cp.: VDI 2221, 19933) The VDI 2221 refers to the systematic-technical execution of the individual phases (i.e. lifecycle phases of the system) where no iterations on the same level are intended. A well-structured approach has of course been established in many technical disciplines. If a company that has been active in its branch of trade for many years decides to design a new product it will consult the same employees and departments as usual. The whole process will occur just like a routine. Clear goals and rules exist, the employees are used to working with each other; they understand their "language" and their way of posing a problem quite well.
The situation tends to be entirely different in a newly compiled team, like for example when SMEs get in touch with a research facility for the first time. Here it is necessary to include all participating parties and also the user into the development process. This, for example, is explained in (Pugh, 1990) but often hard to put into practice. However, this is contradictory to the general recommendation to change only one element in the system "Problememployee-method". This means that no new problem should be solved with new employees or a new method (e.g. simulation tool) should not be validated by solving a new problem. The following chapters will refer to these special constellations on several occasions.
To get a better overview about the position of the development steps we are focusing on the three phases of the innovation process according to (Thom, 1980). The development process is situated mostly in the phases "idea acceptance" and "idea realization".
For the following considerations we would like to define three stakeholder groups, which act in the phases we have defined before: The customer or user: He uses the product or technical system which has to be designed. The identification and consequently the fulfillment of the customer request are the goal of a successful business.  Thom, 1980, p.53) Very often an organization (or an organizational unit) is not capable of developing a product, which entirely fulfills the customer requirements without external support. The organization then turns into an ordering party, which transfers a certain part of the task to a development contractor. The development contractor hereby takes over a certain part of the development effort. In this context some general requirements of the development process shall be listed:


Branch-specific solutions, resulting from the historic development which represents a local optimum already exist. At the same time better solutions may be available in other industrial sectors and even considered standards but they are not noticed.  The strong specialization of many technical fields makes it impossible to keep an overview of all the branches and technical solutions that appeared in them. On the other hand, problems or rather technical systems and products are getting more complex and interdisciplinary. This results in the necessity to link various disciplines which results in new fields such as mechatronics and domotronics.  Development cycles are getting shorter and shorter. Therefore concurrent engineering in different special fields and disciplines is necessary.  The available knowledge is growing constantly. This makes it increasingly hard to keep a significant part of this knowledge inside the own company. It is therefore important and inevitable to include external know-how and facilities into the development process. www.intechopen.com The Development Process as a Complex and Interdisciplinary Team Based Challenge 333  Every company and every individual only has a very limited overview. Every employee is used to apply certain solutions depending on his educational background or work experience. For example: A mechanical engineer will most likely solve a problem with a mechanical solution while an electric, electronic, hydraulic or mechatronic solution might achieve better functionality.  There is enormous potential for new products as a result of interdisciplinary tasks. Examples are medical engineering and veterinary telematics. The number of possible solutions is restricted by the walls of impossibility. The position and stiffness (resistance against moving) of these walls is defined by:  the performance specifications  personal assessment  experience with specific solutions  personal preferences of the participating employees This means that hard-and soft-facts determine the restrictions represented by the "walls of impossibility".
If knowledge and ideas of all the contributing parties are fully exploited, the number of solutions for seemingly simple functions increases enormously. But this only applies when certain open-mindedness is kept during this project phase. The probability that very good solutions are found is correspondingly higher. In order to discover and take advantage of all these solutions the following prerequisites are necessary: -Involvement of all participating parties (user -ordering party-development contractor) -Openness towards untypical or unusual solutions -The customer request has to be determined and represented correctly. For example: Representing the customer request by playing a question-answer-game and thereby generating specification requirements. -To verify development steps concrete solutions need to be presented to the customer in early design phases. -Willingness to invest a lot of resources in an early project phase. (Exploration-and ideafinding phase). -Willingness to question established solutions -Willingness to question the validity of the specifications in the customer requirements.
The models mentioned above as well as (Eppinger and Ulrich 2003) put their focus mostly on the actual product itself and see all sub-tasks directly linked to a product (and its marketing, manufacturing, customers,…).
In cases where a development partner joins the project in a later stage, the understanding of customer requirements may not be enough.

But the following problems may occur
Some specific examples and problems that frequently occur shall be listed below. It is important to note, that the terms "customer" and "contractor" may also apply to organizational units inside the company and only describe how their services are related.
The in VDI 2221 mentioned task is quite often already a modified version of the original task.
The "actual problem" is the fulfillment of the customer requests.
But also in the case of in-company relationships of services like it can be found in contracted developments this means that the customer/user of the product/service shall always be seen as (part of) the ordering party and never be excluded completely from the design process. If the task itself is not defined correctly the customer requests will not be fulfilled either.


Frequently the actual problems of the customer have already been interpreted wrong and translated into faulty technical functions. The abstraction of the problem (i.e. the reduction of the system to the basic level of functions) enables/alleviates the understanding of the problem, opens the horizon of options and facilitates the structured search for solutions.
To cite an example the application of TRIZ shall be mentioned.  During the early stages of a project it is very important to focus all actions and communication on the definition of the actual problem and not on concrete solutions. The discretization of predefined solutions will only exclude other possibilities. Sometimes a solution that has been carried out elsewhere is examined and discarded right away even though its principle would just have needed minor modification in order to function properly.  None of the parties (user, ordering party and contractor) should select solution principles or carry them out practically at a too early design phase (Avoid premature decision making).  The customer requirements are not wrong but kept too general. They contain simplifications and assumptions, which don't describe the problem to the contractor in www.intechopen.com The Development Process as a Complex and Interdisciplinary Team Based Challenge 335 enough detail. (In this case the task can be defined more precisely if the contractor checks back with the ordering party)  The customer request contains requirements with too much detail in a way that already suggestions for solutions or concepts created by the ordering party were integrated. In the worst case and therefore unjustified, this means that variations of solutions (that might have been successful) have been removed from the pool of ideas. A problem that frequently occurs is the presentation of solutions simultaneous to the presentation of the actual problem when the contract is placed.  The contractor is consulted and included too late into the development process. This means that -according to Fig. 8 -the transfer of the task occurs too close to the introduction of the product to the market. In this case some solutions (and maybe even the best one) might already have been eliminated by the customer or they have never been in the pool of feasible ideas. Non-sufficient "expert-knowledge" could result in wrong decisions  Places the filter at a wrong position and generates a blind spot.
A typical statement is: "We have already tried this and it didn't work." But, when has it been tried? Maybe the available technologies have changed or improved since.
How was it tried? Maybe the principle of solution has not been adapted correctly to perform well in the actual construction.
Why exactly did it not work? Maybe some details were not taken into account.
What exactly didn't work? Maybe the error is not to be found in the principle but rather the detail design.
 A problem-oriented approach (on the contrary to a product oriented approach which considers the borders of departments and components as interfaces) is necessary. This approach requires interdisciplinary collaboration and communication between departments and participating parties. On the one hand "organizational blindness" helps to build up a routine to handle and improve a system/method/technology but hinders the change to a better system/method/technology. The technical progress or the continuous change of the customer's needs on the market can lead to the replacement of a formerly good solution by an alternative implementing various advantages, for example lower costs or better fulfillment of the customer requirements.  The existing guidelines, schemes and structured advancement-models are essential requirements guiding the development process. However, the structure of the personality of all participating employees and parties plays a crucial role. But quite often, the individual human is neglected. If -for example -technical criticism is interpreted as a personal issue the improvement of a solution is threatened. This applies to the ordering party, which already has a first solution in mind when entering the design process, the contractor who has to defend his solution as well as to the user who may or may not consider his requirements fulfilled. A factual, objective and problemoriented communication is therefore very important.  A team often requires specialists and generalists. The well-structured specialist with his focused expert-knowledge works on details that can be dispatched in a straight-forward way. The "chaotic generalist" can be seen as the motor that pushes the whole project onward and is responsible for the distribution of resources and setting the goals. Each individual will lean towards one or the other role depending on their personality.
The necessary qualities of the developer as an "individual human being" are discussed explicitly in (Pahl, 1995) but only with regard to the constructing engineer: A good constructing engineer is capable of transferring factual knowledge (facts, experience, principles) and methodological knowledge (the handling of a complex, simultaneous course of events) to the current problem/situation by applying his personal abilities. This requires intelligence (meaning the ability to understand and judge = analytical step-by-step thinking) and creativity (synthetic and intuitive thinking in order to discover new, so far unknown interrelationships). Hence, the ability to switch flexibly between analysis and synthesis is absolutely necessary. It is called heuristic intelligence, and enables the effortless finding of good solutions in little time. It usually results in a solution that represents a compromise of quality and effort.

Therefore
The problems listed in section 3 can often be observed throughout the development process.
The following paragraph will present three principles and methods that can help to lead the innovations process to a successful finish.
The result of a technical development process is always a compromise. It is of major importance to compile a catalog of requirements, criterions and weighting-factors which are constantly verified throughout the process in order to achieve the best possible compromise.
Iterative loops under the comprehension of the user and the ordering party are required.

The paradigm of open innovation
The before mentioned aspects refer to the activity inside the development-funnel. This funnel is shown once more below: www.intechopen.com The Development Process as a Complex and Interdisciplinary Team Based Challenge 337 Fig. 9. The development funnel (cp.: Wheelwright, Clark, 1992, p.112) Even though most pictures of development-funnels refer to the design process of a whole product, they can also be applied very well to the search for details, specific parts or subfunctions. Looking at these sub-functions it can clearly be seen how the number of possible solutions decreases dramatically. Ideally, the criteria, which lead to the systematic elimination of possibilities are defined at a very early stage of the project but kept flexible throughout its course. In reality, many restrictions are unknown when the project is launched and will only be discovered during later project phases, maybe because some properties of solutions have been neglected (for example "harmful substances") prior to realization. But also the outer circumstances might have changed in the meantime because of the dynamics of the market (competitor releases a better product) causing the walls of the development-funnel to remain flexible throughout the design process. The following graphic shows how an incomplete collection of solutions at project start may not even contain the optimal solution. Only during a later project phase (and therefore much too late) another study considering possibilities outside the search-field that was defined by the ordering party reveals the best solution. Including new partners or employees for example can lead to a sudden, drastic increase in ideas for solutions. The image below shows, how the ideal solution can now be found among the ones that have been discarded or neglected before. Fig. 11. ideal solution found among the ones that have been discarded or neglected before While the image above refers to the development of sub-functions it should be seen as a microscopic view of the "Open Innovation"-approach.
Nowadays it is very unlikely that all the knowledge necessary for the development of a highly innovative product can be provided by one company only ("closed innovation").
According to (Chesbrough, 2006, p.177), the classical model of "closed innovation" is applied when product and business ideas are mostly developed inside the company's own R&D-departments. The "Open Innovation" paradigm -also affected by the changed knowledge landscape in the beginning of the twenty-first century -merges external ideas and knowledge with the internal R&D. It raises external ideas -as well as external paths to markets -to the same level as internal ones during the era of closed innovation.
The two different models can be combined in Figure 12 showing the development-funnel and the exchange of ideas across company boundaries: It describes the enterprises´ changed behavior in dealing with intellectual property, ideas in general and the opportunities of the nowadays widespread distribution of useful knowledge.

Closed Innovation Principles Open Innovation Principles
The smart people in the field work for us.
Not all the smart people in the field work for us. We need to work with smart people inside and outside the company. To profit from R&D, we must discover it, develop it, and ship it ourselves.
External R&D can create significant value: internal R&D is needed to claim some portion of that value. If we discover it ourselves, we will get it to the market first.
We don't have to originate the research to profit from it. The company that gets an innovation to the market first will win.
Building a better business model is better than getting to the market first. If we create the most and the best ideas in the industry, we will win. I f w e m a k e t h e b e s t u s e o f i n t e r n a l a n d external ideas, we will win. We should control our IP, so that our competitors don't profit from our ideas.
We should profit from others' use of our IP, and we should buy others' IP whenever it advances our business model.

Dynamic performance specifications
The performance specifications represent the concrete definition of the ordering party's requirements for the product and services delivered by the contractor. Therein the properties are described qualitatively and/or quantitatively. The contractor on the other hand defines his duties in his own specification sheet and thereby decides how he wants to fulfill the performance specifications.
This approach may but reveal several problems:


The compilation of the performance specifications is a "translation" of the customer requirements. But if these are not defined completely and unmistakably even a total fulfillment of the criteria will not lead to total customer satisfaction.  If the contractor itself is an ordering party and not the user, the before mentioned gains twice the importance. First the customer requirements have to be translated by the first ordering party and then again by the contractor. It is obvious, that the chances are very high that the performance specifications do not match the customer requirements. The problem has already been discussed before.  Especially in long-term projects a modification of the general requirements can be useful because of the advancement of technological standards. If, for example, a mechanical solution has been agreed on in the performance specifications but a new electronic solution appears on the market, then this new advantageous option cannot be used. Apart from that, also preferences of the user can change during the course of the project. But when the properties of the product are defined rigidly at the beginning of the project this condition cannot be considered.
Therefore, dynamic performance specifications are beneficial.
 Due to multiple translations of the customer requirements "translation errors" can occur. Hence it is recommendable to match the requirements among all participating parties (i.e. user, ordering party and contractor). The earlier it is realized that different ideas of the result exist within the whole development team, the easier it is to adapt the performance specifications, redefine the task and continue effectively and efficiently with the development process.  At this point it shall be mentioned that VDI 2221 describes the "early iterations under implementation of the user" but these are not necessarily required. One must also note that the systems technology mentioned in chapter 2 does also not imply iterations in the same development phase.
The complete understanding of the customer requirements is a prerequisite for a correct translation. This is why the contractor needs to be able to see through the eyes of the user as well as the ordering party. This means that the problem cannot only be approached from an engineer's point of view. Here, one should deliberately take a step back. Approaching the ordering party in order to discuss whether to redefine the customer requirements (because the ordering party may already have filtered the requirements wrongly) demands appropriate social skills and a fine intuition. The influence of individual human properties has already been mentioned chapter 3.
If the development process is started by only reading the performance specifications, it is sometimes not unmistakably noticeable whether the customer prefers a simple, a clean, a smart, or a "different" solution, if he prefers a certain technology or a specific way of solving the problem. This matter will be discussed in greater detail below, in section 4.3 dealing with the "one step back approach".
"Problem solved" can mean something different to each party. The producer's considers "just as good as absolutely necessary" the cheapest and therefore most adequate solution for serial production. From the customers point of view this is the fulfillment of his requirements. The developer on the other hand considers a problem "solved" if he knows how it can be solved theoretically, whereas the technology-addicted engineer seeks the "best possible" solution -a prototype with features exceeding the ones manifested in the performance specifications.


The ways of thinking and the language of the participating parties, fields and branches can differ significantly. This does not only apply to the level of user -ordering partydevelopment contractor, but also within the individual fields themselves. This does not only apply to specialists or expert engineers from different departments and development divisions, but also employees from the fields of calculations, construction, design, assembly, cost accounting, controlling, sales, etc. During an early project stage play-models or CAD-models can help reveal differences in the understanding of the problem. They can also make non-experts find out whether all parties follow the same goal and the predicted result meets the expectations.  Aside from the above mentioned arguments -such as the appearance of a new technology -other possibilities to fulfill the functionality of the product might emerge and favor a modification of the performance specifications during the development process. As the project advances, one gains an increasingly clearer view on the crucial influencing factors. Problems often occur when a theoretical solution is put into practice. These problems can of course only be realized in the current work step. But the first results of the projects might also reveal that initial requirements increasingly lose importance while others demand more emphasis. Some requirements might even emerge all of a sudden and therefore have to be included retrospectively into the performance specifications. This represents the moving of walls in the developmentfunnel model. An approach like that implies shifting the emphasis and resources which could be the consulting of further experts belonging to other special fields, or the proof of suitability of a new material in a practical experiment.  The mentioned course of action consequently demands the development of multiple variations and proper documentation. Multiple re-evaluations and iterations may suddenly make formerly discarded variants relevant again. Not only the approach and the successful solution, but also previous, discarded ideas have to be documented. If a variant is discarded, the decision has to be backed by arguments. Hereby the property, which leads to the conclusion that the variant is unsuitable, has to be described. Maybe exactly this property might hold great potential to apply this solution to another project.  All participating parties need to be included in the important iterations that are necessary during the development process. These iterations should begin with the definition of the task. Consequently the performance specifications should not only be adapted when a change in the course of the project requires doing so. Questioning the newly assessed and required properties is not only allowed but recommended. The compilation of a flexible and therefore "dynamic" list of performance specifications is encouraged and should be supported by the authorities.


All the above mentioned points are motivated by a result-oriented operation method, but imply the involvement of all parties (user, ordering party, development contractor). General definitions should or must be questioned. This though, should not lead to getting stuck in the definition-phase, but on the contrary help to fulfill the customer requirements unerringly and under the best possible exploitation of resources. Apart from the personal willingness to act flexibly a trusted relationship between all the participants is necessary. A goal-oriented course of action may ask to leave the structures defined by the contract. It is necessary to be constantly focused on "what we actually want" to reach the goal together by optimally fulfilling the customer requirements.

One step back approach
One conclusion that can be drawn based on the statements mentioned above, is the idea to question the task itself. Most of the times it is a good investment, to carefully scrutinize the restrictions listed in the performance specifications. These lists often do not represent what the customer wants, but what the ordering party believes. Quite often they already contain hints for concrete solutions and therefore already restrict the development process. Even though direct communication between the contractor and the user is often impossible it is necessary to interpret and look behind the performance specifications to try and find out the initial customer requirements, which determine the functions and features of the product.
The question "In what way is this requirement beneficial to the customer/user?" is of major importance and should be kept in mind whenever the performance specifications are discussed. Ideally the handover of the project takes place at a very early project stage, in which the change of implicitly or explicitly formulated concepts of solutions can be changed with ease and without financial consequences. According to the authors' experience, the opportunities emerging from such an open-minded consideration of the actual task in this project-phase surpass the possible risks by far.
But especially contracted developments, where the ordering party looks for external support only long time after concept development has started, this is incomparably more difficult.
Costs and, above all, personal engagement have already been invested in one particular solution. It is therefore especially hard to leave the path that has been chosen. In this case it www.intechopen.com The Development Process as a Complex and Interdisciplinary Team Based Challenge 343 mostly depends on the human and personal factors of the development team whether switching to an objectively better solution in a later project phase appears realistic or not.

In practical experience there are several resisting factors against "the one step back"
Due to the focus on the tight schedule and the enormous pressure to quickly introduce a product to the market in order to achieve high revenues, the willingness to take one step back is usually rather limited. Here, the problem of including a development contractor too late becomes evident. Quite often contractor's task in the development is limited to a certain detail, like for example choosing the correct types of bolts, choosing materials and optimizing their strength.
Questioning general, standardized and established solutions usually encounters harsh criticism, even though the continuous advancement of technology itself might have made new solutions favorable in the meantime. Here, investing time and resources at an early project stage will surely pay off regarding the quality of the solution while at the same time reducing the overall effort. One can find this recommendation repeatedly in literature such as (Altshuler, 1986) where the research for patents their analysis is clearly stated as the first step in the development process.
Breaking into the new topic, getting to know and analyzing existing solutions as well as the problem itself at the beginning of the project can be called "exploration-and idea-finding phase". This phase is located in the wide part of the neck of the development-funnel. It can also be beneficial to look into other branches. Adapted versions of solutions may represent goal-oriented and effective solutions for one's own regarded problem.
Two examples for methods of development used in software engineering are "test driven development" and "agile development".
"Test driven development" divides the development process of the whole product into many subsystems. For each of these subsystems a test procedure is defined. The development of every individual cycle is repeated until all subsystems pass the test.
"Agile (software) development" requires the creation of agile principles and agile values. Based on these values agile methods are derived.
Agile values are:  Individuals and interactions are considered more important than processes and tools.  Well running software is more important than extensive documentation.  Collaboration with the customer is more important than the negotiation of the contract.  Reacting to sudden changes is more important than following a strict plan.
Whoever is developing a solution will be proud of it and will defend it. Discarding or modifying this solution will of course encounter resistance from the developer/creator. This especially applies when the ordering party immediately presents "their" idea to the developing party only asking the contractor to put the idea into practice without questioning it.
A new technology, for example the emergence of a new manufacturing method, is capable of moving the "walls of impossibility" and therefore increasing the number of possible solutions drastically. But the emergence of a new technology also holds certain risks. Apart from possibly high costs the lack of long-term experience are both factors against the use of a new technology. Objective judgment of the opportunities and threats is hence necessary.

Conclusion
Pahl (Pahl, 1995) states that methods of development are tools introduced by methodological approaches, as the name already suggests. It is not enough anymore to be a "pure technician". Pahl also states that increasing experience enables the engineer to automatically apply the development methodology and therefore put more capacity into the actual problem solving. In general, methods should only be followed to a certain, reasonable extent but not blindly.
Open Innovation should also move into the classic branches on the market. Well established processes usually work inside a company or branch. Due to the above described modified general requirements the implementation of external partners should not be reduced to sudden evens like "consulting days" or the outsourcing of individual development tasks. Thinking "outside the box" should be a permanent, continuous process.
If -for whatever reason -it is not possible to continuously look beyond the boundaries of one's own company or organizational unit, it should at least become a habit during the early stages of product development. The developers should pay maximum attention to the opening of the development-funnel at the beginning of the project in order to include as many solutions as possible.
Quite often the assignment of task already contains "translation errors" when transferred from the "manufacturer -ordering party" to the "development contractor". Recognizing and correcting these errors is absolutely vital in order to broaden the horizon of possible solutions and finding the best one of them.
This article is an open invitation to advance to a more abstract level, where even before the start of the actual development time is invested to fully understand the actual problem. Preventing small mistakes in this step can prevent big mistakes in later phases.
Nowadays solutions can be found in other technological fields, which do not match the tools and knowledge of the ordering party. For example, complex purely mechanic solutions might be simplified significantly with the support of, or replacement by electronic components -in many branches this is by now the only way be stay competitive.
In order to avoid a too narrow search field for solutions it can sometimes be necessary to question even very detailed performance specifications. Ask the questions: What is the actual problem of the customer and its requirements? Working with an interdisciplinary team during this phase has been successfully approved.
But when questioning or critically evaluating the suggested solutions of the manufacturerordering party, a subtle feeling and social skills are needed in order to avoid insulting the cooperation partner. If it turns out later, that the originally suggested solution is indeed the www.intechopen.com The Development Process as a Complex and Interdisciplinary Team Based Challenge 345 best possible one, early criticism may be considered unnecessary and misunderstood. Never the less it can be said that high investments at the beginning of the project (i.e. opening the development-funnel) is useful in any case; may it be only to sharpen the view for solutions and concepts outside the well-known company-internal possibilities.
Up to now, the suggested approach has not made it into company-guidelines and there also seems to be a lack of understanding from the persons in charge. Communicating inside an interdisciplinary development team and addressing the needs of the user are not yet part of a standardized development process.
Especially SMEs have very low chances to search an extremely broad field of options to find solutions. To them, it is very difficult to compile interdisciplinary teams. But at least the need for the above mentioned approach should be recognized. Only then better ways to achieve even more satisfying solutions can be found.
In many cases it depends on motivated and dedicated individuals, whether potentials in the approach of development projects can be found and exploited. Depending on the conditions this may lead to a change in the schedule of the project implementing an additional step like critically analyzing the actual functions behind the customer request. This especially applies to contracted developments where many decision might have been made beforehand.
Not everyone may be suitable, but whoever thinks he is capable of leaving the beaten path should be motivated and encouraged to do so -even though it might only be on a small scale.
The job of an engineer or developer is far more then generating technical drawings. A creative, open-minded engineer is nowadays more important than a highly specialized technician working on details isolated from the rest of the team. The properties of a good engineer are certainly properties of his personality, but can also be trained to a certain extent (Pahl, 1995).
The implementation of external resources will in future also capture the traditional disciplines of engineering and its available public processes.
Literature and education have so far mainly focused on the solving of details and problems in a standardized way. The identification, the understanding and consequently the formulation of the actual customer requirements should be addressed to a greater extent in education and in the real economy. It will help to exploit the sheer endless potential of possible solutions and technologies and will allow us to successfully master the challenges of the future. The book "New Technologies -Trends, Innovations and Research" presents contributions made by researchers from the entire world and from some modern fields of technology, serving as a valuable tool for scientists, researchers, graduate students and professionals. Some practical applications in particular areas are presented, offering the capability to solve problems resulted from economic needs and to perform specific functions. The book will make possible for scientists and engineers to get familiar with the ideas from researchers from some modern fields of activity. It will provide interesting examples of practical applications of knowledge, assist in the designing process, as well as bring changes to their research areas. A collection of techniques, that combine scientific resources, is provided to make necessary products with the desired quality criteria. Strong mathematical and scientific concepts were used in the applications. They meet the requirements of utility, usability and safety. Technological applications presented in the book have appropriate functions and they may be exploited with competitive advantages. The book has 17 chapters, covering the following subjects: manufacturing technologies, nanotechnologies, robotics, telecommunications, physics, dental medical technologies, smart homes, speech technologies, agriculture technologies and management.

How to reference
In order to correctly reference this scholarly work, feel free to copy and paste the following: Michael Bader and Mario Fallast (2012). The Development Process as a Complex and Interdisciplinary Team Based Challenge, New Technologies -Trends, Innovations and Research, Prof. Constantin Volosencu (Ed.), ISBN: 978-953-51-0480-3, InTech, Available from: http://www.intechopen.com/books/new-technologies-trendsinnovations-and-research/the-development-process-as-a-complex-and-interdisciplinary-team-based-challenge