The Journal of Systems and Software 81 (2008) 2386–2395

Contents lists available at ScienceDirect

The Journal of Systems and Software

journal homepage: www.elsevier.com/locate/jss

The mechanisms of project management of software development

Tom McBride *
Faculty of Information Technology, University of Technology, No. 1 Broadway, Sydney 2007, Australia

a r t i c l e i n f o a b s t r a c t

Article history: The changing environments of software development such as component-based, distributed and outsour-
Received 29 August 2005 ced software development require matching changes by project managers to monitor, control and coor-
Received in revised form 10 June 2008 dinate their projects. While the objectives of project management may be well established, the
Accepted 12 June 2008
mechanisms with which those objectives are achieved are less well known. An empirical study was
Available online 20 June 2008
undertaken to investigate which mechanisms were used by practising project managers to monitor, con-
trol and coordinate software development projects.
Keywords:
First, the types of mechanisms are discussed so that the mechanisms can be classified usefully. Then, the
Software development
Project management
design of the empirical study is described. The data were collected through structured interview, which
Project monitoring provided both quantitative and qualitative data. The data are analysed for each mechanism separately
Project control and the findings presented. The study found that project managers use multiple mechanisms to achieve
Project coordination project management objectives and use the same mechanism to serve multiple objectives. Further
Empirical study research is suggested to investigate project management from the opposite orientation, that is, which
objectives are served by specific project management mechanisms.
Ó 2008 Elsevier Inc. All rights reserved.

1. Introduction software. Nor does the research investigate activities undertaken

after the software’s development such as deployment or support
As software development projects adapt to changing circum- and maintenance for similar reasons. Concentrating on the devel-
stances, management of those projects must also adapt. Such opment phase means that project managers of all projects are
changes could involve adopting different development life cycles, likely to consider the same range of project management mecha-
moving to component-based software development or distributing nisms, the choice of which is likely to be subject to a similar range
the development. While the project management objectives may of influences.
remain the same, the mechanism used to achieve those objectives
will not necessarily remain unchanged and adaptation would be 2. Project monitoring
assisted through understanding which mechanisms are used in dif-
ferent circumstances. Such knowledge of the mechanisms could Project monitoring is the gathering of information to determine
guide the ways in which project managers adapt to different pro- the current state and progress of the project in relation to its ex-
ject environments as well as guide efforts to develop project work- pected state and progress (Shumate and Snyder, 1994; Al-Jibouri,
flow and project management tools. 2003; Navon and Goldschmidt, 2003). Frequently, project monitor-
This research investigates the mechanisms of project monitor- ing supports project control and is so frequently associated with
ing, control and coordination during the project’s development project control that the two are treated as inseparable (Davies
phase. It concentrates on the development phase because that is and Saunders, 1988; Hughes and Cotterell, 1999; Cleland and Ire-
when the project is subject to the unexpected events and external land, 2002; OGC, 2002; Burke, 2003). Yet project monitoring and
influences that require the project manager to take action to keep project control are not the same activity, nor are they inseparable.
the project moving toward its objectives. It does not investigate Control involves directing efforts toward some end objectives
project planning or any other activity that might be undertaken (Ouchi and Maguire, 1975; Eisenhardt, 1985; Kirsch, 1996) and
by the project manager prior to the start of actual software devel- sometimes considers information gathering to be part of the con-
opment because project management during that phase is con- trol activities. While this is a useful view when studying organiza-
cerned with producing the project plan, not developing the tional control, it excludes information gathering for other purposes
such as quality assurance (Shumate and Snyder, 1994; Kitchen-
ham, 1996; Fenton, 2000; McGarry et al., 2002) or coordination
* Tel.: +61 2 9514 4528; fax: +61 2 9514 4535. (Crowston, 1991; Kraut and Streeter, 1995; Carmel, 1999; Faraj
E-mail address: mcbride@it.uts.edu.au and Sproull, 2000; Zhuge, 2002; Sabherwal, 2003).

0164-1212/$ - see front matter Ó 2008 Elsevier Inc. All rights reserved.
doi:10.1016/j.jss.2008.06.015
 T. McBride / The Journal of Systems and Software 81 (2008) 2386–2395 2387

Coordination by
Does the mechanism High Low
A priori standards
specify the rules for
specification performing the task
or the goals to be
achieved?
Coordination by plans
Does the mechanism
rely on a priori
specification of a
blueprint of action, or
adjustments using Coordination by
information obtained formal mutual
during the project? adjustment

Are the adjustments

made in a formal, Low High
Mutual structured fashion or Coordination by
adjustment an informal, informal mutual Fixed Variable
unstructured fashion? adjustment costs costs

Fig. 1. The classification of coordination mechanisms – from Sabherwal (2003).

In this discussion, it is useful to separate monitoring from both (Kerzner, 1998; Hughes and Cotterell, 1999; Project Management
control and coordination so that monitoring mechanisms can be Institute, 2000; Raffo et al., 2000; Cleland and Ireland, 2002).
identified independently of the intended use of the information, There appear to be two main bodies of knowledge that deal
and so that the effect of organizational distance on monitoring with the problem of organizational control: control theory and
can be considered independently. agency theory. Organizational control theory concerns ‘‘attempts
A search of the literature revealed that monitoring mechanisms by the organization to increase the probability that individuals
seem to fall into four groupings: and groups will behave in ways that lead to the attainment of
organizational goals” (Flamholtz et al., 1985). Organizational con-
 Automatic monitoring. Information that can be gathered auto- trol theory is very general, applying to any organization in any
matically from software development or project management circumstance. In contrast, agency theory (Eisenhardt, 1989) con-
tools and systems. siders the problem of organizational control in the specific cir-
 Formal monitoring. Information that is gathered through a formal cumstance where an agent is carrying out work on behalf of a
administrative system. principal, such as may occur when work is sub-contracted or
 Ad hoc monitoring. Information gathered through irregular outsourced.
enquiry such as audits and reviews. Ouchi (1979) studied organizational control mechanisms,
 Informal monitoring. Information gathered informally through identifying three types: market, bureaucratic and clan mecha-
conversations or their equivalent. nisms. Ouchi proposed that the choice of control mechanism de-
pended on knowledge of the transformation process and the
The groupings reflect the same separation based on fixed and ability to measure outputs. Eisenhardt (1985, 1989) later exam-
variable costs that was proposed by Sabherwal (2003) for project ined the role of control in agency theory using Ouchi’s model
coordination (Fig. 1). Fixed costs are those costs incurred to estab- but extended it to include the agent’s attitude to risk. This re-
lish the mechanism and would include such costs as initial pur- sulted in a model that predicted whether outcome control or
chases, training, installation and configuration of any required behaviour control would be favoured. Henderson and Lee
tools. Variable costs are those costs that are incurred each time (1992) found that, within information system (IS) design teams,
the monitoring activities are performed. The more formal monitor- behaviour control and outcome control would coexist within
ing activities tend to incur higher fixed costs because people must the same project. The project manager exerted behaviour control
be trained in their use, but lower variable costs. Informal and ad while the team itself exerted outcome control within the team.
hoc monitoring mechanisms such as face to face meetings or Kirsch (1996) investigated the use of different control mecha-
tele-conferences tend to require little or no training but incur the nisms in IS development but, in contrast to Henderson and Lee,
same expense each time. focussed on relations between the project controller and the pro-
ject team. It is not clear whether the term ‘‘project controller”
3. Project control used by Kirsch refers to the project manager who is part of the
project team or to a manager external to the development team
Organizational control is exercised through actions taken to such as a client. Hamilton and Kashlak (1999) examined a multi-
move the organization toward its objectives (Ouchi and Maguire, national corporation’s selection of a subsidiary’s control system
1975; Eisenhardt, 1985; Flamholtz et al., 1985; Kirsch, 1996). The under various host country’s conditions. They extended the con-
scope of theoretical work on organizational control is normally tingencies to include the host financial policies, cultural distance
the entire organization. However, nothing in the established theo- and political restrictions in addition to the task programmability
ries requires a minimum size of organization or particular type of and output measurability used by Ouchi and Maguire (1975),
organization. Thus, it is valid to apply theories of control to a pro- Ouchi (1979). The control mechanisms used by Hamilton and
ject team. Restricting the scope of control to that of a project with- Kashlak in their analysis were output, behaviour and input con-
in the organization retains the sense that control relates to efforts trol where input control was similar to, but not the same as, clan
made or actions taken to move the project toward its objectives control (Ouchi, 1979, also Section 2.3.).
2388 T. McBride / The Journal of Systems and Software 81 (2008) 2386–2395

The four types of control mechanism thus far identified are: Sabherwal (2003) additionally lists design review meetings,
reporting requirements and liaison roles among the formal
 Output control: Exercised by measuring and rewarding results mutual adjustment mechanisms.
without concern for how those results were obtained.  Coordination by informal mutual adjustment. Informal mutual
 Behaviour control: Achieved through prescribing behaviour to be adjustment is the most flexible all the types of coordination
followed is referred to as behaviour control (Ouchi and Maguire, mechanisms but comes with a high variable cost (Sabherwal,
1975). 2003).
 Clan control: Exercised through adherence to shared values.
When tasks are inherently ambiguous, and a precise description
of how the task is to be performed is impossible, control is exer- 5. Which mechanisms do project managers use?
cised through shared beliefs about how the work should be per-
formed (Ouchi, 1979). So far, it is difficult to find information about which mecha-
 Input control: Exercised through recruitment and training. nisms project managers actually use. There has been investigations
(Hamilton and Kashlak, 1999) 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 (Cho-
4. Project coordination udhury and Sabherwal, 2003), as well as the more theoretical re-
search into the influence of national cultures on the selection of
Coordination is concerned with managing the interdependen- control mechanisms (Hamilton and Kashlak, 1999). Selection of
cies between activities (Malone and Crowston, 1994) or among project coordination mechanisms has been investigated in relation
multiple individuals involved in an activity (Kraut and Streeter, to risk (Nidumolu, 1996) and the type of coordination mechanism
1995). The purpose of coordination, as Kraut and Streeter point (Andres and Zmud, 2002). Kraut and Streeter (1995) examined the
out, is to ‘‘coordinate the work so that it gets done and fits together, more general aspects of how coordination was achieved in soft-
so that it is not done redundantly, and so that the components of ware development but any investigation into project monitoring
the work are handed off expeditiously.” mechanisms is difficult to find.
The most frequently cited definition of coordination is that of Thus, the research question is
Malone and Crowston (1994) in which coordination is defined as
RQ1: Which mechanisms do project managers use to monitor,
‘‘managing the dependencies between activities”. Their analysis con-
control and coordinate software development projects?
siders shared resources, producer/consumer relationships, simul-
taneity constraints and task/subtask dependencies. Thus, their It is useful to divide this research question into three so that
model considers the relationships between actors, actions, the monitoring, controlling and coordination can be investigated
acted upon and the constraints that may operate on combinations separately.
of all three.
RQ1.1: Which mechanisms do project managers use to monitor
Sabherwal (2003) examined prior literature to arrive at a broad
software development projects?
classification of coordination mechanisms into plan, standard, for-
RQ1.2: Which mechanisms do project managers use to control
mal mutual adjustment and informal mutual adjustment. The
software development projects?
mechanisms identified by Sabherwal are distinguished by their
RQ1.3: Which mechanisms do project managers use to coordi-
fixed and variable costs. The more formal coordination mecha-
nate software development projects?
nisms have higher initial costs but lower variable costs. The less
formal mechanisms have a lower initial cost but higher variable
costs as illustrated in Fig. 1. 6. Research design
The available models of coordination (Adler, 1995; Nidumolu,
1996; Andres and Zmud, 2002; Sabherwal, 2003) all display some The research data were gathered by interviewing software
form of continuum from more formal and less interactive to less development project managers, guided by the research instrument.
formal and more interactive. Since this research needs to identify The interviews were audio recorded, transcribed and checked by
the different coordination mechanisms rather than deal with an the interviewed project manager.
undifferentiated group of mechanisms, it will adopt the classifica- The chosen data collection method of structured interview used
tions proposed by Sabherwal as a result of considering the body of questions designed to yield both quantitative data and qualitative
research concerning coordination mechanisms; that is, plan-based, data. Questions and responses can be clarified, new information
standards-based, formal mutual adjustment and informal mutual provided and accepted. More of the subject’s general knowledge
adjustment. can be elicited than is possible with other techniques, and inter-
views can expose issues that the subject had not thought of previ-
 Coordination by standards. The distinguishing feature of this type ously (Seaman, 1999; Wood et al., 1999).
of mechanism is that it is concerned with the rules by which This ability to clarify a question or a response was attractive
something is done rather than the goals that guide the develop- since questions that appear very clear to the researcher are not al-
ment (Sabherwal, 2003). ways clear to the subject. Some questions, such as those designed
 Coordination by plans. When coordination is achieved by specify- to characterise the organization, are more amenable to providing a
ing what is to be produced and, possibly, when it is to be pro- list of possible responses and could have been given in a survey.
duced, then this can be described as coordination by plans Generally, such topics have a known range of responses and it is
(Sabherwal, 2003). possible to develop a set of categorical or quantitative responses
 Coordination by formal mutual adjustment. Overcoming some from which the respondent is expected to choose. However, other
problems requires some form of mutual adjustment, some of information could only have been sought through an open ques-
which can be formalized into specific actions or mechanisms. tion where the interviewer must work hard to avoid imposing
Kraut and Streeter (1995) offer modification request tracking their view of both the question and the expected responses (Yin,
and data dictionaries as examples of formal mutual adjustment. 2003 p. 61).
 T. McBride / The Journal of Systems and Software 81 (2008) 2386–2395 2389

6.1. Research instrument 6.2. Conducting the interviews

The questionnaire that guided the structured interview, was Interviews were mostly conducted at the subject’s premises and
based on assessment models and data collection methods used in at a time convenient to them. The research was introduced and de-
SPICE assessments (ISO 15504, 2004). The questionnaire was made scribed; then the subjects were asked to sign the consent form that
up of 49 questions developed by identifying the constructs needed explained the researcher’s obligations. Permission was sought from
for the research, then devising questions to gather data for the con- each participant to record the interview. All participants agreed to
structs. The questions were then allocated to a question category this request and even though the offer was made to turn the recor-
that related to the subject area so that questions could be asked der off during the interview, only one subject requested that be
in logical groupings and the interview could deal with each subject done for a brief period.
area without having to return to it. The interview questions were Each interview lasted between twenty minutes to just over one
then linked to a research question so that the interview questions hour. The duration depended on how much detail the subject
could be reported by research question or by construct. Listing wanted to provide. At the end of the interview, subjects were told
them in the different ways permitted checking that each construct that the recorded interview would be transcribed and emailed to
and research question was adequately covered and that there was them for checking. The objective of checking was to have the tran-
not an undue concentration in any one area. Some interview ques- script say what they wanted to say rather than to be a literal record
tions would provide information that related to more than one re- of the interview. This was to allow a subject to change their answer
search question. if, after reflection, they thought of additional information or a bet-
A list of possible or probable responses was developed for each ter way to express their answer. It also afforded the opportunity to
question. When the question sought an ordinal response, an ordi- change an answer they found embarrassing once they saw it in
nal scale of responses was developed. When the question sought print. None of the subjects altered a response for this reason.
nominal information, a list of the more expected responses was Each interview was transcribed as soon after the interview as
developed. This aided note-taking during the interview and added possible to preserve accuracy and to overcome audibility problems
context to the question so that if the subject found the question that can sometimes make it difficult to hear precisely what was
ambiguous there was additional information available to clarify being said. Generally, transcribing was completed within the same
it. For example, the first question sought a measure of the size of week. Each interview took between 3 and 6 hours to transcribe and
the project, an ordinal measure. A question on the type of system averaged 10 pages in length. There were 321 pages of transcript in
being developed listed the industry sectors for which, from the re- total.
searcher’s experience and knowledge of the local software devel- Recording and transcribing the interviews also provided consid-
opment industry, software was developed (Table 1). erable raw data for content analysis, giving a different view of the
Specific terminology used in this research do not necessarily same interview. Multi-method research helps to overcome the per-
mean the same thing to all project managers. For example, to ceived weaknesses in single-shot approaches (Wood et al., 1999).
one project manager the term ‘‘project monitoring” might mean Using the two different views of the data, a quantitative survey re-
only those activities that directly seek information while to an- sponse and a content analysis, is not as strong as would be analysis
other it might mean all activities that yield information about of two separate sets of data gathered by different research tech-
the project. For this reason, project managers were not directly niques, but is claimed to be stronger than either one of the tech-
asked ‘‘How do you monitor your projects?” but were, instead, niques used separately.
asked how they dealt with a situation. Their responses yielded
information on project monitoring, project control and project
6.3. Sample selection
coordination.
The total number of questions was constrained by the time that
Subject selection used a combination of self selection and acci-
it was thought each interview would take. While most people are
dental selection. An initial list was drawn up of organizations
prepared to spend up to an hour on a research project such as this,
located in Sydney and known to develop software. Each organiza-
asking for more than one hour of their time was thought likely to
tion was phoned and a request was made to speak to a project
discourage participation.
manager. Accidental selection was performed through phoning
organizations listed in the ‘‘Computer Software and Packages” sec-
tion of the Sydney Yellow Pages. No record was kept of how many
organizations were approached. However, after reviewing the re-
Table 1 tained section of the Yellow Pages, I estimate that approximately
Example questions from the structured interview script showing an ordinal scale of 400 organizations were approached. Thirty two interviews were
responses and a nominal list of potential responses
conducted with people from twenty eight organizations. The
5 How large is your project(s). The measure of size could be one of budget, acceptance rate is approximately 7%.
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.4. External validity
Small – <6 months, $100 K
Medium – 1 year < $1 M
Large – >1 M External validity is the extent to which the findings may be gen-
6 What type of system is being developed? eralised to other contexts (Leedy and Ormrod, 2001). The sample
Financial, ERP, CRM, SRM size of 32 project managers belonging to 28 different organizations
Military is small for quantitative research. While it may be large enough to
Infrastructure
perform some simple statistical tests such as Pearson’s correlation
Telecommunications
Medical or a Chi-square test, it is not large enough for any multivariate
Transport analysis. Even within the sample, some of the tests did not have
Services sufficient occurrences in each category to get a result. Therefore,
Factory automation
the findings of this research are not considered generalizable but
Other
may be a useful of further research.
2390 T. McBride / The Journal of Systems and Software 81 (2008) 2386–2395

7. Analysis 100

90
The first type of data are the question responses encoded
according to the devised response scale or category. These data 80
are amenable to statistical analysis. The second set of data comes 70
from content analysis of the interview transcripts. These, too, are
amenable to quantitative analysis. The third set of data is the inter- 60
view transcripts themselves, which can be examined qualitatively 50
for themes that contribute to understanding the research question.
Yin (2003) argues that case study data analysis, by following the 40
theoretical propositions and by testing rival propositions, are 30
stronger analytical strategies than the third strategy of developing
20
a descriptive framework with which to organize the data.
Content analysis most commonly counts the frequency with 10
which something is mentioned as indicating its importance (Lacity
0

Defect list
judgment
and Janson, 1994). This analysis seeks to identify the different

Progress

statistics
Earned
Expert

Value

Risks

Test
mechanisms used by project managers to monitor, control or coor-
dinate their projects. Of interest was the number of the different
project management mechanisms rather than any indication of
Fig. 2. Project manager responses to the question of how they established the
importance accorded them by the project manager.
project was ‘‘on track”.
Each interview is a small, albeit narrow, case study conducted
to explore the research question that the choice of project manage-
ment mechanisms will depend on the organizational distance be-
tween the project manager and elements of the project team. manager to be counted, there needed to be clear indications that
Each interview is examined for themes that support the research the implementation of the mechanism was separate. For example,
question, or that support possible rival propositions. projects often have team meetings and formal meetings with the
Qualitative analysis is better able to reveal the reasons for ac- organization’s management. Both are formal monitoring mecha-
tions, why a decision was made or a project management mecha- nisms and if a project manager indicated that both were used then
nism was chosen, and to give depth and meaning to a complex the count of formal monitoring mechanisms was two. However, if
situation (Leedy and Ormrod, 2001). While this research primarily the project manager simply referred to ‘‘meetings” and did not dis-
investigates which project management mechanisms are used and tinguish team meetings from management meetings, then only
the relationship between organizational distance and the use of one formal monitoring mechanism was recorded.
project management mechanism, augmenting the quantitative
analysis with qualitative analysis may give a deeper understanding 7.1.3. Qualitative analysis
of the results. 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.
7.1. Project monitoring
Almost without exception, project monitoring is seen as a pro-
cess of maintaining awareness of progress through the planned
This part of the analysis investigates the second sub-question.
schedule. Less frequently, project managers maintained an aware-
That is:
ness of any threats to progress through their monitoring activities.
RQ1.1: Which mechanisms do project managers use to monitor Data on the completion of scheduled tasks was gathered in a num-
software development projects? ber of ways: verbal reports during team meetings, written reports
submitted by the team member, updating a common file and,
The analysis will be performed using data from both the struc-
sometimes, casual conversations. In some of the larger organiza-
tured interview ‘‘check list” responses and from the content anal-
tions, team members appeared to have submitted their reports to
ysis of the interview transcripts. Data from each will be
an administration assistant who then prepared a report for the pro-
presented separately so that the origins of inferences are clear.
ject manager.
Some conclusions will be drawn about which mechanisms are
The structured interview questions dealt with knowing
preferred.
whether the project was ‘‘going right” or ‘‘going wrong” to estab-
lish which information, of all the information the project manager
7.1.1. Structured interview data
may receive in a given period, they most used in order to deter-
Project managers were asked how they established that the
mine the state of the project. The most common response was that
project was ‘‘on track” and, in a separate question, how they de-
the project’s progress was checked against expected progress. For
tected that the project was ‘‘not on track”. The responses were
some, this was determined by task completions, for some by
grouped as shown in Fig. 2. The data indicate that expert judge-
earned value and for some by milestone completion.
ment and various progress measures are used significantly more
than other measures such as earned value or test data.
7.1.4. Findings

7.1.2. Content analysis  The majority of project managers monitor their projects through
Project managers might use different mechanisms to determine the formal mechanisms of team meetings and schedule tracking.
project progress, for example, so the interview transcripts were This is supplemented with informal conversations with the pro-
examined to determine what type of mechanism was used to mon- ject team, afforded by co-location, and conversations with the
itor the project. Project managers could employ multiple monitor- customer.
ing mechanisms on the same project. In order for more than one  The majority of project managers use multiple monitoring
monitoring mechanism of the same type used by the same project mechanisms to track the status of the project.
 T. McBride / The Journal of Systems and Software 81 (2008) 2386–2395 2391

 Project managers do not consciously use automated monitoring was surprise because performance, in terms of system throughput,
to any significant extent. Similarly there are a number of mech- is seldom specified and is not usually thought of as something that
anisms such as phase end reviews, design reviews and project can be traded against project schedule. During the interviews, it
bulletin boards that are used by a minority of project managers. was explained that system performance might have been ex-
While these mechanisms may be essential in some circum- pressed as a required response time or a required transaction
stances and prove very valuable, their use is not widespread as throughput. The clarification seldom altered the respondent’s
a means of monitoring the project. answer.
Quality targets were also rarely knowingly compromised to
meet schedule commitments. Project managers did acknowledge
7.2. Project control that they would sometimes deliver a release with reduced quality
(more defects than expected) when it could be followed up with a
This part of the analysis investigates the second sub-question. ‘‘patch release” that rectified the defects.
That is: Most of the time it was functionality that was traded against
project schedule, as illustrated in Fig. 3. When negotiating project
RQ1.2: Which mechanisms do project managers use to control
objectives with the project stakeholders, it is functionality that is
software development projects?
most often negotiated.
Project control seeks to ensure that people act in a way consis-
tent with achieving the desired objectives (Choudhury and 7.2.1. Content analysis
Sabherwal, 2003). Project managers normally have the three objec- To gain a different perspective of project control mechanisms,
tives of schedule, functionality and quality to juggle by sacrificing the interview transcripts were examined for evidence that project
one to achieve the others. This research added system performance managers used different types of control mechanisms (Table 2).
to the list of objectives because there are some systems, for exam- The classification of the mechanism types and reasons for their
ple real time control systems, where performance is just as impor- selection has previously been discussed. Briefly, the types of con-
tant as functionality. trol mechanisms are output, behaviour, input and clan control.
The structured interview questions took a simple view of pro- The frequency with which specific control mechanisms were men-
ject control. Project managers were asked how the organization tioned in the interview transcripts is given in Table 3.
prioritised their success criteria and how the project manager exer- Of the output control mechanisms, the most frequently used is
cised project control in response to delays in project task comple- some combination of budget, schedule and functionality that is
tion. The content analysis sought evidence of the different types of normally part of the project’s general objectives. This is not sur-
control mechanisms project managers employed during the pro- prising since those objectives, or constraints, drive project plan-
ject. Thus, the analysis of the data from the structured interviews ning. The frequency or ‘‘other output control” is made up of;
focussed on what the project manager did to control the project acceptance testing or other form of formal testing (12 instances),
while the content analysis focussed on the mechanisms with a financial measure over and above meeting the project’s budget
which they did it. such as ‘‘profitability” (5 instances) or some measure of organiza-
Project managers were asked what they would do when some tional target such as meeting Key Performance Indicators or KPI
event delayed the completion of a task. This is a normal decision (7 instances).
faced by project managers when one or more of the project tasks Of the behaviour controls, the project plan is used without
is taking longer than expected or is more difficult to implement exception. The data does not distinguish between different types
than expected. Sometimes functionality, quality or performance of project plan nor is there any measure of the project plan’s gran-
is retained at the expense of the schedule. The most common re- ularity. Nevertheless, the universal use of a project plan indicates a
sponse in this research was that the decision depended on the sit- wide consensus on its value as a control mechanism.
uation. The frequency of the different responses is shown in Fig. 3. Project managers were asked directly if they, or their organiza-
Performance targets for the software being developed were tion, used formal development processes. The processes that were
either not set (15% of responses) or always retained (27% of re- considered to qualify as ‘‘formal” did not need to be those that
sponses). A more correct interpretation of ‘‘always retained” would
be that performance was not knowingly compromised to achieve
other project or product objectives. Frequently the initial response Table 2
Frequency of monitoring mechanisms detected with content analysis

Monitoring mechanism Count Percent

100.00
Automatic CSCW, Workflow 2 6.3
Functionality Configuration management 6 18.8
80.00 Defect, issue tracking 9 28.0
Automated integration & testing 3 9.4
60.00 Quality Release management 12 37.5
Development cycle 11 34.4
Performance Project bulletin board 1 3.1
40.00
Formal Monitoring Product review/inspections 6 18.8
Schedule & milestone tracking 30 94.0
20.00 Team meetings 30 94.0
Status reports 28 87.0
0.00 Management review 24 75.0
marketing

stakeholders
Engineers
retained

decides

Customer review 10 31.0

Project
Review
Always

Negotiated
decides
board
decide

Ad hoc monitoring QA or process audit 6 18.8

with

Phase end review 9 28.0

Drill down inquiry 20 62.5
Informal monitoring Conversations with project team 26 81.0
Conversations with stakeholders 9 28.0
Fig. 3. Trade-off between functionality, quality and performance over schedule Conversations with customer 18 56.0
when the schedule is threatened.
2392 T. McBride / The Journal of Systems and Software 81 (2008) 2386–2395

Table 3  The majority of project managers reported that their project was
Frequency of control mechanism used by software development project managers controlled by the project objectives, commonly functionality,
Control mechanism Count Percent budget and delivery date. The majority of project managers were
Output control Budget, schedule, functionality 28 87.5 also subject to additional project objectives which could be
Customer satisfaction 18 56.3 financial or organizational.
Contract T&C 12 37.5  Co-location and informal communication were employed by a
Other output control 23 71.9 majority of project managers as a means of clan control but
Behaviour control Formal processes 22 68.8
Process training 10 31.3
the choice of mechanisms in this category were less distinct
Project plan 32 100.0 than in the other categories of control types.
Other behaviour control 2 6.3  Project managers commonly employed a portfolio of control
Input control PM selection 2 6.3 mechanisms to control the project rather than rely on one type
Team selection 7 21.9
of control mechanism.
Select by RFP 3 9.4
Other input control 4 12.5
Clan control Team co-location 24 75.0
Exchange developer 1 3.1 7.3. Project coordination
Site visits by PM or team 14 43.8
Informal communication 20 62.5
This section of the analysis investigates the third research sub-
Other clan control 1 3.1
question. That is:
RQ1.3: Which mechanisms do project managers use to coordi-
nate software development projects?
would meet the requirements of an ISO 9001 audit but did have to
be formally expressed in some way. None of the project managers Project team meetings are common in software development
indicated that the project teams ignored the formal development and are one of the more frequently used coordination mechanisms.
or quality processes. This contrasts with anecdotal claims by some The structured interview did not explore different methods of
of the interviewed project managers that development methodol- holding meetings such as video conference or ‘‘in person” but did
ogies and quality management systems tend to be ignored by soft- explore the purpose of team meetings and management meeting
ware developers. through the subjects that were discussed (Table 4). Very few pro-
Team co-location usually meant that the team was in one place ject managers, less than 10%, do not hold regular team meetings.
rather than dispersed. Frequently, the development teams were lo- In the research sample, those that did not hold team meetings were
cated on the customer’s premises, even if that was overseas. teams of one person, where team meetings are inappropriate.
Informal communication is a very general category and is nor- While the data indicate that schedules, budgets and other mat-
mally taken to mean casual conversations but it also included ters related to project progress are discussed more frequently at
emails and phone conversations (Kraut and Streeter, 1995; team meetings (81% of cases), other topics are not neglected. Team
Sabherwal, 2003). The essential characteristic of informal commu- meetings appear to act as a general discussion forum rather than
nication is that it is unplanned and unrestricted and not that it oc- be devoted to a single topic.
cur face to face.
7.3.1. Content analysis
7.2.2. Qualitative analysis A more granular view of project coordination mechanisms re-
Project managers perceived control to be something they veals that project coordination is achieved through more than
actively did rather than something structured during project plan- team meetings. The interview transcripts were examined for evi-
ning. For example, team co-location was seen as a way to better dence of coordination mechanisms that were then classified
understand the client’s requirements rather than as a way to con- according to the previously established scheme of standards-
trol the client or the project team. Even in response to specific sce- based, plan-based, formal mutual adjustment and informal mutual
narios set out in the questionnaire, project managers reported that adjustment. The frequency of each type of coordination mecha-
they tended to control the project by direct actions aimed at keep- nism is displayed in Table 5.
ing the project on schedule. None of the project managers re- It is notable that four mechanisms are used significantly more
sponded with something longer term such as moving the team to frequently: schedule, specifications, project team meetings and
the customer’s premises, an action Sabherwal found when consid- informal conversations. Co-location appears to be almost as popu-
ering the evolution of project coordination mechanisms over the lar. However, in this research sample only 46.9% of projects had
life of a project (Sabherwal, 2003). some outsourced elements so it is reasonable that co-location
Contract terms and conditions or development life cycles would feature as a coordination mechanism in approximately
(shown in Table 3) are more structural in nature and were seen 60% of projects. It’s presence does not indicate a conscious use of
more as organizational than project management matters. When co-location to manage the project.
dealing with outsourced development, project managers occasion-
ally 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. Table 4
Subjects discussed at team meetings

7.2.3. Findings Count Percent

Team meetings are held 29 90.6
 All project managers controlled the behaviour of their develop- Design 18 56.3
ment teams through a project schedule, commonly referred to as Requirements 15 53.1
the ‘‘project plan”. Formalised, that is documented, software Schedule, budgets, milestones 26 81.3
Risks and issues 12 62.5
development processes were also a common mechanisms to
Other 11 34.4
control behaviour in almost 70% of projects.
 T. McBride / The Journal of Systems and Software 81 (2008) 2386–2395 2393

Table 5  Informal mutual adjustment mechanisms were dominated by

Frequency of coordination mechanisms detected through content analysis the informal conversation and by co-location. Management by
Coordination mechanism Count Percent walking about (MBWA) was the least favoured coordination
Standards-based Template work products 16 50 mechanism.
Interface specs 6 19  As with both project monitoring and project control, project
Design rules 6 19 managers employ a portfolio of project coordination mecha-
Plan-based Schedule 27 84 nisms and do not constrain themselves to one or two
Specifications 32 100
Sign offs - phase reviews 11 34
mechanisms.
Test plans 17 53
Formal mutual Code and design reviews 7 21
adjustment Change control committee 11 34
8. Discussion
Project team meetings 28 87
Ad hoc meetings 17 53
Project reviews 14 43 The first research question was ‘‘Which mechanisms do project
Informal mutual Co-location 19 60 managers use to monitor, control and coordinate software devel-
adjustment Management by walking about 11 34 opment projects?” Data gathering and analysis sought to identify
(MBWA)
which project management mechanisms were used by project
Personal conversation 25 78
Site visits 14 43 managers. It was found that some project management mecha-
nisms 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
The data indicate a very high incidence of schedules, specifica- rather than relying on a single mechanism. For example, a project
tions and project team meetings that indicates a trend toward mar- manager does not rely on project meetings to monitor the project
ket based mechanisms (Sabherwal, 2003). but will use multiple mechanisms to monitor the project.
The high use of formal and informal mutual adjustment mech-
anisms, team meetings and personal conversation, indicate a need
8.1. Project monitoring
to manage a significant amount of reciprocal dependency.
Project managers favour formal and informal monitoring mech-
7.3.2. Qualitative analysis
anisms over automatic or ad hoc monitoring mechanisms. The
While project coordination was seen by project managers as the
most familiar monitoring mechanism is the weekly project review
actions they might take to re-align the completion of documents or
meeting with the development team that reviews the schedule and
components, in fact all projects employed some form of specifica-
milestones as well as other project issues. There is little evidence of
tion that described what the various components were to do, and
adopting such automated tools as CSCW or workflow systems but
almost all project managers expressed a work breakdown schedule
some evidence that iterative development is being used with its
in some form of project plan. Coordination was seen as the actions
frequent release cycles permitting a form of automatic monitoring.
taken to adjust the scheduled delivery of components or to adjust
Informal monitoring through conversations with the project team
the effort involved in producing the components.
and with the customer is widely practised. One of the unexpected
The larger or more time critical projects tended to use fairly
findings is that many project managers that use schedule and mile-
detailed work breakdown structures, where tasks were broken
stone tracking to monitor the general state of the project but sup-
down into something that could be completed in a week or less.
plement this with ad hoc ‘‘drill down” enquiries whenever there
There did not appear to be a significant difference between large
are any slippages or even threats of slippages. Such an early warn-
or small projects in the granularity of the work breakdown struc-
ing system of monitoring would appear to be an inexpensive and
ture although there did appear to be a tendency for less rigour
unobtrusive way to monitor the project and react quickly when
when the project iterated over many releases, possibly over sev-
needed.
eral years. In such cases there was a ready mechanism to offload
work that could not be completed in the current release. How-
ever, projects with less flexible delivery dates and less flexibility 8.1.1. Early warning systems
over delivered functionality tended to be planned in considerable The analysis clearly showed that project managers used the for-
detail. mal project monitoring mechanisms as a warning system to indi-
cate that something needs further investigation. If any alarm was
7.3.3. Findings triggered in the mind of the project manager then ad hoc monitor-
ing was initiated in the form of a specific inquiry or something
 Project coordination is achieved by the majority of project man- more formal such as a project audit. This is an efficient way to
agers through plan-based mechanisms of product specifications monitor any project. If the formal monitoring does not need to
and the project schedule. Phase reviews and test plans were gather a lot of information then it can be pared down to only that
used but not as extensively as plan-based mechanisms. which indicates the health of the project rather than having to in-
 The most popular standards-based coordination mechanism, clude information that would indicate all the possible causes of ill
that of template work products, was reported to be used by health. Causes of ‘‘ill health” can be sought through a more directed
50% of project managers. Compared to the reported use of other inquiry that needs only involve those directly concerned with the
mechanisms, such as schedules and specification, this does not particular problem and not the entire project team.
represent a preferred coordination mechanism.
 Of the formal mutual adjustment mechanisms, the most 8.1.2. Multiple sources of information
favoured was the project team meeting. The only other formal Project managers tended to use multiple sources of information
mutual adjustment mechanisms reported by more than 50% of about the same aspect of the project. Mostly this was the project’s
project managers was the ad hoc meeting. While other mecha- progress, which could be measured reasonably clearly, but also in-
nisms were employed in some projects, their use does not indi- cluded less measurable attributes, such as the project’s health. This
cate a strong preference. indicates that multiple sources of information will be sought to
2394 T. McBride / The Journal of Systems and Software 81 (2008) 2386–2395

overcome information uncertainty. If the data cannot be readily ject team meetings is unsurprising since the interview questions
verified by the project manager, then multiple sources of the same asked specific questions about them whereas no questions sought
project attribute will triangulate the information, thus reducing information on design rules or interface specifications.
uncertainty. If the project or product attribute is difficult to mea- Of the informal mutual adjustment coordination mechanisms,
sure, then multiple related measures will tend to reduce the inac- the most frequently employed was personal conversation. This re-
curacy of single measures. For example, it is difficult to monitor a search did not seek the purpose for conversations, so further re-
single project characteristic that would indicate the health of the search is recommended to investigate the varying usage of
project and the probability that it will be completed on schedule. project management mechanisms. Aside from conversations, the
Instead, several measures are sought that can collectively indicate most popular information coordination mechanism was to co-lo-
the project’s health. This research did not pursue this apparent cate the development team. Different forms of co-location were
relationship between information uncertainty and the number of employed. Locating the entire development team close together
information sources. That will be left for further research. and locating the development team on the customer’s premises
were the most common forms of co-location.
8.2. Project control

8.4. Significance to project managers

What is notable about the controls is the dominant use of the
project work breakdown structure and schedule, commonly re-
This research has identified that a range of mechanisms are
ferred to as the project plan. All project managers used some form
available to project managers and has shown the relative popular-
of schedule based plan whether this was a simple ‘‘to do” list or a
ity of each. Although the research has limited external validity due
more elaborate project plan contained in a tool such as Microsoft
to the relatively small number of interviews, it is believed to be
Project.
reasonably representative of the software development industry.
With all the range of controls available, only a few are employed
The research suggests that not only are there many mechanisms
to any great extent. Control mechanisms used significantly more
to monitor, control and coordinate software development projects
than other forms of control were: the main project objectives that
but that several of them might be employed on the same project.
would be part of the project’s charter, development processes, a
Certainly there was some indication that the more experienced
project plan, co-location and informal communications. Of the pos-
project managers employed multiple mechanism to increase the
sible controls, team selection would seem to be used, but either not
richness of information available to them and to verify the consis-
thought important or not drawn out by the research data gather-
tency of the information.
ing. Given the concentration on recruiting software development
The research did not extend to identifying which circumstances
personnel with specific skills that is evident through the press1
or project types tended to favour specific mechanisms. Instead this
or the number of recruitment agencies that concentrate on the soft-
research simply seeks to identify current practice.
ware development industry or the common practice of preparing a
request for proposal (RFP), it is clear that control by recruitment is
practised. 8.5. Future research
The portfolio of controls did not vary significantly over the orga-
nization size, project size, organizational process maturity or any This research investigated the use of project management
other organizational or project attribute. This implies that the com- mechanisms by considering each type of mechanism (monitor,
mon portfolio of controls is very robust and widely applicable. control and coordinate) separately then later observing that project
managers frequently use the same mechanism for multiple pur-
8.3. Project coordination poses. This suggests that the opposite approach could be fruitful,
i.e., to first establish which mechanisms project managers use
Although there is clearly a preference for some coordination and the different purposes for which they are used.
mechanisms over others, most available mechanisms are used. There has not been a rigorous analysis nor any empirical data on
The coordination arising from the more formal aspects of project how any one mechanism is used by a project manager to achieve
management, the specifications and the project schedule, appear multiple objectives. Research to date has investigated project con-
to be almost universally used. trol (Zmud, 1980; Henderson and Lee, 1992; Kirsch, 1996; Addison
As with both monitoring and control, project managers em- and Vallabh, 2002; Choudhury and Sabherwal, 2003) or project
ployed several project coordination mechanisms. The plan-based monitoring (Kitchenham, 1996; Dumke and Winkler, 1997; Royce,
mechanisms dominated but formal mutual adjustment and infor- 1998; Kitchenham et al., 2001) or project coordination (Kraut and
mal mutual adjustment were strongly supported. Streeter, 1995; Crowston and Kammerer, 1998; Faraj and Sproull,
This research indicated that more than 80% of all project man- 2000; Andres and Zmud, 2002; Sabherwal, 2003) and has identified
agers used a project schedule and adjusted the project using the the mechanisms employed to achieve each separate objective. But
schedule, and all project managers used specifications to coordi- many of the same mechanisms used for project control, for exam-
nate how the work was partitioned then integrated. Such signifi- ple, are also used to achieve project coordination.
cant usage of two different mechanisms in the one category of A project management mechanism could be used for different
coordination mechanisms indicates that plan-based coordination objectives, depending on the circumstances. For example, a meet-
may have some advantages over other forms of coordination. ing may be used to enforce project control and, later, another
Coordination by formal mutual adjustment was most fre- meeting be used to clarify how some parts of the system must
quently achieved through project team meetings. Reviews, interact, which is a coordination matter.
whether formal reviews of the project or internal design and code More likely is that mechanisms will be used for several pur-
reviews, were not as frequently employed. The popularity of pro- poses at the same time. A mechanism may be used to achieve a pri-
mary objective as well as a secondary objective. For example, a
specification such as a system design is primarily a control mech-
1
In Sydney there are three daily newspapers. Of these, two have an IT supplement
anism since it specifies what is to be achieved. However, the same
on one weekday which normally includes a selection of jobs. Additionally, the specification acts as a coordination mechanism by specifying the
Saturday edition of all newspapers frequently features a number of IT-related jobs. how different parts of the system will interact.
 T. McBride / The Journal of Systems and Software 81 (2008) 2386–2395 2395

The primary, secondary or incidental purposes for which a Hughes, B., Cotterell, M., 1999. Software Project Management. McGraw-Hill,
London.
mechanism is used could vary according to circumstances and this
ISO 15504. ISO 15504-3:2004 – Information technology – Process assessment – Part
would need to be investigated. 3: Guidance on performing an assessment.
Understanding how the different mechanisms are used would Kerzner, H., 1998. Project Management: A Systems Approach to Planning,
reveal more about how project managers actually monitor, control Scheduling, and Controlling. sixth ed.. John Wiley & Sons Inc, New York.
Kirsch, L.J., 1996. The management of complex tasks in organizations: controlling
and coordinate their projects and lead to a better understanding of the systems development process. Organization Science 7 (1), 1–22.
requirements for tools to assist them. Kitchenham, B., 1996. Software Metrics: Measurement for Software Process
Further research could also be undertaken to investigate the Improvement. NCC Blackwell Ltd.
Kitchenham, B.A., Hughes, R.T., Linkman, S.G., 2001. Modeling software
effectiveness of each mechanism or the reasons for their choice. measurement data. IEEE Transactions on Software Engineering 27 (9), 788–804.
While some mechanisms might be favoured in more formal soft- Kraut, R.E., Streeter, L.A., 1995. Coordination in software development.
ware development projects there is little data available on the ben- Communications of the ACM 38 (3), 69–81.
Lacity, M.C., Janson, M.A., 1994. Understanding qualitative data: A framework of
efits of the mechanism compared to the cost of employing it. test analysis methods. Journal of Management Information Systems 11 (2),
137–155.
References Leedy, P.D., Ormrod, J.E., 2001. Practical Research: Planning and Design. seventh ed.
Merrill Prentice Hall.
Malone, T.W., Crowston, K., 1994. The interdisciplinary study of coordination. ACM
Addison, T., Vallabh, S., 2002. Controlling software project risks: an empirical study
Computing Surveys 26 (1), 87–119.
of methods used by experienced project managers. Proceedings of the 2002
McGarry, J., Card, D., Jones, C., Layman, B., Clark, E., Dean, J., Hall, F., 2002. Practical
annual research conference of the South African institute of computer scientists
Software Measurement. Addison-Wesley.
and information technologists on Enablement through technology, Port
Navon, R., Goldschmidt, E., 2003. Monitoring labor inputs: automated-data-
Elizabeth, South African Institute for Computer Scientists and Information
collection model and enabling technologies. Automation in Construction 12
Technologists, pp. 128–140.
(2), 185–199.
Adler, P.S., 1995. Interdepartmental interdependence and coordination: the case of
Nidumolu, S.R., 1996. A comparison of the structural contingency and risk-based
the design/manufacturing interface. Organization Science 6 (2), 147–167.
perspectives on coordination in software development projects. Journal of
Al-Jibouri, S.H., 2003. Monitoring systems and their effectiveness for project cost
Management Information Systems 13 (2), 77–113.
control in construction. International Journal of Project Management 21 (2),
OGC, 2002. Managing successful projects with PRINCE2. third ed., Office of
145–154.
Government Commerce, London.
Andres, H.P., Zmud, R.W., 2002. A contingency approach to software project
Ouchi, W.G., 1979. A Conceptual Framework for the Design of Organizational
coordination. Journal of Management Information Systems 18 (3), 41–70.
Control Mechanisms. Management Science 25 (9), 833–848.
Burke, R., 2003. Project Management: Planning and Control Techniques. fourth ed.
Ouchi, W.G., Maguire, M.A., 1975. Organizational control: two functions.
Burke Publishing, Tokai, South Africa.
Administrative Science Quarterly 20 (4), 559–569.
Carmel, E., 1999. Global Software Teams: Collaborating Across Borders and Time
Project Management Institute 2000. A Guide to the Project Management Body of
Zones. Prentice Hall PTR, Upper Saddle River.
Knowledge. Project Management Institute.
Choudhury, V., Sabherwal, R., 2003. Portfolios of control in outsourced software
Raffo, D., Harrison, W., Vandeville, J., 2000. Coordinating Models and Metrics to
development projects. Information Systems Research 14 (3), 291–315.
Manage Software Projects. Software Process Improvement and Practice 5, 159–
Cleland, D.I., Ireland, L.R., 2002. Project management: Strategic Design and
168.
Implementation. fourth ed.. McGraw-Hill.
Royce, W., 1998. Software project management: a unified framework. Addison
Crowston, K., Kammerer, E.E., 1998. Coordination and collective mind in software
Wesley, Reading, MA.
requirements development. IBM Systems Journal 37 (2), 227–245.
Sabherwal, R., 2003. The evolution of coordination in outsourced software
Crowston, K.G., 1991. Towards a Coordination Cookbook: Recipes for Multi-Agent
development projects: a comparison of client and vendor perspectives.
Action, A thesis submitted to Alfred P. Sloan School of Management,
Information and Organization 13 (3), 153–202.
Massachusetts Institute of Technology, Boston.
Seaman, C.B., 1999. Qualitative methods in empirical studies of software
Davies, R., Saunders, R., 1988. Applying systems theory to project management
engineering. IEEE Transactions on Software Engineering 25 (4), 557–572.
problems. International Journal of Project Management 6 (1), 19–26.
Shumate, K., Snyder, T., 1994. Software project reporting: management,
Dumke, R.R., Winkler, A.S., 1997. Managing the component-based software
measurement, and process improvement. Annual International Conference on
engineering with metrics. Proceedings Fifth International Symposium on
Ada. ACM Press, Baltimore. pp. 41–45.
Assessment of Software Tools and Technologies, pp. 104–110.
Wood, M., Daly, J., Miller, J., Roper, M., 1999. Multi-method research: An empirical
Eisenhardt, K.M., 1985. Control: Organizational and Economic Approaches.
investigation of object-oriented technology. Journal of Systems and Software 48
Management Science 31 (2), 134–148.
(1), 13–26.
Eisenhardt, K.M., 1989. Agency Theory: An Assessment and Review. Academy of
Yin, R.K., 2003. Case Study Research: Design and Methods. third ed., Sage, Thousand
Management Review 14 (1), 57–74.
Oaks, originally published 1984.
Faraj, S., Sproull, L., 2000. Coordinating Expertise in Software Development Teams.
Zhuge, H., 2002. Knowledge flow management for distributed team software
Management Science 46 (12), 1554–1568.
development. Knowledge-Based Systems 15 (8), 465–471.
Fenton, N.E., 2000. Software metrics: roadmap. International Conference on
Zmud, R.W., 1980. Management of large software development efforts. MIS
Software Engineering, Limerick. ACM Press. pp. 357–370.
Quarterly 4 (2), 45–55.
Flamholtz, E.G., Das, T.K., Tsui, A.S., 1985. Toward an integrative framework of
organizational control. Accounting, Organizations and Society 10 (1), 35–50.
Hamilton III, R.D., Kashlak, R.J., 1999. National influences on multinational Tom McBride is a Senior Lecturer at the University of Technology, Sydney. His
corporation control system selection. Management International Review 39 (2), research interests sit in the boundary between theory and practice where practice is
167–189. not always as theory would predict. The reasons why not can open new insights,
Henderson, J.C., Lee, S., 1992. Managing I/S design teams: a control theories showing just how much our world has changed.
perspective. Management Science 38 (6), 757–777.