Loose , fragmented project arrangements – Some implications for practitioners

© 2018 by the author(s). This is an Open Access article distributed under the terms of the Creative Commons Attribution 4.0 International (CC BY 4.0) License (https:// creativecommons.org/licenses/ by/4.0/), allowing third parties to copy and redistribute the material in any medium or format and to remix, transform, and build upon the material for any purpose, even commercially, provided the original work is properly cited and states its license.


Introduction
The information age poses challenges for the contemporary project structure.Conventional projects are designed according to a logic model that recognizes a specialization of task and function (e.g., design, develop, implement) with the necessary levels of authority and supervision being vested in the project manager position to realize the project goal.However, more and more such a logic model does not fully reflect the project reality as messy, ambiguous and fragmented (Cicmil 2006).How does this suggested messiness affect the project structure and, as practitioners, are there implications concerning how we manage projects?These are themes that are explored in this paper.The paper is based on a pilot case study that was completed in 2012 as part of a DBA programme carried out in DCU Business School, Dublin City University, Ireland.
Project management (PM) research has highlighted the widespread use of project-based forms of organizing, suggesting the rapidly changing environments that organizations must contend with is a source of much of this popularity (Soderlund 2008).Mainstream literature influences our perception of what a project should be.TraditionallyPM researchers have adopted a common interpretation of the project describing it as temporary organization structure existing within a larger host organization structure (Lundin and Soderholm 1995;Shenhar 2001;Turner and Muller 2003).The International Project Management Association, in its latest version of the Individual Competency Baseline (2015), describe it as a temporary structure that takes place within the established systems, structures and processes of a supporting or host organization (IPMA ICBv4 2015: 45).While such definitions are useful in setting an expectation of what a project should be, they do not always accurately reflect the reality of many projects that take place.This paper aims to contribute to our understanding of the project by considering an alternative type of project taken from the world of practice but which appears to be overlooked within much of the existing PM research and previously referred to as Loosely-Coupled Transient (Cullen and Leavy 2017).The paper draws from two project experiences and discusses key implications for PM practitioners concerning the management of these projects.The projects are presented using management-related categories in a compare and contrast manner.Drawing on theoretical insight,the key implications for PM practitioners and researchers are discussed.Previous PM research observes that PM literature could be further developed by exploring the potential usefulness of theories that lie outside of the PM domain (Soderlund 2004).Reflecting on this observation, the potential usefulness of Pfeffer and Salincik's (1978) Resource Dependency Theory (RDT) is discussed.RDT is a theory of macro-organizational behavior and does not acknowledge the project organization as such.However, certain themes from this theory would appear to resonate with the type of project presented in this paper and would, therefore, merit a closer examination.These themes include interpreting the project organization as a collaborative framework as well as the limitations of the traditional command and control model of management.
While both projects presented in this paper focus on a particular sector (information technology), the project experiences demonstrate that using a selective and informed approach to utilising concepts from theories not normally associated with PM(such as RDT) can provide potentially useful insights in a knowledge domain often described as conceptually and theoretically limited (Shenhar and Dvir 2007).Consequently, this study will have relevance for any PM practitioner that implements projects through a process of collaboration with disparate, autonomous entities.

Research Overview
For clarity, presentation of the findings uses PM-related categories drawn from general management practice and devised by the researcher as follows: Project Overview; Management of the Project; Goal Setting; and Project Relationships on the Project.The study is case-based in its approach and features typical projects in which the researcher was actively involved at the time.These are referred to as project A -an East European project, and project B -an African project.Project A was an Information Technology (IT) implementation project.The project sought to achieve the development of a portal (described as a functionally rich website) as well as many web-based services to be integrated into the portal.The project took place in the year 2011, and the role of the author in this project was project manager.Project B was an Information Technology (IT) planning and specification project.The project sought to achieve the planning, design, and specification of a data warehouse solution (i.e., the creation of a centralized data repository for management reporting purposes).The project took place in the year 2010, and the role of the author in this project was as a project team member.
The research design was longitudinal.In the case of project A, research observation took place over the course of eight elapsed months.In the case of project B, research observation took place over the course of six elapsed months.Management-related research has previously been criticised as being too prescriptive in its approach, whereas what can often be more effective is exploratory, inductive approaches to research that are simple and descriptive (Mintzberg 1979).The research on which this paper is based was exploratory in nature and inductive in its approach.Provide a specification for a data warehouse.

Management & Organisation
Team size of five individuals.Sub-contracted project manager.
Project manager had no experience of working for the main contractor.Project manager had no experience of working with team members.
All but one position on the team was sub-contracted out.
Team size of four individuals.Sub-contracted project manager.
Project manager had no experience of working for the main contractor.Project manager had no experience of working with team members.All positions on the team were sub-contracted out.

Expected Outcome
A technical solution.
Knowledge transfer from project team to client staff.

A solution specification.
A solution implementation strategy.

Contextual Specifics
Took place onsite, at client premises.
Project team had no previous experience of client.
Three team members were foreign to the environment.Some team members had previous experience of working together.
Took place onsite, at client premises.
Project team had no previous experience of environment or client.
All project members were foreign to the environment.Team members had no previous experience of working together.

Project A
The purpose of the project was to provide a website portal and many to-be-defined web services to be integrated into the portal.These were to include government-to-government web services, government to business web services and government to citizen web services.The project was awarded to a main contracting firm.The contracting firm had previously implemented similar IT related projects.It employed over one hundred full-time employees and also employed freelance consultants to fulfill specialist roles that arise on some of its projects from time to time.As part of the delivery of this particular project, the firm subcontracted out all but one of the roles on the project.Within this line of business, it is considered a standard operating practice for the firm to make use of freelance resources to fulfill specialist roles on projects.The client was a government agency.The client was primarily responsible for data administration and database management and record management at a national level.As part of carrying out its regular activities, it was necessary for the client to design, develop and implement software solutions, either through internal resources or the involvement of third-party firms.

Project B
The purpose of the project was to deliver the planning, design, and specification of a data warehouse solution for the country's Central Bank.As an expected project outcome, it was anticipated that the client itself would then be in a position to start a build-out of the data warehouse solution.The project was awarded to a main contracting consultancy firm.The firm had previously implemented many IT related projects within the region.Its businessoperating model placed significant emphasis on the use of freelance consultants to fulfill specialist roles on all of its projects.The firm sub-contracted out all of the roles on this project to freelance experts.The project's client was a central banking authority.Its primary objective was formulating and implementing monetary policy aimed at maintaining price stability and enabling sustainable growth in the national economy.

Project A
One of the four project resources assigned to the project was the designated project manager responsible for resource management and project delivery.The project manager also acted as the main point of contact for the project's stakeholders.The project manager had extensive previous experience of managing freelance resources in the delivery of project results.He had no prior experience of working with the client, the contracting firm or any members of the project team.Also,the project manager had no input into the selection of individuals for roles on the project.
The Microsoft Project© planning tool was used to develop a project implementation schedule, and standard office tools were used for reporting purposes.A draft project statement and project plan were prepared that took into consideration the project's aims and objective.Once approved by the client,the project statement and plan set out the direction for the project and detailed what and how specific project outcomes would be achieved.
Co-ordination of work among project team members was achieved through a combination of the project plan, a monthly status report prepared by the project manager as well as on-site project meetings.In the monthly status report, the project manager outlined the project tasks that had been completed by the team as well as the tasks expected to be completed by the project team the following month.Combined with the team meetings that took place, this was the main arena in which priorities and project delivery goals were established for the project.

Project B
One of the six project resources assigned to the project was the designated project manager responsible for resource management and project delivery.The project manager had no prior experience of working with the client, the contracting firm or any members of the project team.The project manager had no input into the selection of the individual experts who worked on the project.A Microsoft©spreadsheet tool was used to develop a project plan, and schedule and standard Microsoft©tools were used for reporting purposes.A draft project statement and project plan were prepared.Co-ordination of work among project team members relied on a process of revising and updating the project plan.During mid to later  and Practice, Vol. 5, 2018  4 project stages, regular project meetings became the main arena in which priorities and project delivery goals were established for the project.

Project A
During the initial project planning meeting, it became evident that the terms of reference for the project were dated and would need to be revised.Revised requirements were documented and incorporated into the project statement.A detailed plan was prepared by the project manager andreviewed by the client.Despite the level of detail contained in the project plan, it was not used as a progress tracking baseline for the project.Instead, coordination of tasks among project team members was done through a combination of a monthly status report as well as on-site project meetings with the project team members.
Team members would have prior knowledge of the expected dates and project outcome for an up-coming on-site mission.The monthly status report outlined project tasks that were previously completed by the team and the tasks expected to be completed next.The team meeting would normally take no more than twenty minutes and would focus on how specific outcomes were to be achieved.Project team members were assigned activities according to the sub-systems that they were designated to work on and could to some extent work independently of one another.Where this was not possible, team members were distributed to phases of a sub-system on a modular basis.This enabled the project's tight schedule to be maintained.
Specifications of functionality to be delivered were kept to a minimum.This was possible as the experience and knowledge of team members led them to perceive that the portal and web services that were to be produced were intuitive.Intuitive in this instance meant that team members had no difficulty in formulating the expected operation and functions of the website and web services.These functions were then elaborated on in some detail in documentation prepared for the client by the project team.The client staff did not have much to add to the operation and functioning of website and web services until after their initial build, at which stage they became more involved as part of a structured review process.
Team members would demonstrate various aspects of the portal and web services under development.During the project's early stages, and up to the mid-point of the project timescale, interactions between team members were minimal.During the latter stages of the project, particularly the final third period of the project life cycle, communication between members of the project team started to grow in frequency, particularly as they started to rely on the expertise of each other in progressing with specific deliverable and meeting deadlines on the project.Interactions tended to last no more than a matter of minutes and related mostly to specific technical issues experienced on the project.Some interactions took the form of informal peer-to-peer reviews of each team member's work on the project.
The process of realising project outcomes and goal attainment was iterative.The office space allocated to the project team served as a natural environment to discuss solution functionality and issues.All team members were located within the same office and shared one large table.This setup facilitated immediate discussion and feedback on issues related to the project.Particularly during the latter stages of the project, ideas would be discussed to and fro between project team members before any development work took place.

Project B
A detailed plan was prepared at the start of the project and documented using the Microsoft Excel© spreadsheet tool and reviewed by the client.As the project unfolded, the project plan was not used as a mechanism to track the activity and progress for the project.Instead, coordination of tasks among project team members was loosely assigned, and the delivery of project outputs depended on significant individual efforts from some project team members.During the early stages of the project, the relevance of some of the project's deliverables to the overall project outcome was questioned with one appearing to have no real merit, while another key design deliverable was omitted.A project status report and onsite project meetings became the mechanisms by which tasks for the project were planned and tracked.
To assist in the delivery of the assignment, a number of the client's mid-ranking managers were identified to participate in the project.They became known as the project champions and were selected based on their in-depth knowledge of different aspects of the client's operations.In all, over fifty such individuals participated as project champions.A series of workshops were organized involving the project champions with the purpose of working through key requirements of the project's solution (i.e., a data warehouse).Towards the latter stages of the project, workshops lasted for three days and were held in an offsite location to allow the project champions to focus exclusively on this critical project related work.
Due to difficulties encountered through-out project delivery, the process of measuring results against the project plan came to be abandoned.Formal presentations became a mechanism used by the client to demonstrate project progress.The formal presentations gave the client's senior management team an opportunity to input into the direction the project should take and factors that should be prioritized, as well as providing them an opportunity to keep a close eye on the project delivery.
The process of realising project outcomes and goal attainment could neither be described as being iterative nor once-off.The process of preparing a deliverable relied on the knowledge, understanding, and analysis of the individual expert concerned and was prepared independently of other team members.When deliverables were developed, they tended to follow a pattern of gradual adjustment toward the expectations of the client, and it normally took many revisions to a deliverable before it was considered acceptable by the client.

Project A
No face-to-face meetings took place between the main contractor and client either before, during or after the project.The project manager for the project acted as the firm's special representative in this regard.One of the team members failed to show up for the first onsite project mission while another returned home after a matter of daysand failed to show up for subsequent on-site missions.Despite numerous attempts by the project manager and main contractor, neither team member would participate in the project.The client became alarmed at this development so early in the project and requested over-sight of the process to replace the team members.Three possible replacement candidates were sourced by the main contractor.An informal discussion between the client, the project manager, and the main contractor suggested that none of the candidates were suitable.Ignoring this, the main contractor made a formal proposal based on the candidates identified which the client subsequently rejected.
The client requested the team make some corrections to some existing software with which they were experiencing issues.Although the request was outside of the project scope, in an attempt to build goodwill with the client it was agreed that a senior team member with the necessary skill-set would provide ongoing assistance to the client.
Difficulties were experienced in obtaining the necessary programme source code from the client.The project team was expected to enhance this as part of the project goals.Initially, no source code was made available, and no server platform for development was made available.Eventually, a limited amount of source code was provided, along with a server platform for the project.On subsequent project missions, the server dedicated to the project was repeatedly taken offline by the client.Because of on-going problems that were experienced, team members had to establish a limited but functioning technical work environment on using their resources in a limited amount of time.

Project B
No face-to-face meetings took place between the main contractor and client either before, during or after the project.The client understood that all team members proposed by the main contractor would participate in onsite project missions.However, the main contractor disputed this and maintained only a small number of them would be made available for on-site missions.This point became an on-going issue throughout the project for the client who felt that the main contractor did not comply with the terms of the proposal and assign adequate resources to the project that were needed for its successful delivery.
One of the team members failed to show up for the first on-site project mission while the project manager returned home after a matter of days and failed to show up for subsequent on-site missions.The main contractor tried to resolve this situation with both members.Besides, a third member of the project team failed to show up for subsequent on-site missions.The main contractor was unsuccessful in efforts to get the absent team members to commit to the project, and the situation was not helped when the main contractor refused to engage with the client in the process of replacing the team members.
While the project manager was on site, a draftproject statement and plan was circulated to team members.One of the team members was particularly critical of this work and made his views known directly to the main contractor.This annoyed the project manager to the point that a request was made to remove the individual from the project team.The main contractor refused this request.
One team member had difficulty meeting a deliverable deadline and cited problems in trying to get timely feedback from the client as the main source of the problem.Despite been given an extended deadline this also overran, and the team member failed to engage with the main contractor despite several attempts to do so.The client was furious with the content and quality of the deliverable when it was eventually submitted and refused to sign off on it until substantial improvements were made.However, the team member did not attempt to improve it and ignored repeated requests from the main contractor and the client to do so.
A lack of project progress against the plan combined with ongoing personnel issues on the project prompted the client to issue formal correspondence with a threat to cancel the project.The client believed that the main contractor was in violation of the contract as: (i) Experts assigned to the project were not being deployed on the project; (ii) Deliverables when produced, overran their deadlines and in some cases had significant quality issues, and; (iii) Without being informed of the development, the project manager had disappeared from Loose, fragmented project arrangements -Some implications for practitioners Project Management Research and Practice, Vol. 5, 2018 7 PAGE NUMBER NOT FOR CITATION PURPOSES the project.Besides, a member of the client's management team sent a note to project team members, the main contractor and senior managers at the client organization that he believed the project was going to fail.
Toward the end of the project,the client requested that the main contractor meets with them to present the project deliverables to the board of directors and officially close-out the project.The initial request prompted no response, so the request was repeated.The main contractor declined the request suggesting that the project had overrun its budget, that there were insufficient funds available to allow them to travel and that because of this no one representing the main contractor or the project team would be made available.The response disappointed the client who felt it was a missed opportunity to make some amends for the poor project delivery by the main contractor and reinforced a sense of dissatisfaction with the overall project delivery.

Discussion
This paper intended to explore a particular type of project that was common in practice although overlooked in mainstream PM research.An empirical examination of two project examples offers some limited, direct insight into these types of projects and unearths some potentially interesting themes that seem to deserve closer examination.
A prominent theme to emerge is the type of project highlighted in each of the cases, which could be considered to be messy and fragmented as well as quite distinct from those that tend to predominate in the conventional PM literature.Much of the current PM literature (Lundin and Soderholm 1995;Turner and Muller 2003;IPMA ICBv4 2015) view the project as a temporary endeavor, embedded within a larger parent organization and characterized by an identifiable objective, timescale, and budget.Some researchers extend this interpretation by emphasizing the project's social perspective (Cicmil and Hodgson 2006), viewing the project as a pattern of social interactions that takes place for a specific purpose and the project manager as a competent social actor.While this is a welcome extension of our interpretation, there remains a shared understanding that the project exists within a parent, hosted the organizational context.The following table attempts to summarise some of the notable differences between traditional, hosted projects and the project examples presented in this study.
In both project examples presented above, project delivery was out-sourced to various independent, freelance entities and therefore the project could be considered to be much less tightly coupled to one particular organization for which they were being carried out.In both project examples, there was no history of the project team members having worked together and no expectation that participants would work together again in the future.Team members were assigned to the project but not dedicated to the project, and team members were free to leave the project should they so choose.In both cases, the project goal was not found to be a sufficient foundation on which to build a unified, collaborative project team.The project organization could, therefore, be said to resemble a transient structure that was loosely-coupled to some freelance entities each with their interests and agendas about the project.
The PM knowledge base can sometimes provide us with what are prescriptive approaches to managing projects, and while this can be suited to certain situations,it is inappropriate for many others (Morris et al. 2006).Such approaches can serve to undermine the practice of PM by reducing it to a set of well-defined methods with only a marginal role for practitioner  insight and judgment.As a result, "essential knowledge, skills, and behaviors that overlap with PM are often considered as belonging to other areas of practice such as general management or human resource management" (Crawford et al. 2006: 724).This contrasts with the actual practice of PM and,as outlined in projects A and B above, the need to respond to complexity and uncertainty, as well as accommodate diverse perspectives and motivations.
The project situation presented above called for a broader review of the literature beyond the PM knowledge base,as it was felt that the situation encountered could not be adequately explained or addressed using the PMBOK (Project Management Institute, 2013), Individual Competency Baseline(IPMA ICBv4 2015) or similar PM-centric material.This search of the literature led the researcher to Pfeffer and Salancik's (1978) Resource Dependency Theory (RDT).RDT was developed primarily to help study macro organizational behavior and inter-organizational relationships.It considers how environments can affect and constrain organizations and how organizations respond to uncertainties within their environment.While RDT does not give explicit consideration to the project setting, some of its ideas may be relevant to certain types of projects, such as the project examples in this paper.The following points can be attributed to Pfeffer and Salancik's (1978) Resource Dependency Theory: "RDT observes that the predominant view of organizations is one of a rational instrument for achieving a goal or set of goals and counters this perspective with its view of the organization existing as a coalition of groups and individuals, with varying interests and preferences, that come together to engage in exchanges" (Pfeffer and Salancik, 1978:23).
"Establishing a coalition large enough to ensure its survival is a critical activity for the organization.In order for this to take place, it is necessary for organizations to provide inducements for participants to participate in their coalition.In return for these inducements, the participants provide contributions to the organization" (Pfeffer and Salancik, 1978:24).
"RDT suggests that the organization resembles a framework of exchange whereby inducements are provided and, in return, individuals agree to participate and provide Seen through the lens of RDT the project examples provided in this paper could be said to resemble such a framework of exchange.Within both examples, each project team member had their interest in particular aspects of the project.This loose project structure relied on the collaboration of all participants to be successful rather than the formal controls and procedures of an over-seeing or host organization.From the above project, examples there were instances of individuals leaving the project when it suited them.Not only that but it appeared that the project manager in both examples had neither the supervisory power nor sanctions that could prevent members from leaving the project.This is suggestive that the collaboration that underpins the project structure in the examples presented above could only be secured on a voluntary basis from team members.Unlike the conventional hosted project, this could not be either expected or commanded from team members by the project manager.
Interpreting the project as a collaborative framework of exchange has implications for how PM practitioners exercise governance on projects.Traditional PM practitioner competencies are viewed as "entry tickets" to the domain of PM, and"traditional skills of planning, organizing and controlling are hygiene factors, which by themselves they do not lead to effective PM practice" (Turner and Muller 2003: 6).Despite this, there is a dominance of PM research that focuses on traditional PM practitioner skills of planning, organizing, coordinating and controlling and these PM skills do not fully reflect the project reality (Cicmil 2006).Central to Cicmil's research is a concern that mainstream literature views project managers as "skillful technicians" (Cicmil 2006: 30) and that this perspective marginalizes the potential of the PM practitioner.
Building on these arguments this paper suggests that effective PM governance means moving away from representations of the project as a form of hierarchical structure that PM practitioners are expected to plan and control.The limitations of traditional PM skills are brought into focus in both project examples as the project manager was seldom in complete control of all of the human and technical components needed for smooth and seamless project delivery.In both project examples, formal project planning was abandoned early on in the project.In project example, A, implementation of the necessary technical platform that was central to completing the project work was beyond the control of the project manager.In both project examples, the project manager had little direct control over project team members.Previous research suggests that within the project context, there is normally insufficient time to clarify team member abilities and competencies and to engage in team building activities that would compensate for contextual instability (Grabher 2002).In both cases, the project manager was expected to build and sustain the necessary level of team commitment throughout the project life cycle sufficient to maintain project momentum and give effect to the desired project outcomes.Unlike the traditional hosted context, the project manager must achieve this in a context where there are practical limitations to his influence and control on the project.
The project arrangement in the above examples resembles a network of peers with no apparent designated supervisory authority.How can the project manager ensure effective project control in such a context?RDT offers potential insight as to how the project manager could exercise control and influence in the absence of a formal supervisory function (Cullen, Cullen Project Management Research andPractice, Vol. 5, 2018 10 2015).RDT contends that "managers do not control individuals, but instead can influencea fraction of an individual's behavior.Individuals do not invest all of their behaviors in any one organization; instead, their behavior is partially included within several groups.An individual's inclusion in an organization is defined by the proportion of his behavior included in that structure, and different demands can be made on the individual's behavior by different organizations.RDT argues that it is possible for an individual to be simultaneously part of more than one organization through different behaviors that take place at different times" (Pfeffer and Salancik, 1978).
Applying this idea to the above project examples, the project manager should recognize that he does not control the individual project team member.At best he will control only a portion of the behavior of a team member, while the individual team member controls other behaviors.Thus, it is possible that the demands on team member's behavior made by the project manager may at times be inconsistent or incompatible with demands on behavior made by another organization to whom the team member also belongs.RDT refers to this phenomenon as inter-role conflict, and this can represent a challenge for the project manager when managing project team members whose behavior is included in organizations outside the project organization (Cullen, 2015).

Conclusion
This paper has presented two live project examples that were based on a pilot case study competed in 2012 as part of a DBA programme carried out in DCU Business School, Dublin City University, Ireland.Both of these projects were staffed by team members hired specifically for the project, with individuals having no prior history of working together, and with little likelihood of them working together again in the future after the project was completed.In this way, the project members were representative of a temporary, loose arrangement of participants with disparate interests and aims.Project members left the project when it was perceived that there was no longer any advantage to be gained by remaining with it.This loose type of project arrangement presented in this paper, although common in practice would appear to be an outlier in much of the existing PM research.This prompted the researcher to conduct a broad review of literature that could shed potential light on the complexities of the situation highlighted in projects A and B. The researcher was drawn to ideas within Pfeffer and Salancik's (1978) Resource Dependency Theory that were considered potentially very useful to this research inquiry.The RDT alternative perspective of the organization existing as a coalition of groups and individuals, with varying interests and preferences, who come together to engage in exchanges would appear to resonate with the project examples provided in this paper.This opened up the possibility to explore the potential utility of RDT inspired ideas.The following table provides a summary of its implications for PM practitioners.
Previous PM research suggests that introducing more theories and concepts into PM will encourage more PM-related research and help establish the discipline within wider academia (Shenhar and Dvir 2007).It has also been suggested that a theory of projects cannot be built solely on empirical insight but also needs to be driven by theoretical insights from related domains (Soderlund 2004).This paper suggests that such theoretical perspectives exist in other fields of research and that there may be utility in importing them into the project context.This paper has introduced the possibility of usefully applying elements of RDT that are outside the domain of PM, to both PM research and practice and suggests that some potential RDT-inspired ideas could be usefully extracted to assist PM practitioners.However, this is an area of research that requires further development.There is scope to examine the utility of RDT-inspired ideas that are presented in this paper as well as other potential concepts that may exist in this and related theories and explore how they could be usefully applied to both PM practice and research alike.PM research observes that actual PM practice is a valuable source of knowledge about how to manage projects (Crawford et al. 2006) therefore a further trajectory of research development could consider the PM practice implications of these project arrangements to help further develop our knowledge base.Many do not see PM as the discipline of managing projects but as the discipline of using a set of predefined techniques to deliver a project on time, within budget and to a predefined scope (Morris et al. 2006).Implicit in this distinction is whether PM is viewed as the ability to use techniques to allocate resources and execute a plan, or overlapping with complementary PM domains such as general management or human resource management to enhance PM practice.This paper suggests that effective PM practice requires going beyond professional PM-related knowledge and techniques and drawing from complementary domains to inform PM practice by giving more explicit consideration to the impact ofexternal factors and human behavior on managing projects.
In both project examples, our attention is drawn to the socio-behavioral elements of managing projects.Grabher (2002) points up that increasingly projects rely on an infrastructure that is societal or social and built around networks and participant firms.Soderlund (2004) suggests that the socio-behavioral aspect of project work requires more explicit PM research consideration while Cicmil and Hodgson (2006) suggest more explicit consideration within PM research of the lived experience of those involved in projects.In the project examples above, a key challenge for the project manager is to build and sustain levels of participant collaboration throughout the project life cycle that are sufficient to maintain project momentum and give effect to desired project outcomes.The lived experience of the project manager suggests that this must be achieved in a context where there are practical limitations to PM influence and control on the project.This brings into perspective the sociobehavioral elements of PM.
Previous research suggests the contemporary project manager is a social architect who works at the intersection of organization and behavior-related elements.As a social architect, the project manager is responsible for developing a climate conducive to the active participation of project team members relying on a range of technical as well as non-technical skills to do so (Thamhain 2004).This description may have an added importance in this context.This socio-behavioral PM influenced trajectory may represent a potentially fruitful research trajectory to be considered as part of further research.

About the Author
A project management practitioner and lecturer in the CPM in University of Limerick.I earned my doctorate in project management from DCU in 2015 and my research interests include the socio-behavioura l aspects of project management as well as governance and project structures.
Loose, fragmented project arrangements -Some implications for practitioners Project Management Research and Practice, Vol. 5, 2018 5 PAGE NUMBER NOT FOR CITATION PURPOSES allocated and usually dedicated to the project.• Guided by established procedures.• Project manager has influence and discretion over resources legitimized through membership of the host organization.• Influenced by routines and norms.• History of participants working/ interacting together, likelihood of same in the future.• Resembles a loose, collaborative arrangement.• Loose participation in the project, resources may not be dedicated.• No established collective routines or norms to draw from.• No track record of association or expectation of future work.• Interdependence without clear overarching legitimized authority.
Loose, fragmented project arrangements -Some implications for practitioners Project Management Research and Practice, Vol. 5, 2018 9 PAGE NUMBER NOT FOR CITATION PURPOSES contributions to the organization.Within this framework, of inducements and contributions are assessed and negotiated between parties.Parties can then enter or leave the framework depending on their own assessment of the relative value to be gained by joining or leaving the framework"(Pfeffer and Salancik, 1978:25).
Loose, fragmented project arrangements -Some implications for practitioners Project Management Research and Practice, Vol. 5, 2018 11 PAGE NUMBER NOT FOR CITATION PURPOSES

Table 2 Contrasting
Project Characteristics

Table 3
Draw out of contrasting perspectives for PM practitioners.