1. INTRODUCTION
As companies grow and expand, they may shift from a single office to a multioffice environment, often spread over a wide geographical area. If this happens, it is vital that unity is maintained in the products or services offered. For the company to grow in the same direction, knowledge and resources need to be shared throughout the company, rather than being limited to individual offices, allowing each office to take on bigger, more complex projects than they might be capable of if limited to local resources. This can be achieved through the formation of distributed teams, allowing key skills and specialisms to be exploited. Simply put, distributed design is the practice of design where members of the design team are geographically separated (MacGregor et al., Reference Lipnack and Stamps2002). Henry and Greenhalgh (Reference Henry and Greehalgh1999) discuss a “50 ft rule of collaboration,” stating that teams are essentially “distributed” if they are more than 50 ft apart, illustrated in Figure 1.
Fig. 1 Scales and variables of distribution according to Henry and Greenhalgh (Reference Henry and Greehalgh1999). Reprinted with permission.
Benefits often documented by companies adopting distributed working within the design process include the following (Top Gear, 1996; Petrie, n.d.):
• improvements in the flow of work allowing companies to move and react faster;
• product development lead time, time to market, and costs reduced while maintaining or improving quality;
• quality failure costs reduced;
• sharing of information and expertise between organizations/departments improved;
• relationships between manufacturers and suppliers strengthened; and
• efficiency of day-to-day dealing with customers improved.
However, the practice of distributed design does not always meet its full potential (MacGregor et al., Reference MacGregor, Thomson and Juster2002), and more often than not, in distributed design projects, designers do not feel entirely satisfied with the product or service provided. Designers are often discouraged from participating in distributed projects because of negative experiences, or worse still by reports of negative experiences from others. Human nature dictates that people take time to develop trust and good working relationships (Williams, Reference Williams1977; Rocco, Reference Rocco1998; Zheng et al., Reference Zheng, Veinott, Bos, Olson and Olson2002); however, participants of distributed design projects regularly feel distant and disconnected from their remote colleagues. In addition to this, working practices are often so far out of synch that any work produced remotely needs to be reworked when the distributed phase of the project is complete. The motivation for this particular study, therefore, was to bridge the gap between various sites within an engineering design consultancy in order to do the following:
• encourage trust and good working relationships between distributed team members,
• rationalize and streamline systems and procedures such that work produced in any site is relevant in any other site to support effective distributed team working, and
• increase the satisfaction felt by participants of distributed design projects that they have provided a quality product or service.
2. EXISTING STUDIES OF DISTRIBUTED DESIGN
This section provides a brief overview of existing research that studies the nature of distributed design and offers support to improve its effectiveness.
Design is a highly diverse social activity (Bucciarelli, Reference Bucciarelli1984). Its success depends in part on the effectiveness of collaboration and communication channels between the team. The diversity of activity together with ever challenging customer requirements leads to larger more complex teams with higher levels of knowledge requirements. As a result, there is a high probability that teams will be distributed. Henry and Greenhalgh (Reference Henry and Greehalgh1999) define the scale and variables involved in distribution as illustrated in Figure 1.
Potentially, an increase in distance between team members results in more problems in the design team. Bradner and Mark (Reference Bradner and Mark2002) monitored the behavior of subjects who were unknowingly sat in adjacent rooms and told they were various distances apart. They demonstrated that increasing the distance that partners believed themselves to be separated by made them less likely to cooperate, less susceptible to persuasion, and more likely to deceive. Trust, which is harder to build and sustain in distributed environments, has been shown to be a critical factor in the success of teams (Jarvenpaa & Leidner, Reference Jarvenpaa and Leidner1998; Lipnack & Stamps, Reference Cheng and Kvan2000). Trust is shown to be greater among individuals who have met face to face, or exchanged a photograph prior to working in a distributed manner (Zheng et al., Reference Zheng, Veinott, Bos, Olson and Olson2002). Increased dispersion inevitably results in a loss of rich subtle interactions meaning work takes longer to do (Herbsleb et al., Reference Herbsleb, Mockus, Finholt and Grinter2000). Furthermore, Allen (Reference Allen1977) analyzed the probability of communication between team members as their physical separation increases. He found that the probability reaches a low asymptotic level within the first 25–30 m; therefore, colleagues in the same building can be considered “remote” if they are more than 30 m apart.
Crabtree et al. (Reference Crabtree, Fox and Baid1997) report on the results of collaborative design case studies where they chart the incidence of problem categories, finding problems relating to information access and acquisition to be most common. They also tracked the time that engineers spent doing certain tasks over a typical week. Peña-Mora and Hussein (Reference Peña-Mora and Hussein1999) state that distributed design environments should include support for representing the following:
• a sense of place,
• spatial interaction,
• degrees of participant engagement, and
• floor control strategies.
However, replicating the collocated environment is difficult and need not be the only support approach. Taking advantage of new distributed spaces without replicating exactly what goes on in conventional work is an alternative strategy. Williams (Reference Williams1977) classifies face-to-face meetings in to two categories: those that can be replaced be computer-mediated communication (CMC) and those that cannot. This suggests that we should strive to retain face-to-face meetings wherever they are necessary and concentrate on building CMC solutions to replace those meetings that do not need to be face to face.
Cheng and Kvan (Reference Cheng and Kvan2000) state the importance of collaboration structure in “finding the best fit between technology and group design for design collaboration.” Sonnewald (1996) describes 13 communication roles that support design collaboration, stating that they could form the basis for prescriptive design methods. Gay and Lentini (Reference Gay and Lentini1995) report on requirements for a networked collaborative design environment. Chiu (Reference Chiu2002) states the importance of organizational structure while specifying the functions of computer-supported cooperative work to support communication in collaborative design: defining task, process, and data dependency; visualizing design process; and supporting team awareness.
Other work offers support for distributed design. Maher and Rutherford (Reference Maher and Rutherford1997) propose a framework for collaborative design that has three major components: a shared workspace, an application domain, and a data management facility.
MacGregor et al. (Reference MacGregor, Thomson and Juster2002) describe detailed case studies of distributed design carried out within two large multinational companies. The case studies focus on adaptive and variant design, respectively. The main output of this work is a design for distribution framework for improved distributed design practice.
The Center for Coordination Science at Massachusetts Institute of Technology have been developing a repository of processes as part of their Process Handbook that aims to resolve collaborative design conflicts. The Process Handbook has been used to manage collaborative projects where the project team includes people from different institutions with varying goals and purposes (Klein, Reference Klein1997, Reference Klein2000). Anderl et al. (Reference Anderl, Lindemann, Thomson, Gaul, Gierhardt and Ott1999) and Gierhardt et al. (Reference Gierhardt, Gaul and Ott1999) created a taxonomy of distribution, including a matrix of characteristics, boundary conditions, and matrix of solutions, based on studies within the automotive environment.
This review of existing research provides a brief overview of some of the studies that have been carried out within the vast distributed design context. The studies described in this section show that getting distributed design right is not as simple as sharing information; a wide range of factors affect its effectiveness and success. Furthermore, it highlights that there are few studies that focus on distributed design teams within a live industrial context. Therefore, there is still a need to conduct further studies, particularly where distribution is an implicit part of day-to-day work.
3. CASE STUDY METHODOLOGY AND CURRENT DISTRIBUTED DESIGN PRACTICE
3.1. Methodology
A case study based approach was adopted. Yin (Reference Yin1994) defines the case study as “an empirical inquiry that investigates a contemporary phenomenon within its real life context.” The four case studies undertaken here were observational rather than participatory, to observe projects from the “outside” to get an accurate picture of how designers operated within their collaborative design teams.
The approach adopted was similar to that of Jagodzinski et al. (Reference Jagodzinski, Reid and Culverhouse2000), which can be summarized as the following:
• immersion of the researcher in normal day-to-day activities of the people under study, occasionally as a participant, but most frequently as an observer or interviewer;
• gathering data from a wide range on sources, including observation, interviews, conversations, and documents in order to build up a rich and detailed picture of participants, their purposes, and activities; and
• an open-ended approach to gathering data, so that key issues can emerge gradually through analysis.
Several methods of data collection were used, including the following:
• Daily “e-mail diaries”: These were submitted by the participants detailing the level of distributed collaboration taking place each day. Participating designers responded to an e-mail sent to them each day containing five short answer questions designed to take only a few minutes to complete.
• Questionnaires: Various questionnaires were used throughout the study to survey opinion or determine working practice. The questionnaires took various formats depending on the type of response required, for example, short answer, multiple choice, or quantifying opinions or attitudes.
• Semistructured interviews: These were frequently used to acquire rich data to supplement the information gathered through the diaries and clarify or develop any issues that arose through the questionnaires.
• Observation: A great deal of rich data and understanding was gained through observation of activities and conversations/discussions.
Two initial case studies were undertaken to identify current practice and develop a “strategy for effective distributed team design.” Evaluation and development of the strategy was facilitated through two further case studies.
3.2. Company background
All of the case studies took place within a UK-based mechanical and electrical engineering consultant referred to within this paper as “the company,” which has approximately 130 staff members, with 60 based in the head office in Glasgow, Scotland, and the rest distributed throughout eight regional offices distributed throughout the United Kingdom, specifically, Glasgow, Edinburgh, Aberdeen, Inverness, Epsom, London, Birmingham, Manchester, and Bristol. The company has been working in a distributed manner to support appropriate projects since the establishment of the regional offices. It is essential for the company to form distributed teams consisting of designers from their various offices for several reasons:
• skills and resources can be leveraged;
• lower cost resources in Scottish-based offices can be exploited including highly skilled, experienced staff;
• facilitates agility, allowing the company to respond to the markets throughout the United Kingdom, independent of location; and
• more stability is achieved by spreading business across the United Kingdom means less vulnerablity to regional fluctuations within the UK market.
The regional offices have grown, both organically and through merger and acquisition, over a period of 15 years and, despite best efforts, drifted in terms of the systems and procedures adopted throughout the design process. As a result, distributed design teams inevitably have difficulty sharing data, thus hampering the effectiveness of the distributed design process, inconveniencing the designers, and projecting an unprofessional image to clients because of an inconsistent interface. It is not surprising that initial interview data in the company highlights low levels of satisfaction with the work produced during distributed projects with designers often being reluctant to work on remote projects.
Company practice for distributed projects is shown in Figure 2. The project is managed from a “lead office” located closest geographically to the actual “project site.” The lead office corresponds with the external design team members and relays information back to designers in a “support office” who have more time or appropriate skills and knowledge to complete elements of the design work.
Fig. 2 Company practice—distributed projects.
3.3. Case studies of current distributed design practice
Case studies investigating two distributed design projects were undertaken to ascertain current status of distributed working within the company. The main findings from each case study are presented in terms of the project stages these being project initiation, distributed design phase—where the main design work is carried out between the distributed design team and project handover—when the project is handed back to the lead office. Findings from the design team satisfaction survey are presented, which took place after each project handover.
3.3.1. Case study project 1
Because of high workload and a shortage of resources in the head office, assistance was requested from the support office to perform the mechanical and electrical design for two new schools. A distributed design team was formed, consisting of designers from two company offices: a project team based in the lead office, with the support office providing distributed team members in the form of one mechanical and one electrical engineer. Although team members in each office has worked together previously and participated in previous distributed projects, this particular team had never collaborated before. All correspondence with the external design team members was channeled through the lead office. Project 1 lasted 5 months.
Project initiation
This project got off to the worst possible start, as there was no formal briefing meeting where the distributed team could meet face to face to discuss the project. The only way to build trust and good working relationships is to meet face to face (Rocco, Reference Rocco1998). The team had never met before, and in fact, did not meet during the entire project, leading to several problems at the outset of the project, most notably the following:
• a lack of awareness among the design team, that is, critical documents being e-mailed to absent team members for distribution;
• a lack of discussion of the brief, resulting in elements being designed that were not required;
• a general lack of awareness of project history, causing neglect of predefined conditions, for example, a preferred manufacturer list, drawing templates, and so forth; and
• a lengthy time-consuming e-mail discussion that could have been clarified at a single face-to-face briefing meeting.
Distributed design phase
The lack of proactive communication was compounded by poor project initiation:
• a lack of awareness of project deadlines attributed to no program being agreed upon at the outset and lack of regular team progress discussions;
• no midproject face-to-face meetings critical for reviewing progress and reevaluating objectives;
• substantial differences in the design methods employed, varying from hand calculations and spreadsheets through design software;
• the drawings that were produced were lacking in detail and had to be substantially reworked before issue; and
• designers were unaware of colleagues' activities confirmed by analyzing the shared project correspondence database “Project Desk” (Fig. 3).
a. There was an average of <0.3 outgoing and incoming e-mails logged in the database per week, surprising for a project of this size and nature. Clearly, the shared project correspondence database was not being used for sending and storing project emails.
b. Faxes were managed more effectively; there were on average three to four incoming and outgoing faxes logged in the system each week.
c. The support office appeared to be logging more internal correspondence than the lead office because of logging on receipt from the lead office.
Fig. 3 Shared project correspondence database activity during the distributed design phase of project 1. [A color version of this figure can be viewed online at www.journals.cambridge.org]
Project handover
There was no formal handover, meaning that there was no opportunity to query, discuss, provide feeback, or comment on the design produced.
Design team satisfaction survey
The team members in this project were not at all satisfied with the systems and procedures in place to facilitate distributed collaborative working (Fig. 4). In general, team members were less than 40% satisfied with the current systems and procedures. Correspondence management within designers' own office was rated below 60%, suggesting a major lack of awareness of team colleagues' activities.
Fig. 4 Participants' satisfaction with systems and procedures. [A color version of this figure can be viewed online at www.journals.cambridge.org]
3.3.2. Case study project 2
The scope of project 2 was to design the mechanical and electrical services for an online bank's customer service center. The lead office requested assistance, because of an excessive workload and restricted resources. This project was split into two packages, with the mechanical package being designed in the lead office and the electrical package being designed in the support office. Although designers in each regional office had worked together previously, they had never collaborated with distributed team members previously. The project was led entirely by the lead office, which was responsible for all correspondence with the external design team members.
Project initiation
Project 2 got off to a better start than project 1 with a face-to-face briefing meeting. The distributed team had never previously collaborated and appreciated the opportunity to meet, discuss the project, and start to form a relationship.
Distributed design phase
A face-to-face meeting took place halfway through the project to discuss progress and reevaluate the program. This meeting went well, with progress decisions being made. However, this project was of a particularly dynamic nature with high levels of correspondence taking place between the external design team and the lead office over a short period of time. This meant that most of the agreements made during the meeting were irrelevant shortly afterward, and the project fell into a period of poor correspondence management and control.
Data from the shared correspondence database (Fig. 5) shows less than 0.5 outgoing e-mails being logged each week, which is below expectations, and support office logging more internal project correspondence, suggesting they were more comfortable with the system.
Fig. 5 Shared correpondence database activity during the distributed design phase of project 2. [A color version of this figure can be viewed online at www.journals.cambridge.org]
Project handover
There was no handover meeting, so the project tailed off and transferred back to the lead office. As a result, the drawings had to be reworked before issue.
Design team satisfaction survey
The results of the design satisfaction survey (Fig. 4) again show poor levels of satisfaction with existing systems and procedures. The project briefing, indicated by [1], scored slightly higher than project 1 (53% compared to 39%) because a face-to-face meeting actually took place and, although the information issued was limited and subject to change later, it provided individuals with a chance to meet each other. The overall experience [2] was rated more highly than project 1, highlighting the fact that the individuals involved appreciated the opportunity to have someone else vet proposals and offer constructive criticism.
3.4. Key lessons from case studies 1 and 2
A number of key lessons can be distilled from these cases.
1. There must be a briefing meeting to explain the project background, agree on roles and responsibilities, and set an internal program.
2. The drawing and design philosophy must be agreed at the outset, and any changes must be discussed as appropriate.
3. There must be more proactive communication and regular checks of progress against an agreed internal program.
4. The correspondence management system was not being used appropriately and required development and a training plan to make it work in the modern business environment.
5. Greater thought and discussion should take place prior to undertaking distributed team working to ensure it is the correct solution for the problem. Case study 2 is an example of a project not particularly well suited to a distributed approach because of its extremely dynamic nature.
6. Existing systems such as the shared correspondence project database could be developed and used to share and store all project correspondence.
7. All notes and minutes from meetings or discussions with external design team members should be stored in the shared correspondence database for future reference.
4. A STRATEGY FOR EFFECTIVE DISTRIBUTED TEAM DESIGN
Following analysis of the key lessons learned from projects 1 and 2, four key areas were highlighted for development:
1. Distributed design process map: A process map that demonstrates how to perform effective distributed design. The procedure should describe how to set up and manage a distributed design project, from a comprehensive assessment of the project at the outset ensuring its suitability for distributed working through to a quality review following completion.
2. Correspondence management system: The system currently being used for project management was initially designed to manage faxes and letters. E-mails were not processed in such an effective manner, and because this was the main method of communication, it was vital that e-mails could be sent, shared, and stored using the central correspondence management system. Alongside this development, there needed to be comprehensive training and support offered to all staff to ensure the system was accepted and adopted companywide.
3. Standardizing design tools and methods: A corporate intranet could also support standardization of design tools and methods by providing access to standard design guides, drawing guides, and any other “best practice” guides. Ensuring that information and data produced during distributed design projects is instantly recognizable and compatible.
4. Corporate intranet: Within the company there are islands of people with skills and knowledge widely distributed around the country with little or no interaction. Development of a corporate intranet would provide a vehicle for raising awareness of remote staff within the company.
4.1. Distributed design process map
The distributed design process map is a procedure aimed at improving the effectiveness of distributed collaborative design. The distributed design process map is shown in Figure 6. Each stage in the distributed design process map is explained in more detail.
Fig. 6 The distributed design process map.
4.1.1. Decision to seek assistance
If an office does not have appropriate skills and resources this decision may be triggered.
4.1.2. Check suitability for distributed collaborative design
Each potential distributed project should be checked to ensure it is the best solution. Key desirables are to be easily and logically split into packages, have well-defined start and end dates, and not require excessive visits to site. A cost/benefit analysis should be performed to ensure that the time and resources saved is greater than the time anticipated to brief the distributed team members.
4.1.3. Select support office
Confirm partnership details
Before any design work commences it is essential to confirm distributed design team personnel as well as time scales and deadlines. If possible, select designers who have worked together successfully in the past.
Project briefing meeting
A project briefing is critical, providing an opportunity to discuss technical, commercial, and political issues relating to the project. It also gives the design team members a chance to meet each other and start to build relationships and trust. Recognition of ownership of the relevant design elements within the distributed team is important.
The following key points should be addressed at the briefing meeting:
• review the project history and discuss the design brief;
• define objectives, responsibilities, and deadlines;
• draft an internal project program and agree who is responsible for monitoring progress;
• agree on design tools, methods, and appropriate standards, including responsibility for design coordination;
• arrange for regular progress reviews and meetings; and
• agree on appropriate levels of quality control.
Distributed design phase
Guidelines for this stage include the following:
• All project communication must be shared, that is, minutes of meetings, notes from discussions, and so forth, through the shared project correspondence database. Phone calls can be used to alert and discuss any major issues affecting the distributed design team.
• Schedule as many face-to-face meetings as the project budget and program allows; otherwise, the telephone is the best medium for discussions. E-mail/fax should be used only for the transfer of documents and technical information.
• All correspondence must be created and shared through the shared project correspondence system.
• Design tools and methods used should be consistent with those detailed in the design guides unless specifically agreed otherwise at the project briefing meeting.
• Weekly progress discussions must occur between the lead engineers in the distributed offices with any amendments to the program or otherwise being made available to all distributed design team members.
• Any assumptions made by a design team member must be checked and approved with the rest of the distributed design team. Proactive communication relating to technical matters is strongly encouraged between members of the distributed design team.
• Resource or management information should be discussed between the project directors (see Fig. 7). If workload or priorities change and resources need to be diverted, then this must be agreed at director level and communicated to the designer.
Project handover meeting
A face-to-face handover allows the team to review the design. Facilitating smooth transfer of ownership back from the support office to the lead office. The handover meeting should be scheduled to allow enough time for final checks and modifications prior to design issue. The handover meeting is the most likely part of the process to be overlooked. However, it is absolutely vital for project closure because it allows queries and feedback among the distributed design team.
Fig. 7 The recommended communication structure. [A color version of this figure can be viewed online at www.journals.cambridge.org]
Postdesign/construction phase assistance
Depending on the type of contract, the design team may or may not have responsibilities for overseeing procurement, installation, and design revisions during the construction phase.
Project review
In the interests of continual improvement, every member of the distributed design team should participate in a project review highlighting strengths and weaknesses of the project.
4.2. Shared correspondence management system
Case studies highlighted several key problems:
1. poor management of e-mails,
2. lack of training and support,
3. inconsistent and user-unfriendly interface, and
4. poor contact management.
A great deal of care has to be taken when developing groupware systems within an organization. Orlikowski and Hofman (Reference Orlikowski and Hofman1997) tell us we need to be improvizational and react to events as they occur during the development process. The project correspondence management system development followed a plan–do–check–act cycle. This is one of the key concepts of the Kaizen (Japanese for “continuous improvement”) management theory, which as Imai (Reference Imai1997) explains, focuses on continuous improvement of working practices and personal efficiency (Fig. 8). The development process used within the company is explained briefly below.
Fig. 8 The plan–do–check–act cycle according to Imai (Reference Imai1997). Reprinted with permission.
4.2.1. Plan
User forum
A user forum was held with a cross-section of engineers, administration personnel, IT personnel, and a meeting facilitator. The current correspondence management system was reviewed in its entirety, taking into account user opinions, requirements, and suggestions for improvement.
Create brief
A detailed brief was developed then outlining the proposed system development. This was distributed as appropriate for review and comment. The brief was revised and reissued for approval.
4.2.2. Do
Development of solution
The project correspondence management system was developed in accordance with the brief. Careful consideration was given to existing systems and retraining issues.
Training
Prior to rolling out the revised system, all users were briefed and trained in the functionality and philosophy of the project correspondence management system, ensuring everyone knew how to use the system, its benefits, and where to go for support or advice. A user manual was compiled and made available to all staff.
Rollout
The revised project correspondence management system was rolled out to all offices over a single weekend so that when staff arrived for work on Monday morning the new system was up and running with all historic correspondence, causing minimum disruption and ensuring all staff in every location were using the same system from day 1.
4.2.3. Check
Feedback
A review questionnaire was issued, selected results show that
• 91% of staff surveyed thought that sending project-related correspondence to external design team members was either easier or much easier,
• 82% thought that their awareness of correspondence received by other design team members had improved, and
• 86% thought that joining a project is (or would be) easier or much easier.
4.2.4. Act
Continual improvement
Feedback from users was handled in-house through a formal feedback database, with serious bugs being fixed immediately and minor bugs and suggestions for additional features being logged and batch processed as appropriate.
4.3. Design tools and methods
Initial case studies highlighted a variation of packages being adopted within the company. Standardizing and controlling the tools throughout the company would improve the efficiency of information and data sharing.
A design standards review forum was set up consisting of four senior engineers. The forum met initially to discuss the findings of a companywide survey of design tools utilized, and reconvened at least monthly to develop and refine proposals for standardizing the design tools and methods. Members of the forum developed spreadsheets for each separate design element and analyzed the various options available before recommending software packages to be adopted as “the company standard.” To ensure maintenance and continued adoption of the standard design guides and tools, a design standards group was set consisting of one designer from each office. The group meets quarterly to feed back on the existing systems and procedures and to discuss potential future developments.
4.4. Corporate intranet
It became apparent from projects 1 and 2 that unless an individual had specifically collaborated with another office in the past, they knew very little, if anything, about their distributed colleagues. This lack of awareness of colleagues, their skills, and knowledge was addressed by creating an online community. A corporate intranet was developed to bring together all existing databases such as the project correspondence database, management information systems (MIS), and so forth, and a new suit of databases, all of which are accessed through a common portal that staff had set as their homepage. The homepage provides access to company standards, information, and staff pages as described below.
4.4.1. Design notes
Design guides: These are best practice advice, company standard design methods including approved software and spreadsheet solutions, relevant standards, and guides:
• drawing guide: an online CAD manual to help ensure that when drawings are produced during distributed design projects, they are of consistent quality and standard;
• distributed design process map: to be followed when embarking on a distributed collaborative design project (Section 4.1); and
• quality assurance: details of the company quality assurance procedures.
Staff notes: These raise awareness of remote colleagues and broadens the pool of skills, knowledge, and experience from which staff can draw, with databases including news, people, offices, and company handbook.
Library: The library contains company standard documents such as design spreadsheets, checklists, electronic documents. Designers are encouraged to submit and share documents within the library.
Discussion forum: A typical discussion forum where users post questions, comments, or observations, and other users respond accordingly, allowing designers to tap the knowledge and experience of staff throughout the company.
Admin notes: The admin notes section provides links to MIS such as time sheets, expenses, and fee invoice databases.
Marketing notes: The marketing notes section provides links to more existing databases such as project registration database (PRDB), ACT (marketing contacts database), and submissions databases.
The corporate intranet also provides access to a distributed design process map and the standardized design tools and methods.
5. EVALUATION OF THE STRATEGY FOR EFFECTIVE DISTRIBUTED TEAM DESIGN
The strategy for effective distributed team design described in Section 4 was evaluated in two further case studies. These projects made use of all aspects of the strategy.
5.1. Case study project 3
Case study 3 was 3 months in duration. The project brief was to design mechanical and electrical services for the extension to an existing shopping center. It was led from a regional office with support of two electrical engineers from the head office. Some distributed team members had worked together previously. All had prior experience of working in a distributed team.
5.1.1. Project initiation
As the distributed design process map recommends, a structured face-to-face briefing meeting took place to allow the distributed team to discuss the project. Notes from the meeting were stored in the shared project correspondence management system. Some of the members of the distributed team had worked together previously.
5.1.2. Distributed design phase
This went well largely because of the fact that some members of the distributed design team had collaborated on previous jobs and had developed good working relationships. Other members of the distributed team who had not met prior to the briefing meeting quickly bonded, and there were frequent proactive telephone calls to discuss matters arising and to check progress.
The project correspondence management system was used extensively. Analysis shows (Fig. 9) there were significantly more incoming e-mails being logged: 11.8 per week compared with 0.3 and 4.6 for projects 1 and 2, respectively. This is a direct result of the improvements made to the system, allowing designers to easily share and store e-mails within the system together with the training and support offered.
Fig. 9 Project correspondence management system database usage during project 3. [A color version of this figure can be viewed online at www.journals.cambridge.org]
5.1.3. Project handover
A handover meeting did take place; however, not all team members could attend. Minutes were shared among the team using the project correspondence database.
5.1.4. Design team satisfaction survey
Figure 4 shows increased levels of satisfaction in key areas such as correspondence management [1], [2], project briefing [3], project handover [4], and general awareness and relationship with the remote partner [5]. There were concerns over drawing management and design standardization, [6], [7], and [8]. Drawing management was not addressed within the scope of this project. The biggest concern was the low levels of satisfaction with design standardization [8]. Design guides were brought online just prior to the initiation of this case study. Designers therefore had limited time to review them fully prior to project commencement.
5.2. Case study project 4
Case study 4 lasted for 1 month and was undertaken by a distributed team consisting of designers from two offices. The head office provided two virtual team members in the form of one engineer and one company associate. The project brief was to provide mechanical and electrical support for an office redevelopment. Some distributed team members had worked together previously. All had prior experience of working in a distributed team.
5.2.1. Project initiation
A structured project briefing meeting took place, allowing discussion of project objectives, responsibilities, and time scales together with technical and commercial issues. Some key members of the design team had a strong working relationship through previous collaboration, whereas the remaining team members had never met.
5.2.2. Distributed design phase
There was frequent correspondence between the distributed design team, both synchronous (via telephone and face to face), and asynchronous (mainly through e-mail). Although this project only lasted 1 month, a midproject review meeting took place. Analysis of the project correspondence management system (Fig. 10) shows both lead and support offices corresponding with external design team members, with internal correspondence being logged extensively [1], 4.75 per week, compared to 3.14, 3.64, and 1.29 for projects 1, 2, and 3, respectively, illustrating the system provided a convenient method for sending and crucially recording internal correspondence. Usage is evenly split between both sites of the distributed team showing confidence in using the system throughout the company.
Fig. 10 Project correspondence management system activity during the distributed design phase of project 4. [A color version of this figure can be viewed online at www.journals.cambridge.org]
5.2.3. Project handover
The one failing in this project was the lack of a handover meeting that did not occur because of time constraints within both offices.
5.2.4. Design team satisfaction survey
The results of the design team satisfaction survey (Fig. 4) illustrate the participants of this project were more satisfied with the systems and procedures than in any of the previous pilot projects. The greatest difference can be seen in the areas of design standardization and drawing management, [1], [2], and [3]. This may be attributed to various factors:
1. key members of the distributed team had worked together previously,
2. design tools and methods to be used were agreed at the briefing meeting, and
3. a midproject review picked up minor deviations before they became critical.
The lack of a structured handover meeting resulted in a low rating [4] and could have left some ambiguity regarding ownership of the design.
5.3. Discussion and conclusions of case studies 3 and 4
Distributed design teams adopted the strategy for effective distributed team design and its four main elements enthusiastically, facilitated by ample and appropriate training. As a result, projects 3 and 4 were definitely a greater success than both projects 1 and 2. The satisfaction of the designers involved was substantially higher in most areas. Furthermore, deliverables were on time and there was no rework required following the project handover.
Distributed team members involved in these projects indicated the following:
• The developed shared correspondence system helped improve awareness of distributed design team colleagues.
• The distributed design process map added value to the process.
• A structured briefing meeting was extremely useful to discuss the project and have the opportunity to form a good relationship from the outset.
• The project was made easier because key team members already had a good working relationship. This helped others bond quickly and form relationships that may be exploited in the future.
• The midproject progress meetings with case study 4, in particular picking up several misinterpreted design features, was important.
6. SUMMARY AND CONCLUSION
This paper described a study of distributed collaborative teamwork within an engineering design consultancy. The study spanned a period of 2 years, with four separate case studies being presented, each based on live projects. The two initial case studies, described in Section 3, highlighted issues and areas for improvement within distributed team working practice, which were addressed through the development of a strategy for effective distributed team design. This strategy addressed four key areas, each of which were described in detail in Section 4:
1. the distributed design process map,
2. the project correspondence management system,
3. design tools and methods, and
4. the corporate intranet.
The strategy was evaluated through two further case studies, again based on live projects; these case studies proved that successful distributed design was achievable with appropriate systems and procedures in place. The shared project correspondence system ensured that designers were aware of the latest developments regardless of where they were located. Analysis of data stored and shared within it showed a dramatic increase in its usage from case studies 1–4, demonstrating a clear improvement in the effectiveness with which the team were communicating and managing their communication. The corporate intranet helped by giving designers in remote locations information about people, skills knowledge, and news about people from all around the company, helping to instill a sense of association with the company as a whole rather than each office being an island. Following the distributed design map improved the effectiveness of the process, with misinterpretations being identified before they had a major impact and requirement for rework diminishing to zero in projects 3 and 4. Furthermore, from case study 1 to case study 4 the team was more satisfied with the various aspects of the distributed design process. In particular, the greatest improvements occurred in the following:
• correspondence management between distributed team offices: 147%;
• design coordination: 115%;
• standardization of design: 133%;
• awareness of relationship with the remote team: 133%; and
• overall experience: 121%.
In addition to offering an evaluated strategy, this study highlighted and reinforced some of the issues discussed in the literature review, that is, trust in distributed relationships is greater between individuals who have met before, and face-to-face meetings are still essential. Furthermore, this study recognized that strangers working in distributed teams with other team members who know and trust each other bond faster and more effectively and it is important to identify critical points within the distributed design process for face-to-face meetings. Value is added by the fact that these results were based on “live projects” rather than laboratory tests that have been the focus of many studies to date.
This study focused on distributed design practice within a medium-sized company, which, like many other small- and medium-sized companies, had the technology to support distributed design in place but needed to develop current company processes and systems, adopt appropriate tools and methods, and address management issues to achieve greater effectiveness within their design process. The lessons learned by the company were developed and packaged into a strategy for effective distributed team design. Many companies, in particular small- and medium-sized companies, face the problems and issues highlighted in case studies 1 and 2. These companies could use the strategy or elements of it to improve the effectiveness of distributed team working within their company. Modification to suit their particular circumstances would allow them to emulate the process undertaken and achievements made by the company at the center of this study. Although this work focused on distributed collaboration between distributed design teams within one company, the strategy itself or its components could be applied to achieving and maintaining effective distributed collaborative design between organizations.
The success of the case study projects was determined by measuring the satisfaction felt by the designers involved, because they were the people using the systems and procedures and were best positioned to comment on their effectiveness. Other measures were considered for measuring the success of the case study projects, for example, “did the project meet time and cost targets?” This measure was dismissed, however, because the case studies were all of significantly different size, scope, and contractual arrangement. It would be interesting to take two projects of similar size, scope, and contractual arrangement and see how much, if at all, distributing the design affects the time and cost associated.
Initially, one of the objectives of this research was to introduce new technologies to support synchronous communication to enhance the distributed design process. However, it became apparent from case studies 1 and 2 that there was a need to focus on the management of the distributed process, standardization of corporate systems and procedures, improve data sharing and management, together with addressing cultural and social issues. Now that a solid foundation has been established with the appropriate systems and procedures in place to facilitate distributed design, it would be interesting to implement new synchronous technologies, such as Web conferencing and instant messaging, and monitor their impact on the distributed design process.
Avril Thomson received her PhD in 1997 at the University of Strathclyde and has been involved in researching distributed design since 1996. She became a Lecturer in the Department of Design, Manufacture and Engineering Management at Strathclyde in September 1998. Dr. Thomson has been involved in a number of projects concerned with distributed design, including ICON (Institutional Collaboration Over Networks) and CVDS (Clyde Virtual Design Studio) funded by SHEFC, the main aim of which was to develop approaches to design based upon virtual environments; VIDEEO Virtual Development Environment for Europe, funded by SOCRATES to support the design and development of VIDEEO, an environment to support the teaching of the New Product Development Process to engineering and business students through scenario-based collaborative projects; Communicative Constraints Imposed by Video Mediated Communication, EPSRC funded to investigate the psychological effects of adopting video-mediated communication within a design environment; and Achieving and Maintaining Effective Gateway Working, funded by Teaching Company Scheme.
Angela Stone obtained her BEng (Hons) in mechanical engineering (Sandwich) in 1990 and her PhD in 1994. She started her career with Oxford Instruments on new product development of offline quality control equipment and then obtained a Senior Lecturer post in engineering design at Staffordshire University in 1996. In August 2002 she became employed at the University of Strathclyde in the Department of Design, Manufacture, and Engineering Management. While at Strathclyde, Dr. Stone has been involved in postgraduate and undergraduate individual projects, dissertations, and industry-led group projects where students are encouraged to undertake computer supported cooperative work. She is actively involved with knowledge transfer partnerships funded by the DTI and undertaken within industry.
William Ion is a Senior Lecturer and Head of the Department of Design, Manufacture, and Engineering Management at the University of Strathclyde. He graduated from the University of Glasgow in 1979 with an Honours degree in mechanical engineering with a specialization in production management. Prior to appointment to the Department of Design, Manufacture, and Engineering Management in 1985, he was employed by Barr and Stroud Ltd. and Yarrow Shipbuilders Ltd. In both these positions he was responsible for a wide variety of design projects, principally for the MOD. Dr. Ion has been actively involved in the development of design and design management education at the secondary school, undergraduate, and postgraduate levels. He established the University of Strathclyde Product Design Engineering course in 1991. He has been an investigator on research projects in the areas of design methods, computer-supported collaborative working in design, design education, and rapid prototyping.
