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
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
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 mysupervisors. 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
1.2 Scope ... 6 1.3 Research strategy... 6 1.4 Contributions ... 7 1.4.1 Theoretical contributions. ... 8 1.4.2 Empirical contributions... 91.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
Page iv
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
Page v
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
Page vi
Figure 3: Task interdependence - coordination strategy. An organic coordination strategy ismore 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
Table 2: Hughes and Cotterell’s (1999) classification of project report types according toformality 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
Page viii
Table 31: Correlations between the number of monitoring practices used by project managersand 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
Page ix
Table 61: Coordination mechanism usage as a percentage of mechanisms within eachorganizational 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
Page x
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
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
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.htmlOrganic
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
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
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 themechanisms 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
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.
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
Page 5
whom may be quite distant, places challenges on the established knowledge of projectmonitoring, 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?
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
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
1The 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.
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
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 betweenorganizational 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.
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.
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,
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
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
Page 15
research. Subjects of monitoring will be identified from available software developmentliterature 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
Page 16
the types of information sought in software development projects before concluding howchanges 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
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
