Abstract
The socio-technical nature of projects has driven the shift in focus of these projects from product delivery to facilitating organizational change. Projects operate in an unstructured environment and are becoming more complex in terms of technology, the interrelationships between stakeholders, evolving project scope, and organizational expectations. In this context, existing tools, routines, and methodologies to manage and deliver projects may not be sufficient to resolve the complexity that emerges during the project life span. The resolution of complex issues requires access to a different style of leadership, covering a broad range of experience and knowledge and the ability to apply that knowledge to the specific requirements of the project. In this paper, we explore the role of leadership in facilitating the conduct of an outsourced ISD project through a case study in a large Australian Federal Government Department. Our study focuses on the role of leadership in the successful delivery and management of the project and shows that different types of leadership are used within and outside the project boundary to address project complexity at a broader, strategic organizational level.
Introduction
Businesses are continually responding to competitive environments by utilizing innovative techniques to deliver business strategies and goals. As organizations adapt to their environments, their business processes and work practices also change to catering to new demands. Project management is playing a crucial role in facilitating these changes. Classical project management assumes that everything in a project can be controlled (Morris, 2002). This approach does not adequately deal with the complex nature of a project, because classical project management processes do not adequately acknowledge or incorporate the human, contextual, and emergent elements of a project and therefore do not equip practitioners to deal adequately with the socio-technical complexities and changes (Young, Owen, & Connor, 2011). The project management literature has traditionally been over-focused on ‘hard-skills,’ with a casual wave given for the ‘soft-skills’ of project management (Cavalari & Reed, 2007). As Rodrigues notes, ‘new more sophisticated techniques are needed to improve performance.’ (1997, p.1) Thus, project management needs to be conceptualised more broadly in order to incorporate complexity and extend the assumptions that underpin project management practices to include emergence, self-organization, and adaptation. A fundamental component of this approach is the what, how, and when of leadership in project management.
To address the challenges of the modern business environment, projects are no longer just technocentric and concerned with product creation, but they also focus on creating value for the organization (Winter et al., 2006b). In this role, projects can be seen as drivers of social and organizational changes as well as physical deliverables. In such unstructured environments projects are becoming more complex in terms of emerging scope, the interrelationships with stakeholders, technological uncertainty, and organizational approaches. This context highlights the need to extend our concepts of project leadership as a capability that ensures project success. This paper explores the nature of leadership in complexity.
The key weakness of the current project management focused leadership literature is that it draws uncritically on the wider business leadership literature. This results in the same failures being repeated within the project management leadership literature (cf Gemmill & Oakley, 1992; Mole, 2004; Barge & Fairhurst, 2008; Beinecke, 2009). What are needed are specific contextual explorations of leadership activities, drawing on a social constructivist perspective (Tourish & Barge, 2010), which acknowledges the human, complex, and changing nature of leadership in projects. Furthermore, the structural procedures of project management methodologies also need to be addressed because of the tendency for the tools to pre-dispose the people involved to particular activities, feelings, thoughts, and passions at particular times in the life cycle (Owen & Linger, 2011). There is already some work acknowledging that different types of projects may need different types of leaders (Müller & Turner, 2007). In addition, beyond the type of project, there is also an indication that different leadership styles and capabilities may be needed, depending on the stage of project.
Our paper addresses the question of what types, styles, and approaches to leadership are required to manage complexity in projects. This question is explored through an empirical study of the delivery of an outsourced ISD project in a large government department. The paper is structured as follows. First, we discuss leadership in projects and the complex nature of projects. This discussion is followed by a case study of an outsourced project to roll out an enterprise project management software tool in a large Australian government department. The case is then analysed to highlight the type of leadership needed to manage complexity in projects.
Leadership in Projects
It has become a tired cliché to say that leadership is one of the least understood but most discussed components of business and wider social organisations (Beinecke, 2009). One of the key trends within the leadership literature is to focus on particular sites or applications of leadership to address research and education on the specific role. An example of this would be military leadership as a type of leadership in and of itself (cf Reed & Bullis, 2009). The applied, contextual leadership approach has been lauded as one of the few practical ways of engaging with the slippery concept of leadership (Mole, 2004). Essentially, leadership in context is about acknowledging the specific social circumstance that a group finds itself in and making sense of that circumstance, often through a leader–follower process. Such an iterative process acknowledges the social construction of meaning inherent to any interactional process between social actors seeking to make sense of their world(s) (Maines, 2000).
Another way of re-formulating the problem of what is leadership and how to transfer that into practice is to focus on the problem the group/leader faces; that is, the contextual social situation. Grint (2008) draws on a large body of knowledge that conceptualises the context of the problem as one of command (in the case of a crisis with a clear problem to be fixed), management (to address routine problems), or as a wicked issue. The wicked problem is an issue that is fluid, difficult to identify, and with little or no clear answer. Wicked problems require significant meaning–making work to be done by the group, often in highly contested and volatile environments. Heifitz (1994; in Beinecke, 2009) calls these types one, two, and three problems. Type one being technical and solvable; type two being a problem with an unknown solution; and, type three, where it is unclear what the problem is (and of course the solution is another unknown). The issues that types one and two problems create for a project are resolvable using traditional methodologies and management approaches. Although this does not discount the needs for communication and sense-making, these approaches and methods are a ‘fix’ if used properly. Of a much greater challenge for project leadership is the type three, or wicked, problem.
Müller and Turner (2007) argue that complex projects require transformational leadership, a style usually associated with change processes. Further work by Müller and Turner (2010) identified critical thinking, influence, motivation, and conscientiousness as common leadership competencies (or traits to use leadership terminology) for all project managers. Their work also identified other traits that are specific to different types of projects. The key ability of a leader is to make sense of or define an issue, communicate with stakeholders, and evolve a course of action. This is fundamentally different from transformational styles of leadership, which at their core are about the leader holding a vision and taking his or her followers there (cf Sarros, Cooper, & Santora, 2008). Although it is beyond the scope of this paper to engage with the debates within the leadership literature (see Tourish & Barge, 2010, for such a commentary), we must acknowledge that we employ a constructivist, iterative sense-making framework to leadership activity, which accepts emergence and non-traditional leadership activities.
Complexity in Projects
The management of a project uses a methodology throughout the project life cycle, covering planning, control, monitoring, and execution (Project Management Institute, 2004; APM, 2006). However, a rational approach to managing projects following a prescribed methodology does not always suit the needs of a project (Kautz et al., 2004). Project methodologies are based on normative and deterministic approaches and are used to manage and control the development process (Avison & Fitzgerald, 1995) and provide a generalized and transparent approach. In practice, a prescribed methodology is not always followed; rather, an emergent methodology is used that adjusts the prescribed methodology to meet the needs of the situation. As Kautz et al. (2004) point out, such emergent methodologies are in fact normal practices in project management (Mathiassen & Stage, 1992). Methodological flexibility enables actors to effectively address project complexity in the deployment and implementation process. Emergent methodologies are based on the actors’ experiential knowledge, their roles in the project, and the contextual nature of the project/issue. To deal with the phenomena of emergent intrinsic issues requires techniques, drawn from the actors’ experience, which are made explicit and incorporated into an emergent methodology. This creates a fundamental tension between the formal, proscribed, and often legally mandated, project management system and the reality of utilising emergent methodologies based on experience. The challenge for project leadership is to exploit internal and external knowledge in a reflective way. It also requires the organization to exhibit significant trust in the leader and project/program team to allow methodological flexibility.
People perceive situations as complex if the situation is unclear, highly complex, or paradoxical, or there are differing interpretations (Weick,1995; Thiry, 2002; Pich et al., 2002). Throughout the project life cycle, complex issues emerge—ranging from managing stakeholder expectations, scope clarity, planning and re-planning, resource allocation, ensuring adequate control, and knowledge transfer (Forsberg et al., 2006; Atkinson et al., 2006; Chapman & Ward, 2003). These intrinsic issues can result from uncertainty; a lack of data, information, and knowledge about a given situation; or ambiguity, different interpretations of the same situation (Thiry, 2002; Atkinson et al., 2006). Using a rational decision-making process with existing knowledge, tools, and techniques to resolve ambiguous intrinsic issues is difficult (March 1991a). In this context, existing tools, routines, and methodologies may not be sufficient to resolve the complexity that emerges during the project's lifespan. In terms of leadership, we move from the requirement to have competent management in a project to needing leaders that can make sense of the emergent complexity (i.e., the wicked or type tree problem).
Managing Project Complexity
Complexity in projects arises from many sources, and classical project management approaches are not appropriate for dealing with such inherent complexities. Complexity requires project leaders who can apply their experience and knowledge to resolving the specific issue. Knowledge-based practices (KBPs) signify the individual practices, soft skills, and social processes that exploit the knowledge and experience of the project leader to frame, formulate, and communicate the wicked problem (Owen, 2010; Owen & Linger, 2011). In the context of wicked problems within a project, the KPB response is a process of iterative sense-making in which the issues are debated, codified, and (probably) addressed.
Where complexity cannot be addressed, or the solution cannot be negotiated within the confines of the project, an ad hoc structure outside the project boundary is formed to address and resolve the issue. The structure can be informal and created on a just-in-time basis (Dening, 2006; Snowden, 2002) but with the appropriate authority to deal with the complexity of the project. Addressing complexity requires experimentation, innovation, and flexibility (March, 1991, a & b), as well as knowledge-based practices, and acknowledgement of existing and changing power structures and negotiation. Resolution of complex issues involves processes that exploit the experiential knowledge of the participant, their domain knowledge, and emergent knowledge of the situation (Brown & Duguid, 1998; Tsoukas, 1996). It is also about constructing shared understanding, with actors articulating their viewpoints, in order to achieve a viable resolution through argumentation (Hirschheim et al., 1996). Such a resolution often entails a reframing of the project to identify more appropriate outcomes.
The process of reframing is termed de-escalation. De-escalation recognizes the expertise of the leaders involved in the process in addressing the complex issue (Montealegre & Keil, 2000); however, such informal processes need to be formalised through processes that ratify or approve the informal resolution, including amendments to the legal or contractual structure of the project. On both the informal and formal levels, it is recognized that the actors engaged in de-escalation form a leadership group, working on a meta-level outside the normal boundaries of the performance of the project. Addressing the complexity of issues on the informal level results in innovation; on the formal level, the proposed resolution is sanctioned and the solution inserted into the performance of the project by documenting it and tailoring the methodology to meeting the needs of the new project agenda. An important decision to be made is whether the issue is an aberration of the specific project situation or whether it is indicative of a fundamental change. If it is the latter, then the resolution needs to be incorporated (explicitly or implicitly) into the project management body of knowledge as an incremental improvement (Kurtz & Snowden, 2003) for re-use in future projects. It is clear that classical tools and techniques cannot adequately address emergent issues that need to be de-escalated outside of the performance of the project (Morris, 2002). It is here that leadership is required.
Research Method
The case presented in this paper is a study of an Information Systems Development (ISD) project used to deliver organizational change (Marshall & Rossman, 1995). The project involved outsourcing the implementation of an enterprise project management software application at an Australian Government Department.
Our empirical research was conducted using an exploratory case study methodology. The study is interpretive, focusing on the socially situated nature of the project (Walsham, 1995), in order to allow the phenomena to be studied in detail using a variety of approaches (Myers, 1997). This allows the social and organizational phenomena to be studied in a specific context, in which ‘…. the experience of the actors is important and the context of the action is critical.’ (Benbasat et al., 1987, p. 369) Moreover, the case study is a means to focusing on emergent phenomena situated in an actual organizational context (Yin, 2009).
The study used a number of different data sources to view the phenomena in different ways in order to cross check information (Sabherwal et al., 1998). The study was conducted by observations, background discussions, in-depth interviews, analyses of internal and publicly available documents, and analyses of secondary sources covering internal and external business processes. Observations and initial background discussions with clients and vendors formed the basis for the development of an interview guide, and a framework for recording and analysing the relevant project documentation and business processes. The framework was adopted for document analysis and secondary data. The analysis was conducted iteratively throughout the data collection process and facilitated a deeper understanding of the formal and informal processes adopted in the management of the project (Owen, 2010, Owen & Linger, 2011).
Nine in-depth interviews, each taking approximately ninety minutes, were conducted with the outsource provider employees. The interviews were conducted by one of the authors. Interviews included the managing director, a member of the senior management team, and a number of consultants, including the two consultants from the case study project team. Interviews with two government department staff responsible for the project were done informally due to restrictions imposed by the Department. However, the same level of ethical conduct, including the explanatory statement, was followed. Follow-up interviews were conducted as necessary to clarify issues that emerged in the data. The interviews were taped and transcribed. The transcripts and notes taken during the interviews were analysed and coded based on key themes derived from the literature and themes that emerged during the interviews.
Detailed analysis of business processes was conducted for the Government Department. This analysis included publicly available documentation to provide an overall profile of how project management occurred within the Department. Important secondary data in this analysis were government audit reports about the department's project management capability. Document analyses of the vendor's project management and business processes were also conducted.
Detailed background discussions with project team members were conducted after an initial analysis of the interviews and document analyses of both organizations. As a consequence, two follow-up, in-depth interviews were conducted with the outsource provider's lead consultant and the client's project manager. This approach facilitated reinforcement of concepts that surfaced during the initial interviews. Open- ended questions allowed emerging themes to be identified (Dawson, 2008). Fundamentally, the interviews explored how the project was delivered and managed, how intrinsic issues emerged, and the role of KBPs in the resolution of these issues. Documents collected from both the vendor and client provided data to support the interviews and add to the richness of the case.
Case Study
The case study ISD project was implicitly constructed to drive organizational change and provides an ideal venue in which to study the management of an outsourced project from the perspective of complexity and the role of leadership. As an outsourced project, there are two parties (actors) involved in the implementation process — the commissioning authority (the Department) and the outsource provider (PM Consulting [PMC]). Both will manage their respective organizational responsibilities for the project and will need to negotiate an acceptable way of jointly managing the project.
In this case study, we consider the government department, the service provider, and the project itself as the significant actors. We have adopted this analytical approach so that we can present the case from the perspectives of each of the three actors. The focus in our study was to understand the conduct of the project from the Department and PMC's perspective and also to study the interaction between them during the implementation process; hence, the project also became an actor. This approach provides three perspectives of the management and implementation of the project.
The Department
The study was conducted in a large Australian Federal Government Department (the Department), comprising a number of divisions, which outsourced the rollout of an enterprise project management software tool to an outsource provider. The Department is a statutory authority established under the Commonwealth Services Delivery Agency Act 1977 and is charged with the delivery of social services support to the Australian community and other government departments. The Department's business is derived from partnerships with a number of government agencies that set social service policy direction. Policy initiatives implemented on behalf of other agencies are largely delivered by projects. Its budget is estimated at just under A$3 billion, which includes revenue from agencies and policy departments of just over A$2.5 billion. Services and products are continually readjusted by the Department, based on government legislation and budgetary initiatives introduced by the government.
The project manager reported to the project sponsors and through the project sponsors to the Project Steering Committee. This Committee reported to the IMPC, which oversaw the delivery of project benefits. A project manager also reported to another committee, such as IT or Service Delivery, if it had an IT component, or was a budget initiative. Another way the Department dealt with the complexity of projects and intrinsic issues was to appoint project directors to monitor and support projects, which led to an improved insight on project progress. ‘These positions have provided invaluable expertise to Division Heads who have responsibility for multiple, diverse projects and limited project management expertise within their Divisions.’ (The Department Internal Report, 2006) This oversight process or senior leadership role is a knowledge transfer and information role.
PMC
PMC was a major software provider of enterprise project management software. PM International was a global company based in the United States, where they researched, developed, and provided software for enterprise project management. The software was sold internationally in 128 countries by authorized resellers, and PMC had been the Australian and New Zealand reseller for 19 years.
PMC was a privately owned, locally run organization, with a professional service culture and informal but developing business processes. The background of the principals was predominantly engineering, thus favouring rational decision-making processes. At the time of the case study, the management structure of PMC was a matrix structure reflecting the regional and functional business lines. A board of management, consisting of executive and non-executive members, governed the strategic direction and finances of the organization. PMC's employees had skills in managing and delivering ISD projects, implementation of enterprise project management tools, and integration with other IT systems. The company employed approximately 20 consultants (implementation and technical) throughout Australia and sourced contract staff from their professional networks, as required. PMC was structured on a state basis, with consultants being allocated to a project by the regional manager. Management, functional areas, and specialist software development and integration areas sat at the Head Office level.
A typical implementation team consisted of a core project team and an extended team. The core team was the on-site project team responsible for managing and delivering the Project Enterprise Project Management Software (PEPMS) implementation, including the project manager and on-site consultant. Core team members were dedicated to the implementation for the term of the project. Extended team members or subject matter experts were individuals from all applicable areas (e.g., DBAs, programmers, project managers, internal customers/sponsors, technical writers, trainers, and PMC's engagement manager) who were generally involved in the implementation on a part-time basis. The size of PMC's implementation was dependent on the size of the number of licenses and the complexity of integrating the PEPMS with the client's other IT systems.
The Project
Consistent with the structure of projects within the Department, the project team consisted of a project manager, two executive sponsors, one the business owner and the other the IT or product owner. The business owner was the Chair of the Steering Committee and reported project progress or significant issues to the Business Improvement Committee through the Corporate Program Office (CPO). The product owner was accountable for the deployment of the PEPMS (Figure 1) into the Department's environment, whereas the project manager was responsible for overall project, vendor, and contract management.
Initially, representation on the project from PMC involved one implementation consultant to lead the consulting side and advise the project manager on technical and functional issues. As requirements broadened, two technical consultants from PMC joined the team to develop the integration of the PEPMS and the ERP. As further requirements emerged in the Business Divisions, additional PMC consultants were deployed for short-term assignments to meet the timeline.
Figure 1: PEPMS project structure (PEPMS Project Management Plan).
The integration of PEPMS with other technology was not in itself complex. Rather, it became complex with the interaction of the integration consultant with stakeholders and users from the Department. PMC recognized that their understanding of the technical requirements was based on assumptions about what the customer wanted. The consultant developed what he thought the Department required, rather than what it required, which exacerbated the complexity for the lead consultant. This recognition led PMC's lead consultant to remove the issue from the confines of the project to resolve the requirements. In an effort to resolve the confusion and reduce the complexity, the PMC lead consultant organized an initial meeting to make sense of the requirements and agree on a set of requirements. This led to the establishment of a weekly meeting between Department representatives and PMC. These meetings were quickly expanded to deal with all emergent issues with the meeting, assuming explicit responsibility to develop a comprehensive understanding of the issues, assign an owner to each issue, and ensure that the issues were resolved.
‘Sometimes the scope is not clearly defined, so we believe we are meant to be there to do something and the customer thinks that we are actually doing something completely different. Or they are expecting us to do more than we have actually signed up for.’ (PMC Professional Services Director)
Champions in each division were identified to assist with the rollout and improve the usage of the tool. These champions were not parts of the project team but were identified as key stakeholders within the Divisions who could influence the usage of the PEPMS. These appointments were fundamentally about making sense of the complex, unknown environment the project was operating in. It was the role of the champion to facilitate a process of resolution to wicked and/or type three issues. The creation of the role was a deliberate response by the Department to a recognized problem situation. The Department also recognized that there was no standard way of managing projects at the individual and enterprise levels; thus, the champions had to respond to an unknown with novel communicative practices. These leadership roles hinged on the creation of shared meanings negotiated by the champions and other stakeholders. The use of champions within Divisions to encourage PEPMS usage and involve stakeholders allowed stakeholders to engage in sense making in order to understand the nature and value of the project.
‘We picked out Change Leaders or Champions in the business…a person who was receptive to change and using PEPMS…they became a center of excellence and provided a decentralized area of systems expertise and support.’ (PMC Lead Consultant)
Issues that emerged and were addressed within the confines of the project used existing tools and techniques, which were adapted to the situation. These issues were process related rather than technology related, although some were seen as major technical issues by the Department. Issues that were process related could be dealt with immediately within the confines of the project. Resolving the issues involved using existing tools and techniques. An example of the type of issue was that a weekly time sheet was required; however, PEPMS could not provide this requirement. This was seen as a major technical issue by the Department and was resolved by PMC addressing it from a process perspective by developing an initial set-up process. This is an example of dealing with types one and two leadership/management problems.
The growing resistance to the PEPMS project was an acknowledgement of its complexity. The complexity, uncertainty, and ambiguity of the situation often meant that issues could not be resolved with the normal, rational decision-making tools and techniques but relied on the experience, knowledge, and skills of the project managers, from the Department and PMC, as well as their collective understanding of the current situation. To deal with this complexity, the project adopted an additional forum, which provided a venue and had the authority to resolve emergent issues that could not be resolved within the confines of the project. Collaboration and reflective practices were keys to the resolution of these issues in this forum. Talk practices, making sense of the unknown, and creating ‘do-ables,’ are key leadership characteristics for wicked/type three problems. In this study, the negotiations were passed to a body that had the authority to deal with the issue. This group created a space in which issues were resolved by reaching a shared understanding through reflection, formulating, and planning a course of action and making commitments to that new action. Within this ad hoc group, leadership was shared and distributive, shifting as the dictates of the problem, or yet to be characterized issue, emerged.
The scope of the PEPMS project presented a number of challenges. First, there was a discrepancy between the Department's stated objective and its actual agenda for the project. The issue arose due to a lack of apparent knowledge and a lack of information about the project scope by PMC. PMC only became aware of the discrepancy after the contract was awarded. The resolution of this discrepancy was achieved by renegotiating the contract terms. The nature of this issue meant that it had to be moved to a different space for a different type of consideration, where the body had a deeper understanding of the issue. This led to a de-escalation process that facilitated recognition of the problem and understanding the discrepancy between the scope of the project and the organizational agenda. De-escalation allowed the project to be re-scoped and a mutually agreeable implementation strategy to be adopted.
The fact that the PEPMS did not do everything that was requested of it in the initial tender necessitated the formation of an informal authoritative group to create temporary solutions. The temporary solutions enabled the PEPMS to meet the Department's requirements. This contributed to the technical complexity of the project, because the software had to be adapted to the Department's requirements and the organizational environment. The group was formed on the basis of their different experiences, which contributed to their ability to collaborate to reach a shared understanding of the problem, assess options, and commit to a new course of action. The activities of the group; making sense of the situation; reflecting on viable options, based on their collective knowledge; and determining the implementation actions, also contributed to learning within the group.
Discussion
The nature of complexity exhibited in the PEPMS project meant that issues had to be moved to a different space where they were considered on the basis of a more strategic understanding of the situation. This constituted learning, because new knowledge and understanding were created to make sense of the situation. Such a venue is usually created by calling a meeting. Although a meeting is a normal technique, the need to resolve emergent issues requires a meeting that is outside the confines of the projects and is used as a venue for exploration, reflection, and action. Such a meeting involves membership with a vested authority to resolve the issues. In this study, the negotiations involved a senior member of PMC's management team and the Department's project manager, who both had the authority to renegotiate the project scope. Both had a deep understanding of the project, from their perspectives, and it was these insights that formed the basis for defining what can be characterized as the real project. At this venue, participants gained a shared understanding of the project and its contexts, their organization's roles, their resources, and their aims and objectives.
The rollout of a major application in the Department is by its nature complex. Typically, the scope of the project emerged or changed as stakeholders exerted their influences and the technical dimensions became clearer. Initially, the integration of the PEPMS with other technology did not appear complex. However, it was the interaction between the integration consultant and stakeholders, including users from the Department, which increased the complexity. During the rollout of the PEPMS, issues that were intrinsic to the project emerged. Most issues that emerged were due to the nature of the project—unknown technical solutions, changing requirements, resistance to change, and divergent stakeholder agendas. In an effort to resolve the confusion and reduce the complexity, the issue was moved out of the project boundary. This created a conversation space for a group comprising internal experts from the project and external experts. This group had the seniority to understand the issues strategically and the authority to resolve the issue. The venue allowed the group to view the issues from a different perspective and use experiential knowledge to collaborate and make sense of the situation, understand the issue and its context, explore different options, and negotiate the most viable option.
A reason that complexity was compounded in the project was due to technical issues that arose during the rollout of the PEPMS, which did not meet all of the Department's requirements. An informal group comprising a PMC consultant from the PEPMS project and experts from PMC considered the issue outside of the performance of the project in order to resolve the gap between PEPMS performance and the Department's requirements. The resolution of complex issues requires access to a broad range of experience and knowledge and the ability to apply that knowledge to the specific requirements of the project in an innovative and flexible way. This is often done through KBPs that draw on experiential knowledge of the participant, their domain knowledge, and knowledge of the situation in which the issues emerges.
The rollout of a major application in the Department was by its nature complex as stakeholders exert their influences and the technical dimensions became clearer. As stakeholders became engaged in the PEPMS project, the scope and technical requirements changed. For these internal stakeholders such changes represent type one or two problems, because the stakeholders want solutions that meet their individual requirements. However, dealing with such emergent changes necessitated moving the issue out of the project boundary so they could be considered strategically, rather than operationally, because such changes impact on both the organization's strategic intent as well as the legal structures that govern the project. Consideration of such changes outside the project boundary requires different toolsets and practices, since these issues are no longer technical (type one or two problems) but are now wicked problems (type three)
Throughout the PEPMS project there was resistance to it, and a lack of stakeholder buy-in within the Divisions of the Department, due to differing stakeholder agendas. Resistance was addressed outside the project boundary, with a decision to establish Champions within each Division to argue for the project. To support the decision, the standard project management communication plan was adjusted in order to identify and cater to this resistance and provided a roadmap and toolset for the Champions. The Champions’ role was to influence the use of the software within the Division by drawing on their intimate knowledge of their Division. This knowledge helped them create a shared understanding of differing stakeholder agendas. Organizationally, the Champions, with some senior project staff, formed a group outside the project boundary that allowed them to collaborate and explore the different agendas across the organization, and draw on their own experiences in their Divisions, to construct a shared understanding and re-interpret the PEPMS project.
Conclusion
The series of activities undertaken by the leaders in the project fit into Grint's (2008) wicked typology of problem resolution and leader behaviour. Of particular note is the sense-making and social constructivism that the leaders had to engage in to identify, talk about, and eventually resolve issues. The capability to do this rested first on communications skill, followed by socio-technical knowledge and, last, on the ability to reflectively assess a social circumstance. The leadership was also emergent and took advantage of processes outside the traditional project management methodologies.
A risk with developing ‘ideal’ leadership methods for project managers is that the evidence indicates that the leadership needed within a project depends on the project type, stage, complexity, and uncertainty level. By definition, complexity and uncertainty are un-knowable; thus, to pre-figure the required leadership type in any project but the most basic can only be an educated guess. Therefore, project management, like management in general, is caught in the bind of only knowing what was good and bad leadership after the fact.
Our study highlights the need for leadership methods that can address the imperative of knowledge based practices, which are required to address complexity and emergent issues in projects. An important aspect of our study is that complexity often requires resolution outside the project boundary. Such resolution has a strategic intent and emerges through practices such as reflection, sense making, and experimentation, all drawing on the experiential knowledge of participants. But our study also shows that such practices are directed to ensure project success, both in terms of product delivery and organizational value. The challenge for project mangers is to demonstrate leadership capacity for types one, two, and three problems simultaneously
