2.4 Project Coordination
2.4.3 Coordination mechanisms in software development
2.4.3.1 Coordination by standards
The distinguishing feature of this type of mechanism is that it is concerned with the rules by which something is done rather than the goals that guide the development (Sabherwal, 2003). Mintzberg (1979) devotes considerable attention to coordination by standards, being one of the determinants of organizational structure. According to Mintzberg, coordination mechanisms form a continuum from mutual adjustment to direct supervision then standardization and mutual adjustment once more. Organizations adopt these coordination types as they become larger and deal with more complex problems. Standardization is broken down into three areas as follows:
• Standardization of work. Work processes are standardized by describing the sequence of tasks to be performed and the techniques to be used in performing them.
• Standardization of outputs. The results of the work are specified but not the means of achieving those results. Mintzberg gives the example of a taxi driver who is told where to go but not how to drive the taxi.
• Standardization of skills. When the outputs are difficult to specify and the work cannot be fully specified in advance, standardized skills are used. For example, a surgical team assigns responsibilities to each team member who discharges those responsibilities within an expected range of behaviours. The anaesthetist does not wield the scalpel, the surgeon does not fetch instruments.
Page 41
Table 5: Coordination by standards
Standards-based coordination
mechanism
References
(Beck, 2000) Selby, 19 (Cusumano and
97)
(Hughes and
Cotterell, 1999) (PMBOK, 2000) 2003) (Lientz and Rea,
Development procedures √ √ √
Project administrative procedures √ √
Organizational procedures √ √
Documented workflow √
Checklists √ √
Metaphor, Modular Architecture √ √
Formal specifications √
Coding standards √ √
Standard tools √ √
Work product templates √
Training/ acculturation/ induction √ √
Collaborative work tools √
As Mintzberg describes them, coordination by standardization is little different to the
organizational control mechanisms of output, behaviour and input controls (Kirsch, 1996). It is acknowledged that control mechanisms and coordination mechanisms are often intertwined and no attempt will be made in this thesis to classify a project management mechanism as
exclusively one or the other. When a mechanism is employed for the purposes of coordination it will be treated as if it was a coordination mechanism, even though organizational control may be achieved at the same time.
Mechanisms that achieve coordination by standards identified in readily available project management texts are shown in Table 5. The table shows a range of different standards-based coordination mechanisms and gives some indication of their popularity within different styles of project. For the more formal project styles (Hughes and Cotterell, 1999; Project Management Institute, 2000; Lientz and Rea, 2003), more formal coordination mechanisms are described whereas those writing about “agile” software development (Cusumano and Selby, 1997; Beck, 2000) describe less bureaucratic, work based standards.
2.4.3.2 Coordination by plans
When coordination is achieved by specifying what is to be produced and, possibly, when it is to be produced, then this can be described as coordination by plans (Sabherwal, 2003). Project
Page 42
planning involves, among other things, dividing the work according to some work breakdown structure and development schedule that permits the development to be carried out largely independently; then, integrated to make a whole product. The planning is not concerned at that stage with exactly how the work will be performed but is concerned with how the product can be divided, how the interfaces between the separate parts must operate and how the component parts may be integrated. Since the project schedule expresses a work breakdown structure, most reference is to the schedule rather than the work breakdown structure.Sabherwal identified a number of coordination mechanisms that can be classified as coordination by plans: delivery schedules, milestones, requirements specification, sign-offs (Sabherwal, 2003). Methods of dividing software development between geographically separated development teams as identified by Grinter and Herbsleb (1999) are all plan-based coordination. Other mechanisms might be called upon in order to complete the work, but these are only mentioned briefly.
Readily available texts on software development or project management identify a range of plan-based coordination mechanisms, shown in Table 6. It is notable that texts on “agile” software development (Thomsett, 1989; Cusumano and Selby, 1997; Beck, 2000) identify fewer plan-based coordination mechanisms than texts that describe more formal project management methods (Hughes and Cotterell, 1999; Project Management Institute, 2000; Lientz and Rea, 2003).
Table 6: Coordination by plans
Plan-based coordination mechanism References
(Beck, 2000) 1997) and Selby, (Cusumano 1989) (Thomsett, 1999) Cotterell, (Hughes and 2000) (PMBOK, Rea (Lientz and
, 2003
)
User stories, Feature Sets √ √
Project scope and objectives √ √
Project charter √
Product Vision Statement √
Business Case √
Project plan / Rapid application planning √ √ √
Project schedule/network diagram √ √ √
Task steps (to implement user stories) √
Development life cycle / process model √
Project Team structure √ √
Organization Breakdown structure √
Roles / Responsibility assignments √ √
Bill of Materials √
Page 43
2.4.3.3 Coordination by formal mutual adjustment.
Mutual adjustment is essential because of the uncertainty of software development (Kraut and Streeter, 1995). Specifications change over time, specifications are unclear or do not fully specify what is to be produced, and it is difficult to specify in advance precisely how the various components are to be integrated. Overcoming the problems requires some form of mutual adjustment, some of which can be formalized into specific actions or mechanisms. Kraut and Streeter offer modification request tracking and data dictionaries as examples of formal mutual adjustment. The coordination techniques in their research results include code inspections, status reviews and error tracking (Kraut and Streeter, 1995). Sabherwal additionally lists design review meetings, reporting requirements and liaison roles among the formal mutual adjustment mechanisms (Sabherwal, 2003).
The distinction between formal and informal mutual adjustment is in the degree of structure and formality. Sabherwal suggests that informal mutual adjustment may be related to team
interdependence whereas formal mutual adjustment may be related to reciprocal interdependence, although no study has been done to test this. In the continuum of
interdependence from pooled through sequential to reciprocal interdependence (Malone and Crowston, 1994), both formal and informal mutual adjustment could potentially be used for both sequential and for reciprocal interdependence.
The need to coordinate activities is not confined to software development and it can be instructive to examine how other industries confront the same problems. For example, in a comparison of set-based concurrent engineering as practised by Toyota against a more
sequential engineering practised by many other car designers, Sobek et al. (1999) note that the Japanese automobile industry’s ability to do concurrent engineering can be attributed to rich, bilateral communication. Certainly set-based engineering, where several alternative designs that utilise many candidate components, relies heavily on reciprocal interdependencies, all of which must be traded off against each other. The USA practice of point-based design, where the imperative is to settle on a basic design early in the process then modify the design in successive refinements, makes more use of sequential interdependence as successive departments or specialists take their turn to modify the one design. However, data indicate that Toyota suppliers spend less time communicating with the parent company than do suppliers to companies that practice point-based design (Ward et al., 1995; Sobek et al., 1999). This reduced
communication appears to be attributable to set-based design methods rather than any inherent differences or efficiencies of communication methods.
Page 44
Project management and software development texts generally do not identify and classify coordination mechanisms. Nevertheless, formal mutual adjustment coordination mechanisms can be identified in many texts, as shown in Table 7.Table 7: Coordination by formal mutual adjustment
Formal mutual adjustment
coordination mechanism
References
(Beck, 2000) Selby, 19 (Cusumano and
97)
(Thomsett, 1989) Cotterell, 1999) (Hughes and (PMBOK, 2000) 2003 (Lientz and Rea,
)
Steering committee √ √
Configuration management √ √ √
Change control √ √ √
Iterative development with small releases √
Phased project with gates √
Synchronize and stabilize √
Continuous integration and testing √
Evolving specification √
Refactoring √
Document inspections / reviews √ √
Quality audit √
Project reports √ √
Project reviews √ √
Project administration office √
2.4.3.4 Coordination by informal mutual adjustment
Corridor conversations, unannounced office visits, unstructured and informal conversations between co-located team members are all examples of informal mutual adjustment. The defining characteristic is, as noted by Sabherwal, the degree of structure and informality. Informal mutual adjustment is the most flexible of all the types of coordination mechanisms but comes with a high variable cost (Sabherwal, 2003). A number of studies argue that informal communication is an essential element of software development (Sawyer and Guinan, 1998; Herbsleb et al., 2000; Boehm and Turner, 2004) although few of them say exactly why. Kraut and Streeter point out that formal communication tends to fail in the face of uncertainty and that informal communication is needed to overcome the uncertainty that seems essential to software development (Kraut and Streeter, 1995). Their research indicated that informal interpersonal procedures were judged of more value when the project was in the planning stages than in later development stages, regardless of the project certainty, size or life cycle.
Page 45
Project management and software development texts rarely identify and classify specificcoordination mechanisms. Researchers into software development frequently point out the coordination role of informal conversation within software development (Kraut and Streeter, 1995; Herbsleb and Grinter, 1999b; Andres and Zmud, 2002; Sabherwal, 2003; Boehm and Turner, 2004), but less frequently identify other mechanisms of informal mutual adjustment. Nevertheless, most texts will mention a range of mechanisms of which some can be labelled as “informal mutual adjustment” as shown in Table 8.
Table 8: Coordination by informal mutual adjustment.
Informal mutual adjustment
coordination mechanism
References
(Beck, 2000) Selby, 19 (Cusumano and
97) (Project Management Institute, 2000) (Lientz and Rea, 2003) Pair programming √
Bullpen work room √
Collocation √
Collective code ownership √
Small teams √
Team building or formation √ √
Organization culture √
Project kick-off meeting √
Task sharing √
Casual conversations √ √
2.4.4 Summary
Since project management texts seldom explicitly record coordination mechanisms, very few conclusions can be drawn from Table 6 through to Table 8 because it is not recorded in the text whether the coordination mechanisms that were referenced were intended to be examples of a larger set or intended to be an exhaustive listing. Coordination seems to be an assumed purpose of project management rather than an explicit purpose.
However, it can be seen from the tables that the more “agile” project management of software development life cycles (Cusumano and Selby, 1997; Beck, 2000) use less standardisation as well as formal mutual adjustment coordination mechanisms but about the same amount of informal mutual adjustment coordination mechanisms.
There is less consensus about classifications of coordination mechanisms among researchers than there is about classifications of control mechanisms, reflecting the different perspectives
Page 46
from which researchers examine coordination. In examining coordination in outsourcedsoftware development, Sabherwal (2003) closely matched the scope of this research and for this reason Sabherwal’s classification schema of coordination mechanisms (Figure 2, Section 2.4.2) will be adopted in this research.