Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
Modelling “Softer” Aspects of the Software Development Process: An Activity Theory based Approach G. Michael McGrath JRCASE, Macquarie University NSW, 2109 Australia
Lorna Uden School of Computing Staffordshire University England, UK
[email protected]
[email protected]
Abstract In our view, all current software engineering tools and techniques have strengths and weaknesses but very few tools provide much in the way of useful support for the critical “people-related” (or “softer”) organisational behaviour issues critical to the successful implementation of any new process or system. In this context, activity theory would appear to have much to offer, incorporating, as it does, notions of intentionality, history, mediation, motivation, understanding, communication, culture and context. Previously, we have reported on the specification and development of a repository designed to represent process knowledge captured within an activity theory framework. Here, we extend this work by proposing a framework for a broad process modelling methodlogy designed around this repository. We take advantage of the substantial overlap between a methodlogy based on knowledge analysis of tasks (KAT) and activity theory. KAT analysis directly supports the fundamental process modelling objective of identifying what people currently do in their work within a given domain. Here our focus is on the software development process and we illustrate our approach by applying it to the change management activity within the implementation stage of the SDLC. Specifically, we present an involving the use of change anchors. These are abstract devices designed to “kick start” change initiatives to a point where these gain sufficient credibility to sustain themselves.
1. Introduction It may come as no great surprise to many readers that considerable evidence suggests that the information systems (IS) implementation success rate has been very poor (see, for example, [13]). Furthermore, few would argue that accurate and relevant models are vital to the success of any significant software engineering endeavour [2]. In general, models are central to practitioners (and researchers) being able to capture, for study and analysis, world phenomena, tangible or
abstract, in that they capture a situation's essential abstractions in an appropriate representation. In studying transient abstract phenomena, where we do not have the luxury of having a physical artefact to study at our leisure, models and modelling are crucially important, in that they alone can give substance to the abstract intellectual artefacts that are characteristic of the subject of study, hence enabling them to be subjected to shared comprehension and scrutiny. Thus, in many ways, modelling methodologies are communication methodologies, albeit with much variability existing in the notations used to convey information. Software engineering process modelling tools serve many purposes. They can be employed: to derive a model of current development processes; to help pinpoint weaknesses in current processes; to develop and test alternative processes; and to assist in the derivation of the automated systems designed to support existing and new processes. Many process modelling tools have been proposed and used in software engineering projects. In our view, all current tools and techniques have strengths and weaknesses but very few tools provide much in the way of useful support for the critical “people-related”, organisational behaviour issues so crucial to the successful implementation of any new process or system. In particular, existing tools enable the recording of the details of the individuals and teams enacting a process, the artefacts produced, and the sequencing of the functional tasks, but not the norms, beliefs and motives of the staff carrying out the process. In this context, activity theory would appear to have much to offer, incorporating, as it does, notions of intentionality, history, mediation, motivation, understanding, communication, culture and context. In previous work, we have focused on the specification of a repository designed to represent process knowledge captured within an activity theory framework. Here, we extend this work by proposing the beginnings of a process modelling methodlogy designed around this repository. Our work draws heavily on previous research into “knowledge analysis of tasks”
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
1
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
(KAT) and we take advantage of the substantial overlap between KAT and activity theory. KAT analysis is used to produce a model of activities in terms of task knowledge structure (TKS); a TKS being a summary representation of the different types of knowledge acquired through learning and performing given (and associated) tasks. TKSs directly support the fundamental process modelling objective of identifying what people currently do in their work within a given domain. Here our focus is on the software development process and we illustrate our approach by applying it to the change
2. IS implementation: Change management The evidence suggests that the IS implementation success rate is poor. According to Rodriques and Bowers [13], budget over-runs of 40-200% are becoming increasingly common; a Standish Group study report claims that 30% of projects are cancelled prior to completion, over 50% of completed projects cost almost twice their estimated cost and, in 1995, US organisations spent $81 billion on cancelled projects and an additional $59 billion on project over-runs [14]; and, finally, a report prepared by U.K. Organizational Aspects Special Interest
management activity within the implementation stage of the systems development life-cycle (SDLC). Our paper is organised as follows: In the following section, we present a view of the SDLC and introduce a particular, generic change management strategy. We then provide an overview of activity theory and our activity theory-based process modelling repository. We then describe how KAT techniques are employed in utilising our repository data. Concepts are illustrated with reference to the change management strategy introduced in Section 2. Concluding comments are presented in Section 5.
Group [11], indicates that around 80% of new systems are delivered late and over-budget, and 80-90% of IS investments do not meet their performance objectives. The OASIG report goes on to state that the reasons for these failures are rarely purely-technical in nature and that organisational and people-related, “softer” problems are at least as significant as technical difficulties. Softer problems encompass leadership, motivation, morale, organisation culture, and power and politics [1] and, while these considerations are important at all stages of the SDLC, they are especially relevant during system implementation, where the issue of effective change management becomes critical.
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
2
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
A view of the SDLC is presented in Figure 1. The emphasis in this view is on the implementation stage and, in particular, on part of a general change management framework which may be employed to guide agents responsible for implementing information systems. In part, our framework is based on Leonard-Barton’s [8] concept implementation characteristics, of which are organisational and technology attributes that both constrain change agents and present them with opportunities. One generic strategy suggested by LeonardBarton (particularly where implementation complexity is high and elements of the technology are unproven) is the use of a champion. This is one of three change anchor types suggested by Lindner [9]; the others being a compelling deadline and a commonly agreed direction (consensus). Essentially, a change anchor is the foundation on which a change initiative is based. It is often used to “kick-start” a change initiative and, whatever the form of the anchor, it must provide credibility to the change process until it gains a life of its own. Choice of an anchor should be determined by the organisation’s familiar mode (its habits and values) and the immediate environment (e.g. the balance of power among key players, whether views are reasonably consistent or whether some event in the external environment necessitates a specific internal response). We shall now demonstrate that key elements of the change anchors concept may be conveniently represented in the activity theory based process modelling approach first presented in [3] and further developed in [10]. In doing so, we shall develop rules which may be employed to assist in the choice of an appropriate anchor.
3. Activity theory and SATBPA An activity is seen as a system of human “doing” whereby a subject works on an object in order to obtain a desired outcome. In order to do this, the subject employs tools. A subject may be an individual or a composite entity. Many subjects may be involved in an activity, and each subject may be involved in one or more roles and have multiple motives. Rules (which include norms, values, beliefs etc.) are both explicit and implicit, and specify how subjects fit into communities. An activity may be broken down into actions and these, in turn, may be decomposed into operations. Actions are well-defined processes directed at specific, conscious goals, while operations may be thought of as (largely) automatic responses to prevailing conditions. With reference to our example, “agenda setting” is an activity. Subjects involved in the activity might include a secretary, the project manager and all (or some) system stakeholders. One of the significant objects of the activity is the agenda itself, and tools used to assist subjects might
include action lists, performance reports, workplans and various communications facilities. Outcomes are closely related to motives and these vary with subjects. For example, the secretary (nominally responsible for preparing the agenda) might be motivated by both a desire for completeness and a wish to please the project manager. The project manager, on the other hand, might want the agenda structured so that attention is deflected from some items while others are highligted. Rules include well-documented specifications of which subject does what and when, as well as beliefs such as “given two items, placing the more important item second on the agenda will maximise the chances of your preferred option being accepted” [12: pp. 150-154]. SATBPA is an automated tool that provides an interface to a database designed to record the detail of business processes in a form consistent with activity theory. This work has been described in more detail in [3], where, as noted previously, SATBPA is intended to be a first step towards the development of a methodology for the structured application of activity theory in business process modelling. Formal conceptual modelling techniques have been employed to define the SATBPA repository. As such, we have found it necessary, on occasions, to employ terminology other than that found in the more standard presentations of activity theory. In particular: 1) the concepts of subject and community have been combined into a single notion of subject; 2) subjects can be decomposed in many different ways, and can be involved in many relationships with other subjects in different roles; 3) we have eliminated Kuutti’s 3-level hierarchy [7] and replaced it with the single concept of a process, which may be decomposed to as many levels as the analyst desires; 4) tools and objects have been merged into a single artefact concept (recognising that an object produced by one process can be utilised as a tool in another process); and 5) the rules that define communities and the division of labour have tentatively been labelled understandings (and are the predominate means employed for the representation of soft factors). The SATBPA repository is specified conceptually at both the data and meta-data levels in entity-relationship (E-R) form. The repository itself has been implemented in Microsoft Access™. A sample database, in relational form and derived from the discussion on IS implementation introduced in the previous section, is presented overleaf. Ellison and McGrath [3] presented a SATBPA data meta-model and demonstrated that it has an inherently repetitive structure. At the core of this meta-model, there are two entities, E1 and E2, with R1r signifying the role the first entity plays in the relationship. This construct can be represented as the template, Template 1: R1r(E1, E2).
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
3
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
in_charge_of(individual, process); and Template 1 represents the core proposition, P. This can strongest_of(individual, all_stakeholders). now be extended to a compound structure which is of the At the next level, the first of these may be extended to same basic type as the core structure. To create the an instance of the sspi (subject-subject-processtemplate for this structure all that is required is: 1) to involvement) as follows: replace E1 and R1r in Template 1 by E3 and R2r should_place(all_stakeholders, respectively; and 2) to replace E2 with Template 1. Thus in_charge_of(individual, process)). Template 2 is: R2r(E3, R1r(E1, E2)). This process can be extended indefinitely. Consider, for example, the core propositions: ppi proc-1 proc-2 ppi-role part_of system_development requirements_elicitation . . . . . . part_of system_development implementation part_of implementation change_management . . . . . . part_of change_management change_anchor part_of change_management coalitions part_of change_management symbolic_action part_of change_management agenda_setting threatened_by external_process process link_to external_process process
ssi
subj-1 individual
subj-2 all_stakeholders
ssi-role strongest_of
spi
subj-id individual committee all_stakeholders
proc-id process process process
spi-role in_charge_of controls consistent_views
proc ess
proc-id
proc-type
process
critical_process
In McGrath and Ellison [10], this approach was extended to encompass elements of speech-act theory (SAT) [5] and it was demonstrated that an analyst may choose to manage complexity within these structures by a Roll Up of any substructure at any point in a modelling session and, thereafter, by simply referencing the identity of the rolled up substructure. In this approach, norms, beliefs etc. are specifically declared and each structure is given a unique identifier. For example: is(C1, should_place(all_stakeholders, in_charge_of(individual, process)));
is(C2, strongest_of(individual, all_stakeholders)); and is(C3, norm(orgn, in_charge_of(individual, process)). Understandings may then be specified using the four binary relationships: isa(U_id, understanding) conclns(U_id, C) subject(U_id, S) condns(U_id, C’) where U_id is the understanding identifier, S is the subject (or “understander”) and C and C’ represent lists of conclusions and conditions respectively. Both these lists have the form: c0(C0, c1(C1, --------, cn-1(Cn-1, Cn))----)
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
4
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
where c0,----,cn-1 are logical connectors and each member of the set {C0,-----,Cn} is either an allowable structure or the identifier of a rolled-up version of the same. The conclusions list must contain at least one entry, while the conditions list may be empty. Understandings are effectively binary tree structures, with connectors at each major node and a structure at each leaf or branch. A major benefit gained from this representation scheme is that trees (along with lists) are the data structures natural to Prolog, the language we employ to manipulate and analyse understandings. Returning again to our earlier discussion on change anchors, an example of an understanding is: isa(U1, understanding) subject(U1, mgnt_theorists) conclns(U1, [C1]) condns(U1, [C3, C2]) which may be loosely interpreted declaratively as the rule: if an organisation tends to put one person in charge (familiar mode) and one person is naturally stronger than the other stakeholders (immediate environment) then the stakeholders should place that person in charge )a champion-based change anchor). If we now add the additional substructures: is(C4, should_place(all_stakeholders, ` in_charge_of(committee, process))); is(C5, norm(orgn, in_charge_of(committee, process))); is(C6, consistent_views(all_stakeholders, process)); is(C7, link_to(process, external_process)); is(C8, threatened_by(process, external_process)); and is(C9, must_urgently_address(orgn, threatened_by(process, external_process))) we may now express two additional understandings: isa(U2, understanding) subject(U2, mgnt_theorists) conclns(U2, [C4]) condns(U2, [C5, C6]) and isa(U3, understanding) subject(U3, mgnt_theorists) conclns(U3, [C7,]) condns(U3, [C8, C9]) which have the declarative interpretations: if an organisation tends to use committees (familiar mode) and all stakeholders have reasonably consistent views (immediate environment) then the stakeholders should place a committee in charge (a consensus-based change anchor) and if there is some external threat (immediate environment) and that threat must be addressed urgently (immediate environment) then link the internal process to the external process (a deadline-based change anchor). Thus, using the SATBPA framework, we have developed and expressed Lindner’s [9] three fundamental rules for selecting an appropriate change
management anchor. We now turn our attention to a means by which information captured within the SATBPA repository may be utilised in a structured and systematic way.
4. Applying AT: A structured approach In the previous section, we presented an example of how our activity theory based process modelling and analysis tool, SATBPA, can be utilised to capture a number of important rules pertinent to the implementation phase of the SDLC. To date, however, our SATBPA work has focused mainly on the specification and development of a repository designed to store relevant process knowledge. In the remainder of this section, we present the outline of a framework designed to utilise the data held in this repository. Our framework is presented in Figure 2. It is based largely on the KAT methodology proposed by Johnson and Johnson [4]. KAT was derived from (and utilises) techniques commonly employed in task analysis, experimental psychology and knowledge elicitation, and its primary purpose is to produce TKSs – which are, essentially, taxonomic representations of the knowledge required of individuals to enable them to effectively carry out tasks (activities) assigned to them. There are three important theoretical underpinnings of KAT. These relate to the representation of tasks as concepts to be represented in memory, the structure of entities in tasks and the differential states of these entities in terms of their representitiveness and centrality. The principal components of this model are taxonomic goal structures and task procedures. KAT represents an attractive starting point for our framework because of the major overlap between its core concepts and activity theory. KAT is concerned with assessing and modelling the knowledge people possess and utilise in carrying out tasks. This process of analysis produces a description of a person’s or communities’ knowledge of tasks that are currently performed in the domain of interest. KAT identifies the knowledge requirements of tasks and is aimed at assisting in the generation of design solutions. The task analysis that people possess is an important subset of their total knowledge and, as with any other activity, it should be taken into account during the design and development of information systems. KAT is based on a theory of task knowledge [4]. It holds that task knowledge is represented in persons’ memory and can be described by TKSs. TKSs represent the knowledge people process about tasks they have previously learned and performed in a given domain, including procedures, actions, objects and goals. TKSs may be linked to each other through a umber of different relations. Relations between TKSs can be within-role
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
5
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
and between-role, where a role is defined by the collection of tasks that a person occupying that role performs. Thus, TKS theory provides a method for the analysis and modelling of the tasks in terms of goals, procedures, actions and objects. Within each TKS, different types of knowledge are represented. Contained
As illustrated in Figure 2, KAT can be divided into three stages: knowledge gathering, knowledge classification and TKS construction. The KAT process is iterative, where the designer is constantly seeking information, confirming existing information and
within TKS are goal-oriented and taxonomic substructures: goal-oriented substructures represent a persons’ knowledge about goals and their enabling states, subgoals and procedures. Taxonomic substructures represent knowledge about the properties of task objects and their associated actions.
rejecting false information. Before any detailed work is undertaken, however, it is imperative that the objective of the KAT exercise be identified. This will esablish domain boundaries and help to ensure that attention is concentrated on the most critical and relevant activities. Once this has been accomplished, knowledge gathering
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
6
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
can commence. Principal inputs to this stage are the objective itself and information garnered through inteviews, questionnaires, and observational and experimental techniques. The major output is a preliminary picture of the domain task knowledge expressed in terms of procedures, actions, objects and goals. The next stage, knowledge classification, takes the outputs of the first stage and categorises each knowledge entity in terms of its representative, central and generic properties1. During the final stage, the actual TKS model is constructed. The aim of this stage is to identify the structure, content and attributes of people’s task knowledge in line with TKS theory. Task models in terms of TKS involve goal-oriented and taxonomic substructures and procedures. A goaloriented substructure can be represented by a network of structured goal nodes that direct sequences of events that unfold over time and eventually satisfy subgoal nodes. Goal nodes can vary in hierarchical level. Goals and subgoals can be represented by nodes with links between them. Nodes can be treated as conditions, as states, or as desired states (subgoals). Subgoals can also be hierarchically and concurrently related to each other. The goal-oriented substructure ‘calls up’ appropriate knowledge from the taxonomic substructure by use of procedures. Associated with subgoals are sets of procedures that have to be executed in order to achieve subgoals directly or indirectly. Any subgoals may give rise to further planning activity and subsequent subgoals and these may be indirectly related to a task procedure set. Task procedures define the behaviour of object combinations during the execution of given subgoals. They are the processes by which taxonomic substructures are activated. Thus a key component of a TKS model is the goal hierarchy (taxonomic goal structures). Implicit in this goal structure is a plan for carrying out the overall task. For goals to be realised, however, there must be an appropriate procedure and, within KAT, procedures are viewed as different from goal structures because they are executable. Within SATBPA this is not necessarily the case. The SATBPA repository has much in common with a TKS model and, because logic has been employed as the underlying formalism, repository data (and its derivatives) can easily be mapped into Prolog assertions and clauses. As such, goal structures are both declarations of the relationships between goals and subgoals and procedures that can be utilised to realise goals. This is
1 Representativeness essentially means the “best example; centrality could be described as “important” or “necessary”; and genericism is concerned with the extent to which task properties are “common” across a whole task class (or classes).
a direct consequence of the dual (declarative and procedural) interpretations of logic programs [6]. Returning to the understandings developed in the previous section, these can easily be mapped into Prolog rules. For example, a Prolog representation of the first of our understandings (dealing with the champion-based change anchor type) is: should_place(all_stakeholders,in_charge_of(X,P)) :norm(orgn, in_charge_of(individual, process)), strongest_of(X, all_stakeholders), isa(X, individual), isa(P, process). Declaratively, this Prolog rule has much the same reading as that presented in the previous section: i.e. place individual X in charge of process P if X is the strongest of all stakeholders and it is an organisation norm to place one strong individual in charge (of important processes). If we now add the assertions: norm(orgn, in_charge_of(individual, process)). strongest_of(‘Jane’, all_stakeholders). isa(‘Jane’, individual). isa(‘Orders system implementation’, process). we may now represent these and our rule as the tree structure presented in Figure 3. The procedural interpretation of our rule now becomes much clearer. Specifically: if we have some (important) process that must be executed (Orders implementation) then if we can also establish that it is normal to place one (strong) person in charge look for the strongest individual of all process stakeholders (Jane) and place Jane in charge of Orders system implementation. Thus, with this representation scheme, the goal hierarchy is itself a procedure (and part of our plan for determining which change anchor to employ). Nevertheless, we are not entirely convinced that Prolog, by itself, is the ideal vehicle for implementing much of our process modelling methodology. In particular, breaking down Prolog statements into goals and subgoals in the manner illustrated above, often leads to a surfeit of fine-grained detail: much of which is often obscure and not entirely relevant to the procedures and plans we are interested in developing. Hence, in practice, we have found the rolled-up versions of our SATBPA conditions and conclusions to be of more use and, again returning to the example developed in the previous section, we may represent our plan for determining an appropriate change anchor as the and/or tree illustrated in Figure 4. Goals in a TKS model must be supplemented with detail concerning context, and enabling and causal conditions. With our approach, much of this information is contained in the rolled-up structures
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
7
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
represented by the nodes of the tree. Allowing for this, our ‘determine a suitable change anchor’ plan may now be stated as: if it is usual to place one strong person in charge of important processes and one strong person is available then use a champion-based change anchor and place the available strong person in charge else if it is usual to place a committee in charge of important processes and stakeholders have reasonably consistent views on the process then use a consensus-based change anchor and place a committee of stakeholders in charge
else look for alternatives to champion- and consensus-based change anchors. if the organisation is facing some critical external threat and the process can be (time-) linked to aspects of the external event then use a deadline-based change anchor and link the process to the external threat else look for alternatives to a deadline-based change anchor.
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
8
Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000
As noted earlier, a perusal of the activity theory literature reveals very little in the way of prescriptive guidelines that might be employed by practitioners. This is unfortunate, since the theory itself appears to have considerable potential – particularly as a basis for dealing with the much neglected, softer issues that have caused so many software engineering projects to fail. Here, we have presented the broad outline of one possible way forward. Specifically, we have suggested that KAT (previously employed to good effect in many areas – including course design), used in conjunction with our SATBPA repository, provides the basis for a broad framework in which task (activity) knowledge may be captured, specified, stored and analysed in a form (and at a level) acceptable to practitioners (in many fields but, particularly, software engineering). We have illustrated our proposed approach by means of an example drawn from the change management literature. We agree with Lindner [9] that effective and skilled deployment of appropriate change anchors is a vital component of any non-trivial change management exercise. However, a perusal of Figure 1 reveals just how broad and complex the software engineering change management process can be – and it is only one component of the total system implementation stage. This makes it imperative that TKSs and associated process models be presented at the right level of detail. In the case of our example, rolled-up SATBPA structures probably resulted in a clearer picture of our task than the alternative structures, derived directly from the underlying Prolog. We suspect, however, that different tasks will demand different levels of granularity and that context and the KAT objective will be principal determinants of the appropriate level. This has been identified as an important future research direction.
5. Conclusion We have presented a broad framework for a software engineering development methodology based on activity theory and KAT. The aim is to empower project managers and others involved in systems development to better deal with the critical human aspects inherent in all non-trivial projects. Our research is aimed at contributing to the development of a sound scientific basis for the software engineering process and, specifically, for that part of the development process concerned with behavioural issues. While a number of methods and techniques commonly employed in software engineering work have reasonably well-developed scientific bases, the same can not be said of the total development process. Systems developed and implemented without a sound set of principles are doomed to unpredictability, with the consequence that
success can neither be sustained nor failure avoided. Our work is based on the premise that, by capturing and formalising relevant people-related factors, we may provide a means of significantly improving the IS development and implementation success rate.
6. References [1] L.L. Constantine, Constantine on Peopleware, PrenticeHall, Englewood Cliffs, NJ, 1995. [2] B. Curtis, M.I. Kellner, and J. Over, “Process modelling”, Communications of the ACM, (35, 9), 1992, pp. 75-90. [3] M. Ellison and G.M. McGrath, “Business process modelling using activity theory: An approach to data capture and analysis”, Australian Computer Journal, (30, 4), 1998, pp. 146-152. [4] P. Johnson, and H. Johnson, “Task analysis and specification for human-computer systems”, in A. Dowton (ed.), Engineering the Human-Computer Interface, McGrawHill, 1991. [5] S.O. Kimbrough and S.A. Moore, “On automated message processing in electronic commerce and work support systems: Speech act theory and expressive felicity”, ACM Transactions on Information Systems, (15, 4), 1997, pp. 321-367. [6] R.A. Kowalski, Logic for Problem Solving, North Holland, NY, 1979. [7] K. Kuutti, “Activity theory as a potential framework for Human-Computer Interaction research”, in Bonnie A. Nardi (ed.), Context and Consciousness: Activity Theory and Human-Computer Interaction, MIT Press, Cambridge, MA, 1996, pp. 17-44. [8] D. Leonard-Barton, “Implementation characteristics of organizational innovations”, Communication Research, (15, 5), 1988, pp. 603-631. [9] J.C. Lindner, “Information technology: Fit and change”, MISR Course Handout, July 1989, Harvard Business School, Boston, MA, 1989. [10] G.M. McGrath and M. Ellison, “A business process modelling approach based on activity theory: Capturing “softer” aspects of organisational behaviour”, Proceedings of the 5th International Conference of the Decision Sciences Institute, Athens, 4-7 July, 1999, pp. 1019-1021. [11] OASIG, “The performance of information technology and the role of human and organizational factors”, Report to the Economic and Social Research Council, UK, available through URL: http://www.shef.ac.uk/~iwp/resprogs/iperf.html, 1996. [12] J. Pfeffer, Power in Organizations, Pitman Pub. Inc., Marshfield, MA, 1981. [13] A.G. Rodriques and J. Bowers, “System dynamics in project management: A comparative analysis with traditional methods”, System Dynamics Review, (12, 2), 1996, pp.121138. [14] Standish, Chaos. Available through http://www.standishgroup.com/chaos.html, 1995.
0-7695-0493-0/00 $10.00 (c) 2000 IEEE
URL:
9
