Scandinavian Journal of Information Systems Volume 23 Issue 2 IT Project Management: Studying agility, globalization, organizational mindfulness and outsourced projects Article 4 12-31-2011 Knowledge-based Practices for Managing the Outsourced Project Jill Owen University of New South Wales, j.owen@adfa.edu.au Henry Linger Monash University, Henry.Linger@monash.edu Follow this and additional works at: http://aisel.aisnet.org/sjis Recommended Citation Owen, Jill and Linger, Henry (2011) "Knowledge-based Practices for Managing the Outsourced Project," Scandinavian Journal of Information Systems: Vol. 23: Iss. 2, Article 4. Available at: http://aisel.aisnet.org/sjis/vol23/iss2/4 This material is brought to you by the Journals at AIS Electronic Library (AISeL). It has been accepted for inclusion in Scandinavian Journal of Information Systems by an authorized administrator of AIS Electronic Library (AISeL). For more information, please contact elibrary@aisnet.org. Owen and Linger: Knowledge-based Practices for Managing the Outsourced Project Knowledge-based Practices for Managing the Outsourced Project Jill Owen University of New South Wales, Australia j.owen@adfa.edu.au Henry Linger Monash University, Australia henry.linger@monash.edu Abstract. The management of outsourced information systems development (ISD) projects is both complex and problematic due to the type of outsourcing arrangement, the nature of the work that is outsourced, and the relationship between the vendor and client. Moreover, outsourced projects are conducted in an unstructured environment with divergent organizational expectations. Existing project management techniques and methodologies may not be sufficient to resolve such complexity, and project management needs to encompass knowledge-based aspects of management. Knowledge-based practices (KBPs) are directed to exploring, understanding and making sense of complex situations, sharing that understanding and using that understanding to inform actions to resolve that complexity. These KBPs need to be explicitly included in an expanded repertoire of project management techniques. In this paper we explore how KBPs facilitate the conduct execution of an outsourced ISD projects through a case study in a large Australian federal government department. Our study shows how KBPs operationalize and formalise a knowledge-based approach to project management for the successful delivery and management of outsourced projects. Significantly our study shows that KBPs are not only used within the project boundary but are also applied outside of the project boundaries boundary to address project complexity at a broader, strategic organizational level. Key words: ISD projects, knowledge-based practices. Scandinavian Journal of Information Systems, 2011, 23(2), 85-108 Published by AIS Electronic Library (AISeL), 2011 1 Scandinavian Journal of Information Systems, Vol. 23 [2011], Iss. 2, Art. 4 1 Introduction The motivation for outsourcing information systems (IS) projects is varied but can be broadly categorized as refocusing business strategy on core competencies and reducing costs (Lacity and Willcocks 2001; Dibbern et al. 2004). There are several different outsourcing options, ranging from the body shop option where external resources are sourced to meet a specific demand to managing a project or component of work to meet a specific demand to total vendor solutions where the vendor assumes responsibility for the majority of the IT work in an organization (Lacity and Hirschheim 1993a). For outsourcing to be successful, there are a number of indicators that contribute to outsourcing success, including but not limited to, the careful selection of functions to be outsourced, an understanding of and the managing of costs, the length of the outsourcing contract and its flexibility (Lacity et al. 1996; Smith and McKeen 2004; Kern and Willcocks 2002; Lacity and Willcocks 2000; Fisher et al. 2008). The management of outsourced projects is both complicated and problematic due to the type of outsourcing arrangement, the nature of the work that is outsourced, and the relationship between the vendor and client. In this context, existing tools, techniques and methodologies may not be sufficient to successfully manage and deliver outsourced projects. Success in such projects depends on the ability to resolve the complexity that emerges during the life of the project as a result of the network of relationships between stakeholders, divergent organizational expectations of each party, differences in Information Systems Development (ISD) methodologies and changes to the project over time. Project managers need to draw on a broad range of experience and knowledge, and be able to apply and share that knowledge, to ensure the success of outsourced projects (Lee et al. 2008). This highlights the need to expand the repertoire of project management beyond the traditional control view (Sauer and Reich 2009) to encompass the experiential and knowledge-based aspects of management (Winter et al. 2006). We have coined the term knowledge-based practices (KBPs) to signify the individual practices, soft skills, and social processes that exploit the knowledge and experience of actors engaged in a professional activity. The concept of KBPs is significant in a number of complementary ways. Firstly, it is a concept that identifies the situated actions that contribute to value creation. Secondly, the KBPs are a means to make explicit the collection of situated actions that are necessary to address complexity, uncertainty and ambiguity that is inherent in the situation in which the activity takes place. Thirdly, the KBPs concept enables a range of practices, skills and processes to be formally incorporated into the processes that underpin the activity. Such processes integrate technical skills that exploit tangible resources required to perform the activity, together with generic skills that exploit intangible resources, knowledge and experience. These generic skills, the KBPs, are reinterpreted for each instance of the activity so that the application of those skills is relevant to the requirements of the situation and the context of the activity. This process of reinterpreting is itself part of the KBPs concept. Moreover, since KBPs are situated and contextualised, they need to be deployed dynamically throughout the activity in order to sense and act on the changing circumstances of the activity. In our research we employ KBPs as an analytical lens to understand how, and reveal what, generic skills are used to deliver the project. In this paper we use the term knowledge-based practices (KBPs) to capture activities that are directed at exploring, understanding and making sense of specific situations, sharing that under86 Owen & Linger http://aisel.aisnet.org/sjis/vol23/iss2/4 2 Owen and Linger: Knowledge-based Practices for Managing the Outsourced Project standing and using that understanding to inform actions that will impact on that situation. Such activities are derived largely from the knowledge management literature (for example Davenport 2005; Nonaka 1993; Alavi and Leidner 2001; Kurtz and Snowden 2003) that deals with issues of knowledge construction, deployment, and exploitation within an organizational setting. Significantly this literature positions these activities within complex settings, involving networks of actors and recognizing the inherent complexity of the activities themselves. This perspective is also articulated in the knowledge-based view of the firm (Grant 2002; Spender 2003; Kogut and Zander 1992) that views knowledge as the most strategic asset of the organization. Additionally, there is an emerging literature in project management that specifically addresses how knowledge is exploited in the context of projects (for example; Desouza 2003; Griffith et al. 2003; Tiwana 2003). More broadly the Winter et al. (2006) report on the Rethinking Project Management agenda highlights the shift toward a knowledge-based approach to project management academically and in practice. Our contribution is an emerging theoretical explanation of the role of KBPs in ensuring project success. Current literature focuses on the need for a knowledge-based approach but provides little insight into how this approach can be incorporated within the structural and functional dimensions of project management and integrated with existing normative practices. Thus our paper addresses the question of how KBPs can be formally and practically incorporated into project management practices to facilitate the effective management and delivery of information systems 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. Firstly we discuss the background of outsourced ISD projects, the evolutionary nature of ISD, development strategies of ISD projects, and the role of KBPs to manage outsourced ISD projects. This discussion is followed by a case study of an outsourced project to rollout an enterprise project management software tool in a large Australian government department. The case is then analysed to highlight the role of KBPs in the project and a theoretical explanation of how KBPs can be formally incorporated into project management practices is presented. This is followed by a discussion of the results reflecting how projects are managed within the confines of the project and how emergent issues are resolved outside of the project boundary at a broader strategic level. The conclusion draws together the research and discusses the contribution of the article to both theory and practise. 2 Background 2.1 Outsourcing Outsourcing has existed outside of the IT space in a number of forms, usually focusing on a homogenous activity. There are multiple definitions of outsourcing; however, Dibbern et al. provides a simple and succinct working definition as 'the use of external agents to perform one or more organizational activities' (2004 p. 9). In IT, outsourcing is a commonly accepted comKnowledge-based practices for managing the outsourced project 87 Published by AIS Electronic Library (AISeL), 2011 3 Scandinavian Journal of Information Systems, Vol. 23 [2011], Iss. 2, Art. 4 ponent of IT strategy, but usually involves the entire ISD process (Hirschheim et al. 2004). The complexity of ISD projects has led to outsourcing that usually involves the provision of multiple services and a complex web of responsibilities. There are different reasons for outsourcing. These include cost reduction and efficiency improvements, improvements in business performance, commercial exploitation of outsourcing provider capability, divesting the company of a problem, and following the lead of others (Fisher et al. 2008; McFarlan and Nolan 1995; DiRomualdo and Gurbaxani 1998; Smith and Keen 2004; Lacity and Hirschheim 1993a). Outsourcing can involve single or multiple vendor relationships and options range from total outsourcing where the vendor is in charge of an organization's ISD to total insourcing where the majority of IS functions are conducted within the organization by the vendor; to selective sourcing where specific functions are conducted by external vendors; to the body shop where contract resources are used to meet short-term resource constraints. (Dibbern et al. 2004; Lacity and Hirschheim 1993b). In our empirical study, we focus on a project-based outsourcing arrangement that is characterised by finite duration and commitments. 2.2 The Evolutionary Nature of ISD ISD has developed in an evolutionary manner (Kautz et al. 2007) from a technical focus to a sociotechnical focus (Hirschheim et al. 1996; Orlikowski 1991) while retaining its emphasis on the development of physical artefacts (Orlikowski and Iacono 2001). Irrespective of the focus, ISD is a complex socially situated activity (Orlikowski 1996) that involves organizational, behavioural and technical change (Markus 1984; Markus and Robey 1988). Thus complexity is inherent in ISD and these projects are characterised by ill-defined and unbounded emergent issues (Mathiassen and Stage 1992) as well as a political, subjective, evolving and negotiable scope (Guindon 1990). Thus key aspects of ISD are the social practices to resolve issues that arise from such complexity (Hirschheim et al. 1996; Brooks 1995; Weidong and Lee 2005). Outsourcing adds to the complexity of ISD projects as it increases the number of actors involved and refocuses the project on people, their relationships, and their actions. ISD projects are simultaneously concerned with constructing an artefact and facilitating organizational change. From the technical perspective, complexity in ISD has increased because of the plasticity of information and communications technology, the rate of technological change, the importance of security, the requirements that emerge throughout the project, the diversity of viewpoints of different stakeholders, and the development process itself. Complexity in ISD is compounded by an organizational context that is characterised by the rate of business change, use of virtual project teams, organizational instability and interdependence with other organizations (Mathiassen and Stage 1990; Lyttinen 1987; Sauer and Reich 2009). The complexity of ISD and the recognition of its implementation as a social phenomenon contribute to the high failure rate of ISD projects (Sauer 1993). Despite an on-going recognition of the complexity of ISD, approaches to develop IS artefacts have continued to be based on rigorous, well-defined methodologies in an attempt to link ISD with engineering (Cockburn 2004). However, prescriptive, planned methodologies are not always appropriate in a dynamic, complex environment (Kautz et al. 2007). More recently there has been the development of less 88 Owen & Linger http://aisel.aisnet.org/sjis/vol23/iss2/4 4 Owen and Linger: Knowledge-based Practices for Managing the Outsourced Project rigorous methods such as Agile Methods (Cockburn 2004) but these remain largely normative approaches concerned with the development of a technical artefact (Kautz et al. 2007; Madsen et al. 2006). Moreover, such approaches do not deal with the complex social activity that is ISD (Goulielmos 2004). ISD failure rates and the growing acceptance of the inherent complexity of ISD, requires improved methods, techniques, and tools (Hasan and Kazlauskas 2009). In this context, KBPs can become a critical component of the ISD project (Lee et al. 2008), encouraging effective collaboration from stakeholders, drawing on their different expertise and the development of innovative solutions to emergent issues (Levina 2005). Such collaboration needs to address the operational, functional and management aspects of the ISD project, as well as the legal framework that governs the outsourced project. 2.3 Managing Complexity in Outsourcing Projects with KBPs The limitation of traditional tools and methods necessitates additional techniques to address complexity. The problematic nature of ISD projects in terms of project size, complexity, emerging technology, and the emergence of intrinsic issues, suggests that knowledge and learning need to be formally integrated into project management practices. Such practices would supplement the traditional approaches that are underpinned by scientific management principles (Reich et al. 2008). We argue that KBPs represent such practices. KBPs directly address complexity, allow issues to be resolved in an innovative and flexible manner, and potentially contribute to the evolution of the body of knowledge that underpins the management of projects. Addressing complexity requires experimentation, innovation, flexibility, collaboration, negotiation (March 1991) and an understanding of existing and changing power structures. Such practices draw on the experiential knowledge of each participant, the domain knowledge of all participants, and the emergent knowledge of the situation (Brown and Duguid 1998; Tsoukas 1996; Orlikowski 2002) rather than relying on rational decision-making processes (Weick 1995; March 1999). Participants need to exploit their existing knowledge and skills to create new knowledge to respond adequately to complexity (Mintzberg 1989; Burns and Stalker 1961). The proliferation of ISD methodologies (Hirschheim et al. 1996) has itself contributed to the complexity that is encountered during the development process. Moreover the outsourcing relationship in IT makes project management more complex and may give rise to additional or different types of risks from both the client and vendor perspectives (Taylor 2007). The management of an ISD project is determined by the methods and tools used in the development as these provide the knowledge and procedures to implement the ISD initiative. However, in situations where existing tools and methodologies cannot resolve the issues that emerge, normal practice is to tailor methodologies to that situation in the context of a specific project and organization (Kautz et al. 2004; Iivari et al. 2001). Tailored methodologies are techniques to deal with the complexity of the project as they are concerned with how to apply a methodology rather than normatively applying it to the specific project. In such reflective practice, the developer's or project manager's approach to the task, and the tools and methods she uses, are based on her experience and knowledge. But such methodological adaptability is Knowledge-based practices for managing the outsourced project 89 Published by AIS Electronic Library (AISeL), 2011 5 Scandinavian Journal of Information Systems, Vol. 23 [2011], Iss. 2, Art. 4 focused on the development task rather than the organizational context and routines. These reflective practices represent KBPs within the confines of the project. Embedded within organizational procedures and processes is technical knowledge (Mathiassen 1998) that consists of 'instrumental problem solving based on scientific theories and techniques' (Schn 1983 p. 24). Within this context, actors need to experiment and collaborate in order to improve practise and to innovate. This approach facilitates change within an organization. For an organization to change, learning and iteration occurs allowing new knowledge to emerge (Mathiassen 1998). Actors undertake such change by \".... [setting] the problem, we select what we will treat as the things of the situation, we set the boundaries of our attention to it, and we impose on it a coherence which allows us to say what is wrong and in what directions the situation needs to be changed. Problem setting is a process in which, interactively, we name the things to which we will attend and frame the context in which we will attend to them\" (Schn 1983, p. 40). This concept of reflective practice occurs at two levels: within the normal performance of the project and as a complex issue arises. This approach allows an intervention to occur within the project to address complexity by allowing the problem to be framed and resolved. In this instance the focus is on the informal, rather than the formal, organizational practices (Schn 1983; Mathiassen 1998). Emergent issues in ISD can be resolved in different ways as usually there is no rational deterministic right answer (Winter and Checkland 2003). In indeterminate situations, where there are a number of potential solutions, reflective practice can be used to resolve intrinsic issues (Schn 1983). However resolution of issues often requires an organizational and/or political context to be addressed. Reflective practice can address the substantive issue, but contextual issues often need to be considered outside the strict project boundary. This is particularly relevant in outsourced projects where many emergent issues arise due to the complexity of the client vendor relationships. Resolution of such issues requires the problem (or project) to be reframed to take into account the contextual and organizational factors. Problem redefinition or reframing occurs \"when individuals alter their choice among decision alternatives in response to changes in frame of reference of the alternatives\" (Diamond and Lerch 1992 p. 1050). Such reframing is a deescalation process that does not decrease commitment to the project but is a problem-solving approach that allows the issue to be considered outside the confines of the project to map a new course for the project. The new course of action is identified, legitimized, and implemented and commitment to this action is negotiated (Montealegre and Keil 2000). While essentially a problem solving technique, deescalation is an effective learning process that allows participants to understand the issues from a broader organizational and strategic level (Montealegre and Keil 2000). It allows a broader collective knowledge and experience to be brought to bear on the issues and, importantly, provides the necessary authority to resolve the issue. Within the project organization, de-escalation must exist either as a formal or informal process and it must be vested with the necessary authority to resolve the issue. This de-escalation process is also part of the formation of an ad hoc structure outside the confines of the project. KBPs provide the analytical lens to understanding project practices that are deployed to deal with complexity, and intrinsic and emergent issues in order to deliver the project. However such practices are usually considered informal: 'it's what any project manager does' and conse90 Owen & Linger http://aisel.aisnet.org/sjis/vol23/iss2/4 6 Owen and Linger: Knowledge-based Practices for Managing the Outsourced Project quently are not acknowledged for their contribution to the effective management of the project. Significantly, KBPs are not only undertaken within the project boundary to provide necessary flexibility, but are a dominant feature outside the formal project boundary, at a political level, to reframe and reorient the project to meet the needs of an evolving context. Outsourced projects in particular rely on KBPs within and outside the project as well as the integration between these spheres of activities. 3 Research Approach Our empirical research was conducted using an exploratory case study methodology to focus on an ISD project used to deliver organizational change (Marshall and Rossman 1995). 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 approach allows the social and organizational phenomena to be studied in a specific context where \".... 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 focus 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 crosscheck findings (Sabherwal et al. 1998). The study was conducted by observations, background discussions, in-depth interviews, analysis of internal and publicly available documents, and analysis of secondary sources covering internal and external business processes. Observations and initial background discussions with client and vendor 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 focused on the use of the KBPs constructs derived from the literature, and linked them to the socio-technical focus of ISD encompassing people, organization, process, context, technology and artefacts. This framework was also adopted for document analysis and secondary data. The analysis was conducted iteratively throughout the data collection process and facilitated a deepening understanding of the formal and informal processes adopted in the project and the role of KBPs in those processes. 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 include 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. These transcripts and notes taken during the interviews were analysed and coded based on key themes derived from the literature and those themes that emerged during interview. The interviews with our informants focused on their understanding of the project and the changes that occurred over the lifespan of the project. In particular we probed the points of breakdown and disjuncture that required action to change the project. We focused on how they Knowledge-based practices for managing the outsourced project 91 Published by AIS Electronic Library (AISeL), 2011 7 Scandinavian Journal of Information Systems, Vol. 23 [2011], Iss. 2, Art. 4 recognised the need to change something in the project, made sense of that situation, formulated action, and understood the impact of their actions. Where possible, we corroborated their individual viewpoints through secondary sources and publicly available documents. In our analysis, we interpreted the interview data through the lens of KBPs. This allowed us to explore how the generic and abstract constructs of KBPs, derived from the literature, were expressed in specific situations in professional practice. Our analysis also enabled us to elaborate and refine the KBPs constructs on the basis of professional practice. Our interview data focused on significant changes in the project, while our analysis examined the particular situation at these points of breakdown and the reactions to these situations. The reactions were examined with regards to what knowledge was brought to bear, how it related to the situation, and what actions were taken, and how the longer-term impact of those actions affected the project and its management. Our analysis highlights how knowledge that is required to resolve the breakdown is expressed in project practices used in those specific situations. This focus on knowledge contextualised technical skills and project practices in terms of KBPs and the actions were interpreted as an expression of KBPs. 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 was Government audit reports about the Department's project management capability. Document analysis of the vendor's project management and business processes was also conducted. Detailed background discussions with project team members were conducted after an initial analysis of the interviews and document analysis of both organizations. As a consequence, two follow-up in-depth interviews were conducted with the vendor'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 this process. Documentary data was collected during and after the interviews, verifying the interviews and adding to the richness of the case. 4 Case Study The case presented in this paper is a study of an ISD project involving outsourcing the implementation of an enterprise project management software application at an Australian Government Department. The 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 socio-technical nature of ISD. As an outsourced project, there are two parties (actors) involved in the implementation process - the commissioning authority (client) and the outsource provider (vendor). Both will manage their respective organizational responsibilities for the project and will need to negotiate acceptable resolution to emergent issues. 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 92 Owen & Linger http://aisel.aisnet.org/sjis/vol23/iss2/4 8 Owen and Linger: Knowledge-based Practices for Managing the Outsourced Project present the case from the perspective of each of the three actors. The focus in our study was to understand the conduct of the project from the client and vendor's perspective and also to study the interaction between them during the implementation process. Hence the project also became an actor. This approach allowed us to gain insight into how each actor approached emergent issues, gained shared understanding of these issues and the negotiated resolution of these issues during implementation. 4.1 The Client - The Department The study was conducted in a large Australian Federal Government Department (the Department), comprising a number of Divisions, that outsourced the rollout of an enterprise project management software tool to an IS 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. To do this, the Department has branches located throughout Australia. 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. The Department manages 140 different products on behalf of 25 policy departments. The policy departments purchased services through agreements called Business Partnership Agreements. These agreements provided details of the services, funding, arrangements and performance outcomes, and detailed the scope of the work to be carried out. Internal initiatives are also implemented by the Department to support their strategic plan in terms of themes, strategic priorities and core business processes. 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. Divisions support the strategic themes for the Department of strengthening customer focus, building a networked organization, and building capability for government. Given the different sources of the Department's projects, the portfolio is critical to the delivery of government policy, as shown in figure 1. After each government budget, the Department has to adjust its portfolio of projects to accommodate the implementation of new budget measures. As government mandates the effective implementation dates via legislation, the dates are immovable. Such measures increase the difficulty of delivering projects on time and within budget to an acceptable quality. Projects that implemented budget measures are specified by the client agency, while internal measures are defined in a business case. All Divisions in the Department were involved in projects that range from IT replacement initiatives to delivery of budget and legislative initiatives, people and planning capability, customer service and service delivery. By their very nature these projects incorporate or enable changes in organizational structure and political and administrative arrangements. Resources to deliver these projects are finite and if stretched to capacity could increase the risk of the project not being delivered. This created a need for the Department to be able to manage their projects at an enterprise or portfolio level to enable them to effectively manage and appropriately allocate resources. Knowledge-based practices for managing the outsourced project 93 Published by AIS Electronic Library (AISeL), 2011 9 Scandinavian Journal of Information Systems, Vol. 23 [2011], Iss. 2, Art. 4 Project Sources Commonwealth Budget direct to Dept XYZ Policy Departments' funded projects Strategic Project Management Set up projects Monitor projects Individual Project Management Project Project Project Internally funded initiatives Review and adjust projects Project Figure 1. The Context of Projects in the Department Given the complex environment, it was recognized that the Department needed to assess projects not only from a single project perspective but also at an enterprise level. This would allow different perspectives of the projects to be delivered - from an investment, resource and business-impact perspective. Given the number of projects undertaken at any one time, the Department recognized that they needed to identify and manage resource constraints allocations, project interdependencies, and risks. An enterprise view of projects aims to provide a transparent link between the original project scope and the government/client's expectations, while providing clear timeframes, schedules and interdependencies. Such a tool would facilitate project scheduling, project tracking, and project financial and human resource management. An enterprise level project management tool was required for this type of reporting to occur. In addition, this technology allowed a top-down approach to managing resources (financial, human and material). Initially the Department tendered a $1 billion outsourcing contract for their IT systems however, it was abandoned as they saw that the risk was too high. Consequently they pursued a strategic sourcing policy and formed partnerships and outsourcing arrangements with private and public sector organizations to develop innovative and cost effective service delivery capabilities. 4.2 The Provider - PMC PM International is a global company based in the USA, where they research, develop, and market software for enterprise project management. The software is sold internationally in 128 countries by authorized resellers. PM Consulting (PMC) had been the Australian and New Zealand reseller for 19 years. PMC is a privately owned, locally run organization, with a profes94 Owen & Linger http://aisel.aisnet.org/sjis/vol23/iss2/4 10 Owen and Linger: Knowledge-based Practices for Managing the Outsourced Project sional service culture and informal, but developing, business processes. The background of the principals is predominantly engineering, thus leaning to rational decision-making processes. The management of PMC is a matrix structure reflecting the regional and functional business lines. A board of management, consisting of executive and non-executive members, govern the strategic direction and finances of PMC. PMC's employees have skills in managing and delivering ISD projects, implementation of enterprise project management tools and integration with other IT systems. The company employs approximately 20 consultants (implementation and technical) throughout Australia and sourced contract staff from their professional networks as required. PMC is 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 sit at the Head Office level. The Project Enterprise Project Management Software (PEPMS) allows scheduling, project management processes, and resource management to be viewed at the enterprise level. A range of industries use PEPMS including architecture, engineering and construction, government, utilities, IT, oil and gas. In Australia, PEPMS has been implemented in both the private and public sector in organizations covering government departments, financial services, oil and gas, engineering and construction. The reason customers implement PEPMS is to view an enterprise level of projects and programs providing visibility, coordination and transparency in project delivery. PMC implemented PEPMS in organizations through projects. They found that clients implement an enterprise project management software tool because they are experiencing a number of problems, such as not being able to manage processes, projects having become uncontrollable, or the need for project management processes. PEPMS is usually implemented by a client as a means to manage resources at the enterprise level, and manage the benefits and interdependencies of projects. 4.3 The Project - PEPMS The Department initiated a project, based on an enterprise-level project management tool, to enable visibility of resource commitment and demand, and to enable projects to be viewed at the portfolio, program and project level within the IT Division. From the project management perspective, the Department used project management software to support its IT and business initiatives. However, the Department recognized that it had to improve the use and integration of IT tools to support project managers and allow projects to be managed at the enterprise level. One of the benefits of the PEPMS project was to allow better prioritization of work and more informed investment decisions. Another objective of the project was to improve resource planning and management information that linked actual effort, or work completed, with planned work. While the initial scope was to implement PEPMS in the IT Division, there was no formal scope management and the scope and project requirements were broadened in the first few months of the project to include both the internal and customer-facing divisions. This change of scope was due to a senior management decision to support good strategic project management. As a result, it was felt that the Department would improve the quality of project performance data by being able to measure actual data, improving its ability to effectively meet commitments Knowledge-based practices for managing the outsourced project 95 Published by AIS Electronic Library (AISeL), 2011 11 Scandinavian Journal of Information Systems, Vol. 23 [2011], Iss. 2, Art. 4 by reporting against actual data. There was also a requirement for more efficient data sharing between systems by integrating PEPMS with the Department's Enterprise Resource Planning (ERP) systems. This was to be facilitated by allowing financial and resource data to be exported from PEPMS to the ERP system. As other Divisions were included in the project, the project scope and requirements changed in terms of configuration requirements and additional functionality. The initial duration of the project was eight months, but was extended to two years to cover the extended scope. As requirements changed and rollout occurred from the IT Division to other business units, the budget was increased. Each time the PEPMS software was rolled out to another Division, additional budget had to be obtained from the Department's Investment Committee. The final budget for the project was $2.7 million, of which 78% covered salaries, administration and contractors and 22% covered hardware and licenses. The PEPMS project involved twenty people: an executive sponsor, seven project board members, a business owner, a project owner, and the project team. The project team consisted of 10 members: the project manager, a project administrator, technical staff, and consultants from PMC. The Department's project team members provided IT coordination, business analysis, project administration and scheduling activities. Initially, representation 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 PEPMS and the ERP. As requirements emerged in the Business Divisions, additional PMC consultants were deployed for short-term assignments to meet the timeline. 5 Findings While the PEPMS project did not appear to be a complex task, it became complex very quickly as it was used, in a political sense, to drive organizational change. The impact of standardization of procedures and reporting, as well as the centralization of control over projects, was facilitated by the implementation of the new application. Divisions within the Department resisted the rollout as users did not understand why they had to use a new system; they assumed that the existing project management systems were sufficient and allowed them to manage projects effectively and efficiently. Project managers and users in Divisions were only concerned with the project they were working on and did not understand the imperative behind viewing projects at an enterprise level. In one service delivery Division, the Senior Manager did not see the benefit in the new system. Even though the project managers and schedulers in his Division wanted to use PEPMS, its implementation in that Division was abandoned. The system was foisted upon them whether they wanted to do it or not. They had to do it as the configuration on the earlier system was prone to breaking down, preventing the Department from performing internal cost recovery. (PMC Lead Consultant) 96 Owen & Linger http://aisel.aisnet.org/sjis/vol23/iss2/4 12 Owen and Linger: Knowledge-based Practices for Managing the Outsourced Project To address such resistance, the project team, comprising both Departmental and PMC staff, devised a strategy to identify Champions in each division to assist with the rollout and improve usage of the tool. These Champions were not part of the project team but were selected because they were both key stakeholders within the Divisions and they were recognised as being able to influence the use of PEPMS within their Divisions. We picked out Change Leaders or Champions in the business ... a person who was receptive to change and using PEPMS ... they became a centre of excellence and provided a decentralized area of systems expertise and support. (PMC Lead Consultant) The integration of PEPMS with other technology was not in itself complex. However it became complex when PMC recognized that their PMC Integration Consultant did not understand the customer requirements. The consultant developed what he thought the Department required and his assumptions about what the customer wanted. 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) In an effort to resolve the confusion and reduce the complexity, the PMC Lead Consultant removed the issue from the confines of the project. He organized an initial meeting to develop a shared understanding of what was actually required in the context of the changed and expanded scope of the project. Participants in the meeting included PMC's Professional Services Director, the Lead Consultant and Senior Departmental Officers (project board members) who had a strategic perspective of the overall project and had the authority to make commitments to any actions decided by the meetings. Subsequent meetings formulated and negotiated an agreed set of requirements. This action highlighted the volatility of the project and led to the establishment of a weekly meeting between Department representatives and PMC to deal with all emergent issues. These meetings assumed explicit responsibility to develop a comprehensive understanding of the issues, assign an owner to each issue and specify actions that would ensure that the issues were resolved within the normal project boundaries. PMC's approach to implementing PEPMS was to use a methodology focusing on software implementation and systems integration. The management and delivery methodology was based on the Project Management Institute's PMBOK (2008). However, the methodology was not followed prescriptively (Kautz 2004). Application of the methodology was tailored to the client site based on the experience of the consultants, the size of the client, and the customer budget. The Lead Consultant's professional experience allowed him to assess how to amend the methodology and use it flexibly. In some cases the implementation might be two or three licenses for a small company, in which case you would typically do most of the steps, but they wouldn't necessarily be structured as those kind of, as discrete phases. So you would still go through it, but you wouldn't necessarily identify them in your plan, in your project plan, as discrete phases ... I would basically say that we probably tend to use our methodology as a guidance more than \"you shall do everything on this\" and to a certain extent sometimes it is driven Knowledge-based practices for managing the outsourced project 97 Published by AIS Electronic Library (AISeL), 2011 13 Scandinavian Journal of Information Systems, Vol. 23 [2011], Iss. 2, Art. 4 by customer budget as well. Sometimes they may say well, we are not prepared to pay for doing a post-implementation review. In which case, we would probably do a follow-up assessment ... We follow the process, but we wouldn't necessarily follow every step ... (PMC Professional Services Director) PMC approached the PEPMS project from the position that their methodology would be used as it was the prescribed methodology for implementing PEPMS software in organizations. On the other hand, the Department had developed a project management methodology also based on the Project Management Institute's (2008) PMBOK. The methodology was developed to reflect the context of the Department's projects, and operational requirements, while at the same time linking the methodology to other business processes. Since a large number of the Department's projects had a significant IT component to support service delivery throughout Australia, PRINCE2 (OGC 2009) was introduced to manage the IT component of projects. The PEPMS's Project Management Plan stated that the Departmental Project Management Methodology would be followed. It also stated that as the project was changing business processes, and integrating with IT infrastructure, an adaptive methodology would be followed. However, this didn't occur because \"... we used a methodology based on PRINCE2 and PMBOK that was adapted and applied based on my experience and knowledge\" (the Department's Project Manager). Moreover, the Department's Project Manager only used the methodology for reporting purposes. Once the initial Project Management Plan was completed, and approved, it became a static document and was not updated. Neither the Department's nor PMC's methodologies were followed prescriptively. The two methods were not consciously reconciled and adapted, rather team members adapted and applied components of the methodology to the situation. This was based on their understanding of the context and their experience. This was particularly prevalent as requirements changed and emerged during the project. Neither methodology allowed for the fact that requirements could emerge nor could they cope with the scope changing throughout the project lifespan. An informal methodology emerged that drew on both methodologies and the experience of PMC consultants and Departmental staff. The Department project staff thought that the Department's project management methodology was being applied and followed. The Integration Consultants thought that they were using PMC's methodology. It was PMC's Lead Consultant who blended the Department's and PMC's methodologies. This methodology was used for project delivery in terms of requirements gathering, configuration and providing data for project reporting. The understanding and knowledge of the situation, as well as professional experience, influenced what aspects of the methodologies were applied and how they were applied. There was no formal reconciliation, either tacit or explicit, as to what methodology should be applied; rather adaptation was a situated action. Methodologies were adapted ... I did what I thought was appropriate for the situation as most people do ...[PMC's methodology] was not prescriptively followed. I did not use the templates, but I applied the principles in terms of documenting user needs and translating them into a configuration document. (PMC Lead Consultant) While methodological flexibility is well documented in the IS literature (Bansler and Bodker 1993; Truex et al. 2000; Fitzgerald 2000; Madsen and Kautz 2002; Madsen et al. 2006) 98 Owen & Linger http://aisel.aisnet.org/sjis/vol23/iss2/4 14 Owen and Linger: Knowledge-based Practices for Managing the Outsourced Project the case study presents another level of complexity in that more than one methodology has to be manipulated simultaneously. This complexity is further compounded by multiple reporting lines that require project performance data to be presented in ways that are consistent with the methodology presumed to be in use and often mandated by governance structures. In the outsourced project case, these structures are overlayed with legal framework and its inherent punitive measures for noncompliance. In our case study, the usual knowledge and experience of the project manager is not sufficient to achieve methodological flexibility. An overt understanding of the need to, as well as the practices that, adapt the methodology needs to be negotiated and authorised outside the boundary of the project. Technical issues arose during the PEPMS project relating to system testing, implementation and functionality. The PEPMS software did not do everything that was specified in the initial requirements, nor in the requirements that emerged during the project. However, where possible, technical and functional issues were addressed using existing project management tools and techniques that were adapted to the situations. There was nothing unusual or circumstantially unique about the occurrence of these issues. They arose for the same reason that issues arise in any project - that is, as projects enter the delivery stage, the forces of change (as is the nature of projects) reveal and cause differences between the current environment and the new. (The Department Project Manager) An example of such an issue was the production of a weekly time sheet that the PEPMS software could not generate. This was seen as a major technical issue by the Department as it did not meet a major requirement of the project. This was resolved by the PMC Lead and Technical Consultants developing an informal workaround to remove resources, such as people working on the project, from a timesheet. They then used internal PMC processes to formally document the issue and sent it to the parent company in the USA to be included in the next formal updated release of PEPMS software. Other technical issues could not be resolved with workarounds as it was deemed too costly for PMC. These issues appeared to be minor for PMC, but the Department saw these issues as significant and therefore the implementation was not meeting their requirements. These issues were passed to PMC's US Headquarters to resolve in the hope that they would be included in the subsequent releases of the PEPMS software. The resolution of technical issues highlights the differing perspectives from which emergent issues are understood and the need to negotiate a resolution that meets divergent objectives. While such issues are not unique to outsourced projects, they are exacerbated by legal arrangements that govern the outsourced project and the lack of an organizational authority to resolve such issues. An outsourced project needs processes so that actors can collectively understand the issues and make sense of them, in the context of the scope and objectives of the project, and negotiate actions that meet those objectives. The alternative is legal action and IS/IT is already fast becoming the most litigated profession. Knowledge-based practices for managing the outsourced project 99 Published by AIS Electronic Library (AISeL), 2011 15 Scandinavian Journal of Information Systems, Vol. 23 [2011], Iss. 2, Art. 4 6 Discussion The nature of ISD requires both formal approaches, usually expressed as methodologies, and the application of the knowledge and experience of the actors involved in the construction of the artefact. This combination is particularly pertinent when the ISD project is understood in terms of social and organizational processes and the need to resolve emergent issues that are an inevitable aspect of ISD. As our case study has shown, in outsourced projects these processes are further complicated by the need to accommodate at least two independent organizations, each with their own imperatives, and the legal framework that governs the conduct and performance of the project. Our focus in this paper is how the project resolves emergent issues and in particular the processes that exploit knowledge and experience to deliver the project. The concept of KBPs can address the activities that underpin the processes used to resolve emergent issues. The common characteristics of KBPs are that they are based on the knowledge and experience of the actor and their ability to apply this knowledge and experience to uncertain, ambiguous, complex and emergent phenomena in novel and often undefined situations. In the case study we have shown KBPs as expressed in their concrete manifestation within the project. For example, tailoring and blending the methodologies in the PEPMS project is an expression of a number of KBPs, even if they are not explicitly acknowledged as such. But the significance of this view is the social and organizational processes that need to be established in order to legitimise the KBPs. What we have found in our case study of the outsourced project is that this process of legitimisation occurs at two levels. The first is within the boundaries of the project itself that closely resembles processes that characterise ISD in general and includes adaptation of methodologies. The second level requires the formation of structures outside of the project boundaries that can address emergent issues at a strategic level, combined with the authority to resolve these emergent issues. Moreover, these two levels interact with actions sanctioned outside the project boundary being transformed into processes within the project boundary. 6.1 Resolving emergent issues within the boundaries of the project Standard prescriptive methodologies to manage projects cannot always deal with the emergence of intrinsic issues. The standard methodology employed in the PEPMS project could not deal with the complexity of the project. As issues emerged, the project team adjusted methods to suit the situation. This tailored methodology enabled actors to effectively address project complexity in the management, design, deployment, and implementation process. These emergent approaches overcome the limitations of standard methodologies, but remain informal. In the outsourced project, emergent approaches are not explicitly identified in the contractual arrangements between the parties and are not documented nor included in the organizational routines and methodologies of either the vendor or the client. 100 Owen & Linger http://aisel.aisnet.org/sjis/vol23/iss2/4 16 Owen and Linger: Knowledge-based Practices for Managing the Outsourced Project In outsourced projects both parties recognise that there is a need to adjust and/or synchronise their methods and approach to their ISD project. This usually occurs as a negotiation between the parties within the confines of the project and results in a blended methodology used by both parties. The tailored or adjusted methodology is based on the actors' experiential knowledge, the context of the project, and situational factors and enables the project team to respond to unforeseen and unanticipated aspects of the project. The negotiations around tailored methodology are based on KBPs that enable the actors to recognise the emergent issues, understand the significance of the issues from the perspective of each organization, make sense of the issues in terms of their impact on the project and apply systems thinking that implicitly draws on the experience of each actor. A key aspect of these processes is an underlying understanding, recognition and agreement between the parties that the emergent issue can be resolved effectively within the boundary of the project even if the resolution does push the boundaries. In an outsourced project, the boundary is usually formalised by contractual agreement and this limits the flexibility of each party. This approach to ISD projects implicitly assumes a degree of flexibility that actors have to tailor formal processes and engage in informal processes that draw on the knowledge and experience of the actors. Thus, in practice, the traditional, normative and deterministic methods and tools of project management are complimented by KBPs in order to create an effective approach to the management of ISD projects. Yet while these complimentary sets of practices are performed within the project boundary, the use of KBPs remain hidden. Reporting of the project is still executed in terms defined by the normative methodology while actors draw on the authority of these normative methods and tools to explain and report their activities. Additionally, with outsourced projects there is an imperative to resort to normative methods to legitimise project activities as the legal frameworks that govern the outsourcing relations are themselves expressed in those terms. Thus the flexibility inherent in project management is governed by the extent to which flexible practices can be legitimately accommodated within the legal framework of the outsource contract. 6.2 Resolving emergent issues outside of the boundaries of the project Where an emergent issue cannot be negotiated within the confines of the project, an additional structure outside the project is formed to address and resolve emergent issues. This structure has the appropriate authority and knowledge to deal with the issues as they need to be reconceptualised within a broader strategic context. Emergent issues that need to be resolved outside the project boundary are those that challenge the definition of the project and are often due to the contextual nature of the project - unknown technical solutions, changing requirements and/ or environments, resistance to change and stakeholder agendas. The structure usually involves stakeholders who are not necessarily directly involved in the project but have the organizational responsibility for the outcomes, have access to the strategic thinking within their organization and are able to exercise the necessary power to resolve the emergent issue. In this sense the stakeholders bring specific knowledge and experience that is not usually available to the project, and explicitly engage in KBPs to resolve the emergent issues. Within this structure, it is recognized Knowledge-based practices for managing the outsourced project 101 Published by AIS Electronic Library (AISeL), 2011 17 Scandinavian Journal of Information Systems, Vol. 23 [2011], Iss. 2, Art. 4 that the group is working at a meta-level that is explicitly outside the normal boundaries of the performance of the project. Within this authoritative structure, a de-escalation process is followed that allows for reframing and re-scoping of the project. Montealegre and Keil (2000) use the term de-escalation to refer to a process where commitment to the current project definition is reduced (de-escalated), and commitment to the project is aligned with the definition that emerges from the deliberations that reframe and re-scope the project. De-escalation occurs in two forums: at a formal level and an informal level. De-escalation at the informal level recognizes and exploits the expertise of the actors who form the group in order to resolve the issues in an innovative manner. Such exploration and innovation is clearly knowledge based and requires both a strategic understanding and project expertise. At the formal level the resolution proposed at the informal level is sanctioned and the contractual or legal ramifications of the proposed actions are resolved. The formal level also specifies how proposed actions will be translated back into the performance of the project. This translation requires KBPs that are grounded in a deep understanding of project management and the specific context of the project. A feature in the PEPMS project was the discrepancy between the stated aim and implied agenda of the Department that contributed to the changing requirements throughout the project. PMC, as the outsource IS provider, only became aware of the discrepancy after the contract was awarded. This discrepancy became evident to all parties as a gap in the scope made the project unbounded. From the Department's perspective, the resolution of this discrepancy was to renegotiate the contract terms. One consequence of the discrepancy was that PMC lacked an understanding of what was needed, in terms of the overall requirements, the areas that required PEPMS and when PEPMS was required. To resolve the different perspectives between the contracted project and what the Department expected, the issue was de-escalated to a group comprising of the Department's Project Steering Group and PMC's Senior Management Team. This group reviewed the contracted aim, articulated the Department's objectives and negotiated a revised scope of the project, the cost, resource requirements and the schedule. This reflects Tiwana's (2003) concept of asymmetric knowledge partitioning where PMC needed to gain a greater knowledge and understanding of the Department's requirements. The discrepancy between the aims and agenda of the PEPMS project meant that the issue had to be moved outside of the confines of the project so it could be considered from a more strategic understanding of the situation. Consideration of this issue within this new forum, outside the confines of the project, allowed both parties to learn about and understand the nature of the project and make sense of the impediments faced by the project. This forum created a venue for exploration, reflection and action. These KBPs rely on a different knowledge base and express meta-level objects that will inform project performance and its management. In the PEPMS project the negotiations were delegated to a senior member of PMC's Management Team and the Department's Project Manager, who both had the (delegated) authority to renegotiate the project definition. The weekly meeting, established to resolve this issue, was quickly expanded to deal with all emergent issues. These meeting assumed explicit responsibility to develop a comprehensive understanding of the issues, assign an owner to each issue and ensure the issues were resolved. These meetings were then formalised as an integral part of the governance of the project. This demonstrates how KBPs, initiated outside the project boundary, 102 Owen & Linger http://aisel.aisnet.org/sjis/vol23/iss2/4 18 Owen and Linger: Knowledge-based Practices for Managing the Outsourced Project are operationalised within the project and how the project accommodates KBPs that reframe the understanding of the project. Another issue resolved outside the boundaries of the project was the resistance to the PEPMS project at the divisional level. The governance meetings authorised the PMC Lead Consultant to appoint Champions who would negotiate the use of PEPMS with their respective Divisions by convincing them of its value. The impact of this action was that it led to a broader understanding of the project and its organizational ramifications while it also improved the Champions' and project teams' understanding of each Division's requirements. This initiative focuses on the KBPs that are directed at intangible social outcomes to facilitate project performance. It is also worth noting the interaction of the meta-level KBPs that considered the issue of resistance and the \"soft\" approach to resolving the issue based on KBPs to facilitate knowledge flows and to build mutual understanding. The Champions and the senior project executives gained a deeper understanding of the issue of resistance and were able to address this issue directly rather than having to argue about project performance as a surrogate for resistance to change. On the other hand the Champions