Embed Size (px)
Citation preview
The use of project management mechanisms
in software development
and their relationship to organizational distance:
An empirical investigation
Tom McBride, B.Sc., M.Sc.Soc.
A dissertation submitted in fulfillment
of the requirements for the degree of
Doctor of Philosophy
Department of Software Engineering
Faculty of Information Technology
University of Technology, Sydney
June 2005
Page i
CERTIFICATE OF AUTHORSHIP
I certify that the work in this thesis has not previously been submitted for a degree nor has it
been submitted as part of requirements for a degree except as fully acknowledged within the
text.
I also certify that the thesis has been written by me. Any help that I have received in my
research work and the preparation of the thesis itself has been acknowledged. In addition, I
certify that all information sources and literature used are indicated in the thesis.
Page ii
Acknowledgements
No student research is possible without the help and guidance of supervisors. I was fortunate to
have Professor Brian Henderson-Sellers and Associate Professor Didar Zowghi as my
supervisors. Their guidance and encouragement was highly valued. In particular they curbed my
tendency to race off in new and interesting directions.
Any endeavour that lasts for several years places added burdens on family and friends. I am
grateful to my wife, Helen Allport, for the support and balance she provided. Numerous times
she listened politely to obscure reasoning about something that could only be of interest to
someone deeply involved in it. And let’s not forget the gourmet meals.
This research depended on the willingness of active and busy project managers who gave up
their time to be interviewed. It is ironic that the same privacy concerns that protect them also
prevent their public acknowledgement and thanks. To all of you I extend my heartfelt thanks.
Page iii
Table of contents 1 Introduction........................................................................................................................... 1
1.1 The problem................................................................................................................. 4 1.2 Scope ........................................................................................................................... 6 1.3 Research strategy......................................................................................................... 6 1.4 Contributions ............................................................................................................... 7
1.4.1 Theoretical contributions. ...................................................................................................... 8 1.4.2 Empirical contributions.......................................................................................................... 9
1.5 Outline of the Thesis.................................................................................................. 10 2 Project Management Mechanisms ...................................................................................... 12
2.1 Terminology .............................................................................................................. 12 2.1.1 Mechanism or practice or activity........................................................................................ 12 2.1.2 Contingency or factor........................................................................................................... 13 2.1.3 Distributed software development. ....................................................................................... 14
2.2 Project monitoring ..................................................................................................... 14 2.2.1 Introduction.......................................................................................................................... 15 2.2.2 Monitoring mechanisms. ...................................................................................................... 15 2.2.3 Monitoring in software development.................................................................................... 20 2.2.4 Summary............................................................................................................................... 24
2.3 Project Control........................................................................................................... 24 2.3.1 Introduction.......................................................................................................................... 24 2.3.2 Control mechanisms. ............................................................................................................ 26 2.3.3 Control mechanisms in software development projects. ...................................................... 29 2.3.4 Summary............................................................................................................................... 35
2.4 Project Coordination.................................................................................................. 35 2.4.1 Introduction.......................................................................................................................... 35 2.4.2 Coordination mechanisms.................................................................................................... 37 2.4.3 Coordination mechanisms in software development ............................................................ 40 2.4.4 Summary............................................................................................................................... 45
2.5 The classification of project management mechanisms ............................................ 46 2.6 Project Contingencies ................................................................................................ 46
2.6.1 Contingencies in prior research........................................................................................... 48 2.6.2 Project contingencies. .......................................................................................................... 53
2.7 Conclusion................................................................................................................. 69 3 Organizational distance....................................................................................................... 71
3.1 Distance within organizations ................................................................................... 71 3.2 Proposed model of organizational distance ............................................................... 73
3.2.1 Cultural distance .................................................................................................................. 74 3.2.2 Structural distance ............................................................................................................... 76 3.2.3 Administrative distance ........................................................................................................ 78 3.2.4 Summary............................................................................................................................... 81
3.3 The effect of organizational distance......................................................................... 81 3.3.1 Cultural distance. ................................................................................................................. 83 3.3.2 Structural distance ............................................................................................................... 86 3.3.3 Administrative distance ........................................................................................................ 90
Page iv
3.4 Conclusion................................................................................................................. 92 4 Research Design.................................................................................................................. 95
4.1 Research Questions ................................................................................................... 95 4.1.1 Which mechanisms do project managers use? ..................................................................... 96 4.1.2 Alternative research areas ................................................................................................... 97 4.1.3 The influence of organizational distance.............................................................................. 98
4.2 Knowledge claim....................................................................................................... 99 4.2.1 Research methods in existing studies ................................................................................. 100 4.2.2 Research methodology ....................................................................................................... 102 4.2.3 Data collection method ...................................................................................................... 103
4.3 Research instrument ................................................................................................ 104 4.3.1 Reviewing the research instrument .................................................................................... 106 4.3.2 Reliability ........................................................................................................................... 107
4.4 Research ethics ........................................................................................................ 107 4.5 Conducting the interviews ....................................................................................... 108 4.6 Sample selection...................................................................................................... 109 4.7 External validity ...................................................................................................... 110 4.8 Construct validity .................................................................................................... 110 4.9 Internal Validity....................................................................................................... 113 4.10 Conclusion............................................................................................................... 113
5 Analysis ............................................................................................................................ 115 5.1 Data sources and analysis ........................................................................................ 115
5.1.1 Structured interviews.......................................................................................................... 115 5.1.2 Content analysis ................................................................................................................. 116 5.1.3 Qualitative analysis............................................................................................................ 117
5.2 Statistical power ...................................................................................................... 117 5.3 Sample Characteristics ............................................................................................ 118
5.3.1 Organization size................................................................................................................ 118 5.3.2 Organizational Process Capability .................................................................................... 118 5.3.3 Process Improvement ......................................................................................................... 119 5.3.4 Project size ......................................................................................................................... 120 5.3.5 Outsourcing........................................................................................................................ 120 5.3.6 Managing outsourced development.................................................................................... 121
5.4 Project management mechanisms............................................................................ 122 5.4.1 Project Monitoring............................................................................................................. 122 5.4.2 Project control.................................................................................................................... 130 5.4.3 Project coordination........................................................................................................... 135
5.5 Organizational Distance .......................................................................................... 141 5.5.1 Cultural Distance ............................................................................................................... 142 5.5.2 Structural Distance ............................................................................................................ 144 5.5.3 Administrative Distance ..................................................................................................... 145 5.5.4 Relational Quality .............................................................................................................. 146 5.5.5 Organizational distance in the sample ............................................................................... 147
5.6 The effect of organizational distance....................................................................... 148 5.6.1 Project Monitoring............................................................................................................. 149
Page v
5.6.2 Project Control................................................................................................................... 153 5.6.3 Project Coordination.......................................................................................................... 159 5.6.4 Findings.............................................................................................................................. 164
5.7 Conclusion............................................................................................................... 165 6 Discussion ......................................................................................................................... 166
6.1 Project monitoring ................................................................................................... 166 6.1.1 Early warning systems........................................................................................................ 167 6.1.2 Multiple sources of information ......................................................................................... 167
6.2 Project Control......................................................................................................... 167 6.2.1 Preferred control mechanisms ........................................................................................... 168
6.3 Project Coordination................................................................................................ 169 6.3.1 Managing dependencies ..................................................................................................... 170
6.4 Portfolios of mechanisms ........................................................................................ 170 6.5 Organizational Distance .......................................................................................... 172
6.5.1 Robustness.......................................................................................................................... 173 6.5.2 Diminished importance of contingencies ........................................................................... 173 6.5.3 Project manager knowledge............................................................................................... 175 6.5.4 Lower level variation.......................................................................................................... 175
7 Conclusions, reflections and future research .................................................................... 177 7.1 Project management mechanisms............................................................................ 177
7.1.1 Precision ............................................................................................................................ 179 7.1.2 Research methods............................................................................................................... 181
7.2 Future research ........................................................................................................ 182 7.2.1 The meaning of project management ................................................................................. 182 7.2.2 The efficiency of project management mechanisms............................................................ 183 7.2.3 Varying usage of project management mechanisms........................................................... 184 7.2.4 The orientation of project management.............................................................................. 184
7.3 Utility of the research contributions ........................................................................ 185 Appendices................................................................................................................................ 188
Appendix A - Structured interview questions....................................................................... 188 Appendix B - Interview questions arranged by topic........................................................... 197 Appendix C - Consent Form ................................................................................................. 200 Appendix D - Content analysis form .................................................................................... 201 Appendix E - Publications .................................................................................................... 202 Appendix F – Research Tools............................................................................................... 203
Page vi
List of figures Figure 1: Comparison of fixed and variable costs for different monitoring mechanisms........... 16 Figure 2: The classification of coordination mechanisms - from Sabherwal (2003) .................. 37 Figure 3: Task interdependence - coordination strategy. An organic coordination strategy is
more successful as the tasks become more interdependent. From Andres and Zmud (2002)............................................................................................................................................ 38
Figure 4: Goal conflict - coordination strategy. A mechanistic coordination strategy is more successful as project goals are increasingly in conflict. From Andres and Zmud (2002)... 39
Figure 5: Eisenhardt's proposed model of control strategy selection (Eisenhardt, 1985) ........... 49 Figure 6: Model of project mechanism fixed and variable costs - Adapted from Sabherwal
(2003).................................................................................................................................. 53 Figure 7: Relationship between distance and communication frequency. .................................. 77 Figure 8: Relationships between organizational distance factors, project management
contingencies and project management mechanisms.......................................................... 82 Figure 9: Areas of potential research arising from the theoretical model of organizational
distance, project contingencies and project management mechanisms............................... 96 Figure 10: Percentage of project managers who use each project monitoring practice. ........... 123 Figure 11: Frequency of multiple monitoring practices............................................................ 124 Figure 12: Frequency with which different monitoring mechanisms are employed................. 126 Figure 13: Trade-off between functionality, quality and performance over schedule when the
schedule is threatened ....................................................................................................... 132 Figure 14: Actions taken when project schedule is threatened. ................................................ 132 Figure 15: Frequency of control mechanisms used by software development project managers.
.......................................................................................................................................... 133 Figure 16: Relative frequency with which different coordination mechanisms are used.
Expressed as a percentage of all cases. ............................................................................. 139 Figure 17: Number of projects that use different forms of meetings and reviews.................... 161 Figure 18: Database design showing relations between hypotheses, research questions and
interview questions ........................................................................................................... 204
Page vii
List of tables Table 1: Example monitoring mechanisms arranged to illustrate the expense of information
gathering. ............................................................................................................................ 17 Table 2: Hughes and Cotterell’s (1999) classification of project report types according to
formality and reporting medium. ........................................................................................ 18 Table 3: Examples of dependencies given by Malone and Crowston ........................................ 36 Table 4: Adler (1995) typology of design/manufacturing coordination mechanisms................. 38 Table 5: Coordination by standards ............................................................................................ 41 Table 6: Coordination by plans................................................................................................... 42 Table 7: Coordination by formal mutual adjustment .................................................................. 44 Table 8: Coordination by informal mutual adjustment. .............................................................. 45 Table 9: Classification schema for project management mechanisms used in software
development........................................................................................................................ 46 Table 10: The conditions determining the measurement of behaviour and of output (Ouchi,
1979). .................................................................................................................................. 48 Table 11: The expected effect of task programmability on project mechanisms........................ 57 Table 12: The expected effect of increased task visibility on project management mechanisms.
............................................................................................................................................ 58 Table 13: The expected effect of increased output measurability on project management
mechanisms......................................................................................................................... 60 Table 14: The expected effect of increased risk on project management mechanisms. ............. 62 Table 15: The expected effect of increased relational quality on project management
mechanisms......................................................................................................................... 66 Table 16: The effect of cost on project management mechanisms. ............................................ 68 Table 17: Summary of the expected effect of increasing contingency on project management
mechanisms......................................................................................................................... 70 Table 18: Napier and Ferris Dimension of Dyadic Distance in Supervisor-Subordinate
Relationship ........................................................................................................................ 72 Table 19: Proposed model of organizational distance between project manager and project team
members.............................................................................................................................. 74 Table 20: The expected changes in project management contingency as organizational distance
increases. ............................................................................................................................. 93 Table 21: Expected relationship between organizational distance and the use of project
management mechanisms. .................................................................................................. 94 Table 22: Empirical studies of control or coordination in software development .................... 101 Table 23: Example questions from the structured interview script showing an ordinal scale of
responses and a nominal list of potential responses.......................................................... 105 Table 24: Organization size in the sample. ............................................................................... 118 Table 25: Organization process capability assessed through a very low rigour assessment
method. ............................................................................................................................. 119 Table 26: Process improvement showing organizational commitment. ................................... 119 Table 27: Project size estimated by budget or equivalent......................................................... 120
Page viii
Table 28: Distribution of outsourced development and contractor staff................................... 121 Table 29: Correlations between organizational size, project size and process capability......... 122 Table 30: Groupings of methods of determining if a project is "on track" or "off track"......... 123 Table 31: Correlations between the number of monitoring practices used by project managers
and organizational characteristics. .................................................................................... 124 Table 32: Frequency of monitoring mechanisms detected with content analysis..................... 125 Table 33: Organizational criteria for project success............................................................... 131 Table 34: Frequency of control mechanism used by software development project managers.133 Table 35: Actions taken when requirements prove unimplementable or unexpectedly difficult.
.......................................................................................................................................... 136 Table 36: Actions taken when a task is taking longer than expected........................................ 137 Table 37: Actions taken when a task is taking longer than expected........................................ 137 Table 38: Frequency of formal management review of projects. ............................................. 138 Table 39: Frequency of coordination mechanisms detected through content analysis. ............ 138 Table 40: Raw data for deducing organizational distance. ....................................................... 142 Table 41: Cultural distance between project manager and project sub-team............................ 143 Table 42: Distribution of structural distances between project manager and sub-team............ 144 Table 43: Incidence of administrative separation between project manager and distant sub-team
members. ........................................................................................................................... 145 Table 44: Incidence of relational quality activities by project managers.................................. 147 Table 45: Organizational distance between project managers and the most distant part of the
project team....................................................................................................................... 148 Table 46: Indicators of project progress grouped by organizational distance........................... 149 Table 47: Pearson correlations between organizational distance and different monitoring
mechanisms from structured interview data. .................................................................... 149 Table 48: Number of monitoring mechanisms vs. organizational distance from interview
content analysis. ................................................................................................................ 150 Table 49: Monitoring mechanisms expressed as a percentage within organizational distance
category............................................................................................................................. 150 Table 50: Pearson correlation between organizational distance and types of monitoring
mechanisms....................................................................................................................... 151 Table 51: Software development capability levels related to organizational distance.............. 153 Table 52: The formality of project planning distributed over organizational distance. ............ 154 Table 53: Formality of schedule planning distributed over organizational distance. ............... 155 Table 54: Frequency of project success criteria. ....................................................................... 155 Table 55: Potential correlations between organizational distance and input control. ............... 156 Table 56: Distribution of the number of each control type across organizational distances..... 157 Table 57: Distribution of control types expressed as a percentage within an organizational
distance category............................................................................................................... 157 Table 58: Pearson correlations between organizational distance and control mechanism........ 157
Page ix
Table 59: Adjusting the project in response to task completion delays. Expressed as a percentage of all responses for the action. ........................................................................ 160
Table 60: Frequency of coordination mechanism vs organizational distance. ......................... 161 Table 61: Coordination mechanism usage as a percentage of mechanisms within each
organizational distance category....................................................................................... 162 Table 62: Correlations between organizational distance and the number of coordination
mechanisms employed. ..................................................................................................... 162 Table 63: Different project management mechanisms showing the usage frequency and different
objectives each might serve. ............................................................................................. 172
Page x
Abbreviations, Acronyms
4GL Fourth Generation Language
CMM Capability Maturity Model
CMMI Integrated Capability Maturity Model
COTS Commercial Off The Shelf
CSCW Computer supported cooperative work
ICT Information and communication technology
IDE Integrated development environment
IS Information systems
IT Information technology
PMBOK Guide to the Project Management Body of Knowledge
PMIS Project Management Information System
PSEE Process-centred Software Engineering Environment
QA Quality Assurance
RFP Request for Proposal
SPICE Software Process Improvement and Capability dEtermination
TQM Total Quality Management
Abbreviations, Acronyms, Glossary
Page xi
Glossary Adverse selection
A transaction in which the seller has relevant information that the buyer does not have, or vice versa. Also refers to the tendency for buyers or sellers to exploit these asymmetries in information to their own advantage. For example, someone with a dangerous occupation or hobby may be more likely to apply for life insurance. www.agtrade.org/defs.cfm
Contingency A term used to identify the few factors that significantly affect outcomes. For example, organizational contingency theory examines the fit between a few variables, usually risk or uncertainty, and organization structure (Lawrence and Lorsch, 1967; Mintzberg, 1979; Perrow, 1986). In statistical terms, the variables would properly be called “mediating variables”. A common term in popular usage is “critical success factor” with the achnowledgement that a contingency or mediating variable is not necessarily associated with success. This term is discussed in Section 2.1.2.
Control To exercise restraint or direction upon the free action of; to hold sway over, exercise power or authority over; to dominate, command. Oxford English Dictionary Online.
In the context of software development project management it is to restrain and direct activities to achieve the projects goals.
Coordination Coordination has been defined as the direction of "individuals’ efforts toward achieving common and explicitly recognized goals" and "the integration or linking together of different parts of an organization to accomplish a collective set of tasks" (Kraut and Streeter, 1995).
Managing the dependencies between activities. (Malone and Crowston, 1994)
Managing the distribution of tasks among those who will perform various activities to perform those tasks, then managing the resources and activities to produce the component parts of the product so that they integrate into a complete whole.
COTS COTS is an acronym for Commercial Off The Shelf. It refers to hardware and software systems that are manufactured commercially and then tailored for specific uses. This is in contrast to systems that are produced entirely and uniquely for the specific application. (http://en.wikipedia.org/wiki/COTS accessed 19 July 2004)
Emergent property
Characteristics that emerge at a level of a system hierarchy but which do not appear at the level below it.
Emergent entities (properties or substances) ‘arise’ out of more fundamental entities and yet are ‘novel’ or ‘irreducible’ with respect
Abbreviations, Acronyms, Glossary
Page xii
to them. Stanford Encyclopaedia of Philosophy
In systems that are sufficiently complex, properties emerge that cannot be reduced to the constituent elements of the system.
Governance The act or manner of conducting the policy and affairs of an organization; the control or influence of people; constituting a rule, standard or principle. www.vcn.bc.ca/volbc/tools/glossary.html The action or manner of governing (see senses of the vb.); the fact that (a person, etc.) governs. Oxford English Dictionary
Horizontal coordination
The extent to which coordination is undertaken through mutual adjustment and communication between users and IS staff (Nidumolu, 1995).
Mechanistic coordination strategy
Coordination achieved through formal, controlling and centralised means (Shenhar, 2001; Andres and Zmud, 2002).
Monitor To observe, supervise or keep under review; to keep under observation; to measure or test at intervals, especially for the purpose of regulation or control. Oxford English Dictionary Online
Moral hazard The risk that a party to a transaction has not entered into a contract in good faith, has provided misleading information about its assets, liabilities or credit capacity, or has an incentive to take unusual risks in a desperate attempt to earn a profit before the contract settles. www.frbsf.org/tools/gloss.html
Organic coordination strategy
Coordination achieved through informal, decentralised and coorperative means (Shenhar, 2001; Andres and Zmud, 2002).
Organizational distance
A measure of the cultural, structural and administrative separation between different members of a project team. This term is described more fully in Chapter 3.
Outsourcing Obtaining goods or services from an outside (the organization) source. Oxford English Dictionary.
Vertical coordination
The extent to which coordination between users and IS staff is undertaken by authorized entities such as project managers and steering committees (Nidumolu, 1995).
Page xiii
ABSTRACT This thesis describes empirical research into project management of software development.
Specifically, the aim of the research is to investigate how project managers monitor, control and
coordinate software development tasks and how this is affected by changing environments, in
this case increased organizational distance between the project manager and elements of the
project team. Differing project environments allow investigation into which project
management mechanisms are essential, which are required in specific circumstances and which
may be useful but not necessarily essential.
To explore how software development projects are monitored, controlled and coordinated, a
broad range of literature from software development and other fields such as organization
theory, supply chain management and automobile manufacture is examined to establish a
consensus of the mechanisms of project monitoring, control and coordination and their
classification into groups. To better understand how the different mechanisms may be selected
in different circumstances, a range of contingencies is examined to deduce which of these
contingencies may significantly affect the project management of software development
projects.
Outsourced and distributed software development projects are becoming more frequent than in
the past with consequent effects on project management practices. Although there has been
some research into the ways in which project managers monitor, control and coordinate
software development projects, little of it has investigated how the mechanisms employed to do
so may be affected by such factors as increasing organizational distance. If more were known
about the ways in which changed project environments affected the selection and use of project
management mechanisms, better responses to those environmental changes could be devised.
This could also identify where tools could be developed to assist project management of
outsourced and distributed projects.
In this research, the term ‘organizational distance’ is used to describe the cultural, structural and
administrative distance between the project manager and elements of the project team. Since
there is limited information available on the concept of organizational distance, a new model is
developed that encompasses the dimensions of distance that may be found in outsourced or
globally distributed projects. A second model is then developed that relates changes in the
factors of organizational distance with preferred choices of project management mechanism via
project contingencies.
Empirical data were collected by structured interviews with project managers who were
currently engaged in software development within Sydney, Australia. The method of collecting
Abstract
Page xiv
the data provided both quantitative and qualitative data that enabled three separate ways to
investigate the research questions.
The empirical research found that project managers do not rely on a single mechanism to
monitor, control or coordinate a software development project but employ multiple mechanisms.
While the portfolio of mechanisms for both monitoring and control comprised a relatively
narrow selection, the portfolio of coordination mechanisms was more diverse.
Project monitoring mechanisms were employed to first detect any project problems then to
respond to those problems. This contrasts with monitoring systems designed to provide all the
information about both the existence and probable causes of project problems.
Project control mechanisms reflected the origin of the control. The constraints imposed on the
project by the organization and used by the project manager to direct the project tended to be
outcome related, for example budget and schedule. The behaviour of the project team, even
across significant organizational distances, was controlled through the use of project plans that
determined when different tasks would be performed.
Project coordination mechanisms reflected the different types of dependencies between software
development activities. The most common was using a project work breakdown structure,
expressed in the project schedule, to resolve sequential and pooled resource dependencies.
Mutual dependencies tended to be resolved using interactive mechanisms such as co-location,
conversations and meetings.
The empirical evidence did not find any difference between co-located projects and distributed
projects so far as the choice of project management mechanisms were concerned. Distributed
and globally outsourced software development projects may encounter many difficulties that a
fully co-located project does not, but the response to those difficulties appears to lie with the
implementation of project management mechanisms and not their selection.
Page 1
1 Introduction The modern form of project management has developed since its first use on the Polaris
submarine projects of the 1950s (Shenhar, 1999). Different specializations have emerged from
the general form of project management as typified by the Guide to the Project Management
Body of Knowledge (PMBOK) (Project Management Institute, 2000). In particular the project
management of software development has been the subject of numerous books, e.g. Hughes and
Cotterell (1999), McConnell (1998), Thomsett (2002a), journal articles (Zmud, 1980; Hofstede,
1983a; Boehm and Ross, 1989; Wolf, 1989; Henderson and Lee, 1992; Saunders, 1992; Boehm,
1999) as well as innumerable conference papers.
Project management is defined by the PMBOK as “the application of knowledge, skills, tools,
and techniques to project activities to meet the project requirements”. In addition, project
management is a management activity that, like any other management activity, is intended to
resolve the “fundamental and opposing requirements: the division of labour into various tasks to
be performed and the coordination of those tasks to accomplish the activity” (Mintzberg, 1979
p2). In general, dividing the work into various tasks requires that the project activities be
planned, estimated and have resources allocated to them before being scheduled. This is a
significant and identifiable part of project planning in contrast to coordinating the project
activities, which is pervasive but often assumed. The PMBOK specifically acknowledges the
need to coordinate the various elements of the project both during project plan development and
during project execution. Other texts on project management e.g. Hughes and Cotterell (1999),
typically tend to assume that coordination is an underlying purpose for many project
management activities.
Having divided the project’s work into separate tasks, their execution must be controlled to
ensure that they are carried out at a time and in a manner that will achieve the task objectives
and, ultimately, the project objectives. To that end, the project manager must monitor, control
and coordinate project activities. The specific activity, technique or other means of monitoring,
controlling or coordinating the project activities will depend on the circumstances, including the
industry, the project attributes and the knowledge and skills of the project manager.
Software development projects share many of the characteristics of all projects. However,
software development has some attributes that distinguish it from all other endeavours. Brooks
Introduction
Page 2
(1995) identified four essential characteristics of software entities: complexity, conformity,
changeability and invisibility. Kraut and Streeter (1995) also identified four characteristics but
specifically relevant to coordination of software development rather than the general activity of
software development. The four characteristics were scale, uncertainty, interdependence and
informal communication. That a software product is complex does not mean that software
development itself is complex, or more complex than other industries, but does contribute to the
risk that the development may fail in some way. Uncertainty refers to the unpredictability of
both the software and the task, principally because most software development is non-routine
(Kraut and Streeter, 1995). Furthermore, Kraut and Streeter argue, uncertainty increases because
the “specifications of the software’s functionality changes over time”. Brooks refers to the same
phenomenon as “changeability” arising from changing circumstances surrounding the product
as well as changed usage of the product. Brooks acknowledges that while other products are
also subject to the same pressure to change, software is seen to be more malleable and is
therefore expected to change. Brooks’ “conformity” and Kraut and Streeter’s interdependence
refer to similar characteristics, that of software needing to interface within itself and to the
world around it. Brooks points out that many of the systems that software must conform to or
interface with were developed independently and show no consistency of approach, design or
function. Kraut and Streeter point to the precise interdependence of a software system’s
components in contrast to, say, the less precise interdependence of a building’s components.
These characteristics of software and software development influence how software is
developed, the strategies employed to manage software development projects, and the
mechanisms employed to monitor, control and coordinate those projects. Software development
projects do not proceed in a series of set plays like a game of tennis, planning followed by a
brief period of doing. A project cannot be halted arbitrarily while the participants plan their next
move. Rather, once the project has been launched it must continue and project managers must
deal with the ever changing project yet still guide it toward its goals.
Project monitoring, control and coordination are achieved through different activities,
techniques, tools or organizational structures depending on the circumstances. Malone and
Crowston (1994) established a framework with which to investigate the general problem of
coordination, Bailetti et al. (1994) offered an alternative structure and Kraut and Streeter (1995)
investigated the different ways in which formal and informal coordination was achieved in
software development projects. Faraj and Sproull (2000) investigated how expertise was
coordinated in software development teams.
Control has also been researched in the general context of projects (Milosevic, 1987; Saunders,
1992; Kornelius and Wamelink, 1998; Cleland and Ireland, 2002; Cooke-Davies, 2002; Lientz
Introduction
Page 3
and Rea, 2003) and in the specific context of software development projects (Wolf, 1989;
Henderson and Lee, 1992; McConnell, 1998; Hughes and Cotterell, 1999; Addison and Vallabh,
2002; Choudhury and Sabherwal, 2003).
Project monitoring is more often perceived as part of or in support of project control so there is
little specific information available. Nevertheless, project monitoring mechanisms have been
studied in general, usually in terms of the range of measures that may indicate a project’s
current state rather than the mechanisms by which monitoring may be performed (Shumate and
Snyder, 1994; Bendeck et al., 1998; Chan et al., 1999; Al-Jibouri, 2003; Lientz and Rea, 2003;
Kadefors, 2004).
Simply investigating the selection of a portfolio of project management mechanisms would not
reveal which of those mechanisms are necessary, which are redundant, which have greater or
lesser utility or, indeed, much about the reasons why they were selected. To examine how
particular portfolios of mechanisms are selected and the influences on their selection, it is
necessary to examine project management under different circumstances. Varying the
organizational distance between the project manager and some part of the project team provides
such changing circumstances that may reveal reasons for and influences on the selection of
portfolios of project management mechanisms. In this research organizational distance,
discussed in Chapter 3, is a measure of the cultural, structural and administrative distance
between a project manager and members of the project team.
Stretching the organizational distance between the project manager and the project team should,
theoretically, stress the project management mechanisms and may reveal which mechanisms are
more robust or which have greater range. The stress may also reveal which mechanisms are
commonly used at one end of the organizational distance dimension but are discarded toward
the other end. This research chose to investigate the dispersion of the development team since
outsourcing arrangements are becoming increasingly common and more complex (Gallivan and
Oh, 1999).
The choice of specific project management mechanisms in specific circumstances has been
investigated (Nidumolu, 1996; Donaldson, 2001; Andres and Zmud, 2002; Chenhall, 2003), as
has the ways in which the collection of project control mechanisms change and evolve over the
life of the project (Doz, 1996; Bresnen and Marshall, 2002; Choudhury and Sabherwal, 2003;
Sabherwal, 2003; Bowles and Gintis, 2004).
Most research so far has concentrated on either project monitoring or project control or project
coordination and, despite Sabherwal’s (2003) acknowledgement that control and coordination
are inter-related, few studies consider the interaction of monitoring, control and coordination.
Introduction
Page 4
This research investigates the mechanisms with which project managers monitor, control and
coordinate software development projects. Project management mechanisms are unlikely to be
equally useful or equally favoured and some knowledge of which mechanisms project managers
use would help when reasoning about, among other things, aids to project management. Then, in
an attempt to separate the essential from the coincidental, the research investigates whether and
how the selection of project management mechanisms changes as organizational distance
increases. Stressing the management of a project by inserting some organizational distance
between the project manager and elements of the project should reveal which project
management mechanisms are situation-specific and which are not.
1.1 The problem Software development is increasingly being carried out not by a single, co-located team but by a
collection of different groups with different skills located in different parts of the world (Carmel,
1999). Software development begins to resemble building construction with a prime contractor
who employs specialists, either as individuals or as contracting organizations supplying whole
teams (Kornelius and Wamelink, 1998). Team members can come from the supplier, the client,
specialist consultants or any one of a number of other places. They may all be co-located or
widely, even globally, dispersed. The effect of these changes in team makeup on project
management is not yet widely investigated, being confined to a small number of experience
reports (Borchers, 2003) and case studies (Gwynne, 1995; Solomond, 1996; Nicholson and
Sahay, 2001; Chevrier, 2003).
Obtaining goods or services from an outside source, or outsourcing (OED, 2003), is far from
new. Machiavelli (1514) thought that outsourcing was not a good idea.
“Mercenaries and auxiliaries are useless and dangerous. If a prince bases the defence
of his state on mercenaries he will never achieve power. For mercenaries are disunited,
thirsty for power, undisciplined, and disloyal; they are brave among friends and
cowards before the enemy; they have no fear of God, they do not keep faith with their
fellow men; they avoid defeat just so long as they avoid battle; in peacetime you are
despoiled by them, and in wartime by the enemy. The reason for all this is that there is
no reason to keep them on the field apart from the little they are paid, and this is not
enough to make them want to die for you.” Machiavelli, The Prince
Clearly, reward systems and control systems have advanced since Machiavelli’s time. However,
distributing software development projects over local staff and outsourced suppliers, some of
Introduction
Page 5
whom may be quite distant, places challenges on the established knowledge of project
monitoring, control and coordination.
Tools and techniques needed for distributed software development have been widely
investigated (Hawryszkiewycz and Gorton, 1996; Gorton et al., 1997; Perpich et al., 1997;
Grundy et al., 1998; Chan et al., 1999; Caldwell et al., 2000; Espinosa et al., 2001), as have the
mechanisms for coordinating distributed development (Jyi-Shane and Sycara, 1996; Grundy et
al., 1998; Herbsleb and Grinter, 1999a; Herbsleb and Grinter, 1999b; Chen and Luh, 2000).
Some investigation has been directed at workflow systems for distributed software development
(Van Der Aalst, 1998; Baker et al., 1999; Godart et al., 2000; Maurer and Zannier, 2001; Zhuge,
2002; Zhuge, 2003). However, the research into distributed software development has not yet
considered how the mechanisms for project monitoring, control and coordination are selected or
how they may be affected by increasing organizational distance between the project manager
and the project team.
Given the difficulties of increased project management costs, schedule delays and project
rework that have been encountered with outsourcing (Huber, 1993; Earl, 1996; Lacity and
Willcocks, 1996; Berggren et al., 2001; Travis, 2004) and with global software development
(Cramton, 1997; Dube and Robey, 1999; Nicholson and Sahay, 2001; Carmel and Agarwal,
2002), it may seem self evident that managing a fragmented and distributed project requires
different practices than managing a co-located project. However, the exact nature of any
required differences is less well known.
One of the problems facing project management, and the focus of this research, is whether
outsourced and globally distributed software development projects require different project
management mechanisms to monitor, control and coordinate the project activities and the nature
of any such differences. If such different requirements for project management were exposed
and understood, it may support more effective project management practices and may set the
direction for project management tools that would assist distributed software development
projects.
To investigate these problems, research questions, discussed more fully in Section 4.1, are
identified as:
RQ1: Which mechanisms do project managers use to monitor, control and
coordinate software development projects?
RQ2: Is there a relationship between the organizational distance between the
project manager and elements of the project team and the selection of project
management mechanisms?
Introduction
Page 6
1.2 Scope This research investigates project monitoring, control and coordination in software development
during the project’s development phase. It concentrates on the development phase because that
is when the project is subject to the unexpected events and external influences that require the
project manager to take action to keep the project moving toward its objectives. It does not
investigate project planning or any other activity that might be undertaken by the project
manager prior to the start of actual software development activities because project management
during that phase is concerned with producing the project plan, not developing the software. Nor
does the research investigate activities undertaken after the software’s development such as
deployment or support and maintenance for similar reasons. Concentrating on the development
phase means that project managers of all projects are likely to consider the same range of
project management mechanisms, the choice of which is likely to be subject to a similar range
of influences.
The focus of this research is on project monitoring, controlling and coordinating software
development tasks and consigns other project management activities to the background. A
project manager may be involved in recruitment, procurement, training, risk management, reuse,
knowledge management and a range of other activities required to complete the project but they
will not be directly investigated except in relation to how they may affect monitoring, control
and coordination of the project.
1.3 Research strategy The aim of this research is to determine how project managers monitor, control and coordinate
software development projects and how this is affected by a changed environment, specifically
how this varies as organizational distance increases between the project manager and those
performing the tasks. If project management mechanisms need to differ as organizational
distance increases, or as project management is stressed in some other way, then understanding
how different circumstances favour selecting different project management mechanisms should
reduce the risk that an inappropriate mechanism is used with detrimental consequences to
project.
The research was divided into roughly three phases. The first year was spent reviewing project
management literature and a range of subjects related to project management such as agent-
based systems and supply chain management, as well as project management in a range of
industries. This wide range of literature reflects a view that while software development may
Introduction
Page 7
have some unique characteristics, it is also shares a number of characteristics with other fields,
such as building construction, car manufacture or supply chain management1.
In the first year, time was also spent learning about research methods and developing the
research method and instrument. The second year was spent collecting the data and doing some
preliminary analysis. The third year was spent performing the data analysis and preparing this
thesis.
The mechanisms of project monitoring, control and coordination are reasonably well known so,
rather than seeking to discover what they are, this research set out to discover which
mechanisms project managers actually use. However, project management is not typically
discussed in terms of coordination mechanisms or control mechanisms and questions about how
a project manager coordinated a project may not receive as direct and accurate an answer as, for
example, a question about which design review technique they used. For this reason data were
collected through interviews where both question and answer could be clarified.
While it would be possible to conduct empirical research to confirm relationships between the
contingencies (Section 2.6) and the choice of project management mechanism, it would require
a large research project to gather all the data necessary to cover the number of contingencies and
their possible combinations. It would be more efficient to use a particular setting, such as
distributed software development, to reason about the expected effects of that changing
environment on the selected contingency factors and, consequently, on the choice of project
management mechanism.
1.4 Contributions Previous research has investigated control portfolios (Choudhury and Sabherwal, 2003) and
coordination mechanisms (Sabherwal, 2003) where the software was developed by a supplier
organization for a client. In both cases, there was no indication that any of the software
development was performed by anyone other than the supplier organization. The adopted
1 The research was also informed by my previous experience in software development and project management gained over several years of commercial employment, as well as experience gained while developing international standards concerned with software engineering. Most of the development projects in which I was directly involved were technical projects, as opposed to information systems. For example, they included some early telecommunications interfaces, expert systems that dealt with building construction or consumer credit lending, and a railway yard control system among others. Although some of my experience did include maintaining parts of a banking system, it could hardly be said to amount to a commercial information system. Most of the projects were relatively small, involving a team of less than 10 and taking 2 years at most. I have never been involved in a software development project that took more than three years or cost more than $10M.
Introduction
Page 8
perspective was independent of both the client and the supplier and simply identified control or
coordination mechanisms employed without identifying who employed them or initiated their
use.
Previous research has also separately investigated the different mechanisms of control in
software development (Henderson and Lee, 1992; Kirsch, 1996) and coordination in software
development (Kraut and Streeter, 1995; Hawryszkiewycz and Gorton, 1996; Bendeck et al.,
1998; Cruz and Tichelaar, 1998; Herbsleb and Grinter, 1999a; Herbsleb and Grinter, 1999b;
Faraj and Sproull, 2000; Mockus and Herbsleb, 2001) but there is little, if any, research into the
combination of monitoring, controlling and coordination in software development. This research
investigates how project managers employ combinations of mechanisms to achieve all three:
monitoring, controlling and coordination. The contributions of this research are both theoretical
and empirical.
1.4.1 Theoretical contributions. An extensive literature search was conducted to identify the different mechanisms used to
monitor, control and coordinate software development projects. Candidate classifications of the
different mechanisms were considered before developing a scheme that was not biased toward
either monitoring or control or coordination. It was important that the classification categories
were of an appropriate granularity to investigate the mechanisms, being neither so fine that too
much detail was required nor so coarse that nothing useful could be concluded. The resultant
classification scheme is shown in Table 9, section 2.5.
Contingencies that, potentially, influence the choice and use of project management
mechanisms were investigated. Identifying contingencies might allow research to investigate
how something indirectly affects project management mechanisms. The set of identified
contingencies is discussed in Section 2.6 and the expected effect of increases in the magnitude
of each of the contingencies on the choice of each type of project management mechanism is
presented in Table 17, Section 2.7.
The concept of organizational distance is investigated, existing models identified and discussed,
and a modified model of organizational distance, better suited for investigating distributed and
outsourced software development, is proposed. The model is presented in Table 19.
A model is developed that links the factors of organizational distance to their effects on the
contingencies of project monitoring, control and coordination mechanisms, and the influence of
the contingencies on the choice of mechanisms. This model is presented in Figure 8. Using the
device of project management contingencies allows greater flexibility than a model that only
Introduction
Page 9
considered the direct effect of organizational distance on the choice of project management
mechanisms. It allows investigation into the relationship between contingencies and the choice
of project management mechanism, and investigation into the relationship between
organizational distance and project management contingency. Such an interface is a common
design feature in software development to protect a component from changes in its external
environment and results in a flexible, modifiable system. In the same way, the interface of
project management contingencies between organization distance and the choice of project
management mechanism allows organizational distance to be replaced by a different
environmental factor, such as software development technology, whose relationship to the
project management contingencies can be investigated more easily than their relationship with
the choice of project management mechanism. The model potentially allows predictions to be
made about the effect of any number of environmental factors on the choice of project
management mechanisms through considering their effect on project management contingencies.
1.4.2 Empirical contributions Empirical research was conducted by interviewing project managers actively engaged in
software development and closely related activities to identify how they monitored, controlled
and coordinated their projects. The resulting data are analysed and the findings presented.
To overcome anticipated threats to internal validity of the findings, due to the comparatively
small sample size, data analysis included quantitative analysis of interview question responses
according to the nominal or ordinal scales that had been developed as part of the research design,
quantitative analysis of the interview transcript content, and qualitative analysis of the interview
transcripts. Taken together, the different analyses contribute toward more robust findings than if
only one analysis method had been employed.
The selection and use of project management mechanisms is investigated. The analysis and
findings are presented in Chapter 5 (Section 5.4) and discussed in Chapter 6 (Section 6.1, 6.2,
6.3). Several researchers have previously investigated which control mechanisms or
coordination mechanisms were used in specific circumstances but there does not appear to have
been an investigation that considered all three mechanisms of project monitoring, control and
coordination.
Organizational distance between the project manager and the most remote element of the project
team was analysed according to the theoretical model of organizational distance (Table 19). The
findings are presented in Section 5.5. The classification of project organizational distance in the
collected data thus deduced was used for the remaining analysis of relationships between
organizational distance and the use of project management mechanisms.
Introduction
Page 10
The relationship between organizational distance and project management mechanism use is
investigated. The mechanisms of monitoring, control and coordination are analysed separately,
using the three different analysis methods, for evidence of relationships between organizational
distance and the choice of different project management mechanism. The findings are presented
in Chapter 5 (Section 5.6) and discussed in Chapter 6 (Section 6.5)
1.5 Outline of the Thesis The rest of this thesis will investigate how project managers monitor, control and coordinate
software development projects and how this varies as organizational distance increases.
Chapter 2. This establishes the current state of knowledge about the different mechanisms used
to monitor, control and coordinate project activities in a wide range of fields to identify which
of them are used in software development projects. The contingencies that favour the different
mechanisms are also investigated so that the effect of increasing organizational distance can be
anticipated.
Chapter 3. Existing models and related knowledge about organizational distance are
investigated to determine whether existing models of organizational distance may be used in
this research. A modified model is proposed and discussed so that the expected effects of
increasing organizational distance on project management contingencies can be deduced.
Chapter 4. The model relating organizational distance to project management mechanisms via
project contingencies is examined and areas of potential research are discussed. A research area
is chosen and research methodologies discussed to decide which methodology and research
method is best suited to investigate the research questions. The research method is described.
This begins by summarising the research methods to date used to investigate software
development. This is done to gauge the appropriateness of using structured interviews in this
research. The choice of structured interviews is briefly justified then the logistics of conducting
the interviews, transcribing and reviewing the transcript is described. Research ethics that
governed this research are presented. Sample selection is discussed as is the research instrument,
its development and review. Construct validity, internal validity and reliability are also
discussed.
Chapter 5. The data are analysed. This proceeds by first reviewing the sample characteristics
and discussing external validity. Then the different sources of data, structured interview data
and interview transcript data, is discussed. This is followed by analysis of the data to determine
whether and how organizational distance affects the mechanisms of monitoring, control and
coordination.
Introduction
Page 11
Chapter 6. The analysis findings are discussed to establish what can be concluded about the use
of project management mechanisms and how their selection alters as organizational distance
increases.
Chapter 7. The conclusions are presented and I reflect on this research, describing two insights
that would influence any future research. Future work arising from this research is also
described.
Appendices. Five appendices are included. First, the structured interview questionnaire shows
the text of the interview questions and an indicative list of potential responses to each question.
The structure of the questionnaire and indicative responses is discussed in Section 4.3.
Appendix B rearranges the interview questionnaire to show the interview questions by research
topic. This simply illustrates the coverage of each research topic and was used to check that
adequate data was sought for each topic within the constraints if interviews. Appendix C shows
the “Consent Form” used to gain informed consent from each research participant, as required
by this institute’s research guidelines. Appendix D shows an example of the form used to
analyse each interview transcript for different project management mechanisms used by the
interview subject in managing their projects. Appendix E lists the publications to date arising
from this research.
Page 12
2 Project Management Mechanisms Before relationships between project management mechanisms and organizational distance can
be examined, it is necessary to establish what project management mechanisms are and what
influences their use. There are many potential ways to group and classify things that can affect
the ease with which they might be examined. Clearly, having no classification scheme would
not be useful because each mechanism would have to be considered separately. At the same
time, any classification scheme must be generally acceptable to others working in the same field.
This chapter proceeds by first discussing terminology, then describing the different project
management mechanisms of monitoring, control and coordination in turn. Each is identified and
described from the general literature; then the use of the mechanism in software development is
described. Going from the general to the specific in this way allows implementations to be
identified that are specific to software development.
To avoid needing to consider what affects the selection and use of each separate group of
project management mechanisms, this research adopts the stance that there are a number of
factors, or contingencies, that explain most of the variance (Nidumolu, 1996; Gemuenden and
Lechler, 1997; Shenhar, 2001; Andres and Zmud, 2002; Cooke-Davies, 2002). A set of
contingencies is identified from the available literature and the expected effect of changes in
each of the contingencies on project management mechanisms discussed. This enables a general
model of project management mechanisms to be proposed that can be used to examine the effect
of any environmental variable.
2.1 Terminology
2.1.1 Mechanism or practice or activity Project monitoring, control and coordination can be achieved in a variety of ways: through
activities, constraints on those activities, the organization structure within which the activities
are performed or through the structure of the project. The collective term used to group the
different ways depends on the field of study. Researchers of project control simply call them
“controls” (Ouchi and Maguire, 1975; Eisenhardt, 1985; Kirsch, 1996; Hamilton and Kashlak,
Project Management Mechanisms
Page 13
1999; Faraj and Sproull, 2000; Choudhury and Sabherwal, 2003)). Researchers of coordination
have used “mechanism” (DeSanctis and Jackson, 1994; Malone and Crowston, 1994; Adler,
1995; Crowston, 2003; Sabherwal, 2003) or “techniques” (Kraut and Streeter, 1995). Other
researchers have not distinguished project coordination from the means by which it is
accomplished so use the term “coordination” (Bailetti et al., 1994; Andres and Zmud, 2002).
Those researchers who study project monitoring separately from project control (Kitchenham
and Walker, 1989; Witting et al., 2003) normally use the term “monitor” or the term “measure”
to describe information gathering activities.
This research needs a term that can serve all three areas and can include both the activities that a
person may perform or the means by which they perform them or can describe something like
an organizational constraint that is outside both the project and the person. The term
“mechanism” is general enough yet conveys the concept of a means by which something is
accomplished. For that reason the term “mechanism” will be used in this research both in the
general sense of project management mechanism or in the specific sense of monitoring
mechanism, control mechanism or coordination mechanism.
2.1.2 Contingency or factor A similar terminology difficulty arises when dealing with the factors that influence the choice of
project management mechanism. In the field of structural contingency theory, the term
“contingency” is used to describe the few factors that appear to determine organizational
structure. In Agency Theory the term “antecedent” is more popular (Eisenhardt, 1989a;
Hamilton and Kashlak, 1999). Others have used the more general term of “factor” (Lederer and
Prasad, 1995; Gallivan and Oh, 1999; Carmel and Agarwal, 2001). Still others have used the
term “critical success factor” (Gemuenden and Lechler, 1997; Cooke-Davies, 2002).
Contingency theory concerns the effectiveness of the organization as a whole and examines the
fit between structural and environmental variables (Shenhar, 2001). Fry (1984) applied
contingency theory to workgroups, as opposed to the organization as a whole. Each of these
approaches considers the effect of a few environmental variables such as risk or uncertainty on
an organization, project or workgroup with the effect of the variables measured in some way
against the task outcomes, usually task success.
This research needs to identify and describe the few factors that influence the choice of project
management mechanisms in different circumstances. The term “antecedent” carries with it the
connotation of something preceding in time. While it is acknowledged that the factors must be
present before the project management mechanism is chosen, it is preferable not to be distracted
into considerations of chronological sequence, so the term “antecedent” will not be used. The
Project Management Mechanisms
Page 14
term “factor” is very general and does not convey any idea of a small number. Similarly, the
term “critical success factor” assumes that the factor is associated with “success” and implicitly
excludes those factors associated with failure or other negative outcomes. In this research, the
term “contingency” will be used to describe those, preferably few, factors that influence the
choice of project management mechanism.
2.1.3 Distributed software development. The term “distributed software development” could be applied to almost any software
development where the development team was not entirely co-located in the same building, if
not the same room. It could also be applied only to those software development projects where
the project team does not all work for the same organization, or it could be interpreted to mean
only those development projects where at least some of the development was carried out in
some physically remote location.
This research will use the term “distributed software development” to include any separation
between the project manager and one or more elements of the software development team. This
will include projects where the development team all work for the same organization but are
geographically distributed (Herbsleb et al., 2000; Borchers, 2003), globally distributed
development (Carmel, 1999) as well as outsourced software development (Nicholson and Sahay,
2001; Sabherwal, 2003).
2.2 Project monitoring This chapter will now consider, in turn, project monitoring, project control and project
coordination. Each will be defined, the range of mechanisms from the general literature will be
identified and described, and then the implementation of mechanisms in software development
will be described. Having established the project management mechanisms that may be used in
software development, the contingencies affecting their choice will be examined. Where other
research has examined the contingencies that influence the choice of mechanism in project
control (Henderson and Lee, 1992; Hamilton and Kashlak, 1999) or the choice of project
coordination (Kraut and Streeter, 1995; Nidumolu, 1996; Faraj and Sproull, 2000; Andres and
Zmud, 2002; Sabherwal, 2003), this research will establish the contingencies that influence the
portfolio of monitoring, control and coordination mechanisms.
This section will define project monitoring and distinguish it from project control and project
coordination. Monitoring mechanisms will be identified and classified into a framework that
distinguishes the essential characteristics of each type of mechanism for the purposes of this
Project Management Mechanisms
Page 15
research. Subjects of monitoring will be identified from available software development
literature and briefly discussed.
2.2.1 Introduction Project monitoring is the gathering of information to determine the current state and progress of
the project in relation to its expected state and progress (Shumate and Snyder, 1994; Al-Jibouri,
2003; Navon and Goldschmidt, 2003). Frequently, project monitoring supports project control
and is so frequently associated with project control that the two are treated as inseparable
(Davies and Saunders, 1988; Blanchard, 1990; Duncan, 1996; Hughes and Cotterell, 1999;
Cleland and Ireland, 2002; OGC, 2002; Thomsett, 2002a; Burke, 2003; Faulconbridge and Ryan,
2003; Lientz and Rea, 2003). Yet project monitoring and project control are not the same
activity, nor are they inseparable. Control involves directing efforts toward some end objectives
(Ouchi and Maguire, 1975; Eisenhardt, 1985; Kirsch, 1996) and sometimes considers
information gathering to be part of the control activities. While this is a useful view when
studying organizational control, it excludes information gathering for other purposes such as
quality assurance (Shumate and Snyder, 1994; Kitchenham, 1996; Jorgensen, 1999; Fenton,
2000; McGarry et al., 2002) or coordination (Hauptman, 1990; Crowston, 1991; Kraut and
Streeter, 1995; Carmel, 1999; Faraj and Sproull, 2000; Zhuge, 2002; Sabherwal, 2003).
Sabherwal (2003) argues that project control differs from coordination; yet information
gathering may support project coordination activities instead of, or as well as, project control. In
this research, it is useful to separate monitoring from both control and coordination so that
monitoring mechanisms can be identified independently of the intended use of the information,
and so that the effect of organizational distance on monitoring can be considered independently.
Separate monitoring activities are most often those arising out of measurement programmes
intended to support more than just the immediate project. Herbsleb and Grinter (1998) identify
three different systems that consume measurement information: project management system,
process improvement system and strategic management system. This research will consider
general information gathering focussing attention on that which supports the project
management system. Usually the information of interest is that which indicates the future state
of the project if things were to continue in their current form.
2.2.2 Monitoring mechanisms. This section will investigate a framework of project monitoring mechanisms and the
contingencies that favour or discourage each category. Then the model will be used to explore
Project Management Mechanisms
Page 16
the types of information sought in software development projects before concluding how
changes in the contingencies are likely to affect the choice of monitoring mechanism.
The available project management literature rarely separates project monitoring from project
control so has not suggested a framework of project monitoring mechanisms. However, there
are available models of project control and of project coordination. These will be presented in
Sections 2.3 and 2.4 of this thesis.
A search of the literature revealed that monitoring mechanisms seem to fall into four groupings:
• Information that can be gathered automatically from software development or project
management tools and systems.
• Information that is gathered through a formal administrative system
• Information gathered through irregular enquiry such as audits and reviews.
• Information gathered informally through conversations or their equivalent.
The groupings were taken largely from similar groupings of coordination mechanisms described
by Sabherwal (2003) and reflect the same separation based on fixed and variable costs (see
Section 2.4). Fixed costs are those costs incurred to establish the mechanism and would include
such costs as initial purchases, training, installation and configuration of any required tools.
Variable costs are those costs that are incurred each time the monitoring activities are performed.
The more formal monitoring activities tend to incur higher fixed costs because people must be
trained in their use, but lower variable costs. Informal and ad hoc monitoring mechanisms such
as face to face meetings or tele-conferences tend to require little or no training but incur the
same expense each time. The model is illustrated in Figure 1 which portrays automatic
monitoring systems as incurring the highest fixed costs but lowest variable costs
Figure 1: Comparison of fixed and variable costs for different monitoring mechanisms.
Some examples of each type of monitoring mechanism are given in Table 1. The focus of
monitoring may be the product being developed or the processes used to develop the product.
Each type of monitoring mechanism will be explored in the following sections.
Fixed costs
Variable costs
Automatic monitoring
Formal monitoring
Ad hoc monitoring
Informal monitoring
High Low
Low High
Project Management Mechanisms
Page 17
Table 1: Example monitoring mechanisms arranged to illustrate the expense of information gathering.
Automatic Formal Ad hoc Informal Product PSEE output
CSCW output Formal quality assurance processes
Audit Review Conversations with development team
Process CSCW output Project management tools
Project Management administration
Phase end review Project audit
Conversations with project team
2.2.2.1 Automatic monitoring While measures of the software product’s internal and external characteristics may be gathered
through formal methods, tools are emerging that can automatically gather, record and report
those measures. Automatic monitoring involves gathering data as a side effect of another
activity. It is information gathered, essentially, for free because the main purpose of the activity
is something other than information gathering. Integrated development environments (IDE) may
be able to provide the information, especially when they are integrated with revision control
systems. However, workflow management systems (Grefen and Hoffner, 1999; Van Der Aalst,
1999; Barnes and Gray, 2000; Godart et al., 2001; Bajaj and Ram, 2002), and computer
supported cooperative work (CSCW) systems (Hawryszkiewycz, 1993; Kataoka et al., 1998;
Roller et al., 2002) do record the progress and state of work and can automatically report it.
Aegis (Miller, 2004) is an example of a configuration management tool that incorporates a
software development process that can be configured to report development information.
Software development life cycles that deliver the final product in increments also have the effect
of monitoring the state of the project simply by frequently and visibly completing some part of
the project (Thomke and Reinertsen, 1998; Beck, 2000; Highsmith and Cockburn, 2001; Moore,
2001; DeMarco and Boehm, 2002; Fowler, 2003; Cockburn, 2004). Automated tools enforce a
degree of objectivity on the information being provided since they create reports in response to
system events.
2.2.2.2 Formal monitoring Formal monitoring involves gathering information through some formal organizational structure
and procedures. Most project management texts describe project monitoring in terms of the
information that is sought without specifying how the information is to be gathered. The
information described by Hughes and Cotterell (1999 p173) and the examples given clearly
assume that the information will be gathered by the project administration rather than by any
automated means. Cleland and Ireland (2002 p380) describe a range of performance observation
processes that are a mix of formal, informal and specific enquiry. This is not to say that any of
Project Management Mechanisms
Page 18
these authors preclude automated data gathering, but that the assumption is that information will
be gathered manually.
Information gathered formally tends to support well defined measures that are generally agreed
within the software development community and for which common definitions are readily
available (ISO 9126, 2001; McGarry et al., 2002). These measures may be of the product, the
process or be project-related, such as risk.
Product monitoring Information related to the quality of the product being developed may be available
automatically, as discussed in the previous section, but is more normally available through
specific manual information-gathering tasks that form part of the project’s administration. The
most common product information is very general and deals with the overall product attributes
of size and quality. These attributes are what ISO 9126 (2001) refers to as external quality
characteristics, which are those that can be evaluated without visibility into the product itself. In
other words, white box testing will evaluate internal characteristics while black box testing
(integration and/or system testing) will evaluate external characteristics. Fenton (2000) provides
a broad table of internal and external metrics for products, processes and resources.
Information can also be sought about progress of developing specific artefacts, i.e., how much
of it has been developed or how much effort is required to complete it. Although this measure
could be applied to the artefact, it is more normal to regard progress measures as applying to the
project tasks rather than the artefacts of those project tasks.
Project monitoring Project information normally sought is related to the project’s progress, costs and risks. The
means of eliciting this information can vary (Hughes and Cotterell, 1999; Project Management
Institute, 2000; Cleland and Ireland, 2002). Hughes and Cotterell (1999 p172) list a
classification of information sources according to their formality and means of reporting with
examples of each type. A summary is shown in Table 2.
Table 2: Hughes and Cotterell’s (1999) classification of project report types according to formality and reporting medium.
Report Type Examples Oral, formal, regular Weekly or monthly progress meetings. Minutes might
be taken. Oral, formal, ad hoc End-of-stage review meetings. These could also be
formal audits. Written, formal, regular
Job sheets, progress reports
Written, formal, ad hoc
Exception reports, change reports
Project Management Mechanisms
Page 19
Risk monitoring Risk monitoring normally refers to monitoring already identified risks rather than the
identification of new risks. Kerzner (1998) advocates incorporating risk monitoring into other
monitoring such as earned value measurement and schedule performance monitoring while
Boehm (1991) prefers to monitor risks through scheduled management reviews of the project.
2.2.2.3 Ad hoc monitoring Ad hoc monitoring is information gathering initiated for a particular purpose. It is neither
regular nor is the information necessarily gathered on all projects. Ad hoc monitoring normally
serves one of two purposes. The first is as an independent check on the project. The second is to
seek clarification of some matter.
The occasional review and formal audit are conducted as the need arises (Cleland and Ireland,
2002 p388) or at the end of project phases (Kerzner, 1998 p1067). Their purpose can vary but
are generally intended as a more thorough examination of some aspect of the project than is
normally performed during regular project reporting. They can be a normal part of the project.
For example, an ISO 9001 audit is required annually and investigates projects as part of its
information gathering and reporting on quality management.
Project managers sometimes refer to “drill down” enquiries. When some information in the
normal monitoring flow triggers an alarm, a project manager may seek further information to
clarify the situation. Sometimes the response to such an alarm can be a formal project audit
while at other times it is simply the project manager discussing matters with the project team.
Regardless of the type of response, the intention is to investigate something more thoroughly.
2.2.2.4 Informal monitoring Much has been said of how much software development depends on social interaction (Gruhn,
1992; Jagodzinski et al., 1997; Sawyer et al., 1997; Gasson, 1998; Sawyer and Guinan, 1998).
Gruhn argues that formal software development processes must be augmented with social
processes among developers, a sentiment shared by Gasson. That the formal reporting systems
must be augmented with an informal, socially interactive one is acknowledged by various
authors on project management when they advocate project monitoring via canteen
conversations (Hughes and Cotterell, 1999) or “walking the project” (Cleland and Ireland, 2002).
Information could also be gathered through monitoring discussion boards or other
communications between team members (Lientz and Rea, 2003 p147)2. For example, a
2 My personal experience is that informal communications either between the project manager and team members or among several team members reveals trends or areas of concern, but seldom reveals anything specific.
Project Management Mechanisms
Page 20
discussion about design alternatives may indicate that the requirements have not been fully
understood but not the exact nature of the understanding. Or a discussion about a particular
technical issue may indicate that the team is beginning to “gold plate” the product. Lientz and
Rea (2003) stress the importance of communications, and miscommunications, in international
teams and the need to monitor project communications to maintain awareness of the project
environment.
The type of information gathered informally seems to be the more tacit, less measurable
information. Information that can be readily gathered, and for which there is wide consensus
about its meaning and use, does not appear to need extensive conversations to convey the full
meaning or contextual information. On the other hand, context based information or complex
information appears less readily gathered and less easy to transmit.
It appears that the formal reporting system can only report what it anticipates and a less formal
mechanism is needed to observe and report the unanticipated.
2.2.3 Monitoring in software development. The most commonly cited attributes of project success are time, cost and functionality
(Henderson and Lee, 1992; Lawlis et al., 1995; Jones, 1996; Linberg, 1999; Butler and Lipke,
2000; Johnson et al., 2001). So it is reasonable to expect that monitoring will focus on those
attributes of the project and on the attributes that contribute to or threaten them. Many texts on
project management advocate monitoring time (schedule), cost, scope (functionality), quality
and risk.
When dealing specifically with internationally distributed projects, Leintz and Rea (2003)
advocated monitoring issues, rather than risks. Among the reasons given for this was to judge
how well the project was being managed and to gauge the local management team’s manner of
working. The term “issue” is not clearly defined by Lientz and Rea but is used to describe
almost anything that may require the project manager’s attention. An issue may be a “problem
or an opportunity” (Lientz and Rea, 2003 p18). Whereas a risk is something that may happen,
an issue appears to be something that has already happened.
2.2.3.1 Time and schedule Schedule is normally monitored by comparing the expected progress of project tasks with
planned progress (Project Management Institute, 2000; Cleland and Ireland, 2002; Burke, 2003;
Faulconbridge and Ryan, 2003). Some of the experience-based texts of software development
argue that tasks should not exceed two weeks in duration because that is long enough to achieve
something but short enough to prevent most of the problems that can beset individual software
Project Management Mechanisms
Page 21
development tasks (McCarthy, 1995). When tasks are longer than the reporting period, it is
normal to report progress through the tasks either by some measure of completeness or some
measure of work remaining. Some project managers argue that measures of completeness are
not useful because software developers are perpetually optimistic and will not realise the effort
required to complete a task or project (Brooks, 1995). Tasks are routinely reported at 80% or
90% completed for a considerable time, much to the frustration of the project manager. To
counter this tendency toward optimism, some project managers advocate reporting estimated
time to complete a task. This approach recognises that time past cannot be reclaimed and is only
of historical interest (Fleming and Koppelman, 1999a). What matters to the project manager is
how much time is required to complete a task.
Earned Value Management combines both cost and schedule to report on progress (Humphrey,
1994; Shumate and Snyder, 1994; Fleming and Koppelman, 1999b; Butler and Lipke, 2000; Al-
Jibouri, 2003). At its simplest, earned value is a comparison of how much money has been spent
to complete the work to date, compared to the budgeted cost for the same work. It can also serve
in software development projects as a check on the initial estimates of task durations. This is
because software development costs are largely direct costs of labour and task duration
estimates are frequently based on expert opinion rather than historical data. If the Actual Cost of
Work Performed (ACWP) exceeds the Budgeted Cost of Work Performed (BCWP) then it
indicates that the work is being completed less productively than planned and either the budget
or the productivity estimates should be revised.
When measures are based on task completions, it is necessary to decide what “complete” means.
As an example, a coding task can be considered complete either when the coding is complete,
when the code has been reviewed, when the code has been compiled and tested or when the
code has passed all unit or acceptance tests. Similarly a design task could be considered
complete when the first draft is complete, when all reviews have been conducted and the design
is approved or at some arbitrary intermediate point. Obviously if such criteria for completeness
are not decided and agreed by all team members, task completion measures may indicate an
overly optimistic or overly pessimistic project state.
Although there can be more detailed measures than conformance to planned schedule, their use
is seldom mentioned.
2.2.3.2 Cost Directly comparing budgeted costs to actual costs seldom indicates anything useful by itself.
Hughes and Cotterell give an example where a comparison of actual cost vs. budgeted cost
could indicate a project that was running late or one that has shown considerable cost savings
(Hughes and Cotterell, 1999 p179).
Project Management Mechanisms
Page 22
As pointed out in the previous section on time and schedule, measures of cost or expenditure are
usually combined with measures of elapsed time. This is especially true of software
development projects where costs have so far been tied directly to labour and a measure of
developer hours is directly convertible to dollars spent.
There have been some arguments that software development is not amenable to schedule
compression and that there is a minimum development time (Putnam and Myers, 1992). This is
expressed most famously by Brooks (Brooks, 1995 p16) where he argued that “men and months
are interchangeable only when a task can be partitioned among many workers with no
communication among them” (Italics from the original).
As software development projects change from simple single team development to complex
projects where purchased components, fixed price contracts and variable priced contracts are all
added to the efforts of the central development team, there is much more potential for the
project manager to directly alter the cost of the project by switching development between
outsourced suppliers or by purchasing a COTS component.
2.2.3.3 Functionality and scope Scope creep is the term used to describe the subtle but often devastating changes in the project’s
functional requirements. From my experience, the changed functionality almost invariably
increases the scope of the project, seldom decreasing it.
Most frequently, changes to the scope of the project can be monitored through some form of
change control (Project Management Institute, 2000). Such monitoring may reveal that the
scope has changed in some way, but not necessarily how that change will affect the overall
project. There have been some attempts to put objective measures to software project scope,
most notably function point measurement (Albrecht and Gaffney, 1983).
Controlling scope is sometimes considered part of the configuration control task. This, in turn,
is part of the larger process of configuration management (ISO 15271, 1998). Some authors
consider scope control to be part of the responsibilities of configuration control (Cleland and
Ireland, 2002). Certainly one of the functions of configuration management is to report on the
current configuration, hence scope.
2.2.3.4 Quality Quality management is sufficiently important that it is usually treated separately from other
aspects of software development (Kerzner, 1998; Hughes and Cotterell, 1999; Project
Management Institute, 2000). In software development, quality is usually gauged by the extent
to which the software is free of defects. Increasing performance requirements or usability
requirements, for example, will usually increase the development effort. A system required to
Project Management Mechanisms
Page 23
process 10,000 transactions per hour will not always be a scaled up version of a system
designed to process 1000 transactions per hour.
Monitoring the quality characteristics is a necessary adjunct to monitoring the state of
completion of the work in progress. After all, if the software doesn’t have to work it could be
declared finished at almost any time.
Frequently the quality levels required of the various intermediate software deliverables, such as
a design or a specification, will be described in the specific task requirements as a completion
criterion for that task. Quality will be assumed to be satisfactory provided the exit criteria have
all been satisfied. It is only when the software is being integrated into an executable system and
its final functionality checked that the normal meanings of quality are applied to the deliverable
product. At this point the quality measures may be the number of functions, or requirements,
that have passed their tests. Alternatively, the quality measures may be expressed as the number
of defects remaining in the product.
It is quite normal in software development to classify software defects in a four or five level
hierarchy: defects that cause the system to fail, defects that fail to implement some functionality
but for which there is a workaround, defects where the functionality is difficult to use and
cosmetic defects. For an example of such classification schemes, see the Bugzilla Guide (The
Bugzilla Team, 2005). Normally software acceptance criteria require that there be no critical
defects and limited numbers of other defects.
2.2.3.5 Risk A risk is a threat to the success of the project (Project Management Institute, 2000). An essential
characteristic of a risk is that it has not yet happened. Once it does occur, or is triggered, then it
becomes an issue whose response may or may not have been planned. However, Leintz and Rea
(2003) use the term “issue” to cover both those threats to the project that haven’t eventuated and
those threats that have.
Risk management involves determining which risks might affect the project, assessing their
potential effect and the probability that they will occur, mitigating the risk appropriately then
monitoring and controlling the risks (Boehm, 1991; Kerzner, 1998; Hughes and Cotterell, 1999;
Project Management Institute, 2000).
The main risk identification is normally done during project planning (Hughes and Cotterell,
1999; Project Management Institute, 2000) where a standard list of risks common to most
software development projects can be reviewed. Hughes and Cotterell identify three types of
risk of which two can reasonably be identified during project planning while the third is made
up of risks due to unforseen or unplanned events. Jiang et al. (2002), through empirical survey
Project Management Mechanisms
Page 24
and factor analysis, identified six software development risk factors. All six factors are likely to
be present and assessable at the start of the project.
That risk should be assessable at the start of a project doesn’t mean that all risks will be
identified. Some will only become evident during the project. For example, one of the risk
factors is a lack of team expertise. It may only become evident during the project that the team’s
expertise is deficient. Therefore, risk monitoring involves identifying new risks as well as
reviewing already identified risks.
2.2.4 Summary Project monitoring is frequently closely associated with project control, but because project
monitoring can gather information for more than project control, it will be treated separately in
this research. Regardless of the purpose, monitoring mechanisms can be classified as automatic,
formal, ad hoc and informal. The fixed and variable costs of the different types of project
management mechanisms are shown in Figure 1, Section 2.2.2 and will influence the choice of
mechanism. Instances of each type of project monitoring mechanism are likely to be used in
software development projects.
2.3 Project Control This section will examine the mechanisms of project control. Organization theory is examined
for control mechanisms, as is the application of organization theory to software development.
The different control mechanisms that would normally occur in software development projects
are described.
2.3.1 Introduction Organizational control is exercised through actions taken to move the organization toward its
objectives (Ouchi and Maguire, 1975; Eisenhardt, 1985; Flamholtz et al., 1985; Kirsch, 1996).
The scope of theoretical work on organizational control is normally the entire organization.
However, nothing in the established theories requires a minimum size of organization or
particular type of organization. Thus, it is valid to apply theories of control to a project team.
Restricting the scope of control to that of a project within the organization retains the sense that
control relates to efforts made or actions taken to move the project toward its objectives
(Kerzner, 1998; Hughes and Cotterell, 1999; Project Management Institute, 2000; Raffo et al.,
2000; Cleland and Ireland, 2002). Often, control is viewed as including any monitoring
necessary to gather information about the state of the project in relation to its objectives (Ouchi
Project Management Mechanisms
Page 25
and Maguire, 1975; Eisenhardt, 1985; Kirsch, 1996; Hughes and Cotterell, 1999) but, as argued
in the previous section, monitoring will be treated separately from control for this research.
There appear to be two main bodies of knowledge that deal with the problem of organizational
control: control theory and agency theory. Organizational control theory concerns “attempts by
the organization to increase the probability that individuals and groups will behave in ways that
lead to the attainment of organizational goals” (Flamholtz et al., 1985). Organizational control
theory is very general, applying to any organization in any circumstance. In contrast, agency
theory (Eisenhardt, 1989a) considers the problem of organizational control in the specific
circumstance where an agent is carrying out work on behalf of a principal, such as may occur
when work is sub-contracted or outsourced.
Project managers need to influence the behaviours of team members so that the project’s goals
may be achieved (Henderson and Lee, 1992). In particular, when plans do not achieve their
anticipated outcomes during the project, corrective actions will need to be undertaken and these
are usually carried out through some form of control exerted by the project manager. Many texts
on project management assume that the corrective actions, once identified, will simply happen
(Hughes and Cotterell, 1999; Project Management Institute, 2000; Bauch and Chung, 2001;
Cleland and Ireland, 2002). There is no consideration that project team members may be
unwilling or unable to carry them out.
The problem of ensuring that project management directives are carried out is becoming more
important because the changing composition of project teams removes team members from the
direct control of the project manager (Gallivan and Oh, 1999). In matrix organizations, the
project manager may not have direct authority over the team members, but will have some
indirect control through the organization’s hierarchy. When project team members work for
different organizations, the problem of control becomes that much harder.
Ouchi (1979) studied organizational control mechanisms, identifying three types: market,
bureaucratic and clan mechanisms. Ouchi proposed that the choice of control mechanism
depended on knowledge of the transformation process and the ability to measure outputs.
Eisenhardt (1985; 1989a) later examined the role of control in agency theory using Ouchi’s
model but extended it to include the agent’s attitude to risk. This resulted in a model that
predicted whether outcome control or behaviour control would be favoured. Henderson and Lee
(1992) found that, within information system (IS) design teams, behaviour control and outcome
control would coexist within the same project. The project manager exerted behaviour control
while the team itself exerted outcome control within the team. Kirsch (1996) investigated the
use of different control mechanisms in IS development but, in contrast to Henderson and Lee,
focussed on relations between the project controller and the project team. It is not clear whether
Project Management Mechanisms
Page 26
the term “project controller” used by Kirsch refers to the project manager who is part of the
project team or to a manager external to the development team such as a client. Hamilton and
Kashlak (1999) examined a multinational corporation’s selection of a subsidiary’s control
system under various host country’s conditions. They extended the contingencies to include the
host financial policies, cultural distance and political restrictions in addition to the task
programmability and output measurability used by Ouchi (1975; 1979). The control
mechanisms used by Hamilton and Kashlak in their analysis were output, behaviour and input
control where input control was similar to, but not the same as, clan control (Ouchi, 1979, also
Section 2.3.2.3).
The four types of control mechanism thus far identified will now be examined.
2.3.2 Control mechanisms.
2.3.2.1 Output control Output control, first proposed by Ouchi (1975; 1979), then taken up by Eisenhardt (1985; 1989a)
has become sufficiently established that the concept is used unchanged by subsequent authors,
although Kirsch (1996) refers to it as “outcome control”. The term “output control” will be used
in this thesis.
Output control is exercised by measuring and rewarding results without concern for how those
results were obtained. Originally, Ouchi analysed the different mechanisms with which
organisations performed various functions. The market mechanism of determining prices for
goods was one of the mechanisms (Ouchi, 1979) but it was only later (Ouchi and Maguire, 1975)
that the term “output control”, rather than “market control”, was used to describe the control
mechanism used within an organisation. Performance is linked to concrete results such as
paying a commission on sales (Hamilton and Kashlak, 1999). This is in contrast to paying
wages for a sales role with no commission for sales. Contractual progress payments linked to
agreed milestones would be an example of output control, as would be piecework payments
which are based on the number of items produced.
Some software development projects involve buying components on the open market. There are
the obvious components such as compilers, debuggers and other tools used during development
but not part of the final product and there are also components such as protocol stacks, VBX
controls or C++ components that would be incorporated into the final product. Such component
purchases use the market mechanism described by Ouchi in the same way as any other
acquisition. Software development projects may let a contract to develop a specific part of the
system or perform a specific function within the project. Bids may be sought from several
potential suppliers with the contract specifying progress payments on achieving certain
Project Management Mechanisms
Page 27
milestones, a type of output control. While payments are tied to milestones, the project manager
may or may not require visibility into how those milestones are achieved.
2.3.2.2 Behaviour control Control that is achieved through prescribing behaviour to be followed is referred to as behaviour
control (Ouchi and Maguire, 1975). This type of control is exercised by bureaucracies through
rules “concerning processes to be completed or rules which [sic] specify standards of output”
(Ouchi, 1979). Ouchi distinguishes rules from prices, used in output control, by arguing that the
rules are “incomplete bundles of information”. Hamilton and Kashlak (1999) characterize
behaviour control as “the degree to which an employee is held accountable regardless of the
results; the degree to which there is concern for procedures or methods; the degree to which
performance programs are imposed from the top down; the frequency with which employees
receive feedback or performance evaluation.”
Eisenhardt (1985) refers to knowledge of the transformation process or task programmability
while Kirsch (1996) retains the term “knowledge of the transformation process.” Both authors
are referring to the degree to which behaviours or procedures can be described that will reliably
achieve the desired outcomes. The familiar form of this in the workplace are office procedures,
explicit work practices or other documented instructions pertaining to how work will be carried
out. Often products are delivered with an operations manual that describes how to operate the
device and sometimes how to perform routine maintenance and routine problem diagnostics.
Such operations manuals conform to the description of behaviour controls by the supplier to an
organization to control how the device will be operated by its users.
Software development methodologies describe how the various development activities are to be
performed. They vary from the very high level, general methodologies described in international
standards such as ISO 12207 (2002) or ISO 15288 (2003) through to the very detailed
commercial methodologies such as Rational Unified Process (RUP, 2003).
While empirical data on the spread of knowledge and agreement on software development
processes is scarce, an indication can be gained from the international acceptance of the
Capability Maturity Model (SEI, 2004b) and its successor the Capability Maturity Model
Integration (SEI, 2004a). Both of these define a collection of software development processes
and prescribe the outcomes that must be achieved during those processes. While this would tend
to categorise the CMMI as an output control, its adoption and use requires that a software
development methodology be defined and adopted, thus implementing behaviour controls. The
CMM and CMMI originated in the USA but have been adopted throughout the world, in
particular in India (Carmel and Agarwal, 2002), indicating that not only are the transformation
Project Management Mechanisms
Page 28
processes of software development widely understood and agreed, but that measures of software
process capability are also widely understood and agreed.
2.3.2.3 Clan control Clan control is exercised through adherence to shared values. Ouchi (1979) distinguished
between bureaucratic (behaviour) control and clan control by pointing out that some tasks are
inherently ambiguous, such as in a hospital, and precise description of how a task is to be
performed is impossible. Instead, almost all workplaces have a period of indoctrination while
people learn how work is carried out and the values that guide the work. Ouchi acknowledges
that similar values shared by people spread over many organizations are referred to as a
profession. When referring to shared values of a political organization, it is a culture. When the
shared values describe the unique properties of an organization, Ouchi defines it as a clan
(Ouchi, 1979).
Essential to clan control is the period, sometimes lengthy, of indoctrination to acquire the values
expected of the profession, political party or organization. Ouchi argues that once someone
understands the values and is trying to achieve the “right” objectives, their manager can
eliminate many costly forms of auditing and surveillance. In the case of professions such as
doctors, lawyers, engineers or academics, it may be that absorbing the “right” values is a
condition of admission to the professional association. While many countries have professional
bodies to which software developers may belong, thus forming a recognised clan, membership
is rarely compulsory. A professional software development or IT related culture has been
proposed (Carayannis and Sagi, 2001) but with limited evidence of its strength compared to
national cultures. Duliba (1991) investigated whether there was such a thing as an occupational
community but concluded that there was not. Thus, evidence that software developers the world
over or those engaged on the same project form a clan, in Ouchi’s use of the term, is limited.
2.3.2.4 Input control Agency Theory (Eisenhardt, 1989a) examines the problem of risk sharing when cooperating
parties have differing goals and division of labour. The agency relationship is where one party
(the principal) delegates work to another party (the agent) who performs that work. Using the
perspective of Agency Theory to examine control system selection in multinational corporations,
Hamilton and Kashlak (1999) proposed “input control” in contrast to “clan control”.
Where clan control is exercised by the clan and within the clan, input control is exercise by a
principal over an agent. Hamilton and Kashlak characterise input control as being exercised
through recruitment and training. The multinational company “establishes the best staffing
procedures available; becomes involved in the skill development of an employee; performs
Project Management Mechanisms
Page 29
multiple evaluations before hiring an individual; provides opportunities for broadening a skill
set of an employee; takes pride in hiring the best employees possible and the overall
commitment of the firm to training and development.” (Hamilton and Kashlak, 1999)
2.3.3 Control mechanisms in software development projects. In this section, the available project management literature is examined to determine what
control mechanisms are proposed or recommended in software development and to examine
which type or types of control the mechanisms exercise. If different control mechanisms are
required for projects with some outsourced or distributed work, then the proposed analysis
should expose such differences.
When examining the different control mechanisms, it became apparent that it was not always
possible to neatly classify some mechanisms as mainly “behaviour” or mainly “transformation”.
In such cases the mechanism is included in both sections.
2.3.3.1 Output control mechanisms. Output control mechanisms are intended either to specify the outcomes that must be achieved or
to determine whether or not the outcomes have been achieved. Examples of output controls are;
• Project goals or objectives
• Project constraints such as budget or schedule
• Functional requirements
• Milestones, often a combination of schedule and examinable intermediate products
• Acceptance test specifications
• Contract terms and conditions
Of these, the most common practice in software development is that of determining project
goals or objectives. The goals range from the very high level organizational goals through to
specific project goals that might be sub-divided into business goals, political goals and technical
goals (Lientz and Rea, 2003). Sometimes the goals or objectives are simply to act as constraints
on the project (Project Management Institute, 2000) while other objectives are very specific and
intended to be achieved by the project or as a side effect of the project (Lientz and Rea, 2003
p28). Lientz and Rea propose that since most projects are deployed into an existing situation, it
is necessary to measure the current situation so that it can be determined whether or not the
project made a difference and, if so, what difference (Lientz and Rea, 2003 p25).
Project Management Mechanisms
Page 30
The project requirements are variously referred to as scope (Project Management Institute, 2000;
Lientz and Rea, 2003), statement of work (Kerzner, 1998) or requirements (Cleland and Ireland,
2002). In the context of types of project control, the project or product requirements are a type
of output control. They determine what the project is to achieve without concern for how it is to
be achieved.
Despite the fact that most output control is exercised at either end of a project, project
milestones have the attributes of output controls (Kerzner, 1998; Project Management Institute,
2000; Cleland and Ireland, 2002; Lientz and Rea, 2003). By themselves they attest whether or
not something has been achieved without concern for how it may have been achieved.
Where most of the mechanisms so far in this section are invoked during planning, acceptance
testing applies toward the end of the project to test whether or not the requirements or goals
have been met (Hughes and Cotterell, 1999; Project Management Institute, 2000).
When the project management texts specifically dealt with procurement, more output control
practices were described. The PMBOK (Project Management Institute, 2000) has a specific
procurement knowledge area, while Lientz and Rea (2003) specifically identify practices related
to outsourcing. Both are notable for the number of output-based controls mentioned and
specifically described as relevant. The most commonly mentioned practice, used in software
development as well as many other fields, is the request for proposal (RFP). Although the RFP
is very similar to a requirements specification or scope of works, it is a specific type of control
used in a specific context and with a widely agreed and understood meaning. As the PMBOK
describes it, an RFP is a type of procurement document used to solicit proposals from
prospective sellers. A Scope of Works is one of the inputs to its development.
2.3.3.2 Behavior control mechanisms Most of the control mechanisms described or identified in the project management texts can be
classified as behaviour control mechanisms. Behaviour control mechanisms are intended to
control the behaviour of project team members either by constraining how they perform tasks or
by reporting on how they are performing tasks. Examples of behaviour controls are:
• Project schedule/project scheduling
• Development methodology or processes
• Change control procedures
• Project status reporting
Project Management Mechanisms
Page 31
Project schedule The most common practice in project planning is to develop a work breakdown structure
(Kerzner, 1998; Hughes and Cotterell, 1999; Project Management Institute, 2000; Cleland and
Ireland, 2002; Lientz and Rea, 2003). A work breakdown structure divides the whole task into
manageable subtasks, then allocates responsibility for performing the subtask to an appropriate
group. By itself, a work breakdown structure does not determine the sequence in which tasks
must be performed. That is left to a schedule, which also records the resources required for each
task, the task duration, interdependencies between tasks and the occasional milestone.
Frequently, there is a distinction between the project work breakdown structure and a project
activity network. The distinction contrasts subdivision of the work into manageable packages
with the relationships between the various tasks of the activity network (Kerzner, 1998 p671).
By itself, the work breakdown structure does not impose any control on the project team, but the
project schedule does. In most project management texts, a schedule is assumed to contain a
work breakdown structure.
The project schedule is normally developed during project planning, which is where most of the
project control is implemented (Kerzner, 1998; Hughes and Cotterell, 1999; Project
Management Institute, 2000; Cleland and Ireland, 2002; Lientz and Rea, 2003). This is in
contrast to control such as project audits, which would normally be conducted in response to
some trigger that occurred during the project (Cleland and Ireland, 2002 p388). The control
mechanisms that are usually developed during project planning are neither wholly intended to
make the transformation process explicit nor wholly intended to increase the visibility of team
members’ project behaviour. For example, a project schedule that would typically be developed
using a tool such as Microsoft Project not only lists all the project tasks, their sequence and
interdependencies, durations and required resources but will usually also record milestones and
provide a means by which the project progress may be measured. The schedule makes the
transformation process explicit as well as increasing the visibility of behaviour during the
project.
A project schedule controls the behaviour of the project team members by determining when
they undertake specific tasks, the scope of those tasks and the relationship to those team
members undertaking other tasks.
Software development methodology While some general project management texts refer to organizational procedures (Kerzner, 1998;
Hughes and Cotterell, 1999; Cleland and Ireland, 2002), the software development industry has
developed a large number of software development methodologies. While some are proprietary,
many are publicly available, often published in books. The objective of a methodology is to
Project Management Mechanisms
Page 32
describe nearly everything that must be done in a successful software development (Henderson-
Sellers et al., 2004), at least to some level of detail that balances the need to be specific with the
need to allow for differing circumstances. It is a set of tools, methods and practices used to
produce software (Humphrey, 1989).
Software development is usually divided into a series of processes that align with the differing
skills used to produce different artefacts. For example, there is normally a project planning
process that produces a project plan, a requirements elicitation process that produces a
collection of requirements, a system design process that produces a system design and so on.
Each process may be divided into a number of tasks that combine to produce the output or, in
the case of ISO 12207, a number of responsibilities that collaborate to produce the outcomes
(ISO 12207, 2002). Methodologies describe the transformation process in sufficient detail to
ensure all necessary activities are performed with a minimum of repetition. They can also
describe the flow of work products through the processes and activities so that it is evident how
the tasks must be sequenced.
Some methodologies are very high level and intended only as a framework. ISO 12207 is very
high level, serving only to define a number of processes relevant to software development and a
small amount of detail about each process but deliberately not describing how the processes
would be selected and assembled for a specific project. In turn, ISO 12207 serves as a
framework for process assessment, to assess how well a specific organization performs a
selection of processes (ISO 15504, 1998). The Capability Maturity Model (CMM) defines the
software development processes even though its primary purpose is to assess those processes
(Paulk et al., 1993). Other methodologies are more specific and describe how the various tasks
are to be performed (1994b; Mazza et al., 1994a).
Whatever their origin, software development methodologies increase the explicitness of the
transformation process as well as increasing the visibility of software development behaviour,
which would influence the likelihood of adopting behaviour control.
Change control Most project management texts list change control as one of the project control mechanisms
(Thomsett, 1989; Hughes and Cotterell, 1999; Project Management Institute, 2000; Cleland and
Ireland, 2002) making it one of the more commonly advocated control mechanisms. This
technique acknowledges that there will be requests for changes in the project requirements or
objectives but that the changes need to be controlled to avoid needless activity such as
implementing the same change twice, redoing work to resolve conflicts among different
changes or undoing work to resolve contradictory changes. Generally, there is some form of
review of the requested changes, often by a committee, to decide which of them will be
Project Management Mechanisms
Page 33
accepted and how they will be incorporated into the project plan (Thomsett, 1989). The
activities involved in change control serve to increase the visibility of behaviours.
Project status reports The highest visibility of behaviours, in terms of most widespread communications, comes from
the practice of project status reporting. Typically the project manager gathers relevant project
information and distributes it to the project stakeholders. The exact contents of a project status
report may vary considerably between different projects but will have a similar intent to that
described by Thomsett (1989):
• The state of the project - is it still proceeding to plan or not?
• If not, what is the revised situation and causes for the variation?
• What actions have been taken by the team to solve any problems?
• What alternative scenarios are available?
• What actions can be taken by senior management?
Similarly the distribution may vary considerably between projects. Different stakeholders may
require different information. Senior managers may only require summary information while
managers overseeing multiple projects may require more detail to determine the possible effects
of one project on another.
2.3.3.3 Clan control mechanisms. Clan control mechanisms are those that promote or increase shared values among the project
team. Examples of clan control mechanisms are;
• Published project objectives
• Team meetings
• Project web pages or other project management information system
• Project kick-off meetings
While the project’s objectives would normally be regarded as an output control, publishing them
so that all team members understand what the project is trying to achieve fits the definition of
clan control.
More directly recognisable as a clan control technique is that of team building. Leintz and Rea
(2003) devote a chapter to choosing the team and, within that, a section on building a team
mentality. They believe that team building begins with a project kick-off meeting which all of
the critical team members should attend. Since Leintz and Rea are concerned specifically with
Project Management Mechanisms
Page 34
international projects where team members may be distributed around the globe, they do
acknowledge that a physical presence may be difficult and that attendance by video conference
is an alternative. At the first meeting, argue Leintz and Rea, it is important to instil a common
sense of purpose and goal. They go on to give a description of ways to instil a greater degree of
team mentality. One of the suggested mechanisms is to take a collaborative approach to
planning the work, a sentiment echoed by Thomsett when he advocates team driven project
management (Thomsett, 1989 p6). Leintz and Rea also recommend that the project manager
take advantage of opportunities to draw distributed team members, persons or organizations,
into the project ‘clan’ by visiting them through rotated project meetings, regular and frequent
site visits and sharing tasks between ‘head office’ and the distributed team members.
Less obvious is the use of a project management information system to promote a common
understanding of the project (Cleland and Ireland, 2002). While project reporting may not be
intended solely to instil shared project values, it will have the effect of promoting a shared
understanding of the project.
In a recent article, Thomsett argues that software development project teams are different from
teams of twenty or thirty years ago (Thomsett, 2002b). In an earlier time, a team may have
remained together for long periods that may have spanned more than a single project whereas
now teams are likely to be composed of a mix of contractors, consultants and others from
various organizations that have no common allegiance. Thomsett argues that commonly
advocated team forming mechanisms are likely to be irrelevant and the whole concept of “team”
should be questioned. Nevertheless he goes on to suggest that virtual teams, although different,
still need to form some sort of “teamness”, even if that is more of a commercial transaction of
joining a team for a common commercial purpose, that of completing the project, rather than the
more club-like teams of old that shared some social values over and above the commercial
objectives of the project.
Carmel (1999) expresses similar sentiments about the loss of “teamness” when comparing co-
located teams to globally distributed teams. Although Carmel’s perspective differs from that of
Thomsett, both conclude that modern software development teams are less likely to form
through social interaction than did the co-located, stable teams of some years ago.
2.3.3.4 Input control Mechanisms Input control is exercised through recruitment and training, often to instil a particular mindset.
Some examples of input control mechanisms are:
• Recruiting project team members
• Project-specific training
Project Management Mechanisms
Page 35
Project management texts pay some attention to selecting project team members but it is usually
in the context of engaging contractors or outsourced suppliers. Hughes and Cotterell (1999)
briefly deal with team selection whereas Leintz and Rea (2003) devote a chapter to setting up
the project organization structure, of which a significant proportion deals with the importance of
selecting the project leader or project manager.
Although recruitment and training are frequently covered in texts, it is in the context of ensuring
that the team members possess the skills required by the project plan than as any form of project
control.
2.3.4 Summary Mechanisms of control within software development projects can be classified as output,
behaviour, input and clan control mechanisms. Each have specific conditions that favour their
use but more than one control can operate within the same project simultaneously.
2.4 Project Coordination This section will examine coordination in terms of the models used to classify the mechanisms
and their contingencies, then review coordination mechanisms in project management texts,
especially software development project management. Several coordination mechanisms
typically used in software development will be examined to determine the likely effect of
distance between the cooperating parties.
2.4.1 Introduction Coordination differs from control. Coordination is concerned with managing the
interdependencies between activities (Malone and Crowston, 1994) or among multiple
individuals involved in an activity (Kraut and Streeter, 1995). In contrast, control focuses on
improving the performance of activities relative to some overall goal when the individual goals
of those involved in the activities may differ from the overall goal (Eisenhardt, 1985; Henderson
and Lee, 1992; Hamilton and Kashlak, 1999).
Coordination and control are both important to outsourced or distributed software development,
although they are quite different in terms of the problems studied, the theories applied and the
ways of classifying the mechanisms (Sabherwal, 2003).
Kraut and Streeter (1995) identified the characteristics of software development that give rise to
coordination problems and described why these characteristics introduce “perhaps unresolvable
tension in large software projects.” The scale of software products, the precision of component
Project Management Mechanisms
Page 36
interactions, the uncertainty over functional requirements and development methods all require
interdependence between the various parts of the development team. The purpose of
coordination, as Kraut and Streeter point out, is to “coordinate the work so that it gets done and
fits together, so that it is not done redundantly, and so that the components of the work are
handed off expeditiously.”
The most frequently cited definition of coordination is that of Malone and Crowston (1994) in
which coordination is defined as “managing the dependencies between activities”. Their
analysis considers shared resources, producer/consumer relationships, simultaneity constraints
and task/subtask dependencies. Thus, their model considers the relationships between actors,
actions, the acted upon and the constraints that may operate on combinations of all three. While
Malone and Crowston’s definition of coordination has an appealing simplicity to it, it is evident
even in their own paper that there can be dependencies between product components that have
little to do with tasks. They resolve this by arguing that their focus on tasks greatly simplifies
the analysis of a coordination situation. They further argue that dependencies between
components matter because “they, explicitly or implicitly, affect the performance of some
activities … and can, therefore, be viewed as a source of dependencies between those
activities.” While the argument seems strained when dealing with dependencies between
product components, it is less strained when dealing with tasks. They list the types of
dependencies as shared resource, producer-consumer, simultaneity and task-sub-task
relationships. Examples of each of these are given in Table 3.
Table 3: Examples of dependencies given by Malone and Crowston
Dependency type Dependency example Shared resource Activities share some limited resource. Sharing the available
expertise over several tasks or projects. Producer - consumer One activity produces something that is used by another
activity. Flow of work products, through software development. Requirements, specifications, design, code, test, released product.
Simultaneity constraints Activities need to occur at the same time, or cannot occur at the same time. Meetings depend on the simultaneous availability of the attendees. A development task depends on the simultaneous availability of the tools, inputs and people performing the activity.
Task - subtask relationships
Top down decomposition is a common method of breaking a large task into manageable tasks. Achieving the overall goal depends on achieving all the sub-goals.
Malone and Crowston’s interest is in examining which type of mechanism is useful for each
type of dependency. From there, they can examine alternative mechanisms that may be suitable
as circumstances alter (Crowston and Osborn, 1998; Crowston, 2003). As useful as that
Project Management Mechanisms
Page 37
perspective is for reasoning about specific coordination mechanisms, it does not readily deal
with the next level where different types of mechanisms can be compared when dealing with the
same dependency type under different circumstances.
2.4.2 Coordination mechanisms Sabherwal (2003) examined prior information system literature to arrive at a broad classification
of coordination mechanisms into plan, standard, formal mutual adjustment and informal mutual
adjustment. The mechanisms identified by Sabherwal are distinguished by their fixed and
variable costs. The more formal coordination mechanisms have higher initial costs but lower
variable costs. The less formal mechanisms have a lower initial cost but higher variable costs as
illustrated in Figure 2.
Sabherwal examined a number of software development projects to identify which types of
coordination mechanism were used between the developer and the supplier and whether this
evolved during the course of the project. He found that the coordination mechanisms did evolve
and that the customer preferred to pull (sic) the relationship toward a hierarchical structure,
typified by informal adjustment while the developer pulled (sic) the relationship toward a
market structure, typified by standards, plans and formal mutual adjustment (Sabherwal, 2003).
Figure 2: The classification of coordination mechanisms - from Sabherwal (2003)
Adler (1995) investigated coordination strategies between design and manufacture. In such a
setting, an absence of any form of coordination between the two functions, described
colloquially as “throw it over the wall”, is a valid coordination strategy. In all other respects, the
taxonomy of coordination mechanisms is very similar to that of Sabherwal: non-coordination,
standards-based, schedule and plan-based, mutual adjustment and teams. These are shown in
Fixed costs
Variable costs
Does the mechanism rely on a priori specification of a blueprint of action, or adjustments using information obtained during the project?
A priori specification
Mutual adjustment
Does the mechanism specify the rules for performing the task or the goals to be achieved?
Are the adjustments made in a formal, structured fashion or an informal, unstructured fashion?
Coordination by standards
Coordination by plans
Coordination by formal mutual adjustment
Coordination by informal mutual adjustment
High
High Low
Low
Project Management Mechanisms
Page 38
Table 4. Adler’s main interest was in the differing coordination strategies that were more
successful, or more frequently used, at different stages of the product development life cycle.
Table 4: Adler (1995) typology of design/manufacturing coordination mechanisms.
Pre-project phase Product and process design phase
Manufacturing phase
Non-coordination Anarchy Over-the-wall Work-arounds Standards Compatibility
standards Design rules or tacit knowledge
Manufacturing flexibility
Schedules and plans Capabilities, development schedules
Sign-offs Exceptions, resolution plans
Mutual adjustment Coordination committees
Producability design reviews
Producability engineering changes
Teams Joint development Joint teams Transition teams
Andres and Zmud (2002) investigated relationships between coordination strategy and project
success as the two contingencies of task interdependence and goal conflict varied. They
identified a three dimensional model of coordination with the dimensions being:
• Formality - vertical versus horizontal communication
• Cooperativeness - the extent of shared decision making
• Centralization - the locus of decision autonomy.
Within these three dimensions coordination mechanisms are described as organic at one extreme
and mechanistic at the other, adopting terms first used to describe different styles of
organizational management (Burns and Stalker, 1966). Informal, cooperative and decentralised
strategies reflect an organic strategy whereas formal, controlling and centralised strategies
reflect a mechanistic coordination strategy. The relationships between task interdependence,
coordination strategy and project success are illustrated in Figure 3.
Figure 3: Task interdependence - coordination strategy. An organic coordination strategy is more successful as the tasks become more interdependent. From Andres and Zmud (2002)
The relationships found between goal conflict, coordination strategy and project success are
illustrated in Figure 4.
Task Interdependence
Organic
Mechanistic
Softw
are
Proj
ect
Succ
ess
Project Management Mechanisms
Page 39
Figure 4: Goal conflict - coordination strategy. A mechanistic coordination strategy is more successful as project goals are increasingly in conflict. From Andres and Zmud (2002)
Nidumolu (1996) uses a continuum of coordination mechanisms similar to that of Andres and
Zmud (2002) although using the two dimensions of vertical coordination and horizontal
coordination. Vertical coordination is given as “the extent to which coordination between users
and IS staff is undertaken through decisions by authorized entities” while horizontal
coordination is given as “the extent to which coordination between users and IS staff is
undertaken through mutual adjustments and communication” (Nidumolu, 1996). Nidumolu
compared structural contingency and risk-based perspectives regarding the effects of
coordination and requirements uncertainty on project performance. Project performance was
measured on the two dimensions of process control and product flexibility.
Process control is described as “the extent to which the development process is under control.”
Process control is reflected in how well the project met its schedule, cost and quality objectives.
Product flexibility is given as “the extent to which the software developed at the end of the
project is able to support distinctly new products or functions in response to changing business
needs.” These two performance dimensions were chosen because they are typical of the
tradeoffs made to meet differing project objectives.
Grinter and Herbsleb (1999) investigated coordination strategies in software development when
geographical distance impeded direct communication. The thrust of their research is not to
identify coordination mechanisms, but to identify which strategies are used to solve particular
coordination problems. Four coordination strategies are identified that different organizations
use to resolve the main coordination difficulties: divide the work according to functional areas
of expertise, divide the work according to product structure (architecture), divide the work
according to process steps and divide the work according to product feature. Each strategy
attempts to deal with the main coordination problems which they identify as minimising the
amount of communication needed between the separated groups. However, each strategy does
not provide all of the necessary coordination and part of the discussion concerns the
consequences and compensatory coordination needed to make the strategy work. The
mechanisms are only briefly mentioned and are not intended to fully describe the range needed
to coordinate the work. Each of the four coordination strategies would be grouped under a plan-
based mechanism even though each is quite different from the perspective of the main problem
Softw
are
Proj
ect
Succ
ess
Goal conflict
Organic
Mechanistic
Project Management Mechanisms
Page 40
each tries to address. The theme of architecture-based coordination occurs in another study by
the same authors (Herbsleb and Grinter, 1999a).
2.4.2.1 Summary The available models of coordination (Adler, 1995; Nidumolu, 1996; Andres and Zmud, 2002;
Sabherwal, 2003) all display some form of continuum from more formal and less interactive to
less formal and more interactive. Since this research needs to identify the different coordination
mechanisms rather than deal with an undifferentiated group of mechanisms, it will adopt the
classifications proposed by Sabherwal as a result of considering the body of research concerning
coordination mechanisms; that is, plan-based, standards-based, formal mutual adjustment and
informal mutual adjustment.
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.
Project Management Mechanisms
Page 41
Table 5: Coordination by standards
Standards-based coordination mechanism
References
(Beck, 2000)
(Cusum
ano and Selby, 1997)
(Hughes and
Cotterell, 1999)
(PMB
OK
, 2000)
(Lientz and Rea,
2003)
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
Project Management Mechanisms
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)
(Cusum
ano and Selby, 1997)
(Thomsett,
1989)
(Hughes and
Cotterell,
1999)
(PMB
OK
, 2000)
(Lientz and R
ea, 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 √ Scorecards √
Project Management Mechanisms
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.
Project Management Mechanisms
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)
(Cusum
ano and Selby, 1997)
(Thomsett, 1989)
(Hughes and
Cotterell, 1999)
(PMB
OK
, 2000)
(Lientz and Rea,
2003)
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.
Project Management Mechanisms
Page 45
Project management and software development texts rarely identify and classify specific
coordination 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)
(Cusum
ano and Selby, 1997)
(Project M
anagement
Institute,2000)
(Lientz and R
ea, 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
Project Management Mechanisms
Page 46
from which researchers examine coordination. In examining coordination in outsourced
software 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.
2.5 The classification of project management mechanisms
Mechanisms of project monitoring have been investigated and discussed in Section 2.2.3, those
of project control in Section 2.3.3, and those of project coordination in Section 2.4.3. It is now
appropriate to collect together the different classifications into a combined table (Table 9).
Table 9: Classification schema for project management mechanisms used in software development
Automatic monitoring Formal monitoring Ad hoc monitoring
Monitoring mechanisms
Informal monitoring Output-based control Behaviour-based control Input-based control
Control Mechanisms
Clan control Coordination by standards Coordination by Plans Coordination by formal mutual adjustment
Coordination mechanisms
Coordination by informal mutual adjustment
The aggregated classification schema will now be used within this research.
2.6 Project Contingencies This research seeks first to investigate which mechanisms project managers use to monitor,
control and coordinate software development projects, then to investigate the effect of
organizational distance on the choice of mechanism. Determining which mechanisms project
managers use to monitor, control and coordinate software development projects could
accomplished by the relatively straight-forward means of simply asking them. However, such
data gathering would not reveal anything about why specific mechanisms were chosen or what
may have influenced the choice. To investigate what might influence the choice of project
management mechanisms, this section will examine the available literature to determine if there
is a common set of environmental variables (contingencies) that play a significant role in
Project Management Mechanisms
Page 47
determining the selection of project monitoring, control and coordination mechanisms discussed
so far.
Contingency theory, in its most general form, asserts that organizational effectiveness will
depend on the fit between environmental factors, such as technological complexity, and
organizational characteristics, such as organizational structure (Donaldson, 2001). Most
frequently it has been the relationship between technology and organizational structure that has
been explored (Woodward, 1958; Mintzberg, 1979; Perrow, 1986; Donaldson, 2001). In these
studies, technology has been defined as the organizational process of converting inputs to
outputs (Fry and Slocum, 1984). This is a much wider definition than if organizational
processes were separated from the tools and materials employed by those processes.
Nevertheless, Fry (1982) argues that there is little consensus in how the concepts of structure
and technology are made operational, leading to a view that it would be better to articulate the
components of structure and technology in order to avoid misleading generalisations. Fry also
observes that studies of technology and structure have been conducted at different
organizational levels with no attempt to control for possible effects of different organizational
levels (Fry, 1982).
Some authors have recommended a contingent approach to the study of projects (Eisenhardt and
Tabrizi, 1995; Nidumolu, 1996; Souder et al., 1998; Shenhar, 1999; Shenhar, 2001; Andres and
Zmud, 2002). Shenhar (2001) argues strongly that management should adopt a project specific
style rather than adopt a “one size fits all” approach. Andres and Zmud (2002) investigated the
fit between task interdependence, coordination mechanisms, productivity and process
satisfaction in software development projects and found that the multiple contingency
perspective was useful. In contrast, to date studies have concentrated on contingencies that
influence the choice of control mechanism (Ouchi and Maguire, 1975; Eisenhardt, 1985; Kirsch,
1996; Hamilton and Kashlak, 1999) or the choice of coordination mechanism (Nidumolu, 1996;
Andres and Zmud, 2002; Sabherwal, 2003) but not on the contingencies that that would
influence the choice of a combination of mechanisms to monitor, control and coordinate a
project.
Prior research has identified differing sets of factors related to project success in software
development projects (Gemuenden and Lechler, 1997; Cooke-Davies, 2002) but neither study
was directed at relationships between project characteristics and the choice of project
monitoring, control and coordination mechanisms.
Project Management Mechanisms
Page 48
2.6.1 Contingencies in prior research
2.6.1.1 Contingencies of monitoring mechanisms Monitoring, both in projects and organizations, is most often considered to be part of the field of
organizational control and there have been no studies that specifically consider the
contingencies of monitoring. Since this section seeks to identify contingencies of software
development projects, it would be unnecessary, as well as unwise, to speculate on what
contingencies might influence the choice of monitoring mechanism. Instead, those
contingencies identified in relation to project control will be assumed to apply also to project
monitoring.
2.6.1.2 Contingencies of control mechanisms Different types of control are more suited to some conditions than others. Ouchi (1979) argued
that “an essential element that underlies any bureaucratic or market form of control is an
assumption that it is feasible to measure, with reasonable precision, the performance that is
desired”. To that end, he proposed that the choice of control mechanism would depend on the
“ability to measure outputs” and the “knowledge of the transformation process”. The choice of
control mechanism in different circumstance proposed by Ouchi is shown in Table 10.
Table 10: The conditions determining the measurement of behaviour and of output (Ouchi, 1979).
Knowledge of the transformation process Perfect Imperfect Ability to measure outputs
High Behavior or output measurement
Output measurement
Low Behaviour measurement Ritual and ceremony, “Clan” control
Eisenhardt (1985) extended Ouchi’s work by considering the problem of control when an agent
is carrying out work on behalf of a principal. This introduced considerations of risk that
depended on the uncertainty of the outcome, with outcome assumed to be a function of
behaviour together with some possible random effects. Thus, there is some uncertainty about the
outcome even if the task is perfectly programmable and perfectly observable. Eisenhardt
separates task programmability, which is a characteristic of the task, from how well the actions
of those executing the tasks may be monitored, which she labels “behaviour measurement”.
Eisenhardt reasons that the contingencies of task programmability, behaviour measurement,
outcome measurement and risk all combine to influence the choice between an outcome-based
control strategy and a behaviour-based control strategy, as depicted in Figure 5.
Project Management Mechanisms
Page 49
Figure 5: Eisenhardt's proposed model of control strategy selection (Eisenhardt, 1985)
In a later paper that proposed several testable propositions arising from agency theory,
Eisenhardt added a further factor of the length of the relationship between the principal and the
agent (Eisenhardt, 1989a). The matter of trust in project relationships was taken up by several
researchers, most notably Das and Teng (1998; 2001), who explored relationships between trust,
risk and control strategies. Starting with an assumption that perceived risk levels will be high if
there is neither trust nor control, they propose that risk levels may be reduced through a
combination of trust and control. Although there is a great deal of detail in their work, it can be
summarised by saying that increased trust reduces the perceived risk but increased control
reduces trust and risk.
Needing to deal with multinational corporations, Hamilton and Kashlak (1999) extended
previous work on organization control theory to consider which specific host country factors
increase market variation. They proposed that host country culture, political risk as reflected in
host country restrictions on operations and host country economic instability were sufficient to
determine which control strategy would be more successful.
Software development projects were the setting for two studies of control systems. The study by
Henderson and Lee (1992) concluded that managerial control appears to be more effective when
it is behaviour-based and team-based control is more effective when it is outcome-based. That is,
organizational management, including project managers, should exercise control through
determining how the work will be accomplished while project teams exert the pressure to meet
deadlines. This begs the question of who set the deadlines and commitments in the first place.
A study by Kirsch (1996) investigated control theory in software development projects. He
argued that the theory of control is incomplete. He proposed that knowledge of the task is a key
determinant of the type of control. The study refers to the person who commissioned the project
and who acts as an interface between the development team and the intended users of the system
as the “sponsor”. In agency theory, the sponsor would be referred to as the principal. Kirsch
concluded that the sponsor’s level of systems development knowledge interacts with the extent
Task Characteristics • Task programmability
Information systems • Behaviour measurement • Outcome measurement
Uncertainty (of the outcome)
Control strategy Behaviour-based vs. Outcome-based
Influence the choice of
Project Management Mechanisms
Page 50
to which behaviours are monitored to determine the amount of behaviour control. In other
words, if the sponsor understands the system development process and monitors how the
development is being performed, there is a high level of behaviour control. Outcome control
depends on the extent to which behaviours are monitored and outcomes are measurable. Kirsch
found no relationship between clan control and any of the other variables. However, Kirsch’s
study did not find a need for more or different environmental variables than those already
arising from control theory and agency theory.
In summary, an examination of the theories of control has identified several contingencies that
may be used to influence the choice of control strategy. There is some consensus that the
contingencies of task programmability, behaviour measurement, outcome measurement and risk
apply in almost all circumstances. However, there are also situation-dependent contingencies
such as host country culture, political risk and host country restrictions.
2.6.1.3 Contingencies of coordination mechanisms Among researchers of coordination in either software development projects or product
development projects there is some consensus about the categorisation of coordination
mechanisms but less consensus about the contingency factors that influence the choice of
coordination mechanism.
Andres and Zmud (2002) chose task interdependence and goal conflict from among the
contingencies facing a work group in software development tasks. Their research was
specifically concerned with conflicting contingencies typified by the choice of task
interdependence and goal conflict. Adler (1995) analysed field data to arrive at the two
contingencies of analysability of fit issues and novelty of fit issues. Nidumolu (1996) set out to
investigate the specific contingency of requirements uncertainty and consequently only
considered uncertainty. Sabherwal (2003) studied the evolution of coordination mechanisms
within outsourced software development projects and considered the contingencies that were
relevant to the commercial relationship between the two parties.
In case study research that spanned aircraft hydraulic systems manufacture and printed circuit
board design and manufacture, Adler (1995) used a similar taxonomy of coordination
mechanisms to that of Sabherwal (2003). The study’s purpose was to examine the fit between
design and manufacturing process and the coordination mechanisms used under different
circumstances. Adler proposed two dimensions (contingency factors), suggested from the field
study, of the degree of fit novelty and the degree of analysability.
Fit novelty is increased by the newness of the product and process technology. It is related to,
and largely determines, uncertainty in the fit between the design processes and the
Project Management Mechanisms
Page 51
manufacturing processes. The effect of such uncertainties is not stated directly but is assumed to
be inefficiencies in coordination between the two, design and manufacturing, which are
expected to result in sub-optimal design or higher manufacturing costs.
Fit analysability is defined as “the difficulty of the search for an acceptable solution to the given
fit problem.” This is a reflection of how much is known about how to build whatever has been
designed. Established technologies tend to have more information available on how to build the
design. Toyota’s engineering checklists (Sobek et al., 1999) are an example of a mechanism to
determine if a design can be manufactured as are the various tools available on CAD/CAM
systems. The latter can be used to check for flaws in the design as well as to check for
manufacturability. In software development, the equivalent would be some of the formal
methods that attempt to prove the correctness of the proposed solution prior to coding the
system. This contingency also matches that of “task programmability” introduced in agency
theory (Eisenhardt, 1989a).
Nidumolu’s study concentrated on requirements uncertainty rather than consider all the possible
contingencies that might affect software development (Nidumolu, 1996). Risk-based models
consider all three, requirements uncertainty, vertical coordination and horizontal coordination as
contributors to risk, which then directly affects how well the project achieves its goals. However,
combining factors into the one overall factor of risk doesn’t help to tease out which of the many
candidate contingencies are more important for determining which coordination strategy to use
or how coordination might be affected by changes in the project’s environment.
Sabherwal (2003) identified four factors that potentially affected coordination in outsourced
software development: efficiency, equity, relational quality and uncertainty. Of these, the first
three had been identified from prior literature concerning interorganizational relationships while
the fourth, uncertainty, came from literature on coordination within organizations.
Efficiency concerns the benefits of the particular governance structure used for the undertaking.
Without attempting to provide an exhaustive list of such governance structure, these could be
outsourced development, contracted developers working within the development team or an
entire development activity performed at the developer’s site by a contracted team. While this
may be an environmental factor when considering coordination mechanisms, a particular
governance structure is part of how a project is controlled. When both project control
mechanisms and coordination mechanisms are being considered, governance mechanisms
become dependent variables rather than independent variables.
Equity concerns fairness in the dealings “requiring reciprocity but not necessarily equality”
(Sabherwal, 2003). Equity would be reduced by perceived opportunistic actions by either party
such as reassigning “start” personnel to another project (Lientz and Rea, 2003 p149). Concerns
Project Management Mechanisms
Page 52
for fairness of dealings are significant within agency theory and have a major influence in the
selection of control mechanisms.
Relational quality depends on the personal bonds between the participants, largely the
principal participants. As two organizations deal with each other, they become familiar with
each other’s methods and have some measure of trust for each other. Sabherwal points out that
relational quality also includes considerations of similar language and culture but that these
factors have not been explicitly examined for their effects on coordination mechanisms
(Sabherwal, 2003).
Uncertainty is frequently cited as something that can affect almost all aspects of software
development. In the field of organizational communication, uncertainty refers to the lack of
information about something and is distinguished from equivocality which is defined as a lack
of knowledge (Daft and Lengel, 1986). Uncertainty, in this context, can be alleviated by more
information whereas equivocality requires more knowledge. On the other hand, Kraut and
Streeter use the term “uncertainty” to group uncertainty over incomplete specifications,
knowledge about the domain, meaning and interpretations of the requirements, understanding
about precisely how to develop the software (Kraut and Streeter, 1995).
While there is no general “uncertainty management” activity in project management or software
development, there is acknowledgement of risk management, which has increased in both
visibility and importance in recent years. The Project Management Institute added the
knowledge area of “Risk Management” to the previous edition of the PMBOK to arrive at the
2000 edition (Project Management Institute, 2000). Considerations of risk management have
given rise to different software development life cycles (Boehm, 1988) and a body of research
into risks in software development (Boehm, 1991; Jones, 1994; Fenton et al., 2002; Jiang et al.,
2002; Thomsett, 2002b). While acknowledging that software development risks encompass
more than is intended by software development uncertainty, adopting risk rather than
uncertainty as a coordination contingency allows the considerable body of knowledge about risk
to be used. Additionally all of the familiar risk assessment and management techniques can be
used rather than introduce the need to define, understand and reason about uncertainty.
2.6.1.4 Contingencies of distributed projects In his paper on the evolution of coordination in outsourced projects, Sabherwal briefly describes
the costs of different types of coordination mechanism but does not include cost as one of the
factors affecting the choice of coordination mechanisms (Sabherwal, 2003). The model of
different coordination mechanisms , incorporating fixed and variable costs, given by Sabherwal
is just as applicable to any monitoring and control mechanisms. In the model, briefly illustrated
in Figure 6, the more formal mechanisms have a higher initial cost to set them up, possibly
Project Management Mechanisms
Page 53
install and configure software packages and train people in the method but once established the
costs for continuing use are minimal. This contrasts with the very informal mechanisms that
generally have very little initial costs but incur the same operational cost each time they are used.
To date there has been little, if any, research into the comparative costs of different project
management methods or, indeed, any other software development practice employed in
distributed or outsourced projects. Papers on outsourcing have tended to concentrate on the risks
rather than the costs of outsourcing (Earl, 1996; Handfield and Krause, 2000) or how
outsourcing can be achieved (Lacity et al., 1995; McFarlan and Nolan, 1995; Kornelius and
Wamelink, 1998; Carmel and Agarwal, 2001; Carmel and Agarwal, 2002). So, while costs can
reasonably be included in the set of contingencies for software development projects, there is
little empirical data on how distributing a software development project actually affects project
costs. However, that there is little empirical data does not mean that costs are irrelevant, and
they will be included as one of the contingencies.
Figure 6: Model of project mechanism fixed and variable costs - Adapted from Sabherwal (2003).
2.6.2 Project contingencies. The purpose of examining a range of project contingencies through separately considering work
on project monitoring, control and coordination is to identify a manageably small set of
contingencies that can be readily observed and that significantly influence the choice of project
monitoring, control and coordination mechanisms. The literature examined in this section thus
far does not indicate that any particular set of contingencies has more influence on the choice of
project management mechanisms than any other. Nor is there any empirical work supporting
Automated or formal mechanism intended for use over many projects e.g. CSCW tools, standards, development methodologies
Formal non-interactive mechanism instantiated for a single project e.g. project plan or schedule, project web page.
Formal interactive mechanism such as project review, design review, project meeting, ad hoc inquiry.
Informal mechanism such as co-location, conference calls, conversation, site visits.
High
High Low
Low
Fixed or set-up costs
Variable costs
Project Management Mechanisms
Page 54
one set or another. Lacking such a set of contingencies, this section will consider which
contingencies are best suited to the research of this thesis.
The contingencies should have broad applicability to software development. This eliminates
analysability of fit and novelty of fit used by Andres and Zmud (2002) because, although both
could be reinterpreted in a software development context, they apply to the fit between design
and manufacture and are not intended for the broader scope of the entire project. Similarly, task
interdependence and goal conflict (Andres and Zmud, 2002) were used in relation to project
coordination and did not extend to project monitoring or project control.
The chosen contingencies should not depend on other contingencies. Thus, Sabherwal’s
proposed contingency of efficiency, which relates to the choice of project governance, would
require that the mechanisms of project control be determined in order to reason about the choice
of coordination mechanism. This would require project control to be both a result of
contingencies as well as a contingency.
Sabherwal’s contingency of equity seems little distinguished from relational quality. Both
concern relationships between parties. Equity concerns actions whereas relational quality relates
to a continuing state of relations between the parties. If equity was perceived to be uneven
between the parties then relational quality would be affected. In the interests of reducing the
number of contingencies, and selecting those that are readily measurable, relational quality will
be retained and equity will be dropped.
The contingencies considered by Hamilton and Kashlak (1999) arose when considering
multinational organizations and are refinements of risk or, in the case of culture, will be
reflected in relational quality.
A further consideration in choosing a set of contingencies is to choose those that are already
apparent in software development projects and could be measured without undue difficulty.
This places some doubt on the merits of including relational quality because it is not something
for which measures have been developed nor is it overtly considered when managing projects.
However, the importance of cultural differences (Gregory, 1983; Hofstede, 1991; Dube and
Robey, 1999; Carmel and Agarwal, 2001; Ghemawat, 2001; Chevrier, 2003) and relationships
within software development teams (Henderson and Lee, 1992; Brooks, 1995; Hawryszkiewycz
and Gorton, 1996; Cramton, 1997) argues for its retention.
Having reviewed the available literature to arrive at the following set of contingencies, each will
now be more fully described along with their expected effects on monitoring, controlling and
coordination mechanisms. The selected set of contingencies are;
• task programmability
Project Management Mechanisms
Page 55
• task visibility
• output measurability
• project risk
• relational quality
• cost
2.6.2.1 Task programmability Knowledge of the transformation process, or task programmability, is described by Ouchi (1979)
in terms of the steps in process of transforming inputs into outputs. If we understand all of the
technology and all of the process steps involved in producing something, then it is possible to
measure, or at least observe, someone else’s knowledge of the transformation process and to
correct their behaviour if we observe some fault in their performance. In a production line where
every step has been prescribed and is observable, task programmability is high. If, on the other
hand, the task is complex or not easily programmed, then task programmability is low. For
example, the task of selling goods depends to some extent on the salesperson’s ability to sell
and is not easily prescribed in a series of predefined steps. There, task programmability is low
(Eisenhardt, 1985).
While researchers have written in general terms about task programmability because they were
considering the general problem of organizational control, software development is a specific
activity with a considerable body of knowledge about the steps in its performance and how they
should be performed. There are a large number of texts on the methods of software development.
Educational courses in all aspects of software development are readily available. There are even
international standards on the processes of software development (ISO 12207, 2002; ISO 15288,
2003) as well as guidance standards on their use (ISO 15271, 1998; ISO 19760, 2003). Thus,
while the tasks of software development may not be as programmable as, say, those of mass
producing a simple consumer product, they are far from unprogrammable.
Software development is not, however, uniformly programmable over all types of projects. The
way software development projects are structured and planned depends very much on whether
they are viewed as a production problem (Curtis et al., 1987; Boehm and Ross, 1988; Krishnan,
1998) or as a design problem (Smith and Browne, 1993; Gasson, 1998). If they are viewed as a
production problem, then it is assumed that the problem at hand is largely understood and that
its implementation in an information system is a matter of producing the required documents,
code, tests and other artefacts in a reasonably predictable and controlled manner. On the other
hand, if a project is viewed as design problem for which the solution is unknown and far from
Project Management Mechanisms
Page 56
certain, there will be more emphasis on understanding and solving the problem at hand and less
emphasis on steady progress toward project completion.
Production projects Production that is less frequently repeated in the sense of, for example, building construction is
characterized by extensive schedule planning to reduce the unknowns. Then, scheduled
activities are executed in pursuit of the final goal (Muller, 1982; Yates and Tatum, 1982).
Essential to this type of planning is that the techniques used are well known and the problems to
be solved have precedent solutions.
Many writings on project management reflect this, frequently assumed, production approach to
software development (Scarola and Tatum, 1982; McConnell, 1998; Hughes and Cotterell, 1999;
ISO 16326, 1999; Boehm, 2000; Project Management Institute, 2000; Bauch and Chung, 2001;
Thomsett, 2002a). The assumption is that planning will be done once and, with only minor
corrections, will accurately predict how the project will be carried out. This requires detailed
estimates of how long each task will take and the resources required for its completion. It is
argued that, with the software development project divided into component parts, it becomes
possible to treat software development as an engineering process, amenable to standard
monitoring, management and improvement techniques (Humphrey, 1989; 1994; 2000).
Design projects. Treating software development as a design problem is viewed differently by different groups. A
systematic approach developed by Chen (2002) in the context of Engineering Science argues
that there are a finite number of steps that will obtain a design solution. However, Chen argues
that the representation of the domain knowledge lies at the heart of the design problem. This
accords with Gasson (1998) and Curtis (1987) who see the design problem as one of
understanding the problem, which would necessarily involve the problem’s representation.
Smith and Browne (1993), however, believe that the elements of design problems are more than
its representation, however important, and include goals, constraints, alternatives,
representations and solutions.
The design process is widely seen as a collaborative process that is largely opportunistic rather
than orderly (Curtis et al., 1987; Henderson and Lee, 1992; Gasson, 1998; Chen et al., 2002).
Performance is understood in terms of how individuals systematically affect the behaviours of
each other (Henderson and Lee, 1992). Gasson (1998) further argues that the traditional model,
based on the rational model of problem solving and involving problem decomposition, requires
that all the requirements are defined before problem decomposition begins. Obviously, this is
Project Management Mechanisms
Page 57
seldom true when, on average, only 58% of requirements are specified before beginning product
design (Thomke and Reinertsen, 1998).
Volatile requirements compound the problem of designing software systems but should not be
confused with the design itself. Volatile requirements for a comparatively well understood
problem present different challenges than stable requirements for a new and little understood
problem. It is entirely possible that both challenges can be addressed by the same mechanisms,
those of the various forms of agile development (Beck, 1999; Highsmith and Cockburn, 2001;
Moore, 2001; Fowler, 2003).
The influence of task programmability on project management mechanisms From organizational control theory (Ouchi, 1979) and agency theory (Eisenhardt, 1989a), task
programmability favours behaviour-based controls. There is no information available on the
expected effect of task programmability on monitoring. However, it is proposed that increased
task programmability would favour the more formal monitoring mechanisms while reduced task
programmability would favour the less formal, more interactive monitoring mechanisms.
Greater task programmability favours coordination by standards or plans while reduced task
programmability favours coordination by mutual adjustment (Sabherwal, 2003). These results
can be summarised in a table (Table 11).
Table 11: The expected effect of task programmability on project mechanisms.
Increased task programmability
Automatic monitoring ↑ Formal monitoring ↑ Ad hoc monitoring ↓
Monitoring mechanisms
Informal monitoring ↓ Output-based control ─ Behaviour-based control ↑ Input-based control ─
Control Mechanisms
Clan control ↓ Coordination by standards ↑ Coordination by Plans ↑ Coordination by formal mutual adjustment
↓
Coordination mechanisms
Coordination by informal mutual adjustment
↓
Notes: In this and following similar tables, “↑” indicates that an increase in the contingency is expected to favour the use of the particular mechanism. “↓” indicates that the contingency is expected to discourage the use of the particular mechanism. “─” indicates that the contingency is not expected affect the use of the mechanism.
Project Management Mechanisms
Page 58
2.6.2.2 Task visibility A task may be programmable but not visible to those who want to monitor it. Agency theory
specifically considers how much visibility the principal has into the activities of the agent, and
the consequences of this. Eisenhardt (1989a) argues that there are two possible responses to a
lack of visibility and they are to invest in information systems that can discover the information
thereby making the task more visible, or to contract the outcomes thereby obviating the need to
monitor task performance.
Task visibility in software development is affected by access and by understanding. If the task is
being performed remotely and the person performing it simply doesn’t reveal any information,
then the task is not very visible. On the other hand, if the task is comprehended by very few,
then few are likely to understand what it is they are seeing even if everything about the task is
highly visible (Kirsch, 1996). This second condition will be considered in Section 2.6.2.3 when
output measurability is discussed.
For this discussion on task visibility, it will be assumed that the task is readily measurable and
that the measures are widely understood. These assumptions direct attention to how well the
project manager is able to verify matters for themselves. If project tasks are highly visible then
less information would be needed because the project manager could determine exactly what it
is they needed to know and easily verify the accuracy of it. But if the task is less visible, they
would be less able to verify specific information and would need to rely on multiple sources in
order to deduce the true state of affairs.
Table 12: The expected effect of increased task visibility on project management mechanisms.
Increased task visibility
Automatic monitoring ↑ Formal monitoring ↑ Ad hoc monitoring ↓
Monitoring mechanisms
Informal monitoring ↓ Output-based control ─ Behaviour-based control ↑ Input-based control ─
Control Mechanisms
Clan control ↓ Coordination by standards
↑
Coordination by Plans ↑ Coordination by formal mutual adjustment
↓
Coordination mechanisms
Coordination by informal mutual adjustment
↓
Project Management Mechanisms
Page 59
Measurement programmes in software development serve to increase the visibility of the
development process as much as they guide efforts toward better quality products (Curtis et al.,
1987; Kitchenham and Walker, 1989; Atkinson et al., 1998; Fenton, 2000; Herbsleb and
Mockus, 2003). Herbsleb and Grinter (1998) note that corporate wide metrics programmes
“provide unprecedented opportunities to gain insight into the software development process”
which indicates that measurement programs provide greater visibility. In turn, measurements of
attributes of the software development process would favour the more formal monitoring,
control and coordination mechanisms.
The effect of task visibility on project management mechanisms High task visibility favours behaviour controls (Eisenhardt, 1989a). In fact, Eisenhardt proposes
that information systems are positively related to behaviour-based controls. Since information
systems provide information about the task, they would increase the task visibility.
Task visibility achieved through measurement programs favours the more formal monitoring
and coordination mechanisms. A summary of the expected effects of increased task visibility on
project management mechanisms is shown in Table 12.
2.6.2.3 Output measurability Some outputs can be readily measured, others less readily. In the case of selling goods, referred
to previously, goods are either sold or not sold and it is easy to measure. Ouchi (1979) gives the
example of the Apollo moon-shot program where the outcome was that either the manned
capsule got to the surface of the moon and returned safely or it did not. Measuring whether the
capsule returned safely is relatively easy. Both Ouchi and Eisenhardt (1985) proposed that high
output measurability favoured output control when task programmability is low. Eisenhardt
confirmed this proposal with empirical research investigating relationships between task
programmability and reward strategies in specialty stores.
Outputs may be observable but not easily measurable. Software quality is often given as one of
the measures of software development success (Kraut and Streeter, 1995; Linberg, 1999;
Johnson et al., 2001). While software quality may be observable to the user, precise measures of
software quality are hard to come by. A measure such as “the absence of defects in the
software” (Kraut and Streeter, 1995) unless qualified in some way doesn’t define what are
considered to be defects and doesn’t define the meaning of presence or absence. So, although an
outcome may be observable it is not necessarily easily measured.
Some of the more basic measurements such as the size of a project can be measured by a count
of function points (Thomsett, 1989; Boehm et al., 1995; Kitchenham et al., 1995), lines of code
Project Management Mechanisms
Page 60
(Jones, 1996; Boehm, 2000) or even a count of the number of requirements. That there are
multiple measures of the same attribute does not alter the basic measurability of that attribute.
Where measurability is less possible is in some of the non-functional attributes such as
reliability, robustness or the much debated measures of complexity (Fenton, 1994). A
judgement on how “good” is the design of a software system is similarly difficult to define. That
it may be difficult has not stopped various attempts to establish measures that either directly
measure non-functional attributes, or measure attributes believed to predict non-functional
attributes (Fenton, 1994; Musa, 1997; Park and Hwan Lim, 1999).
Attributes that are more measurable should be more repeatable (repeated measures produce the
same result) and reproducible (different people produce the same result). The measurement
could be performed by almost any means, by almost any person and be easily communicated.
Attributes with low measurability would be difficult to reproduce and communicate. They
would tend to require the project manager perform the measurement themselves and tend to
require more than one measure of the same attribute. For example, a judgement that a project
team has been working too hard and needed to ease up is more easily made by the project
manager simply talking to the project team and observing their behaviour than by indirect
measures of the average number of hours worked per week.
Increased output measurability favours formal monitoring and coordination mechanisms, and
favours output control. A summary of the expected effect of increased output measurability is
shown in Table 13.
Table 13: The expected effect of increased output measurability on project management mechanisms.
Increased output measurability
Automatic monitoring ↑ Formal monitoring ↑ Ad hoc monitoring ─
Monitoring mechanisms
Informal monitoring ↓ Output-based control ↑ Behaviour-based control ─ Input-based control ─
Control Mechanisms
Clan control ↓ Coordination by standards
↑
Coordination by Plans ↑ Coordination by formal mutual adjustment
↓
Coordination mechanisms
Coordination by informal mutual adjustment
↓
Project Management Mechanisms
Page 61
2.6.2.4 Project risk Risk, or uncertainty, in this context includes such factors as competitor actions, government
policies, the weather and anything else that is outside the control of either the principal or the
agent for which the agent bears the risk. Hamilton and Kashlak (1999) also have a measure of
environmental effects outside the control of either party but confine the measure to cultural
distance between the principal’s country and the agent’s country, host country restrictions and
host country economic instability.
While cultural differences have been noted to affect software development projects (Perkins,
1999; Nicholson and Sahay, 2001; Borchers, 2003; Chevrier, 2003), precisely how, and how
much, the effects might be has yet to be established. Hamilton and Kashlak (1999) use the
concept of cultural distance but don’t provide a specific measure. Hofstede (1983b) developed
the most well known measures of culture using four, and later five, dimensions. Hofstede’s
work was broadly supported by Ronen (1985) who also supports the use of cultural distance to
indicate, rather than precisely define cultural differences. Influences on selection of control
mechanisms doesn’t require high precision so it is reasonable to argue that Hofstede’s
dimensional model of culture is sufficient for the purpose.
Hamilton and Kashlak combine cultural distance with host country restrictions and economic
stability, suggesting that the magnitude of the restrictions will bear some relation to influence on
choice of control mechanism. Their review of the available measures of political risk and
economic restrictions concluded that the Euromoney country-risk index captured the essential
information and should be used in future empirical examinations (Hamilton and Kashlak, 1999).
For their purposes precision was not required.
Risk and control Eisenhardt extended Ouchi’s organizational control model for use within agency theory by
including the dimension of uncertainty (Eisenhardt, 1989a). She proposed that increased
outcome uncertainty would favour behaviour-based contracts. However, the risk averseness of
the two parties, the agent and the principal, may alter the overall control preference. A risk
averse agent favours a behaviour-based contract while a risk averse principal favours an output-
based contract. Hamilton and Kashlak (1999) examined three different factors that would
contribute to outcome uncertainty and represent risk to the principal. They proposed that output
controls would be preferred when the level of uncertainty was low but that input control would
be preferred when the uncertainty level was high.
One of the reactions of the software industry to project risk has been to introduce alternative
development life cycles. For the most part, risk is reduced through some form of gradual
development, whether this is through a “spiral” development life cycle (Boehm, 1988),
Project Management Mechanisms
Page 62
incrementally adding functionality (Tran and Galka, 1991; Cusumano and Selby, 1997;
Karlsson et al., 2000; Shenhar, 2001), evolving the software product (Boehm and Ross, 1988;
Gilb, 1988) or one of the more recent “agile” development methodologies (Thomke and
Reinertsen, 1998; Beck, 2000; Ghemawat, 2001; Highsmith and Cockburn, 2001; Fowler, 2003;
Cockburn, 2004). Despite the differences in these software development life cycles, they are all
examples of behaviour control.
Risk and monitoring Eisenhardt argues that, as outcome uncertainty increases, the cost of shifting risk to the agent
increases and therefore behaviour-based controls are favoured (Eisenhardt, 1989a). Since
agency theory does not separate monitoring and controlling activities but assumes that
monitoring is performed as part of the control activities, behaviour control requires more
information. However, the propositions of agency theory do not say how behaviour control
might be affected by varying uncertainty. Chenhall (2003) reviewed a number of authors on
management control systems and found that high task uncertainty was associated with more
participative management control systems that sought broader scope information.
Das and Teng (2001) separate risk into relational risk and performance risk in order to examine
relationships between risk, trust and control. They argue that relational risk, i.e. risk that a
partner will engage in opportunistic behaviour, is best reduced by behaviour controls.
Performance risk, i.e. the risk that the partner will be unable to complete the task, is best
reduced by output control. When both relational risk and performance risk are present, it is
social or clan controls that are most effective (Das and Teng, 2001). This implies that the more
informal, social monitoring mechanisms will be employed when overall risk is higher and the
more formal monitoring mechanisms, that don’t necessarily involve direct contact between the
two parties, will be favoured when overall risk is lower.
Table 14: The expected effect of increased risk on project management mechanisms.
Increased risk Automatic monitoring ─ Formal monitoring ─ Ad hoc monitoring ↑
Monitoring mechanisms
Informal monitoring ↑ Output-based control ─ Behaviour-based control ↑ Input-based control ↑
Control Mechanisms
Clan control ↑ Coordination by standards ↓ Coordination by Plans ↓ Coordination by formal mutual adjustment ↑
Coordination mechanisms
Coordination by informal mutual adjustment
↑
Project Management Mechanisms
Page 63
Risk and coordination Nidumolu (1996) examined the relationship between risk, principally requirements uncertainty,
and coordination mechanisms and showed that increased requirements uncertainty favoured
horizontal coordination mechanisms while the opposite, reduced requirements uncertainty,
favoured vertical coordination mechanisms. Vertical coordination is given as the extent to
which coordination between users is undertaken through decisions of authorities such as project
managers and steering committees. Horizontal coordination is achieved through mutual
adjustment. This conclusion echoes and reinforces earlier work on structural contingency where
increased technical complexity is associated with a more organic organizational system
(Woodward, 1958; Burns and Stalker, 1966; Lawrence and Lorsch, 1967; Mintzberg, 1979;
Perrow, 1986).
The expected effect of risk on project management mechanisms From a review of the available literature the expected effect of increased uncertainty (risk) on
the selection of project management mechanisms can be summarised as shown in Table 14.
2.6.2.5 Relational Quality Relational quality describes “the extent to which the partners feel comfortable and are willing to
rely on trust in dealing with one another” (Arino et al., 2001). Four elements contribute to
relational quality:
• Initial conditions that surround the exchange, including any prior dealings the partners
may have had with each other.
• The negotiation process, through which the partners form opinions about each other’s
organizational capabilities, technical competence and ethical behaviour.
• Their experience with each other’s behaviour during the venture.
• The partner’s behaviour outside the context of the venture.
Clearly, relational quality collects together the various forms of trust between partners (Arino et
al., 2001).
The concept of trust has been seen as a critical success factor in partnering projects (Kadefors,
2004) with the acknowledgement that not all partnering projects are successful. But trust is not
something that can be demanded of a partner or imposed on a partner in the same way that some
governance mechanisms can be, but instead must be established and maintained. Kadefors
reviewed the literature to conclude that there were three types of trust: calculus-based, relational
Project Management Mechanisms
Page 64
and institution based. Gallivan and Depledge (2003), who also reviewed the literature on trust,
concluded that the term “trust” can be made to mean whatever the theorist or practitioner wants
it to mean. The most consistent definition of trust expresses the view that one party is willing to
expose itself to potential harm by another party. That definition still allows for various types of
trust in relations between two parties.
Relational trust arises between individuals who repeatedly interact over time (Kadefors, 2004).
The parties obtain direct evidence of trustworthiness through direct experience with each other
and are able to gauge the level of trust each has for the other. Arino and de la Torre (1998)
called this “relational quality” referring to each party’s assessment of the quality of the
relationship. Arino and de la Torre found that relational quality was continually being assessed,
though not through any formal means, and could cause partners to engage in renegotiations of
the terms of the contract or to modify their behaviour unilaterally until a new mutual
understanding is restored.
Relational quality is likely to be low at the beginning of a relationship when the partners have
not had time to experience each other but must rely on the calculus-based trust. This calculus-
based trust will be based on the broader reputations their institutions have for fair dealings
(Arino and de la Torre, 1998). Models of the evolution of the relationship are that both partners
must learn about the environment, tasks, skills, processes and goals and revaluate the efficiency
and equity of the relationship throughout its life (Doz, 1996; Arino and de la Torre, 1998). If
learning and revaluation were not performed, the relationship tended to fail (Doz, 1996).
Where Arino and de la Torre (1998) see trust as substituting for or moderating more formal
governance structures, Das and Teng (1998) regard trust as a component of confidence that is
required to launch and sustain cooperation in an alliance. Various types of alliance may require
different levels of confidence in partner cooperation. Some alliances require some
unrecoverable alliance-specific investments, in which case partners need more certainty about
the alliance before committing substantially to an alliance. On the other hand, if there is little
unrecoverable investment then a contractual relationship, where there is no trust, may be
adequate.
Relational quality and monitoring From the project manager’s viewpoint, when trust is high, they would not need to check
information supplied by a partner because there is trust that the information is correct and there
is no intention to mislead (Das and Teng, 2001). Any inaccuracies would be assumed to be
errors and corrected in due course. Thus, high levels of trust should enhance formal monitoring
because there is no belief on the part of the monitored that the information would be misused
(Das and Teng, 2001).
Project Management Mechanisms
Page 65
Even though the mechanisms of formal monitoring are quite robust and can tolerate a certain
amount of mistrust, there would be a point beyond which a lack of trust would be counter-
productive. Project managers can always take action to verify the information they are receiving
is correct, albeit at some expense. If the relationship degenerates to the point where the project
manager must check much of the information they are receiving, then the relationship would be
in danger of dissolution. But if dissolution was not an allowable outcome, as it might be in the
middle of a contract, then the two parties would simply continue to incur the expense of
checking.
Relational quality and control Das and Teng (2001) propose that both output control and behaviour control will undermine
relational trust and calculus-based trust in an alliance because “ the employment of strict rules
and objectives means that members do not have the autonomy to decide what works best.”.
Members’ goodwill is thrown into doubt and an atmosphere of mistrust is created. However,
these propositions have yet to be tested empirically. Gallivan and Depledge (2003) find partial
support for this proposition through a study involving content analysis of partnerships. While
control generally has a negative effect on trust, not all forms of control affect trust in
partnerships. Gallivan and Depledge cite examples of supplier performance evaluation systems,
SCORE and Scorecard, that have had an overall positive effect on supply partnerships.
Conversely, Das and Teng (2001) propose that goodwill trust and competence trust will enhance
the effectiveness of all control modes. So trust will enhance control but control will usually
diminish trust. Relational quality and clan control interact to reinforce each other (Das and Teng,
2001). When the situation does not have clear outcomes and there is no clear way of proceeding,
organizations come to share the same values and goals through consensus making, discouraging
opportunistic behaviour (Das and Teng, 2001). Thus, clan control will reinforce relational
quality. Increased relational quality implies greater trust in the other party but does not
necessarily lead to shared goals. Das and Teng also note that inadequate goodwill trust,
therefore reduced relational quality, “makes partners wonder whether control is for the purpose
of advancing someone’s private interest rather than the common interests of the alliance.” This
implies that reduced relational quality would discourage clan control, not only the establishment
of clan control but also would tend to undermine any previously established clan control.
Relational quality and coordination Relational quality affects the amount and variety of coordination each party believes is
necessary in the relationship. If relational quality is high, less coordination is thought to be
necessary but, when relational quality is low, each party believes more coordination is necessary
(Sabherwal, 2003). Sabherwal observes that in outsourcing, both the client and the vendor may
Project Management Mechanisms
Page 66
feel vulnerable to opportunistic behaviour by the other. He found that clients tended to prefer
informal mutual adjustment whereas the vendors preferred to use standard-based coordination
mechanisms. The preference of each party attempts to prevent opportunistic behaviour while
minimising the cost to themselves. The mutual adjustment mechanisms generally incur travel
and accommodation costs to the vendor (developer) whereas standards-based mechanisms
require the client to invest time to understand and approve the proposed standards. In
Sabherwal’s study, it was the vendors who proposed that standards be used for coordination. If
it was the project manager that proposed the use of standards-based coordination mechanisms,
the costs of understanding and complying with the standard would be borne by the developer.
Thus, in this research it is assumed that both the project manager and the project team may be
concerned about opportunistic behaviour but most of the costs would be borne by the project
team because they need to adapt to the demands of the coordination mechanism.
Changes in relational quality affect the use and type of coordination mechanisms (Sabherwal,
2003). If relational trust changes from high to low, as it might following concerns about
efficiency, coordination effort would be increased. Conversely, if relational quality increased
during a project, coordination effort might be reduced.
The effect of relational quality on project management mechanisms Reduced relational quality increases the need for monitoring, control and coordination. From
this it can be deduced that increased relational quality favours the less intrusive forms of
monitoring, control and coordination. This is summarised and shown in Table 15.
Table 15: The expected effect of increased relational quality on project management mechanisms.
Increased relational quality
Automatic monitoring ↑ Formal monitoring ↑ Ad hoc monitoring ─
Monitoring mechanisms
Informal monitoring ↓ Output-based control ↑ Behaviour-based control ↑ Input-based control ↑
Control Mechanisms
Clan control ↑ Coordination by standards ↑ Coordination by Plans ↑ Coordination by formal mutual adjustment
↓
Coordination mechanisms
Coordination by informal mutual adjustment
↓
Project Management Mechanisms
Page 67
2.6.2.6 Cost The cost of using a project management mechanism is a combination of its fixed and variable
costs (Sabherwal, 2003). The fixed costs are incurred when the mechanism is first deployed and
include, for example, acquisition, installation and training. As an example, to acquire and install
a configuration management system will incur the cost of purchasing the software, computer
resources to support its use, the cost to install and configure it, any conversion cost involved in
loading the initial data and training costs. Adopting a standard method of performing and
reporting design reviews would generally incur the training costs only. The variable costs are
incurred each time the mechanism is used. In the case of the configuration management tool, the
variable costs come from the time involved in using the configuration management system.
Similarly, the cost of conducting a design review would come from the time involved in
preparing, conducting, reporting the review and the time involved in correcting any defects
revealed by the review. In contrast to the two mechanisms discussed so far, the fixed cost of co-
location would be the cost of physically moving the personnel to the same location while the
variable costs come from the costs of keeping the personnel in the same location.
Ritzer (2004) argues that organizations seek the lowest cost of producing a given product or
service through activities typified by the fast food industry. Hence the term “McDonaldization”
to describe the drive toward ever greater efficiency. One of the main methods of reducing
production costs has been through automating many of the production steps, increasing
predictability and reducing costs. Software development projects seek the same goal of lowered
cost (Back and Moreau, 2001; Johnson et al., 2001). Automating the processes of software
development through workflow systems, configuration management tools, automated testing
and more powerful programming languages are ways of achieving this.
Microsoft enforces the use of the one programming language and common coding standards in
their development projects allowing people to move between groups on the same product and
even between projects (Cusumano and Selby, 1997). While some of Microsoft’s development
practices may be aimed at allowing a large number of people to work on the same product
development, they also have the side effect of reducing the development cost through avoiding
rework. Using a standard set of development processes and a common set of design standards
will enable software development to be distributed. In fact, it isn’t the cost of development that
is reduced so much as the cost of integrating components after distributed development that is
reduced through common standards (Cusumano and Selby, 1997). In distributed projects, cost
considerations would also favour suppliers and partners who already used the same tools,
processes and standards because the fixed costs of establishing the project management
mechanisms would be substantially reduced. Thus, organizations adopt common software
Project Management Mechanisms
Page 68
development processes such as through CMMI accreditation, or adopt common quality
management systems such as through ISO 9001 accreditation.
If the organization believes that the mechanism will operate over sufficient projects to recoup its
fixed costs, then it is likely to implement the mechanism. But if the project circumstances are
sufficiently unique that they are unlikely to be repeated, or of short duration, then recouping the
mechanism’s fixed costs becomes more difficult. In that case, a mechanism with a lower fixed
cost is more likely to be chosen.
However, some tools such as configuration management tools, requirements management tools,
defect tracking tools, standard development methodologies may be adopted for reasons other
than reduced project costs. Frequently, these tools are adopted as part of a quality management
initiative (Kitchenham and Walker, 1989; Davis and Mullaney, 2003; Evans and Jack, 2003;
Kontoghiorghes, 2003). Even so, quality management objectives are pursued with economy in
mind.
The effect of cost on project management mechanisms Overall, the need to reduce costs favours the more formal, low variable cost project
management mechanisms for long term projects but favour the low fixed cost mechanisms for
short term projects. This is summarised in Table 16.
Table 16: The effect of cost on project management mechanisms.
Increased fixed cost
Increased variable cost
Automatic monitoring ↓ ↑ Formal monitoring ↓ ↑ Ad hoc monitoring ↑ ─
Monitoring mechanisms
Informal monitoring ↑ ↓ Output-based control ─ ─ Behaviour-based control ↑ ─ Input-based control ─ ─
Control Mechanisms
Clan control ↓ ↑ Coordination by standards ↓ ↑ Coordination by Plans ↓ ↑ Coordination by formal mutual adjustment
↑ ↓
Coordination mechanisms
Coordination by informal mutual adjustment
↑ ↓
Project Management Mechanisms
Page 69
2.7 Conclusion Project management mechanisms for project monitoring, controlling and coordinating a
software development project can be classified into groupings that are generally agreed by
researchers. So far, researchers have identified groups of mechanisms within each type of
project management mechanism but have not identified a classification scheme for all project
management mechanisms regardless of whether they would be used for monitoring, control or
coordination. There is less consensus about contingencies that affect the selection and use of the
differing project management mechanisms. Nevertheless, the proposed set of contingencies has
been developed from the available literature and is believed to be a useful set with which to
investigate questions about the selection and use of the different mechanisms.
While it is acknowledged that the different contingencies will interact, as will the different
project management mechanisms, to consider even a small number of the interactions is beyond
the scope of this thesis. For this reason the effects of the different contingencies on the different
project management mechanisms will be summarised in Table 17 as if they were independent of
each other. This allows reasoning about a portfolio of project management mechanisms without
needing to consider potential or actual interactions between them.
Thus far, we have examined a wide range of literature to determine which mechanisms are used
by project managers to monitor, control and coordinate software development projects, and have
selected a set of contingencies that are expected to influence the choice of project management
mechanism in different circumstances. While it would be possible to conduct empirical research
to confirm relationships between the contingencies and the choice of project management
mechanism, it would require a large research project to gather all the data necessary to cover the
number of contingencies and their possible combinations.
It would be more efficient to use a particular setting, such as distributed software development,
to reason about the expected effects of that changing environment on the selected contingency
factors and, consequently, on the choice of project management mechanism. The next chapter
will define the concept of organizational distance, use it to reason about the set of contingencies
and then to predict the effect of organizational distance on the selection of project monitoring,
control and coordination mechanisms.
Project Management Mechanisms
Page 70
Table 17: Summary of the expected effect of increasing contingency on project management mechanisms.
In
crea
sed
task
pr
ogra
mm
abili
ty
Incr
ease
d ta
sk v
isib
ility
Incr
ease
d ou
tput
m
easu
rabi
lity
Incr
ease
d ri
sk
Incr
ease
d re
latio
nal
qual
ity
Incr
ease
d fix
ed c
ost
Incr
ease
d va
riab
le c
ost
Automatic monitoring ↑ ↑ ↑ ─ ↑ ↓ ↑ Formal monitoring ↑ ↑ ↑ ─ ↑ ↓ ↑ Ad hoc monitoring ↓ ↓ ─ ↑ ─ ↑ ─ Informal monitoring ↓ ↓ ↓ ↑ ↓ ↑ ↓ Output-based control ─ ─ ↑ ─ ↑ ─ ─ Behaviour-based control ↑ ↑ ─ ↑ ↑ ↑ ─ Input-based control ─ ─ ─ ↑ ↑ ─ ─ Clan control ↓ ↓ ↓ ↑ ↑ ↓ ↑ Coordination by standards ↑ ↑ ↑ ↓ ↑ ↓ ↑ Coordination by Plans ↑ ↑ ↑ ↓ ↑ ↓ ↑ Coordination by formal mutual adjustment
↓ ↓ ↓ ↑ ↓ ↑ ↓
Coordination by informal mutual adjustment
↓ ↓ ↓ ↑ ↓ ↑ ↓
Page 71
3 Organizational distance The previous chapter identified project management mechanisms and the contingencies that
influence their selection and use. Potentially there are many environments to which the
contingencies may be sensitive such as the dispersion of the development team, the dispersion
of the technologies being used to develop the product or that must be integrated into the product,
or the diversity of tasks that the intended product must accomplish. In order for this research to
examine how project management mechanisms are affected as an environment changes, the
relevant factors of that environment must be identified.
In this chapter, the concept of organizational distance is investigated. Projects in which the team
is not co-located may require different mechanisms of monitoring, control and coordination
depending on the organizational distance between the project manager and the project team.
Firstly, existing models of organizational distance will be investigated before proposing a model
suitable to the current research. Then the factors that make up the proposed model will be
explored in preparation for investigating the effect of organizational distance on project
management mechanisms.
3.1 Distance within organizations To investigate the dyadic relationship between a supervisor and their subordinate, Napier and
Ferris (1993). proposed a model of organizational distance (Table 18) comprised of
psychological distance, functional distance and structural distance. Their objective was to
integrate the various concepts of distance in organizations to improve the efficiency in dealing
with some human resource issues within organizations. Although Ferris and Napier identify “the
globalization of the economy” among the motivations for their model, and say that the model
has implications for other aspects of distance, including distance between an individual and a
work group, the model appears to focus on supervisor-subordinate relations, limiting the
model’s applicability to inter-group relations. The model was also proposed to serve as a
foundation to a range of future research rather than to reason about a body of existing research
results.
Organizational Distance
Page 72
As noted above, Napier and Ferris’s model has three main constructs: psychological distance,
structural distance and functional distance. Psychological distance “refers to the psychological
effects of actual and perceived demographic, cultural, and value differences” between the two
parties. A number of contributors to psychological distance are proposed without presenting a
method with which the various contributions could be combined to form an overall
psychological distance.
Table 18: Napier and Ferris Dimension of Dyadic Distance in Supervisor-Subordinate Relationship
Distance construct General Indicators Specific indicators Psychological distance Demographic similarity
Power distance Perceived similarity
Age, Sex, Education, Experience and Race distance
Values similarity Work related value, Sex role orientation and Cultural value distance
Structural distance Design distance Office design distance, Physical distance
Opportunity to interact Social contact at work, Social contact outside work, Accessibility
Spatial distance Span of management
Functional Distance Affect Liking, Support, Trust Perceptual Congruence Sex Role perceptions Latitude Role discretion (Autonomy),
Influence in decision-making Relationship Quality Supervision satisfaction,
Relationship satisfaction The dimension of structural distance is intended to capture the aspects of physical distance as
well as organizational structure. The conceptual link that binds those factors that contribute
toward structural distance all have to do with the amount of interaction in the supervisor-
subordinate relationship. This construct depends on the same assumptions of an additive effect
of independent contributors and appears to be acceptable for the same reasons as previously
stated.
The third construct proposed by Napier and Ferris is that of Functional Distance. This describes
“the degree of closeness and quality of functional working relationship between the supervisor
and subordinate”. Of the factors given as contributing to Functional Distance, relationship
quality seems to combine the other factors of affect (liking, support and trust), perceptual
congruence (the degree to which members of the dyad understand each other) and latitude (the
degree to which the subordinate has both latitude and discretion). In the context of outsourced
software development, relationship quality would be one of the easier factors a project manager
Organizational Distance
Page 73
could readily understand and reasonably rate. Relational quality identified by Sabherwal (2003)
appears to refer to the same aspect of a commercial relationship.
Each of the constructs (psychological distance, structural distance and functional distance) is
comprised of several sub-constructs. The relationship between each of the constructs and their
respective sub-constructs appears to be that the sub-constructs are independent and the effect of
each simply accumulates to give the overall effect. Since each of the contributions represents
some form of separation for which a measure might be possible, it is reasonable to assume that
simply adding the individual separations together would give an overall measure of distance. To
do so denies the possibility that the different contributions are unequal or that the relationship
between them is not independent. However, the purpose of the measure seems to be
comparative, where two endpoints are adjudged more, or less, separated than two other
endpoints. For such a purpose, absolute accuracy is not required and the assumed independence
and simple relationship among the contributors seems to be acceptable.
Napier and Ferris’s model focussed on the relationships between a supervisor and subordinate
within an organization, possibly a globally dispersed organization. Extending it unchanged to
deal with project management issues in distributed and outsourced projects presents some
problems. However, it can provide a basic structure and a departure point.
3.2 Proposed model of organizational distance This thesis requires not so much a model on which to base future research but a simpler model
made of readily measured constructs that can give a ready, if approximate, measure of
organizational distance. Since Napier and Ferris’s model has been subjected to peer review, it is
desirable to retain the overall structure of their model. To achieve this objective, a model of
organizational distance consisting of cultural distance, structural distance and administrative
distance is proposed (Table 19).
This model is simpler than that of Napier and Ferris, employs more easily measured constructs,
and is easier to use in research that requires a simple measure of organizational distance, yet
retains the structure of the original. The components of the proposed model are expanded in the
sections that follow.
Organizational Distance
Page 74
Table 19: Proposed model of organizational distance between project manager and project team members
Distance construct Definition Indicators Cultural distance A measure of the extent to
which cultures are similar or different on selected values.
Individualism - collectivism Power distance Uncertainty avoidance Masculinity - femininity Long term - short term outlook
Structural distance Physical separation Geographical distance Time zone difference Communication separation
Administrative distance Organizational and structural separation between project manager and project team
Access to project team Project reporting structure
3.2.1 Cultural distance Of the factors that Napier and Ferris identify as contributing to psychological distance, only
cultural distance has been studied extensively. Organizational cultures (Kanter, 1985; Schein,
1996; Martin, 2002) and professional cultures (Duliba and Baroudi, 1991; Hansen, 1995;
Cameron, 2001; Carayannis and Sagi, 2001) have been studied, sometimes popularly (Peters
and Waterman, 1982), but there has not been a structure proposed that might measure or
characterise organizational or professional culture in the same way that Hofstede characterised
national cultures (Hofstede, 1983b)
The distance between cultures is indicated by the ease, or its lack, with which members of
different cultures understand each other and work together. Several case studies (Dube and
Robey, 1999; Youker, 1999; Nicholson and Sahay, 2001) have as their theme that national
cultures affect how international projects are or should be managed. All of the case studies
regard culture as one of the factors affecting the project but none of them focus on how culture
affects project management. Rather, it seems that research in this area has barely progressed
beyond experience reports.
Hofstede (1991) published the most extensive characterisation of different cultures. He
characterised cultures by their position on five dimensions: power distance, individualism
versus collectivism, masculinity versus femininity, uncertainty avoidance and long term versus
short term outlook. Ronen and Shenkar (1985) found broad agreement among many researchers
that countries could be clustered by their cultural similarities and broad agreement on the
clusters and which countries belonged in the various clusters. Hofstede is careful to point out
that his research merely classifies and does not imply that any country is better or worse than
Organizational Distance
Page 75
any other, or more predisposed toward, say, an occupation than any other. In a paper on project
management, Hofstede (1983a) summarises the first four dimensions (the fifth was added after
the paper was published) but merely points out that national cultures will make a difference to
project management. He does not venture into the nature of that difference.
Shenkar (2001) reviewed the concept of cultural distance to point out some of the illusions that
undermine the validity of the concept of cultural distance. His criticism appears to be that the
concept of cultural distance is too often taken as an interval measure when in fact it has not been
shown to have the properties of an interval measure. That cultures are different and that these
differences matter is not questioned, only that care should be taken when treating cultural
distance as some sort of measure.
In an experiment that involved ten teams of students from the City University of Hong Kong
and Eindhoven University of Technology in The Netherlands, Vogel et al. (2001) report that
there were several issues related to cultural differences. The specific nature of these differences
and their effects are not important, other than that they exist, because each project and each
combination of cultures will bring forward a different set of issues. The overall effect is to
increase “the ambiguity, complexity and confusion in group processes” (Chevrier, 2003).
In all cases, the differences between national cultures had a negative effect on project
performance (Youker, 1999; Ghemawat, 2001; Massey et al., 2001; Nicholson and Sahay, 2001;
Borchers, 2003; Chevrier, 2003). So far there has been no report of cultural differences within
an organization actually improving project performance.
Software design is an activity in which the design team builds a shared mental model (Walz et
al., 1993; Levesque et al., 2001) that enables them to communicate effectively about the design.
Levesque et al. found that this shared mental model did not build up continuously nor remain
for any length of time but rather seemed to develop when and as it was needed to perform a
specific task and then dissipate. This would imply that development teams need to closely
coordinate their work only some of the time, which would enable a team to come together for a
specific activity of limited duration and then, having completed the activity, to disperse again.
On the other hand, Gasson (1998) argues that the design activity pervades the whole of the
development life cycle, which would imply that the whole team needs to be in close contact all
the time. Certainly, when the problem to be solved is novel, greater coordination may be
required to both explore the problem, then design and implement its solution. Neither Gasson
(1998) nor Smith (1993) indicate how prevalent novel problems are. If many of the software
systems being developed have precedent solutions or are a redevelopment of an existing system,
it is difficult to argue that they should be treated as a completely novel problem requiring
significant design.
Organizational Distance
Page 76
The potential for misunderstandings is significant when a project is executed in one culture and
monitored in another. Not only do concepts differ but the whole notion of monitoring may be
entirely different3. Some common practices may also be viewed differently by different cultures.
In Australia the idea of independent review is well established and there is no significant stigma
attached to a mildly adverse review finding. Major adverse findings such as an ISO 9001 audit
non-conformance may cause problems but there is still the view that the audit should proceed
and find whatever it finds. However, in countries with a greater power distance (Hofstede, 1991
p27), monitoring may be seen as a lack of trust in the person in charge, with attendant loss of
face on the part of the monitored. This would be especially so if there are any adverse findings.
Consequently, while the idea of independent audit may be well accepted in western cultures, it
might not be at all welcome in other cultures. It is reasonably well accepted that national
cultures do affect software development projects but it is less well established how project
management practices are, or should, change because of it.
3.2.2 Structural distance Structural distance is a measure of physical separation. It encompasses physical distance as well
as temporal distance.
Herbsleb and Mockus (2003) found that distance introduced delay - “splitting the work across
sites slows down the work primarily because it requires the involvement of more people than
comparable work accomplished at the one site”. The particular tasks tended to be interdependent
and no attempts were made to rearrange the work, spontaneously or otherwise, to reduce the
interdependence. The subjects of Herbsleb and Mockus’s research were engaged in software
maintenance, which often requires specific expertise. There is no easy way to predict which
expertise will be required for each problem and there is not the luxury of rearranging the work
or the people to reduce interdependence, as would be the case in a development project. The
normal tendency is to divide the work according to the structure of the organization carrying it
out so that coordination between the different departments is reduced (Herbsleb and Grinter,
1999a; 1999b). From this, it appears that distributed tasks will take longer to perform depending
on how much they are interdependent.
A frequently cited study by Allen (1977) found that communication between people diminishes
sharply when separated by as little as 30 metres ( Figure 7). In a later study he also found that 3 For example, I had the experience of noting the different meaning of the phrase “it’s finished” used by three different cultures. In Australia, the phrase meant that whatever was required to be completed is now complete. In Germany, the term was not used until the deliverable had been tested for long enough to assure that there were no significant oversights or defects remaining in the product. In America, the phrase seemed to be used to mean that although “it” is not technically complete, it is very close and there is every confidence that it will be complete before it causes any schedule hold-ups.
Organizational Distance
Page 77
communication aids such as email had some, but very little, effect on the overall communication
frequency between separated parties (Allen, 2000). From these studies, it appears that separated
groups or individuals are reluctant to communicate with people with whom they have infrequent
social interaction. They prefer to seek information from people they know rather than an expert
whom they don’t know. It is not the distance or the communication difficulties themselves but
the reduced motivation to communicate with distant people. This would imply that if the
motivation was not a problem then the communication would be as frequent as if they were
close.
Figure 7: Relationship between distance and communication frequency.
In contrast, research on and experiments involving virtual teams (Jarvenpaa and Leidner, 1998;
Potter and Balthazard, 2002; Thomsett, 2002b) and projects distributed across cultures
(Cramton, 1997; Vogel et al., 2001) indicate that there are many obstacles to communication
with physical separation being only one. Cramton (1997) classified problems into four
categories: structural characteristics, quality of information exchange, degree of team
integration and outcomes. While many of the problems identified by Cramton may well have
occurred had the teams been co-located but equally unfamiliar with each other, some problems
were identified that were due to structural characteristics such as differences in time zones. Of
the other problems, some were due to language or cultural differences while others were due to
impediments to social processes.
The social processes of software development are frequently raised as essential to successful
development (Curtis et al., 1988; Gruhn, 1992; Grudin, 1994; Jones, 1996; Sawyer et al., 1997;
Prob
abili
ty o
f com
mun
icat
ion
at le
ast o
nce
a w
eek
0
0.1
0.
2
0
.3
25 50 75 100Separation distance (metres)
Organizational Distance
Page 78
Gasson, 1998). For the most part, the social interaction appears to be essential when tasks are
tightly coupled such as a design document review that involves several people (Gruhn, 1992).
Automatic activities (those that can be carried out without human interaction, such as compiling
and executing automated tests) or individual interaction activities (such as editing a source file)
do not require so much social interaction and are less affected by separation between team
members.
Research into workflow systems and CSCW systems largely concentrates on the complexities of
the process itself and ignores social interaction aspects of software development. Distance is
necessarily assumed and it does not matter whether participants in the workflow system are co-
located or widely separated, the system is structured so that all interaction is via the system and
not directly between participants. An exception to this is the work by Hawryszkiewycz and
Gorton (1996) who explicitly recognised the need to support social interaction during
distributed software development.
Between groups, however, social interaction may be more valuable to orient everyone toward
the same goals (Lientz and Rea, 2003 p71) than to support information sharing. Information
may still need to be shared and more informal communication channels may be better than less,
but that is outside the scope of this research.
3.2.3 Administrative distance Administrative distance indicates the organizational separation between the project manager and
the project team. A project team in a different organizational division from the project manager
does not necessarily have the same goals and priorities as does the project manager. Even
though they may both belong to the same organization, there are some elements of the agency
problem that are relevant.
Napier and Ferris (1993) used the concept of functional distance to describe the degree of
closeness and the working relationship between a supervisor and their subordinate. Since this
thesis concerns relations between a project manager and team members who are not necessarily
their subordinates, there is a need to include a concept of the administrative separation, rather
than functional separation, between them. When all of the project team members belong to the
one organizational division, administrative distance is minimal. The project manager has direct
control over the team. But when a project team member belongs to a separate organization, the
project manager has no direct control over them. In a matrix organization, a project manager
does have some authority over the team members but has no functional control. When team
members belong to separate divisions or separate organizations, possibly in different countries,
the project manager’s authority over the team may be further challenged (Selin, 1991).
Organizational Distance
Page 79
Organization research looked at the relationship between organization structure and the type of
work being performed and found that the structure was, not unsurprisingly, related to the type of
production system. Woodward (1958) found relationships between the management structure
and technical complexity of the production system. More complex production systems tend to
employ flatter organization structures. Perrow (1986) attributes this to the need of technically
complex production systems to have decision-making closer to production. Mintzberg (1979)
reasons that the span of control is not so much related to decision-making as to coordination.
When tasks are complex and interdependent, coordination is by mutual adjustment which
cannot be achieved if communications between those involved must travel through an extended
bureaucratic structure (Mintzberg, 1979). Even within the same organization, there may be
differing amounts of organizational separation between a project manager and the project team.
Organizational separation when more than one organization is involved is not a simple matter of
extending organizational separation. Agency Theory (Eisenhardt, 1989a) and Control Theory
(Ouchi and Maguire, 1975; Eisenhardt, 1985) both deal with control by one party over another.
Separation between the two parties is an essential pre-condition, particularly in Agency Theory.
There the two parties are assumed to be separate entities, having different goals and different
attitudes toward risk (Eisenhardt, 1989a). The two parties, principal and agent, do not
necessarily belong to different organizations. However, the contingency factors that bear on the
choice of control mechanism include the visibility the principal has into how the work is being
carried out by the agent (visibility of the transformation process). When the principal and the
agent belong to separate organizations, the principal has less ability to examine the internal
affairs of the agent. But organizational separation is not the only way in which visibility may be
reduced. A principal would have less visibility when they do not understand what it is they are
seeing. In this case, the transformation processes may be perfectly transparent to someone
familiar with them but opaque to the principal who is unfamiliar to them. So although Agency
Theory includes ways of acknowledging and dealing with separation between the principal and
the agent, it is not directly considered.
More familiar is the matrix organization. Mintzberg (1979) proposed that this is a liaison device
to combine a product or project orientation with a functionally structured organization. The
matrix organization sets up a dual authority structure where one person may report to a
functional superior but also report to the project manager of whatever project it is they are
working on at the time. Within a matrix structure, a project manager does not have direct and
unambiguous authority over the team members. However, the administrative distance between
the project manager and the team is reduced since the project manager does have some control,
even if ambiguous, over the project team.
Organizational Distance
Page 80
Mintzberg does not consider inter-organizational ties or any form of matrix structure that may
have spanned more than one company. He does describe international organizations that have
the effect of dealing with multiple organizations (Mintzberg, 1979 p172--173). However, the
described structures and examples of such structures do not specifically deal with a dispersed
team. Instead, it appears that the matrix organization or general organization administration is
assumed to be able to cope with a dispersed project team.
Whereas the matrix organization arose to improve product focus and organizational
responsiveness within a functional organization, a project based organization is a more recent
though logical development extending the matrix organization (Hobday, 1998). According to
Hobday, what distinguishes the project-based organization from the matrix, functional and other
forms of organization is that the project is the primary unit for production. Mintzberg described
a similar type of organization, one whose environment was both dynamic and complex, as the
“adhocracy” (Mintzberg, 1979 p449). Nothing in Hobday’s analysis suggests that the
organization is dispersed or that the proposed organization could not deal with a fragmented
organization.
This apparent lack of information on dispersed organizations can be overcome by considering
endeavours that necessarily deal with multiple organizations. For example, the field of supply
chain management necessarily deals with products and services supplied by separate
organizations. Supply chain management is normally situated in the area of manufacturing
(Womack et al., 1990; Cousineau et al., 2004; Themistocleous et al., 2004; Yusuf et al., 2004)
where the focus is on the repeated supply of a diverse range of components required by the
manufacturing process. But supply chain management can also deal with integrating a diverse
collection of organizations that must cooperate in a unique endeavour (Kornelius and Wamelink,
1998; Zeng, 2003). In particular, Kornelius and Wamelink describe a virtual corporation that
could apply to almost any industry that develops substantially unique products. They describe
ten bottlenecks for logistics in construction, the first two of which are the need for extensive
preparation of approval procedures and conflicts of interest within the project organization. The
remaining eight bottlenecks are more physical logistics, such as balancing delivery rates, rather
than organizational matters. Although they propose a collection of coordination types to
overcome these bottlenecks, there is no suggestion that the coordination types would depend on
any measure of separateness between the two organizations. Instead, there is a suggestion that
organizations must employ a closer relationship to cooperate closely - a partnership rather than
an adversarial contract. This idea that the legal separation of two organizations may be
overcome by a closer functioning relationship was also reported by Ward et al. (1995) in their
examination of Toyota’s methods of car design.
Organizational Distance
Page 81
The various threads of organizational theory, from Agency Theory (Eisenhardt, 1989a) through
to supply chain management, have not considered that there may be varying degrees of
separation between differing parts of the organization or between a project manager and the
project team members. Instead, either it is assumed that everything takes place within an
organization and a separation across divisions is insignificant, or that separation is inevitable but
can be overcome through relationships.
Viewing administrative distance with its intended meaning of the length of the administrative or
bureaucratic path between the project manager and the project team member, a longer distance
would tend to formalize communication.
3.2.4 Summary The model proposed here of organizational distance with constructs of cultural distance,
structural distance and administrative distance is simpler than that of Napier and Ferris (1993).
Each construct in the model describes a type of distance between the project manager and a part
of the project team that can be readily and objectively observed. In specific cases, the distance
could be reduced by some appropriate action. Cultural distance can be reduced, or at least
managed, through common systems, training and “cultural bridging” of staff (Krishna et al.,
2004) among other things. Structural distance could be reduced by co-location (Sabherwal,
2003).
This model retains the essential structure of Napier and Ferris’s (1993) model but extends the
scope to deal with inter-organizational distance rather than being confined to supervisor-
subordinate relationships. This model, in combination with the previously developed
contingencies of project management (Section 2.6), will be used to investigate the effects of
organizational distance on the choice of project management mechanisms.
3.3 The effect of organizational distance This section will examine how changes in organizational distance can be expected to affect
project contingencies and, in turn, how those expected changes in project contingencies are
expected to influence the choice of project mechanisms used to monitor, control and coordinate
a software development project.
To begin, a model of the relationships between organizational distance (Table 19, Section 3.1),
project contingencies (Section 2.6.2) and project management mechanisms (Table 9, Section
2.3.4) is shown in Figure 8. Using the device of project management contingencies allows
greater flexibility than a model that only considers the direct effect of organizational distance on
Organizational Distance
Page 82
the choice of project management mechanisms. It allows investigation into the relationship
between contingencies and the choice of project management mechanism, and investigation into
the relationship between organizational distance and project management contingency. Such an
interface is a common design feature in software development to protect a component from
changes in its external environment and results in a flexible, modifiable system. In the same
way, the interface of project management contingencies between organization distance and the
choice of project management mechanism allows organizational distance to be replaced by a
different environmental factor, such as software development technology, whose relationship to
the project management contingencies can be investigated more easily than their relationship
with the choice of project management mechanism. The model potentially allows predictions to
be made about the effect of any number of environmental factors on the choice of project
management mechanisms through considering their effect on project management contingencies.
For these reasons, this model of the relationships between organizational distance, project
management contingencies and the choice of project management mechanisms is considered to
be a significant contribution of this thesis.
Organizational Distance construct
Project management contingencies
Project management mechanisms
Task programmability
Cultural distance
Affect Task visibility Influence the choice of
Monitoring • Automatic • Formal • Ad hoc • Informal monitoring
Output Measurability
Structural distance
Risk
Control • Output • Behaviour • Input • Clan control
Relational Quality
Administrative distance
Costs
Coordination • Standards based • Plan Based • Formal Mutual Adjustment • Informal Mutual Adjustment
Figure 8: Relationships between organizational distance factors, project management contingencies and project management mechanisms.
The effect of increased organizational distance on each of the project management
contingencies will be examined in turn to gain some insight into how this is likely to influence
the choice of project monitoring, control and coordination mechanism.
Organizational Distance
Page 83
3.3.1 Cultural distance.
3.3.1.1 Task programmability Task programmability is an attribute of the task, independent of the environment in which the
task is performed. In describing task programmability, Ouchi (1979) and Eisenhardt (1985;
1989a) did not consider whether the task description was as comprehensible to the agent as it
was to the principal. In the context of single organizations, comprehension was assumed.
Although it has been claimed that software developers throughout the world largely share a
common view of software development tasks (Carmel, 1999 p73), cultural differences do appear
to influence views of how the tasks should be carried out, hence programmability. Borchers
(2003) described the effect of three of Hofstede’s (1991) cultural dimensions in projects
involving American, Indian and Japanese software developers. He reports that some differences
affected social aspects of project management but at other times the culture affected technical
aspects. This echoes Herbsleb’s view that architecture is influenced by organization structure or,
in this case, culture (Herbsleb and Grinter, 1999a).
3.3.1.2 Task visibility There is little research available that investigates relationships between cultural distance and
task visibility. Experience reports (Dube and Robey, 1999; Nicholson and Sahay, 2001;
Borchers, 2003) imply that visibility into a task is not improved but, since the issue is not
addressed directly, it is difficult to conclude that reduced visibility is due to cultural distance
and not geographical distance.
Two studies that involved teams distributed across at least two continents highlighted a number
of problems that arose but none of the problems concerned visibility into one party’s task by
another party (Cramton, 1997; Vogel et al., 2001).
Lientz and Rea (2003) acknowledge the difficulties of communication on international projects
and, although they recommend that the project manager travel to the remote location to meet
informally, their recommendation is based on avoiding misunderstanding and misleading
reportage rather than lack of visibility into the remote tasks.
Thus, task visibility does not appear to be significantly affected by cultural distance.
3.3.1.3 Output measurability Hamilton and Kashlak (1999) propose that increased cultural distance between the parties will
favour input control. They reason that the degree of cultural distance will influence a
multinational company’s parent-subsidiary performance ambiguity and task definition. As a
result, it is reasoned, task programmability and output measurability will decline. Roth and
O’Donnell (1996) point out that, with increased cultural distance, complete and accurate
Organizational Distance
Page 84
information becomes more difficult and expensive to attain, making it harder to verify
conformance to expected behaviour or to verify that expected outputs have been achieved. Thus,
despite the number of available methodologies that detail exactly how to develop software and
the commercial QA audit industry devoted to ensuring that an organization follows the
development process, there are those who argue that software development is essentially
ungovernable.
Although large cultural differences should favour input controls, software development is one of
the few industries where the product is readily transportable and readily measurable making the
task of verifying outputs comparatively easy. This is especially so when that output is a
relatively small and transportable artefact like a specification, design or executable program.
When the output is less transportable, an installed large system for example, remote verification
is more difficult but not impossible. The principal can ask the agent to verify that the required
outputs have been achieved or they could do the verification themselves.
Where cultural difference may matter is in understanding which outputs to measure and
specifying how to measure them. For example, Borchers (2003) relates how the Japanese do not
classify defects by severity nor do they sequence them in the order in which they are to be
resolved. The Japanese view is that all defects must be resolved so the sequence in which this is
done does not matter. Classifying defects and ordering them by severity is useful when there is
an understanding that the most significant must be fixed before the product ships. Cosmetic
defects or defects with marginal impact on the customer are not the kind of things to hold up an
income stream from delivered product. But the Japanese in Borchers’ experience believed that
the product should be defect free before shipment so did not understand the need to classify
defects.
3.3.1.4 Risk Hamilton and Kashlak (1999) specifically included cultural distance as a contributor to project
uncertainty and then propose that smaller cultural distance between the two parties will favour
behaviour controls while larger cultural distance will favour input control. This matches the
general thrust of Eisenhardt’s proposals arising from considering outcome uncertainty within
agency theory (Eisenhardt, 1989a).
While neither Lientz and Rea (2003) nor Carmel (1999) identify cultural distance as a separate
risk, they both reference several circumstance that have the general effect of increasing
uncertainty. Most of the increased uncertainty seems to arise through different ways of working
(Carmel, 1999 p76) or general communication difficulties.
Organizational Distance
Page 85
In the absence of compelling evidence, it will be assumed that cultural differences may increase
project uncertainty to some degree but the increase will likely be small compared to other
project risks.
3.3.1.5 Relational quality When developing a model of relational quality, Arino et al. (2001) consider demographic
attributes as part of a relationship’s initial conditions. The initial conditions determine the level
of relational quality that is later modified by experience. The context of their paper is
international corporate alliances rather than software development projects, so that initial levels
of relational quality may be set by corporate risk averseness and start out low.
Logically cultural diversity should make it impossible that everyone believe in the same values
and share the same goals. Indeed, both Carmel (1999 p144) and Lientz and Rea (2003)
recommend some effort be made to create a team. This is an attempt to overcome differences at
the national or organizational culture level with a team culture. Carmel reports that high context
cultures, such as Asian cultures, are slower to develop trust than low context cultures, such as
Australia. This would normally make team forming a difficult, slow affair except that in practice
teams form comparatively quickly. This has given rise to the theory of swift trust in which team
members assigned a common task of finite duration assume that the other team members are
reliable and competent, just like themselves (Jarvenpaa and Leidner, 1998; Gallivan and
Depledge, 2003).
In an interesting experiment testing swift trust theory on global virtual teams, Jarvenpaa and
Leidner (1998) found that culturally diverse teams could establish trust quite quickly even
though restricted to asynchronous electronic communications. Trust was not established in all
teams. Some started with low trust and stayed low, some started low and became high, some
started high and became low and some started high and remained high. Although this was not a
test of clan control, it relied on clan control to get the task completed. There was a prescribed
but vague outcome of proposing and developing a web site of interest to IS practitioners.
Behaviours were neither prescribed nor monitored although some teams did develop some rules
of conduct. What remains is clan control - belief in common goals and values.
Overall, cultural distance appears to have little effect on relational quality in dispersed software
development teams.
3.3.1.6 Costs If, as Constantine (cited in Carmel, 1999 p73) argues, the computer subculture is stronger than
national culture then both the fixed and variable costs of software development team
performance would not be as high as expected. The mechanisms of mutual adjustment, for
Organizational Distance
Page 86
example, should be little affected by cultural differences. But that is not the view of Chevrier
(2003) who found that teams needed to make cultural adjustments when working together for
the first time. It is quite possible that people who have experienced working with different
cultures have less need for adjustment than people who have not.
Informal mutual adjustment, which incurs higher variable costs, is used for matters that require
precise communication and clear understanding between the different parties. Kraut and Streeter
note that informal, interpersonal communication tended to be used all the time but was favoured
when the project was certain and in the planning stages (Kraut and Streeter, 1995). Difficulties
experienced by cross cultural teams reported by Cramton (1997) were partly attributable to the
geographical separation and partly attributable to cultural misunderstandings. Although some of
the problems may have been resolved faster if the teams had been co-located, many of the
problems only arose because of cultural differences and many took longer to resolve due to
different expectations on how they should be resolved. Thus cultural distance is expected to
increase variable costs.
However, an empirical study by Gomez-Mejia and Palich (1997) did not find significant
difference in market measures of performance for a number of Fortune 500 organizations over
the ten year period 1985 - 1994. In their discussion, Gomez-Mejia and Palich note that a
laboratory study by Watson et al. (1993) found that, initially, culturally diverse teams performed
better but that this effect was short-lived. Both culturally diverse teams and homogenous teams
performed at about the same level after 9 weeks on solving complex business problems.
Thus it can be deduced that cultural distance may have significant effect on team performance,
and therefore project cost, for a short duration project or a short duration relationship but is not
significant in the longer term.
3.3.2 Structural distance
3.3.2.1 Task programmability Various strategies for task distribution are reported to affect the way in which tasks must be
programmed (Grinter et al., 1999). Although this is applying the term “task programmability” to
the wider context of the task environment rather than the narrow context of the task itself, from
the point of view of a project manager, the programmability of the task has been affected. This
may affect coordination more than monitoring or control.
While it may be reasonable to expect that structural distance may affect the ability of an
organization or project manager to enforce conformance to particular work practices, citable
evidence of this is difficult to find. Lientz and Rea (2003) point out that people at a remote site
Organizational Distance
Page 87
have their own concerns and agendas, making them less likely to perform tasks precisely as
directed. Carmel (1999) notes some of the problems of working with global software
development but does not identify a problem that could be classified under the heading of “task
programmability”.
3.3.2.2 Task visibility The effect of structural distance on task visibility is well illustrated in an anecdote by Herbsleb
and Grinter (1999a) in which a reported defect was only solved when a developer visited the site
from which the defect was reported. Essentially, the defect occurred because the developer had
imperfect visibility of the tester’s actions. Structural distance makes it that much more difficult
for a project manager to directly observe task performance.
Structural distance normally affects the principal’s, or project manager’s, visibility into the
transformation processes. They are less able to pick up on chance remarks and less able to walk
about monitoring the team’s efforts and progress. In agency theory terms, the information
system must compensate for the distance by substituting some other means of gathering
information. Lacking a different information system that provides sufficient information to
enforce behaviour control, a principal will favour outcome control (Eisenhardt, 1989a).
Microsoft moved some development projects from Japan to their headquarters because the
Japanese tended to try to hide what was going on from the people at headquarters (Cusumano
and Selby, 1995 p286). Microsoft clearly found this lack of visibility a problem and located
major product development projects at a single site where “project personnel get together
physically on a regular basis and explore ideas interactively.” As with Herbsleb and Grinter
(1999a), the lack of visibility into each others’ work allows small problems to develop into large
problems. While it is possible to argue that the example of Microsoft’s problem with
development in Japan could be attributable to culture rather than structural distance, the same
reported anecdote notes that the multi-site development of OS/2 encountered the same problems.
Within the examples of coordination processes typically used to resolve Malone and Crowston’s
different dependency types (Malone and Crowston, 1994), all are potentially affected by task
visibility. Of them, the most obvious would be concurrent engineering which seems to depend
on increasing participation and visibility of selected tasks (Shina, 1991; Liker et al., 1996).
While some of the dependencies can be resolved using such methods as schedules and common
interfaces, those mutual dependencies that require a high level of communication would seem
vulnerable to reduced task visibility.
Organizational Distance
Page 88
3.3.2.3 Output measurability Authors on the subject of software measurement generally concern themselves with the
measurements themselves rather than the methods of measurement (Fenton, 1994; Kitchenham
et al., 1995; Kitchenham, 1996; Fenton, 2000; McGarry et al., 2002). Even when writing on
quantitative project management, the subject of measurement logistics is not dealt with
adequately (Kitchenham and Walker, 1989; Shumate and Snyder, 1994; Atkinson et al., 1998;
Loch and Tapper, 2002). This could reflect the comparative recency of distributed and
outsourced software development. Whatever the reason, specific difficulties in measuring the
outputs of software development are not yet known and it is left to infer such difficulties, and
their possible solutions, from more general information on distributed projects.
Although software products themselves may be readily measurable, performing the
measurements, that is testing the product, may not be so easily performed at a distance. In
general, software systems would be more difficult to measure when they are installed at a
remote site for three reasons. The first is that it is more difficult and more expensive to deploy
the entire test team to the remote site. The second reason is that the installation site may lack the
means to create specific circumstances required by the testing. They may lack specific
configurations or specific equipment. The third reason is that customers may be reluctant to
spend the time testing the product when, in their view, it should already have been tested. Once
the product is installed any delay in putting it into production represents lost revenue.
However, if the task output is readily transmitted around the world, as most software
development artefacts are, then increased structural distance is unlikely to affect its
measurability.
3.3.2.4 Risk Distance creates delays (Herbsleb et al., 2001) and they, in turn, increase uncertainty. The
distant team are subject to differing agendas, being less directly responsive to the project
manager (Lientz and Rea, 2003) creating uncertainty over task outcomes.
Wallace et al. (2004) found that risk increased for both team risk and for control and planning
risk in outsourced projects. The remaining four dimensions of risk from their
model - organizational environment, requirements, user and complexity risk - did not display
statistically significant differences between outsourced and non-outsourced projects. This
suggests that structural distance arising from outsourced projects contributes to the project
uncertainty associated with the project team and from the ability to develop or keep to a
schedule.
Organizational Distance
Page 89
Other authors on outsourced or distributed software development don’t treat risk as a separate
factor but simply acknowledge that outsourced projects will entail risks, suggesting that risk
management is important (Carmel, 1999 p182; Lientz and Rea, 2003 p17).
Motorola’s experience with global software development exposed many issues related to project
risk (Battin et al., 2001). However, this was not a quantitative study and no single issue was
identified as having contributed more toward project risk or outcome uncertainty than any other.
Risk increased, and it was managed.
3.3.2.5 Relational quality The very nature of relational quality transcends distance to a large degree. Organizations
develop relational trust through working with each other over time (Kadefors, 2004) and while
it may be initially more difficult to form a relationship at a distance, the end result should be the
same. Arino et al. (2001) document examples where relationships over a distance have failed
but the reasons given for their failure were attributed to culture rather than distance.
We can therefore conclude that structural distance is expected to have little effect on relational
quality.
3.3.2.6 Cost A study into multi-site development (Herbsleb et al., 2001) found that distributed work teams
took about two and a half times longer to complete similar work items than did co-located teams.
The study concluded that delays were related to the size of the network of people who worked
on the item. Part of the reason for the larger networks and delay was that each site tended to
duplicate the collection of expertise needed to solve the problem instead of collaborating across
the separation. People tend to seek advice and assistance from those close to them, thus creating
a network of expertise at each site. This seems to be a natural outcome from Allen’s finding that
communication drops off precipitously after a distance of only 30 metres separation (Figure 7)
(Allen, 1977; Allen, 2000).
Many software development researchers have identified that informal communication among
the team seems to be an essential part of software development (Kraut and Streeter, 1995;
Herbsleb et al., 2000). If informal communication is hindered, then it is expected that
performance will suffer by increasing the cost of development or reducing final product quality
due to the time it will require to resolve problems.
In their studies into distributed software development, Herbsleb et al (1999a; 1999b; 2000)
found that the primary effect of distance was to stretch out issue resolution. They found that
distributed work items took about two and one half times as long to complete as similar items
where the work is co-located and that the distributed work involved more people. The duration
Organizational Distance
Page 90
of the tasks was directly related to the number of people involved in the work which, in turn was
higher because people needed advice and sought the most readily available expertise. Other
problems encountered included unrecognized conflicts among the assumptions made by
different sites and incorrect interpretations of communications. Cramton (1997) reported similar
findings, that structural distance may not create the problems but does hinder their resolution.
Unrecognized conflicts and misinterpreted communications can occur in any field but are
particularly consequential in software development where precision is required.
Travel and conference calls were common methods used to overcome geographical separation at
Motorola (Battin et al., 2001). Ignoring the cost of conference calls, travel of 1.4 million miles
by the development team on a project that delivered 511,000 lines of code is much more than
would be expected for a co-located team. Travel was one of Motorola’s responses to the
problem of maintaining communications between team members, one that might not be the
preferred solution for a different organization.
3.3.3 Administrative distance
3.3.3.1 Task programmability Increasing administrative distance would reduce the ability of the principal to enforce specific
behaviours on the agent. This would then favour output control or input control depending on
whether or not outputs could be measured (Eisenhardt, 1989a). In software development terms,
if the project manager had reduced ability to determine how the remote team performed their
tasks, the project manager is more likely to use contractual terms and conditions or extensive
selection procedures such as tendering.
In an example of decentralised project management, Barber et al. (1999) noted several problems
that arose during the introduction of team based workgroups that collectively were constructing
a highway. Although the overall project management could, in theory, determine how people
were to perform their tasks, difficulties were encountered when the teams’ performance bonus
criteria did not match the project management’s objectives. A change in the bonus structure
solved that particular problem. However, the change to autonomous teams threw up several
such challenges to the project manager’s ability to determine how tasks would be performed.
The recent interest in organizational alliances formed for specific projects has provided some
indication of the effects of administrative distance on task programmability. Selin (1991) points
out that the profit motive of differing divisions does not always coincide with the interests of the
project. This is echoed by Lientz and Rea (2003) who point out that local (as opposed to head
office) teams have their own agendas that are unlikely to coincide with those of the project.
Organizational Distance
Page 91
Overall, it may be concluded that increased administrative distance seems to reduce task
programmability.
3.3.3.2 Task visibility When project teams are comprised of personnel from different organizations or different
divisions of the same organization, the project manager might not have direct access to or direct
control over the project personnel. Instead of dealing directly with the project team members
project managers may be constrained to deal indirectly through their manager or other
organizational representative.
3.3.3.3 Output measurability
As was argued in a previous section ( 2.6.2.3) when the outputs are visible to the project
manager output measurability is unlikely to be affected. However, if the output is not directly
visible to the project manager but must be communicated through the administrative chain, then
the effective measurability will be affected. For example, if a project manager is tracking a
project through milestones such as progress through a design, then the measure of progress
visible to the project manager is whatever they are told by the remote team. However, that
example is somewhat contrived and the point about output measurability is that measurement is
performed at whatever point the output becomes visible. On the whole, this implies that output
measurability should remain largely unaffected by administrative distance.
3.3.3.4 Risk To date, no author has identified a relationship between project risk and administrative distance.
Some inferences can be made from structural contingency theory, particularly related to high
tech projects or software development projects. Andres and Zmud (2002) argue that as goal
conflict increases, as is likely when there are administrative barriers between the project
manager and the project team, then a mechanistic coordination strategy will be more successful
than an organic coordination strategy. In other words, an inappropriate coordination strategy
will increase the risk of negative outcomes. Other authors (Nidumolu, 1996; Donaldson, 2001;
Shenhar, 2001) espouse similar themes.
Thus increased administrative distance will not necessarily increase project risk of negative
outcomes, unless there is a mutual dependency involving the project team behind the
administrative levels.
3.3.3.5 Relational quality Relational quality is generally taken to exist between organizations rather than between
individual people. However, neither Arino et al. (1998), Das and Teng (1998; 2001) nor
Organizational Distance
Page 92
Gallivan and Depledge (2003) preclude relational quality between individuals. On the other
hand, Kadefors (2004) points out that informal cooperative relationships between individuals
can exist alongside relationships between the organizations to whom the individuals belong.
Relational quality between two organizations could rest on relations between the project
manager and the other organization’s project team or between the project manager and the
administrative contact point that interfaces between the project manager and the project team.
Relational quality is not necessarily diminished simply because there is an intermediary between
the project manager and a project team. Indeed, it is conceivable that relational quality could be
improved if relations between a project manager and a project team declined, and an
intermediary was appointed to deal with the project manager and allow the project team to work
uninterrupted.
3.3.3.6 Cost An increase in administrative distance is likely to increase cost. Herbsleb and Mockus (2003)
established that distributed projects took longer due mainly to the number of people involved
and the necessity to communicate among all those involved.
When communications between two parties must pass through intermediate steps, the
probability of error increases. Although Herbsleb and Grinter (1999a) were examining structural
distance rather than administrative distance, they noted that issue resolution took longer. At
least part of the longer resolution time would have been due to miscommunications. However, if
the project team is largely independent of the rest of the project and doesn’t need to closely
coordinate their work, then the need for communication is reduced. Hence costs are unlikely to
rise.
Overall, it seems that increased administrative distance may increase cost in some
circumstances.
3.4 Conclusion There are very few available models of organizational distance, and none that deal with
distributed and outsourced software development. A model of organizational distance has been
developed consisting of the three dimensions of cultural distance, structural distance and
administrative distance (Section 3.1). This model has been used to discuss the expected effect of
increases in each of its dimensions on the contingencies of project management mechanisms. A
graphic summary of these expectations is shown in Table 20.
Organizational Distance
Page 93
Table 20: The expected changes in project management contingency as organizational distance increases.
Project management contingency Organizational distance factor Ta
sk
prog
ram
mab
ility
Task
vis
ibili
ty
Out
put
mea
sura
bilit
y
Proj
ect r
isk
Rel
atio
nal
qual
ity
Cos
t
Cultural distance
─ ↓ ↓ ↑ ─ ↑
Structural distance
↓ ↓ ↑ ─ ↑
Administrative distance
↓ ─ ─ ↑ ─ ─
Notes: “↑” indicates that the contingency is expected to increase as organizational distance factor increases. “↓” indicates that the contingency is expected to decrease as the organizational distance factor increases. “─” indicates that the contingency is not expected to be affected as the organizational distance factor increases. As is evident in the theoretical conclusions shown in Table 20, task programmability, task
visibility and output measurability are expected to decrease, relational quality is expected to be
unaffected and both project risk and project costs are expected to increase.
We are now in a position to consider the expected effect of increased organizational distance on
the selection and use of project management mechanisms. The simplest way to achieve this is to
reproduce the table from the previous chapter (Table 9), showing the expected effect of
increased contingencies on project management mechanisms but to consider the expected
direction of change in the contingency, then to summarise whether the mechanisms is likely to
be favoured or not by each contingency into an overall single “favour” or “discourage”.
Empirical observations will only be able to tell if the use of a specific project management
mechanisms was favoured or discouraged when organizational distance increased and will not
be able to assign parts of any change to specific contingencies.
In this thesis, we have so far shown the broad expectations, shown in Table 21, about which
project management mechanism should be favoured by an increase in organizational distance
and which should be discouraged. The table shows a tendency to favour the interactive and
informal mechanisms over the formal and non-interactive mechanisms.
Having established a model of organizational distance and its interaction with project
management mechanisms via contingencies, we can now consider what research method should
be used to investigate the expected effects.
Organizational Distance
Page 94
Table 21: Expected relationship between organizational distance and the use of project management mechanisms.
Expected change in project management contingency
D
ecre
ased
task
pr
ogra
mm
abili
ty
Dec
reas
ed ta
sk
visi
bilit
y
Dec
reas
ed o
utpu
t m
easu
rabi
lity
Incr
ease
d ris
k
Unc
hang
ed
rela
tiona
l qua
lity
Incr
ease
d co
st
Ove
rall
effe
ct o
n th
e pr
ojec
t m
anag
emen
t m
echa
nism
Automatic monitoring ↓ ↓ ↓ ↑ ↓ Formal monitoring ↓ ↓ ↓ ↑ ↓ Ad hoc monitoring ↑ ↑ ↑ ↓ ↑ Informal monitoring ↑ ↑ ↑ ↑ ↓ ↑ Output based control ↑ ↑ ↓ ↑ ↑ ↑ Behaviour based control ↓ ↓ ↑ ↓ ↓ Input based control ↑ ↑ ↓ Clan control ↑ ↑ ↑ ↑ ↓ ↑ Coordination by standards ↓ ↓ ↓ ↓ ↑ ↓ Coordination by Plans ↓ ↓ ↓ ↓ ↑ ↓ Coordination by formal mutual adjustment
↑ ↑ ↑ ↑ ↑ ↑
Coordination by informal mutual adjustment
↑ ↑ ↑ ↑ ↑ ↑
Page 95
4 Research Design Chapter two established a classification scheme for mechanisms to monitor, control and
coordinate a project along with a set of contingencies that influence their selection in different
circumstances. Chapter 3 developed and presented a model of organizational distance (Table 19)
that can be used to examine the relationship between the selection of project management
mechanisms and organizational distance (Figure 8 and Table 21).
This chapter proceeds by examining the strength of the theoretical model arising from the
previous two chapters and the potential areas of research. From this examination of the model,
one of the areas of potential research is selected and two research questions are proposed.
To decide on an appropriate research methodolgy4, alternative knowledge claims are considered.
Existing empirical research is reviewed to establish whether there are preferred methodologies
and whether broad consensus has been reached about mechanisms for project monitoring,
control and coordination in software development. Then the proposed research methodology
and method are described and discussed. Research ethics governing this research and some of
the tools used to aid the research are described. External validity is briefly discussed, construct
and internal validity also being discussed. The differing ways in which the research instrument
was reviewed are presented. The manner in which the research was conducted allowed different
analyses to be performed and this is discussed, followed by a brief description of how the
interviews were conducted, transcribed and checked.
4.1 Research Questions The proposed model relating the effect of organizational distance on project management
contingencies, and from there the effect on the selection of project management mechanisms
contains many potential areas for research. First, although the set of project management
contingencies has been established from the literature, there has not been any empirical work
into the make up of the set. Second, the relationships between the set of contingencies and the 4 Evans and Gruba (2005) argue that a research methodology is the “branch of knowledge that deals with the method and its application in a particular field of study”. The “method”, on the other hand, is the collection of specific techniques used to collect data and to test the hypotheses or answer research questions.
Research Design
Page 96
project management mechanisms is also unexplored. And last, the overall relationship between
organizational distance and the selection of project management mechanisms, regardless of any
intermediate contingencies, has been examined in some circumstances for both project control
and project coordination but not for overall project management. These areas of potential
research are illustrated in Figure 9.
Figure 9: Areas of potential research arising from the theoretical model of organizational distance, project contingencies and project management mechanisms.
This research will examine questions arising from potential research area 3. That is, which
project management mechanisms do project managers favour and how does increasing
organizational distance affect the selection of mechanisms used to monitor, control and
coordinate a software development project.
4.1.1 Which mechanisms do project managers use? The previous two chapters have described the different project management mechanisms that
might be used in any one project but nothing has been established about which mechanisms
project managers actually use. It is unlikely that all mechanisms are equally preferred. The term
“portfolio” was used by Choudhury and Sabherwal (2003) and will be adopted for this research
to describe the collected project management mechanisms used on a project.
There have been investigations into control mechanisms used in information systems design
(Henderson and Lee, 1992), the evolution of a portfolio of control mechanisms over the life of a
software development project (Choudhury and Sabherwal, 2003), as well as the more theoretical
research into the influence of national cultures on the selection of control mechanisms
(Hamilton and Kashlak, 1999). Selection of project coordination mechanisms has been
investigated in relation to risk (Nidumolu, 1996) and the type of coordination mechanism
(Andres and Zmud, 2002). The evolution of coordination mechanisms (Sabherwal, 2003) has
also been investigated. Kraut and Streeter (1995) examined the more general aspects of how
Organizational Distance
The mechanisms of project monitoring, project control and project coordination
Contingencies affecting the selection of project management mechanisms
Potential research area 2
Potential research area 1
Potential research area 3
Research Design
Page 97
coordination was achieved in software development but any investigation into project
monitoring mechanisms is difficult to find.
To date, there has been no research into portfolios of mechanisms used to monitor, control and
coordinate a software development project. Thus the first subject for investigation is;
RQ1: Which mechanisms do project managers use to monitor, control and
coordinate software development projects?
It is useful to divide this research question into three so that monitoring, controlling and
coordination can be investigated separately.
RQ1.1: Which mechanisms do project managers use to monitor software
development projects?
RQ1.2: Which mechanisms do project managers use to control software
development projects?
RQ1.3: Which mechanisms do project managers use to coordinate software
development projects?
4.1.2 Alternative research areas There are several candidate dimensions along which it would be possible to investigate
changing portfolios of project management mechanisms. As was listed in the previous chapter
the dispersion of the development team, the diversity of the technologies being used to develop
the product or that must be integrated into the product and the diversity of tasks that the
intended product must accomplish are all dimensions along which project management itself
might be stressed and which might favour or discourage the selection and use of different
project management mechanisms.
To consider the influence of organization size, or project size, on the selection of project
management mechanisms risks confusing selection due to the needs of software development
with selection due to size. Large projects may be more likely to favour mechanisms that
increase control of the project where small projects can afford to be less formal. This may not
reveal much about the demands of software development so much as the demands of size.
Similarly, considering relationships between project management mechanisms and industry type
or system type risks confusing the demands of the industry with those of software development.
Selecting any dimension along which to investigate project management mechanisms risks
confounding variables due to the dimension itself. However, the dimension of organizational
Research Design
Page 98
distance may reveal something novel about the subject, and findings or conclusions would be
useful for distributed and outsourced software development.
Examining which mechanisms project managers favour in order to monitor, control and
coordinate software development projects may add some empirical evidence to the theoretical
work that has established groupings of the different mechanisms. While the different groupings
have been used or adopted by a number of researchers, there is very little empirical evidence of
which mechanisms or groups of mechanisms are favoured or the reasons why they are favoured.
4.1.3 The influence of organizational distance Simply investigating the selection of a portfolio of project management mechanisms would not
reveal which of those mechanisms are necessary, which are redundant, which have greater or
lesser utility or, indeed, much about the reasons why they were selected. To examine how
particular portfolios of mechanisms are selected and the influences on their selection it is
necessary to examine project management under different circumstances. Varying the
organizational distance between the project manager and some part of the project team provides
such changing circumstances that may reveal reasons for and influences on the selection of
portfolios of project management mechanisms.
Stretching the organizational distance between the project manager and the project team should
stress the project management mechanisms and may reveal which mechanisms are more robust
or which have greater range. The stress may also reveal which mechanisms are commonly used
at one end of the organizational distance dimension but are discarded toward the other end. This
research chose to investigate the dispersion of the development team since outsourcing
arrangements are becoming both more common and more complex (Gallivan and Oh, 1999).
Thus, the second subject for investigation is;
RQ2: Is there a relationship between the organizational distance between the
project manager and elements of the project team and the selection of project
management mechanisms?
There are several potential dimensions of the software development environment along which
project management could be examined in order to deduce something about which project
management mechanisms are favoured under different circumstances. Of these, this research
has chosen the dimension of organizational distance because doing so may reveal something of
value to the project management of distributed and outsourced software development. For
example, if distributed projects chose more formal project management mechanisms than co-
located projects then this would indicate that organizations embarking on distributed projects
need to invest in training or tools that support more formal project management mechanisms.
Research Design
Page 99
First, existing empirical research is reviewed to establish whether there are preferred methods
and whether broad consensus has been reached about mechanisms for project monitoring,
control and coordination in software development. Then the proposed research method is
described and discussed. Research ethics governing this research and some of the tools used to
aid the research are described. External validity is briefly presented, construct and internal
validity are discussed. The differing ways in which the research instrument was reviewed are
presented. The manner in which the research was conducted allowed different analyses to be
performed and this is discussed.
4.2 Knowledge claim There are potentially three knowledge claim positions that could inform this research:
postpositivist, interpretivist and pragmatic (Williamson et al., 2002; Creswell, 2003). Positivists
see the world as a collection of observable events and facts that can be measured (Williamson et
al., 2002). Effects have causes which may or may not yet be observed and understood. The
positivist knowledge claim underlies much of the sciences where the world is expected to be
objectively observable. Scientists use deductive reasoning to postulate testable theories. If a
theory does not fit the observed facts, the theory must be revised to better predict reality
(Trochim, 2001). Hypotheses are never proven but simply supported. Where positivism
constrains a researcher to what can be observed and measured, postpositivism does not
distinguish between scientific reasoning and common sense. Postpositivists recognise a reality
that can be studied independently of a person’s thinking about it but believe that all observation
is fallible and all theory revisable (Trochim, 2001). Both positivist and postpositivist research is
concerned with experimental validity and reliability.
Interpretivist’s knowledge claim is that individuals seek understanding of the world in which
they live and so develop subjective understanding of their experiences (Williamson et al., 2002;
Creswell, 2003). Interpretivism is largely associated with qualitative research and the social
sciences. In contrast to the postpositivists, an interpretivist believes that reality is constructed in
the mind of the individual and that this may differ, sometimes significantly, from individual to
individual.
The pragmatic knowledge claims “arise out of actions, situations, and consequences rather than
antecedent conditions” (Creswell, 2003). Pragmatists will use multiple research approaches in
order to understand the problem.
If this research investigated how project managers understood project monitoring, control or
coordination and how this understanding related to the actions they took then an interpretivist
Research Design
Page 100
claim would be appropriate. Such research would concentrate on what information a project
manager sought to establish the state of the project and how they perceived that state. Since
such questions of whether or not a project is “under control” or is “well coordinated” have not
been objectively defined such that measures could be devised for either attribute, an
interpretivist research project could reveal insights into tools, techniques and information that
would better support a project manager. Seaman (1999) points out that “many in the industry
recognize that software development also presents a number of unique management and
organizational issues or ‘people problems’” that are well served by qualitative research methods
adopting an interpretivist stance.
Instead, this research investigates phenomena that, to some extent, have an objective existence
and a common perception among the project team. That is, the project management mechanisms
exist independently of the project manager’s understanding of them. Furthermore, the research
investigates how the selection and use of these phenomena, the project management
mechanisms, is affected by changes in the environment. That is, the research investigates cause
and effect relationships between the environment and the mechanisms used to monitor, control
and coordinate a software development project. Such relationships are commonly investigated
from a postpositivist stance. Even though there needs to be some consensus among the project
team about the differing project management mechanisms, the consensus need not be exact.
Different people may have a different understanding of the same mechanism or its purpose.
Thus, this research needs some information on how the phenomena are understood and some on
relationships between cause and effect. A pragmatic knowledge claim that allows for both
quantitative methods and qualitative methods would appear to be best and will be adopted.
4.2.1 Research methods in existing studies Empirical studies of control or coordination in software development tend to be case study,
survey, semi-structured interview based or controlled experiment (Table 22). The data sought
are largely categorical or ordinal rather than interval or ratio. This may reflect a lack of accepted
measures of organizational control or project coordination. There is not, for example, an
accepted measure of how well or poorly a project is coordinated although there has been an
attempt to develop a measure of coordination load in production processes (Albino et al., 2002).
Empirical studies to date have:
• identified a taxonomy of mechanisms and contingency factors for organizational or
project control (Eisenhardt, 1985; Henderson and Lee, 1992; Kirsch, 1996; Choudhury
and Sabherwal, 2003);
Research Design
Page 101
• identified a taxonomy and contingency factors for project coordination (Crowston, 1991;
Majalian et al., 1992; DeSanctis and Jackson, 1994; Adler, 1995; Kraut and Streeter,
1995; Nidumolu, 1996; Bailetti et al., 1998; Herbsleb and Grinter, 1999a; Herbsleb and
Grinter, 1999b; Faraj and Sproull, 2000; Andres and Zmud, 2002; Sabherwal, 2003).
Table 22: Empirical studies of control or coordination in software development
Study Subject Method Sample Adler (1995) Interdepartmental
Interdependence and Coordination
Semi structured interview
13 firms, 119 interviews
Andres and Zmud (2002)
A Contingency Approach to Software Project Coordination
Controlled experiment
80 subjects, 2 tasks each
Cramton (1997) Information Problems in Dispersed Teams
Controlled experiment
45 teams
Crowston (1991) Towards a Coordination Cookbook: Recipes for Multi-Agent Action
Case study 3
DeSanctis and Jackson (1994)
Coordination of information technology management
Case study 1 firm
Faraj and Sproull (2000)
Coordinating Expertise in Software Development Teams
Survey 333
Hawryszkiewycz and Gorton (1996)
Distributing the software process
Controlled experiment
3 trials
Henderson and Lee (1992)
Managing I/S Design Teams: A control Theories Perspective
Survey, Key informant
432 persons, 48 teams, 10 firms
Herbsleb and Mockus (2003)
An empirical study of speed and communication in globally distributed software development
Survey, MR data from config mgmt
92 respondents, 2227 MRs
Hoegl and Gemuenden (2001)
Teamwork Quality and the Success of Innovative Projects
Standardized interview
575 interviews
Kraut and Streeter (1995)
Coordination in software development
Survey 563
Levesque et al (2001)
Cognitive divergence and shared mental models in software development project teams
Controlled experiment
62 teams
Majalian et al (1992)
The effects of team size on team coordination,
Controlled experiment
12 subjects
Muller (2003) Determinants for external communications of IT project managers
Questionnaire 100 respondents
Nidumolu (1996) A comparison of the structural contingency and risk-based perspectives on coordination in software development projects
Survey 13 firms, 6 projects each 250 firms, 2 projects each
Sabherwal (2003) The evolution of coordination in outsourced software development projects
Case study / structured interviews
11 projects, 6 suppliers, 11 clients
Research Design
Page 102
Project monitoring appears not to have been the subject of empirical research except as part of
quantitative methods of project management (Kitchenham and Walker, 1989; Dumke and
Winkler, 1997).
There is also empirical work in the area of workflow systems or computer supported
cooperative work (CSCW) that necessarily implements some elements of control and
coordination although, in the main, they have tended to implement pre-existing work procedures
largely unchanged. While advanced work on workflow or CSCW systems are exploring control
and coordination aspects (Easterbrook, 1995; Hawryszkiewycz and Gorton, 1996; Godart et al.,
2000), most of the work appears to be confined to getting something to function correctly rather
than implementing sophisticated control or coordination systems within the tools.
The empirical research identified in Table 22 has established mechanisms and contingencies of
control and coordination in software development projects for a range of circumstances and
environments. However, consensus on the classification and definition of different mechanisms
has yet to be achieved. Mechanisms identified for project control (Henderson and Lee, 1992;
Choudhury and Sabherwal, 2003) are sometimes also identified as project coordination
mechanisms (Kraut and Streeter, 1995; Faraj and Sproull, 2000; Sabherwal, 2003). The existing
research has examined either project control or project coordination or project monitoring but
has not examined the mechanisms with which project managers achieve all three.
4.2.2 Research methodology Clearly the most obvious method of investigating what project managers do in specific
circumstances is to ask them. This could be done by almost any research methodology.
However, the questions being investigated by this research aim for some acceptable level of
external validity. The project management mechanisms identified in previous research are taken
as a starting point for this research to examine which of them are selected and how that selection
is affected by specific changes in the environment. The research is not aimed at confirming the
existence of previously identified mechanisms nor at identifying new mechanisms. If it were,
then an interpretivist stance and a qualitative research methodology such as grounded theory or
case study may have been appropriate (Eisenhardt, 1989b; Seaman, 1999; Scandura and
Williams, 2000; Williamson et al., 2002; Creswell, 2003). Instead, the research investigates
cause (the environment) and effect (selection of different project management mechanisms)
where quantitative methodologies are more appropriate and concerns of validity and reliability
must be addressed (Trochim, 2001; Williamson et al., 2002; Creswell, 2003). In particular, the
results should attain some measure of external validity before reaching any conclusions about
Research Design
Page 103
relations between the environment and the selection of project management mechanisms
independent of characteristics of the project manager, the organization or the project.
The objectives of the research, which were to investigate which mechanisms project managers
use to monitor, control and coordinate software development projects and how the choice of
those mechanisms was influenced by organizational distance, indicate that data should be
gathered from a number of sources to achieve statistical validity, but that some of the data
should be qualitative to allow latitude in interpreting what the participants intend in different
circumstances.
4.2.3 Data collection method Research in the area of project control and project coordination has used survey and structured
interview (Table 22). Some researchers have used mixed research methods (Henderson and Lee,
1992; Herbsleb and Mockus, 2003; Sabherwal, 2003) for differing reasons. Sabherwal (2003)
gathered his data by interview and used qualitative methods to attain rich insights but
quantitative methods of analysis to compare across cases. Such mixed methods research
supports pragmatic knowledge claims (Creswell, 2003).
In my experience, the project management concepts being investigated by this research, project
coordination in particular, are not commonly discussed by project managers. While many
project managers may be aware that the objective of some of their actions is to coordinate
project activity, it is unlikely that all project managers will share a common perception of the
extent of project coordination or whether a specific action is aimed at project control, project
coordination or something else. They may know what they do but not necessarily why they do it
or all of the effects of doing it. Without consensus on the central concepts, it would be difficult
to conduct a survey.
A structured interview offered the possibility of collecting both quantitative and qualitative data
while strongly directing data collection to specific issues. Questions and responses can be
clarified, new information provided and accepted. More of the subject’s general knowledge can
be elicited than is possible with other techniques, and interviews can expose issues that the
subject had not thought of previously (Seaman, 1999; Wood et al., 1999).
This ability to clarify a question or a response was attractive since questions that appear very
clear to the researcher are not always clear to the subject. Some questions, such as those
designed to characterise the organization, are more amenable to providing a list of possible
responses and could have been given in a survey. Generally, such topics have a known range of
responses and it is possible to develop a set of categorical or quantitative responses from which
the respondent is expected to choose. However, other information could only have been sought
Research Design
Page 104
through an open question where the interviewer must work hard to avoid imposing their view of
both the question and the expected responses (Yin, 2003 p61).
Face-to-face interviews enable a researcher to establish rapport with the subject and to gain their
cooperation (Leedy and Ormrod, 2001). They also enable the researcher to clarify and elaborate
a question. Since I had worked as a project manager in software development I was able to
comprehend many of their responses quickly and allow the interview to flow where it might
otherwise falter over misunderstandings. This also meant that we could discuss something of
mutual interest, which helped establish rapport, or pick up on some point that elicited interesting
information. Interviews enable the researcher to establish rapport with the participants as well as
the opportunity to clarify ambiguous answers and to seek follow-up information (Leedy and
Ormrod, 2001). The participant is presented with evidence that the researcher is willing to spend
time and effort, whereas surveys are far less personal and do not convey the same visible effort
and commitment.
Interviews can be time consuming compared to other ways of gathering data, especially if the
number of interviews becomes large. In this case, there was enough time available and enough
potential subjects. There were also no logistical or technical obstacles that would preclude
interviews.
The chosen data collection method was structured interview using questions designed to yield
both quantitative data and qualitative data.
4.3 Research instrument Assessment models used in CMMI (SEI, 2000) and SPICE (ISO 15504, 1998), both of which
measure software development capability, seek to measure objectively an attribute that would
normally be considered subjective. This is done by considering what objective evidence would
normally demonstrate different achievement levels of the subjective attribute. The number of
data points sought for each level of attribute contribute to measurement repeatability and
reproducibility. There have been empirical studies of both CMMI (Herbsleb et al., 1994;
Goldenson and Gibson, 2003) and of SPICE (Simon et al., 1997; Hunter and Jung, 2000; Jung
et al., 2001) that confirm their validity.
The questionnaire was based on assessment models and data collection methods used in SPICE
assessments5. The questionnaire was made up of 49 questions developed by identifying the
5 I have participated in the development of the ISO standard for process capability assessments ISO 15504 – Software Process Improvement and Capability dEtermination. I have also participated in the development of the OOSPICE process assessment model for object oriented software development. I am a trained SPICE assessor and have also participated in the SPICE trials by conducting several assessments of the software development processes
Research Design
Page 105
constructs needed for the research, then constructing questions to gather data for the constructs.
The questions were then allocated to a question category that related to the subject area so that
questions could be asked in logical groupings and the interview could deal with each subject
area without having to return to it. The interview questions (Appendix B) were then linked to a
research question so that the interview questions could be reported by research question or by
construct. Listing them in the different ways (Appendix A and B) permitted checking that each
construct and research question was adequately covered and that there was not an undue
concentration in any one area. Some interview questions would provide information that related
to more than one research question.
A list of possible or probable responses was developed for each question. When the question
sought an ordinal response, an ordinal scale of responses was developed. When the question
sought nominal information, a list of the more expected responses was developed. This aided
note-taking during the interview and added context to the question so that if the subject found
the question ambiguous there was additional information available to clarify it. For example, the
first question sought a measure of the size of the organization, an ordinal measure. A question
on the type of system being developed listed the industry sectors for which, from my experience
and knowledge of the local software development industry, software was developed (Table 23).
Table 23: Example questions from the structured interview script showing an ordinal scale of responses and a nominal list of potential responses.
1 How large is the software development organization - number of personnel, number of divisions, number of locations? < 10 staff 11 - 30 31 - 120 >120 - 1000 single organization > 1000 or Multinational 6 What type of system is being developed? Financial, ERP, CRM, SRM Military Infrastructure Telecommunications Medical Transport Services Factory automation Other
used by my organization over a two year period. I have also assisted in an assessment of the software development section of a large Australian State Government department using the OOSPICE method. This experience was used in developing the research instrument to ensure that the data sought was as objective as possible and contributed to the attribute of interest.
Research Design
Page 106
Specific terminology used in this research do not necessarily mean the same thing to all project
managers. For example, to one project manager the term “project monitoring” might mean only
those activities that directly seek information while to another it might mean all activities that
yield information about the project. For this reason, project managers were not directly asked
“How do you monitor your projects?” but were, instead, asked how they dealt with a situation.
Their responses yielded information on project monitoring, project control and project
coordination.
The total number of questions was constrained by the time that it was thought each interview
would take. While most people are prepared to spend up to an hour on a research project such as
this, asking for more than one hour of their time was thought likely to discourage participation.
4.3.1 Reviewing the research instrument The research instrument was briefly presented at a PhD assessment conducted by Associate
Professor Jie Lu, Associate Professor Barry Jay and Professor Chengqi Zhang of the University
of Technology, Sydney. The objective of the doctoral assessment is to “ensure that the student
has knowledge and skills to enable successful and timely completion of the research program”
(UTS, 2005). To achieve this, I gave a presentation outlining the problem and its importance,
the state of research known to date, the research approach and proposed research method. A
member of the panel asked how many questionnaire questions dealt with “organizational
distance”. At that time there was one question that sought information to classify the
organization on a simple, four quadrant diagram of organizational distance. The panel member
expressed a concern that one question would not elicit sufficient data for a construct so central
to the proposed research. As a consequence, the questionnaire was modified to address those
concerns and to review the adequacy of information sought for all of the constructs to be used in
the research (see Section 4.8). The revised questionnaire was reviewed by the panel member.
There was no formal pilot study performed for the questionnaire. Instead, the initial interviews
indicated that some questions needed clarification or augmenting. Consequently, some questions
were revised after the initial interviews to clarify them, and some questions were added to seek
information on requirements management and project management process capability, neither
of which were included in the research analysis due to the emerging depth of smaller area of
project management mechanisms.
After about ten interviews, it became obvious that project managers did not manage outsourced
team members differently to their own team members so the remaining subjects were simply
asked whether or not they managed the outsourced team members differently. This obviated the
need to spend 15 to 20 minutes answering the questions that were the same as previously asked
Research Design
Page 107
questions, except that they dealt with outsourced development. If the project manager indicated
that they did manage outsourced tasks differently to co-located projects then all the questions
were asked.
4.3.2 Reliability Reliability is the consistency or repeatability of the measures (Trochim, 2001 p88). The
structured interview questions and their response checklists were modelled on the ISO 15504
(SPICE) assessment model (ISO 15504, 1998) whose reliability was established during trials
(between September 1996 and June 1998). The trials established that internal consistency was
high enough to be usable in practice.
Although the current research cannot be as rigorous in a one hour interview as a five day ISO
15504 assessment, it borrows from the method to convert a subjective judgement to one that is
as objective as possible and thus achieve some measure of reliability.
An evaluation of the SPICE trials noted that there were two aspects to reliability: internal
consistency and inter-rater agreement (Jung et al., 2001). They noted that internal consistency
was affected by ambiguities in wording and inconsistencies in the interpretation of the wording.
This research was minimally affected by ambiguities and interpretation since the structured
interview questions were developed by the same person that conducted the interviews. Also
most of the questions were accompanied by a checklist of potential responses that clarified the
intention of the question and provided a context for the responses. To avoid prejudicing the
interviewee’s possible responses, they were not shown the checklists. While these factors
reduced ambiguities, there was no formal independent test of the interview questions’ internal
consistency.
Inter-rater consistency does not apply because there was only one “rater”. However, the
question of consistent rating by the one “rater” should be addressed. Deciding which of several
possible values on a nominal scale best represents the interview subject’s response is a
subjective judgement. Lacking any constraints such subjective judgements may reduce the
survey’s repeatability. This can be prevented by ensuring that the listed responses are such that a
subject’s response clearly and unambiguously fits only one item in the list.
4.4 Research ethics This research was required to conform to the research ethics guidelines of the University of
Technology, Sydney. A research proposal was submitted to the UTS Human Research Ethics
Committee in December 2002 and approval number HREC 02/142 was granted in January 2003.
Research Design
Page 108
Although the ethics review is mainly aimed at ensuring research participants do so under
“informed consent”, particularly if the subjects are children or students, it also covers matters of
privacy and data security. The intended research did not raise any ethical concerns. Actions
taken to secure the interview data are described in the next section (Section 4.5).
Informed consent was gained by asking subjects to read and sign a consent form that described
the research objectives, repeated that participation was voluntary and that they could withdraw
at any time, and gave contact details for the researcher as well as an escalation path should they
have any concerns about the research or the researcher (Appendix C - Consent Form).
4.5 Conducting the interviews Interviews were mostly conducted at the subject’s premises and at a time convenient to them.
The research was introduced and described; then the subjects were asked to sign the consent
form that explained the researcher’s obligations. Permission was sought from each participant to
record the interview. All participants agreed to this request and even though the offer was made
to turn the recorder off during the interview, only one subject requested that be done for a brief
period. In this research, the recorder used was an analogue tape recorder and not the next
generation of digital recorders. This had two consequences. The first is that on two occasions
the tape failed to auto reverse with the result that the second side of the tape did not record
anything and the transcript could not be completed. Fortunately, notes of responses were also
taken during the interview so that not all data were lost. The interviews were transcribed within
a day or two, thus allowing additional notes to be added or missing information to be provided.
The second consequence was that recordings on tape are not as easy to send to the interviewee
as would be digital recordings. This meant that the interviewee could only review the transcript
rather than check it against the audio tape.
Each interview lasted between twenty minutes to just over one hour. The duration depended on
how much detail the subject wanted to provide. At the end of the interview, subjects were told
that the recorded interview would be transcribed and emailed to them for checking. The
objective of checking was to have the transcript say what they wanted to say rather than to be a
literal record of the interview. This was to allow a subject to change their answer if, after
reflection, they thought of additional information or a better way to express their answer. It also
afforded the opportunity to change an answer they found embarrassing once they saw it in print.
None of the subjects altered a response for this reason.
Each interview was transcribed as soon after the interview as possible to preserve and to
overcome audibility problems that can sometimes make it difficult to hear precisely what was
Research Design
Page 109
being said. Generally, transcribing was completed within the same week. Each interview took
between 3 and 6 hours to transcribe and averaged 10 pages in length. There were 321 pages of
transcript in total. Initially the transcripts were a literal representation of what was said but often
this was a difficult-to-read collection of speech mannerisms, unfinished sentences, poor
grammar and other characteristics of informal conversation. With experience, the interviews
were transcribed to remove speech mannerisms that impeded readability while retaining
accuracy and the personality of the interviewee.
Completed transcripts were emailed to each subject to check and they were told that once they
had responded with corrections and permission to include it in the research, all references to
them and their organization would be encoded to ensure security and privacy of their interview.
Subject names were encoded with a “PM” followed by a random number between 1 and 100.
Organizations were encoded with a “C” followed by a random number between 1 and 100.
There was no relation between the number used for the organization and the number used for
subjects or anyone else within that organization.
Recording and transcribing the interviews also provided considerable raw data for content
analysis, giving a different view of the same interview. Multi-method research helps to
overcome the perceived weaknesses in single-shot approaches (Wood et al., 1999). Using the
two different views of the data, a quantitative survey response and a content analysis, is not as
strong as would be analysis of two separate sets of data gathered by different research
techniques, but is claimed to be stronger than either one of the techniques used separately.
4.6 Sample selection Subject selection used a combination of self selection and accidental selection. An initial list
was drawn up of organizations located in Sydney and known to develop software. Each
organization was phoned and a request was made to speak to a project manager. Sometimes this
request resulted in an explanation to an R&D manager or the divisional secretary or someone
similarly unconnected with software development. But, generally, people were prepared to
listen and tried to accommodate the request. Six of the initial list of eighteen organizations
accepted and were subsequently interviewed.
Accidental selection was performed through phoning organizations listed in the “Computer
Software and Packages” section of the Sydney Yellow Pages. No record was kept of how many
organizations were approached. However, after reviewing the retained section of the Yellow
Pages, I estimate that approximately 400 organizations were approached. Thirty two interviews
Research Design
Page 110
were conducted with people from twenty eight organizations. The acceptance rate is
approximately 7%.
4.7 External validity External validity is the extent to which the findings may be generalised to other contexts (Leedy
and Ormrod, 2001). In turn, this is related to the sample and its selection. The method of
selecting the sample has been discussed (Section 4.6), so this section will examine the sample
characteristics to establish how well the sample represents the general population of software
development organizations.
As can be readily seen from the data presented in the analysis (Section 5.3), the sample is not
representative of all software development organizations. This is evident in the distribution of
organization sizes in the sample which shows a bias toward small organizations and
multinational organizations (Table 24 in Section 5.3). Similarly, the weak external validity is
evident when comparing the distribution of organization process capability level in the sample
with the distribution of the same characteristic over a wider population gained during trials of
the SPICE standard (Table 25 in section 5.3). Thus extreme care must be taken with
externalising the findings of this research outside the research sample.
The sample size of 32 project managers belonging to 28 different organizations is small for
quantitative research. While it may be large enough to perform some simple statistical tests such
as Pearson’s correlation or a Chi-square test, it is not large enough for any multivariate analysis.
Even within the sample, some of the tests did not have sufficient occurrences in each category
to get a result.
Despite this weak external validity, the results presented in Chapter 5 are reasonably
unambiguous throughout the sample. This indicates that similar results would have been found
had the sample been larger and more representative of software development projects. The
conclusions, discussed in Chapter 6, are likely to be valid for any software development project
in Australia.
4.8 Construct validity Construct validity is the extent to which the research instrument measures a characteristic that
cannot be directly observed (Leedy and Ormrod, 2001). It is also expressed in an ISO standard
on measurement as the “fitness for purpose” of a measure which is judged by how well it
measures what it purports to measure (ISO 15939, 2002).
Research Design
Page 111
The number of interview questions related to each construct was reviewed to ensure that
sufficient data would be gathered and that the questions were not overlapping or unnecessarily
repetitious. Keeping the questions in a database made this task relatively easy because the list of
questions could be reported, grouped by construct, by category or in interview sequence.
Questions could also be reported listing which construct they supported to check which were the
important questions – the ones that supported multiple constructs.
The constructs needed to investigate these questions are described in the following section.
Some of the constructs are nominal and some ordinal.
4.8.1.1 Organizational Distance This is an ordinal construct made up of three dimensions: cultural distance, structural distance
and administrative distance.
Cultural distance borrows from Hofstede and the work of others (Hofstede, 1983a; Ronen and
Shenkar, 1985; Hofstede, 1991; Shenkar, 2001). This research uses the clusters of similar
national cultures proposed by Ronen and Shenkar (1985) to classify cultural distance.
Structural distance was judged by a combination of geographical distance and time zone
difference. Geographically separated countries that did not have a large time zone separation
were considered closer than those that did have a large time zone difference. So Japan was
considered much closer to Sydney than India.
Administrative distance was measured by the number of organizational layers between the
project manager and the project team. This was assessed by whether the project manager had
direct access to the project team or was constrained to deal through the outsourced
organization’s project manager, or through someone like a marketing manager who was
removed from the outsourced organization’s project manager. This is intended to be a coarse
measure of how much direct control a project manager has over the task. Techniques of direct
supervision are different from those of indirect supervision. This variable is intended to indicate
distance between the project manager and the person or team carrying out the project task.
4.8.1.2 Project management activities This ordinal construct is intended to discover the range of activities used by project managers to
monitor, control and coordinate a task. Lacking a predefined set of activities, the questions must
be designed to elicit and accept a range of responses that may be analysed later and possibly
group the responses into similar categories. From there, the mechanism being employed by the
project manager can be deduced. For example, if a project manager said they dealt with a task
overrun by rescheduling the project then the activity is rescheduling but the mechanism is the
schedule.
Research Design
Page 112
Asking a project manager directly how they monitored the project or controlled the project team
may evoke a range of responses that are not directly comparable. Different project managers
may have different ideas of what “monitor” is or what “control” is. Project coordination, for
example, is achieved indirectly and one project manager might consider a particular action
related to coordination while another might consider it related to project control. It is also
possible that a project manager might consider that some actions are related to risk management
and have nothing to do with monitoring, control or coordination. To overcome these different
perspectives, project managers were presented with a situation and asked what they would do
about it.
Acknowledging that the different project management mechanisms are inter-related and that a
question directed at, say, monitoring is likely to evoke information relating to monitoring as
well as control and coordination, interview questions were aimed at the different project
management mechanisms as follows. Questions 16, 17, 18, 30 and 31 (Appendix A - Structured
interview questions.) elicit information on project monitoring. Questions 2, 8, 9, 10, 11 and
25 - 29 relate to project control. Questions 19, 20, 21, 22, 33 - 36 relate to project coordination.
4.8.1.3 Project management capability Project management capability is an ordinal construct modelled on a SPICE process capability.
There may be variations of how well the project monitoring and management is performed.
Such variations should conform to a form of capability scale. The concept of process capability
is taken from software process assessment models such as CMMI (SEI, 2000) and SPICE (ISO
15504, 1998). In such models a process is defined in terms of its purpose and outcomes. The
outcomes provide evidence that the process purpose is being achieved. In turn, evidence that
outcomes have been achieved must be objective and requires either the production of a
deliverable work product or a significant change of state (of a deliverable or work product).
Emphasis is on objective evidence. A change of state could be that a document changes state
from "draft" to "reviewed" or from "reviewed" to "approved”. The set of outcomes is considered
as basic to the process. The objective evidence attests that the outcomes have been achieved,
which demonstrates that the process purpose has been achieved. Additionally, there are a set of
outcomes related to how well the process is managed and the achievement of these outcomes
determines the organization’s process capability or maturity.
Where possible, the fully tested SPICE indicators of process capability were used but, where no
such indicators were available or gave no result, alternative indicators of capability were
developed.
Research Design
Page 113
4.8.1.4 Organizational characteristics Organizational characteristics such as size, type of software developed and quality certification
were solicited so that some additional analysis could be performed. These attributes were either
ordinal (size, process capability) or nominal (existence of process improvement programme).
4.8.1.5 Project characteristics The attributes of a “typical” project were characterised by an ordinal measure of size and a
nominal classification of system/industry type
4.9 Internal Validity Internal validity is the extent to which the data allow the researcher to draw accurate
conclusions about cause and effect (Leedy and Ormrod, 2001) and other relationships within the
data. In this section, the validity of the ordinal constructs of organizational distance and project
management capability is discussed.
Threats to internal validity can arise through, inter alia, reactivity, experimenter expectancy
(Leedy and Ormrod, 2001 p104). Although the research participants were told that the research
subject was how project managers managed their projects and, in particular, how they managed
distributed and outsourced projects, there was no discussion of the expected results. This was
simply because, while interviews were being conducted, no conclusion had been reached about
what were the likely answers to the research questions.
However, a threat to internal validity arises because participants were chosen through accidental
sampling. Some organizations declined to participate in the research and those that did
participate could be disposed toward particular project management mechanisms.
4.10 Conclusion Research described here is best performed from a pragmatic knowledge claim that allows and
supports mixed method research. This allows data to be gathered for later quantitative analysis
for similarities or trends across all cases and for reviewing the qualitative data for unanticipated
insights.
Existing empirical studies of project management mechanisms have been conducted using case
studies, surveys, interviews and controlled experiments. This established a range of appropriate
research methods to guide decisions for this research. A strategy was chosen that acknowledged
the researcher’s limited experience and the probability that both knowledge and perception of
the subject was likely to change during the research. This resulted in choosing structured
Research Design
Page 114
interview as a method of gathering both quantitative and qualitative data and providing
sufficient samples to provide some, albeit limited, statistical validity.
A questionnaire was developed to guide the interview. Its composition was guided by the
information needed for the constructs of interest to this research. The questionnaire was
modelled on methods of assessing organizational process capability that have been used in the
software development industry since 1993. The research instrument (the questionnaire) was
reviewed during a doctoral assessment and after the initial few interviews. Modifications were
made to the research instrument that clarified some interview questions without altering the
validity or utility of data already gathered.
The external validity of the research is limited because the research sample is comparatively
small at 32 instances, and because the characteristics of the research sample differs from the
characteristics of the general population of software developers. Construct validity is claimed
through a review of the information gathered for each construct but is not proven through any
external test. Such tests of validity are beyond the scope of this current research project.
The research data were gathered by interviewing software development project managers,
guided by the research instrument. The interviews were audio recorded, transcribed and checked
by the interviewed project manager. The results of the analysis form the focus of Chapter 5.
Page 115
5 Analysis The previous chapter considered the research methodology (survey) and research method
(structured interview) best suited to investigate the research questions. This chapter will
examine the data thus collected. First, the sample characteristics are examined. Then, the data
will be examined to establish how project managers generally monitor, control and coordinate
their projects. Then, the measure of organizational distance, and the data contributing to the
measure, will be presented. This allows the distribution of the research sample on the scale of
organizational distance to be discussed. Next, the effect of increasing organizational distance on
the selection and use of monitoring, controlling and coordinating mechanisms will be examined.
Each mechanism will be examined in turn to establish whether different mechanisms are
associated with different organizational distances. Then, an analysis of which mechanisms are
essential for project management of software development projects will be presented.
5.1 Data sources and analysis The data taken from the interviews are of three forms. The first is the question responses
encoded according to the devised response scale or category. These data are amenable to
statistical analysis. The second set of data comes from content analysis of the interview
transcripts. This, too, is amenable to quantitative analysis. The third set of data is the interview
transcripts themselves, which can be examined qualitatively for themes that contribute to
understanding the research question. Yin (2003) argues that case study data analysis, by
following the theoretical propositions and by testing rival propositions, are stronger analytical
strategies than the third strategy of developing a descriptive framework with which to organize
the data.
5.1.1 Structured interviews The interview questions were either seeking categorical data or ordinal data. A question
concerning the size of the company, for example, sought information to enable classifying the
organization on a scale of small, medium or large. In this case, the question was accompanied
Analysis
Page 116
by an ordinal list and the appropriate organization size was selected from the list during the
interview.
Questions that sought categorical data were accompanied by a check list of the expected
common responses and space for recording responses that were not already in the list. Where
the responses used differing terms to describe the same type of phenomenon, the actual term
used by the interview subject was recorded. In later encoding, the range of terms was examined
and groupings made so that essential differences were preserved but simple terminology
differences were not accorded undue significance.
When encoded into SPSS, the dataset required 100 variables, some of which had been added to
represent aggregations of other variables. For example, there were a number of possible
methods project managers used to determine if their projects were “on track”. In addition to
recording which methods a project manager said they used, an additional variable recorded the
total number of methods. Similarly a variable was added for “Organizational distance” since it
is a combination of the variables that were responses to several other questions.
5.1.2 Content analysis Analysis of the transcripts was left until long after the interviews were completed. Analysing all
interviews in a condensed period helped get a consistent analysis by reducing the tendency to
modify criteria over time.
Content analysis most commonly counts the frequency with which something is mentioned as
indicating its importance (Lacity and Janson, 1994). This analysis seeks to identify the different
mechanisms used by project managers to monitor, control or coordinate their projects. Of
interest was the number of the project management mechanisms of the different types rather
than any indication of importance accorded them by the project manager. The various
mechanisms were classified according to frameworks established from the literature (Table 9).
The data were encoded into an SPSS data file using 82 variables, separate from the data set used
for structured interview data. The two data sets were checked to ensure that both the project
manager code and the organization code matched. A mismatch would have indicated a missing
interview or a data entry error.
Of the 82 variables, 4 variables characterised the organization (organization size, process
capability, project size, project novelty), 3 variables established an assessment of organizational
distance (cultural difference, structural distance, time zone difference and administrative
distance), 7 variables recorded the different types of automatic mechanisms (CSCW/Workflow,
configuration management, defect/issue tracking, automated testing, release management,
Analysis
Page 117
development life cycle and project web page) plus another variable to total the group. Then the
mechanisms use to monitor, control and coordinate were each represented by forty-five
variables (Appendix D), plus a variable to record a total for the group. Recording the raw and
aggregated data in this way allowed several different analyses to be explored to ensure that the
findings were sound.
5.1.3 Qualitative analysis Each interview is a small, albeit narrow, case study (Yin, 2003) conducted to explore the
research question that the choice of project management mechanisms will depend on the
organizational distance between the project manager and elements of the project team. Each
interview is examined for themes that support the research question, or that support possible
rival propositions.
Qualitative analysis is better able to reveal the reasons for actions, why a decision was made or
a project management mechanism was chosen, and to give depth and meaning to a complex
situation (Leedy and Ormrod, 2001). While this research primarily investigates which project
management mechanisms are used and the relationship between organizational distance and the
use of project management mechanism, augmenting the quantitative analysis with qualitative
analysis may give a deeper understanding of the results.
5.2 Statistical power The statistical tool used in this research to examine relationships is most often Pearson’s
correlation. While a correlation cannot prove causation it can show that there is a relation
between two variables. Cohen (1977) argues that the significance level of a correlation should
be augmented by considering the effect size, which is one of the main determinants of statistical
power. Conventional definitions of the effect size present in a correlation offered by Cohen are:
Small r = 0.10 Medium r = 0.30 Large r = 0.50
These criteria will be used in this research when describing relationships between variables.
Analysis
Page 118
5.3 Sample Characteristics
5.3.1 Organization size Organization size can be measured in different ways such as number of employees (ABS, 2002)
or the total income of the organization (ATO, 2004) among others, with the choice of measure
seeming to depend on the purpose of the classification. For this research the number of
personnel in the organization, actual or estimated, will be adopted as the measure of
organization size. This estimate includes the whole organization, not just the software
development part of it. Table 24 gives the distribution of organization size. The size divisions
were chosen because they reflect approximately where organizations tend to change structure
(Mintzberg, 1979), from direct supervision through simple, single layer management through to
multi layer management.
Alternative measures of organization size such as gross turnover or assets were not used because
it was thought that some organizations may have been reluctant to divulge such information.
Normally people are less reluctant to supply the number of employees.
Table 24: Organization size in the sample.
Frequency Percent Small (< 10 staff) 12 37.5 Medium (11 - 30) 4 12.5 Large (31 - 120) 3 9.4 Multinational (<1000 or multinational) 13 40.6 Total 32 100.0
5.3.2 Organizational Process Capability Process capability is a measure of how well an organization performs or executes a given
process. The concept builds upon “ principles of product quality that have existed for the last
sixty years” (Paulk et al., 1993), and was applied to software development in a rigorous
framework by the Software Engineering Institute in 1993. The organizational process capability
in this research is a very approximate guide based on the ISO 15504 (SPICE) or CMMI scale of
process capability. These ratings would be the equivalent of a very low rigour SPICE
assessment. Organizations were adjudged at level 3 if they were ISO 9001 accredited or had
undergone a SPICE or CMMI assessment and had achieved that rating. Level 2 was assigned if
the organization had documented software development processes, particularly those dealing
with project management and document control. The single instance of a capability level of 5
(Table 25) came from an organization that had recently undergone a CMMI assessment and was
accredited with that level.
Analysis
Page 119
Data on organizational process capability was sought as an alternative independent variable. If it
proved that the choice of project management mechanisms was not related to organizational
distance, would they be related to organizational process capability. The data came from
Question 2 of the questionnaire, shown in Appendix A.
The distribution of capability levels shown in the fourth column of Table 25 comes from the
SPICE Trials conducted to validate the assessment method (Hunter and Jung, 2000). They
indicate that the research sample is not representative of worldwide software development and
indicates that the research has limited external validity.
Table 25: Organization process capability assessed through a very low rigour assessment method.
Frequency Percent SPICE Trials
percent Incomplete - level 0 0 0.0 20 Performed - level 1 6 18.8 42 Managed - level 2 8 25.0 22 Defined - level 3 17 53.1 14 Measured - level 4 0 0.0 2 Optimizing - level 5 1 3.1 0 Total 32 100.0 100
5.3.3 Process Improvement Organizational commitment to process improvement shows another aspect of how formally an
organization views its software development processes. While very few organizations do not
improve the way they develop software, many also do not commit resources to doing so on any
regular basis. Process improvement is a requirement of ISO 9001 and also required at SPICE
and CMMI Level 3 but is often regarded by many organizations as an unjustifiable overhead.
The data came from Question 3 of the questionnaire, shown in Appendix A.
Table 26: Process improvement showing organizational commitment.
Frequency PercentNone 1 3.1 Episodic and informal 8 25.0 Regular and informal 7 21.9 Official function 16 50.0 Total 32 100.0
Table 26 indicates the distribution of process improvement initiatives within the sample
population from the perspective of how regular and how formal they are. The data came from
Question 3 of the questionnaire, shown in Appendix A.
Analysis
Page 120
5.3.4 Project size Some software development practices are appropriate for different sized projects. For example a
small, two person three month project does not require the same planning and formality as a
large project involving hundreds of personnel. Project management practices might vary with
the project size rather than with organizational characteristics. The size divisions of small,
medium or large were chosen because they approximately match the division used by Capers
Jones (1996), divisions that he defines in terms of function points. Projects in this research were
sized by the budget or by the number of personnel and project duration rather than function
points because few in the sample used function points. Measures based on budget or duration
were much more readily available. Jones’ upper and lower project sizes were discarded due to
the comparatively low sample size and because there are few very large (10,000 function points
or greater) projects in Australia. The resulting distribution of projects by size is shown in Table
27. The data came from Question 5 of the questionnaire, shown in Appendix A.
Table 27: Project size estimated by budget or equivalent.
Frequency Percent Small (< 6 months, $100K) 10 31.3 Medium (1 year < $1M) 12 37.5 Large (> 1M) 10 31.3 Total 32 100.0
5.3.5 Outsourcing The separation between organizations is not as simple as considering who are or are not
employees. Project teams can be made up of employees, contractors that are indistinguishable
from employees, contract suppliers who perform specific development functions and fully
outsourced development. The term “blended teams” was mentioned more than once during
interviews to describe project teams with a mix of the project manager’s employees, the
customer’s employees and contractors independent of either. Outsourced development in this
research was originally intended to describe development of some part of the project carried out
by a separate organization under suitable governance, such as a contract that described the scope
of works, responsibilities and payments. This research distinguished between projects that were
carried out entirely by employees of that organization, projects that utilized contracted staff that
were indistinguishable from employees, and those projects that fully outsourced, both legally
and financially, some of the project’s activities (Table 28). Responses to questions 23 and 24 of
the questionnaire were examined to determine the nature of the outsourcing.
Analysis
Page 121
Table 28: Distribution of outsourced development and contractor staff.
Frequency Percent No outsourcing 8 25.0 Contract 9 28.1 Outsource 15 46.9 Total 32 100.0
Approximately half of the respondents engaged in some form of outsourced development while
a further 28% employed contractors.
5.3.6 Managing outsourced development At the time the structured interview was developed, it was assumed that project managers would
manage outsourced development differently from local development so a number of interview
questions sought information on monitoring, managing and coordinating local software
development. Then, after establishing characteristics of any outsourced development, the same
questions were repeated for outsourced projects. But, within a small number of interviews, it
became very apparent that project managers were giving the same answers to both sets of
questions leading to the conclusion that project managers managed all development on the one
project, whether local or outsourced, using the same practices. This was easy enough to confirm
by asking “Do you do anything differently when managing outsourced development?” which
was invariably answered “No.”
That project managers did not consider their management techniques to be different could
simply mean that the project managers did not distinguish and did not consciously do anything
differently. It could also mean, for example, that their overall techniques change to
accommodate the demands of outsourced development and that the changed techniques work
for local development as well.
The structured interview was not altered to redirect the research because to do so would have
wasted the data already collected with possible detrimental effects on relations with those
interviewed. Also, the data being sought contained enough information to examine the modified
research direction.
Before proceeding with any analysis of project management practices, relationships between the
organizational characteristics will be examined. As can be seen in Table 29, There is a
significant relationship between organization size and project size, and between organization
size and process capability. This implies that larger organizations tend to employ more formal
software development methods and tend to undertake larger projects.
Analysis
Page 122
Table 29: Correlations between organizational size, project size and process capability.
Project size Organization size
Process capability
Project size Pearson Correlation 1 .568** .396* Sig. (1-tailed) . .000 .013 Organization size Pearson Correlation .568** 1 .699** Sig. (1-tailed) .000 . .000 Process Capability Pearson Correlation .396* .699** 1 Sig. (1-tailed) .013 .000 . Count 32 32 32 ** Correlation is significant at the 0.01 level (1-tailed). * Correlation is significant at the 0.05 level (1-tailed).
5.4 Project management mechanisms In this section, the first research question will be examined. That is:
RQ1: Which mechanisms do project managers use to monitor, control and
coordinate software development projects?
The analysis will be performed using data from both the structured interview “check list”
responses and from the content analysis of the interview transcripts. Data from each will be
presented separately so that the origins of inferences are clear. Some conclusions will be drawn
about which mechanisms are preferred.
5.4.1 Project Monitoring This part of the analysis investigates the first sub-question of RQ1. That is:
RQ1.1: Which mechanisms do project managers use to monitor software
development projects?
The two different perspectives of the research data, structured interview response and content
analysis, may show different views of project monitoring. The term “project monitoring” does
not necessarily mean the same thing to all project managers. To one it might mean only those
activities that directly seek information while to another it might mean all activities that yield
information about the project. For this reason, project managers were not directly asked “How
do you monitor your projects?” but were, instead, asked how they dealt with a situation. Their
responses yielded information on project monitoring, project control and project coordination.
5.4.1.1 Structured Interview data Through questions 16 and 17 of the questionnaire project managers were asked how they
established that the project was “on track” and, in a separate question, how they detected that
Analysis
Page 123
the project was “not on track”. The responses were grouped as shown in Table 30. These will be
analysed according to the type of mechanism in Table 9, Section 2.5.
Table 30: Groupings of methods of determining if a project is "on track" or "off track".
Expert judgment Judgment by the project manager using their experience to interpret the general disposition of the project and personnel.
Progress Objective indications of progress such as task completions or achieving milestones (or “inch pebbles”).
Earned Value Earned Value Report compares work accomplished against work planned in dollars and as percentage of the total budget (Shumate and Snyder, 1994).
Risks Some form of risk management. Defect list Monitoring the state of the project or developed product
through actively reviewing the number and type of outstanding defects or the growth and decline in the number of defects.
Test statistics Reviewing progress through formal testing through statistics such as the number of tests performed, tests passed, test coverage and similar.
Each monitoring practice’s usage frequency is presented in Figure 10.
0102030405060708090
100
Exp
ert
judg
men
t
Pro
gres
s
Ear
ned
Val
ue
Ris
ks
Def
ect l
ist
Test
stat
istic
s
Figure 10: Percentage of project managers who use each project monitoring practice.
Project managers frequently use more than one indication of project status and progress. Figure
11 shows that most project managers use 3 or 4 different monitoring practices. Project
monitoring using a portfolio of practices has not yet been described, in contrast to papers
describing a portfolio approach to project control (Choudhury and Sabherwal, 2003) and
multiple coordination mechanisms within the one project (Sabherwal, 2003). That project
managers use multiple monitoring practices should not be surprising, but, is there some pattern
in which project managers use more?
Analysis
Page 124
Count of monitoring Techniques
654321Missing
Perc
ent
30
20
10
0
Figure 11: Frequency of multiple monitoring practices.
The correlations, in Table 31, show a strong correlation between organizational process
capability and the number of monitoring practices used but a weaker correlation with
organization size and weaker still with project size. This indicates that project managers in
organizations with more mature software development processes use a variety of methods and
sources to seek more information about the state of their projects.
Table 31: Correlations between the number of monitoring practices used by project managers and organizational characteristics.
Process capability
Organization size
Project size
Count of monitoring Techniques
0.512** 0.443* 0.245
Sig. (2-tailed) 0.003 0.011 0.177 ** Correlation is significant at the 0.01 level (2-tailed). * Correlation is significant at the 0.05 level (2-tailed).
5.4.1.2 Content analysis The interview transcripts were examined for direct or indirect reference to monitoring
mechanisms which were then classified and counted according the classification schema
developed in Section 2.5 Table 9. The count recorded only different project monitoring
mechanisms. If a project manager referred to the same project monitoring mechanism more than
once, it was counted only as the one mechanism. It is possible to count the number of
mechanisms in two ways. The first is a simple, raw count of the mechanisms irrespective of
project manager. The second is a count of how many project managers used a particular
mechanism, regardless of how many different ways the project manager used the particular
mechanism. This research considers that a raw count gives a better indication of the popularity
of a particular monitoring mechanism.
Analysis
Page 125
Table 32: Frequency of monitoring mechanisms detected with content analysis.
Monitoring mechanism Count Percent CSCW, Workflow 2 6.3 Configuration management 6 18.8 Defect, issue tracking 9 28.0 Automated integration & testing 3 9.4 Release management 12 37.5 Development cycle 11 34.4
Automatic
Project bulletin board 1 3.1 Product review/inspections 6 18.8 Schedule & milestone tracking 30 94.0 Team meetings 30 94.0 Status reports 28 87.0 Management review 24 75.0
Formal Monitoring
Customer review 10 31.0 QA or process audit 6 18.8 Phase end review 9 28.0
Ad hoc monitoring
Drill down inquiry 20 62.5 Conversations with project team 26 81.0 Conversations with stakeholders 9 28.0
Informal monitoring
Conversations with customer 18 56.0
Project managers could employ multiple monitoring mechanisms on the same project. In order
for more than one monitoring mechanism of the same type used by the same project manager to
be counted, there needed to be clear indications that the implementation of the mechanism was
separate. For example, projects often have team meetings and formal meetings with the
organization’s management. Both are formal monitoring mechanisms and if a project manager
indicated that both were used then the count of formal monitoring mechanisms was two.
However, if the project manager simply referred to “meetings” and did not distinguish team
meetings from management meetings, then only one formal monitoring mechanism was
recorded.
The number of cases using at least one of the specific type of monitoring mechanisms is
displayed in Table 32 and, graphically, in Figure 12. The graphic presentations conveys the
relative popularity of different mechanisms more readily than tabular data.
Analysis
Page 126
0 2 0 4 0 6 0 8 0 1 0 0
C S C W , W o r k f lo w
C o n f ig u r a t io n m a n a g e m e n t
D e f e c t , is s u e t r a c k in g
A u t o m a te d in te g r a t io n & t e s t in g
R e le a s e m a n a g e m e n t
D e v e lo p m e n t c y c le
P r o je c t b u lle t in b o a r d
P r o d u c t r e v ie w / in s p e c t io n s
S c h e d u le & m ile s t o n e t r a c k in g
T e a m m e e t in g s
S t a tu s r e p o r t s
M a n a g e m e n t r e v ie w
C u s t o m e r r e v ie w
Q A o r p r o c e s s a u d it
P h a s e e n d r e v ie w
D r ill d o w n in q u ir y
C o n v e r s a t io n s w ith p r o je c t t e a m
C o n v e r s a t io n s w it h s t a k e h o ld e r s
C o n v e r s a t io n s w ith c u s to m e r
Figure 12: Frequency with which different monitoring mechanisms are employed.
The data show that formal monitoring mechanisms were more popular than informal, ad hoc or
automatic monitoring mechanisms. Project managers used ad hoc monitoring less than informal
monitoring, reflecting the view that ad hoc monitoring is called on only when necessary
whereas informal monitoring is used constantly. Additionally, project managers did not use only
one mechanism of each type. This indicates that no one monitoring mechanism provides all the
information sought by project managers and they use different mechanisms to gain more
information or different perspectives.
5.4.1.3 Qualitative analysis. Project managers’ views of what it meant to monitor a project and how they achieved it was
largely contained in the responses to questions 16, 17 and 18 of the questionnaire.
Almost without exception, project monitoring is seen as a process of maintaining awareness of
progress through the planned schedule. Less frequently, project managers maintained an
awareness of any threats to progress through their monitoring activities. Data on the completion
of scheduled tasks was gathered in a number of ways: verbal reports during team meetings,
written reports submitted by the team member, updating a common file and, sometimes, casual
conversations. In some of the larger organizations, team members appeared to have submitted
their reports to an administration assistant who then prepared a report for the project manager.
The structured interview questions dealt with knowing whether the project was “going right” or
“going wrong” to establish which information, of all the information the project manager may
Analysis
Page 127
receive in a given period, they most used in order to determine the state of the project. The most
common response was that the project’s progress was checked against expected progress. For
some, this was determined by task completions, for some by earned value and for some by
milestone completion. One of the more encompassing responses was.
PM70 Well, as I said , there was a detailed schedule so that was certainly one of the key tools I
had. Each week there were formal status meetings where we looked at what was due to
be completed this week, what was due to be completed next week. Of course most of
the time you communicated with the team informally but there was a formal mechanism
as well to say “what are you committing to next week?”. And then when next week
came along, “Have you done it? What problems have you had?” etc. Obviously if there
were major problems you’d find out about them at the time, not in the weekly meeting.
We used Earned Value in the case where we had fixed amounts of money or a certain
amount of work had to be done at a certain stage, particularly for the June release.
Other project managers were not so concerned about the specific details.
TM Project monitoring. The project is in train now. As a project manager, what do you look
at to see if it’s going right? And how do you know the project is on track?
PM25 Generally our project managers are from a technical background and the project
management plan would have been constructed on a basis that they could be followed
on a weekly basis. So there wouldn’t be many activities that are over a week in the
project plan. There’d be project meeting once a week where progress, logs, issues, tests,
plans (were discussed).
TM As a project manager, what do you look at to see if it’s going wrong?
PM25 I think, I mean there are alarm bells that go off as soon as earned valued or schedule go
more than 10, I think schedule is 20% and earned value is 10%. If they go any more off
track than that then that will show up in the monthly metrics that are presented to the
leadership team.
However, no project manager indicated that they regularly sought or reported information
containing both the status of the project and the causes of that status. Regularly sought
information seemed mostly to act as an early warning system that directed attention to where
further information was needed to establish the cause of adverse status or progress.
Most project managers were not explicit about how they established the cause of adverse status.
Rather, it appeared to be a general part of project management activities such as team meetings
or conversations between themselves and team members. Some project manager, however,
Analysis
Page 128
explicitly reacted to adverse project status or other indications that the project was “going
wrong”
PM74 It’ll appear in the other deliverables, so things will start slipping and we’ll then drill
down on the team that’s having problems and find out what’s going on. We just talk to
people, work it out.
Automatic monitoring. No project manager spoke directly of automatic monitoring, leading to the impression that, if
automated tools were used, they were not thought of as project monitoring tools. The most
frequent use of automated monitoring came with the use of iterative development that project
managers regarded as a means to guide the development through feedback from the client.
Overall, project managers appeared to be unaware of the use of automated mechanisms as ways
of monitoring the project.
Formal monitoring. Formal monitoring by design or code review or ad hoc inquiry was less frequent with fewer than
five project managers mentioning such reviews. The independent audit is an infrequently used
means of monitoring projects and in only one out of the three cases was initiated in response to
adverse project status. In the other two cases, the review was simply an independent check on
the project.
Regular reviews with organizational management where the project manager reports the state of
the project to senior management was more popular. Sometimes these were regular, normally
held monthly where senior management were appraised of the project’s status, risks and issues.
One organization reduced the interval between their management reviews which were attended
by more of the organization’s senior management in response to “issues with that particular
customer”.
More common was the concept of a phase review where senior management reviewed the
project at defined phases such as the end of project planning, the end of high level design, the
end of testing and at the end of implementation. In its various forms this was mentioned by five
project managers who worked in the larger organizations.
Informal monitoring Team meetings were the most common means by which informal monitoring was carried out.
Aside from a brief review of the project’s progress and the opportunity to discuss a number of
project issues, team meetings allowed the project manager to detect hidden issues through
casual conversations. Conversations are not limited to the team meeting and were mentioned
Analysis
Page 129
throughout the interviews in response to a number of questions. Sometimes the conversation
was between the project manager and the customer, sometimes between the project manager and
the team, and sometimes between the project manager and the organization’s management.
Some of the project managers were more aware of conversations as a means to monitor the
project, as illustrated by the following.
PM62 Yes. Management by walking about. It’s not just that. It’s talking to people and getting
a feel. Like, for example, I’ll give you a good example. One of our consultants is going,
or he’s in a project today and I will give him a ring this afternoon just to find out “Well,
you’ve been there. Just give me a gut feel for how these guys are tracking. What’s going
on” and just get that feedback on a regular basis. So, apart from the weekly meetings
that I have with this customer to track what this project is doing, I also want to know
from our people that go there, possibly call the project manager in between and just get
a feel for what is happening. Just to make sure that I’m on top of any major issues that
need to be aware of. And that’s the informal. But there’s also the formal meeting every
week where I look at all the details.
Ad hoc monitoring Although several project managers did mention “drill down” as a response to information
received through more regular means, most project managers weren’t conscious of doing
anything special. To them it was normal and expected that they would investigate when they
thought such actions were necessary. In some cases, however, response to project information
could be a more formal review by project auditors.
5.4.1.4 Findings The majority of project managers monitor their projects through the formal mechanisms of team
meetings and schedule tracking. This is supplemented with informal conversations with the
project team, afforded by co-location, and conversations with the customer.
The majority of project managers use multiple monitoring mechanisms to track the status of the
project.
Project managers do not consciously use automated monitoring to any significant extent.
Similarly there are a number of mechanisms such as phase end reviews, design reviews and
project bulletin boards that are used by a minority of project managers. While these mechanisms
may be essential in some circumstances and prove very valuable, their use is not widespread as
a means of monitoring the project.
These findings will be discussed in more detail, in the context of the research questions, in the
next chapter.
Analysis
Page 130
5.4.2 Project control This part of the analysis investigates the second sub-question. That is:
RQ1.2: Which mechanisms do project managers use to control software
development projects?
Project control seeks to ensure that people act in a way consistent with achieving the desired
objectives (Choudhury and Sabherwal, 2003). Project managers normally have the three
objectives of schedule, functionality and quality to juggle by sacrificing one to achieve the
others. This research added system performance to the list of objectives because there are some
systems, for example real time control systems, where performance is just as important as
functionality.
The structured interview questions took a simple view of project control and sought information
about project control by asking how the organization prioritised their success criteria and how
the project manager exercised project control through reactions to delays in project task
completion. The content analysis sought evidence of the different types of control mechanisms
project managers employed during the project. So the analysis of the data from the structured
interviews focussed on what the project manager did to control the project while the content
analysis focussed on the mechanisms with which they exercised control over the project.
5.4.2.1 Structured interview data Project objectives could be established either by the existence of written project objectives such
as may be included in a contract’s terms and conditions, or through the criteria with which the
organization judges that a project has been successful. The latter acknowledges that what a
client may regard as successful, the developer or supplier may regard as unsuccessful. For
example, a fixed price project that was delivered on time may be regarded as successful by the
client but, because it ran over budget, may be regarded as unsuccessful by the developer. This
research sought the developer’s success criteria. Project management objectives were
ascertained by asking how project success was measured in the organization (Question 8,
Appendix A).
The data in Table 33 shows that schedule (delivering to the agreed schedule) and budget
(keeping the project within budget) are more frequently used as project success criteria than
other criteria. The original interview question did not anticipate the success criteria of “customer
satisfaction”. It was recorded in the encoded data because, of the responses that would normally
be collected in a category of “other”, “customer satisfaction” was frequently and specifically
forwarded by project managers as an additional success criteria.
Analysis
Page 131
Table 33: Organizational criteria for project success.
Count Percent Schedule 29 90.6% Budget 28 87.5% Functionality 20 62.5% Quality 17 53.1% Customer Satisfaction 19 59.4% Political 11 34.4%
Project managers were asked what they would do when some event delayed a task (Questions 9,
10, 11 shown in Appendix A). This is a normal decision faced by project managers when one or
more of the project tasks is taking longer than expected or is more difficult to implement than
expected. Sometimes functionality, quality or performance is retained at the expense of the
schedule. The most common response was that the decision depended on the situation. The
frequency of the different responses is shown in Figure 13.
Performance targets for the software being developed were either not set (15% of responses) or
always retained (27% of responses). A more correct interpretation of “always retained” would
be that performance wasn’t knowingly compromised to achieve other project or product
objectives. Frequently the initial response was surprise because performance, in terms of system
throughput, is seldom specified and is not usually thought of as something that can be traded
against project schedule. During the interviews, it was explained that system performance might
have been expressed as a required response time or a required transaction throughput. The
clarification seldom altered the respondent’s answer.
Quality targets were also rarely knowingly compromised to meet schedule commitments.
Project managers did acknowledge that they would sometimes deliver a release with reduced
quality (more defects than expected) when it could be followed up with a “patch release” that
rectified the defects.
Most of the time it was functionality that was traded against project schedule, as illustrated in
Figure 13. When negotiating project objectives with the project stakeholders, it is functionality
that is most often negotiated.
Analysis
Page 132
0.00
20.00
40.00
60.00
80.00
100.00
Alw
ays
reta
ined
Engi
neer
sde
cide
Proj
ect
Rev
iew
boar
dde
cide
s
mar
ketin
gde
cide
s
Neg
otia
ted
with
stak
ehol
ders
Functionality
Quality
Performance
Figure 13: Trade-off between functionality, quality and performance over schedule when the schedule is threatened
0
20
40
60
80
100
Do
noth
ing
Add
reso
urce
s
Red
uce
scop
e
Rea
ssig
nsc
ope
Oth
erac
tion
Figure 14: Actions taken when project schedule is threatened.
Project managers were asked what action they took when project tasks or other event delayed,
or threatened to delay, the project. The project could be threatened for any number of reasons
and project managers have a number of courses of actions available to them. The responses are
presented in Figure 14 and show that the most project managers will add people (human
resources) (63%). Reducing the scope of functionality (42%) and reassigning some functionality
to another release or another part of the system (42%) are also common responses.
5.4.2.2 Content analysis Interview transcripts were examined for evidence that project managers used different types of
control mechanisms. The classification of the mechanism types and reasons for their selection
has previously been discussed (Chapter 2). Briefly, the types of control mechanisms are output,
behaviour, input and clan control. The frequency with which specific control mechanisms were
mentioned in the interview transcripts is given in Table 34 and, graphically, in Figure 15.
Analysis
Page 133
Table 34: Frequency of control mechanism used by software development project managers.
Control mechanism Count Percent Budget, schedule, functionality 28 87.5% Customer satisfaction 18 56.3% Contract T&C 12 37.5%
Output Control
Other output control 23 71.9% Formal processes 22 68.8% Process training 10 31.3% Project Plan 32 100.0%
Behaviour Control
Other Behaviour control 2 6.3% PM selection 2 6.3% Team selection 7 21.9% Select by RFP 3 9.4%
Input control
Other Input control 4 12.5% Team co-location 24 75.0% Exchange developer 1 3.1% Site visits by PM or team 14 43.8% Informal communication 20 62.5%
Clan control
Other clan control 1 3.1%
Of the output control mechanisms, the most frequently used is some combination of budget,
schedule and functionality that is normally part of the project’s general objectives. This is not
surprising since those objectives, or constraints, drive project planning. The frequency for
“other output control” is made up of; acceptance or other form of formal testing (12 instances),
a financial measure over and above meeting the project’s budget such as “profitability”(5
instances) or some measure of organizational target such as meeting Key Performance
Indicators or KPI (7 instances).
0%
20%
40%
60%
80%
100%
Budg
et, s
ched
ule,
func
tiona
lity
Cus
tom
er s
atis
fact
ion
Con
tract
T&C
Oth
er o
utpu
t con
trol
Form
al p
roce
sses
Proc
ess
train
ing
Proj
ect P
lan
Oth
er B
ehav
iour
con
trol
PM s
elec
tion
Team
sel
ectio
n
Sele
ct b
y R
FP
Oth
er In
put c
ontro
l
Team
co-
loca
tion
Exch
ange
dev
elop
er
Site
vis
its b
y PM
or t
eam
Info
rmal
com
mun
icat
ion
Oth
er c
lan
cont
rol
Figure 15: Frequency of control mechanisms used by software development project managers.
Of the behaviour controls, the project plan is used without exception. The data does not
distinguish between different types of project plan nor is there any measure of the project plan’s
Analysis
Page 134
granularity. Nevertheless, the universal use of a project plan indicates a wide consensus on its
value as a control mechanism.
Project managers were asked directly if they, or their organization, used formal development
processes. The processes that were considered to qualify as “formal” did not need to be those
that would meet the requirements of an ISO 9001 audit but did have to be formally expressed in
some way. None of the project managers indicated that the project teams ignored the formal
development or quality processes. This contrasts with anecdotal claims by some of the
interviewed project managers that development methodologies and quality management systems
tend to be ignored by software developers.
Team co-location usually meant that the team was in one place or at least grouped rather than
dispersed. Frequently, the development teams were located on the customer’s premises, even if
that was overseas.
Informal communication is a very general category and is normally taken to mean casual
conversations but it also included emails and phone conversations (Kraut and Streeter, 1995;
Sabherwal, 2003). The essential characteristic of informal communication is that it is unplanned
and unrestricted and not that it occur face to face.
5.4.2.3 Qualitative analysis Project managers perceived control to be something they actively did rather than something
structured during project planning. For example, team co-location was seen as a way to better
understand the client’s requirements rather than as a way to control the client or the project team.
Even in response to specific scenarios set out in questions 18 - 20 of the questionnaire, project
managers reported that they tended to control the project by direct actions aimed at keeping the
project on schedule. None of the project managers responded with something longer term such
as moving the team to the customer’s premises, an action Sabherwal found when considering
the evolution of project coordination mechanisms over the life of a project (Sabherwal, 2003).
Contract terms and conditions or development life cycles (shown in Table 34) are more
structural in nature and were seen more as organizational than project management matters.
When dealing with outsourced development, project managers occasionally travelled to the
supplier’s site but is was normal to talk to them regularly. Although this was normally part of,
or intended to be, a way to establish the project status, it also served as a form of clan control.
One project manager’s responsive was quite instructive.
TM What do you do when they are an important part, they are significant, and they are not
here? They are overseas somewhere. How do you monitor it then?
Analysis
Page 135
PM67 Well, again. You would audio conference and call them in. You would call them in,
have a discussion with them. Make sure they are submitting regular status reports. And,
I personally set an expectation with them guys that I need to know before a delay occurs.
Before you announce the delay, I want to know that there’s a possibility of a delay. If
you set that mindset from them and you find out from them have they set their plan to
that level to be able to find out that a delay can potentially occur, what mechanisms are
they going to have in place to inform us.
Clearly this particular project manager inculcated a particular belief in how they wanted the
project to run.
Very few project managers used trained outsourced teams in particular development methods or
any other aspect of software development. It appeared to be sufficient to check the delivered
component by testing or review.
5.4.2.4 Findings All project managers controlled the behaviour of their development teams through a project
schedule, commonly referred to as the “project plan”. Formalised, that is documented, software
development processes were also a common mechanisms to control behaviour in almost 70% of
projects.
The majority of project managers reported that their project was controlled by the project
objectives, commonly functionality, budget and delivery date. The majority of project managers
were also subject to additional project objectives which could be financial or organizational.
Co-location and informal communication were employed by a majority of project managers as a
means of clan control but the choice of mechanisms in this category were less distinct than in
the other categories of control types.
Project managers commonly employed a portfolio of control mechanisms to control the project
rather than rely on one type of control mechanism.
5.4.3 Project coordination This section of the analysis investigates the third research sub-question. That is:
RQ1.3: Which mechanisms do project managers use to coordinate software
development projects?
The structured interview questions sought information on how project managers adjusted the
project after discovering that a task could not be completed in the allocated time or could not
implement the functionality originally intended. Also, questions 21 and 22 were asked about
Analysis
Page 136
project team meetings because this is a common forum where informal information about the
project is exchanged, which can help to create a shared memory among the project team
(Herbsleb et al., 2000; Espinosa et al., 2001; Levesque et al., 2001).
The transcripts of the interviews were examined for mention of a specific coordination
mechanism. Each identifiable mechanism was recorded only once regardless of how frequently
it may have been mentioned. This provided a different view of coordination mechanisms that
could be analysed separately.
5.4.3.1 Structured interview data Evidence of the use of different coordination mechanisms were sought through questions 8, 12,
13, 15 and 16 - 22 related to project planning, schedule planning, adjustments made to the
project arising from unforseen difficulties, and through the topics discussed at team meetings.
Project plans and schedules Project plans and schedules are used both as control mechanisms and as coordination
mechanisms and was pervasive, with all respondents using project plans and schedules of some
form.
Project adjustments Respondents were asked a series of questions (questions 18, 19, 20) to determine how they
overcame the problem of some part of the project taking longer than planned or being
unimplementable. The frequencies of the differing responses are shown in Table 35.
Table 35: Actions taken when requirements prove unimplementable or unexpectedly difficult.
Frequency Percent Drop functionality 1 3.1 Work around 15 46.9 Reallocate within system 3 9.4 Slip release 1 3.1 Depends on situation 10 31.3 Missing 2 6.3 Total 33 100.0
Project managers expressed a reluctance to drop functionality or in some other way reduce the
utility of the finished produce and, instead, preferred to work around the problem (49% of
cases). A response that was not expected was that project managers would respond depending
on the situation (41% of cases). Taken together, these responses indicate that project managers
are reluctant to disrupt the planned project progress. Delays to task completions could happen
for a number of reasons: being distracted by more urgent work, the task proving more difficult
than envisaged. Regardless of the reason, the project manager must take some action to
Analysis
Page 137
rebalance the schedule. A summary of the frequency of the alternative actions is shown in Table
36.
Most of the respondents nominated several possible actions, depending on the circumstances.
While it may be possible that there is some relation between the number of alternative actions
considered by a project manager and an attribute of the organization or the project manager such
as greater experience, such a relationship was not present in the sample data.
Table 36: Actions taken when a task is taking longer than expected.
Count Percent Do nothing 8 25.0% Add resources 15 46.9% Descope 12 37.5% Reassign scope 12 37.5% Other 14 43.8%
Project meetings Project team meetings are common in software development and are one of the more frequently
used coordination mechanisms. The structured interview did not explore different methods of
holding meetings such as video conference or “in person” but did explore the purpose of team
meetings and management meeting through the subjects that were discussed. As can be seen in
Table 37, very few project managers do not hold regular team meetings. Both of the
organizations that did not hold team meetings were teams of one person, where team meetings
are inappropriate.
Table 37: Actions taken when a task is taking longer than expected.
Count Percent Team meetings are held 29 90.6 Design 18 56.3 Requirements 15 53.1 Schedule, budgets, milestones 26 81.3 Risks and issues 12 62.5 Other 11 34.4
While the data indicate that schedules, budgets and other matters related to project progress are
discussed more frequently at team meetings (81% of cases), other topics are not neglected.
Team meetings appear to act as a general discussion forum rather than be devoted to a single
topic. The data for this came from question 21.
Some organizations also require project managers to report about their projects to more senior
management. There is a wide range of ways in which this may be done but the most frequent is
a written report that is reviewed during a meeting which could be in person or via phone. As is
Analysis
Page 138
shown in Table 38, half of all project managers meet with their management, about 20% submit
reports and about 30% do not have meetings. The data for this came from question 22.
Table 38: Frequency of formal management review of projects.
Frequency Percent No meeting 9 28.1 Meet 16 50.0 Report 6 18.8 Missing 1 3.1 Total 32 100.0
5.4.3.2 Content Analysis The interview transcripts were examined for evidence of coordination mechanisms which were
then classified according to the previously established scheme (Table 9) of standards-based,
plan-based, formal mutual adjustment and informal mutual adjustment. The frequency of each
type of coordination mechanism is displayed in Table 39 and, graphically in Figure 16.
Table 39: Frequency of coordination mechanisms detected through content analysis.
Coordination mechanism Count % Template work products 16 50 Interface specs 6 19
Standards based
Design rules 6 19 Schedule 27 84 Specifications 32 100 Sign offs - phase reviews 11 34
Plan based
Test plans 17 53 Code and design reviews 7 21 Change control committee 11 34 Project team meetings 28 87 Ad hoc meetings 17 53
Formal mutual adjustment
Project reviews 14 43 Co-location 19 60 MBWA 11 34 Personal conversation 25 78
Informal mutual adjustment
Site visits 14 43 It is notable that four mechanisms are used significantly more frequently: schedule,
specifications, project team meetings and informal conversations. Co-location appears to be
almost as popular. However, in this research sample only 46.9% of projects had some
outsourced elements so it is reasonable that co-location would feature as a coordination
mechanism in approximately 60% of projects. It’s presence does not indicate a conscious use of
co-location to manage the project.
A graphical view of the data from (Figure 16) better illustrates the relative popularity of the
different coordination mechanisms. It is evident that standards-based coordination mechanisms
Analysis
Page 139
(template work products, interface specs, design rules) were not frequently spoken about. This
could have been a lack of direct questions concerning such coordination mechanisms or may
have been that such mechanisms are so much a part of the environment that they are
unremarkable.
The data indicate a very high incidence of schedules, specifications and project team meetings
that indicates a trend toward market based mechanisms (Sabherwal, 2003).
The high use of formal and informal mutual adjustment mechanisms, team meetings and
personal conversation, indicate a need to manage a significant amount of mutual dependency.
0
20
40
60
80
100
Tem
plat
e w
ork
prod
ucts
Inte
rface
spe
cs
Des
ign
rule
s
Sche
dule
Spec
ificat
ions
Sign
offs
- ph
ase
revi
ews
Test
pla
ns
Cod
e an
d de
sign
revi
ews
Cha
nge
cont
rol c
omm
ittee
Proj
ect t
eam
mee
tings
Ad h
oc m
eetin
gs
Proj
ect r
evie
ws
Co-
loca
tion
MBW
A
Pers
onal
con
vers
atio
n
Site
vis
its
Figure 16: Relative frequency with which different coordination mechanisms are used. Expressed as a percentage of all cases.
5.4.3.3 Qualitative analysis While project coordination was seen by project managers as the actions they might take to re-
align the completion of documents or components, in fact all projects employed some form of
specification that described what the various components were to do, and almost all project
managers expressed a work breakdown schedule in some form of project plan. Coordination
was seen as the actions taken to adjust the scheduled delivery of components or to adjust the
effort involved in producing the components.
The larger or more time critical projects tended to used fairly detailed work breakdown
structures, where tasks were broken down into something that could be completed in a week or
less. There didn’t appear to be a significant difference between large or small projects in the
granularity of the work breakdown structure although there did appear to be a tendency for less
Analysis
Page 140
rigour when the project iterated over many releases, possibly over several years. In such cases
there was a ready mechanism to offload work that could not be completed in the current release.
However, projects with less flexible delivery dates and less flexibility over delivered
functionality tended to be planned in considerable detail. In one project there was a common
schedule developed for both the prime developer and at least one of the outsourced suppliers:
PM79 ….In terms of managing teams, we set up terms of reference so there’s a framework
against which our relationship has to work. With some of our internal companies we
have agreed to work against a mutual project plan. They have a project plan for their
activities, I have one for my activities, the customer includes their activities and we
mutually agree that’s the way we are going to behave.
In the case of projects with iterative release, the following illustrates a typical attitude to
planning and scheduling.
PM70 Typically I didn’t have anything on the schedule that was less than a day. Usually
anything from a couple of days to several weeks because things like the testing, for
example, would be a large block of time. User acceptance testing would be a block of
time, usually 6 to 8 weeks, where users would go through a formal test plan. The
schedule, to a certain extent, was pretty standard from year to year because the only
thing that would change were the programs you worked on, so the approach was quite
similar from release to release.
Team meetings are also used to coordinate projects. However, few project managers regard
team meetings primarily as a way to coordinate the project. They are seen more as a way to air
issues or to discuss the project requirements or design issues.
5.4.3.4 Findings Project coordination is achieved by the majority of project managers through plan-based
mechanisms of product specifications and the project schedule. Phase reviews and test plans
were used but not as extensively as plan-based mechanisms.
The most popular standards based coordination mechanism, that of template work products, was
reported to be used by 50% of project managers. Compared to the reported use of other
mechanisms, such as schedules and specification, this does not represent a preferred
coordination mechanism.
Of the formal mutual adjustment mechanisms, the most favoured was the project team meeting.
The only other formal mutual adjustment mechanisms reported by more than 50% of project
managers was the ad hoc meeting. While other mechanisms were employed in some projects,
their use does not indicate a strong preference.
Analysis
Page 141
Informal mutual adjustment mechanisms were dominated by the informal conversation and by
co-location. Management by walking about (MBWA) was the least favoured coordination
mechanism.
As with both project monitoring and project control, project managers employ a portfolio of
project coordination mechanisms and do not constrain themselves to one or two mechanisms.
These findings will be discussed in the next chapter.
5.5 Organizational Distance This section will examine organizational distances within the projects in the research sample.
This addresses the second research question:
RQ2: Is there a relationship between the organizational distance between the
project manager and elements of the project team and the selection of project
management mechanisms?
Questions 23, 24 and 37 - 41 provided the data for this analysis.
Organizational distance was evaluated between the project manager and the most remote part of
the project that was still significant to the project. For example, if a project component was
being developed in Israel for a project in Sydney, then the organizational distance was evaluated
between Sydney and Israel even though the rest of the project may have been carried out in
Sydney. Similarly, if a project was being developed in Sydney but delivered and implemented in
Japan then, provided the implementation was part of the project responsibility, organizational
distance was evaluated between Sydney and Japan. The criterion for deciding if organizational
distance was involved was whether the remote activities were managed by the project manager.
For example, one organization developed products that were distributed throughout the world
but all development was performed in Sydney. Distribution, installation and maintenance were
not performed by the development team; so organizational distance considered only the
development activities in Sydney and organizational distance was evaluated as “close” or
“none” on a scale, shown in Table 40, of “none”, “close”, “close/medium”, “medium”,
“medium/distant” and “distant”. This is further discussed in Section 5.5.5.
Four factors were combined to assign an organizational distance to a specific project. The
factors were cultural distance, structural distance, administrative distance and relational quality.
The raw data are shown in Table 40 because the mapping from the factors of organizational
distance to the ordinal measure of organizational distance is not algorithmic but judgemental.
Each of the four factors is examined, then the deduced measures of organizational distance for
the sample are presented and discussed.
Analysis
Page 142
Table 40: Raw data for deducing organizational distance.
Proj
ect M
anag
er
code
Cul
tura
l dis
tanc
e
Stru
ctur
al
dist
ance
Tim
e zo
ne
diff
eren
ces
Leve
ls o
f A
dmin
istra
tive
dist
ance
Con
tract
or
outs
ourc
e
Esta
blis
h re
latio
ns
Mai
ntai
n re
latio
ns
Org
aniz
atio
nal
dist
ance
5 No None 10 No None 17 No None 25 No None 34 No None 78 No None 82 No None 23 Cont Close 52 Cont Close 57 Sydney Cont Close 70 Australia 1 OS Yes Close 24 Anglo Australia 0 Cont Yes Yes Close/medium 48 Anglo Sydney 1 OS Yes Close/medium 56 Far East Int’l OS Close/medium 59 Anglo Sydney Yes Cont Close/medium 74 Anglo Sydney 0 OS Close/medium 13 Anglo Int’l OS Yes Yes Medium 16 Latin
Europe Sydney Yes 0 OS Yes Yes Medium
49 Anglo Int’l 0 Yes Yes Medium 62 Far East Australia 1 OS Medium 11 Far East Int’l 0 Cont Yes Med/Distant 22 Far East Int’l Yes 1 Cont Med/Distant 30 Other Int’l Yes 1 OS Yes Yes Med/Distant 32 Far East Int’l 0 OS Yes Yes Med/Distant 46 OS Yes Med/Distant 67 Anglo Int’l 1 OS Yes Yes Med/Distant 72 Anglo Int’l Yes 0 OS Yes Yes Med/Distant 73 Latin
Europe Int’l 1 Cont Med/Distant
79 Anglo Int’l Yes 1 OS Yes Yes Med/Distant 94 Anglo Int’l Yes 0 OS Med/Distant 75 Far East Int’l Yes 0 Cont Yes Yes Distant 92 Far East Int’l Yes OS Distant
5.5.1 Cultural Distance Cultural distances were classified according to groupings of similar countries developed by
Hofstede (1983b) and synthesized by Ronen and Shenkar (1985). The distribution of projects
into national culture groupings is shown in Table 41. The data came from responses to question
24.
Analysis
Page 143
Table 41: Cultural distance between project manager and project sub-team.
Frequency Percent Australia - Anglo (US, UK, NZ, Canada) 10 31.3 Australia - Latin Europe (France, Spain, Italy) 2 6.3 Australia - Far East (Asia) 7 21.9 Other (Israel) 1 3.1 None 12 37.5 Total 32 100.0 Almost 40% of the surveyed projects did not involve any cultural distance. Of the remainder,
most reflect Australia’s trading partners rather than any form of historical association. The
distribution of different cultures would appear to be sufficient to reveal culture-related effects.
Although some project managers did not encounter many problems themselves stemming from
cultural distance, there was general acknowledgement that culture-based problems could occur.
It was a matter of expecting the problem and dealing with it when it arose. In some it was a
language issue but for others problems originated from differing world views or weltanschauung
(Checkland, 1981).
TM How much difficulty do you have communicating with the development team.
PM75 I’m pretty lucky. I’ve lived in Asia and don’t have any difficulties communicating with
the development team. I actually trust them greatly. … But I guess it’s each for their
own. I mean, somebody that I’ve worked very closely with and understand very well
may be totally misinterpreted by one of our Australian staff, and it often goes that path.
However, me personally, I don’t have problems.
TM So it’s reasonable to say that there are occasionally language problems, culture
problems.
PM75 With the company, yes. Depending how long a staff member of the Australian team has
been in place. It’s not the Malaysian team that misunderstands culture that easily. They
may misunderstand our cynicisms and sarcasms, but that’s more of the joking side. In
general we communicate fairly well. Our team is really developed over time and there is
a lot of occasions when we get to meet our colleagues in Malaysia and get to work close
together.
TM How difficult is it to communicate with the client organisation.
PM11 Varies. Where it concerns dealing with other parts of C19, perhaps the Canadian
partners, there are few language problems but some subtle cultural difficulties. When
dealing with the Japanese, there is obviously a language problem. But compounding
Analysis
Page 144
that are the differing cultural concepts. For example, in western insurance there is the
concept of a “death benefit” which has no direct equivalent in Japan. Something similar,
but not the same. There can also be problems of habits. Some of my analysts can get to
the point of asking for a “Yes, No” response to some question to which the Japanese are
reluctant to respond with a “Yes or no” and I have to drag my people out of there and
point out that pushing them isn’t likely to be productive.
PM72 There is a level of difficulty dealing with Israel. They’re coming from a totally different
culture. We’re very much into long term support whereas with Israel, if it works now
well, why worry about it. It’s just a totally different attitude.
The common theme is that there are culturally based differences in vocabulary, attitudes and
concepts, any of which could be the source of misunderstandings.
5.5.2 Structural Distance Structural distance, defined in Section 3.2.2, is concerned with the physical distance and, if it
was mentioned, time zone differences. Data for this construct came from responses to question
24.The distribution of structural distance between the project managers and project sub-teams is
shown in Table 42. In addition to the geographic distance, nine of the thirty-two project
managers mentioned time zone differences indicating that the most frequent effect of larger
distances was the difference in time zones. This was mentioned more often than travel or
logistical problems.
Table 42: Distribution of structural distances between project manager and sub-team.
Frequency Percent Within Sydney 5 15.6 Within Australia 3 9.4 International 15 46.9 No distance 9 28.1 Total 32 100.0 PM79 The problem with our internal team in that they’re in the wrong time zone. And so
getting up at, as I did this morning, to participate in a call. Someone was last night
staying late to talk to someone in their morning. There’s an annoyance in that. But it is
the primary frustration of a project manager that you can’t act as you would if they were
local.
Analysis
Page 145
TM How much difficulty do you have communicating with other parts of the organisation in
other countries.
PM30 OK, that will vary. Mainly on time zone. The hardest one to communicate with is the
States because it’s so different in time zone. So invariably you send an email, right, then
if you need to you’ll wake up or stay up till the middle of the night. … So generally the
hardest one is due to time zone in the States.
In general, project managers appear to be more affected by time zone differences than by
geographical distance. This implies that interactive communication, such as phone calls or
video-conferences, is needed sufficiently often, to manage reciprocal dependencies (Malone and
Crowston, 1994; Kumar and Dissel, 1996), and is not adequately replaced by non-interactive
communication such as email or bulletin boards.
5.5.3 Administrative Distance Indications of administrative distance were sought by asking about whether the project manager
had direct access to the project sub-team members or had to deal with an intermediary such as a
supervisor or another project manager. This was question 37 of the interview. The responses are
shown in Table 43.
Table 43: Incidence of administrative separation between project manager and distant sub-team members.
Frequency Percent Direct 24 75.0 via supervisor 8 25.0 Total 32 100.0
Some project managers found lack of direct access to the project team to be a problem but
others did not.
PM79 We always deal through a project manager, interface. Never through a developer. We
may have technical people talking to technical people, by arrangement. But in terms of,
we’re talking here in terms of project management, it would be through a project
manager.
TM How administratively removed are your, you call them vendors, from the project
managers and team leads? So, what project organization structure is used to manage
them.
Analysis
Page 146
PM32 While were still doing the pre-concept commit effort, then there’s dialogue with my
team for feasibility and those sorts of things. Once we’ve actually committed to
undertake the project, the model is that we, the vendor that we select for undertaking
that project, provides a team lead who reports to me. So that’s that person in the middle.
We have a couple of problems we’re trying to get around. The first one is we don’t want
the project managers going direct to our vendors because very few of our project
managers are technical. They have no idea whether they are getting the wool pulled
over their eyes from a technical point of view, they have no idea whether our vendor is
delivering something which is actually going to work on our infrastructure. So it’s very
important that we, as a technical team, have visibility into that project. On the other
hand, I don’t want all the communication between the project manager and the vendor
go through me or someone who reports to me, because I’ve often been a bottle neck. I
have lots of things that I’m involved in, so I don’t want it to be me. So what we tried to
do was to get the best of both worlds and have a vendor resource reporting to me and
answerable to me for the technical issues and yet still allow the project manager to have
direct contact with the vendor. And make that scalable by having that done for each
project. So each project has a team lead. Sometimes the vendor would use the same
person for two or three projects but potentially is scalable. I don’t have to go and hire
another person.
While most project managers had direct access to the members of the project team, even when
the task was outsourced, some did not. The main theme in responses to this question was that
project managers wanted direct visibility into, and control over, all project tasks. When they did
not have direct access to the outsourced team, it was mostly imposed by the outsource vendor
and not an initiative of the project manager.
5.5.4 Relational Quality Indications of relational quality were taken from relationship initiation and relationship
maintenance. Some project managers indicated that some activity was undertaken to initiate the
relationship or at the start of the project. This was distinguished from activities intended to
maintain the relationship such as site visits. The combination of the two gives an indication of
how many project managers recognized the need for relational quality and engaged in activities
related to it. The incidence of activities to establish a relationship and to maintain a relationship
were recorded separately and are displayed, combined, in Table 44. Data for this analysis were
gathered by reviewing the interview transcripts for specific mention of the activities in response
to questions 23, 24 and 37 – 41.
Analysis
Page 147
Table 44: Incidence of relational quality activities by project managers.
Frequency Percent Establish relationship 11 34.4 Maintain relationship 13 40.6
Establishing relationships between the project manager and an outsourced team tended to be
regarded as more important when the outsourced team was undertaking a major part of the
development or in some way could seriously affect the project’s outcome.
PM16 Well, there are issues. What we find works extremely well is, you start off with people
who are remote, you must have face to face meetings to start. One or more. So people
can get the body language, size up who they’re dealing with. But thereafter
teleconferences and email are perfectly OK. If people are going to be here anyway then
we arrange to meet but we never had an instance where we summoned people who were
remote. We always found we could work without that as being a frequent requirement.
PM75 Our team is really developed over time and there is a lot of occasions when we get to
meet our colleagues in Malaysia and get to work close together.
PM49 At the client end it is fairly rare to be dealing with a committee, or board or all those
sorts of things. That does happen, but it is fairly rare. The first thing that we try to do is
build a bit of rapport with the main contact on the site, … and as part of building that
rapport we try to find how that person likes to work, because at the end of the day what
is important to the client is, when the project is finished, that yes, it was profitable but
the client is happy and they’re ready to do something else. That’s normally what
happens. We end up saying we’ll see how these clients work.
On the whole, project managers recognised the need to establish and maintain relationships with
remote teams.
5.5.5 Organizational distance in the sample No algorithm was used to deduce a measure of organizational distance because it is difficult to
ascribe relationships between the possible combination of indicators or their absences. Rather,
the combination was reviewed for each project manager and a measure of organizational
distance decided based on the combination. Culturally different places tend to be structurally
distant so that those two factors tended to dominate the conclusion.
Analysis
Page 148
This research sets out to examine if the selection of project management mechanisms by project
managers differs depending on organizational distance so that some measure of organizational
distance is required. The measure need only be ordinal rather than interval. Since the specific
concept of organizational distance used by this research has not been used before, a new
measure was required. The resultant scale used five categories of distance, plus a “none” to
cover cases where no outsourcing or contracting occurred. Three categories would not have
given enough distinction between the different factors that combine to form the overall
organizational distance, and more than five appeared unnecessary.
The distribution of organizational distances is shown in Table 45. The data indicate a reasonable
spread of organizational distances within projects. Approximately one third of the projects
involved little or no distance, one third were medium or close-medium and approximately one
third were distant or medium-distant. This may reflect the composition of the sample where
multinational organizations make up more than 40% of the sample. Multinational organizations
would be more likely to engage in distributed development than small, local organizations.
Table 45: Organizational distance between project managers and the most distant part of the project team.
Frequency PercentNone 7 21.9 Close 4 12.5 Close-Medium 5 15.6 Medium 4 12.5 Med-distant 10 31.3 Distant 2 6.3 Total 32 100.0
5.6 The effect of organizational distance This section will examine the relationship between the choice of project management
mechanism and organizational distance. The second purpose of this analysis is to use
organizational distance to examine which project management practices are regarded as
essential so that some insight might be gained into project management aids and tools. If a
mechanism is used in all circumstance then it is likely to be regarded as essential for successful
project management whereas a mechanism that is used at some organizational distances but not
others, while not essential, has utility in some circumstances.
Analysis
Page 149
5.6.1 Project Monitoring The different project monitoring mechanisms employed by project managers were presented
and briefly discussed previously (Section 5.4.2). This section will examine relationships
between project monitoring mechanisms and organizational distance.
5.6.1.1 Structured interview data. The distribution of project monitoring mechanisms according to the organizational distance
present in the project is presented in Table 46. A Pearson test of correlation between
organizational distance and the different monitoring mechanisms does not reveal any significant
relationship, nor is there any significant correlation between organizational distance and the
total number of monitoring mechanisms used by each project manager (Table 47).
Table 46: Indicators of project progress grouped by organizational distance.
Project management mechanism Organizational distance Expert
judgmentProgress Earned
value Risks Defect list Test
statistics None 3 7 6 1 2 2 Close 4 4 4 1 2 Close-Medium 2 5 5 1 3 Medium 4 4 3 Med-distant 6 10 10 2 4 4 Distant 1 2 2 1 Total 16 32 31 4 13 9
Table 47: Pearson correlations between organizational distance and different monitoring mechanisms from structured interview data.
Organizational distance
Effect size
Progress Pearson Correlation 0.192 Small Sig. (1-tailed) 0.184 Earned value Pearson Correlation -0.224 Small Sig. (1-tailed) 0.147 Risks Pearson Correlation -0.500 Large Sig. (1-tailed) 0.333 Defect list Pearson Correlation 0.055 Sig. (1-tailed) 0.441 Test statistics Pearson Correlation 0.117 Small Sig. (1-tailed) 0.402 Count of monitoring Techniques
Pearson Correlation 0.015
Sig. (1-tailed) 0.472
Analysis
Page 150
5.6.1.2 Content analysis The transcripts were examined for evidence of different types of monitoring mechanisms that
were used by project managers. The classification of the monitoring mechanisms, as discussed
in Section 2.5, was by type rather than by the actual mechanism used.
Section 5.4.1 of this chapter discussed the different types of monitoring mechanism used and
will not be repeated here. This section will move directly to examining possible relations
between the monitoring mechanisms and the organizational distance involved in the projects.
Table 48 displays the frequency of the different monitoring mechanisms grouped according to
organizational distance.
Table 48: Number of monitoring mechanisms vs. organizational distance from interview content analysis.
Organizational distance
Automatic Formal Ad Hoc
Informal Total
None 12 24 4 12 52 Close 2 17 3 9 31 Close/medium 4 28 8 10 50 Medium 11 16 7 6 40 Med/Distant 14 52 17 16 99 Distant 1 11 0 5 17 Total mechanisms 44 148 39 58
Because there were a differing number of cases at each organizational distance category any
usage pattern could be difficult to discern. An alternative view would be the distribution of
monitoring mechanisms at each organizational distance category expressed as a percentage of
all mechanisms used within the organizational distance category (Table 49). While there are
some changes in the proportionate use of mechanisms, this could be an artefact of the low
sample size, particularly for the “Distant” category where there were only two cases.
Table 49: Monitoring mechanisms expressed as a percentage within organizational distance category.
Organizational distance Mechanism type
None Close Close-Medium
Medium Medium - Distant
Distant
Automatic 23 6 8 28 14 6 Formal 46 55 56 40 53 65 Ad Hoc 8 10 16 18 17 0 Informal 23 29 20 15 16 29 There is no strong evidence of a pattern of favouring one or other monitoring mechanism as
organizational distance changes (Table 50). Only one of the relationships achieved statistical
significance and the effect size of the relationship was medium rather than strong. That
Analysis
Page 151
relationship is between organizational distance and formal monitoring mechanisms and is
shown in Table 50.
Table 50: Pearson correlation between organizational distance and types of monitoring mechanisms.
Organizational distance
Effect size
Total automatic Pearson Correlation -0.005 Nil Sig. (1-tailed) 0.489 Total formal monitor Pearson Correlation 0.381* Medium Sig. (1-tailed) 0.016 Total ad hoc monitor Pearson Correlation 0.259 Small Sig. (1-tailed) 0.076 Total informal monitor
Pearson Correlation -0.045 Small
Sig. (1-tailed) 0.403 Count 32
** Correlation is significant at the 0.01 level (1-tailed).
* Correlation is significant at the 0.05 level (1-tailed).
5.6.1.3 Qualitative analysis When monitoring software development tasks at a distance, project managers did not
demonstrate any awareness of doing anything different. They spoke of using the same
mechanisms of formal reporting against scheduled milestones to check the project’s progress
supplemented with conversations with the remote team. None raised any issue of the costs of
monitoring remote project teams. However, several did raise the problem of dealing with time
zone differences. The most common issue that arose with regard to remote project teams was
that of ambiguous communications. One project manager was very conscious of the need to
clearly understand the nuances of what was being said.
TM Outsourced task monitoring. Same questions. But this time applying specifically to
outsourced or to remote tasks. As a project manager, how do you know that the project
is on track.
PM79 My strategy is learn carefully from the individual I’m dealing with on the way they
provide information and try to learn from their experience, their language, the way they
communicate information so we get some additional way of qualifying what
information you get. For example, my counterpart in the UK on the C49 project is a
very positive individual, positive applied to every sentence almost. (…) have had a few
problems but the positivity is now relevant factor in determining the information which
is coming through. There are other individuals which are much more overt when things
are going well or not going well. You can detect from the way they communicate
Analysis
Page 152
whether they are happy with where they are. I’ve learned to communicate whether they
are happy or not. I think there’s a bit more when things are at arms length. I certainly
want to get any indicator I can to alert whether we need to spend more time working out
things.
TM Do you use measures, objective measures like hitting milestones or task completions.
PM79 Absolutely. I mean, we track progress against a detailed schedule. We’re obviously
looking at the deliverables that are coming through on the date, on or before date. All
milestones get measured on baselined projects and tracked variance to the baseline. And
we revalidate future parts of the plan based on what we’ve seen previously. Whether it’s
as simple as a customer up front agreeing to review documents within five days but
halfway through a project we notice that every time they take 10 days. We’ll adjust the
plan by agreement.
Another project manager was very conscious of the communication problems that arose
between cultures more than problems that arose through distance.
TM When you get new people in Australia who haven’t necessarily lived overseas, there’s
some initial difficulty in communication.
PM75 Not so much from a western perspective. Like if we were dealing with other office that
wasn’t in Asia there wouldn’t be a problem. It’s more so the Asian perspective in that
you are dealing with Hong Kong Chinese, Singaporean, mainland Chinese, Japanese.
They’re all very, very different and they all get offended over each others actions. So
for a westerner to even pick one of those culture just by looking at a person, they
usually can’t. They haven’t had the experience of living with those people. In general.
And that does take time for anyone, really, to get a good grip on and to understand what
small things can really be blown up into big issues between people.
TM What is the most common way Australians put their foot in it?
PM75 They take people too literally. They forget people are speaking English as a second
language. They, their expectations might be different. Their expectations might be to be
straight-forward in saying “Yes” or “No”, or “We can” or “We can’t.” Where some
cultures are more so instead of saying “We can’t” and saying “We’ll try”. They are the
sort of things we run into a little bit. …. But once again, bring in an account manager to
explain and interpret, he then becomes more aware of what’s going on and more aware
of the hierarchy and the system over in Asia and who he should be speaking to and who
he shouldn’t be speaking to and how to communicate and what turnkey points, if you
like, to really get a result.
Analysis
Page 153
In summary, the project managers appear not to use different monitoring mechanisms when
dealing with distant project teams, but do vary the way the mechanism is used to, among other
things, remove misunderstandings.
5.6.1.4 Findings. The finding from structured interviews, content analysis and qualitative analysis is that
organizational distance does not favour any one monitoring mechanism over any other. There is
insufficient evidence to find that project monitoring practices vary as organizational distance
increases.
5.6.2 Project Control In this section, the use of project control mechanisms will be described and then examined for
evidence of relationships with organizational distance. Evidence will be taken from data
collected through structured interviews and through content analysis of the interview transcripts.
Conclusions will be drawn and briefly discussed on the question of project control mechanisms
varying with organizational distance.
5.6.2.1 Structured Interview data The structured interview sought information on the software development methods, measures of
project success, how the project is adjusted to cope with changing circumstances, information
on project meetings and on project reports. The main interest concerned how project managers
set project goals and then controlled the development in relation to those goals.
5.6.2.2 Behaviour Control The main methods of behaviour control were project planning with subsequent project control
using the plan, and using documented or standardised software development methods. The
usage of a software development methodology was recorded in terms of the formality of their
software development processes, or capability levels, as shown in Table 51.
Table 51: Software development capability levels related to organizational distance.
Organizational distance Total Process Capability
None Close Close - Medium
Medium Medium - distant
Informal 3 2 1 6 Managed 2 1 1 3 1 8 Defined 3 2 5 5 2 17 Optimizing 1 1 Total 8 5 6 9 4 32
Analysis
Page 154
If organizational distance was related to the formality of software development methods then
more distant organizations would have used more mature processes and the table would have
shown a pattern of lower numbers toward the top left and higher numbers toward the bottom
right. A Pearson Chi-Square test did not indicate any relationship between software
development capability level and organizational distance.
Information on project planning and schedule planning was sought in separate questions
(questions 8, 12 and 15 for planning, 13 for schedule) even though some project managers may
regard the schedule and the project plan as the same thing. The intent was to investigate whether
they were regarded as different things and how seriously each was treated. Pearson’s Chi-
Square test showed a significant correlation between the formality of project planning and
organizational distance (p = 0.016) as shown in Table 52 but not between the formality of
schedule planning and organizational distance (p = 0.139) as shown in Table 53. To check on
confounding variables, possible relationships between project planning formality and
organizational size and organizational process capability were tested using Pearson’s Chi-
Square. Neither showed a significant relationship leading to the conclusion that any relationship
between project or schedule planning and organizational distance is weak.
Table 52: The formality of project planning distributed over organizational distance.
Project planning Organizational distance Total None Close Close -
Medium Medium Medium -
distant
Informal and minimal
2 1 1 4
Formal but not extensive
5 1 2 8
Formal and extensive
1 3 6 8 1 19
Depends on the project
1 1
Total 8 5 6 9 4 32 Project plans are distinguished from project schedules because project plans cover such areas as
quality management, budget, risk management, communication management, procurement and
possibly human resource management whereas a project schedule expressed the expected
schedule of tasks required to complete the project.
Table 52 shows the popularity of formal and extensive project planning, with 19 out of 32
project managers, more than half, indicating that level of project planning. However, although
Table 53 shows that 11 out of 32 project managers believe their schedule planning is “formal
and extensive”, this is significantly less than the same choice regarding project planning.
Analysis
Page 155
Other indications of behaviour controls, such as corrections to the project plan, were checked
for statistically significant relationship with organizational distance but none were evident. Use
of a project schedule and project meetings were so pervasive that it is not a good discriminator
of behaviour control mechanisms employed at differing organizational distances.
Table 53: Formality of schedule planning distributed over organizational distance.
Schedule planning
Organizational distance Total
None Close Close - Medium
Medium Medium - distant
Informal and minimal
4 1 1 1 7
Gantt chart 1 1 Formal but not extensive
3 2 3 1 9
Formal and extensive
1 1 6 2 1 11
Depends on the project
1 2 1 4
Total 8 5 6 9 4 32
5.6.2.3 Output Control Output controls are those that can be applied without knowledge of how the results were
obtained (Ouchi and Maguire, 1975). Evidence of output control was sought directly through
soliciting criteria by which projects would be judged successful (Question 8). The common
criteria of adhering to budget and schedule, and delivering the expected functionality were
augmented with “quality levels” and “political success”. The most commonly suggested
additional success criteria was “customer satisfaction”, which sometimes determined the project
manager’s bonus. Projects may be regarded as a success after their completion (Linberg, 1999)
but what was sought was known criteria that the organization used to determine project success.
The frequencies of these success criteria are displayed in Table 54. This information was
previously presented in Table 33 and is duplicated here for convenience.
Table 54: Frequency of project success criteria.
Count Percent Schedule 29 90.6% Budget 28 87.5% Functionality 20 62.5% Quality 17 53.1% Customer Satisfaction 19 59.4% Political 11 34.4%
Analysis
Page 156
Pearson’s Chi-Square test did not reveal any relationship between organizational distance and
any of the success criteria. Nor was there a relationship between the number of success criteria
used by any one project and organizational distance.
5.6.2.4 Input control Information on input control was sought through question 25 of the interview (Appendix A).
Input control is exercised through recruiting and training rather than determining behaviours or
measuring outputs. The data do not indicate any correlation between organizational distance and
training, specifically training in software development or project management methods (Table
55).
Table 55: Potential correlations between organizational distance and input control.
Organisational distance
Outsourcee training Pearson Correlation
0.216
Sig. (2-tailed) 0.346 N 21
** Correlation is significant at the 0.01 level (2-tailed).
While general or project specific training is frequently performed, there is no evidence that this
is correlated with organizational distance.
5.6.2.5 Content Analysis The transcribed interviews were examined for evidence of output, behaviour, input or clan
controls used on the project as a whole. No distinction was made between a control mechanism
mentioned in the context of general project management or in the context of specific aspects of
the project such as a local or outsourced project sub-team.
The frequency of the different types of control mechanisms was displayed in Table 34.
To determine whether or not there was any relationship between the types of control and
organizational distance, the total number of controls was recorded for each organizational
distance category (Table 56). Since there are an unequal number of cases in each organizational
distance category, it is difficult to determine whether or not one type of control mechanism is
preferred as organizational distance varies. Such a preference, if there is one, would be easier to
determine if the controls employed in each organizational distance category were expressed as a
percentage of all controls employed within the same category (Table 57).
Analysis
Page 157
Table 56: Distribution of the number of each control type across organizational distances.
Type of control mechanism Organizational distance
Output Behaviour Input Clan Sum
None 12 12 1 14 39 Close 10 6 0 9 25 Close/medium 16 12 2 12 42 Medium 13 12 5 10 40 Med/Distant 31 25 8 17 81 Distant 10 3 1 1 15
Table 57 displays potential differences that bear further investigation. The count of control
mechanisms is higher for the medium-distant category but relatively equal for all other distance
categories except “distant” which is significantly less. A test of correlations between
organizational distance and control mechanisms (Table 58) reveals a statistically significant
relationship between output control and organizational distance, and between input control and
organizational distance; that is, between the total number of output controls employed by a
project manager and organizational distance, and between the total number of input controls and
organizational distance.
Table 57: Distribution of control types expressed as a percentage within an organizational distance category.
Type of control mechanism Organizational distance
Output Behaviour Input Clan
None 31 31 3 36 Close 40 24 0 36 Close/medium 38 29 5 29 Medium 33 30 13 25 Med/Distant 38 31 10 21 Distant 67 20 7 7
Table 58: Pearson correlations between organizational distance and control mechanism.
Organizational distance
Effect size
Total Output control Pearson Correlation 0.548** Large Sig. (1-tailed) 0.001 Total Behaviour control
Pearson Correlation 0.272 Small
Sig. (1-tailed) 0.066 Total Input control Pearson Correlation 0.324* Medium Sig. (1-tailed) 0.035 Total Clan control Pearson Correlation -0.225 Small Sig. (1-tailed) 0.108 Count 32
Analysis
Page 158
** Correlation is significant at the 0.01 level (1-tailed).
* Correlation is significant at the 0.05 level (1-tailed).
These relationships should be treated with caution since the number of cases in the different
categories of organizational distance, particularly the “distant’ category, is small with only 2
cases. Despite this, the relationship between output control and organizational distance agrees
with theoretical expectation that increased organizational distance favours the use of output
control (Section 3.3). However, the theoretical expectation that larger organizational distances
should favour clan control (Section 3.3) was not realised.
5.6.2.6 Qualitative analysis Very few project managers said that their organizations expected the outsourced organization to
implement specific software development methods, nor give any other indication of controlling
how the outsourced organization performed their work. Instead, the outsourced vendor was told
what was required then given full responsibility to produce it. The delivered work was checked
on delivery, usually by one form of testing or another. A common theme emerged when project
managers were asked how they knew that the delivered work had met the requirements. This
produced a range of responses from specific testing on delivery to relying on integration or
system testing to expose any shortcomings in the delivered product. None of these responses
indicated that distance was a factor. Typical of the responses was:
TM How do you know the outsourcee’s developer has met the requirements.
PM32 Code reviews, user acceptance testing. We don’t, probably don’t go to the point of
having a compliance matrix and going, formally going back and saying has every single
requirement been mapped against a particular test. Our testing is not that rigorous. But it
is user acceptance testing which is really running through all the main functions of the
application and validating the accuracy of the results that might deal with financial tools.
Another, similar, response was:
PM70 Because as part of the contract, key deliverables were monitored against and signed off.
There was a schedule they were monitored against and we had user acceptance testing
to certify that it has been done.
In summary, projects were controlled using similar mechanisms regardless of any distance
involved. Unlike project monitoring, project control did not appear to require any change in how
they were used to cope with cultural differences or time zone differences.
Analysis
Page 159
5.6.2.7 Findings Output controls are favoured as organizational distance increases. Other relationships were
insufficiently strong to support any conclusions. The differing uses of the project constraints,
project plan and its associated project schedule dominate the control mechanisms as
organizational distance increase. This indicates that, while clan control was employed in all
projects through co-location and informal conversations, increasing organizational distance
requires more formal project control mechanisms.
The one clear relationship between organizational distance and a control type was that of output
control. Given that the “distant” category has only two cases, the finding would need to be
proven over a much larger sample.
Overall, it appears that project managers do not vary their use of control mechanisms as
organizational distance increases. As with project monitoring mechanisms, this implies that the
control mechanisms are sufficiently robust to cope with changes in organizational distance or
that project managers are unaware of alternatives.
5.6.3 Project Coordination In this section, the usage of project coordination mechanisms will be described and then
examined to determine if different coordination mechanisms are employed at differing
organizational distances. Evidence will be taken from data collected through structured
interview and through content analysis of interview transcripts. The findings will be discussed
briefly below.
5.6.3.1 Structured interview Evidence of the use of different coordination mechanisms was sought through questions related
to project planning (questions 8, 12 and 15), schedule planning (question 13), adjustments made
to the project arising from unforseen difficulties (questions 18--20), and through the topics
discussed at team meetings (questions 21 and 22). The frequency with which these mechanisms
were used was illustrated in Table 35, Table 36 and Table 37.
5.6.3.2 Project and schedule planning It was assumed that all project managers planned the project and schedule in some way, and
asked about the level of formality with which this was done. The level of formality was assessed
at one of:
• No planning
• Informal and minimal
Analysis
Page 160
• Gantt chart and budget
• Formal but not extensive
• Formal and extensive
Since these are nominal categories, relationship with organizational distance was tested using
the Chi-Square test. There was no significant relationship.
5.6.3.3 Adjusting the project Project managers were asked how they adjusted the project if, and when, a task is taking longer
than planned. That could happen if the task was more difficult than expected, if the task required
more expertise than was available, if it was delayed by another task or any one of many reasons.
The responses are expressed as a binary “Yes/No” depending on whether the particular action
was undertaken or not. Since the number of cases for each organizational distance category is
unequal, the total number of responses would be misleading. Instead the responses are
expressed as a percentage of all responses for the action (Table 59).
Table 59: Adjusting the project in response to task completion delays. Expressed as a percentage of all responses for the action.
Organizational distance
Nothing Add resources
Descope Reassign scope
Other
Close 37.50 13.33 25.00 16.67 14.29 Close - Medium 33.33 33.33 33.33 42.86 Medium 37.50 40.00 33.33 41.67 35.71 Medium - distant 25.00 13.33 8.33 8.33 7.14
Table 59 does not show any pattern of favouring any particular action as organizational distance
varies.
5.6.3.4 Project meetings Project managers were asked if they held regular project team meetings, formal management
project reviews, distributed a project report to management and held regular meeting with the
customer. During such meetings, it is normal to discuss the state of the project and to decide on
actions to be taken to adjust the project in some way so that the workload is balanced or
progress is maintained. Several project managers distinguished between a management review
of the project and project gate reviews6. The frequency with which the differing project
meetings and review are held is illustrated in Figure 17.
6 Gate reviews are held at differing stages of the project to determine if the project should proceed to the next phase or be stopped. Often they are a formal and searching review conducted by senior managers of the organization intended to assess the business case for the project. Common stages of the project to conduct gate reviews are:
• at the end of marketing investigation intended to evaluate the potential market and to develop the product
Analysis
Page 161
As can be readily seen in Figure 17, almost all (29 of the 33 projects) projects have regular
project team meetings. There was no detectable relationship between any of these review
mechanisms and organizational distance.
Figure 17: Number of projects that use different forms of meetings and reviews.
5.6.3.5 Content analysis As with monitoring and control mechanisms, potential relationships between coordination
mechanisms and organizational distance were examined by reviewing the distribution of
mechanisms at each category of organizational distance (Table 60). The data in Table 60 shows
that plan-based coordination and formal mutual adjustment coordination (reviews, formal
meetings) are the preferred coordination mechanisms, with informal mutual adjustment the next
most popular. Automatic coordination mechanisms such as a CSCW, configuration management
tool or workflow tool were less popular. This could reflect the expense of setting up such tools
for what could be a relatively small project.
Table 60: Frequency of coordination mechanism vs organizational distance.
Organizational distance Type of coordination mechanism
None Close Close - Medium
Medium Medium - Distant
Distant
Automatic 12 2 4 11 14 1 Standards based 7 4 6 7 11 0 Plan Based 18 13 17 13 38 6 Formal mutual adjustment 18 13 17 13 38 6 Informal mutual adjustment 17 14 13 12 27 4
concept
• at the end of initial project planning intended to estimate the project schedule, budget, technical risk • at the end of high level design when there is a clearer understanding of the technical feasibility and risk • at the end of development to assess the product fitness for release and to reassess the market • at the end of the trial installations, sometimes also called Beta testing.
Each review is a gate through which the project must pass, or be cancelled.
0 5 10 15 20 25 30 35
Project team meeting
Management project meeting
Management report
Project gate reviews
Customer meetings
Number of projects
Analysis
Page 162
Changes in coordination mechanism usage with varying organizational distance are difficult to
detect by reviewing the frequency because the number of samples in each organizational
distance classification is unequal. A better indication would be determine if there were
significant changes in distribution of mechanisms within each organizational distance category.
Such a distribution is displayed in Table 61 and shows that there is a potential change in the use
of standards-based coordination mechanism. However, the number of standards-based
mechanisms recorded is low and insufficient to clearly indicate a significant change. There is no
clear indication that, for example, plan-based or automatic coordination mechanisms are
preferred over coordination by informal mutual adjustment.
Table 61: Coordination mechanism usage as a percentage of mechanisms within each organizational distance category.
Organizational distance Type of coordination mechanism
None Close Close - Medium
Medium Medium - Distant
Distant
Automatic 17 4 7 20 11 6 Standards based 10 9 11 13 9 0 Plan Based 25 28 30 23 30 35 Formal mutual adjustment
25 28 30 23 30 35
Informal mutual adjustment
24 30 23 21 21 24
This lack of relationship between organizational distance and coordination mechanism is shown
by the lack of any significant correlation (Table 62).
Table 62: Correlations between organizational distance and the number of coordination mechanisms employed.
Organizational distance Pearson Correlation -.043 Sig. (1-tailed) .407
Total Standards based coordination
Count 32 Pearson Correlation .253 Sig. (1-tailed) .081
Total plan based coordination
Count 32 Pearson Correlation .253 Sig. (1-tailed) .081
Total formal mutual adjustment
Count 32 Pearson Correlation -.042 Sig. (1-tailed) .411
Total informal mutual adjustment
Count 32 The correlations shown in Table 62 are not as uninformative as they might first appear. The
significance of the correlations between organizational distance and plan-based and formal
Analysis
Page 163
mutual adjustment coordination is 0.081 for both, whereas the significance for correlations
between organizational distance and standards-based and informal mutual adjustment are both
close to 0.4. This indicates that there may be some relationship between plan-based and formal
mutual adjustment coordination mechanisms and organizational distance but this research was
unable to establish it, and that further research is highly unlikely to find any relationship
between organizational distance and standards-based or informal mutual adjustment.
5.6.3.6 Qualitative analysis In this sample, the main coordination mechanism appears to be the project schedule that is
decided on during project planning. Project management coordination activities, once planning
is complete, seem mainly to be concerned with relatively minor adjustments designed to retain
both progress through the schedule and the component production and integration decided on
and expressed in the work breakdown structure.
There was little indication that standards or standard work practices play any significant role in
coordinating software development projects. Clearly components must integrate and interface so
there must be some agreement about their interfaces. These may have been expressed in the
design or in the contract terms and conditions, yet most project managers said that design
responsibility rested with the outsourced developer and not with their own team.
Coordination actions by the project manager were brought out in response to being asked what
they did to overcome task slippages. For the most part, project managers tried to retain the
original schedule by speeding up the work on the task, or by moving some of the work to
another part of the project. It was noticeable that most project managers did not restrict
themselves to one particular action but would react according to the circumstances. The
following extract illustrates this point well.
PM67 I would personally look at it if there was a late running task. Is it an issue with the skill
of the person dong that work? Is it an issue with the will of the person doing that work?
Is there, does that person need additional help. Could we break it down into further
smaller tasks and can we assign somebody else to recover that delay? If that particular
task is going to be delayed, is it on the critical path. What other knock-on effects is this
going to have? If it is not going to have knock-on effects and it is not on the critical path,
you might let it delay. But if it does have knock-on effects, you start to worry about
how you are going recover this slippage? How long is the slippage, first? Is it just a
couple of days? Is it a couple of weeks? If it is just a couple of days, you might say OK,
we might be able to work overtime. We might be able to work on the weekend and
catch up this particular delay.
Analysis
Page 164
TM No. It’s critical and it’s significant.
PM67 If it’s critical and it’s significant, then of course there seems to be some bigger planning
glitch. If suddenly we find out that instead of doing this we have to do something else,
which will have some four week hit on the project, as far as business is concerned, if it
is a technical problem, it is just unacceptable. So we need to start thinking about what
are going to be my alternatives. Can I put in a short term solution in place? Can I put in
a day one solution which can do the trick and follow that up with a more robust cleaner
solution. There is no rocket science here. There is no fixed formula that one can follow.
But there was seldom any mention of the need to alter what one group was doing to match a
change in what another group was doing. Only one project manager made specific reference to
the need to coordinate work of a distributed project team. Their approach was to minimise the
problem by structuring the work within iterative releases.
PM11 Well, I suppose there’s various times that you identify that that can happen. In the
design phase and so on. OK, small projects, it’s quite easy because you’ve got everyone
together and you can get it through. Projects that I’ve got on right now, I’ve got about
19 employees in all different locations all around the world. Extremely difficult to know
that function A is not going to affect function Y that’s been developed somewhere else.
Typically we do it through our cascading method. I don’t know if cascading is the right
word. But we have a structured release methodology that we’re using for this project.
We don’t use it for every project. And so, first we do security issues, then we do client,
and we know “client” stands alone. And then we do “new business” which uses the
previous release and so on and so, for each release we have its own project plan and its
own development schedule, and part of that schedule is a design review. And so, in
theory, it doesn’t always work in practice, but in theory when you review the design for
phase 3 it’s not going to affect anything in phase 2 or 1 because that’s the way our
system is modularised.
This implies that other project managers and project teams coordinated a changing project
through mutual adjustment using either formal mechanisms such as team meetings and design
reviews or through informal mechanisms.
5.6.4 Findings. There is no evidence of a relationship between organizational distance and the use of project
management mechanisms despite the strong theoretical expectation, expressed in Table 17, that
such a relationship would be found. Project managers continued to use a portfolio of
Analysis
Page 165
coordination mechanisms that utilise coordination mechanisms from all types of mechanisms.
This finding will be discussed further in the next chapter.
5.7 Conclusion The data have been analysed in three different ways: using quantitative analysis on the
responses to interview questions, using quantitative analysis of the content of the interview
transcripts and using qualitative analysis of the interview transcripts.
The analysis findings have been presented at the end of each section of the analysis and will be
discussed further in the next chapter. The analysis revealed which mechanisms project managers
prefer in order to monitor, control and coordinate their software development projects and that
they used portfolios of mechanisms rather than a single mechanism. The finding that there was
no evidence that project managers favoured different project management mechanisms as
organizational distance increases was unexpected and will be discussed in the next chapter.
Page 166
6 Discussion The previous chapter analysed the quantitative data, data from content analysis and qualitative
data from the interview transcripts to produce some findings for each of the research questions
being investigated.
The first research question was “Which mechanisms do project managers use to monitor,
control and coordinate software development projects?” Data gathering and analysis sought to
identify which project management mechanisms were used by project managers. It was found
that some project management mechanisms are used more frequently than others. In some cases
the usage pattern was quite distinct. A finding that was not anticipated was that project
managers employ a portfolio of mechanisms rather than relying on a single mechanism. For
example, a project manager does not rely on project meetings to monitor the project but will use
multiple mechanisms to monitor the project.
The second research question was “Is there a relationship between the organizational distance
between the project manager and elements of the project team and the selection of project
management mechanisms?”. This was investigated to identify which project management
mechanisms project managers find essential, which are favoured in some circumstances and not
others, and which are used but not essential. The analysis did not reveal any relationship
between organizational distance and the use of project management mechanisms. This finding
was unexpected because nothing in the literature on project management suggested it.
The findings will now be discussed and conclusions drawn about the use of project management
mechanisms in software development projects.
6.1 Project monitoring Project managers favour formal and informal monitoring mechanisms over automatic or ad hoc
monitoring mechanisms. The most familiar monitoring mechanism is the weekly project review
meeting with the development team that reviews the schedule and milestones as well as other
project issues. There is little evidence of adopting such automated tools as CSCW or workflow
systems but some evidence that iterative development is being used with its frequent release
cycles permitting a form of automatic monitoring. Informal monitoring through conversations
Discussion
Page 167
with the project team and with the customer is widely practised. One of the unexpected findings
is that many project managers that use schedule and milestone tracking to monitor the general
state of the project but supplement this with ad hoc “drill down” enquiries whenever there are
any slippages or even threats of slippages. Such an early warning system of monitoring would
appear to be an inexpensive and unobtrusive way to monitor the project and react quickly when
needed.
6.1.1 Early warning systems The analysis clearly showed that project managers used the formal project monitoring
mechanisms as a warning system to indicate that something needs further investigation. If any
alarm was triggered in the mind of the project manager then ad hoc monitoring was initiated in
the form of a specific inquiry or something more formal like a project audit. This is an efficient
way to monitor any project. If the formal monitoring does not need to gather a lot of information
then it can be pared down to only that which indicates the health of the project rather than
having to include information that would indicate all the possible causes of ill health. Causes of
“ill health” can be sought through a more directed inquiry that needs only involve those directly
concerned with the particular problem and not the entire project team.
6.1.2 Multiple sources of information Project managers tended to use multiple sources of information about the same aspect of the
project. Mostly this was the project’s progress, which could be measured reasonably clearly, but
also included less measurable attributes, such as the project’s health. This indicates that multiple
sources of information will be sought to overcome information uncertainty. If the data cannot be
readily verified by the project manager, then multiple sources of the same project attribute will
triangulate the information, thus reducing uncertainty. If the project or product attribute is
difficult to measure, then multiple related measures will tend to reduce the inaccuracy of single
measures. For example, it is difficult to monitor a single project characteristic that would
indicate the health of the project and the probability that it will be completed on schedule.
Instead, several measures are sought that can collectively indicate the project’s health. This
research did not pursue this apparent relationship between information uncertainty and the
number of information sources. That will be left for further research.
6.2 Project Control Project managers use a portfolio of controls (Choudhury and Sabherwal, 2003) that include
output, behaviour and clan controls. These are oriented toward the common project constraints
Discussion
Page 168
of budget, schedule (completion date) and functionality. They would normally be stated at the
outset of the project and used to determine the project’s feasibility before planning. The project
plan and detailed schedule that sets out the work breakdown structure and task allocation is
ubiquitous. It seems to be so much a part of project control that its use tends to be assumed.
Input control, that is control by selecting the project manager or project team appears to be the
least favoured control mechanism. Similarly, exercising input control by training the project
manager or project team is also not favoured.
Control by co-location, informal conversation and even site visits appears to be frequently used.
However, neither the structured interview nor the content analysis investigated the
communication purpose. Informal communication using phone, email or casual conversation
could have been for a number of purposes that have no direct connection to forming common
goals and objectives.
All project managers readily identified the criteria by which projects were judged successes and
all used some form of specification to describe what was expected of the development. For the
purposes of control mechanisms, broad requirements, detailed requirements and functional
specifications are all used for the same purpose – to detail what must be done without
prescribing how it must be done. These output controls and those in the “other output control”
section are controls imposed on the project by its sponsors and do not originate from the project
manager. However, when dealing with an outsourced sub-project, the project manager can
devise output controls of their own to guide the sub-project.
6.2.1 Preferred control mechanisms What is notable about the controls is the dominant use of the project work breakdown structure
and schedule, commonly referred to as the project plan. All project managers used some form of
schedule based plan whether this was a simple “to do” list or a more elaborate project plan
contained in a tool such as Microsoft Project.
With all the range of controls available, only a few are employed to any great extent. Control
mechanisms used significantly more than other forms of control were: the main project
objectives that would be part of the project’s charter, development processes, a project plan, co-
location and informal communications. Of the possible controls, team selection would seem to
be used, but either not thought important or not drawn out by the research data gathering. Given
the concentration on recruiting software development personnel with specific skills that is
Discussion
Page 169
evident through the press7 or the number of recruitment agencies that concentrate on the
software development industry or the common practice of preparing a request for proposal
(RFP), it is clear that control by recruitment is practised.
The portfolio of controls did not vary significantly over the organization size, project size,
organizational process maturity or any other organizational or project attribute. This implies that
the common portfolio of controls is very robust and widely applicable.
6.3 Project Coordination Although there is clearly a preference for some coordination mechanisms over others, most
available mechanisms are used. The coordination arising from the more formal aspects of
project management, the specifications and the project schedule, appear to be almost universally
used.
As with both monitoring and control, project managers employed several project coordination
mechanisms. The plan-based mechanisms dominated but formal mutual adjustment and
informal mutual adjustment were strongly supported.
This research indicated that more than 80% of all project managers used a project schedule and
adjusted the project using the schedule, and all project managers used specifications to
coordinate how the work was partitioned then integrated. Such significant usage of two different
mechanisms in the one category of coordination mechanisms indicates that plan-based
coordination may have some advantages over other forms of coordination.
Coordination by formal mutual adjustment was most frequently achieved through project team
meetings. Reviews, whether formal reviews of the project or internal design and code reviews,
were not as frequently employed. The popularity of project team meetings is unsurprising since
the interview questions asked specific questions about them whereas no questions sought
information on design rules or interface specifications.
Of the informal mutual adjustment coordination mechanisms, the most frequently employed was
personal conversation. This research did not seek the purpose for conversations, so further
research is recommended to investigate the varying usage of project management mechanisms.
Aside from conversations, the most popular information coordination mechanism was to co-
locate the development team. Different forms of co-location were employed. Locating the entire
7 In Sydney there are three daily newspapers. Of these, two have an IT supplement on one weekday which normally includes a selection of jobs. Additionally, the Saturday edition of all newspapers frequently features a number of IT-related jobs.
Discussion
Page 170
development team close together and locating the development team on the customer’s premises
were the most common forms of co-location.
6.3.1 Managing dependencies Although this research regarded coordination as more than “managing the dependencies
between activities” (Malone and Crowston, 1994), it is opportune to discuss the different types
of dependency between activities and how they are managed.
Different types of dependency require different coordination mechanisms. The work breakdown
structure expressed in the development schedule specifies sequential dependencies, pooled
dependencies and mutual dependencies. Sequential dependencies exist between different parts
of the development process, between the requirements and the design for example, and between
different product components. Pooled resource dependencies occur when the one developer
must complete several tasks or when there are a limited number of resources such as software
licences. The project schedule can express and resolve both sequential and pooled resource
dependencies but can’t resolve mutual dependencies. These are resolved by interaction.
Accepting that different types of dependency require different coordination mechanisms
provides an explanation for using a portfolio of coordination mechanisms, together with some
insight into its probable composition.
6.4 Portfolios of mechanisms A recurring theme from the analysis is that project managers did not rely on one mechanism but
employed a portfolio of mechanisms. This echoes Sabherwal (2003) and Choudhury and
Sabherwal (2003) who were investigating how the mechanisms of coordination and the
mechanisms of control evolved with the project. Project managers did not rely on a weekly team
meeting to monitor the project but supplemented that with informal conversations, progress
reports from the team members, information gleaned from ad hoc project reviews and audits and
possibly other sources. Project control and project coordination showed the same use of multiple
mechanisms. There are several possible explanations for this. The first is that the effect of a
single mechanism is uncertain, the second that the scope of a single mechanism is insufficient
and the third is that mechanisms differ in their responsiveness to events.
The use of multiple monitoring mechanisms has already been discussed (Section 6.1.2). A
single monitoring mechanism or a single source of data will not necessarily convey accurate
information. Multiple views of the same aspect of the project help to verify the information
being received, help to clarify project attributes that are difficult to measure or to articulate and
help to indicate the accuracy of the information. Similarly, a single control mechanism may not
Discussion
Page 171
be completely effective. Relying only on contract terms and conditions, especially heavy
penalties for late delivery, will not necessarily ensure that the development will be completed
according to the contract. Nor is it advisable to rely solely on the project schedule to coordinate
the development and subsequent integration of the product components. The schedule does not
convey sufficient information to achieve the precision of interworking.
A single monitoring mechanism, such as a project team meeting, covers a limited range of
information. Their structure and formality precludes delving into details that may take days to
uncover. Their formality also precludes discussing sensitive information. Control mechanisms
also each have a limited scope. An output control, such as a specification, does not usually
describe how the various components are to be integrated, nor are they usually able to convey
the context of a particular requirement. People who work with telecommunication software
know that the software must operate unattended and uninterrupted for years. This is something
that is part of the value system in the field of embedded systems. It is not specified throughout
the specifications because it is a pervasive, unstated requirement that becomes part of the clan
control. A schedule can help to coordinate the development but cannot convey the precision
with which components must be developed. That requires interaction among the developers
particularly when the components are mutually dependent (Kraut and Streeter, 1995).
Mechanisms differ in their responsiveness and flexibility. In general, the more formal
mechanisms give a necessary structure to the project but are less able to adapt to changing
circumstances whereas the less formal mechanisms can adapt quickly but do not support the
structure quite so well. Project schedules convey a lot of information about how the whole
project is to be conducted but cannot react to frequent and minor changes of circumstances. On
the other hand, informal conversations between developers can resolve schedule conflicts
efficiently but those same conversations do not convey the detail of the overall project with the
same precision as a project schedule.
This research has followed the lead of previous researchers by considering project management
mechanisms in three separate categories. In practice, project managers don’t separately monitor
or control or coordinate a project in the same way that they would separately hold a meeting or
review the project schedule. Instead, the same mechanism is used to achieve different objectives.
This becomes evident when the classifications of the different mechanisms are viewed together.
For example, a project schedule can be used to monitor the project, as a type of behaviour
control and as a type of plan-based coordination mechanism. Table 63 summarises the interview
transcripts showing how many project managers used a particular mechanism and an indication
of the different objectives of monitoring, control or coordination served by the same mechanism.
Discussion
Page 172
Table 63: Different project management mechanisms showing the usage frequency and different objectives each might serve.
Usage Count
Monitoring Controlling Coordination
Specification 32 √ √ √ Schedule/Plan 32 √ √ √ Team meetings 30 √ √ √ Co-location 29 √ √ √ Status reports 28 √ √ Informal conversations 27 √ √ √ Other meetings 24 √ √ √ Ad hoc inquiries 20 √ √ Site visits 19 √ √ √ Customer satisfaction ratings
18 √
Goals and objectives 12 √ Change control committee
11 √ √
Design reviews 10 √ √ √ Recruitment or training 10 √ Sign-offs, phase reviews 9 √ √ Interface specifications 7 √ Audits 6 √ √
Tempting as it may be to deduce that project managers choose particular mechanisms because
they efficiently achieve multiple purposes, this is not justified by the data. There has not been a
rigorous analysis of different project management mechanisms nor any empirical data on how
any one mechanism is used by a project manager. However, that is a promising line of enquiry
for future research.
6.5 Organizational Distance Examining relationships between organizational distance and the selection of project
management mechanisms did not help discern which coordination mechanisms are essential to
software development project management. Indeed, organizational distance added no
knowledge to that already known from earlier analysis of the types of coordination mechanisms
employed by project managers (Section 2.7). There are several possible explanations for this.
• Existing project management mechanisms are sufficiently robust to tolerate the degree
of stress introduced by the organizational distances sampled in this research.
• Identified contingencies are not as significant in the choice of project management
mechanisms as originally thought.
Discussion
Page 173
• Project managers in the sample were unaware of any alternative ways in which to
manage their project.
• Variation exists but is at a lower level than the choice of mechanism.
These possibilities will be discussed below.
6.5.1 Robustness In an earlier section, the efficiency of a range of mechanisms was discussed (Section 6.4 ) and it
is evident that the more popular project management mechanisms such as project plans, product
specifications and co-location are useful in all three categories of monitoring, controlling and
coordinating projects. In particular, the use of specifications, schedules, team meetings, co-
located development and the various forms of personal conversation are so entrenched as
standard software development practices that their use becomes almost assumed as, indeed, this
research did.
Given that their use is so prevalent, organizational distance may only alter the expected form the
mechanisms would take but not the existence or use of them. One organization may express the
specification in more detail than another or may express it using formal methods, but all will
have some form of specification. An organization may express the schedule as a collection of
milestone dates while another may have a detailed Gantt chart. Team meetings can be held in
person or supplemented by phone or video-conference. None of the mechanisms have a single
form and all are able, in some way, to be adapted to the circumstances. For example, an entirely
co-located team may hold project team meetings in the one room. But a dispersed team could
hold a project meeting where those who can attend do, and those that cannot attend phone in.
Although much can be made of the need for rich media (Daft and Lengel, 1986; Muller, 2003) it
appears that project team meetings can function without face-to-face interaction. This is not to
say that any one of the mechanisms is robust enough to cope with increased organizational
distances but that the portfolio of mechanisms is collectively robust enough. It could be that as
organizational distance increases shortfalls in team meetings may be made up in more reliance
on detailed milestone reporting, or more attention paid to the requirements. This possibility will
be left for future research.
6.5.2 Diminished importance of contingencies The contingency factors that formed the models of monitoring, controlling and coordination
mechanisms were derived from organizational studies and not empirical software engineering.
Nevertheless the contingency factors were expected to affect the choice of mechanism in the
different circumstances. The contingency factors were:
Discussion
Page 174
• Task programmability
• Task visibility
• Output measurability
• Project risk
• Relational quality
• Cost
The research findings do not distinguish between two possibilities: that the contingencies are
not as strong in software engineering as they may be in other fields or that the contingencies are
little affected by changing organizational distance.
It has already been pointed out that software development tasks are highly programmable and
equally so whether performed locally or remotely. Software development texts, commercial
methodologies, international standards all describe in some form a work breakdown structure
that, regardless of variation, can be followed quite easily.
Similarly, the outputs of software development are easily measured in the sense that output
measurability was proposed as a contingency factor (Ouchi and Maguire, 1975; Eisenhardt,
1989a; Hamilton and Kashlak, 1999). The intention of output measurability as a contingency
factor was to distinguish circumstance where the task’s output could be detected and measured.
The example given by Ouchi of the Apollo moon shot program where the output, that of the
safely returned capsule, was unambiguous and highly visible whereas the output of a buyer for a
fashion boutique was much less measurable. The outputs of software development are highly
visible and, through testing, highly measurable. As was pointed out earlier in this thesis,
software can normally be transported anywhere in order to be measured except when the project
must install the software at a particular site. Outputs can still be measured but must be measured
on site instead of anywhere in the world.
Uncertainty in software development can take many forms. As defined by Hamilton and
Kashlak (1999), uncertainty related to the economic uncertainty of the host country’s
environment and was made up of cultural distance, host country restrictions and economic
stability. Eisenhardt (1989a) did not constrain “uncertainty” in her review of Agency Theory but
simply pointed out that task outcomes were assumed to be a product of employee behaviours
and random effects. Several examples of possible random effects were given in order to make it
clear that assigning responsibility for task completion to a third party was not without risk. In
his study of the evolution of coordination in outsourced software development, Sabherwal
identified uncertainty as a lack of information (Sabherwal, 2003). Thus uncertainty can be taken
to be almost anything that may prevent the agent successfully performing the task. Risk
Discussion
Page 175
management has gained much more attention in software development in the last fifteen years
and has served to show that software development itself is quite risky and not made especially
more risky by increasing organizational distance (Boehm, 1991; Chillarege and Biyani, 1994;
Thomsett, 2002b). That is, increasing organizational distance may increase the risk to the
project, but so might reliance on some technically unproven component. Risk may affect the
choice of mechanism but increasing organizational distance is not the sole determinant of
project risk.
6.5.3 Project manager knowledge Any choice depends on knowing that there are alternatives. The expression “to a person with a
hammer, every problem is a nail” applies. Distributed projects are relatively new to software
development and, as shown by the case studies and experience reports so far, the industry is still
exploring the implications for project management. No project management methodology to
date has advocated differing governance mechanisms for different project sub-teams. Rather,
the trend has been toward unifying all the suppliers into the same governance and reporting
mechanism (Milosevic, 1987; Back and Moreau, 2001; Bauch and Chung, 2001).
Project managers do employ different mechanisms for different parts of the project but only in
extreme cases. The example of buying COTS components has already been discussed. What has
not been evident either in the research or in the literature is any need to examine the different
parts of the project to decide how that particular part of the project should be managed.
Decisions on monitoring, controlling and coordinating parts of a project would seem to rest with
perceptions of the project component. If it is perceived as a component to be purchased, then
purchasing practices will be employed. If it is perceived as a hardware component then
hardware engineering practices will be employed but if it is perceived as software then software
engineering practices will be employed regardless of the merits of doing so. Now that
purchasing departments are having to deal with almost bespoke products and hardware products
can have most of their functionality delivered in software, it is possibly time to revise old habits.
6.5.4 Lower level variation This research expected that varying organizational distance would result in changes to the
preferred mechanisms used to monitor, control and coordinate a project. The expected changes,
listed in Table 21, were that:
• Ad hoc and informal monitoring mechanisms would be favoured and automatic and
formal monitoring mechanisms discouraged.
Discussion
Page 176
• Output and clan control mechanisms would be favoured and behaviour and input
controls discouraged.
• Coordination by formal and informal mutual adjustment would be favoured and
coordination by standards and plans discouraged.
Analysis of the data did not reveal any significant change in choice of project management
mechanism.
The research did not consider that the same mechanism could be implemented quite differently
depending on the circumstances. For example, a meeting conducted in person and a meeting
conducted by video conference is still a meeting. The mechanism hasn’t changed but the
implementation of it has changed. The data gathering in this research did not distinguish
between the two but recorded each as “meeting”. Similarly a project report could be a simple
summary of things already discussed with the project manager or they could be a detailed
explanation of the status of a task along with expected actions and alternatives. It would still be
recorded as “project report”. This means that the mechanisms may be robust enough and
generally applicable enough to span considerable organizational distances but their
implementation needed to change according to the circumstances.
The use of a portfolio of mechanisms allows the project manager to shift the emphasis to suit
the circumstance without necessarily changing the choice of control. This has the advantage of
using a mechanism familiar to both the project manager and the team while changing its
implementation. Such changes could completely change the dominance of one mechanism over
others or to shift the emphasis from, say, control to monitoring or coordination.
To investigate this possible changing implementation of project management mechanisms
would require more specific and detailed research that could be conducted in future.
Page 177
7 Conclusions, reflections and future research
This research set out to investigate the mechanisms used by project managers to monitor,
control and coordinate software development projects. The research also sought to identify
which of the project management mechanisms were essential and which were used depending
on the circumstances by examining the relationship between organizational distance and the
selection of project management mechanisms.
Research data was presented and analysed in Chapter 5 and discussed in Chapter 6. This chapter
will now present the overall conclusion of this research project.
7.1 Project management mechanisms. Project managers employ a portfolio of mechanisms to monitor, control and coordinate software
development projects. The portfolio comprises a combination of mechanisms that specifically
monitor or control or coordinate, and mechanisms that can be used to achieve all three.
Project monitoring
Project monitoring is achieved through a combination of mechanisms designed to inform the
project manager of potential or actual problems, but not to supply information on the cause or
the solution to potential problems. Ad hoc monitoring mechanisms are used to gather specific
information on causes and possible solutions as the need arises. This enables project managers
to use routine monitoring systems as an early warning system rather than a full information
gathering system.
Information may be gathered on the same matter through multiple sources or using multiple
mechanisms. When greater accuracy is required or when the project attribute concerned is more
subjective than objective, multiple sources, and multiple monitoring mechanisms, serve to
increase accuracy or confidence in the findings.
Project control
Project control is achieved through a portfolio of controls. Output controls such as the target
delivery date, project budget and desired functionality are the most common output controls, but
Conclusion, Reflections and Future Work
Page 178
these were frequently augmented with other objectives such as achieving a profitable outcome
for the project or meeting assigned KPIs. Project managers also reported on the need to have the
developed product pass acceptance tests or system tests.
The most common behaviour control was imposed by the project plan that, among other things,
determined when project team members performed specific development activities. The next
most popular was formal development processes that prescribed how some of the development
activities were to be performed.
Project managers in the research sample did not report using recruitment as a means of
controlling either the local development team or as a means of controlling an outsourced team.
Clan control, achieved through co-location, although practised by most project managers, was
not something they were particularly conscious of doing. Only those project managers who were
involved in fully outsourced projects appeared to see a need to co-locate some of the
development team or to foster common goals.
Project coordination
Project coordination, like both monitoring and control, is achieved using a portfolio of
mechanisms. However, the use of two different plan-based coordination mechanisms,
specifications and project plans, indicates that plan-based coordination has some advantages
over other coordination mechanisms that transcends organizational distance.
Informal mutual adjustment was also commonly used although not as frequently as plan-based
coordination. It would seem that informal interaction is required to resolve mutual dependencies
that seem to be an unavoidable part of software development.
Formal mutual adjustment, achieved through such activities as code or design reviews, project
reporting or project audits, were not used as frequently as other coordination mechanisms.
Standards-based coordination, achieved through standard activities or interface specifications, is
not employed with any frequency.
The effect of organizational distance
Despite strong theoretical indications that increasing organizational distance will have some
effect on the choice of project monitoring, control and coordination mechanisms, the empirical
data did not find any evidence of this. Instead, there were strong indications that the portfolios
of project management mechanisms used for co-located projects were used for distributed and
outsourced projects. This finding may imply that any improvements in project management
applied to outsourced or distributed projects are also likely to improve project management of
co-located projects. That is, if something works well in the more extreme circumstances, then it
will also work well in the less extreme circumstances.
Conclusion, Reflections and Future Work
Page 179
While it is unlikely that there is no relationship between organizational distance and the use of
project management mechanisms, the data gathered for this research was intended only to
investigate the choice of mechanisms and is insufficient for analysis of the composition of a
portfolio of project management mechanisms or variations in the implementation of a
mechanism in different circumstances. That shall be left to future research.
This research sought to identify which project management mechanisms were essential and
which were contingent on circumstances by examining the relationship between organizational
distance and the selection of project management mechanisms. The research did not find such a
relationship and is unable to conclude anything about the essentialness or otherwise of project
management mechanisms based on organizational distance. While other project based
differences, such as extremes of technical requirements, might still reveal some differences in
project management mechanism selection, it is possible that the project management
mechanisms that this research found were most frequently selected are, in fact, the essential
ones. That is:
1 project monitoring through formal meetings and informal conversations
2 project control through project objectives and adherence to the project plan
3 project coordination through specifications and project plans as well as co-location.
This research did not identify which project management mechanisms were favoured depending
on circumstances but did expose that a more fruitful area for research is the varying usage of
project management mechanisms (Section 7.4.3).
Reflections.
In this section I reflect on the research project, in particular how my world view has changed
through it. The more significant changes concern the need for precision in the terminology and
concepts to be investigated, how portrayal and presentation of project management affects
research and the need to consider multiple and diverse research methods when investigating
phenomena that have both a subjective and an objective understanding among practitioners.
7.1.1 Precision At the start of the research the intention was to investigate how project managers managed their
software development projects. This rapidly exposed that the term “manage” was too broad
because there are a variable number of activities that can be grouped under the general activity
of “manage”. This led to refining the term by specifying that, for the purposes of this research,
the term “manage” would include monitoring, controlling and coordinating project activities.
Obviously the intention was that the project manager should monitor, control and coordinate
Conclusion, Reflections and Future Work
Page 180
activities and resources directly related to software development. But what is meant by
“monitoring”? Does that include measurement or not? Is measurement a type of monitoring or is
all monitoring a type of measurement? While this research very quickly decided that monitoring
and control were two different activities and should be considered separately, it was not so easy
to decide whether “control” should be restricted to actions initiated by someone or to extend the
concept to passive controls such as administrative structures While it would be possible to refine
and sub-divide key terms into ever finer categorizations, there also must be some judgement
applied about how fine the granularity of categorization must be. However, that decision should
be made early in the research.
When comparing different authors’ use of terms over different fields, it becomes apparent that
the terminology is applied differently in different contexts. For example, a paper only recently
published argues that “coordination takes place in conversations” (Quinn and Dutton, 2005).
This view contradicts that of Mintzberg (1979) who argues that coordination is achieved
through organizational structure. Similarly, Albino et al. (2002) define a measure of
coordination load for use in factory production settings that would need to be modified if it were
to be applied to software development projects. As noted earlier, some authors consider that the
scope of control activities include monitoring activities (Ouchi, 1979; Eisenhardt, 1985; Kirsch,
1996; Hughes and Cotterell, 1999), while others consider monitoring activities separately from
control (Kitchenham and Walker, 1989; Al-Jibouri, 2003; Navon and Goldschmidt, 2003).
While it may be tempting to argue that all terminology should be used with its common
meaning within the software engineering and information systems community, this assumes that
there is sufficient consensus within those communities. It also denies the potential richness of
information available from other fields such as automobile manufacture ( e.g. Womack et al.,
1990) and supply chain management ( e.g. Cousineau et al., 2004; Supply Chain Council, 2004)
among others. Despite the difficulties, one of the most important tasks in research is to define
the concepts precisely.
Within the field of project management, there is an objective of improvement so that projects
are better managed or are better able to achieve their objectives (Ibbs and Kwak, 2000; Kwak
and Ibbs, 2000; Project Management Institute, 2004). However, there has yet to be an accepted
measure of what a well managed or well coordinated project might be. The current models of
project management maturity have taken the model of process maturity from software
engineering (Paulk et al., 1993; ISO 15504, 1998; SEI, 2000) and adapted it to project
management. These models of process improvement are aimed at improving software
development processes and indirectly improving the results of applying those processes, the
quality of the software product. While there are measures of software quality that may be used
to direct software process improvement efforts, there are no equivalent measures commonly
Conclusion, Reflections and Future Work
Page 181
used to measure project management or project coordination. One of the more difficult aspects
of this is that the very concept of a “managed” project or a “coordinated” project remain
subjective. Although there may well be a broad consensus on both terms, that broad consensus
is insufficient for research into the effects of changes to project management mechanisms.
Research into the effects on projects of various project management tools and mechanisms
would need some generally accepted, objective measures of project monitoring, control and
coordination.
7.1.2 Research methods In the beginning, this research expected to find all necessary data through quantitative research
methods. However, during the project it became apparent that the problem being investigated
was not so well formed that quantitative data alone would be sufficient. Rather, it is now
apparent that the basic concepts needed for investigating project monitoring, control and
coordination are subjective and would need to be determined through some form of
interpretivist research before any quantitative research investigated questions of how project
managers deal with those concepts.
In the past a normal approach may have been to establish the concepts, as understood by project
managers, first. Then, having an apparent sound set of concepts, investigate relationships
between those concepts. In other words, there would be some time elapsed between the first
study and the second. But phenomena such as distributed software development are very
contemporary. The use of outsourced software development or distributed software
development may rise and fall in a very short period. Research into those same phenomena must
be performed quickly so that the findings can be used.
Sequential research programs might not reach useful conclusions in time to be applied. Instead,
the eventual findings may prove relevant to a problem that no longer exists because, rather than
wait for a solution to a particular problem, software developers have eliminated the problem by
doing something else.
Mixed methods research has been gaining theoretical underpinnings as well as acceptance
(Brannen, 1992; Creswell, 2003). In particular, Brannen notes that interest in mixed method
research arises due to funders’ interest in “making the most of whatever methods were strategic”,
among other things. Mixed method research has the potential to investigate both the qualitative
and quantitative aspects of project management advocated in the next section (Section 7.4) and
to do it quickly enough to be useful while organizations are still in the early stages of distributed
software development. Thus, mixed method research should be preferred in future research in
this area.
Conclusion, Reflections and Future Work
Page 182
7.2 Future research This section will describe potential research projects whose need has been highlighted by this
research.
7.2.1 The meaning of project management The objectives of project management are generally assumed to be as they are given in the
PMBOK:
“Project management is the application of knowledge, skills, tools and techniques to project
activities to meet project objectives” (Italics in the original) (Project Management Institute,
2000).
This assumes that the identified project objectives are the only objectives and that project
managers will strive to meet them. However, projects are performed by a group of people who
may have individual perceptions of their objectives in any given circumstances. In particular,
there is not yet a definition of “project coordination” nor any measure of how well a project is
coordinated at any one time. Coordination-related objectives and any judgement of how well a
project is coordinated exist, subjectively, in the mind of the project manager. Similarly, a project
manager’s objectives for and judgement of project control remain subjective.
While there has been a number of investigations into some of the social aspects of software
development (Gruhn, 1992; Sawyer et al., 1997), particularly teamwork (Mantei, 1981; Walz et
al., 1993; Hoegl and Gemuenden, 2001; Potter and Balthazard, 2002), project management
objectives have not been viewed as subjective. Investigations into the social aspects or
subjective aspects of project management could advance understanding of the area and,
potentially, point out ways to improve project management of software development projects.
An investigation into how project managers understand their project objectives, what those
objectives are and how they might change as the project progresses could reveal new insights
into aspects of project management. For example, a project manager could regard the project
team’s harmonious interactions as a primary objective, believing that if the team is working well
together than all other objectives will be accomplished. Such a view would change perspectives
on project management tools toward more social objectives rather than utilitarian objectives.
Thus, research is proposed to investigate which objectives project managers regard as important,
what they understand by those objectives and how both the objectives and their understanding
change as a project progresses.
Conclusion, Reflections and Future Work
Page 183
7.2.2 The efficiency of project management mechanisms There has not been a rigorous analysis nor any empirical data on how any one mechanism is
used by a project manager to achieve multiple objectives. Research to date has investigated
project control (Zmud, 1980; Henderson and Lee, 1992; Kirsch, 1996; Addison and Vallabh,
2002; Choudhury and Sabherwal, 2003) or project monitoring (Kitchenham, 1996; Dumke and
Winkler, 1997; Royce, 1998; Kitchenham et al., 2001) or project coordination (e.g. Kraut and
Streeter, 1995; Crowston and Kammerer, 1998; Fussell et al., 1998; Faraj and Sproull, 2000;
Fussell et al., 2000; Andres and Zmud, 2002; Sabherwal, 2003) and has identified the
mechanisms employed to achieve each separate objective. But many of the same mechanisms
used for project control, for example, are also used to achieve project coordination.
Sabherwal (Sabherwal, 2003) considers efficiency in relation to project coordination, taking the
definition of efficiency from Ring and Van de Venn (1994) as “the most expeditious and least
costly governance structure for undertaking a transaction”. While this definition may be useful
when considering interorganizational relationships, it would be difficult to apply to the
mechanisms of project management where efficiency should concern the effects of a mechanism
compared to the costs of using it.
A project management mechanism could be used for different objectives, depending on the
circumstances. For example, a meeting may be used to enforce project control and, later,
another meeting be used to clarify how some parts of the system must interact, which is a
coordination matter.
More likely is that mechanisms will be used for several purposes at the same time. A
mechanism may be used to achieve a primary objective as well as a secondary objective. For
example, a specification such as a system design is primarily a control mechanism since it
specifies what is to be achieved. However, the same specification acts as a coordination
mechanism by specifying the how different parts of the system will interact.
The primary, secondary or incidental purposes for which a mechanism is used could vary
according to circumstances and this would need to be investigated.
Understanding how the different mechanisms are used would reveal more about how project
managers actually monitor, control and coordinate their projects and lead to a better
understanding of requirements for tools to assist them.
A research project is proposed to investigate the efficiency of project management mechanisms
used by project managers during a software development project. The research should
investigate the “whole of life” costs of using different project management mechanisms and the
results obtained by using them. Such research should reveal some reasons why different project
management mechanisms appear to be preferred. This may indicate fruitful directions for
Conclusion, Reflections and Future Work
Page 184
project management training as well as the types of tools that would support distributed project
management.
7.2.3 Varying usage of project management mechanisms. This research did not find any evidence that increasing organizational distance influenced the
selection of project management mechanisms. However, the research did not anticipate that
increasing organizational distance might affect the manner in which those same mechanisms
were used. For example, in a co-located project a meeting may be held with everyone in the
same room and able to discuss matters interactively and in person. With a distributed project,
the same meeting might be held using video-conferencing or telephone conferencing or even by
one of the electronic forums such as NetMeeting. Regardless of the implementation, this
research project considered all of these examples as “meetings” and did not distinguish between
them.
Clearly, when investigating distributed or outsourced projects, the categorization of project
management mechanisms appears to be too broad and needing to be extended to include
elements of the mechanism’s implementation. Mechanisms that are interactive, such as
meetings, are clearly affected by the degree of interactivity afforded by the meeting logistics.
Mechanisms that are considered more rigid, such as standards-based control or coordination
mechanisms, could be quite responsive to circumstances through tailoring rather than fixed for
all time and all circumstances.
Research that considers the usage of different mechanisms and whether this usage, in relation to
other mechanisms, varied as the project contingencies varied should reveal what project
managers need in order to manage their projects. It should also indicate more about what it is
that is essential in order to monitor, control and coordinate a project separated from specific
realizations of project management mechanisms.
Thus, a research project is proposed that investigates the ways in which project management
mechanisms are implemented as project contingencies vary.
7.2.4 The orientation of project management The theories and methods of project management have come largely from industrial practice
and not from, for example, sociology. This results in a heavy concentration on the logistics of
activities such as planning the work, monitoring the work and coordinating the work. The
PMBOK (Project Management Institute, 2000) has been adopted by the IEEE as a standard for
project management (IEEE 1490, 1998) and will serve as an example text. The PMBOK places
the project activities at the centre of project management efforts and everything else serves to
Conclusion, Reflections and Future Work
Page 185
support the activities. For example, human resource management is concerned with recruiting
and training personnel as needed by the project. Recruitment and training is not, for example,
oriented toward staff well-being or to help them to attain skills beyond those required by the
project.
A very strong theme through project management texts is that the project manager should direct
the efforts of others. Yet software development projects are characterised by, among other
things, interdependence among groups (Kraut and Streeter, 1995) that requires considerable
interaction among the groups. Software development is performed by teams with considerable
interaction among the teams (Gruhn, 1992; Brooks, 1995; McCarthy, 1995; Cusumano and
Selby, 1997; Carmel, 1999). Rather than be oriented around the activities with the project
manager as some sort of supervisor, software development could be considered as a group
activity with the chief role of project management being to foster group interactions. However,
it is pointless to argue that, because software development involves teams, the social processes
of teams are more important than the logistical processes of software development.
So far, there is little information available on the interaction of social process and logistical
processes in software development. This means that discussion about improving software
development project management has difficulty comparing “agile” projects (Beck, 1999;
Highsmith and Cockburn, 2001; Fowler, 2003; Cockburn, 2004) with more orthodox software
development projects and valuable lessons from one are discounted in the other. Projects that
employ “extreme programming” or other agile software development methods do succeed
despite little apparent formal project management and there has been at least one attempt to
examine where and why each project approach, plan-driven and agile, succeed or fail (Boehm
and Turner, 2004). Boehm and Turner (2004) note that “Good people and teams trump other
factors” and go on to list some of the factors relevant to people oriented software development
that are paid insufficient attention by the more orthodox software development methodologies.
However, their book is concerned primarily with software development methodologies and not
project management and does not venture into exactly how project management should deal
with the identified human factors.
Future research into mechanisms of project monitoring, control and coordination ought first
establish what project managers understand by a project being “under control” and a project
being “coordinated”, and establish what project managers do to influence both states.
7.3 Utility of the research contributions The classification schema (Table 9) of project management mechanisms used in software
development projects was developed through an extensive literature review and served this
Conclusion, Reflections and Future Work
Page 186
research well. The classification built on previous work by Adler (1995), Andres and Zmud
(2002), Nidumolu (1996) and Sabherwal (2003) among others by combining the concepts from
diverse fields into a classification scheme that acknowledges the different forms of mechanism
and combines the mechanisms of monitoring, control and coordination into a common
framework. This can serve other research by providing a common classification scheme where,
previously, there was none.
The classification of project management mechanisms provides a means for project managers to
assess whether there are more or alternative mechanisms with which they can monitor, control
and coordinate their project. This can overcome a tendency to rely on the same, and possibly
inappropriate, mechanisms through not knowing that alternatives exist.
The model linking organizational distance, project management contingencies and project
management mechanisms (Figure 8) can be adapted to investigate influences on project
management mechanisms other than organizational distance. This model provides an efficient
means to investigate different environments by separating the environment from the
contingencies, and the contingencies from the project management mechanisms.
The empirical research identified which project management mechanisms are used and the
relative frequencies with which they are used. These results can assist project managers in
choosing which project management mechanisms to use in different circumstances. For example,
in a short project a project manager may not want to set up formal monitoring through meetings
but may need to retain the rigour afforded through formal reporting. The research results can
guide the project manager about which alternative monitoring mechanisms are more frequently
used.
The empirical findings can also be used by developers of automated project management tools,
particularly workflow or process-centred software engineering environments (PSEE). The
findings point out that some activities such as informal conversations appear to be an essential
part of software development, possibly to resolve ambiguities or to resolve reciprocal
dependencies. If workflow or PSEE tools remove the ability to freely converse, they must
provide alternative ways to achieve what was previously achieved through conversation.
The conclusion that project managers monitor, control and coordinate their projects through
portfolios of project management mechanisms identifies that project management is a more
complex activity than is normally portrayed. Rather than advocating that a project manager
control a project through regular project meetings, for example, texts and other advice should
advocate that a project manager should adopt a portfolio approach to project control. Such an
approach to project management would reduce the risk of a project failure through relying on
single project management mechanisms that overlook project events. A portfolio approach
Conclusion, Reflections and Future Work
Page 187
allows multiple mechanisms to compensate for each other’s weaknesses and provides a more
robust means to manage software development projects.
Page 188
Appendices
Appendix A - Structured interview questions. The following questions are accompanied with the categorical or ordinal scale used by the interviewer to record responses. The interview subjects were shown the questions prior to the interview but were not shown the intended measures. This was to reduce any tendency to constrain an answer to perceived expectations. Blank lines in the questions separate the expected primary response to a question from potential follow up questions, used to clarify or expand the response. For example, question 12 asks about project planning and it’s approval. The expected responses were eitehr that specific project planning is performed or that the rigour of project planning depends on the project. Additionally the likely project approver is identified. Date: Time start Time finish Interviewee Interviewer Consent Signed Tape Organization 1 How large is the software development organization - number of personnel,
number of divisions, number of locations? < 10 staff 11 - 30 31 - 120 >120 - 1000 single organization > 1000 or Multinational 2 How formal are the software development processes? Are they
CMM/SPICE/CMMI assessed? Is the software development division ISO 9001 accredited?
Informal - Level 1 Managed - Level 2 Defined - Level 3 Measured - Level 4 Optimizing - Level 5 3 Is there an official, or unofficial, software process improvement initiative? No Episodic and informal Regular and informal
Page 189
Official function Serious 4 What is the highest level of the organization with an active interest in software development? Low - project manager Middle - division manager High - CEO & board Project characteristics 5 How large is your project(s)? The measure of size could be one of budget,
number of requirements or function points, or planned effort or duration? The purpose of the question is to have some way to separate projects into large, medium or small projects.
Small - < 6 months, $100K Medium - 1 year < $1M Large - > 1M 6 What type of system is being developed? Financial, ERP, CRM, SRM Military Infrastructure Telecommunications Medical Transport Services Factory automation Other
Is the system performance critical in some way? Life critical Performance critical Financial critical 7 Is the system being developed for this organization or an external customer? If
external, is the customer Australian or international? Internal External Australian International Project planning 8 How is project success measured in this organization? Schedule Budget Implemented functionality Quality levels Political success 12 How extensive is project planning before the project is formally approved with
Page 190
budget and personnel? No planning Informal and minimal Gantt chart and budget Formal but not extensive Formal and extensive Depends of the project size Depends on project risk Project manager approves Development manager approves CEO or Board approves 13 How rigorous is schedule planning? Is it detailed and unable to be changed or
are broad milestones considered enough? No planning Informal and minimal Gantt chart Formal but not extensive Formal and extensive Depends of the project size Depends on project risk 15 What is the highest level of the organization with an active interest in project
planning and approval? Project manager IT or R&D Manager VP CEO or Board of Directors Project management 9 Is functionality dropped to meet the delivery schedule? Who decides what
functionality gets dropped and how do they decide? Always retained Engineers decide Project review board decides. Negotiated with stakeholders Marketing decides. 10 Are the project’s quality objectives compromised to meet delivery deadlines?.
Quality objectives in this context would be number of major or significant defects known to be in the shipped product.
No quality goals set Set but never relaxed Set and sometimes relaxed Engineers decide to relax quality goals Project review board decides to relax quality goals
Page 191
Negotiated with stakeholders Marketing decides 11 Are the project’s performance objectives compromised to meet delivery deadlines? No performance objectives set Set but never relaxed Set, sometimes relaxed Engineers decide when to relax performance criteria Project review board decides Negotiated with stakeholders Marketing decides 14 How rigorous is the requirements management effort? Is there an extensive
effort spent to elicit and validate the requirements, and to allocate them to design elements? Or is design allocation of requirements considered part of the high level design?
No planning Informal and minimal Informal Specification written then shelved Actively managed specification Tool used to actively manage requirements 46 Is there a standard process for managing requirements? No - each PM does their own thing Yes, but informal and flexible Yes, defined but not very extensive Yes, defined and extensive 47 Do you have measures for requirements such as the total number, added since
baseline, changed, revisions No We have measures but not directly tied to requirements Extensive measures for requirements 48 Do you have libraries of standard requirements? No Some used where possible. Yes. Projects are all different - it is not worthwhile 49 Are any tools used to manage the system requirements? Nothing special DOORS or RequisitePro Project monitoring 16 As a project manager, what do you look at to see that it’s going right? How do
you know the project is on track?
Page 192
Expert judgment Milestones Budget Schedule Defect list growth and decline Test stats 17 As a project manager, what do you look at to see if it’s going wrong? How do
you know when something is not right and needs attention? Expert judgment Tip off Not hitting the milestones 18 If some requirements cannot be implemented as planned in one part of the
system, how is this detected and reported? During design phase Do not find out until integration Tip off Continuous integration exposes it Regular discussions with development team Regular project review 19 What is done to the rest of the system to compensate for being unable to
implement requirements where or as planned? Drop functionality Work around without changing the rest of the system Reallocate functionality to other parts of the system Redesign the system to eliminate the need 20 If a project task is taking longer than planned, what is done to adjust expected
task completion time or adjust the rest of the schedule? Nothing - it just takes longer Add resources Drop functionality Change the task to move work elsewhere Adjust the rest of the schedule 21 Is there a project review such as a weekly meeting to establish the state of the
project? In such meetings, what is reviewed? Nothing special Regular meeting Design issues Requirements issues Schedule, budget, quality, test results Risks or issues Gossip 22 Is there a formal, organization level, project review at scheduled intervals? In
such reviews, what is reviewed?
Page 193
Nothing special Regular meeting Design issues Requirements issues Schedule, budget, quality, test results Risks or issues Gossip 43 Is there a standard method or process for monitoring project tasks? No - each PM does their own thing Yes, but informal and flexible Yes, defined but not very extensive Yes, defined and extensive 44 Do you monitor how much time you spend on the various project management activities? Not especially Yes, broadly Yes, to a fairly detailed level Always looking at where PMs spend the time 45 How do you get better at monitoring project tasks? How do you tell others about
improvements you have discovered or tested? Yes, informally Yes, regular forums Changes to project management process or techniques are centrally managed Organizational distance 23 What project organization structure is employed to manage an outsourced development? Part of PM job Specific management by PM team Specific role within development department Marketing, Supply or Purchasing department manages them 24 What is the relationship between this organization, specifically this project, and
the outsource organization? Different division of the same organization Same organization but different legal entity Different company Same building Same city Different city - same country Different country 37 Do you deal directly with the outsourced supplier's developer or is it through
intermediaries? Direct with the developer Little direct contact with the developer or PM
Page 194
Never get to speak with the developer 38 How many organization layers would be involved in any dispute escalation? PM manages both teams - direct We share the same manager - direct through one layer My manager talks to their manager (negotiated through one layer) Department head talks to department head (negotiated and indirect) Between CEOs (extreme indirection) 39 How much difficulty do you have communicating with the supplier? Very easy - we talk the same language Easy - questions are technical and answers understood Neutral - questions are both technical and non-technical but answers are understood Difficult - some technical and non-technical misunderstandings Very difficult - frequent and severe misunderstandings 40 How would you characterize the first point of contact in the outsourced supplier
for regular communications such as project status enquiries or to notify changed requirements?
CEO, VP? Office manager? Project manager or development team? Purchasing or sales department? CEO, VP separated from the project team QA manager separated from the project team Office manager Purchasing department, sales or marketing Project team 41 How different is their development team's technical expertise from your project
team's expertise? Similar expertise Similar field but slightly different expertise Neutral - different field but similar technology Different field and technology but understandable Different field and technology and source of difficulties 42 Is it clear who you should talk to about the task’s progress? Yes, always able to get through Yes, but not always there Yes, but they do not have the information Unclear just who is in charge Control method 25 Do you train the outsourcee in your development methods, project management
methods or other techniques? No training given Train in response to shortcomings Regular training
Page 195
Project specific training Mentoring 26 Do you require the outsourcee to gain ISO 9001 accreditation? No Yes No, but require certification to another standard 27 Do you require the outsourcee to implement a software process improvement initiative? No No, but they have one anyway Yes, but its informal Yes, ISO 9001 Yes, SPICE or CMMI 28 How much responsibility is given to the outsourced developer for the system or
component design? None. They implement our design. Some. Given detailed design but details can be negotiated Significant. High level requirements given, they decide the implementation details Total. They conceive the product and develop the main requirements before soliciting our input. 29 How do you know the outsourced developer has met the requirements? Informal communications Expert judgment Integration testing Acceptance testing Actively monitor development Outsourced task management 33 If some requirements cannot be implemented as or where they were originally
planned, what is done to the rest of the system to compensate? Drop functionality Work around without changing the rest of the system Reallocate functionality to other parts of the system Redesign the system to eliminate the need 34 If an outsourced project task is taking longer than planned, what is done to
adjust expected task completion time or adjust the rest of the schedule? Nothing - it just takes longer Add resources Change the task to move work elsewhere Adjust the rest of the schedule Outsourced task monitoring 30 As a project manager, what do you look at in an outsourced task to see that it’s
Page 196
going right? How do you know the project is on track? Expert judgment Milestones Budget Schedule Functionality Defect list growth and decline Test stats 31 As a project manager, what do you look at in an outsourced task to see if it’s
going wrong? How do you know when something is not right and needs attention?
Expert judgment Tip off Not hitting the milestones 32 How would you find out that some functionality cannot be implemented as
planned in one part of the system? Do not find out until integration Tip off Continuous integration exposes it Regular discussions with development team Regular project review 35 Is there a project review such as a weekly meeting to establish the state of the
outsourced project or task? In such meetings, what is reviewed? Nothing special Regular meeting Design issues Requirements issues Schedule, budget, quality, test results Risks or issues Gossip 36 Is there a formal, organization level, review of an outsourced project or task at
scheduled intervals? In such reviews, what is reviewed? Nothing special Regular meeting Design issues Requirements issues Schedule, budget, quality, test results Risks or issues Gossip
Page 197
Appendix B - Interview questions arranged by topic Organization 1 How large is the software development organization - number of personnel,
number of divisions, number of locations? 2 How formal are the software development processes? Are they
CMM/SPICE/CMMI assessed? Is the software development division ISO 9001 accredited?
3 Is there an official, or unofficial, software process improvement initiative? 4 What is the highest level of the organization with an active interest in software
development? Project characteristics 5 How large is your project(s)? The measure of size could be one of budget,
number of requirements or function points, or planned effort or duration? The purpose of the question is to have some way to separate projects into large, medium or small projects.
6 What type of system is being developed? 7 Is the system being developed for this organization or an external customer? If
external, is the customer Australian or international? Project planning 8 How is project success measured in this organization? 12 How extensive is project planning before the project is formally approved with
budget and personnel? 13 How rigorous is schedule planning? Is it detailed and unable to be changed or
are broad milestones considered enough? 15 What is the highest level of the organization with an active interest in project
planning and approval? Project management 9 Is functionality dropped to meet the delivery schedule. Who decides what
functionality gets dropped and how do they decide? 10 Are the project’s quality objectives compromised to meet delivery deadlines?.
Quality objectives in this context would be number of major or significant defects known to be in the shipped product.
11 Are the project’s performance objectives compromised to meet delivery deadlines?
14 How rigorous is the requirements management effort? Is there an extensive effort spent to elicit and validate the requirements, and to allocate them to design elements? Or is design allocation of requirements considered part of the high level design?
46 Is there a standard process for managing requirements? 47 Do you have measures for requirements such as the total number, added since
baseline, changed, revisions? 48 Do you have libraries of standard requirements? 49 Are any tools used to manage the system requirements? Project monitoring 16 As a project manager, what do you look at to see that it’s going right? How do
you know the project is on track? 17 As a project manager, what do you look at to see if it’s going wrong? How do
Page 198
you know when something is not right and needs attention? 18 If some requirements cannot be implemented as planned in one part of the
system, how is this detected and reported? 19 What is done to the rest of the system to compensate for being unable to
implement requirements where or as planned? 20 If a project task is taking longer than planned, what is done to adjust expected
task completion time or adjust the rest of the schedule? 21 Is there a project review such as a weekly meeting to establish the state of the
project? In such meetings, what is reviewed? 22 Is there a formal, organization level, project review at scheduled intervals? In
such reviews, what is reviewed? 43 Is there a standard method or process for monitoring project tasks? 44 Do you monitor how much time you spend on the various project management
activities. 45 How do you get better at monitoring project tasks? How do you tell others about
improvements you have discovered or tested? Organizational distance 23 What project organization structure is employed to manage an outsourced
development? 24 What is the relationship between this organization, specifically this project, and
the outsource organization? 37 Do you deal directly with the outsourced supplier's developer or is it through
intermediaries? 38 How many organization layers would be involved in any dispute escalation? 39 How much difficulty do you have communicating with the supplier? 40 How would you characterize the first point of contact in the outsourced supplier
for regular communications such as project status enquiries or to notify changed requirements? CEO, VP? Office manager? Project manager or development team? Purchasing or sales department?
41 How different is their development team's technical expertise from your project team's expertise?
42 Is it clear who you should talk to about the task’s progress? Control method 25 Do you train the outsourcee in your development methods, project management
methods or other techniques? 26 Do you require the outsourcee to gain ISO 9001 accreditation? 27 Do you require the outsourcee to implement a software process improvement
initiative? 28 How much responsibility is given to the outsourced developer for the system or
component design? 29 How do you know the outsourced developer has met the requirements? Outsourced task management 33 If some requirements cannot be implemented as or where they were originally
planned, what is done to the rest of the system to compensate? 34 If an outsourced project task is taking longer than planned, what is done to
adjust expected task completion time or adjust the rest of the schedule? Outsourced task monitoring 30 As a project manager, what do you look at in an outsourced task to see that it’s
going right? How do you know the project is on track? 31 As a project manager, what do you look at in an outsourced task to see if it’s
Page 199
going wrong? How do you know when something is not right and needs attention?
32 How would you find out that some functionality cannot be implemented as planned in one part of the system?
35 Is there a project review such as a weekly meeting to establish the state of the outsourced project or task? In such meetings, what is reviewed?
36 Is there a formal, organization level, review of an outsourced project or task at scheduled intervals? In such reviews, what is reviewed?
Page 200
Appendix C - Consent Form UNIVERSITY OF TECHNOLOGY, SYDNEY CONSENT FORM - STUDENT RESEARCH I ____________________ agree to participate in the research project “Task coordination in software development” being conducted by Tom McBride, Rm 10.4.564, PO Box 123 Broadway, NSW 2007, of the University of Technology, Sydney, for the purpose of his PhD degree. I understand that the purpose of this study is to investigate the effects of organizational distance on the ability of project managers to monitor and coordinate software development tasks, and to determine the characteristics of the more successful practices. I understand that my participation in this research will involve being interviewed about my organization’s project management task coordination practices and checking that the interview has been accurately transcribed. I am aware that I can contact Tom McBride or his supervisor, Professor Brian Henderson-Sellers, if I have any concerns about the research. I also understand that I am free to withdraw my participation from this research project at any time I wish and without giving a reason. I agree that Tom McBride has answered all my questions fully and clearly. I agree that the research data gathered from this project may be published in a form that does not identify me in any way. ________________________________________ ____/____/____ Signed by ________________________________________ ____/____/____ Witnessed by NOTE: This study has been approved by the University of Technology, Sydney Human Research Ethics Committee. If you have any complaints or reservations about any aspect of your participation in this research which you cannot resolve with the researcher, you may contact the Ethics Committee through the Research Ethics Officer, Ms Susanna Davis (ph: 02 - 9514 1279, [email protected]). Any complaint you make will be treated in confidence and investigated fully and you will be informed of the outcome. Professor Brian Henderson-Sellers may be contacted on (02) 9514 1687 or [email protected]
Page 201
Appendix D - Content analysis form
Project Manager of Organizational distance Count Control Count
Australia - Anglo (US, UK, NZ, Canada)
Budget, schedule, functionality
Customer satisfaction Australia - Latin Europe (France, Spain, Italy) Contract T&C Australia - Far East (Asia)
Output
Cultural distance
Australia - other Formal dev processes Within Sydney Process training Within Australia
Behaviour
International PM Selection
Structural Distance
Time zone differences Team selection Direct to other company staff Selection by tender Indirect via supervisor
Input
Admin distance
Via supervisor to anonymous staff Development team collocation Establish relationship Developer exchange Relational quality Sustain relationship Site visits
Clan
Informal conversations Automatic systems Count Coordination Count
CSCW, Workflow Template work products Configuration management Interface specs Defect, issue tracking
Standards
Design rules Automated integration & testing Schedule Release management Specifications Development cycle Sign offs - phase reviews
Project bulletin board
Plan based
Test plans Monitoring Count Code and design reviews
Product review/inspections Change control committee Schedule & milestone tracking project team meetings Team meetings ad hoc meetings Status reports
Formal mutual adjustment
project reviews Management review Co-location
Formal Monitoring
Customer review MBWA QA or process audit Informal conversation phase end review Informal email
Ad hoc monitoring
Drill down inquiry
Informal mutual adjustment
Site visits Conversations with project team conversations with stakeholders
Informal monitoring
conversations with customer
Page 202
Appendix E - Publications The following conference papers have arisen from this research. McBride, T., Henderson-Sellers, B. and Zowghi, D. (2004), "Monitoring and Controlling
Software Development Projects", EMCIS 2004, Tunis McBride, T., Henderson-Sellers, B. and Zowghi, D. (2004), "Project Management Capability
Levels: An Empirical Study", 11th Asia-Pacific Software Engineering Conference, Busan, IEEE Computer Society, pp. 56-63
The following paper has been accepted for publication by the Journal of Enterprise Information Management at a date yet to be determined. McBride, T., Henderson-Sellers, B. and Zowghi, D. "Software Development as Design or a
Production Project: An Empirical Study of Project Monitoring and Control", Journal of Enterprise Information Management
Page 203
Appendix F – Research Tools Academic research that involves participants from commercial organizations relies on the
goodwill of those participants. They are the “customers” of academic research and deserve to
be treated with care and consideration. Their interview data should be retained securely,
should not be lost and they should not receive phone calls or correspondence that gives them
the impression that the research is poorly organised. To this end a small “CRM” system was
sought that suited research management or could be adapted to research management. There
are some high end tools available to manage clinical trials that were not considered suitable.
On the low end of the scale were a collection of shareware, freeware or very inexpensive
customer relationship tools or small database tools. A selection were tested and the most
suitable, and best quality, was chosen. This was “Our Customer Base” from Graphicalic
Denmark. While it could have been used in its original form, the vendor was approached to
see if they were prepared to modify the tool to track research projects that had the
characteristics of market surveys. The vendor was very obliging and the result, “Organization
Research”, was a small commercial database that tracked companies, contacts within those
companies, research participants, research projects, the status and progress of each interview.
The same information could have been kept manually but using the tool raised the level of
professionalism slightly.
The database product was invaluable during the time of recruiting organizations to the
research, conducting and transcribing the interviews, and following up reviews. It became
easy to keep track of who it was I had spoken to in each company, who was to be interviewed
and when, all of their contact details and the status of each interview (interviewed, transcribed,
reviewed, updated, analysed). Reports showing the number of interviews and their various
stages of completion allowed research progress to be judged and estimates for when the
interview phase of the research would be completed.
During the doctoral review, a question was raised about the number of survey questions
related to a particular organizational attribute. The question, which was later fully addressed,
raised the point that survey questions do need to relate to the research questions. Tracking
relationships research questions, constructs needed to answer those research questions and
survey questions to supply the data for the constructs is difficult when they are simply written
on paper. But databases are useful for implementing relationships between things. So a small
Microsoft Access database was developed to record each hypothesis, research question,
survey question and, where appropriate, the ordinal scale of expected responses. The database
design is shown in Figure 18.
Page 204
Figure 18: Database design showing relations between hypotheses, research questions and interview questions
Recording the interview questions in a database permitted easy checking that each research
question was adequately covered by interview questions and that each research topic was
adequately covered.
Project Project ID Description Research Question
Research Question Question ID Question text Project ID
Scale Scale ID Scale Type Rationale
Question Category Question Analysis
Page 205
Page 206
Bibliography ABS (2002), 1321.0 Small Business in Australia, Australian Bureau of Statistics, 1321.0 Addison, T. and Vallabh, S. (2002), "Controlling software project risks: an empirical study of
methods used by experienced project managers", Proceedings of the 2002 annual research conference of the South African institute of computer scientists and information technologists on Enablement through technology, Port Elizabeth, South African Institute for Computer Scientists and Information Technologists, pp. 128-140
Adler, P. S. (1995), "Interdepartmental Interdependence and Coordination: The Case of the Design/Manufacturing Interface." Organization Science, Vol.6, no 2, pp. 147-167.
Albino, V., Pontrandolfo, P. and Scozzi, B. (2002), "Analysis of information flows to enhance the coordination of production processes", International Journal of Production Economics, Vol.75, no 1-2, pp. 7-19.
Albrecht, A. J. and Gaffney, J. E., Jr. (1983), "Software Function, Source Lines of Code, and Development Effort Predistions: A Software Science Validation", IEEE Transactions on Software Engineering, Vol.SE-9, pp. 639-648.
Al-Jibouri, S. H. (2003), "Monitoring systems and their effectiveness for project cost control in construction", International Journal of Project Management, Vol.21, no 2, pp. 145-154.
Allen, T. J. (1977), Managing the Flow of Technology: Technology Transfer and the Dissemination of Technological Information Within the R&D Organization, MIT Press, Boston
Allen, T. J. (2000), "Architecture and communication among product development engineers", Engineering Management Society, Albuquerque, NM , USA, IEEE Computer Society, pp. 153-158
Andres, H. P. and Zmud, R. W. (2002), "A Contingency Approach to Software Project Coordination", Journal of Management Information Systems, Vol.18, no 3, pp. 41-70.
Arino, A. and de la Torre, J. (1998), "Learning from failure: Towards an evolutionary model of collaborative ventures", Organization Science, Vol.9, no 3, pp. 306-325.
Arino, A., de la Torre, J. and Ring, P. S. (2001), "Relational quality: Managing trust in corporate alliances", California Management Review, Vol.44, no 1, pp. 109-131.
Atkinson, G., Hagemeister, J., Oman, P. and Baburaj, A. (1998), "Directing software development projects with product metrics", Proceedings. Fifth International Software Metrics Symposium, pp. 193-204
ATO (2004), Taxation Statistics 2000-01: A summary of taxation, superannuation and industry benchmark statistics 2000–01 and 2001–02, Available: http://www.ato.gov.au/taxprofessionals/content.asp?doc=/content/37484.htm&page=75&H14_3, accessed 19 May 2005
Back, W. E. and Moreau, K. A. (2001), "Information Management Strategies for Project Management", Project Management Journal, Vol.32, no 1, pp. 10-19.
Bailetti, A. J., Callahan, J. R. and DiPietro, P. (1994), "A coordination structure approach to the management of projects", Engineering Management, IEEE Transactions on, Vol.41, no 4, pp. 394-403.
Bailetti, A. J., Callahan, J. R. and McCluskey, S. (1998), "Coordination at different stages of the product design process." R&D Management, Vol.24, no 4, pp. 237-248.
Bajaj, A. and Ram, S. (2002), "SEAM: A state-entity-activity-model for a well-defined workflow development methodology", Knowledge and Data Engineering, IEEE Transactions on, Vol.14, no 2, pp. 415-431.
Baker, D., Georgakopoulos, D., Schuster, H., Cassandra, A. and Cichocki, A. (1999), "Providing customized process and situation awareness in the collaboration management infrastructure", IFCIS International Conference on Cooperative Information Systems, CoopIS '99., Austin, TX, USA, Practical, pp. 79-91
Barber, P., Tomkins, C. and Graves, A. (1999), "Decentralised site management - a case study",
Bobliography
Page 207
International Journal of Project Management, Vol.17, no 2, pp. 113-120. Barnes, A. and Gray, J. (2000), "COTS, workflow, and software process management: an
exploration of software engineering tool development", Australian Software Engineering Conference, Canberra, Australia, IEEE Computer Society, pp. 221-232
Battin, R. D., Crocker, R., Kreidler, J. and Subramanian, K. (2001), "Leveraging resources in global software development", IEEE Software, Vol.18, no 2, pp. 70-77.
Bauch, G. T. and Chung, C. A. (2001), "A Statistical Project Control Tool for Engineering Managers." Project Management Journal, Vol.32, no 2, pp. 37-44.
Beck, K. (1999), "Embracing change with extreme programming", Computer, Vol.32, no 10, pp. 70-77.
Beck, K. (2000), Extreme Programming Explained, Addison-Wesley, Boston Bendeck, F., Goldmann, S., Holz, H. and Kotting, B. (1998), "Coordinating management
activities in distributed software development projects", Seventh IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, Kaiserslautern Univ., Germany, Practical, pp. 33-38
Berggren, C., Soderlund, J. and Anderson, C. (2001), "Clients, contractors, and consultants: The consequences of organizational fragmentation in contemporary project environments", Project Management Journal, Vol.32, no 3, pp. 39-48.
Blanchard, F. L. (1990), Engineering Project Management, Marcel Dekker, Inc., New York Boehm, B. (1999), "Making RAD work for your project", Computer, Vol.32, no 3, pp. 113-114,
117. Boehm, B. (2000), "Safe and simple software cost analysis", IEEE Software, Vol.17, no 5, pp.
14-17. Boehm, B., Clark, B., Horowitz, E., Madachy, R., Selby, R. and Westland, C. (1995), "An
Overview of the Cocomo 2.0 Software Cost Model", Software Technology Conference, Salt Lake City, pp. 21
Boehm, B. and Ross, R. (1988), "Theory-W software project management: a case study", Proceedings of the 10th International Conference on Software Engineering, Singapore, IEEE, pp. 30-40
Boehm, B. and Turner, R. (2004), Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, Boston
Boehm, B. W. (1988), "A spiral model of software development and enhancement", Computer, Vol.21, no 5, pp. 61-72.
Boehm, B. W. (1991), "Software risk management: principles and practices", IEEE Software, Vol.8, no 1, pp. 32-41.
Boehm, B. W. and Ross, R. (1989), "Theory-W software project management principles and examples", IEEE Transactions on Software Engineering, Vol.15, no 7, pp. 902-916.
Borchers, G. (2003), "The software engineering impacts of cultural factors on multi-cultural software development teams", Proceedings of the 25th international conference on Software engineering, Portland, Oregon, IEEE Computer Society
Bowles, S. and Gintis, H. (2004), "The evolution of strong reciprocity: cooperation in heterogeneous populations", Theoretical Population Biology, Vol.65, no 1, pp. 17-28.
Brannen, J. (Ed.) (1992), Mixing Methods: qualitative and quantitative research, Avebury, Aldershot.
Bresnen, M. and Marshall, N. (2002), "The engineering or evolution of co-operation? A tale of two partnering projects", International Journal of Project Management, Vol.20, no 7, pp. 497-505.
Brooks, F. P., Jr (1995), The Mythical Man-Month, Addison Wesley Longman Burke, R. (2003), Project Management: Planning and Control Techniques., Burke Publishing,
Tokai, South Africa Burns, T. and Stalker, G. M. (1966), The management of innovation, Tavistock Ltd Butler, K. and Lipke, W. (2000), Software Process Achievement at Tinker Air Force Base,
Oklahoma, Software Engineering Institute, Oklahoma City, CMU/SEI-2000-TR-014 Caldwell, N. H. M., Clarkson, P. J., Rodgers, P. A. and Huxor, A. P. (2000), "Web-based
Bobliography
Page 208
knowledge management for distributed design", Intelligent Systems, IEEE [see also IEEE Expert], Vol.15, no 3, pp. 40-47.
Cameron, D. (2001), "Chefs and occupational culture in a hotel chain:A grid-group analysis." Tourism & Hospitality Research, Vol.3, no 2, pp. 103-114.
Carayannis, E. G. and Sagi, J. (2001), "Dissecting the professional culture: insights from inside the IT "black box"", Technovation, Vol.21, no 2, pp. 91-98.
Carmel, E. (1999), Global Software Teams: Collaborating Across Borders and Time Zones, Prentice Hall PTR, Upper Saddle River
Carmel, E. and Agarwal, R. (2001), "Tactical approaches for alleviating distance in global software development", Software, IEEE, Vol.18, no 2, pp. 22-29.
Carmel, E. and Agarwal, R. (2002), "The maturation of offshore sourcing of information technology work." MIS Quarterly Executive, Vol.1, no 2, pp. 65-77.
Chan, W.-T., Chua, D. K. H. and Lang, X. (1999), "Collaborative scheduling over the Internet", Computer Aided Civil and Infrastructure Engineering, Vol.14, pp. 15-24.
Checkland, P. (1981), Systems Thinking, Systems Practice, John Wiley & Sons, Chichester Chen, D. (2002), "Developing a theory of design through a multidisciplinary approach", IEEE
International Conference on Systems, Man and Cybernetics, Bordeaux, France, IEEE Computer Society, pp. 449-454
Chen, H. and Luh, P. B. (2000), "Scheduling and coordination in manufacturing enterprise automation", Robotics and Automation, 2000. Proceedings. ICRA '00. IEEE International Conference on, Dept. of Electr. & Syst. Eng., Connecticut Univ., Storrs, CT, USA, Application, pp. 389-394 vol.1
Chen, Y., Probert, R. L. and Sims, D. P. (2002), "Specification-based regression test selection with risk analysis", IBM Centre for Advanced Studies Conference, Toronto, IBM Press
Chenhall, R. H. (2003), "Management control systems design within its organizational context: findings from contingency-based research and directions for the future", Accounting, Organizations and Society, Vol.28, no 2-3, pp. 127-168.
Chevrier, S. (2003), "Cross-cultural management in multinational project groups", Journal of World Business, Vol.38, no 2, pp. 141-149.
Chillarege, R. and Biyani, S. (1994), "Identifying risk using ODC based growth models", Proceedings of 5th International Symposium on Software Reliability Engineering, Portland, OR, ACM, pp. 282-288
Choudhury, V. and Sabherwal, R. (2003), "Portfolios of control in outsourced software development projects." Information Systems Research, Vol.14, no 3, pp. 291-315.
Cleland, D. I. and Ireland, L. R. (2002), Project management: Strategic Design and Implementation, McGraw-Hill
Cockburn, A. (2004), Crystal Methodologies, Available: http://alistair.cockburn.us/crystal/crystal.html, accessed July 21 2004
Cohen, J. (1977), Statistical Power Analysis for the Behavioral Sciences, Academic Press Cooke-Davies, T. (2002), "The "real" success factors on projects", International Journal of
Project Management, Vol.20, no 3, pp. 185-190. Cousineau, M., Lauer, T. W. and Peacock, E. (2004), "Supplier source integration in a large
manufacturing company", Supply Chain Management, Vol.9, no 1, pp. 110-117. Cramton, C. D. (1997), "Information Problems in Dispersed Teams", Academy of Management
Proceedings, pp. 298-302. Creswell, J. W. (2003), Research Design: Qualitative, Quantitative and Mixed Methods
Approaches, Sage Publications Inc, Lincoln Crowston, K. (2003), A taxonomy of organizational dependencies and coordination
mechanisms., In Tools for Organizing Business Knowledge (Eds, Malone, T. W., Crowston, K. and Herman, G.) MIT Press, Cambridge.
Crowston, K. and Osborn, C. (Eds.) (1998), A Coordination Theory Approach to Process Description and Redesign, MIT Press, Cambridge.
Crowston, K. G. (1991), Towards a Coordination Cookbook: Recipes for Multi-Agent Action, A thesis submitted to Alfred P. Sloan School of Management, Massachusetts Institute of
Bobliography
Page 209
Technology,Boston Cruz, J. C. and Tichelaar, S. (1998), "Managing evolution of coordination aspects in Open
systems", Database and Expert Systems Applications, 1998. Proceedings. Ninth International Workshop on, Software Composition Group, Berne Univ., Switzerland, Practical, pp. 578-582
Curtis, B., Krasner, H. and Iscoe, N. (1988), "A field study of the software design process for large systems", Communications of the ACM, Vol.31, no 11, pp. 1268 - 1287.
Curtis, W., Krasner, H., Shen, V. and Iscoe, N. (1987), "On building software process models under the lamppost", Proceedings of the 9th international conference on Software Engineering, Monterey, California, IEEE Computer Society Press, pp. 96-103
Cusumano, M. A. and Selby, R. W. (1997), "How Microsoft builds software", Communications of the ACM, Vol.40, no 6, pp. 53-61.
Cusumano, M. J. and Selby, R. W. (1995), Microsoft Secrets, HarperCollins, London Daft, R. L. and Lengel, R. H. (1986), "Organizational Information Requirements, Media
Richness and Structural Design", Management Science, Vol.32, no 5, pp. 554-571. Das, T. K. and Teng, B.-S. (1998), "Between Trust and Control: Developing Confidence in
Partner Cooperation alliances", Academy of Management Review, Vol.23, no 3, pp. 491-512.
Das, T. K. and Teng, B.-S. (2001), "Trust, Control, and Risk in Strategic Alliances: An Integrated Framework", Organization Studies, Vol.22, no 2, pp. 251-283.
Davies, R. and Saunders, R. (1988), "Applying systems theory to project management problems", International Journal of Project Management, Vol.6, no 1, pp. 19-26.
Davis, N. and Mullaney, J. (2003), The Team Software Process in Practice: A Summary of Recent Results, Software Engineering Institute, CMU/SEI-2003-TR-104
DeMarco, T. and Boehm, B. (2002), "The agile methods fray", Computer, Vol.35, no 6, pp. 90-92.
DeSanctis, G. and Jackson, B. M. (1994), "Coordination of information technology management: Team-based structures and computer-based communication systems", Journal of Management Information Systems, Vol.10, no 4, pp. 85-110.
Donaldson, L. (2001), The Contingency Theory of Organizations, Sage Publications Doz, Y. (1996), "The Evolution of Cooperation in Strategic Alliances:Initial Conditions of
Learning Processes?" Strategic Management Review, Vol.17, pp. 55-83. Dube, L. and Robey, D. (1999), "Software stories: three cultural perspectives on the
organizational practices of software development", Accounting, Management and Information Technologies, Vol.9, no 4, pp. 223-259.
Duliba, K. A. and Baroudi, J. (1991), "IS personnel: do they form an occupational community?" Special Interest Group on Computer Personnel Research Annual Conference, Athens, Georgia, ACM Press, pp. 111-118
Dumke, R. R. and Winkler, A. S. (1997), "Managing the component-based software engineering with metrics", Proceedings Fifth International Symposium on Assessment of Software Tools and Technologies, pp. 104-110
Duncan, W. R. (1996), A Guide to the Project Management Body of Knowledge, Project Management Institute, Newtown Square
Earl, M. J. (1996), "The Risks of Outsourcing IT", Sloan Management Review, Vol.37, no 3, pp. 26-32.
Easterbrook, S. (1995), "Coordination breakdowns: why groupware is so difficult to design", IEE Colloquium on CSCW (Computer Supported Co-operative Working) and the Software Process, pp. 1-4
Eisenhardt, K. M. (1985), "Control: Organizational and Economic Approaches", Management Science, Vol.31, no 2, pp. 134-148.
Eisenhardt, K. M. (1989a), "Agency Theory: An Assessment and Review", Academy of Management Review, Vol.14, no 1, pp. 57-74.
Eisenhardt, K. M. (1989b), "Building Theories From Case Study Research", Academy of Management Review, Vol.14, no 4, pp. 532-550.
Bobliography
Page 210
Eisenhardt, K. M. and Tabrizi, B. N. (1995), "Accelerating adaptive processes: Product innovation in the global computer industry", Administrative Science Quarterly, Vol.40, no 1, pp. 84-110.
Espinosa, J. A., Kraut, R. E., Slaughter, S. A., Lerch, J. F., Herbsleb, J. D. and Mockus, A. (2001), "Shared Mental Models and Coordination in Large-Scale, Distributed Software Development." International Conference in Information Systems, New Orleans
Evans, D. and Gruba, P. (2005), How to Write a Better Thesis, Melbourne University Press, Melbourne
Evans, J. R. and Jack, E. P. (2003), "Validating key results linkages in the Baldrige Performance Excellence Model", The Quality Management Journal, Vol.10, no 2, pp. 7-24.
Faraj, S. and Sproull, L. (2000), "Coordinating Expertise in Software Development Teams." Management Science, Vol.46, no 12, pp. 1554-1568.
Faulconbridge, R. I. and Ryan, M. J. (2003), Managing Complex Technical Projects: A Systems Engineering Approach, Artech House, Inc, Norwood
Fenton, N. (1994), "Software measurement: a necessary scientific basis", Software Engineering, IEEE Transactions on, Vol.20, no 0098-5589, pp. 199-206.
Fenton, N., Krause, P. and Neil, M. (2002), "Software measurement: uncertainty and causal modeling", IEEE Software, Vol.19, no 4, pp. 116-122.
Fenton, N. E. (2000), "Software metrics: roadmap", International Conference on Software Engineering, Limerick, ACM Press, pp. 357-370
Flamholtz, E. G., Das, T. K. and Tsui, A. S. (1985), "Toward an integrative framework of organizational control", Accounting, Organizations and Society, Vol.10, no 1, pp. 35-50.
Fleming, Q. W. and Koppelman, J. M. (1999a), "The Earned Value Body of Knowledge", Project Management Institute 1999 Seminars & Symposium, Philadelphia, PMI
Fleming, Q. W. and Koppelman, J. M. (1999b), Earned Value Project Management...an Introduction, In Crosstalk, July 1999
Fowler, M. (2003), The New Methodology, Available: http://www.martinfowler.com/articles/newMethodology.html, accessed October 2003
Fry, L. W. (1982), "Technology-structure research: Three critical issues", Academy of Management Journal, Vol.25, no 3, pp. 532-552.
Fry, L. W. and Slocum, J. W., Jr. (1984), "Technology, Structure, and workgroup effectiveness: A test of a contingency model", Academy of Management Journal, Vol.27, no 2, pp. 221-246.
Gallivan, M. J. and Depledge, G. (2003), "Trust, control and the role of interorganizational systems in electronic partnerships." Information Systems Journal, Vol.13, no 2, pp. 159-190.
Gallivan, M. J. and Oh, W. (1999), "Analyzing IT outsourcing relationships as alliances among multiple clients and vendors", Proceedings of the 32nd Annual Hawaii International Conference on System Sciences, pp. 15-29
Gasson, S. (1998), "Framing design: a social process view of information system development", International Conference on Information Systems, Helsinki, Association for Information Systems, pp. 224-236
Gemuenden, H. G. and Lechler, T. (1997), "Success factors of project management: the critical few-an empirical investigation", International Conference on Management and Technology, pp. 375-377
Ghemawat, P. (2001), "Distance Still Matters", Harvard Business Review, Vol.79, no 8, pp. 137-145.
Gilb, T. (1988), Principles of Software Engineering Management, Addison-Wesley Godart, C., Bouthier, C., Canalda, P., Charoy, F., Molli, P., Perrin, O., Saliou, H., Bignon, J. C.,
Halin, G. and Malcurat, O. (2001), "Asynchronous coordination of virtual teams in creative applications (co-design or co-engineering): requirements and design criteria", Workshop on Information Technology for Virtual Enterprises., Gold Coast, Australia, IEEE, pp. 135-142
Godart, C., Charoy, F., Perrin, O. and Skaf-Molli, H. (2000), "Cooperative workflows to
Bobliography
Page 211
coordinate asynchronous cooperative applications in a simple way", Seventh International Conference on Parallel and Distributed Systems, Iwate, Japan, IEEE, pp. 409-416
Goldenson, D. R. and Gibson, D. L. (2003), Demonstrating the Impact and Benefits of CMMI: An Update and Preliminary Results, Software Engineering Institute, CMU/SEI-2003-SR-009
Gomez-Mejia, L. R. and Palich, L. E. (1997), "Cultural diversity and the performance of multinational firms", Journal of International Business Studies., Vol.28, no 2, pp. 309-345.
Gorton, I., Hawryszkiewycz, I., Ragoonaden, K., Chung, C., Lu, S. and Randhawa, G. (1997), "Groupware support tools for collaborative software engineering", International Conference on System Sciences, Hawaii, IEEE, pp. 157-166
Grefen, P. and Hoffner, Y. (1999), "CrossFlow-cross-organizational workflow support for virtual organizations", Workshop on Research Issues on Data Engineering: Information Technology for Virtual Enterprises, Sydney, Australia, IEEE, pp. 90-91
Gregory, K. L. (1983), "Native-view paradigms: Multiple cultures and culture conflicts in organisations." Administrative Science Quarterly, Vol.28, no 3, pp. 359-376.
Grinter, R. E., Herbsleb, J. D. and Perry, D. E. (1999), "The Geography of Coordination: Dealing with Distance in R&D Work", Conference on Supporting Group Work, Phoenix, ACM Press, pp. 306 - 315
Grudin, J. (1994), "Groupware and social dynamics: eight challenges for developers", Communications of the ACM, Vol.37, no 1, pp. 92-105.
Gruhn, V. (1992), "Software processes are social processes", Fifth International Workshop on Computer-Aided Software Engineering, Montreal, IEEE, pp. 196-201
Grundy, J. C., Hosking, J. G. and Mugridge, W. B. (1998), "Coordinating distributed software development projects with integrated process modelling and enactment environments," 7th IEEE Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, Stanford, IEEE CS Press, pp. 39-44
Gwynne, P. (1995), "Managing `Multidomestic' R&D at ABB." Research technology Management, Vol.38, no 1, pp. 30-33.
Hamilton, R. D., III and Kashlak, R. J. (1999), "National Influences on Multinational Corporation Control System Selection", Management International Review, Vol.39, no 2, pp. 167-189.
Handfield, R. B. and Krause, D. R. (2000), "Avoid the Pitfalls in Supplier Development." Sloan Management Review, Vol.41, no 2, pp. 37-49.
Hansen, C. D. (1995), "Occupational cultures: Whose frames are we using?" Journal for Quality & Participation, Vol.18, no 3, pp. 60-64.
Hauptman, O. (1990), "The different roles of communication in software development and hardware R&D: Phenomenologic paradox or atheoretical empiricism?" Journal of Engineering and Technology Management, Vol.7, no 1, pp. 49-71.
Hawryszkiewycz, I. T. (1993), "Supporting coordination in CSCW systems", International Symposium on Autonomous Decentralized Systems, Kawasaki, Japan, IEEE, pp. 225-231
Hawryszkiewycz, I. T. and Gorton, I. (1996), "Distributing the software process", Australian Software Engineering Conference, Melbourne, Australia, IEEE, pp. 176-182
Henderson, J. C. and Lee, S. (1992), "Managing I/S Design Teams: A control Theories Perspective", Management Science, Vol.38, no 6, pp. 757-777.
Henderson-Sellers, B., Serour, M., McBride, T., Gonzalez-Perez, C. and Dagher, L. (2004), "Process Construction and Customization", Journal of Universal Computer Science, Vol.10, no 4, pp. 326-358.
Herbsleb, J., Carleton, A., Rozum, J., Siegel, J. and Zubrow, D. (1994), Benefits of CMM-Based Software Process Improvement: Initial Results, Software Engineering Institute, CMU/SEI-94-TR-013
Herbsleb, J. D. and Grinter, R. E. (1998), "Conceptual simplicity meets organizational
Bobliography
Page 212
complexity: case study of a corporate metrics program", 20th international conference on Software engineering, Kyoto, IEEE Computer Society, pp. 271-280
Herbsleb, J. D. and Grinter, R. E. (1999a), "Architectures, coordination, and distance: Conway's law and beyond", IEEE Software, Vol.16, no 5, pp. 63-70.
Herbsleb, J. D. and Grinter, R. E. (1999b), "Splitting the organization and integrating the code: Conway's Law revisited", International Conference on Software Engineering, Los Angeles, IEEE Computer Society
Herbsleb, J. D. and Mockus, A. (2003), "An empirical study of speed and communication in globally distributed software development", IEEE Transactions on Software Engineering, Vol.29, no 6, pp. 481-494.
Herbsleb, J. D., Mockus, A., Finholt, T. A. and Grinter, R. E. (2000), "Distance, dependencies, and delay in a global collaboration", Computer Supported Cooperative Work, Philadelphia, ACM Press, pp. 319-328
Herbsleb, J. D., Mockus, A., Finholt, T. A. and Grinter, R. E. (2001), "An empirical study of global software development: distance and speed", International Conference on Software Engineering, Toronto, IEEE Computer Society, pp. 81-90
Highsmith, J. and Cockburn, A. (2001), "Agile software development: the business of innovation", Computer, Vol.34, no 9, pp. 120-127.
Hobday, M. (1998), "Product complexity, innovation and industrial organization", Research Policy, Vol.26, no 6, pp. 689-710.
Hoegl, M. and Gemuenden, H. G. (2001), "Teamwork Quality and the Success of Innovative Projects: A Theoretical Concept and Empirical Evidence", Organization Science, Vol.12, no 4, pp. 435-449.
Hofstede, G. (1983a), "Cultural dimensions for project management", International Journal of Project Management, Vol.1, no 1, pp. 41-48.
Hofstede, G. (1983b), "National Cultures in Four Dimensions: A research based theory of cultural differences among nations", International Studies of Management and Organization, Vol.13, no 1-2, pp. 46-74.
Hofstede, G. (1991), Cultures and Organizations: Software of the Mind, McGraw-Hill, New York
Huber, R. L. (1993), "How Continental Bank outsourced its "crown jewels."", Harvard Business Review, Vol.71, no 1, pp. 121-129.
Hughes, B. and Cotterell, M. (1999), Software Project Management, McGraw-Hill, London Humphrey, W. S. (1989), Managing the Software Process, Addison-Wesley Publishing Humphrey, W. S. (1994), A Discipline for Software Engineering, Addison-Wesley Humphrey, W. S. (2000), The Team Software Process, Software Engineering Institute,
CMU/SEI-2000-TR-023 Hunter, R. and Jung, H.-W. (2000), "Some experiences and Results from the SPICE trials",
SPICE 2000 - International SPICE Conference, Limerick Ibbs, C. W. and Kwak, Y. H. (2000), "Assessing Project Management Maturity", Project
Management Journal, Vol.31, no 1, pp. 32-43. IEEE 1490:1998 - Adoption of PMI standard - a guide to the project management body of
knowledge ISO 9126-1:2001 - Software engineering - Product quality - Part 1: Quality model ISO 12207:2002 - Information technology -- Software life cycle processes - Amendment 1 ISO 15271:1998 - Information Technology - Guide for ISO/IEC 12207 (Software Life Cycle
Processes). ISO 15288:2003 - Systems engineering - System life cycle processes ISO 15504-1:1998 - Information Technology - Software Process Assessment ISO 15939:2002 - Software Engineering - Software Measurement Process ISO 16326:1999 - Software engineering - Guide for the application of ISO/IEC 12207 to project
management ISO 19760:2003 - Systems Engineering — A Guide for the application of ISO/IEC 15288
System Life Cycle Processes
Bobliography
Page 213
Jagodzinski, P., Parsons, R., Reid, F., Burningham, C. and Culverhouse, P. (1997), "Use of ethnography to acquire an insider's view of engineering design teams", Workshop on Soft Approaches to Product Introduction Improvement, Birmingham, UK, IEEE, pp. 1-5
Jarvenpaa, S. L. and Leidner, D. E. (1998), "Communication and Trust in Global Virtual Teams", Journal of Computer-Mediated Communications, Vol.3, no 4.
Jiang, J. J., Klein, G. and Ellis, T. S. (2002), "A measure of software development risk", Project Management Journal, Vol.33, no 3, pp. 30-41.
Johnson, J., Boucher, K. D., Conners, K. and Robinson, J. (2001), Collaborating on Project Success, Available: www.softwaremag.com/archive/2001feb/CollaborativeMgt.html, accessed July 17, 2002
Jones, C. (1994), Assessment and Control of Software Risks, Prentice-Hall Inc Jones, C. (1996), Patterns of Software Systems Failure and Success, International Thomson
Computer Press Jorgensen, M. (1999), "Software quality measurement", Advances in Engineering Software,
Vol.30, no 12, pp. 907-912. Jung, H.-W., Hunter, R., Goldenson, D. R. and El-Emam, K. (2001), "Findings from Phase 2 of
the SPICE trials", Software Process: Improvement and Practice, Vol.6, no 4, pp. 205-242.
Jyi-Shane, L. and Sycara, K. P. (1996), "Multiagent coordination in tightly coupled task scheduling", Second International Conference on Multi-Agent Systems., Menlo Park, CA, USA, AAAI Press, pp. 181-188
Kadefors, A. (2004), "Trust in project relationships--inside the black box", International Journal of Project Management, Vol.22, no 3, pp. 175-182.
Kanter, R. M. (1985), The Change Masters, Allen and Unwin, London Karlsson, E.-A., Andersson, L.-G. and Leion, P. (2000), "Daily build and feature development
in large distributed projects", International Conference on Software Engineering, Limerick, Ireland, ACM Press, pp. 649 - 658
Kataoka, N., Koizumi, H., Takasaki, K. and Shiratori, N. (1998), "Remote joint application design process using package software", Twelfth International Conference on Information Networking, pp. 495-500
Kerzner, H. (1998), Project Management: A Systems Approach to Planning, Scheduling, and Controlling., John Wiley & Sons, Inc, New York
Kirsch, L. J. (1996), "The Management of Complex Tasks in Organizations: Controlling the Systems Development Process." Organization Science, Vol.7, no 1, pp. 1-22.
Kitchenham, B. (1996), Software Metrics: Measurement for Software Process Improvement, NCC Blackwell Ltd
Kitchenham, B., Pfleeger, S. L. and Fenton, N. (1995), "Towards a framework for software measurement validation", IEEE Transactions on Software Engineering, Vol.21, no 12, pp. 929-944.
Kitchenham, B. A., Hughes, R. T. and Linkman, S. G. (2001), "Modeling software measurement data", IEEE Transactions on Software Engineering, Vol.27, no 9, pp. 788-804.
Kitchenham, B. A. and Walker, J. G. (1989), "A quantitative approach to monitoring software development", Software Engineering Journal, Vol.4, no 1, pp. 2-13.
Kontoghiorghes, C. (2003), "Examining the association between quality and productivity performance in a service organization", The Quality Management Journal, Vol.10, no 1, pp. 32-42.
Kornelius, L. and Wamelink, J. W. F. (1998), "The virtual corporation: learning from construction", Supply Chain Management, Vol.3, no 4, pp. 193-202.
Kraut, R. E. and Streeter, L. A. (1995), "Coordination in software development", Communications of the ACM, Vol.38, no 3, pp. 69-81.
Krishna, S., Sahay, S. and Walsham, G. (2004), "Managing Cross-cultural issues in global software outsourcing", Communications of the ACM, Vol.47, no 4, pp. 62 - 66.
Krishnan, V. (1998), "Modeling ordered decision making in product development", European
Bobliography
Page 214
Journal of Operational Research, Vol.111, no 2, pp. 351-368. Kumar, K. and Dissel, H. G. v. (1996), "Sustainable collaboration: Managing conflict and
cooperation in interorganizational systems", MIS Quarterly, Vol.20, no 3, pp. 279-300. Kwak, Y. H. and Ibbs, C. W. (2000), "The Berkeley project management process maturity
model: measuring the value of project management", Proceedings of the 2000 IEEE Engineering Management Society, pp. 1-5
Lacity, M. C. and Janson, M. A. (1994), "Understanding qualitative data: A framework of test analysis methods." Journal of Management Information Systems, Vol.11, no 2, pp. 137-155.
Lacity, M. C. and Willcocks, L. P. (1996), "The Value of Selective IT Sourcing." Sloan Management Review, Vol.37, no 3, pp. 13-25.
Lacity, M. C., Willcocks, L. P. and Feeny, D. F. (1995), "IT Outsourcing: Maximize Flexibility and Control." Harvard Business Review, Vol.73, no 3, pp. 84-93.
Lawlis, D. P. K., Flowe, C. R. M. and Thordahl, C. J. B. (1995), "A Correlational Study of the CMM and Software Development Performance", Crosstalk, Vol.8, no 9.
Lawrence, P. R. and Lorsch, J. W. (1967), High-performing Organizations in Three Environments, In Organization Theory: Selected Readings (Ed, Pugh, D. S.) Penguin Books, 1971.
Lederer, A. L. and Prasad, J. (1995), "Causes of inaccurate software development cost estimates", Journal of Systems and Software, Vol.31, no 2, pp. 125-134.
Leedy, P. D. and Ormrod, J. E. (2001), Practical Research: Planning and Design, Merrill Prentice Hall
Levesque, L. L., Wilson, J. M. and Wholey, D. R. (2001), "Cognitive divergence and shared mental models in software development project teams", Journal of Organizational Behavior, Vol.22, pp. 135-144.
Lientz, B. P. and Rea, K. P. (2003), International Project Management, Academic Press Liker, J. K., Sobek, D. K., II, Ward, A. C. and Cristiano, J. J. (1996), "Involving suppliers in
product development in the United States and Japan: evidence for set-based concurrent engineering", Engineering Management, IEEE Transactions on, Vol.43, no 2, pp. 165-178.
Linberg, K. R. (1999), "Software developer perceptions about software project failure: a case study", Journal of Systems and Software, Vol.49, no 2-3, pp. 177-192.
Loch, C. H. and Tapper, U. A. S. (2002), "Implementing a strategy-driven performance measurement system for an applied research group", Journal of Product Innovation Management, Vol.19, no 3, pp. 185-198.
Machiavelli, N. (1514), The Prince Majalian, K. A., Kleinman, D. L. and Serfaty, D. (1992), "The effects of team size on team
coordination", International Conference on Systems, Man and Cybernetics, Storrs, CT, IEEE, pp. 880-886 vol.1
Malone, T. W. and Crowston, K. (1994), "The interdisciplinary study of coordination", ACM Computing Surveys, Vol.26, no 1, pp. 87-119.
Mantei, M. (1981), "The effect of programming team structures on programming tasks", Communications of the ACM, Vol.24, no 3, pp. 106-113.
Martin, J. (2002), Organizational Culture: Mapping the Terrain, Sage Publications, Thousand Oaks
Massey, A. P., Hung, Y.-T. C., Montoya-Weiss, M. and Ramesh, V. (2001), "When culture and style aren't about clothes: perceptions of task-technology "fit" in global virtual teams", Conference on Supporting Group Work, Boulder, Colorado, ACM Press, pp. 207-213
Maurer, F. and Zannier, C. (2001), "4th ICSE workshop on "Software Engineering over the Internet"", ACM SIGSOFT Software Engineering Notes, Vol.26, no 6, pp. 29-31.
Mazza, C., Fairclough, J., Melton, B., Pablo, D. D., Scheffer, A. and Stevens, R. (1994a), Software Engineering Guides, Prentice Hall
Mazza, C., Fairclough, J., Melton, B., Pablo, D. D., Scheffer, A. and Stevens, R. (1994b), Software Engineering Standards, Prentice Hall
Bobliography
Page 215
McCarthy, J. (1995), Dynamics of Software Development, Microsoft Press, Richmond McConnell, S. (1998), Software Project Survival Guide, Microsoft Press McFarlan, F. W. and Nolan, R. L. (1995), "How to manage an IT outsourcing alliance." Sloan
Management Review, Vol.36, no 2, pp. 9-23. McGarry, J., CArd, D., Jones, C., Layman, B., Clark, E., Dean, J. and Hall, F. (2002), Practical
Software Measurement, Addison-Wesley Miller, P. (2004), Aegis configuration management, Available: http://aegis.sourceforge.net/,
accessed 20 July 2004 Milosevic, D. Z. (1987), "Organizing project control systems", International Journal of Project
Management, Vol.5, no 2, pp. 76-79. Mintzberg, H. (1979), The Structuring of Organizations, Prentice-Hall, Englewood Cliffs, N.J. Mockus, A. and Herbsleb, J. (2001), "Challenges of global software development", Seventh
International Software Metrics Symposium, London, IEEE, pp. 182-184 Moore, R. J. (2001), "Evolving to a "lighter" software process: a case study", 26th Annual NASA
Goddard Software Engineering Workshop, Maryland Univ. USA, IEEE Computer Society, pp. 14-21
Muller, F. (1982), "Definition of Construction Management", Specialty Conference on Engineering and Construction Projects, New Orleans, American Society of Civil Engineers, pp. 1-18
Muller, R. (2003), "Determinants for external communications of IT project managers", International Journal of Project Management, Vol.21, no 5, pp. 345-354.
Musa, J. D. (1997), "Introduction to software reliability engineering and testing", The Eighth International Symposium on Software Reliability Engineering, Albuquerque, NM, IEEE, pp. 3-12
Napier, B. J. and Ferris, G. R. (1993), "Distance in Organizations", Human Resource Management Review;, Vol.3, no 4, pp. 321-357.
Navon, R. and Goldschmidt, E. (2003), "Monitoring labor inputs: automated-data-collection model and enabling technologies", Automation in Construction, Vol.12, no 2, pp. 185-199.
Nicholson, B. and Sahay, S. (2001), "Some political and cultural issues in the globalisation of software development: case experience from Britain and India", Information and Organization, Vol.11, no 1, pp. 25-43.
Nidumolu, S. (1995), "The Effect of Coordination and Uncertainty on Software Project Performance: Residual Performance Risk as an Intervening Variable." Information Systems Research, Vol.6, no 3, pp. 191-219.
Nidumolu, S. R. (1996), "A comparison of the structural contingency and risk-based perspectives on coordination in software development projects", Journal of Management Information Systems, Vol.13, no 2, pp. 77-113.
OED (2003), Oxford English Dictionary, Available: http://dictionary.oed.com/, accessed Feb 2005
OGC (2002), Managing successful projects with PRINCE2., Office of Government Commerce, London
Ouchi, W. G. (1979), "A Conceptual Framework for the Design of Organizational Control Mechanisms", Management Science, Vol.25, no 9, pp. 833-848.
Ouchi, W. G. and Maguire, M. A. (1975), "Organizational Control: Two Functions." Administrative Science Quarterly, Vol.20, no 4, pp. 559-569.
Park, K. S. and Hwan Lim, C. (1999), "A structured methodology for comparative evaluation of user interface designs using usability criteria and measures", International Journal of Industrial Ergonomics, Vol.23, no 5-6, pp. 379-389.
Paulk, M. C., Curtis, B., Chrissis, M. B. and Weber, C. V. (1993), Capability Maturity Model for Software (Version 1.1), Software Engineering Institute, Pittsburgh, CMU/SEI-93-TR-024
Perkins, G. (1999), "Culture clash and the road to world domination", IEEE Software, Vol.16, no 1, pp. 80-84.
Bobliography
Page 216
Perpich, J. M., Perry, D. E., Porter, A. A., Votta, L. G. and Wade, M. W. (1997), "Anywhere, anytime code inspections: using the Web to remove inspection bottlenecks in large-scale software development", International Conference on Software Engineering, Boston, ACM Press
Perrow, C. (1986), Complex Organizations: A Critical Essay, Random House, New York Peters, T. J. and Waterman, R. H. (1982), In Search of Excellence: Lessons from America's
Best-Run Companies, Harper & Row, New York Potter, R. E. and Balthazard, P. A. (2002), "Virtual team interaction styles: assessment and
effects", International Journal of Human-Computer Studies, Vol.56, no 4, pp. 423-443. Project Management Institute (Ed.) (2000), A Guide to the Project Management Body of
Knowledge, Project Management Institute. Project Management Institute (2004), Organizational Project Management Maturity Model
(OPM3), Project management Institute Putnam, L. and Myers, W. (1992), Measures for excellence: reliable software on time, within
budget, Prentice-Hall Inc., Engelwood Cliffs, NJ Quinn, R. W. and Dutton, J. E. (2005), "Coordination as energy-in-conversation", The Academy
of Management Review, Vol.30, no 1, pp. 36. Raffo, D., Harrison, W. and Vandeville, J. (2000), "Coordinating Models and Metrics to
Manage Software Projects", Software Process Improvement and Practice, Vol.5, pp. 159–168.
Ring, P. S. and Van De Ven, A. H. (1994), "Developmental processes of cooperative interorganizational relationships." Academy of Management Review, Vol.19, no 1, pp. 20-48.
Ritzer, G. (2004), The McDonaldization of Society, Pine Forge Press, Thousand Oaks Roller, D., Eck, O. and Dalakakis, S. (2002), "Advanced database approach for cooperative
product design", Journal of Engineering Design, Vol.13, no 1, pp. 49-61. Ronen, S. and Shenkar, O. (1985), "Clustering Countries on Attitudinal Dimensions: A Review
and Synthesis." Academy of Management Review, Vol.10, no 3, pp. 435-454. Roth, K. and O Donnell, S. (1996), "Foreign subsidiary compensation strategy: An agency
theory perspective", Academy of Management Journal, Vol.39, no 3, pp. 678-703. Royce, W. (1998), Software project management : a unified framework, Addison Wesley,
Reading, MA RUP (2003), Rational Unified Process, Available:
http://www.rational.com/products/rup/prodinfo.jsp, accessed September 2003 Sabherwal, R. (2003), "The evolution of coordination in outsourced software development
projects: a comparison of client and vendor perspectives", Information and Organization, Vol.13, no 3, pp. 153-202.
Saunders, R. G. (1992), "Project management: a systems perspective", International Journal of Project Management, Vol.10, no 3, pp. 153-159.
Sawyer, S., Farber, J. and Spillers, R. (1997), "Supporting the social processes of software development", Information Technology & People, Vol.10, no 1, pp. 46-62.
Sawyer, S. and Guinan, P. J. (1998), "Software development: processes and performance", IBM Systems Journal [H.W. Wilson - AST], Vol.37, no 4, pp. 552-568.
Scandura, T. A. and Williams, E. A. (2000), "Research methodology in management: Current practices, trends, and implications for future research", Academy of Management Journal, Vol.43, no 6, pp. 1248-1264.
Scarola, J. A. and Tatum, C. B. (1982), "Definition of Project Management", Specialty Conference on Engineering and Construction Projects, New Orleans, American Society of Civil Engineers, pp. 1-18
Schein, E. H. (1996), "Three Cultures of Management: The Key to Organizational Learning." Sloan Management Review, Vol.38, no 1, pp. 9-20.
Seaman, C. B. (1999), "Qualitative methods in empirical studies of software engineering", IEEE Transactions on Software Engineering, Vol.25, no 4, pp. 557-572.
SEI (2000), CMMI for Systems Engineering/Software Engineering, Version 1.02, Carnegie
Bobliography
Page 217
Mellon University/Software Engineering Institute, Pittsburgh, CMU/SEI-2000-TR-019 SEI (2004a), Maturity Profile - CMMI, Available:
http://www.sei.cmu.edu/sema/profile_CMMI.html, accessed 17 August 2004 SEI (2004b), Process Maturity Profile: Software CMM, Available:
http://www.sei.cmu.edu/sema/profile_CMMI.html, accessed 17 August 2004 Selin, G. (1991), "Project management in decentralized organizations", International Journal of
Project Management, Vol.9, no 4, pp. 216-221. Shenhar, A. J. (1999), "Strategic project management: the new framework", Portland
International Conference on Management of Engineering and Technology, 1999., Portland, IEEE, pp. 382-386 vol.2
Shenhar, A. J. (2001), "One size does not fit all projects: Exploring classical contingency domains", Management Science, Vol.47, no 3, pp. 394-413.
Shenkar, O. (2001), "Cultural Distance Revisited: Towards a More Rigorous Conceptualisation and Measurement of Cultural Distance", Journal of International Business Studies, Vol.32, no 3, pp. 519-535.
Shina, S. G. (1991), "Concurrent engineering: new rules for world-class companies", Spectrum, IEEE, Vol.28, no 7, pp. 22-26.
Shumate, K. and Snyder, T. (1994), "Software project reporting: management, measurement, and process improvement", Annual International Conference on Ada, Baltimore, ACM Press, pp. 41-45
Simon, J.-M., El Emam, K., Rousseau, S., Jacquet, E. and Babey, F. (1997), "The reliability of ISO/IEC PDTR 15504 assessments", Software Process: Improvement and Practice, Vol.3, no 3, pp. 177-188.
Smith, G. F. and Browne, G. J. (1993), "Conceptual foundations of design problem solving", IEEE Transactions on Systems, Man and Cybernetics,, Vol.23, no 5, pp. 1209-1219.
Sobek, D. K. I., Ward, A. C. and Liker, J. K. (1999), "Toyota’s principles of set-based concurrent engineering." Sloan Management Review, Vol.40, no 2, pp. 67-82.
Solomond, J. P. (1996), "International high technology cooperation: lessons learned", Engineering Management, IEEE Transactions on, Vol.43, no 1, pp. 69-77.
Souder, W. E., Sherman, J. D. and Davies-Cooper, R. (1998), "Environmental uncertainty, organizational integration, and new product development effectiveness: a test of contingency theory", Journal of Product Innovation Management, Vol.15, no 6, pp. 520-533.
The Bugzilla Team (2005), The Bugzilla Guide, Available: http://www.bugzilla.org/docs/tip/html/, accessed 11 May 2005
Themistocleous, M., Irani, Z. and Love, P. E. D. (2004), "Evaluating the integration of supply chain information systems: A case study", European Journal of Operational Research, Vol.159, no 2, pp. 393-405.
Thomke, S. and Reinertsen, D. (1998), "Agile product development: managing development flexibility in uncertain environments." California Management Review, Vol.41, no 1, pp. 8-9.
Thomsett, R. (1989), Third Wave Project Management, Yourdon Press Computing Series, Upper Saddle River
Thomsett, R. (2002a), Radical Project Management, Prentice Hall PTR Thomsett, R. (2002b), Risk in Projects: The Total Tool Set, Available:
http://www.thomsett.com.au/main/articles/risk_0404/risk0404_toc.htm, accessed 17 August 2004
Tran, P. and Galka, R. (1991), "On incremental delivery with functionality", Tenth Annual International Phoenix Conference on Computers and Communications,, Scottsdale, AZ, IEEE Computer Society, pp. 369-375
Travis, L. (2004), "More Thoughtful Approach to Outsourcing Needed", Supply Chain Management Review, Vol.8, no 4, pp. 17-18.
Trochim, W. M. K. (2001), The Research Methods Knowledge Base, Atomic Dog Publishing, Cincinnati
Bobliography
Page 218
UTS (2005), Doctoral and Master's Degree by Thesis Assessment Procedures, Available: http://www.gradschool.uts.edu.au/policies/policiesprocess/Assessmentprocedure.html, accessed Feb 2005
Van Der Aalst, M. P. (1998), "Modeling and analyzing interorganizational workflows", 1998 International Conference on Application of Concurrency to System Design, Fukushima, Japan, IEEE Computer Society, pp. 262-272
Van Der Aalst, W. M. P. (1999), "Generic workflow models: how to handle dynamic change and capture management information?" International Conference on Cooperative Information Systems, Edinburgh, UK, IEEE Computer Society, pp. 115-126
Vogel, D. R., Van Genuchten, M., Lou, D., Verveen, S., Van Eekout, M. and Adams, A. (2001), "Exploratory research on the role of national and professional cultures in a distributed learning project", Professional Communication, IEEE Transactions on, Vol.44, no 2, pp. 114-125.
Wallace, L., Keil, M. and Rai, A. (2004), "Understanding software project risk: a cluster analysis", Information & Management, Vol.42, no 1, pp. 115-125.
Walz, D. B., Elam, J. J. and Curtis, B. (1993), "Inside a software design team: knowledge acquisition, sharing, and integration", Communications of the ACM, Vol.36, no 10, pp. 63-77.
Ward, A., Liker, J. K., Cristiano, J. J. and Sobek, D. K. I. (1995), "The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster." Sloan Management Review, Vol.36, no 3, pp. 43-59.
Watson, W. E., Kumar, K. and Michaelson, L. K. (1993), "Cultural diversity's Impact on interaction processes and performance: Comparing homogenous and diverse task groups", Academy of Management Journal, Vol.36, no 3, pp. 590-602.
Williamson, K., Burstein, F. and McKemmish, S. (2002), The two major traditions of research, In Research methods for students, academics and professionals (Eds, Whitten, P. and Salmond, R.) Centre for Information Studies, Wagga Wagga.
Witting, K., Challenger, J. and O'Connell, B. (2003), "Monitoring distributed systems: a publish/subscribe methodology and architecture", IFIP/IEEE Eighth International Symposium on Integrated Network Management, pp. 89-92
Wolf, M. L. J. (1989), "Project planning and controlling in software development", International Journal of Project Management, Vol.7, no 4, pp. 223-227.
Womack, J. P., Jones, D. T. and Roos, D. (1990), The Machine that Changed the World, Rawson Associates, New York
Wood, M., Daly, J., Miller, J. and Roper, M. (1999), "Multi-method research: An empirical investigation of object-oriented technology", Journal of Systems and Software, Vol.48, no 1, pp. 13-26.
Woodward, J. (1958), Management and Technology, In Organization Theory (Ed, Pugh, D. S.) Penguin Books, London, HMSO.
Yates, M. K. and Tatum, C. B. (1982), "Definition of Engineering Management", Specialty Conference on Engineering and Construction Projects, New Orleans, American Society of Civil Engineers, pp. 1-18
Yin, R. K. (2003), Case Study Research: Design and Methods, Sage, Thousand Oaks Youker, R. (1999), "Managing International Development Projects - Lessons Learned." Project
Management Journal, Vol.30, no 2, pp. 6-7. Yusuf, Y. Y., Gunasekaran, A., Adeleye, E. O. and Sivayoganathan, K. (2004), "Agile supply
chain capabilities: Determinants of competitive objectives", European Journal of Operational Research, Vol.159, no 2, pp. 379-392.
Zeng, A. Z. (2003), "Global sourcing: process and design for efficient management", Supply Chain Management, Vol.8, no 4, pp. 367-379.
Zhuge, H. (2002), "Knowledge flow management for distributed team software development", Knowledge-Based Systems, Vol.15, no 8, pp. 465-471.
Zhuge, H. (2003), "Workflow- and agent-based cognitive flow management for distributed team Cooperation", Information & Management, Vol.40, no 5, pp. 419-429.
Bobliography
Page 219
Zmud, R. W. (1980), "Management of Large Software Development Efforts", MIS Quarterly, Vol.4, no 2, pp. 45-55.
