University Management School:

Large technology and software engineering programmes, such as enterprise system programmes, are increasingly implemented through a mixture of customer and specialist third-party resources. These multi-partner working environments can be thought of as a complex social system, which oftentimes experience various forms of conﬂict. This can be due to competing objectives and priorities of the various organizations, along with incompatibilities of team members within the work-based social network of the implementation programme. If not brought under control, conﬂict can lead to complex emergent behaviours and dynamics within the wider social network, which can severely impact the likelihood of successful programme implementation of these software-intensive systems. Using social network analysis and thematic coding analysis within a case study, we show that the project management of complex software-intensive implementations requires considerable focus on control and communication across the programme-wide social network of team members, which we represent as a cybernetic system. A conceptual framework has been developed that extends extant literature around conﬂict in teams by framing the individual projects and the overall programme-wide implementation as cybernetic systems. The conceptual framework illustrates how a cybernetics approach to conﬂict within enterprise system implementations, can provide new insights into how conﬂict develops within project teams. Finally, we argue that the cybernetic approach allows us to develop project management interventions to mitigate the risk of conﬂict development, or control and regulate conﬂict once it has developed. We conclude by setting the agenda for future research on how conﬂict can be controlled within the implementation of software-intensive systems, such as enterprise systems


I. INTRODUCTION
I T is common knowledge within the technology and software engineering community that the majority of failures within large information system (IS) or information technolgy (IT) programmes are not attributable to the technology, but rather the interactions between team members on the programme or constraints imposed by the end-user and implementing organizations involved [1].In reality, this situation is frequently exacerbated by large technology and software engineering implementations oftentimes being outsourced to external software and professional service providers, where the individual third-party employees have different cultural and educational backgrounds, professional training and eti-quette, and cognitive aptitude, with respect to the in-house customer employees [2].Indeed, it has been shown that the larger technology and engineering implementations are generally assembled into separate project teams who perform development activities in parallel to facilitate the efficient implementation of the programme [3].At the larger scale, such as multi-party IT/IS programmes implemented across multiple geographic locations, there may be hundreds of team members involved, that are employed by both the customer and the various third-party organizations [4].
Whitty [5] has postulated that expansion in scale and complexity of these technology and software engineering implementations, causes them to display characteristics of VOLUME 8, 2020 complex systems.The behaviour(s) that emerge from these socio-technical systems, can be attributed to the complexity that arises through interactions between the large number of team members that come from a variety of employers, and whose individual professional and personal characteristics, may give rise to unforeseen social behaviours and dynamics.Moreover, due to the multi-party environment, the team members may have a set of objectives and priorities that align to the organizational objectives of their specific employer, but that are in conflict with those from other employers; which may ultimately lead to programme-wide conflict, as recently shown by Williams [4].As such, we believe that both the academic and professional communities who are interested in the development and propagation of conflict within large technology and software engineering programmes, will benefit from a new avenue of research that utilizes the concept of Cybernetics.
The IEEE publications and conferences have a long history of applied research and practice-based publications into software engineering project management (e.g.[6]), conflict propagation within large technology and software engineering programmes (e.g.[4]), and the cybernetics of complex systems, such as: multicriteria decision-making in groups [7]; diffusion of information throughout social networks [8]; and the impact of implementers' actions on user resistance to IT implementation [9].The field of cybernetics has exerted an influence on a diverse range of academic disciplines, including: artificial intelligence, biology, computer science, electrical engineering, management, and sociology.It has been defined in a number of ways, but all essentially relate to control of, and communication within, a complex system, be that engineered, living, or social [10].Cybernetics has undergone three main periods of development, with: the initial period that focused on engineered systems spanning the mid-1940s to the mid-1970s, and being termed firstorder cybernetics; the second period that focused on biological systems spanning the mid-1970s to the mid-1990s, and being termed second-order cybernetics; and the third period that focused on social systems beginning in the mid-1990s and giving rise to third-order cybernetics.Within this paper, we build upon this expanding body of knowledge by adopting a cybernetics lens to investigate the development of conflict within large technology and software engineering programmes, and specifically large Enterprise System implementations.A cybernetic lens to analyze projects has recently been advocated by Lent [11], who suggests the approach is required to investigate the dynamics and behaviours of project team members, which are underpinned by various feedback loops.We adopted the case study technique, and analyzed the results through a multi-method approach that used high-level social network analysis, qualitative data analysis, and diagrammatic modelling.Our results indicate that the multitude of team members invariably begin their work within the Enterprise System programme with a shared understanding of the programme-level vision, aims and objectives.However, subtle differences in employer objectives, alongside differences in the personal and professional characteristics of individual team members, slowly give rise to localized forms of conflict, which if not effectively controlled, can lead to conflict at the programme-level through a variety of feedforward mechanisms and feedback loops.
In this article, we will commence with a review of the literature to provide the context behind Enterprise System implementation, the background and theory of cybernetics, and the different types of conflict that can develop within project environments.We then define our approach taken for data collection and data analysis, before discussing the case study that represents a large technology and software engineering programme.We then adopt a cybernetics lens to discuss the development of conflict within the case study, and propose a conceptual framework that conveys how the dynamics and behaviours seen within the case study correspond to first-order, second-order, and third-order cybernetic systems.Finally, we conclude by developing suggestions for further research into the cybernetics of conflict, and how to utilize various cybernetic mechanisms to dampen the effects of conflict once it has developed.

II. RELATED WORK
This section provides an overview of the major concepts that contribute to the theory behind our study.

A. ENTERPRISE SYSTEMS AND THEIR IMPLEMENTATION
Enterprise Systems are large software applications that allow an organization to integrate their often-fragmented organization-wide data that is associated with their various business processes (potentially unique to the organization, and often structured by organizational department or functional unit), into a single software-intensive system that uses preconfigured (and standardized) software modules and the associated hardware and middleware [12].Due to the complexity of modern-day business environments and the increasing size of IS/IT systems, the implementation of Enterprise Systems need to be considered as transformation projects [13] that will impact the organization as a whole, and not merely as a technology project for implementation by the IT department [14].In fact, large organizations usually employ third-party service providers to install and configure these software-intensive systems, and structure the implementation programme around separate projects that align to the functional modules within the Enterprise System and the technical architecture required to host the software system.
The largest implementations may utilize the services of both the software vendor (e.g.Oracle or SAP) and IT or IS professional service providers (e.g.Accenture, CapGemini, Deloitte, etc).Within such an environment, the client, vendor and professional service provider personnel are combined into distinct project teams that relate to the functional modules (e.g.Human resources, Payroll, etc), technical architecture (e.g.web services, middleware infrastructure, database, etc), along with the Programme Management Office (PMO) that focuses on the overarching administrative and contractual aspects of the implementation.Consequently, it is occasionally difficult to discern precisely who is accountable for resolving emergent issues and risks that may span a number of the projects within the overall programme.Additionally, it can be difficult to identify who is responsible for the successful delivery of individual projects, or who is ultimately accountable for the end-to-end delivery of the overall business transformation programme.This integration of personnel from multiple organizations, along with their structuring into project teams that align to the functional modules of the Enterprise System, technical architecture to host the software, and project administration aspects of the programme, result in a complex interconnected social network of team members.Guimera and Nunes Amaral [15] speculate that the key to success of complex networks is their use of a modular structure, which in this case is the structuring of the overall Enterprise System implementation into discrete projects.
Sommerville [16] has argued that software engineering is subtley different from other types of engineering, and therefore the project management of software-intensive systems has a number of unique challenges.Along with traditional project management constraints relating to delivering the product to the customer within the predetermined timescales, ensuring the overall costs are within the agreed budget, delivering the product to the agreed scope, and maintaining a wellfunctioning team [17], software project management has additional challenges.These software specific project management challenges relate to: an intangible product, where it is oftentimes difficult to see progress due to there not being a physical artifact, as is the case in mechanical engineering; the larger software implementations are unique to the particular customer, and lessons from experience as project manager at prior projects are not always relevant; software engineering processes and procedures are not standardized across the world, and are oftentimes either sector-specific (e.g.Public Sector, Financials Sector, Utilities and Energy, etc) or vary between customer organizations [16].

B. CYBERNETICS
Norbert Wiener defined Cybernetics as "the scientific study of control and communication in the animal and the machine" [18], and that it is applicable when a system of interest contains a circular causal relationship, so that dynamics or behaviours developed from the system are able to affect the wider environment, which subsequently affects the system, thereby introducing feedback that initiates a change to the system.He later built upon this definition with specific reference to communication within social systems, by advising that communication is based upon the spoken word being transmitted from a sender and decoded by a receiver, with this decoding step potentially being affected by the mental state of the receiver [19].Indeed, this latter decoding step has the potential to introduce feedback through affecting any emotions being experienced by the receiver at the time of decoding the message, i.e. amplification or reduction of magnitude of emotion.This was further built upon by Shannon [20], who advised that bidirectional communication within cybernetics is a generalization of his Information Theory.Marko [21] extends this further, by explaining that cybernetics is the "science of message transmission, processing, and the regulation and control of complex systems".With specific reference to conflict within Enterprise System programmes, this means that communication between members of the programme may introduce positive or negative feedback to the emotional state or conflict state of individual team members.
Shortly after Wiener's definition of cybernetics, the pioneers of the time began to develop additional granularity into the definition of a cybernetic system so that it could cater for the different types of research questions that are posed when investigating a system, especially a biological or social system.As such, cybernetics is inherently interdisciplinary, with an overall aim to elucidate unifying theories on how complex systems function and can be controlled [22].Three orders of cybernetics were defined, with first-order cybernetics relating to the observed system, and being consistent with the definition from Wiener, is concerned with interactions among variables in the system.Second-order cybernetics is related to observing the system [23], so is concerned with the interactions between the observer and the observed [24]; an example from Enterprise System implementations being interactions between the project manager (observer) and the individual team members (the observed).Whilst third-order cybernetics is more reflexive in nature and provides a way of analyzing the relationships that exist between observers in a system and the effects of these relationships on the system [25].
The underlying premise of cybernetics is that an autonomous system, for example an individual human being, can be portrayed as having a set of personal aims/objectives/goals that they aspire to attain, and that they implement strategies to counter the effects of environmental factors that reduce the likelihood of achieving these aspirations.Heylighen and Joslyn [26] advise that there are three main approaches to managing such perturbations, and thus maintain regulation of the system: buffering, feedforward and feedback.Taking these in turn: Buffering is the damping of perturbations through passive means (i.e. in the absence of active regulatory mechanisms); Feedforward is the suppresion of an environmental factor before its affects have been able to perturb the system, which requires the ability to gather information and anticipate the effects of the perturbation and implement mitigatory measures; and Feedback is the implementation of remedial action after an environmental factor has already affected the system, with the aim of reversing the negative effects and allowing the system to regain momentum towards the aims/objectives/goals.
Finally, Stafford Beer pioneered the field of Management Cybernetics, which he defined as the "the science of effective organizations" [27].Here he applied cybernetic laws and theories to the management processes/practices that were being used in all types of socio-technical organizations.Beer's Management Cybernetics, which focuses on management in general, can be augmented to apply to Project Management specifically.For instance, project management is about control and communication of project resources to ensure the project objectives are achieved within time and budget constraints.Lent [11], with specific reference to cybernetics, advises that project managers, aided by their team and associated technical resources, aim to steer the project towards predefined goals (e.g.project milestones and ultimate objectives).He also advises that the project environment provides feedback to the project, and that the project management processes/procedures that are used to control the project, can be considered analogous to system mechanics from first-order cybernetics.

1) First-Order Cybernetics
Cybernetics, as a field of study, emerged out of the military needs of developing weapon targetting systems and servomechanisms during World War Two [18], with an initial focus on complex engineered systems that contained feedback mechanisms, and in particular, how they could be controlled and regulated [26].As such, the early field of cybernetics was predominantly interested with integrating the fields of mechanical engineering, electrical network theory, logic modelling and control systems, to develop theoretical models that could be used to control physical engineered systems, which Wiener had referred to as Observed Systems [18], and was later defined as First-Order Cybernetics.
The field of cybernetics is underpinned by both engineering and science, and as such, aims to identify regular patterns and repeatable behaviours within complex systems, and the associated mechanisms that underpin them [28].Once the mechanisms are known, we are then able to develop predictions on the system's future state/dynamics due to the regularity/repeatability, and ultimately develop interventions to control the system.There are however situations where mechanism is unknown, and where the concept of a Black Box is invoked in order for us to make causal inferences between how differences in System Inputs can lead to corresponding differences in System outputs, whilst being essentially ignorant to the actual mechanistic behaviours of the system.Ashby [29] was the first to reason this approach, whereby the Scientific Observer constructs a descriptive model that contains an unseen, presumed mechanism, to transform a set of system inputs to a corresponding set of system outputs.First-order cybernetics considers human behaviour to originate from such a 'black-box', but importantly, also considers the world to be a hierarchy of black boxes, such that cells make up humans, humans make up societies or corporate organizations, etc [22].

2) Second-Order Cybernetics
Cybernetics from 1980s onwards became known as secondorder cybernetics and focused not only on what is being observed, but also on the observers who generate their own personal version of reality of the observed system, that aligns to their individual experiences [24].Second-order cybernetics originated from the work of von Foerster in 1974 [30], where he introduced the concept of a second-order feedback loop to cybernetics, which related to the observer of the realworld cybernetic system actually being a cybernetic system themselves, thus having their own feedback loop.This is important because the intent was to redirect the focus of science from that of defining the extent of our knowledge of a system, to that of describing the processes, procedures and techniques that we use to develop our own personal version of reality [31].
The initial field of cybernetics, which focused on the control of a system, was therefore augmented to cater for the fact that there can be double-loop processes within systems (i.e.control processes that provide feedback into other control processes) due to the effects from observers of the underlying system.Hence, second-order cybernetics was born when the focus of investigation shifted to the observation of the observed system [32].Von Foerster termed this the Cybernetics of Cybernetics [23], hence the term second-order cybernetics, but this was subtley rephrased by Glanville, who states that "it is cybernetics, when cybernetics is subjected to the critique and the understandings of cybernetics" [28].Turning back to the concept of the black-box, the crucially important point for second-order cybernetics is that the black-box is constructed by the observer.This in turn means that the observer is associated with the system of interest through their own feedback loop, which incorporates circularity into the observer-observed system relationship [28].Although the early origins of second-order cybernetics were focused on biological systems, these were later used as analogies for social processes, and like constructivism, second-order cybernetics is now concerned with human cognitive systems [22].Indeed, the use of second-order cybernetics to explain the dynamics and emergent behaviours of social systems has now become routine [33].

3) Third-Order Cybernetics
Whereas first-order cybernetics focuses on the system of interest and second-order cybernetics focuses on observing the system of interest, third-order cybernetics focuses on mutually observing systems [33].Third-order cybernetics is underpinned by self-referentiality, where the observer is required to be reflexive, and to explicitly include their act of observing the system of interest, into their explanation of that system's dynamics and behaviours, which Boxer and Kenny have defined as the cybernetics of "observers observing observed systems" [32].As such, third-order cybernetics allows us to investigate the effects of the observer, through their interactions with, the observed system [34].
As would be expected from the interwoven and recursive nature of cybernetics, complex social systems, such as the temporary organization that is created to implement an Enterprise System programme, have characteristics and behaviours that correspond to both first-order and second-order cybernetics.A third-order cybernetic approach to investigating complex social systems builds upon this, through incorporating additional characteristics, such as: 1) they are generated through the cognitive processes of the observer; 2) they can be used by an observer to interact with or manipulate the observed system, but can equally be generated by the observer as an adaptive reaction to their environment; 3) contrariwise, the objectives of the observer can be influenced by the environment, but the observer can equally influence their environment in attainment of their objectives; and 4) due to third-order cybernetic systems being generated through interaction of the observer and the observed system, these social systems are prone to emulate other complex systems that we see in nature [33].As such, third-order cybernetics doesn't just present the background and contextual relationship to understand the observed system, but also gives rise to new approaches for intervening with or maintaining the system [32].

4) Cybernetics of Project Management
A large multi-partner Enterprise System programme is a good example of a complex social system, that managers, in this case Programme and Project Managers, need to control.This organizational complexity is predominantly due to issues relating to inter-organization process control and communication, and when viewed from a cybernetics vantage point, is generally regarded to be a problem of regulation [35].As discussed above, these large multi-partner Enterprise System programmes contain multiple project teams, which are usually focused on different aspects of the Enterprise System (e.g.HR, Payroll, Financials, Technology, Hosting, etc) and consist of project team personnel who come from the different organizations involved in the programme.As such, each of these project teams will have their own teamlevel objectives (e.g.scope and constraints of the individual project), and individual team members will also have their own individual objectives, whether professional (i.e.tasks assigned to them by the Project Manager) or personal (e.g.relating to personal success, promotion prospects, learning new skills, etc).In addition, each project team will have to work within the process and procedural constraints of the wider programme, and may also have dependencies on other project teams, for example, where decisions made by one project team then become constraints for another, or where functional/technical deliverables are commenced by one team, but completed by another.
In cybernetics, these components (i.e.resources, processes, and procedures that constitute a control system) are acknowledged as functional aspects of the complex system, although they do not necessarily correlate to functional units of the Enterprise System or structural units of the programme implementation structure.Heylighen and Joslyn [26] advise that this situation can be generalized as a feedback cycle with two inputs.The first relates to the goal, which is analogous to the preferred state of the system, i.e. attainment towards project-level and individual-level objectives; and the second relates to perturbations, which encompasses all the processes, procedures and constraints imposed at the programme-level implementation environment that the project team and individuals do not have control over, but can affect them achieving their goal(s).Furthermore, in complex systems, such as the temporary organizations of large Enterprise System programmes, the goals are oftentimes categorized into a hierarchy, where the programme-level goals control the setting of project-level goals, and then individual team member goals.
As discussed above, the original definition of cybernetics related to control and communication of man and machine, with particular focus on self-regulation and the maintenance of system dynamics at an equilibrium point through buffering, feedback, and feedforward.Project management can be considered as a formalized collection of project phases, process groups and processes (see PMI PMBoK [17]), that focus on control and communication of project resources to achieve a set of predefined project objectives, within prespecifed time and cost constraints.Due to the considerable degree of communication between team members, control of resources, and impacts due to environmental factors, a cybernetics approach to project management becomes an attractive proposition [11].With specific reference to thirdorder cybernetics, this can be seen when the behaviours of team members are observed by other team members [25] and provide feedback to the observers action(s).This observation and feedback is of paramount importance for the project manager, in that their observation of individual team member behaviour(s) and overall project-level system dynamics, act as the stimuli for potential interventions to control the system and steer it towards achievement of the project-level objectives.
An important phase of the Project Lifecycle is that of Monitoring and Control (see PMI PMBoK [17]), which emphasizes that project team members continuously monitor their performance against the approved plans (e.g.project schedule, scope definition, requirements specification, risk register, issue log, etc), to choose what tasks should be implemented next, and if necessary identify and develop interventions in order to maintain progress against the planned scope and budgeted time and cost constraints.The monitoring and control activities within project management can themselves be subject to control, through for example adjusting actions if the monitoring and control activities (e.g.reviewing schedule, reviewing risks, identifying issues, etc) are not performing to their full potential, thus can be deemed a second-order cybernetic system [11].Finally, because the project manager observes the project as a whole (first-order system) and also observes the effects of project management techniques alongside the processes and procedures that the project has to comply with, they are deemed to be a thirdorder cybernetics system [36].Rivard and Lapointe [9] build upon this notion through their cybernetic theory of user resistance in IT implementations.Their theory assigns the implementers to act as cybernetic control devices, whose objective is to ensure that the resistance from users is kept to a minimum, through a variety of interventions that aim to act as negative feedback mechanisms to dampen down resistance.

C. CONFLICT IN PROJECT TEAMS
Conflict, when applied to group situations such as project teams, has been defined as interpersonal incompatibilities or the divergence of outlook/opinion between members [37].Conflict has been found to develop from a variety of situations encountered by project teams [38], and to take five main forms: 1) task conflict, such as divergent opinions on how activities should be performed or project deliverables developed; 2) process conflict, which in a project context could develop due to enforced compliance with bureaucratic policies and procedures; 3) relationship conflict, which could be due to personality clashes or differences in personal characteristics between team members; 4) intrateam conflict, which relates to conflict between team members within an individual project team; and 5) interteam conflict, which relates to conflict between team members in different project teams.Finally, conflict within project teams has been found to have a pronounced relationship with the individual team member's affective experiences [39], and as such, has been argued to be intrinsic to project team dynamics [40].

1) Task Conflict
Task Conflict relates to functional conflict within project teams that is focused at the level of work being performed, which is frequently termed either an activity or a task [40].As such, task conflict relates to the recognition and ensuing reactions/responses that arise between team members that have divergent opinions and perspectives on the scope of project tasks and how they should be performed [41].With specific focus to Enterprise System programmes, task conflict may develop between team members in positive ways, such as through personal excitement and animated discussions when discussing ideas on how to tackle project tasks, or negative ways, for instance when entrenched positons are taken and the animated discussions then morph into arguments [42].
Jehn and Shah [43] discovered that a moderate level of task conflict is advantageous for certain categories of tasks.A relevant example is that during the design phase of large IS/IT programmes, it has been observed that if the customer/client issues explicit statement of requirements to software developers, the developers frequently reduced their effort on requirements analysis and instead jumped to solution design activities.It was also found that these early solution ideas often utilized the reuse of solutions from previous projects, which risked the development of suboptimal solutions on the current project [44].Similarly, Shah and Jehn [45] discovered that when teams were confronted with complex cognitive tasks, the most successful were those that contained members who had divergent perspectives and opinions.This is regularly experienced during the design phase of Enterprise System programmes, in particular, tasks related to requirements analysis; or during the development/delivery phase when team members are confronted with complex functional or technical issues that require the collective cognitive power of the whole team in order to formulate contingency plans and technical workarounds.
Research has found that when task conflict is effectively managed, the project team is able to assimilate the diverse perspective and opinions into a concensus, which is oftentimes a better solution than that proposed by individual team members, and thus leads to higher quality decision-making within the team [46].Conversely, if task conflict is not effectively managed, there is a propensity for tension to emerge within the team when one or more dominant team members are too forceful in promoting their ideas/opinions [40].If left unchallenged, this tension can evolve into significant unease between project team members, which may ultimately result in long-term antagonism and a reluctance for the team members to continue to work together, or to be part of the same team in future projects/programmes.

2) Process Conflict
Process Conflict relates to how tasks are performed and whether administrative factors, such as policies, processes or procedures impact on them being successfully achieved [47].When project teams have been found to experience poor team morale and corresponding low levels of productivity, it has often been identified that process conflict is to blame [42].With specific focus to Enterprise System programmes, process conflict may develop between team members through four main scenarios.Firstly, when policies, processes or procedures are found to be overly bureaucratic, thus requiring considerable time and effort to adhere to the administrative side of the policy/process/procedure [48], which takes the team member away from performing their functional/technical tasks.Secondly, process conflicts can arise from issues of duty, whether to themselves, their employer, or their multi-organizational team.Thirdly, issues with allocation of resources, so that some team members feel that they are unfairly overallocated with workload, and thus do not have equity or parity with respect to colleagues.Fourthly, excessive accumulation of technical debt due to poor decision-making [49] or dependencies on the work of others, which requires coordination between resources, and if dependent on the technical work of another project team, also requires the project manager in the other project team to be sympathetic to this dependency and the subsequent consequences of late delivery.[50].It has recently been discovered that process conflict can develop between team members through: disagreements on responsibility for task completion; communication issues, in particular due to decisions being made by a subset of project team members, and that these may not be recorded in relevant project documentation (e.g.functional specifications, test plans, conceptual architecture documentation, etc), so have adversely impacted other members of the project team, or members of another project team [4].

3) Relationship Conflict
Relationship Conflict relates to conflict that develops due to personal issues between members of a project team, for example anger, irritation, frustration and annoyance are oftentimes the outward symptoms that emerge through these personal differences [42].Amason and Sapienza [51] argued that relationship conflict can be categorized as a type of affective conflict, due to the emergence of tensions between team members being felt, by them and other team members, when they work together within the project.In fact, the consequences of relationship conflict can result in more than overt tensions between team members, having also been observed to develop feelings of mistrust and intolerance between team members, in particular due to their perceived Machiavellian intentions and inauspicious behaviours [52].These feelings of mistrust and intolerance may give rise to significant emotional stress and anxiety, which correlate to reduced cognitive reasoning skills [53] and a decrease in performance [40], which may ultimately lead to poor quality project documentation and deliverables [54].Unfortunately, this can be compounded if the anxiety that team members experience, later morphs into feelings of anger, frustration or fear [55], because these feelings either lead to negative emotional reactions within the project team(s), or to team members disconnecting themselves from the project [56].
With specific reference to Enterprise System programmes, relationship conflict between team members, either within an individual team or between different teams, may lead to negative views of the project (and wider programme) aims and objectives, along with a subsequent reduction in motivation/commitment to complete functional or technical tasks that they have been assigned.Furthermore, large Enterprise System programmes that use a multi-partner approach to implementation and management, are oftentimes confronted with relationship conflict as a consequence of competing corporate objectives and organizational dynamics, which are enacted by their employee representatives in the multiorganizational project teams [4].In addition, differences in cognitive abilities and occupational specialisms have been found to increase the likelihood of conflict between members of software teams [57].Wall and Nolan [58] reinforce this point when they advise that if relationship conflict is not acknowledged and properly managed, the consequence is always a reduction in performance from those team members affected and a reduction in productivity of the project team as a whole.With respect to multi-partner Enterprise System programmes, the most significant incidents of relationship conflict may lead to nonfulfillment of project-level objectives, or worst still, nonfulfillment of overall programme objectives following the propagation of conflict across the programme-wide social network of team members [4].

4) Intrateam and Interteam Conflict
It should be noted that Interpersonal Conflict relates to conflict between two or more people, whilst Intrateam Conflict relates to conflicts that develop within an individual project team.Rout and Omiko [59] stipulate that to be deemed intrateam conflict, the conflict needs to involve the majority of the project team members.As such, we will use this definition for our study, which means that although conflict may develop between two or more people within an individual project team, it is not deemed intrateam conflict until it has propagated to involve the majority of the team members.Korsgaard et al. [60] advises that intrateam conflict can develop due to two types of factors: 1) internal factors, such as differences in personal characteristics or communication styles, which we believe are analogous to the causes of relationship conflict; or 2) external factors, such as dependencies on the work of other teams or overly burdensome administrative procedures, which we believe are analogous to task and process conflict.
Conversely, Interteam Conflict relates to conflict that develops between two or more distinct project teams [61].Although the causes of interteam conflict development are specific to external factors, like the development of intrateam conflict, the causes are ultimately associated with task, process or relationship conflict.For example, the cultural transmission model of Gelfand et al. [62] models the propagation of relationship conflict between two groups/teams due to their cultural differences, whilst Roberts et al. [63] linked the development of task conflict that arose due to overly complex tasks to issues with communication within, and between, software project teams.

5) Conflict Resolution Strategies
Project team members respond to conflict in their own individual way, which can be based upon a large number of factors, including their personalities, culture, education, and importantly experiences from prior conflict.These factors, in particular the latter, may contribute to the development of a default response to how individual team members react to conflict.There is an increasing body of knowledge around conflict responses and resolution strategies, which have traditionally revolved around a Conflict Style Inventory.The most common inventories have taken inspiration from the Managerial Grid Model of Blake and Mouton [64], where an axis between Concern for People and Concern for Production is used to identify five main styles of management.Two popular conflict style inventories are the Thomas Kilmann Conflict Mode Instrument [65], which has been used as a standard since 1974, and the Kraybill Conflict Style Inventory [66], which provides a more culturally nuanced perspective.
For our research, we focused on the model developed by Thomas and Kilmann, whereupon they updated the axes of the Blake and Mouton model to reflect Assertiveness and Cooperativeness.The assertiveness axis relates to the degree to which a team member endeavours to fulfil their own needs, whilst the cooperativeness axis relates to the degree to which a team member endeavours to fulfil the needs of others [65].Thomas and Kilmann plotted five conflict resolution styles onto these axes, relating to: Avoidance, Accommodation, Competition, Collaboration, and Compromise.
Taking these in turn, Avoidance is a conflict resolution style that is both uncooperative and unassertive, and results in the underlying cause(s) of the conflict not being addressed, which means that neither team member has their needs fulfilled.Examples of avoidance strategies include: the postponement of crucial decisions until a later date, removing yourself from the decision-making process (e.g.project committee), or more drastically, resigning your position in a project team so that you are not affected by the conflict with other team members.
Competition is a conflict resolution style that is extremely assertive, whilst also being uncooperative.In general, this arises through an abuse of power by one team member over another, and results in that team member fulfilling their needs at the expense of the other team member.Examples of such a win-lose situation, include: an individual team member aggressively defending their position, aggressivley standing up for their rights and entitlement, or deciding to win the perceived battle at all cost.
Accommodation is a conflict resolution style that is unassertive and very cooperative, whereby a team member sacrifices their personal needs in order to promote the acquisition by another team member of their own needs.Examples include deference to authority figures within the project (e.g.Team Leaders, Project Managers, or team members with more experience), or the downplaying of differences and emphasis on similarities in order to preserve the working relationship with the other team member [67].
Collaboration is a conflict resolution style that is both assertive and cooperative, whereby both team members aim for a win-win situation through the mutual achievement of their aims/needs.Examples include: the open and frank discussions around each other's needs in order to try and resolve the disagreement or cause(s) of the conflict; entering into a dialogue in order to develop additional approaches, which may result in a better solution than those originally proposed; the sharing of key resources in order to develop economies of scale or the frequent communication of progress on specific tasks in order to mitigate the risk of schedule slippages due to dependencies across project teams [67].
Finally, Compromise is a conflict resolution style that falls in the middle of the two axes of cooperation and assertiveness.Within a project environment, this approach is followed when the overriding goal is to ensure harmony between the team members or different project teams.Examples include the provision of concessions to the other team member(s); or, resolving problems/issues quickly through focusing on a middle-ground between the team member(s), in order to avoid the issues escalating into conflict [65].

III. RESEARCH METHODOLOGY
Our research design is based on a multi-method approach that utilized the case study paradigm of Yin [68], along with deductive inference and inductive research.We have applied Yin's five components of effective case study research design using a similar process to that advocated by Ambituuni et al [69], but due to our need for a multi-method approach to analyze social network and process data [70], [71], we have aligned our overall data collection and analysis strategy with that advocated by Miles and Huberman [72].The case study approach was chosen, because like cybernetics, it allows us to focus at the system-level behaviours and dynamics of a complex system [73], in particular, by providing the ability to perform an in-depth investigation on the causal relationships behind the dynamics and emergent behaviours of the system within its real world sociotechnical and spatiotemporal contexts [74].Deductive reasoning was used following a review of the cybernetics literature to develop an initial conceptual model.Conversely, inductive reasoning was used following focus groups, participatory observation, and documentary analysis, to augment the initial conceptual model.This integration of deductive and inductive approaches provided an ability to link theory to observable reality [75], and was consistent with the process advocated by Miles and Huberman [72] for developing conceptual models through case study research.
The motivation behind this study is to complement recent research into conflict development (and propagation) within multi-partner technology and software engineering programmes (e.g.[4]), by using a cybernetics lens to develop interventions that may mitigate the risk of conflict developing within the social networks of these programmes, or to dampen down the effects of conflict should it develop.We believe that cybernetics, being based on control and communication within the animal and the machine [18], is an obvious choice for this purpose.The rationale for this paper's methodological fit [76] is our objective to confront problems of theoretical and practical importance around the issue of conflict within multi-partner technology and software engineering programmes.The study utilized existing theoretical and empirical work around conflict development within teams, work-based social networks as cybernetic systems analysis, project management of Enterprise Systems and the uniqueness of the case to justify the creation of a conceptual framework for the cybernetics of conflict in multipartner Enterprise System implementations.Quality assurance of the research design was performed according to Yin's case study tactics: construct validity, internal validity, external validity, and reliability [68].Construct validity ensured that appropriate measures were identified for the concepts being studied, and was achieved through the use of multiple sources of evidence.Internal validity focused on establishing causal relationships, in particular feedback loops relating to project management of the software implementation, along with the social dynamics and emergent behaviours within the case, and was achieved through explanation building.External validity ensured that the case study's findings can be generalized, and was achieved through reference to theory.Reliability demonstrates that the procedures used in the study can be repeated, and was achieved through developing focus group protocols, a case study database, and maintaining a chain of evidence.

A. DATA COLLECTION
Due to the multi-method approach, a hybrid form of data collection was taken.The initial data collection activity focused on the collection of Programme and Project documentation to facilitate us developing a comprehensive understanding of the aims, objectives and business drivers that justified the need for the business transformation programme, along with the relative progress in managing the individual projects and the wider programme.This documentary data enabled us to develop an initial conceptual model, by providing the background to the decisions taken to proceed with the implementation programme, along with the context of the multipartner programme environment and the relative progress in managing the implementation.
The second data collection phase increased our understanding of the programme structure, along with the reporting and management hierarchy within this structure.A focus group was held with five project managers from a cross section of the projects on the wider programme, representing: customer, software vendor, and the three professional service providers.The objective of this first focus group was to develop an outline structure of the implementation programme, along with a detailed social network map of the individual team members, with focus on the formal workbased relationships between team members of the various project teams, alongside the formal relationships that occur between project teams [77].The broad theme of conflict and how it developed was also discussed to elicit interesting examples that occurred within the various project teams.The majority of interesting examples related to the HR Project team, in particular due to the different styles of project management and personal characteristics between the customer project manager and the third-party project managers within the project team.
The third data collection phase focused on the HR Project team in order to develop a detailed understanding of how conflict can develop between two or more team members of a project team.In addition, focus was also applied to develop a detailed understanding of how conflict propagation can occur to create conflict within the entire team.We performed three focus groups that were comprised of team members from the HR Project that were grouped by their organization (see Table 1 for focus group composition).The objective of the focus groups was to gain a detailed understanding of the types of conflict that were developed within the HR Project, and to discuss interesting examples that would allow us to understand: why the conflict arose; who it was initially between; whether it propagated to encompass additional members of the project team; what the short-term and long-term consequences were; and whether it was able to be resolved.The focus groups were held onsite at the project location, were audio recorded, ran for 90-120min, and were conducted with adherence to ethical considerations.The audio files were subsequently anonymized during the transcription process, and analyzed using the framework described below.

B. DATA ANALYSIS
Our data analysis framework consisted of four complementary strands for explanatory analysis of the case study (see Fig. 1).First, the social network topology of the multipartner Enterprise System programme was developed following the data collected from focus group 1.This allowed us to develop a detailed understanding of the formal workbased relationships between each of the resources on the programme with specific reference to the relationships within individual project teams and also between different project teams.Although providing an underdstanding of the social network environment in which the programme implementation occurs, by itself this does not allow us to develop a detailed understanding of the causes of conflict development, and thus needs to be augmented with findings from other analytical approaches.We have therefore adopted our previous approach for data analysis within case study research [4], through taking inspiration from Martínez et al [78] to integrate high-level concepts and techniques from social network analysis with the principles of qualitative case study research [68], in order to evaluate the development and propagation of conflict within multi-partner technology and software engineering implementations.
The second strand of data analysis focused on the transcripts of focus group 2-4, which provided a qualitative perspective on how conflict developed within the HR Project team.Through following a similar approach to Ambituuni et al. [69], we utilized an inductive approach to thematic coding analysis that was underpinned by the strategy of Braun and Clarke [79].Specific focus was made to the causes and context of task, process and relationship conflict development within the project, and through a detailed analysis of the examples discussed within the focus groups, provided in-depth explanations of the local effects of conflict, i.e. consequences within the HR Project team, and between the HR Project team and other teams on the programme.Familiarization and understanding of the qualitative data was obtained through multiple iterations of reading the entire set of transcripts from the focus groups.Each transcript was read a minimum of three times, which facilitated the emergence of new themes upon each iteration of reading, or the refinement of existing themes.Within this strand of analysis, the themes that emerged were focused on development of task, process or relationship conflict within Enterprise System implementations, and were assigned initial codes that represented features of interest within the data set [80].We completed this strand of data analysis by making connections between the themes and codes, and also establishing causal links of conflict development to specific resources/roles within the programme.Finally, there was a small amount of rationalization of themes in order to develop a meaningful set of categories.Briefly, this was performed through collapsing of disparate themes to group them into a single cohesive theme, to separate a large theme into a more granular collection of individual themes, or to exclude no longer relevant themes [79].
The third and fourth strands of data analysis again focused on the qualitative transcripts from focus groups 2-4, but the themes that formed were focused around conflict development within and between teams on Enterprise System implementations (third strand), along with conflict development as a cybernetic process (fourth strand), which is underpinned by the cybernetics of project management and second-order cybernetic systems.The thematic coding analysis during both strands was complemented by diagrammatic modelling which took inspiration from Soft System's Methodology [81] to model the development of conflict between the resources involved in the HR Project and the subsequent propagation of conflict throughout the social network of the HR Project team.

IV. CASE STUDY: THE RESOURCE MANAGEMENT PROGRAMME
The case study pertains to the implementation of Enterprise System software that formed part of a major strategic modernization programme being implemented by a large United Kingdom (UK) based organization (the Customer).The customer had initiated a major Information System and Information Technology change programme that would drive more efficient business processes and cost savings throughout the entire back-office functions of their business, by integrating the new Enterprise System with existing systems.This business-wide initiative was termed The Resource Management (RM) Programme, with the Enterprise System representing a Commercial-off-the-Shelf (COTS) application suite, which provides a set of standardized business processes relating to the most common back-office functions, including: Human Resources (HR), Payroll, Financials, and Procurement.Through integrating these out-of-the-box business processes with a suite of new middleware and hardware facilities, the RM Programme aimed to introduce best practice to the employees located within back-office support functions around the UK.
The RM Programme comprised a multi-partner environment, with a global software vendor who specialized in enterprise systems being appointed as the sole software provider, alongside three Professional Service Providers to act as Subject Matter Experts.Two of the Professional Service Providers provided knowledge and guidance around the configuration and extension of the functional modules that provided out-of-the-box business processes, whilst the third focused on the IT hardware and middleware architecture that was necessary for hosting the Enterprise System.The customer and software vendor structured the overall programme implementation around the functional modules within the Enterprise System (e.g.HR, Payroll, Financials, etc) and the various technical aspects of the middleware and hardware infrastructure (e.g.Hosting, Helpdesk, etc).
The case study therefore constitutes a large Enterprise System programme that is implemented through the use of multiple third-party organizations who have the necessary project management, functional, and technical expertise.Resources from both the customer and these third-party organizations were assigned to project teams that aligned to the functional modules within the Enterprise System or the technical areas associated with the middleware and hardware infrastructure needed to host the software (see Fig. 2).As each project team comprises resources from different organizations, there is increased potential for conflict development, which has recently been described by Williams [4].The aim of this study, is therefore to advance our knowledge of how the cybernetic system of Enterprise System programmes and the secondorder cybernetic system of project management can facilitate conflict development.In addition, through conceptualization of this situation, our aim is to establish mitigation approaches to reduce the likelihood of conflict development, along with contingency plans that may reduce the consequences of conflict if it has already developed.

A. FIRST-ORDER CYBERNETIC SYSTEM
A First-Order Cybernetic System corresponds to the Observed System, which in our case is the HR Project within the wider RM Programme.The first focus group allowed us to define the complete list of 159 team members within the RM Programme, along with core work-based demographic information relating to: their employer; the project team that they belong to; their role within the project; and their highlevel role type (i.e.Management, Functional or Technical).In addition, the formal work-based relationships for each team member were defined, which were initially represented within an adjacency matrix, before being transformed into an undirected network map.The network consisted of 972 undirected work-based relationships, which provides an average number of connections per team member of 12.23, and a network density of 0.077, meaning that the network is relatively sparse [4].There were five key work-based relationships of interest, which are consistent with Walker [82] and corresponded to: dependence on team members for sub-components of software code and for key information; feedback on performance from team leaders and project managers; reporting to team leaders, project managers and the PMO; escalation of issues for resolution by higher authority; dependence on team members for extra resources.
The HR Project consisted of 32 team members, with the majority coming from the Customer HR Department, so being functional specialists, along with a mixture of functional and technical resources from the Software Vendor (both onsite and offshore in the shared services development centre in India), and finally 4 resources from Professional Service Provider 2 who acted in a Subject Matter Expert auditing and advisory role (see Table 2 for HR Project Team composition).Fig. 3 defines the formal work-based relationships of the HR Project team members and how the project is situated within the wider RM Programme social network.There were found to be 478 undirected work-based relationships, which equates to an average number of connections per team member of 14.94.The maximum number of possible connections in the social network of the HR Project would require all team members to have a formal work-based relationships with each other, and would provide 992 separate undirected connections.As such, the density of the HR Project social network is 0.482, or 48%.Furthermore, through documentary analysis and analysis of transcripts from the four focus groups, the HR Project social network was found to contain: Knots, Cut-Points (i.e.Bridgers), Social Circles, Cliques and Structural Equivalence nodes (terminology used as per [83]).
We identified three knots in the HR Project that corresponded to the sub-sets of team members from the three different employing organizations, i.e. knot1 consists of 16 team members from the Customer, knot2 consists of 4 team FIGURE 3: The HR Project Environment: Social network for the HR Project.This social network corresponds to the workbased relationships of resources within the HR Project.Building upon the programme structure defined in Section IV, it can be seen that the HR project is a core sub-network from the overall programme-level social network, and that there are specified resources who have formal working relationships with counterparts in other project teams.members from PSP2, and knot3 consists of 12 team members from the Vendor.As could be expected, the team members within these knots were shown to have strong ties to each other (i.e. with fellow team members form their employing organization) due to their reliance on each other for information, assistance and expert knowledge.Conversely, the team members within an individual knot were also shown to have weak ties with those team members in other knots (i.e. from another employing organization), due to the coordination required in order to complete project-level objectives and to ensure validation and quality assurance of design specifications, configuration of the HR module, iterative development of custom extensions to the HR module, and the various phases of testing (e.g. unit, system, integration and acceptance).The Customer PM (CustHRPM), PSP2 PM (PSP2HRPM) and Vendor PM (VenHRPM) acted as the cut-points within the social network of the HR Project, helping to bridge the 3 knots when tensions arose between the functional and technical team members.Similarly, as the HR Project Team as a whole can be defined as a social circle, the 3 HR PMs also acted as bridgers to link their respective knot and indeed the HR Project Team as a whole to the wider programmewide social network and to other social circles (i.e.project teams).
We also identified three cliques, which were comprised of the same team members as the knots, thus: clique1 had the same team member composition as knot1 and represented a 16 member 2-clique, because each team member could connect to the others either through a direct formal workplace relationship (i.e. 1 link), or indirectly through that of an intermediate team member (i.e. 2 links); clique2 has the same team member composition as knot2 and represented a 4 member 1 clique; and clique3 has the same team member composition as knot3 and represented a 12 member 1 clique, meaning that all team members were directly connected to each other.Structural equivalence was identified for the 3 functional resources from PSP2, the majority of functional resources from the Vendor, and the majority of technical offshore resources from the Vendor.It is believed that this structural equivalence arises from the standardized functional/technical training that they complete with their employing organization, alongside familiarization of the HR module within the enterprise system software and similar prior experiences of implementing the module on previous projects.A few exceptions were of course identified, which related to niche functional (e.g.employment law) or technical (e.g.database administration or technical architecture) skills, but on the whole, structural equivalence was common across team members from their employing organization.Finally, although PSP2HRPM and VenHRPM were not identified to have structural equivalence, their expertise in project management was deemed to be transferable to other Enterprise System modules, so they were identified as having role equivalence to Professional Service PMs or Vendor PMs in other project teams.
As discussed in Section IV above, the RM Programme  was an IT and IS business transformation programme, which aimed to facilitate more efficient business processes across the Customer organization, alongside generating cost savings to back-office functions.With respect to the Customer's Human Resources Department, the two aims of the HR Project were to: 1) utilize out-of-the-box business processes to introduce best practice to their HR processes and procedures; and 2) to generate cost savings by streamlining as many processes as possible, and automating these where they can, in order to reduce the number of administrative staff involved in the business function.These aims will be delivered through implementation of the Enterprise System, which provides an integrated service across HR, Finance, Payroll and Procurement.Furthermore, and where appropriate, the HR module will maximize the use of self-service functionality, thus moving the administrative and data entry tasks onto individual employees, so reducing the administrative burden within the HR Department.Functionality within the HR module was structured around: recruitment of new staff, the employment lifecycle (i.e.personal details, assignment to roles, pay and benefits, appraisals, disciplinary and grievance, end of employment), competence management, performance management, learning and development, absence management, and time and attendance (see Fig. 4).

B. SECOND-ORDER CYBERNETIC SYSTEM
As the Customer's overall organizational objective through implementing the RM Programme is to reduce costs, a number of environmental obstacles are introduced into the complex social system that represents the multi-partner delivery environment of the RM Programme.Of paramount importance is that having become aware of the medium-tolong term consequences from a successful delivery of the RM Programme, individual customer employees who want to retain their jobs, and those of line managers who want to ensure their subordinates retain their jobs, changed their behaviour towards the Enterprise System implementation, and within the HR Project, became: resistant to project delivery,

Input Output
Team Member Response FIGURE 5: Team member response as a Cybernetic System within the HR Project.The project status, wider RM Programme environment, alongside an individual team member's emotions/motivations and personal experiences, all contribute towards the mental model that the team member has of the HR Project, and how they make sense of the situation, and how they respond to the situation and behaviours of colleagues.
detached from the RM Programme and HR Project goals, subversive towards the Vendor and PSP2 team members, and aggressive towards VenHRPM.These behaviours can all be explained through conflict development as part of a cybernetic system.From a cybernetics perspective, the development of task, process or relationship conflict in situations such as this, is perfectly normal.Observers within a cybernetic system, i.e. the team members in the HR Project, sense/observe the project dynamics and behaviours of colleagues, and create a mental model of the situation.If these project dynamics or colleague behaviours do not align with their personal values, motivations or objectives, then the goals of the first-order cybernetic system (the observed system) of the HR Project do not align with their personal goals as a second-order cybernetic system (the observing system).The team member then expands upon their mental model to try and predict how the project-level dynamics and colleague behaviours will affect their goals, along with developing response stategies to try and safeguard their goals (see Fig 5).
The RM Programme was initiated by the Customer organization to facilitate medium-to-long term efficiencies for their operations, thus reducing costs and maximizing profits through a software-intensive business transformation programme.All levels of the Customer organization were made aware of these benefits during the project definition and contracting stages, and in the early phases of the RM Programme, the Customer resources aligned their personal goals and objectives with that of their employer.However, once CustHRPM became aware of the consequences of successful implementation of the RM Programme to her and her team, it was inevitable that she would disseminate this information to her team members.It was also inevitable that she would begin to develop and implement interventions to try and minimize the likelihood of successful implementation of the HR Project, or to at least slow the pace of delivery in order to buy time so that her team members, some of whom were close friends or family, could commence VOLUME 8, 2020 Project Manager/ Team Member (Observer) Team Member (Observer)  looking for employment before completion of the RM Programme.The relationship between the Observed System of first-order cybernetics and Observer in second-order cybernetics is depicted in Fig. 6, where the Project Manager or Team Member observes the project dynamics and behaviours of other team members, alongside potentially documenting these dynamics/behaviours in various project management documentation, such as progress reports, updating project schedule, updating risk register, creating new project issues, creating a change control request due to evolution of project scope/requirements.

1) Task Conflict as a Second-Order Cybernetic System
As discussed above, the HR Project consisted of 32 team members who were employed by the Customer, Vendor and PSP2; with the overwhelming majority being co-located at the Customer office, but the Vendor also having 6 resources (4 Technical and 2 Functional) based at their Offshore Services Centre in India.In addition, the wider RM Programme was structured around separate Projects that implemented the separate modules within the Enterprise System alongside the associated technical architecture, and that these were implemented using a single Software Vendor along with three Professional Service Providers through back-to-back contracts.This meant that none of the third-party providers had contractual relationships with each other, so the contractual model could be metaphorically termed a Hub and Spoke model, where the Customer acted as the Hub and the individual third-party providers acted as the Spokes.As such, within this contractual environment, the Customer was accountable for ensuring overall delivery of the RM Programme.Documentary analysis revealed that all of the Customer and PSP2 team members were assigned to the HR Project for the duration of the RM Programme (circa 3.5 years), but that there was frequent changes to composition of team members from the Vendor.
The wider environment of the RM Programme, in which the HR Project was situated, led to a number of incidents of task conflict within the HR Project.For instance, the contractual environment facilitated the emergence of a number of task conflict events, which from a cybernetics perspective, acted as feedforward into the implementation of the HR Project as a second-order cybernetic system.Through focus groups 2-4, it emerged that the most significant reason for task conflict development was due to insufficient requirements gathering and analysis by the Customer at the preprogramme scoping phase.This resulted in a contract with the Vendor that omitted critical functionality to ensure the HR module within the Enterprise System could handle all of the core business processes performed.Two key examples included: the lack of functionality to cover the Offer Letter and Contract Management processes related to recruiting new staff; alongside the assumption that 50 custom reports would be sufficient to cover the internal reporting requirements of the HR Department.The former resulted in significant task conflict during the design phase of the HR Project because the Customer HR team members assumed that it was within scope and consistently requested system design activities to include this functionality, whilst the Vendor HR team members consistently resisted requirements relating to Contract Management processes from entering the design specifications.The Vendor team offered to develop functionality surrounding the Offer Letter as part of the provision of 50 custom reports, in order to dampen the task conflict.However, it was soon realized that the concept of the Offer Letter was actually a phrase used to define the hardcopy output that was sent to the successful job applicant at the end of the Recruitment process, but at the technical system level was actually a very complicated set of processes.This was compounded by the fact that the Contract Management process was again a set of integrated functional processes, that were underpinned by an equally complicated set of technical processes within the Enterprise System software.Through significant requirements analysis and investigation of the out-of-the-box Enterprise System functionality, it was discovered that these business processes could not be replicated by the standard business processes within the software, and therefore had to be developed as custom extensions to the HR module within the Enterprise System.Similarly, a thorough requirements gathering and analysis exercise was performed around the internal reporting requirements within the HR Department, which culminated in the specification of 129 individual reports.These additions to the HR Project scope were provisioned for through the Change Management process and culminated in a very expensive Change Note to the original contract.
Another major issue that resulted in task conflict within the HR Project was the fact that the Customer team was disproportionately staffed with junior resources that had little experience of more than one business process within the overall set of HR-related business processes.These Customer HR resources did not have a clear understanding of how their specific area of HR connected with the other HR business processes, so although they worked closely with the Vendor HR team members to configure the HR module and design extensions to the out-of-the-box software, they were unable, and unwilling, to sign-off the configuration documents and design specifications.This had the effect of significantly delaying the overall design phase of the HR project because all requirements, configuration, and design documentation had to be signed-off by either the Customer HR Training Lead (CustHR2) or CustHRPM.Not only did this cause task conflict between the Customer and Vendor resources within the HR Project, but it manifested itself in positive feedback, through initial delays to signing-off documentation, causing delays to other downstream (i.e.later scheduled) documentation due to dependencies in the HR software module design.As such, this instance of task conflict was amplified and also led to further task conflict due to the fixed-price nature of the contract between the Customer and Vendor, which set responsibilities and obligations on both parties.Due to the inability of the Customer HR team to sign-off core design documentation in a timely manner, the Change Management process was again enacted, which once again culminated in another expensive Change Note to the original contract.

2) Process Conflict as a Second-Order Cybernetic System
As discussed above, the HR Project was implemented as part of a wider business transformation initiative that required implementation of a software-intensive system throughout the back-office functions of the Customer.In addition, the structure of the RM Programme was not only to reflect the underlying functionality of the Enterprise System, but also to facilitate efficient programme management, which required the creation of the PMO to centralize project and programme management monitoring and control, such as the reporting of progress, risks, issues, and requests for change.This centralized PMO developed a Customer-centric set of Standard Operating Procedures (SOPs) for the RM Programme that was heavily based on the PRINCE2 method [84], which provides a comprehensive set of project management procedures that are underpinned by a considerabe number of project documents.In addition, the PMO developed a governance structure within the RM Programme that consisted of a number of committees that would analyze requests for change from the initial contract, consisting of: The enforcement of these SOPs alongside the various steering committees led to a number of incidents of process conflict within the HR Project, that were all ultimately underpinned by the significant administrative burden that was imposed on the team members.Through focus groups 2-4, it emerged that a number of mild-to-moderate instances of process conflict were due to the considerable administrative overheads, such as the weekly reporting requirements at various levels of the project implementation.An example being that individual team members had to complete progress reporting templates and send to their PMs, that the PMs from the various organizations had to integrate progress of their team members into an organizational HR Project reporting template, and that CustHRPM, VenHRPM and PSP2HRPM then had to meet and integrate their individual reported progress into a HR Project report for submission to the PMO.At each step of the weekly reporting cycle, the process conflict became amplified due to positive feedback, which was further compounded through a feedforward mechanism after the first few months of the RM Programme due to team members (including PMs), dreading the end of week rush to complete the progress reports, and once the slippages in the HR Project began to take hold, the weekly reporting activities were treated with contempt.The reporting templates at the individual team member level required progress against the activities that they were assigned to, the summarization of known risks and new issues, and the reporting of potential changes to scope.The organizational reporting also required the updating of detailed MS Projects plans (i.e.project schedules), and the transcription of these into a rigid MS Word template for each activity that the organization was responsible for.The administrative burden was compounded when VenHRPM or PSP2HRPM wanted to make minor changes to their project schedule or project scope, but were stopped from doing this by CustHRPM and Customer PMO because this would impact their ability to monitor overall progress using their internal SOPs; but that when CustHRPM wanted to make large changes to the scope or project schedule, these were tried to be forced through without initiating the formal Change Management process, thus trying to force VenHRPM or PSP2HRPM to perform the changes for zero cost.
Another main reason for process conflict was due to the frequent change in team members on the Vendor side, due to high demand for their functional resources who were subject matter experts on HR business processes in the UK, thus being extracted from the RM Programme to fix problems at other client projects.In addition, the HR Project represented a long project with respect to timescales, which led to a number of Vendor and PSP2 team members wanting to move off the RM Programme and onto another project at other Customers after circa 6-9 months.Focus groups 3 and 4 suggested that this was predominantly due to boredom through their team members feeling that they were no longer learning from the HR Project and becoming de-skilled, or due to personal/family issues arising because the Customer was too far away from their home, which required them leaving their home on late Sunday evening or early Monday morning and not returning until late Friday afternoon/evening; whereas other customer projects that the Vendor or PSP2 were involved in, were much closer to their homes.Finally, it was evident that there was very high turnover in Vendor offshore resources, which was due to the resources leaving the organization after they had gained enough experience and expertise to emigrate from India and secure employment with organizations in the UK or USA.
Finally, the third main reason for process conflict was due to the software development lifecycle that the Vendor used on the RM Programme.The Vendor utilized a hybrid software development lifecycle that leveraged the upfront requirements gathering, analysis, and documentation activities from the Waterfall approach; along with the user engagement, familiarization and informal testing of the HR module configuration and custom extensions, from an Agile approach.The Vendor termed these familiarization and informal testing events Conference Room Pilots (CRPs), with three formal CRPs scheduled throughout the Development Phase of the HR Project.The logic behind this hybrid approach was that the core business processes within the HR module could be fully analyzed and specified during the Design Phase of the HR Project and configured as fully as possible for initial familiarization and informal testing during CRP1.The intent for CRP1 was that as much of the configuration as possible could be confirmed and signed-off as appropriate to the Custumer, with a number of Technical Issues then being raised around further configuration changes or for the development of custom extensions, which would provide functionality that is not incorporated into the standard COTS application.The configuration changes would then be performed and following any associated contractual changes, the custom extensions developed and incorporated into CRP2, which provides the Customer with another opportunity to informally test the configuration of the HR module and to also familiarize themselves with the newly developed custom extensions and informally test.Finally, this incremental and iterative Development Phase would culminate with CRP3, which was intended to allow a full end-to-end informal test of the HR module.Unfortunately, the Customer HR Team did not fully understand what they really needed from the HR module in order to run their back-office processes on the new Enterprise System.As such, they were unable to fully engage with the Design Phase and were overly subservient to the Vendor and PSP2 resources when developing the Functional Requirements documentation for the HR Business Processes.This resulted in considerable process conflict during the Development Phase because the three CRPs were essentially perceived by the Customer HR team as demonstrations of what the Enterprise System functionality was with respect to HR. Positive feedback (with respect to process conflict) ensued between CRP1 to CRP2 and CRP2 to CRP3, which increased the level of process conflict within the HR Project at each CRP.This required the doubling of CRP events, with the first three acting as familiarization events, and the latter three then acting as the proposed CRPs for iterative sign-off of business process configuration and incremental development of custom extensions.In a similar way to the process conflict described previously, this instance of process conflict culminated in a significant delay to the overall HR Project (and indeed the wider RM Programme) and further increased the cost through the Change Management process.

3) Project Management Intervention as Second-Order Cybernetic Control
The examples of task and process conflict discussed above, required a considerable amount of time and effort from the Vendor PM to resolve, which disproportionately required enaction of the Change Management process.As defined within the Project Management Institute's Project Management Guide to the Body of Knowledge [17], there are five phases within the typical Project Lifecycle, with four (Initialization, Planning, Implementation, and Closing Phases) consisting heavily of Project Management Processes, and the fifth (Monitoring and Control Phase) acting as the Mechanics of the Cybernetic System.With specific reference to this latter Phase, one of the main objectives of the PM is to monitor and control adherence to the Project Management Triple Constraint, which focuses on a project's agreed Scope, Cost and Time dimensions.Through the implementation of PM processes related to the Monitoring and Control phase of the HR Project, VenHRPM acted as a von Foerster Observer, and was able to monitor the resulting delays in implementing activities.This, along with a detailed analysis of the causes of the delays, indicated the need for additional HR functionality to resolve a number of the task and process conflicts, e.g.inclusion of Contract Management functionality; increase in the number of custom reports; and updating the structure of the project lifecycle to increase the number of CRPs.This increase in scope, resulted in VenHRPM and CustHRPM enacting the Change Management process, where an analysis of the impact of the increased scope was performed with respect to the original cost and time dimensions of the project.The feedback in this process is at the second-order cybernetic level, meaning that the Change Management process could either dampen or amplify conflict, dependent on whether the proposed changes are accepted or rejected, and whether there are cost and time implications of the revised scope.
In addition, the frequent changing of Vendor resources required a number of unforeseen project activities to be implemented within the Vendor Project Team around handover of project work from the outgoing team member to the incoming team member, along with the orientation of the new resources to the HR Project and wider RM Programmme.Although these activities were not incorporated into the original HR Project schedule, they were also not due to a change in contractual terms between the Customer and the Vendor.As such, VenHRPM had to ensure the handover and orientation activities were performed in order to maintain the quality of the work performed and to keep the momentum on the HR Project, but was unable to enact the Change Management process (due to the fixed-price nature of the contract), so had to absorb these additional costs from their contractual budget, which eroded their profit margin for the project.We propose that these project management interventions performed by VenHRPM on the HR Project can be viewed as second-order cybernetic control (see Fig. 7), and that they do not complete until the project is closed.

C. THIRD-ORDER CYBERNETIC SYSTEM
As discussed in Section IIB.3, the viability and cohesion of an organization depends upon the processes and procedures being able to appropriately function in a recursive manner across all levels of the organization.With respect to the RM Programme, this effectively means that the overall implementation needs good working relationships and harmony between resources at all levels, in order to ensure: harmony between individuals within a team, thus mitigating the risk of intrateam conflict; harmony between teams, thus mitigating interteam conflict; and harmony between organizations, thus mitigating conflict between the Customer, Vendor and PSPs.Within the HR Project, we found that relationship conflict was the leading cause of disharmony within, and between, the three knots/cliques (i.e.Customer, Vendor and PSP2 teams) of the HR Project social network.Furthermore, we found that the PMs were the resources who were most likely to observe conflict development within the HR Project, and also to devise and implement conflict resolution strategies in order to dampen conflict, thus controlling the system dynamics through means of negative feedback.

1) Relationship Conflict as Third-Order Cybernetic System
Focus groups 2-4 identified a significant number of instances of relationship conflict within the HR Project.Although a number of these were due to differences in personal characteristics, in particular through educational and professional differences between the Customer and Vendor/PSP2 team members, the majority were due to misalignment between the Customer organization's business objectives through implementing the RM Programme and that of the personal objectives of individual Customer team members in the HR Project.As discussed in Section V.A above, the overall aim of the RM Programme was to facilitate more efficient business processes across the Customer organization, with particular emphasis on generating cost savings to back-office functions.It became apparent through focus groups 1, 3 and 4, that the Senior Leadership Team of the Customer expected the HR Project to provide a substantial portion of these cost savings, in particular through the automation of a significant number of business processes, which would ultimately lead to a reduction in administrative staff numbers over time.Focus groups 2 and 4, along with documentary analysis indicated that a number of Customer HR Project team resources came to this realization part-way through their involvement on the project.
Within the HR Project, the main source of relationship conflict was between CustHRPM and the various Vendor PMs.Focus groups 2 and 4 indicated that CustHRPM became aware of the cost saving objectives for the RM Programme, approximately 6 months into the HR Project implementation.At that point, she began to fully appreciate the consequences of automating business processes within HR, and that not all of the team members within the HR Department could be retrained in order to move on to less administrative roles.With this realization came: frustration at not being able to retain all of her staff; disappointment with the Senior Leadership Team within her organization for not exaplaining this clearly to her during the scoping and contracting phases of the RM Programme, before implementation began; and anger towards the Vendor HR team, and in particular VenHRPM, who she began to view as the enemy, and someone who was actively facilitating the organizational cost savings, thus reduction in staff personnel within the HR Department.From a cybernetics of conflict perspective, CustHRPM initially developed task conflict through second-order cybernetics, because she observed the progress of HR Project implementation, whilst also enhancing her understanding of the wider organizational objectives of the RM Programme and realization of the consequences of successful implementation.Subsequently, this increased understanding led to feelings of frustration and disappointment with her Senior Leadership Team, and through positive feedback, caused amplification of emotions.This culminated in anger towards VenHRPM, which resulted in relationship conflict between these two observers of the HR Project implementation -representing a third-order cybernetic system, as previously depicted in Fig. 6.Our analysis indicates that this relationship conflict between CustHRPM and VenHRPM was not specific to the individual Vendor resource, but actually targeted towards the role, because the aggression and anger emanating from CustHRPM resulted in her working her way through seven Vendor PMs, five of which had left within the first 18 months of the HR Project.We believe that the anger and animosity acted as a feedforward mechanism due to the Customer HR PM maintaining relationship conflict against the role of Vendor HR PM, so that with each new Vendor PM, the relationship conflict escalated, requiring the new Vendor PM to immediately enter the HR Project in conflict resolution mode.
Another pertinent example of relationship conflict, developed between VenHRPM and the Vendor Technical PM.Like many large technology organizations, the Vendor took on a large number of recent University graduates each year onto their Graduate Training Scheme.These graduate recruits were highly educated, technically competent (having progressed through the initial orientation activities and intensive technical training schemes), and had been assimilated into the Vendors organizational culture.However, due to the recruits having between 6-18 months employment, they were still very junior and had limited real-world experience on customer-facing projects.As such, when the Vendor Technical PM decided to assign a large team of recent graduate recruits to develop custom extensions to the Enterprise System on the RM Programme, this caused significant process conflict for VenHRPM due to the urgency for the custom reports and other custom extensions needed as a result of the Change Control Notes following CRPs1-3.Although the quality of the custom reports and extensions was very high, they took the Vendor Technical team far more time than was provisioned in the revised contract, which began to compound the delays in the HR Project, and further amplified the relationship conflict between VenHRPM and CustHRPM.This ultimately led to a feedforward mechanism, whereby the delays in developing the custom reports and extensions, led to delays in implementing the newly expanded set of CRPs within the HR Project, and culminated in relationship conflict developing between VenHRPM and the Vendor Technical PM.

2) Conflict Resolution within the HR Project
As discussed in Section IIC.5, there are five main conflict resolution styles that individual project team members may adopt.Analysis of focus groups 2-4, alongside documentary analysis, indicated that team members within the HR Project utilized a number of these styles when trying to resolve their own particular conflicts.Examples of conflict resolution styles utilized for some of the major conflicts experienced within the HR Project are discussed below, and represent the five resolution styles from Thomas and Kilmann [65].Fig. 8 defines the conflict resolution process utilized by VenHRPM, which we believe was also utilized by the other Vendor PMs on the wider RM Programme.
The first two examples relate to the conflict resolution style of avoidance.The Vendor HR Reports Lead (VenHR5) began to experience considerable personal process conflict approximately 3 months into his assignment on the HR Project, due to having to work away from his family at the Customer offices, which was a 5hr drive away from home.At approximately 6 months into his assignment, this became amplified and transitioned into relationship conflict with his family due to the extended periods away from home (4 nights away each week).After 7 months on the project he made a request to his Line Manager at Vendor HQ to assign him to another customer closer to home, because he was missing his wife and children, and his weekly absences were causing tensions at home.Another example of avoidance related to CustHRPM avoiding escalating the informal testing issues that came out of CRPs1-3 to the Programme Directorate.We conjecture that this is because she wanted the HR Project to fail, so did not want to increase the scope of the HR Project to incorporate the missing functionality that was identified during the CRPs.By her continuously postponing the raising of the issues coming out of CRPs1-3, VenHRPM had no other option but to formally raise the issues to the Programme Directorate himself, thus by-passing the formal hierarchical reporting structure, and compounding the relationship conflict that was already evident between him and CustHRPM.
The third and fourth examples relate to the conflict resolution style of accommodation, and focus on the immediate period after the scope increase was raised to the Programme Directorate.PSP2HRPM actively tried to arbitrate during the task conflict that initially arose between CustHRPM and VenHRPM in order to downplay differences in perspectives of the scope and how that translated to detailed requirements on the HR Project.This was due to CustHRPM trying to extract maximum additional work for free from the Vendor, and VenHRPM trying to maximize extra revenue from the Customer and to hold the line with respect to scope versus out-of-scope work.Another example, is that the Customer Recruitment Lead (CustHR1) and Employee Details Lead (CustHR4) both developed very close working relationships with their Vendor counterparts (VenHR1 and VenHR3 respectively), and through CRPs1-3, began to understand that key functionality was not within the scope of the original contract, so needed to be incorporated into scope through the Change Management process.Unfortunately, they did not want to enter into conflict with their PM (CustHRPM), who was also their Line Manager outside of the HR Project, so adopted a deferential approach in order to accommodate the views of CustHRPM, which meant that the wider conflict between CustHRPM and VenHRPM was able to intensify without this negative feedback control to dampen down the conflict.
The next two examples relate to the conflict resolution style of competition and compromise.Once the conflict affecting CustHRPM had evolved from task conflict (focused on the RM Programme objectives) to relationship conflict, the associated anger towards the Vendor HR PM role, resulted in CustHRPM adopting a competitive conflict resolution style.Her primary goal appears to have been to try and steer the HR Project towards overall failure, thus minimizing the likelihood of organizational efficiencies and mitigating the risk of her colleagues being made redundant.Her competitive conflict resolution style was aimed at whomever was the current Vendor HR PM at the time, and resulted in five different Vendor PMs being removed from the project within the first 18 months, one of which requested to leave the project due to the high-level of aggression aimed at him personally, and the other four were requested to leave by the Programme Directorate.These requests from the Programme Directorate were made after CustHRPM had reported upwards through the hierachy in the Customer organization, and focused on the deficiencies that she perceived in the respective Vendor PM at the time.The situation was finally brought to a stable equilibrium when the Vendor assigned a relatively young FIGURE 8: The Conflict Resolution Process utilized by the Vendor HR PM on the HR Project (after [11]).
PM onto the HR Project who had a unique set of personal and professional characteristics, including: high-level of education, following multiple science and technology degrees; highly ambitious and hungry for success, in order to gain quick promotions within the Vendor organization; gregarious and unassuming in normal situations, which allowed him to build rapport, and quickly gain the respect and trust of others; and a keen sportsman, including team and solo sports, which meant that he was used to multiple forms of competition, and accustomed to various forms of aggression and intimidating behaviours.The new Vendor HR PM, representing the sixth PM that the Vendor fielded, quickly developed the trust of both the Vendor and Customer teams, and established a set of ground rules with respect to what behaviours were, and were not, acceptable.He also performed a rapid, yet detailed, analysis of the limitations of the initial contract, before developing two major Change Control Notes that would bring into scope the newly identified functionality from CRPs1-3.Furthermore, he also developed a new HR Project Schedule that focused on the introduction of a significant number of custom extensions and reports that would be developed by the Vendor Technical Project team and tested by the HR Project team within CRPs4-6.This Vendor PM was also requested by his superiors to act in a very nurturing manner towards Customer HR team members and to foster high levels of trust and collegiality between his resources and the Customer resources.The one exception was CustHRPM, whom he was requested to convey an equally competitive persona towards, in order to show her that she could not simply work her way through Vendor PMs as if they were throw-away commodities, but instead had to respect the position of the Vendor HR PM, and learn to collaborate with them, even if she did not like them personally.Through focus group 4, it became apparent that the sixth Vendor HR PM performed his role diligently, although even he became impacted by the toxic nature of the HR Project, when it transpired that once CustHRPM realized that she was unable to steer the project towards failure, she used her power and authority over her organizational resources, to effectively ostracize VenHRPM.This resulted in him having to endure the indignity of no customer resources (i.e.CustHR1-CustHR15) being willing to speak to him for a period of 2 months.At that point he took a vacation to decompress, and during this time CustHRPM once again used the Programme Directorate to remove him from the project.However, documentary analysis indicates that after six Vendor PMs were removed from the HR Project, the Programme Directorate became acutely aware of the Machiavellian behaviours of their HR PM, and slowly began to remove her autonomy and power.This was achieved by the Programme Directorate utilizing a Compromise Conflict Resolution style, by taking a more active and detailed interest in the day-to-day implementation of the project and ensuring that the seventh Vendor HR PM was given equal access to them.This meant that he could report any issues with working behaviours or project dynamics directly to the Programme Directorate, so that a balanced view could be formed of HR Project progress.
The final example relates to the conflict resolution style of collaboration.Following the Vendor Programme Manager becoming aware of the conflict between the Vendor Technical PM and VenHRPM due to the use of Graduate Recruits for custom development, he instigated a couple of meetings that allowed the two Vendor PMs to engage in open and frank discussions around each others needs.He also arbitrated in order to reduce (and ultimately remove) the relationship conflict, which allowed focus to turn to the process conflict arising from the use of junior resources to develop timecritical custom reports and extensions for CRPs4-6 in the HR Project.This culminated in the Vendor Technical PM agreeing to assign the custom extensions to more experienced (and senior) developers, in order to ensure they could be developed quickly and informally tested by the Customer in CRP4, whilst the custom reports would be developed by junior resources, and tested within CRPs5-6.
Finally, Fig. 9 presents a Rich Picture that defines the observable phenomena seen within the HR Project and the hypothesized development of conflict through the interactions between team members, and also between different project teams.In addition, the use of conflict resolution styles is also hypothesized to mitigate (i.e. through avoidance or accommodation styles) or dampen (i.e. through collaboration or compromise) conflict.

VI. IMPLICATIONS FOR RESEARCH
Our conceptual framework of the Cybernetics of Conflict within large technology and software engineering programmes, such the RM Programme, has provided an increased understanding of how conflict develops within large multi-partner programme environments.The objective of the cybernetic approach is to understand how complex systems, such as humans, social systems, and software-intensive systems, interact and communicate in order to regulate the system.It's early contributions were to associate control mechanisms that were found in biological systems to those engineered in manufactured systems, in order to ensure the outputs of the manufactured system continue to meet the system's objectives.Cybernetics has an inter-scientific and transciplinary character, meaning that it takes inspiration and leverages key approaches and techniques from a number of different academic disciplines.As such, it is recognized as rising above the academic disciplinary silos and has a rep-utation for being able to develop meta-theory that promotes discussion between researchers from different disciplines.
Our focus in developing this conceptual framework was to instigate a discussion about the cybernetics of conflict within large multi-partner technology and software engineering implementations.With respect to the programme and project management of implementing these softwareintensive systems, conflict development can be considered a crisis, with cybernetics acknowledging the crisis as a crisis of regulation [85].We believe that the multidisciplinary approach of cybernetics, allows us to develop hypotheses for how conflict develops in these multi-partner software implementations, and more importantly, how the conflict can be controlled/regulated (Fig. 8-9), which can then be translated into project management interventions for regaining control of the project.We therefore believe that an increased understanding of conflict development can be derived by utilizing the cybernetics perspective in future research into large technology and software engineering programmes.The results and findings from these additional studies can then be used to augment our conceptual framework and develop new hypotheses on the causes of conflict development from a firstorder, second-order and third-order cybernetics perspective.
Our findings indicate that project team members act as von Foerster observers within a second-order cybernetic system, whereby they observe the relative progress of the project along with the behaviours of other team members, in order to develop their personal mental model of the project.If the mental model does not align with the team member's personal values, motivations or objectives, then misalignment ensues between the goals/objectives of the first-order cybernetic system of the project (the Observed System) and the second-order cybernetic system of the individual team member (the Observing System).We believe that such misalignment of goals can lead to conflict development in project teams, which when applied to multi-partner technology and software engineering programmes, can lead to devastating effects on the productivity of team members within individual projects, and a decrease in the likelihood of success of the overall programme.This highlights the need for research into the cybernetics of project success and failure, due to the misalignment of goals/objectives between the second-order cybernetic Observing System versus the first-order cybernetic Observed System.Fig. 6 defined the relationships between the Observed System of first-order cybernetics, the Observing System of second-order cybernetics, along with the relationship between two (or more) Observing Systems of third-order cybernetics.Our findings indicate that once task or process conflict develops at the second-order cybernetic level, positive feedback loops may be enacted that affect the interpersonal relationships and professional interactions between the team members at a third-order cybernetic level.This identifies a need for research into conflict development, which is focused on the relationships between first-, second-, and third-order cybernetics of conflict development.As such, we believe that future research should focus on which programme and project management processes have a propensity to facilitate task and process conflict development through secondorder cybernetic feedback and feedforward mechanisms, along with third-order cybernetic mechanisms that may be associated with relationship conflict between resources in the programme-wide social network.In addition, we believe research is also required into: the cybernetic mechanisms associated with the amplification of conflict intensity between team members; the transition of task or process conflict into relationship conflict; and the propagation of conflict across the social network of programme-wide resources.
Furthermore, we believe that research is required around conflict resolution styles, and how these relate to negative feedback and buffering.Our findings indicate that PMs were the most likely resource to observe conflict development within the HR Project, and also the most likely to devise and implement conflict resolution strategies in order to dampen conflict via negative feedback and buffering mechanisms at both the second-order and third-order cybernetic levels.This identifies a need for research into the second-order and thirdorder cybernetics of conflict resolution.We believe that it is timely to build upon the work of Thomas and Kilmann [65], and suggest that embedding a cybernetics perspective into their five conflict resolution styles (Avoidance, Accommodation, Competition, Compromise, and Collaboration) would be of vital importance to professional Project Managers in industry when developing interventions to regain control of projects once conflict has developed.
Researchers who use a cybernetics perspective to investigate complex social systems, have a tendency to manipulate metaphors and to use analogies from biological systems in order to further their understanding of their particular social system of interest.For this to work, the metaphors and analogies are often translated into diagrammatic and/or computational models that reflect the content (e.g.individuals, organizations, processes, outputs, etc) of the social system and its environment.The manipulation of these diagrammatic and conceptual models allow us to study these complex social systems from an abstract perspective, however we believe that one of the major strengths of the cybernetics approach is that it lends itself to being modelled using computational modelling and simulation techniques, such as agent-based modelling and simulation.A key distinction of cybernetic models over traditional models, is the focus on dynamic (as opposed to static) relationships between the system's components/constituent parts.With this in mind, our previous work [86] provided an agent-based model of intrateam and interteam relationships that gave rise to conflict within an Enterprise System programme.
Finally, we believe that a multi-method approach, that uses qualitative, quantitative and computational techniques, will be a powerful means for future research to deal with the complexity of conflict development within large technology and software engineering programmes.Such an approach would allow us to take into consideration the emergent behaviours of the complex social system along with the immergent second-order cybernetic properties, thus facilitating the computational simulation of different project scenarios or project management interventions.Furthermore, once realistic computational models have been developed, they lend themselves to simulation-based experimentation of the dynamics inherent to these artificial social systems, which falls under the scope of the field of Artificial Life.Finally, we believe that agent-based models of conflict development within social systems are compatible with second-order cybernetics, and provide a logical next step for investigating the recursive mechanisms within cybernetic systems.

VII. IMPLICATIONS FOR PRACTICE
It has previously been argued that conflict is ubiquitous within large multi-partner technology and software engineering implementations [4].From a programme and project management perspective, multi-partner project teams provide a perfect environment for conflict development due to the different organizational objectives of the Customer and thirdparties, alongside the different personal and professional characteristics of team members.As such, a combination of task, process, relationship, intrateam and interteam conflict is inevitable, meaning that the key to project success is how the PM(s) control the emergent behaviours following team members interacting with one another and how they react to programme-and project-level processes and procedures.As discussed, cybernetic control relies upon regulatory mechanisms, such as feedback, feedforward, and buffering, to maintain system dynamics within a specific range [26], which is akin to homeostasis in biological systems.Within a programme and project management environment, cybernetic control can be deemed as the capability to identify deviations from the agreed project schedule, or the scope, cost and time dimensions that define the project's triple constraint [11].As such, cybernetic control of a programme or project requires four key factors: 1) an accurate project schedule that has been approved by the Customer; 2) the ability to measure work performed and to accurately estimate work remaining; 3) the ability to calculate deviations from the baseline scope, cost and time dimensions; and 4) the ability to take corrective action(s) to minimize, and preferably eradicate, those deviations that are considered to be unacceptable.
Our findings indicate that conflict can develop as a secondorder cybernetic system due to the processes and procedures that need to be followed within a project, and also as a thirdorder system due to the intrateam and interteam relationships between team members.Within the HR Project, we believe that the conflict arising from a misalignment of CustHRPM goals (second-order cybernetics of project management) versus project-level goals (first-order cybernetics) gave rise to the most intense conflict, which was able to transition from the initial task conflict due to the misalignment of goals, into relationship conflict between CustHRPM and VenHRPM, and ultimately propagate to become relationship conflict between the Customer HR Team and the VenHRPM.This identifies the need for a thorough organizational change management exercise (led by the Customer and aimed at their in-house resources) before the technology and software engineering programme commences.This organizational change management exercise could be delivered through a standalone project, but we believe that the essential objective of this exercise is to be as open and honest with the in-house resources as possible, and not to bury bad news in order to coerce resources into working on the subequent software implementation.We also believe that after this initial change management exercise has been performed, the key messages should be repeated throughout the subsequent technology programme to ensure resource buy-in continues.
Additionally, the findings from this study suggest that the PM needs to be open and honest with team members, in particular, about project objectives, project status, risks and issues.With particular reference to a project as a cybernetic system, the PM needs to foster a collegial culture to ensure positive feedback of good-working conditions (at the second-order cybernetic level), along with eradicating rumours and negative informal water cooler discussions between resources, in order to facilitate positive working relationships (at the third-order cybernetic level).However, when negative feelings do emerge within the team, the PM not only needs to be cognizant to this, but importantly also needs to be sympathetic to their resources who may be experiencing conflict due to a misalignment of their own personal objectives versus the organizational objectives that are being delivered through the project or wider-programme.
Furthermore, this study provides evidence that a cybernetics perspective for conflict, should be taken when performing the Risk Management process, in particular when performing Risk Identification at the start of a project [11].The first, of two key examples from the HR Project, relate to the need to be cognizant of conflict amplification, transition and propagation, so that multiple mitigation and contingency plans can be developed, which aim to manage the risk(s) under normal project environments, along with a project that is experiencing cybernetic mechanisms related to conflict.The second example relates to the VenHR5 experiencing process conflict due to the need to stay away from home for 4-5 nights each week, which subsequently transitioned into relationship conflict with his family.We believe that the PM of a PSP or Vendor needs to pay particular attention to this risk during the selecting and assignment of resources to their team, which in a matrix-structured organization, may mean that the PM needs to discuss not only a resource's functional/technical expertise with the relevant resource's Line Manager, but also whether there are any pressures in the resource's personal life that may become amplified from assignment to the project.
Finally, we believe that the concepts of feedback, feedforward and buffering, are of particular importance for PMs when trying to develop interventions that can dampen or eradicate conflict within their team.These interventions can either be designed and implemented through normal project management practices (e.g.Stakeholder Manage-ment, Scope/Cost/Time Management, Change Management, etc) or through adopting one of the conflict resolution styles [65].Importantly, PMs need to be cognizant that project management processes are not linear, but in fact have circular feedback loops due to second-order cybernetics, meaning that any intervention that they make to regain control of project dynamics (e.g.negative feedback or buffering with respect to conflict development), needs to be carefully monitored in case there are any unforeseen consequences due to positive feedback or feedforward mechanisms.

VIII. CONCLUSION
Large technology and software engineering programmes, such as the RM Programme, are increasingly implemented through a mixture of customer and specialist third-party resources.These multi-partner working environments can be thought of as a complex social system, that managers, in this case programme and project managers, need to control.This organizational complexity is predominantly due to issues relating to inter-organization process control and communication, which oftentimes lead to various forms of conflict within the programme or one of its constituent projects.This can be due to competing objectives and priorities of the various organizations, along with incompatibilities of team members within the work-based social network of the implementation programme.If not brought under control, conflict can lead to complex emergent behaviours and dynamics within the wider social network, which can severely impact the likelihood of successful programme implementation of these softwareintensive systems.
Cybernetics is inherently interdisciplinary, with an overall aim to elucidate unifying theories on how complex systems function and can be controlled.Three orders of cybernetics have been defined, with first-order cybernetics relating to the observed system; second-order cybernetics relatiing to observing the system; and third-order cybernetics, being more reflexive in nature, provides a way of analyzing the relationships that exist between observers in a system and the effects of these relationships on the system itself.With particular emphasis to a multi-partner environment, such as the HR Project, we discovered that cybernetic mechanisms may exacerbate conflict development through amplification, transition, and propagation.The conceptual framework presented in this study, illustrates how a cybernetics approach to conflict within Enterprise System implementations can be generalized as a problem of regulation.
Our findings indicate that project team members act as von Foerster observers within a second-order cybernetic system, whereby they observe the relative progress of the project along with the behaviours of other team members, in order to develop their personal mental model of the project.If the mental model does not align with the team member's personal values, motivations or objectives, then misalignment ensues between the goals/objectives of the first-order cybernetic system of the project (the Observed System) and the second-order cybernetic system of the individual team member (the Observing System).In addition, once task or process conflict develops at the second-order cybernetic level, positive feedback loops may be enacted that affect the interpersonal relationships and professional interactions between the team members at a third-order cybernetic level.Indeed, within the HR Project, we found that relationship conflict is the worst of the three types of conflict and is the hardest to control or eradicate.Furthermore, the HR Project has shown that misalignment of goals may not only lead to conflict development in the respective project team, but when applied to a multi-partner programme environment, it may also lead to devastating effects on the productivity of the team members, and if not regulated, a decrease in the likelihood of success of the overall programme.
It is our aspiration that the conceptualization of the cybernetics of conflict in this study, may promote the development of interventions to regulate or control conflict by programme and project managers on multi-partner technology or software engineering programmes.We sincerely hope that the conceptual framework will revive interest in the cybernetics of complex social systems, and that the engineering project management community will harness the cybernetic perspective to control and regulate their projects that are afflicted by conflict.Furthermore, we propose that along with PMs being trained in programme/project management methodologies that are accredited by a relevant professional body, we advocate that they also become familiar with Conflict Resolution Styles and ways of introducing Cybernetic Control Mechanisms into their project management interventions.In addition, we propose that professional bodies, such as the Institute of Electrical and Electronics Engineers, Project Management Institute, or Association for Project Management, should make use of the Cybernetics perspective when they refresh/update their Project Management Standards for Technology and Software Engineering (e.g.PMI-IEEE Software Entension to the PMBoK Guide [12]), in order to ensure the cybernetics perspective can take centre stage when applied to monitoring, control, and regulation of complex projects.

FIGURE 1 :
FIGURE 1: Iterative approach to data analysis.Following initial thematic coding analysis, the qualitative data was further analyzed incrementally, with respect to literature around 1) Enterprise System Programmes and Conflict in Project Teams; 2) Social Networks in Enterprise System Programmes and Conflict Propagation; 3) Cybernetics of Project Management.

FIGURE 2 :
FIGURE 2: The RM Programme Organizational Structure.The overall Enterprise System programme was composed of project teams that implement a functional model (e.g.Payroll, HR) within the Enterprise System software, or a technical stream of the wider implmentation (e.g.Database, Middleware, Web Services).Each project team is made up of team members from the Customer and Vendor, and potentially one of the three Professional Service Providers.

FIGURE 4 :
FIGURE 4: Relationships between the HR Project and wider RM Programme goals versus environmental factors/project orientators.

FIGURE 6 :
FIGURE 6: Relationships between First-Order, Second-Order and Third-Order Cybernetics in the HR Project.

FIGURE 7 :
FIGURE 7: Second-Order Cybernetic Control by the HR Project Manager.

FIGURE 9 :
FIGURE 9: Rich picture of the HR Project Environment: Observable phenomena seen within the HR Project and the hypothesized development of conflict through the interactions between team members, and also between different project teams.The use of Conflict Resolution Styles is also hypothesized to mitigate or dampen conflict (after[4]).

TABLE 1 :
Composition of the focus groups

TABLE 2 :
Composition of the HR Project Team