PROJECT MANAGEMENT THEORY MEETS PRACTICE

Tove Brink Pekka Buttler Helge Søndergård Hvid Theis von Moos Charles Møller Jan Pries-Heje Eva Riis Vibeke Kristine Scheller Jesper Schlamovitz Nazli Shahim Per Svejvig Gitte Tjørnehøj The book presents a selection of state-of-the-art research, theory and models based on studies of project management practice. Topics include: Self-organizing agile management teams How Scrum influences the temporal environment Hidden goals and what you can do Frontloading your project Metaphors used to communicate in the project Maturity in project-portfolio management Value generation in projects Heroes as catalysts in projects Project Management Theory Meets Practice is published in cooperation with the Danish Project Management Association. ISBN: 978-87-7867-461-6 PROJECT MANAGEMENT THEORY MEETS PRACTICE Andreas Saxkjær Jespersen Project Management Theory Meets Practice contains the proceedings from the 1st Danish Project Management Research Conference (DAPMARC 2015), held in Copenhagen, Denmark, on May 21st, 2015. Jan Pries-Heje and Per Svejvig (eds.) AUTHORS Jan Pries-Heje and Per Svejvig (eds.) PROJECT MANAGEMENT THEORY MEETS PRACTICE Jan Pries-Heje is a Full Professor in Information Systems at Roskilde University, Denmark. He is currently head of a research group on IT innovation and head of Studies for Master in Project Management and Process Improvement. Jan holds M.Sc. and Ph.D. degrees from Copenhagen Business School. He has written more than 250 papers and books in International Conferences and Journals. He has studied and written about internet speed projects, agile projects, estimation and risk management, enterprise architecture, IT strategy and maturity. Further, Jan has more than 20 years of experience working as Project and Research manager and doing research in IT and Project Management. For the last 5 years he has been active in the Research Programme of the Danish Project Management Association. Per Svejvig is Associate Professor at the Department of Business Administration, Aarhus University. His research interests are in the areas of project management and outsourcing, implementation and use of enterprise systems, managing IT-enabled change, and interplay between technology and organizations. He has published in International Journal of Project Management, Journal of Information Technology, Scandinavian Journal of Information Systems, Journal of Information Technology Case and Application Research, International Journal of Enterprise Information Systems, International Journal of Business Information Systems, International and Journal of Services Technology and Management. He holds a PhD in Enterprise Systems from Aarhus University. He has more than 25 years of business experience as a manager, project manager and consultant. He is a Certified Senior Project Manager (IPMA level B) and is active in Danish Project Management Association. 9 788778 674616 67461 Project Management OMSLAG sort/hvid forfatter 26 MAR.indd 1 14/04/15 11.36

Project Management Theory Meets Practice

Jan Pries-Heje and Per Svejvig (eds.) Project Management Theory Meets Practice

Jan Pries-Heje and Per Svejvig (eds.) Project Management Theory Meets Practice 1. edition 2015 Roskilde University Press 2015 COVER: SL grafik (slgrafik.dk) TYPESET: SL grafik PRINT: Specialtrykkeriet Viborg A/S TRYKT BOG ISBN: 978-87-7867-461-6 E-BOG ISBN: 978-87-7867-466-1 Published in cooperation with the Danish Project Management Association Roskilde University Press Rosenørns Allé 9 1970 Frederiksberg C info@samfundslitteratur.dk samfundslitteratur.dk/ruforlag All rights reserved. No part of this publication may be reproduced or used in any form or by any means graphic, electronic or mechanical including photocopying, recording, taping or information storage or retrieval systems without permission in writing from Roskilde Universitetsforlag.

Foreword DAPMARC 2015 5 FOREWORD DAPMARC 2015 This is something special! This book contains the Proceedings for the First Danish Project Management Research Conference (DAPMARC), held in Copenhagen, 21 May 2015. It is always exciting to start something new and innovative. But this time we hope it will make a lasting impression and, therefore, that it will be the first book in a series of future DAPMARC Proceedings. DAPMARC was born out of a Research Initiative that the Organization Dansk Projektledelse started years ago. The two of us (Per Svejvig and Jan Pries-Heje) have been meeting regularly within this initiative for the last 4-5 years. About a year ago we had a discussion about how we could better integrate theory with practice one more time. When we say one more time it is because we succeeded in publishing a state-of-the-art book with Danish research on Project Management in 2013 (Pries-Heje, Jan (ed.) (2013). Project Management Multiplicity: Current Trends. Samfundslitteratur). But now the idea was to integrate a research conference within the Project Symposium that Dansk Projektledelse has been organizing since 1985. We thought that was an excellent idea and grasped the opportunity to do so and here is the book. Following this line of thought we want to thank Morten Fangel and Jesper Garde Schreiner, both from Dansk Projektledelse, for their cooperation. Without their backing and willingness to think in a new way about the Project Symposium this book and DAPMARC would never had happened. The process bringing us to this book started in October 2014. We produced a call for papers and initiated an EasyChair submission and reviewing page. In the call we identified the theme of the Conference to be Theory Meets Practice in Projects, and we asked for submissions within the following areas of project management: Situational project management Innovation, creativity and entrepreneurship Strategic management of portfolios, programs and projects Project management office

6 Foreword DAPMARC 2015 People, leadership and professionalism Stakeholder management Agile project management Leadership, governance and decision making Collaboration, trust and relationships Project-based organizations and networks We received 12 submissions. All 12 were sent out to at least two reviewers from the program committee, consisting of: Anita Mac, Associate Professor, Roskilde University Charles Møller, Professor, Aalborg University Eva Riis, Researcher, Southern Danish University Jacob Nørbjerg, Associate Professor, Aalborg University and Copenhagen Business School Anita Friis Sommer, Researcher, Aalborg University Kasper Edwards, Senior Researcher, Danish Technical University Constance Elisabeth Kampf, Associate Professor, Aarhus University Peter Axel Nielsen, Professor, Aalborg University Ivan Aaen, Associate professor, Aalborg University Pernille Kræmmergaard, Professor, Aalborg University and The IT University of Copenhagen Lene Pries-Heje, Associate Professor, The IT University of Copenhagen Sara Grex, Assistant Professor, Danish Technical University Jesper Schlamovitz, Assistant Professor, Roskilde University We want to take this opportunity to thank everyone in the Program Committee for their excellent and insightful reviews. We are certain that all authors benefitted significantly from the high quality of the reviews. While the reviews were carried out we contacted potential publishers. We wanted to publish with a publisher listed in the Danish Bibliometric Research Indicator we had said that in the call for papers and were certain that it was a strong motivator for the researchers submitting papers. Roskilde Universitetsforlag seemed very appropriate as Roskilde Universitet is one of the Universities in Denmark that are most engaged in Project Management Research. We want to

Foreword DAPMARC 2015 7 take this opportunity to thank Annette Kjølby who represented the publisher for her excellent work and responsiveness. In the beginning of February we The Editors met to look at all the reviews. In a few cases we decided that we needed to do one more review ourselves. But in all cases we wrote an Editorial Report with our decision on whether to accept or reject the paper. The accept or reject decision was hard to make. We had nine papers of sufficient quality with at least one reviewer positive about the paper at this point. Nevertheless we decided to accept eight papers for this book, based on what fitted the theme Theory Meets Practice in Projects best. Authors were then given three weeks to cope with all the review and editorial comments and on the last day of February we gathered all the papers, added this foreword, and thereby had this book. As Editors of the book, and as General Chairs and Program Chairs for DAP- MARC, we are proud to present a book of such high quality. We hope you our reader will enjoy the content now and for many future years. Jan Pries-Heje and Per Svejvig

8

CONTENTS Foreword DAPMARC 2015 5 1. Are Heroes All We Need? The New Role of the IT Project Manager 11 Gitte Tjørnehøj, Andreas Saxkjær Jespersen and Theis von Moos 2. Fast or Smart? How the Use of Scrum Can Influence the Temporal Environment in a Project 39 Vibeke Kristine Scheller, Jan Pries-Heje and Helge Søndergård Hvid 3. Hidden Goals in Projects: A Qualitative Exploratory Study of Their Occurrence and Causes 61 Pekka Buttler 4. Frontload in Complex Project Program Management to Aim for Lifetime Sustainability of Offshore Windmill Parks 73 Tove Brink 5. Metaphors in Projects An Overlooked X-Factor 87 Per Svejvig 6. Bridging Gaps between IT and Business: An Empirical Investigation of IT Project Portfolio Management Using Process Mining and P3M3 Maturity Model 101 Nazli Shahim and Charles Møller 7. Governance of Projects and Value Generation in Project-oriented Organizations 117 Eva Riis 8. Theory Meets Practice: Practical Implications of Process Theory in Project Management 139 Jesper Schlamovitz

PROJECT MANAGEMENT THEORY MEETS PRACTICE 11 1. ARE HEROES ALL WE NEED? THE NEW ROLE OF THE IT PROJECT MANAGER ARE HEROES ALL WE NEED? THE NEW ROLE OF THE IT PROJECT MANAGER Gitte Tjørnehøj, Aalborg University, Denmark, gtj@dps.aau.dk Andreas Saxkjær Jespersen, Bankdata, Denmark, andreas.saxkjaer@gmail.com Theis von Moos, Aalborg University, Denmark, theisvm@gmail.com ABSTRACT More and more software firms adopt agile methods into their practice to become more flexible and increase their speed to market. To get the best from both worlds they often choose to balance agility with traditional approaches. This complicates the job for the project managers especially. This paper identifies motives, opportunities and challenges for organizations to balance and categorizes types of balancing as the basis for investigating the new project manager role of balanced systems development. It builds a theoretically based framework of the role of the project manager when balancing and renders it probable through two distinct different case studies one of a born-agile organization introducing traditional practices and the other of a traditional organization introducing agility. The paper describes theoretically and empirically based complexity and overload of the new project management role. It identifies a new beneficial shallow type of balancing and suggests solutions in line with this. An alternative solution is to form self-organizing project management teams to decrease the load on the individual and increase the pool of skills and reflections in the management of projects. Keywords: Balancing, Agility, Traditional Systems Development, Project Managing, IT Project Manager, Boundary Spanning, Ambidexterity, Overload, Stress, Shallow Balancing, Self-Organizing Project Management Team INTRODUCTION Systems development practice is under transformation to meet new demands caused by the increasing demand for information systems in business, government and society. Rapid growth in use areas, new technologies and challenges of

12 Are Heroes All We Need? The New Role of the IT Project Manager technical integration, customer knowledge and expectations has created a rapidly changing and very demanding market for software firms. Pampered customers want high quality, inexpensive, useful and integrated software for everything and they want it now. This, together with an expanding global software market, puts the firms under pressure to increase their adaptability, flexibility and speed to market (Baskerville et al. 2011). Many newly formed firms are created to be good at exactly that, while established firms often struggle to match the market. Traditionally, the challenges of software development have been complexity and quality, which has been handled through the standardization of comprehensive processes prescribing the appropriate activities, tools and artifacts needed in these professional software practices. The Rational Unified Process (Kruchten 2004) and CMMI (Humphrey 1989; McFeeley 1996; The CMMI product team 2001) are high-profile examples of these approaches that are commonly called traditional, disciplined or plan-driven, because of their emphasis on planning and control. Most professional software firms have organized their systems development practice in accordance with these principles, with more or less successful results. That was until the recent wave of agility. The traditional principles go well with a centralized, top down managed and rather bureaucratic company culture that can be argued to fit better in the late industrial age (Rose et al. 2008). Thus many firms fight to overcome the new challenges of systems development by new means, as the old way has proven insufficient. Agile methods promise flexible, efficient and effective systems development (Beck et al. 2001; Beck and Boehm 2003), which seem to be exactly what the software firms need. But still the virtues of traditional software development appear to be somewhat beneficial. Recent research concludes that most firms strive to reconcile the traditional approaches with agility into new, more suitable, practices (Magdaleno et al. 2012). Apparently it is a post-agility era, where balancing agility and the traditional approaches is the new trend of systems development, even for the born-agile firms (Baskerville et al. 2011). Introducing agile methods in traditional practices, or vice versa, is a difficult mission (Baskerville et al. 2011; Boehm and Turner 2003a). The complexities at all levels, and in all relations, increase as two disparate worlds of assumptions, methods, practices and tools needs to be handled, integrated and understood by all involved. This may cause difficulties and Baskerville et al. (2011) emphasize that boundary spanning by key persons is important to integrate the distinct social worlds of balancing. This research finds that the key persons in the boundary spanning could easily

PROJECT MANAGEMENT THEORY MEETS PRACTICE 13 be the IT project managers and that they play a significant role in eroding the experienced boundaries. We investigate how the increasingly challenging and complex situation affects the IT project managers. As most software development has the nature of uncertainty it is organized as projects, giving the project manager a key position in the production of the software managing the people, the processes and the products. The question is what role the project manager plays in software firms when balancing agile and traditional software development? Most published research on balancing focuses on the aspect of processes, for example, investigating attempts to combine practices from CMMI/ISO, XP and Scrum. Our research sheds light on the challenges and opportunities at the organizational and project level as suggested by Magdaleno et al. (2012), by developing a theoretical framework for understanding the (new) role of the IT project manager. The framework is developed from a literature study and rendered probable through two small but distinct different case studies one traditional software firm striving to adopt agility and a born-agile firm adopting certain traditional practices to consolidate their business. The paper is structured as follows: First the research approach is described, then a section on balancing agile and traditional systems development provides an overview of the existing knowledge on why and how to balance, before the framework focusing on how balancing influences the role of the project manager is presented and argued. The case analysis presents the results from the two case studies, and the cross analysis discuss what parts of the framework are rendered probable by the cases and zooms in on the role of the project manager for comparison. The discussion elicits implications for practice and the conclusion sums up, answers the research question and suggests further research. RESEARCH APPROACH This research constructs a theoretically based framework for the role of the IT project manager in organizations balancing agility and traditional systems development. The framework is rendered probable through two minor case studies. As balancing of agility and traditional systems development is a rather new phenomenon in the complex context of the software industry, it is feasible to investigate through case studies (Yin 2009). Through a literature study the existing knowledge of balancing were mapped (Yin 2009, p. 14), and served as the analytical framework for the case study. The cases were chosen to be distinctly different

(1) Accommodated communication Management (steering committee etc.) (7) Feedback E.g. changed plans Technological environments (11) Expectations management Artefacts Controls the content Accommodated communication Coach Product /facilitator owner /motivator Coaching incl. on Architect technical aspects Plan work and delegates Responsible for the rather detailed (14) architectural quality (13) Controls the Gate keeper of the solution content Direct control and Feedback management (4) (12) (5) Traditional developmet Team(s) (6) (8) Overall responsible for the project and for aligning plans, people and long-term goals The Project manager (9) Accommodated Accommodated communication communication (5) Artefacts Balancing the approaches through risk assesment (15) Product (2) Stakeholders cutomers, users etc. (7) Feedback E.g. changed requirements Expectations management (10) The agile development Team(s) Agile context: The scrum master focus on today and to morrow, while the team is self-organizing 14 Are Heroes All We Need? The New Role of the IT Project Manager as the born-agile firm were rapidly growing, feeling the need for more structure and discipline in certain parts of their processes, and the traditional middle sized software firm in the financial sector were starting to adopt agile methods needing more flexibility. Exploratory pilot study? Literature studies Construct framework Balancing from agility Data collection & analysis Data collection & analysis Interpreting Balancing from traditional Interpreting Result Result Cross case analysis Similarities and differences across contexts DEVELOPMENT LAYER STRATEGIC LAYER Monitoring and evaluating technology to integrate Figure 1.1. The research process has been iterative in both the construction of the framework based on the literature review and in the process of rendering the framework probable through the case studies. First, an explorative pilot study (two interviews) on challenges of adopting agility helped focus our attention on the project manager as the key person. Second a literature study was designed focusing on both balancing and on the project managers role in balancing. This literature study followed a structured approach recommended in Webster and Watson (2002). The literature was analyzed through three distinct questions: 1) why balancing? 2) How can balancing be done? and 3) how does balancing influence the role of the project manager? The results were displayed in concept matrixes and the finds, from question 3 especially, laid the ground for developing the theoretical framework by attempting to pin bits and pieces from the literature together to create a meaningful whole describing the new role of the project manager. The two case studies were designed as parallels in terms of interview guide, data collection and analysis. For practical reasons we had four interviews in the traditional organization across the organizational levels and only two in the born-agile organization, covering the same span of organizational levels. The parallel design allows for cross case analysis (Yin 2009) investigating how balancing is played out in different contexts and the effects on the role of the project manager.

PROJECT MANAGEMENT THEORY MEETS PRACTICE 15 The constructed framework served as the interview guide in the open ended interviews, where the interviewees discussed and evaluated the match of the framework to their perceptions of practice. Notes were taken, or drawn onto the model, in collaboration with the interviewee. The interviews were sound recorded, transcribed and tagged by two researchers, individually, and the results compared and negotiated. The data, organized this way, was analyzed and interpreted with the purpose of rendering the framework probable by comparison to the studied practices. Based on this the framework was further developed and any new aspect discovered was added. Even though the data collection and analysis of the two cases were undertaken in parallel the case of balancing from traditional practice turned out to be far more complex in terms of organization, challenges and diversity than the agile case. Thus the traditional case is reported in more detail. BALANCING AGILE AND TRADITIONAL SYSTEMS DEVELOPMENT APPROACHES Despite early discourses about agility and traditional systems development to be irreconcilable paradigms (Beck and Boehm 2003), research now concludes that it is beneficial to balance agile and traditional approaches (Magdaleno et al. 2012). The concept of balancing suggests that both agile and traditional approaches have their home grounds of organizational conditions under which the approaches are most likely to succeed (Boehm and Turner 2003d). Systems development projects should be evaluated according to the home grounds and balanced approaches should be tailored to match the project (Boehm and Turner 2003c; Port and Bui 2009). Since systems development projects are rarely positioned entirely on either home ground (Galal-Edeen et al. 2007), combining methods (balancing) are most often recommended. Why balance? Motives, opportunities and challenges Across all the contributions on balancing, motives, opportunities and challenges are discussed widely. The motive most often mentioned is that neither agile nor traditional approaches are complete solutions (Boehm and Turner 2003b; Boehm and Turner 2003d; Boehm and Turner 2005; Boehm 2002; Galal-Edeen et al. 2007; Jakobsen and Johnson 2008; Lukasiewicz and Miler 2012; Lycett et al. 2003; Magdaleno et al. 2012; Marcal et al. 2007; Nawrocki et al. 2006; Port and Bui

16 Are Heroes All We Need? The New Role of the IT Project Manager 2009; Vinekar et al. 2006). Balancing is a kind of general solution allowing for pragmatic handling of a wide range of challenges, since both agile and traditional methods have their separate strengths. There is a need to maintain dual structures that accommodate both approaches (Vinekar et al. 2006) since a changing world requires both agility and discipline (Nawrocki et al. 2006). Opportunities are that balancing can drive process optimization, increase flexibility and reduce cost and time to market by pragmatic utilization of the optimizing aspect of the traditional approaches combined with the flexibility and low overhead cost of agility (Boehm and Turner 2003d; Galal-Edeen et al. 2007; Lepmets and Nael 2010; Lukasiewicz and Miler 2012; Port and Bui 2009; Vinekar et al. 2006). Superfluous processes can be diminished (Little 2005) and thus the processes can be optimized (Marcal et al. 2007). Project failures can decrease (Venugopal 2005) and quality can improve (Magdaleno et al. 2012). The close customer contact of agility (Baskerville et al. 2011) and the team communication (Pikkarainen 2009) is especially pinpointed as beneficial, while the traditional virtue of documentation is emphasized to increase visibility, scalability and reliability of the solution (Beck and Boehm 2003). Boehm and Turner (2005) formulate the main challenge of balancing as the need to avoid development process conflicts that can ruin the agility and undermine the optimization already achieved by traditional practice over the years. It is crucial to exploit the strengths of the approaches and minimize the weaknesses (Boehm and Turner 2003d; Marcal et al. 2007). The key to successful balancing is handling people, values, communication and expectations (Boehm and Turner 2003b). Coordination and communication are thus core challenges (Baskerville et al. 2011; Boehm and Turner 2005; Galal-Edeen et al. 2007; Lycett et al. 2003; Magdaleno et al. 2012). Organizational culture is important and can be a barrier (Galal-Edeen et al. 2007; Karlström and Runeson 2005; Lukasiewicz and Miler 2012; Magdaleno et al. 2012; Vinekar et al. 2006). Handling the diverging culture and contradictory work processes of the approaches can be a severe management challenge (Pikkarainen 2009). Engaging everybody in the change processes is crucial (Boehm and Turner 2005; Vinekar et al. 2006), but hard because the dissimilarity of the approaches often require radical changes by individuals (Baskerville et al. 2011; Vinekar et al. 2006).

PROJECT MANAGEMENT THEORY MEETS PRACTICE 17 How can balancing be done? Types of balancing The literature discusses three different types of balancing, depending on the organizational level in focus. Literature on project based balancing focuses on tailoring approaches at project level, using general concepts of plan-driven and agility without being methodological specific. The main contributions are the above mentioned texts of home grounds. Alternatively, balancing by the principle of ambidexterity (Raisch et al. 2009) at project level is also suggested, subscribing parts of the development work to separate organizational units for agility and stability respectively (Galal-Edeen et al. 2007; Vinekar et al. 2006). Contributions on methodological balancing target balancing, by constructing hybrid light weight methods by combining specific practices from specific methods. An example is XPrince (Nawrocki et al. 2006) that combines XP (Beck 2003), Prince2 (Bentley 2009) and RUP (Kruchten 2004). The balance should be reached by striving towards minimal methodological structure that are not being laissez-faire, i.e. integrating only the necessary elements of the involved methods (Jakobsen and Johnson 2008; Little 2005; Lycett et al. 2003; Marcal et al. 2007; Nawrocki et al. 2006). The assumption of contributions on organizational balancing is that successful balancing is dependent on the capability of the organization when handling the ambiguity between agility and traditional approaches. Different approaches to achieve balancing (Little 2005; Lycett et al. 2003; Venugopal 2005) and theories providing understanding of balancing (Baskerville et al. 2011; Karlström and Runeson 2005) are presented with the effects on the organization in focus. It is highlighted that when organizations embark on balancing, they need to be aware that it is an organizational change process they need to master (Baskerville et al. 2011; Little 2005; Lycett et al. 2003; Venugopal 2005). Baskerville et al. (2011) concludes from a longitudinal study of balancing that combining agile and traditional methods will be necessary in the post-agility era. A reintroduction of the traditional project manager role in agility is required because of the limited scope of Scrum (Schwaber and Beedle 2001). Karlström and Runeson (2005) focus on the project manager role in both agile and traditional methods, and they map the pros and cons of balancing in a stage-gate model. They suggest combination of the agile aspects for optimizing daily planning, and the traditional aspects for securing long term overview in project management.

18 Are Heroes All We Need? The New Role of the IT Project Manager THE INFLUENCE OF BALANCING ON THE ROLE OF THE IT PROJECT MANAGER CONSTRUCTING THE FRAMEWORK The framework was constructed based on knowledge of the role of the project manager when balancing, found in the literature review, and on basic knowledge about agile and traditional approaches. None of the studied literature focused explicitly on project management, but many mentioned aspects of the role or aspects that could influence the role. When balancing, a project manager basically needs to master both agile and traditional project management, but balancing in itself seems to add more tasks and demand more from the project manager. This framework elaborates on all these intertwined aspects as a whole and serves as a proposition of how balancing will influence the role of the project manager. The framework thus expresses the existing theoretical knowledge of this topic. Based on the project managers traditional position as the boundary spanner of the project, the framework is divided into a strategic and development layer with the project manager linking the two as a vital all-rounder (1). The project manager is expected to handle the dualism of keeping the full overview of the project, and tracking plans and milestones, in the strategic layer while, in the development layer, also coaching and protecting the development team from outside disturbances. The last is especially evident in agile approaches. Baskerville et al. (2011) argues that, when balancing, the project manager needs to fill the role as boundary spanner between the day-to-day systems development in the team and the customers and management that need to know about progress and quality of the product. Important actors in the strategic layer are the management (2) and stakeholders (3), while in the development layer the project manager potentially deals with both traditional (4) and agile development teams (5) (Galal-Edeen et al. 2007). In the strategic layer the project manager should develop a widely agreed upon vision, establish the frames for the project and develop artifacts, such as plans (6), that can be utilized to accommodate the communication to the actors of the layer management and other outside stakeholders (Boehm and Turner 2003d; Nawrocki et al. 2006). The most important task in the strategic layer is thus stakeholder communication and expectations management (7) and the project manager generally has the overall responsibility for aligning plans, people and long term goals for the project (8).

PROJECT MANAGEMENT THEORY MEETS PRACTICE 19 At the same time the project manager should be capable of playing a range of roles such as facilitator, coach and motivator (9) in the actual work of the project and in managing the development work (Baskerville et al. 2011; Boehm and Turner 2005; Nawrocki et al. 2006). The architect (10) is responsible for the technical aspect of the solution. The literature disagrees on whether this responsibility should be integrated with the project manager role (Jakobsen and Johnson 2008) or not (Nawrocki et al. 2006). Thus the architect role is depicted separately in the framework. The responsibility for watching and evaluating new technologies to integrate in the solution is also mentioned as the responsibility of the project manager (11) (Boehm and Turner 2003d). This responsibility does not really fit in the layers, but demand that the project manager has some of his focus outside the project on the technical environments. There may be more of these distracting responsibilities not fitting in depending on the situation. STRATEGIC LAYER DEVELOPMENT LAYER (1) Accommodated communication Management (steering committee etc.) (7) Feedback E.g. changed plans Technological environments (11) Expectations management Plan work and delegates rather detailed (13) Direct control and management Traditional development Team(s) (2) (3) (6) Monitoring and evaluating technology to integrate Accommodated communication Artifacts Controls the content (8) Overall responsible for the project and for aligning plans, people and long-term goals The Project manager (9) Coach /facilitator /motivator Controls the content Feedback Accommodated communication Accommodated communication Artifacts Balancing the approaches through risk assessment Product Product owner Stakeholders customers, users etc. (7) Feedback E.g. changed requirements Coaching incl. on technical aspects (14) Gate keeper Expectations management Architect Responsible for the architectural quality of the solution (4) (12) (5) (15) (10) The agile development Team(s) Agile context: The scrum master focus on today and tomorrow, while the team is self-organizing Figure 1.2. The role of the project manager in organizations balancing agile and traditional approaches. The numbers (x) refer to numbers in the text describing the framework.

20 Are Heroes All We Need? The New Role of the IT Project Manager Being the centerpiece, the project manager links between all the actors both between the layers and in the layers. Translating the communication back and forth between the two layers by, for example, linking customers and developers by promoting the development solutions to the customers (Karlström and Runeson 2005). As in traditional approaches the project manager links the development project to the rest of the organization and can also be the single point of contact to customers/users. If balancing is done at the project level then the project manager potentially deals with cultural and practical clashes between the disparate approaches within the team or between different involved teams. The project manager can utilize artifacts, such as roadmaps, product backlogs and burn down charts, as a kind of boundary object in the translation processes (12) (Baskerville et al. 2011). An example of the translation of information is when the project manager receives information from one stakeholder (e.g. the customer) interprets the information and expresses it to other stakeholders (e.g. the developers) through the artifacts (e.g. requirements or architecture diagrams). This powerful idea is integrated in the framework, giving artifacts a central mediation role for the communication. Finally, but very importantly, the project manager is expected to do the actual balancing by evaluating the project characteristics as the starting point for composing an appropriate balanced approach, drawing on elements from agile and traditional approaches (Boehm and Turner 2004; Galal-Edeen et al. 2007). In case the traditional elements dominate the project manager needs to plan and delegaterather detailed work (13) (Vinekar et al. 2006). If, on the other hand, the project is mostly agile, with decentralized and flexible structures of smaller teams that collaborate closely with stakeholders and each other (Vinekar et al. 2006), then the role of the project manager is transformed into gatekeeper, coach and technical sparring partner (14) (Boehm and Turner 2005). As a gate keeper the project manager will be responsible for the overall plans, staffing and progress and quality (Baskerville et al. 2011), but also for coaching the team and taking part in technical and other system development decisions (Pikkarainen 2009). Explicit risk management (15) will ease the process of finding the right balance in the project but never the less the project manager must be capable of handling any combination of the roles. When all responsibilities of the project manager mentioned here and there in the literature is pinned together to a whole as in the framework above, it displays

PROJECT MANAGEMENT THEORY MEETS PRACTICE 21 a very complex situation with a diversity of actors, interest, tasks and conceptual worlds in which the project manager among many other roles must play the important role of translating information and knowledge to and from the different actors and layers. CASE ANALYSIS Balancing from traditional practice by adoption of parts of agility as project based balancing The organization was a middle sized software firm within the financial sector, producing new software but also maintaining and modernizing many legacy systems. It had, until recently, performed systems development through traditional approaches resembling the waterfall model. Their motive for balancing was to supplement their traditional practices with agile aspects in order to take advantage of the promised opportunities for cost saving and more efficient systems development. The improvement process was conducted by their process group, striving to develop a new adapted balanced (e.g. more agile) approach through an organizational learning process, by letting their project managers experiment as they wished. The goal was to develop a basic portfolio of elements and techniques that systems development projects should use, depending on project characteristic. In the end the firm wanted all projects to perform consistently and compliant with the models, meaning that the goal was methodological balancing, while it started out by experimental project based balancing. This case can be called the usual case, as most cases reported in the literature are about adopting agility into traditional practice. The improvement attempt towards project-based balancing was clearly designed and management approved, however, as expressed by the interviewee, the balancing turned out to be much less systematic as the project managers could chose and mix approaches according to preferences or by intuition. The centrally designed process model was provocatively described by one department manager as being a traditional model, and then when we have done analysis and design we iterate through programming and test. An interviewee from a higher level of management, however, emphasized the many agile techniques and tools recommended in the processes, which in his view accounted for agility. The confusion was widespread, as seen in a quote from the interviewee from the process

22 Are Heroes All We Need? The New Role of the IT Project Manager group: Agility is many things; it is not only working iteratively. In our model we do have iterations, no one disagrees on that, but that does not mean you cannot use the waterfall model. Their main challenges turned out to be communication, coordination and the need to engage everyone in the change towards the new processes. The attempt to adopt agility can be characterized as a top-down approach, unsuccessful in communicating the change rationale and the opportunities for the change to the employees, even though interviewees from the management formulated the goal for balancing clearly: efficiency we do this to be more efficient and cost effective when developing it systems. The attempt seemed halfhearted and unfocused and the actual balancing in the projects was haphazard and dependent on the individual project managers abilities and willingness. Management pushed their project managers to adopt more agility but that message, however, was not fully understood or even overheard. The quote from the department manager above could suggest that agility to the willing project managers meant something else, or more than what management promoted. Hence, following from this lack of clarity, the challenges for all involved were substantial. Internally, confrontations between groups supporting and rejecting balancing grew. Externally the customers of the organization were also uninformed about the advantages of the new approaches evading the frequent deliveries and the customer involvement during the iterations. An example of the half-heartedness was that the firm had to make do with internal deliveries and customers only reluctantly accepting to participate in demos of the delivered product. The role of the IT project manager when balancing from traditional practice Even though the basic structure of layers (1) from the framework was evident in the case, some of the set up was simpler than in the framework. Management and the customers formed a shared board (2), which was the main actor in the strategic layer, simplifying the communication task for the project manager in some ways. Still the users and other stakeholders (3) needed to be addressed, however these were less influential. In the development layer there was only one project team (4) that utilized a mix of the traditional and agile practices. The center space around the project manager was, however, more complicated, as it was staffed by different specialists: the architect (5), the business project manager (6) playing the role of product owner and different consultants planning