If we now accept that the goal of a manufacturing organisation is to make money, and that the time to market of quality products can have a major impact on the scale of the sales to make money, then any technique or way of thinking - such as concurrent engineering - which shortens this product delivery cycle whilst retaining a quality product is therefore a move towards this goal and should be utilised or at the very least, investigated
What Concurrent Engineering requires as a base before it can help move the organisation towards the goal is a team; bearing in mind that we now consider the organisation as a whole rather than as functional units. This will undoubtedly have a great impact upon practising organisations, the way their people interact and relate to one another, and are managed - especially those used to the over-the-wall sequential delivery process.
The importance of the team to concurrent engineering's success cannot be overstated, it is perhaps the hub of the whole philosophy. However, for many companies in the western hemisphere, the concept of working in true teams is at best felt unnatural, and due to a number of factors are not used to working in a team environment, unlike many of their far eastern competitors.
The concept of team must be outlined from the start. For the purposes of clarification, a group is a collection of people or things placed together due to a common element. This is an apt description to describe the functional elements of a company, e.g. engineering, design, finance etc. A team however, is a group of people working together towards a common goal. A concurrent engineering team, as will be developed later, is a collection of people from functional groups all working toward a common goal.
"Every high quality product is the result of the convergence of diverse organisational talents. If a product lacks the desired level of quality it is usually the result of a lack of collaboration at a critical time and place during development."
[Gillen & Fitz. 3]
Having a team, which is interdependent on each other requires different tools such as an ongoing monitoring of dependencies and task interrelationships to see where certain tasks may be falling behind schedule, or even going too far ahead. The formation of a successful team then is a continuous cycle of improvement.
Another aspect of the employment of multi-functional teams over the older functional approaches, and which may test the resolve of the established management techniques, is that (like the technical aspect of the concurrent approach) initially, there will be a higher cash expenditure with less visible output from the team in comparison to 'over-the-wall', where financial allotment is more evenly distributed.
This switch from function to product (team) orientation is a key factor in CE implementation; especially since most members of that team will not be working on the CE project all of the time and must revert to 'functional' working for other tasks. This will put a strain on the group and also the individuals involved but must be persevered with to attain greater long term synergy. Another factor which comes from this is that as team members alter their work perceptions, they will affect all those around them so that people not involved with the concurrent philosophy at that time can be exposed to the basic principles which may lead to an easier transition into the wider organisation and reduces the risk that is always present when a fundamental, culture changing technique is introduced.
As this is often a new way for a business to work, the management, from the top down must show a commitment to the process, and more importantly, support it. In the early stages of concurrent engineering implementation, a framework for the team will have to be present - akin to a computers operating system, a firmware adhered to but open to improvements. However, due to the nature of concurrent engineering teams, it will often be at odds with the existing framework, and so a new one must be created.
To gain such a framework could be to introduce the new techniques through pilot projects, rather than carte blanche and therefore allow the organisation to gain from this trial group. This method does have its drawbacks as described earlier in the form of 'two cultures running in the same organisation, at the same time' situation. Another technique is to add the concurrency one function at a time over a number of projects, e.g. initially design and manufacture; then finance, and so on. Again this is not a perfect technique, but it may suit some organisations dependant on their existing framework. It is not only the actual placement of the concurrent philosophy that has to change, as will be looked at later in this section, attitudes and policies on rewards and recognition must also change, supporting collaborative methods over individual achievements. This is driven by the need to view the organisation as a whole. It is also important to remember that these changes are not 'home' runs', they will each bring slow, small improvements which may take perhaps up to 5 years to bring to fruition.
When it is decided that a team is to be formed - and after it has been established what the term 'team' is to mean, then the task turns to whom is to comprise the team. Members of the team will obviously differ from those suggested here, depending on the nature of the organisation and what it produces.
By 'team member', we mean either a single delegate from a function or a number of delegates, dependant upon the project and its requirements. Ideally, this should be the same person(s), but if circumstances dictate otherwise, then the person most suitable for a particular situation may be deputised to the team. The actual size of the team may well depend on the actual size of the project, but for a main team a size of approximately 10 may be optimal, as numbers above this can actually inhibit the team function; however, other parties which must be included, but are in addition to this can usually be accommodated into sub-teams, this is mainly due to the notion that the more people in a team, the lower their dedication to it, as suggested in Fig. 4.2.
Since the goal of the project team is to produce a product which will satisfy customer demands in the market-place when it is launched and thus make money for the organisation, then the construction of the team must reflect this, and be geared towards it. If it fails in this key point, then the team may well produce a high quality, innovative product very quickly on little money which nobody needs or wants - thus the whole project is a failure (remember: benefits, not features). With this in mind then, it stands to reason that the group which generate these requirements - the market customers - should be incorporated into the team in some way. Obviously it is not possible to include all of your target customers (decided possibly by corporate direction and the marketing departments research studies) so a next best scenario must be explored, to include representatives of the largest groups of customers, or perhaps user groups.
A case study to illustrate this is the aircraft manufacturer Boeing's experience when developing its 777 design [M'Ment Today 1]. In a bid to retake market it was loosing to McDonnell Douglas and Airbus it invited representatives from eight leading airlines including JAL, Quantas and British Airways to help it set out some customer requirements with a view to seeing the exercise through from clean sheet to final product specification. This proved difficult as the airlines were in direct competition with each other on many routes and so Boeing had to get professional facilitators in to get the companies' representatives to talk to Boeing about what it was they wanted in a new large passenger aircraft. Initially Boeing believed that they could talk the airlines into accepting a stretched version of a previous model - a simpler design job altogether, but when the airlines made their case, Boeing were forced to slaughter several sacred design cows and had to adopt a whole new concurrent culture to allow for a whole new creation which was 25% wider and has a revolutionary flexible cabin allotment system.
It may sound as if all these customers did was cause difficulties, but it was also these same parties which were to place orders for the aircraft, and knowing what they wanted gave Boeing that edge over some very powerful competitors. (Indeed one of the solutions to a major design problem they were having with that plane came from an engineer at British Airways.) The moral of this is that having your customers there when the requirements are hammered out is vital in concurrent engineering to ensure that quality goals set are the correct quality goals. This setting of requirements (and these may include requirements from some other parts of the team) may be the longest individual component of the whole delivery process, but time spent here can save many times more in time and money later in the cycle.
Other function representatives to include in the team can then be extrapolated from here. (Remembering that the functions which begin the process - the department which makes product 'direction' decision and carries out the market research should continue with the team and provide updates from the market, perhaps including information about competitors products.) For instance, the design function, manufacturing, finance, scheduling, purchasing and so on can be incorporated.
With purchasing, a special case can be made with how concurrent engineering and 'over-the-wall' differ from one another with regards to vendor supplies. As the usage and reliance upon third party parts vendors has grown over the last two decades, in general, so has the bureaucracy that controls them. In a new product environment, this is not a move towards the goal, and thus must be addressed with a new relationship between vendor and organisation, who are to an extent reliant upon one another. With this in mind, bringing the vendors into the team, in contexts such as finance, engineering and so on makes sense with regards to achieving the goal. Problems due to the size of the delegation again would be individual to the project and vendor involvement e.g. if brand new tooling were being designed, then an engineering representative may be of the best usage, if it were discussion over a long term, high volume screw supply, perhaps sales and scheduling would fulfil the role better. However, having interaction with tool makers etc. at close call will aid the product delivery process immensely, from design through to manufacture. This means that in many cases, the choice of vendor must be made before a part is designed and so calls for a mutual understanding and relationship to be fostered, which is why bringing even these 'outsiders' into the group is essential. What this means from a control point of view is that vendor selection and dealings must be brought under the team umbrella as early as possible, and thus procurement becomes a part of that team.
Essentially then, the members of this team, are those who will have input into the project, and can now have a history and familiarity with the project and allow information from any required sources to be available easily. Another factor here, but which falls in its entirety out of the scope of this work is the selection of each functions representatives - this is usually down to heads of department, although it should be said that in the early stages of concurrent engineering implementation those with both experience, good communication skills and open minds are possibly the best candidates to involve.
We have discussed the need for the team and assessed those who would need to be a part of it. In this section we will look at means to getting the representative(s) from each function and making them into a product oriented team. Being a team, essentially means knowing about one anothers' functions, and appreciating the requirements and expertise of others in the team. Broadly, this involves the expansion of each members knowledge of the overall situation, to allow a convergence of functions within the team to give an ideal total knowledge and reliance upon the group. This demands then, a surrender of personal political fiefdoms, and an abandoning of the use of expertise and data as powerchips to bargain and curry favour.
"Lines that once divided areas of responsibility must become less rigid. The success of one team member and failure of another cannot be tolerated for a concurrent design to work. It must be understood by each team member that if one discipline fails, then the development project fails."
It is an ineffective team that has its members loyalties to their function over the team and the product. So it must be the task of the organisation initially to try to break this functional mould, and this may mean starting to build the team even before the full project begins, to start to bring the people together
Management could start the process by focusing the team by stating the goal of the project - the product, the service etc. and how it will help the company attain its goal, to see the organisation as a whole. Management must do their part to ensure that departmental measurements and metrics to not hamper or interfere with the project or its movement towards achieving its goal. The importance of this factor comes from the fact that in many functionally based organisations, each department is measured for 'success' against a set of criteria which may be at odds with those used by another department.
On a more physical level, the members of a team, where possible should be located close to one another. This can be taken to the point of locating in one building and removing walls to have open areas, having a central plaza with offices around, having whiteboards readily located or having a central management office to promote availability. This is intended to foster a team spirit and over time aid the knowledge expansion/function convergence process detailed later in this section, ensuring members are product and not functionally oriented.
The goals of the project and even the organisation should be communicated (aired, discussed, clarified) regularly, and perhaps even displayed on available whiteboards. Everyone should be aware of what it is they are striving towards. The team mindset must be altered to show how much functions can benefit one another, this is covered in the following section. Functions must realise that when differences occur, it is not a confrontation that is required, but it is an opportunity to begin a learning process, by exploring each others point of view.
This is the process exemplified by Gillen and Fitzgerald by which the team can start to take advantage of the organisations diverse talents and knowledge in a collaborative way that allows the team to solve problems quicker and take advantage of opportunities rather than merely fight fires [Gillen & Fitz. 4].
Essentially, knowledge of other functions is expanded to allow a greater focus of the teams components, and then when focused on the project, they converge. It not only makes the team stronger, but also aids the concurrent engineering implementation process. This then, is an important component in attaining the concurrent engineering mindset, as it results in an understanding and appreciation of wants and needs within the team, and even the organisation as a whole.
Most organisations paradoxically, have a massive reservoir of specialised knowledge and expertise, but very little convergent knowledge. A pitfall to avoid at this stage though, is to merely restructure the organisations, which may well remove political empires, but will do little to build a synergy through convergence. As corporations have grown into large multi-national entities their knowledge of the world economy has expanded and converged to global markets, so for the same reason, must their functions expand their knowledge of the 'bigger picture' and converge themselves to meet that requirement and face that market. To achieve this expansion and subsequent convergence then the group must go through several phases of development.
This stage involves gauging the level of trust and openness between not only members of the team, but also the management and possibly other external factors. This is the beginning of the expansion phase. It relies on honesty and a large degree of management support. It aims to assess the team's perception of each function, their frames of reference, and the current level of knowledge. This is important, as there is stereotyping in all organisations, and it's rarely based on fact, more on history and peer analysis, so it important to learn the specific facts, and if possible, achieve a clean slate for each function. If there are problems at this point, major or minor, they should be openly debated, and not circumnavigated to make the team appear more cohesive than they actually are. The team requires a solid base to work from, and has been said, a difference is a point of learning and understanding, not an event for political gain and friction.
This new openness should be fostered by the management. Note that the work done so far has not involved the product, it has been directed internally, to build the team, not to develop the task. The time frame may be difficult to judge, and will be constrained by project requirements, which, as suggested, could mean bringing the team together before the project is required to start, and this phase should really be accepted as being an essential part of the project. This learning between one member and another will become transparent as it is accepted as a part of the culture and so it is at this point that the knowledge has started to converge.
As the camaraderie of the team grows, the management must ensure that as the team spirit grows so the team members are empowered both mentally in their expanding knowledge, and within the organisation, and are encouraged to accept responsibility, and act in a collaborative way, even outside of the team. This is giving the convergent knowledge the tools to be make use of itself. It also lends the team a legitimisation within the organisation, and eventually, it will be accepted as an equal part of it.
Undoubtedly, the hardest section of this development is the first step, as at the time it is started, it may well be alien to many of those participating in it. To help in this phase, there are several techniques a manager can use to enable the team to successfully expand their knowledge. Skills such as perceptive listening will need to be encouraged as the team will need to learn to listen to one another. As a rule of thumb, if no-one is surprised by, or already knew what they heard, then either the organisation is exceptionally static, or that person was only hearing what they wanted to hear, what conformed to their model of whatever was being put forward. This selective listening will lead to a false basis for the team, and so must be looked out for, examined, and changed. Once the team learns to listen, then the members can build new frames of reference and re-assess the other functions, building knowledge and trust. A simple framework to build such skills may be one such as the following three step process.
Statement - Each function should produce a mission statement, that outlines its purpose within the organisation, supported by the available means it has of achieving it. Activity Assessment - Each function outline the activities which take the most time, the most frequently - this may well be inter- departmental communication and information retrieval checking and goes to highlight the need for team working and the expansion/convergence process.
Final working report - Each function should now suggest how it can expand its role to benefit and improve the team (and organisation) overall. The presentation of this final step should almost certainly be made to senior management and department heads.
Once this expansion and convergence has begun it is an on-going process of continual learning and improvement.
The fundamental shift in culture that concurrent engineering can entail at the team level has an equally fundamental effect on the management involved with it. The whole management task has now shifted in emphasis, it is no longer geared towards getting the functions to achieve their tasks, but ensuring tasks are handled collaboratively, and helping the team with situations outside of the team sphere, with functions not in the concurrent sphere of influence. To enable the manager to achieve this he/she must go through the same expansion / convergence exercises as the rest of the team because they too are a part of that team. The co-ordination role continues, but the effect of the team means that the manager must now be one of a focuser, not so much instructing as to what must be done, but helping gel the team, and diagnose problems and potential conflicts within the team which may be caused by dependencies i.e. a team member is dependant upon another to continue an action, and is having to wait - this can lead to frustration which must be discussed, understood and learned from. This will be eased as many dependencies will be recognised as knowledge expands and through discussion of critical issues at the requirements stage of the cycle.
Another of the manager's tasks is to see that the balance of factors is addressed, e.g. if a technology issue is resulting in a larger financial outlay in a certain area, then the manager who must ensure that it does not lead to problems with other functions, or the schedule of the project, or perhaps the project's overall budget. The manager must understand the issues and help the members involved overcome the situation. What a manager must also be aware of is that they cannot have a total knowledge of all functions, and trying to be everyone to everybody is a potentially disastrous move. They must accept that others will know more and must trust the team spirit to allow knowledge to be given when needed. This means they must allow team members their own responsibility, otherwise they will destroy the team and end up firefighting on a day to day basis. They are there to 'lead' ,but also to help the team keep together and enable the success of the project; these skills are highlighted in Fig.4.4. All to often however, project management can fail because that manager has not been given the authority or support necessary to reach the objective with their assigned criteria - such as an ambitious schedule.
The manager must also be the one to ultimately predict and determine and acknowledge dependencies between tasks in aiding the development of a schedule plan. In this way, planning systems such as PERT analysis may be applied. Dependencies between tasks can generally be regarded as either soft- or hard dependencies as shown in Fig. 4.5. Deciding which of these is which, along with where they exist is obviously a vital task, especially given their impact on delivery and the established importance of time to market versus cost. Indeed there may well be a shift in culture here from a cost based control, to a more time oriented one; as Smith and Reinertsen have already expressed [Smith & Rein. 4], although companies go to great lengths to monitor the effects of production costs, they do not account as much for the losses due to slippage and lack of funding.