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.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).

  1. 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.

  2. b. Faxes were managed more effectively; there were on average three to four incoming and outgoing faxes logged in the system each week.

  3. 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.

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. 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. 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. 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. 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. 1. poor management of e-mails,

2. 2. lack of training and support,

3. 3. inconsistent and user-unfriendly interface, and

4. 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.

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. 1. key members of the distributed team had worked together previously,

2. 2. design tools and methods to be used were agreed at the briefing meeting, and

3. 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.

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. 1. the distributed design process map,

2. 2. the project correspondence management system,

3. 3. design tools and methods, and

4. 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.