Abstract
Background: To address the low success rate in information system (IS) projects, organisations in South Africa are adopting agile implementation methodologies. Agile delivery environments advocate an iterative approach where autonomous, self-organising teams share project management (PM) activities. This encroaches on the traditional project manager role. Are project managers still relevant in agile delivery environments and how should they adapt?
Objectives: This case study investigated how project managers could adapt to agile IS implementation environments to remain relevant. Specifically, the views of their key stakeholders (the management and implementation teams) were elicited to provide insights into what is expected from agile project managers.
Method: A qualitative, inductive content analysis approach using purposive sampling was used to identify 13 participants (comprising management and implementation team members) within a large South African insurance company. Semi-structured interviews were conducted with all participants.
Results: The management and implementation teams agreed that PM remains highly relevant in an agile environment for ensuring project governance including delivery, risk management, reporting and budgeting. There was, however, disagreement between the management and implementation teams on project management interaction with the implementation team. Management preferred a command and control type project manager, while the implementation team favoured a more inclusive, facilitative PM style.
Conclusion: To remain viable in an agile IS project implementation environment within large corporates, project managers need to be aware of what various stakeholders expect of them. They need to retain some of the classic PM functions while adapting to the interpersonal and collaborative requirements of the agile way.
Introduction
Information system (IS) development projects have a reputation for failure in terms of overrun in budget, timeliness and not meeting users’ expectations (Karleskey & Voord 2008; Savolainen, Ahonen & Richardson 2012; Yeo 2002). Evidence for this reputation is that only 29% of worldwide IS projects achieved project management (PM) success (The Standish Group International 2015). This failure rate is high when compared with other high-tech projects and is the reason for concern given that IS is increasingly seen as being of critical strategic and operational importance in organisations (Sauer & Reich 2009). Furthermore, within the knowledge economy, software is seen as a source of knowledge and IS development as a source of knowledge creation (Bailin 1997; Shongwe 2015), and creating knowledge affords organisations the opportunity to gain and sustain competitive advantages (Mitchell & Boyle 2010).
In an attempt to address the failure of traditional approaches to IS delivery, organisations are turning to agile methodologies (Dybå & Dingsøyr 2008; Lindvall et al. 2004). Agile software development differs from the traditional waterfall approach in that, in a waterfall approach, a formal, sequential process of planning, analysing, designing, implementing and maintaining is followed. Agile, on the contrary, is characterised by fast and flexible results based on iterative delivery, frequent feedback loops and constant involvement of the customer (Cohn 2004; Rao, Naidu & Chakka 2011; Stettina & Horz 2015). The wide-spread adoption of agile implementation methodologies is attributed to their ability to respond to fast changing business requirements, market conditions and technology innovation (Augustine, Payne, Sencindiver & Woodcock 2005; Stavru et al. 2014).
From a PM perspective, the move to agile implementation has introduced a number of challenges. The project manager can no longer only be concerned with planning, organising and controlling, but instead has to learn to facilitate and coach to encourage collaboration between team members in line with the agile way (Highsmith 2003; Nerur, Mahapatra & Mangalaraj 2005). They also have to play an active role in project knowledge management, which contributes to project success (Srikantaiah, Koenig & Hawamdeh 2010:v). A further complication is that agile software development encourages autonomous, self-organising teams who are meant to share PM tasks and responsibilities such as estimation, planning and progress tracking. This new focus encroaches on the project manager’s territory and raises questions about the project manager’s role (Hoda & Murugesan 2016).
To complicate matters even more, many, especially large organisations, struggle to make the transition from traditional to agile IS implementation methodologies (Dybå & Dingsøyr 2008; Nerur et al. 2005; Sidky, Arthur & Bohner 2007). In fact, it is more likely that large organisations employ both traditional and agile IS implementation practices in what is termed an ambidextrous approach (Vinekar, Slinkman & Nerur 2006), this duality presenting additional complex challenges to the PM role.
Given these team-related and organisational challenges faced by project managers, the question arises: how should project managers adapt to fit into an agile implementation environment within large corporates? This research set out to explore this question by obtaining the perspectives of the following two important project stakeholders: the management team and the implementation team. How do they view the role of a project manager in an agile environment and what do they require from such a role to more successfully complete IS implementation projects? If project managers who operate in implementation environments that are moving into an agile space are aware of the traditional versus agile needs of their key stakeholders, they could adapt their approach to strike a balance between the old and new way of working.
The rest of this article is structured as follows: Firstly, theoretical perspectives on IS projects in agile environments are presented. Next the case study research design used in this research is explained, and finally, the findings, discussion and key guidelines for the adapted role of PM are provided.
Information system implementation and project management challenges
The global business landscape has changed dramatically in the last few decades. Access to data, disruptive technological advances and the speed of innovation are some of the key drivers fuelling this revolution (Barkema, Baum & Mannix 2002). IS development is a crucial part of delivering technology innovation (Schwaber 2004), and as a result, business is both more aware and more critical of the success of IS projects. Business sees IS as being of strategic and operational importance – they want to see a return on their investment in IS and they have become more mature in their understanding of the nature of IS and IS projects (Sauer & Reich 2009).
Despite many efforts for IS implementation to meet customers’ value needs in recent years, many software projects still fail to deliver value. They use more resources than planned, deliver less functionality at lower quality than expected and take longer to complete than anticipated (Barros, Werner & Travassos 2004). Some of the reasons offered for these failures include badly defined requirements, unrealistic expectations from business, poor reporting on project status and poor management of risks (Charette 2005). To manage risks, one has to manage knowledge (Neef 2005) and project knowledge is considered as one of the most powerful tools in managing risk (Cooper 2003; Srikantaiah et al. 2010). PM can play a significant role in knowledge management and, therefore, risk management because of the distributed interaction it has with many layers in the organisation (Schiel 2010).
Most IS professionals believe that using IS project methodologies will improve the PM success rate; however, project managers face a number of challenges that limit their success: unrealistic project deadlines, working on multiple projects simultaneously, ineffective use of PM software and lack of knowledge of PM methodologies (Terlizzi, De Souza Meirelles & De Moraes 2016). The nature of IS projects has also changed in recent years with an increase in technical complexity, rate of technology change, importance of security, business change involved in projects, prevalence of virtual teaming, organisational instability and interdependence with other organisations. All of these factors contribute to the fact that information system project management has become increasingly challenging (Sauer & Reich 2009:184).
The move from traditional to agile
Agility in organisations emerged from multiple domains including logistics and manufacturing (Stettina & Horz 2015) and found its way into software development at the end of the 1980s (Nagel & Dove 1991). One of the drivers towards agile methodology involves moving away from the extensive use of planning, codified processes that enforce standardisation, rigorous software reuse, heavy documentation and big upfront design, which traditional software development processes demand (Arikpo & Osofisan 2010; Nerur et al. 2005). In traditional waterfall methods, a sequential process is followed whereby projects force users to describe their needs accurately upfront, to capture as much information as possible, and only to deliver the requested features at the end of the process (Hong et al. 2011; Stoica, Mircea & Ghilic-Micu 2013). This has created a challenge for most organisations, mainly because of the false impression that proper planning and collecting detailed user requirements assist project teams in learning everything that they need to know about user requirements (Goodpasture 2015). The reality is that because of rapidly changing technology, market and social conditions, most real-world development efforts are conducted in more volatile environments (Augustine et al. 2005; Nerur et al. 2005). As a result, system requirements will change fast, often at ‘Internet speed’ (Baskerville et al. 2003).
Agile development leverages the concept of lean manufacturing that aims at deferring a decision until the reasonable moment, thereby assisting an organisation not to waste time on tasks until the odds of actually doing them are high (Schiel 2010). The agile approach follows four basic principles: individuals and interaction over process and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to chance over following a plan (Fowler & Highsmith 2001).
Agile methodology allows for the prioritisation of functionality, as development teams deliver product features sooner, through iterations. Agile also entails frequent feedback loops and iterative reviews (Stettina & Horz 2015). By using agile methods, customers are constantly involved in the development process by providing input into what should form part of the feature, which gives customers the assurance that the outcomes will be as close as possible to their requirements (Cooke 2014). The role of management in an agile environment is that of facilitating rather than controlling and developers often work collaboratively or in pairs, whereas in the traditional approach they are required to work more individually within teams (Hoda, Noble & Marshall 2008).
Although there is increased awareness of and interest in agile methods, it appears to be more difficult to implement in larger projects (Dybå & Dingsøyr 2008). The speed of change and close customer involvement required by agile is particularly challenging for larger organisations with well-established processes and structures (Stettina & Horz 2015). There currently seems to be no structured approach for the adoption of agile methodology, resulting in organisations asking different questions on the way to proceed when adopting agile practices (Sidky et al. 2007). Agile systems development requires changes to organisational culture (Vinekar et al. 2006), and this may take several years to achieve (Adler & Shenhar 1990), implying that there are varying levels of agile maturity within an organisation. A number of agile maturity frameworks exist, an example being the agile maturity model (AMM) by Patel and Ramachandran (2009). This model lists five stages of agile maturity based on the level of agile process improvement: initial, explored, defined, improved and sustained. Many large organisations claim to follow an agile IS implementation approach, but in reality because of current low levels of agile maturity within large organisations, many employ both traditional and agile implementation approaches (Vinekar et al. 2006). This presents unique challenges to the PM discipline and the role of the project manager in IS implementation projects within large organisations.
The challenges of agile project management
In response to the shift towards agile IS implementation methodologies, the PM discipline has started to reinvent itself in the form of the emerging agile project management (APM) discipline (Lee & Yong 2010; Persson, Mathiassen & Aaen 2012). APM is a conceptual PM framework for undertaking software development projects in which the emphasis is moved from planning to execution (Chin 2004), and encompasses the study of which methods, tools and techniques to employ to improve the performance of the project by promoting agility (Conforto & Amaral 2016). Taking a brief look at APM may assist in a better understanding of the challenges that face traditional PM in agile environments.
According to Augustine et al. (2005), APM lets software project managers and employees adapt to changing circumstances rather than trying to impose rigid formal controls, as in traditional linear development methods and this in itself poses a challenge to traditional PM approaches. Although PM remains an important and necessary part of any software development process in terms of managing the teams, customer relationships, cost reduction, risk management, maintaining project time line and budget, the manner in which it is done in an agile environment has changed (Hoda et al. 2008). Project managers are left in the lurch, since many of the commonly known PM practices and tools are geared towards large and relatively slow-moving projects (Chin 2004).
One such example is the emphasis on documentation in the traditional environment. Because of the fast changing context of the agile space, if a project manager attempts to rigorously document variations on the originally agreed-upon plan, their time will be consumed with tracking, analysing and documenting ever more complex variations, and they risk demoting their position to that of an administrative role (Chin 2004). Roles and responsibilities have also changed. Agile introduced a new set of roles such as product owner and scrum master, which share some of the traditional responsibilities of the project manager, further blurring the line of PM (Hoda et al. 2008).
To manage changes in requirements, an agile environment needs to allow for innovation and creativity, and by applying traditionally heavy PM techniques, the project manager risks stifling innovation. A balance is, therefore, required between too much process and too little process (Chin 2004). The agile manager is, however, responsible for establishing clear roles and responsibilities to ensure proper team alignment and accountability. They also need to be vigilant in identifying practices not being followed, understand the causes of the impediments and endeavour to remove any obstacles (Augustine et al. 2005).
Chin (2004) recommends two strategies that project managers could employ to adapt to agile environments:
- take more of an outward-facing perspective to facilitate the integration of the project and the business
- focus energy on delivering results that solve business needs rather than staying within present project boundaries (Chin 2004).
Augustine et al. (2005) echo this sentiment by stating that project managers should become visionary leaders rather than uninspired taskmasters and embrace the notion of self-directed teams with ‘light touch’ leadership. Agile project managers must aim to steer and guide the various entities involved in an agile project, and encourage continuous learning and adaptation by acting as facilitators (Augustine et al. 2005; Nerur et al. 2005). Nerur et al. (2005), however, also warn that shifting from authoritative manager to facilitator may not be easy for people who thrive on authority.
Having surveyed the literature, the researchers concluded that prior research into the changing role of the project manager in an agile environment seems to have been limited mostly to theoretical concepts leaving a clear gap for empirical research to be conducted. To provide a novel angle on what is expected from a project manager in an agile environment, perspectives were sought from the people who interact on a daily basis with project managers, namely the management team and the implementation team.
Research design
This research followed a qualitative, case study approach. This design was chosen to obtain descriptions of the phenomena (perceptions held by management and implementation teams) within the relevant context as described by the study participants, based on their experiences (Darke, Shanks & Broadbent 1998). Interpersonal expectations, as explored in this research, are highly complex and the qualitative case study approach allowed the researcher to deal with this complexity by gaining insights into behavioural conditions from the participants’ perspectives (Zainal 2007).
Sampling and research setting
Purposive sampling was used (Wilmot 2005) to identify 13 participants working within the IS department of a business unit within a large insurance company in South Africa. Five of the participants belonged to the management team and the remaining eight were part of the IS implementation team. The management team roles consisted of the IT executive, senior IT consultant, project manager head, software methodology head and a program manager. The implementation team roles included project managers, developers, testers, architects and analysts. Members of these teams have been part of both successful and failed agile projects within the organisation.
Participants were included based on their advanced level of experience and knowledge about IS project implementations, with all of them having been involved in IS for at least 10 years. Participants were approached directly by the researcher and all participants signed informed consent forms, where the nature of the research and their rights as participants were explained. The ethics committee of the University of Stellenbosch approved this research.
Data collection and analysis
Semi-structured interviews were conducted with all participants. A basic interview guide was used to elicit deep reflection about the experiences of participants during IS implementation projects (Barriball & While 1994; Merriam & Tisdell 2015). This approach allowed participants to share their understanding of the challenges they faced and specifically the role that project managers played. Interviews were digitally recorded, transcribed and proofread by the researcher.
Data were analysed using an inductive qualitative content analysis approach (Hsieh & Shannon 2005). This analysis method was used because of its ability to extract the meaning of data through a process of coding and to describe theoretical concepts by means of an inductive approach (Cho & Lee 2014). The qualitative data analysis software package ATLAS.ti was used to identify initial categories through line-by-line coding (open coding), followed by category reduction through axial coding (Corbin & Strauss 1990). Initial coding yielded 380 codes, which after axial coding and memo writing (Charmaz 2014) was reduced to a set of 10 main challenges faced during agile implementation projects. This article reports on one of these identified challenges namely what is expected of project managers.
Findings and discussion
The expectations that the management team (hereafter referred to as ‘M-1’, ‘M-2’, etc.) and the implementation team (hereafter referred to as ‘I-1’, ‘I-2’ etc.) had of the PM role in an agile environment within a large corporate consisted of two main themes namely ‘Performing a governance role’ and ‘Interacting with the implementation team’. The latter theme (‘Interacting with the implementation team’) had two sub-themes: ‘Exerting control’ and ‘Serving as a coach and facilitator’.
The expectations of both teams with regard to these themes are illustrated in Figure 1. Although project governance expectations are shared, expectations on how to interact with the implementation team differ. The rest of this section discusses these findings.
 |
FIGURE 1: Management and implementation teams’ expectations from project managers in an agile environment within a large corporate organisation. |
|
Performing a project governance role
Traditionally, project governance is a key part of the PM role within IS projects and is used to achieve more predictable rates of PM success (Terlizzi et al. 2016). In an agile environment, where there is supposedly less focus on process and tools and more on individuals and interactions (Fowler & Highsmith 2001), one would assume that expectations from management and implementation teams would have changed. The findings of this research, however, reveal that both the management and implementation teams still value and expect project managers to fulfil a governance role, specifically relating to project delivery, risk management, reporting and budgeting.
In terms of project delivery, both the management and implementation teams agreed that driving a project plan is one of the key roles that remain important for a project manager in an agile environment as illustrated in these comments:
‘A project manager has to focus on chasing the plan ensuring that people stick to what they promised, according to the plan.’ [I-7; male; project manager]
‘A project manager’s role is to report progress and risks to the executives.’ [M-1; male; IT executive]
‘In our case I don’t think you can do without the project manager because there’s detail and high level issues that must be dealt with on a daily or weekly basis that impacts your timelines, so you can’t do without the project manager role.’ [M-3; male; head of PMO]
The traditional PM governance role was seen as critical in an agile environment since there is the perception that pure agile, as opposed to the traditional waterfall approach, does not provide the necessary tools ‘to ensure accountability and responsibility on the delivery team members as individuals’ (M-1). This finding is contrary to what agile software development advocates. Sprint teams are expected to be autonomous and self-organising and keep themselves accountable by sharing some of the typical PM tasks such as planning and estimation (Hoda & Murugesan 2016). The fact that the perception exists that individuals are not held accountable may point to the fact that there is a low level of agile maturity in this specific environment possibly, because there are no formal agile process improvement initiatives in place (Patel & Ramachandran 2009). According to Goodpasture (2015), self-organisation is often as the result of highly motivated, highly skilled and experienced team members and evolves over time. From a management perspective, this need for control can perhaps be understood in the context of the high rate of IS project implementation failure (Savolainen et al. 2012).
There seems to be an expectation that a project manager should be able to take ultimate responsibility for ensuring that tasks are completed. This is argued by I-6, who cannot imagine a team without a project manager, who takes full responsibility, ensuring that due process is followed. A project manager is someone that takes the responsibility for ‘pushing the people when things are falling behind’ (I-6). The expectation is more than merely meeting a deadline. I-4’s view is that the organisation expects the project manager to be able to connect the original business case with project delivery and also to play a role in ensuring that the desired end result is reached. From a management perspective, there was a concern that in an agile environment, there is the danger that without a project manager there is no one who takes ultimate responsibility for project delivery and above all, project failure (M1). This sentiment is in line with the fact that traditionally project managers have been held responsible for time, cost and quality aspects of IT projects (Sheffield & Lemetayer 2013).
M-3 raised the importance of creating awareness around project risks:
‘…in an Agile world, there are people thinking that you do not need project management roles when using an agile approach, which I think is not correct… you still need to know what the overall milestones are, what the budget is, what the risks are, all arising project issues, managing the stuff that does not change.’ [M-3; male; head of PMO]
The implementation team in general affirmed this view by stating that a project manager manages the delivery of the project in terms of time and that a project manager should remain aware of the project scope and overall quality. In addition, governance disciplines ensure proper compliance and conformance to project ceremonies and these are typically a PM role, even in an agile environment (I-5). In implementations of agile such as Scrum, the view is counter to that expressed by the participants: project managers have no project plans or time reporting, but instead rely on the frequent delivery cycle of the agile approach to show results (Schwaber 2004).
There was a clear expectation from management that project managers must take responsibility for executive management reporting on agile projects (M-1; M-3). They were particularly adamant about this given the perception in the organisation that agile projects do not provide clear feedback to management stakeholders:
‘I think agile hasn’t done a lot of work on communicating transparent scope changes and agreements outside the project… because of the daily stand-ups, people know what’s going on, its crystal clear to the people around, but in terms of the person outside the project who’s giving the money and who wants to know every six months as an investment if their money is safe, how do roles such as Head of Business, CIO, and other senior business representatives get visibility in an agile project?’ [M1; male; IT executive]
This perception, however, is contradicted by the nature of feedback in pure agile environments which takes the form of regular, rapid feedback to customers, developers and end-users through frequent releases of the working software (Cohn 2004; Rao et al. 2011). It would appear that at senior management level, the need to be personally present at feedback sessions is a pragmatic obstacle:
‘They (senior management) don’t have time in a day to come look at that level of details as sponsors.’ [M1; male; IT executive]
It is clear from these findings that both the management and implementation teams value the governance role that project managers fulfil on agile projects, particularly with regards to project delivery, risk management, reporting and budgeting. This finding points to the dual nature of IS delivery methodologies in large organisations where organisations, while realising the need to embrace agile, still have a need for the structure provided by traditional development approaches (Vinekar et al. 2006). In terms of interacting with project stakeholders, this implies that project managers are challenged to function in both paradigms as revealed in the discussion that follows.
Interacting with the implementation team
A key change in an agile environment as opposed to a traditional IS delivery approach is the way in which the implementation team operates. The agile manifesto prescribes individual interaction over process and tools, collaboration over contracts and being responsive rather than following a rigid plan (Fowler & Highsmith 2001). Agile IS development places a premium on people and their interactions. The emphasis is on teams and on the intense dynamics of team interactions (Vinekar et al. 2006). The findings discussed in this section reveal how the project manager has to renegotiate their role within the implementation team based on the expectations of both management and implementation. The two sub-themes capturing this aspect are ‘Exerting control’ and ‘Serving as a coach and facilitator’.
Exerting control
Some of the management team members expect project managers to take on a command and control role; whereas, the implementation team spoke out against such form of restriction. Three of the management team members (M-1; M-2; M-3) supported the existing culture of control in the organisation and expected project managers to help sustain this approach in an agile environment:
‘If you’ve grown up in the waterfall world, you’ve come up through the ranks there, you know what the issues are, you know that you got to pay attention to this and that, to make this go right.’ [M-2; male; IT consultant]
‘Say you have a team of 10 where eight pull their weight whereas the other two do not, but you as a project manager don’t actually take on those two, if the other eight see that they are getting away with it, then the whole team takes a fall.’ [M-3; male; head of PMO]
‘One of the tenets of project management is meant to be a mechanism that identifies the goal and helps the community achieve that goal. So it implies an element of drive to control people by saying yes/no.’ [M-1; male; IT executive]
Only one manager [M-4] disagreed by expressing that command and control are not necessary in an agile environment since the team manages itself.
This expectation from management that seems to contradict the agile principles was pointed out by Cockburn and Highsmith (2001) who stated that PM style in a traditional waterfall organisation tends to exert command and control over developers. They further emphasise the importance of collaborative decision-making to improve agility within business. They believe that a command and control approach inhibits agility and ultimately fails the implementation teams in an agile environment (Cockburn & Highsmith 2001). IS professionals and project managers are knowledge workers. They often identify themselves in terms of their area of expertise and not the organisations they work for. Therefore, organisations who apply a ‘boss and subordinate’ approach to PM may face the risk of losing these professionals (Srikantaiah et al. 2010:4). Augustine et al. (2005) echoes this sentiment by stating that ‘skilled professionals don’t adapt well to micromanagement‘.
Contrary to management’s view, the implementation team felt strongly that there is no place for command and control from project managers in the agile space:
‘Styles like micro management, authoritative, that doesn’t work. Being too detail oriented. You can’t be too set about what you’re actually going to get, you have to be flexible, you have to be able to change.’ [I-2; female; business analyst]
‘The ones that are not succeeding with agile are those that are very commanding and controlling. If you going to have someone that is commanding and controlling, who will end up pushing people to do things, people are going to leave.’ [I-3; male; developer]
I-3 argued that a project manager needs to be the person who works for the project team, one who is the eyes and ears of the people in the team and is expected to fight battles for the team, attending meetings with management to ensure they get the ‘stuff required to keep the project running’. Styles like micromanagement and being authoritative do not work in agile environments (I-2). I-4 supported this view: in a waterfall project, project managers can be authoritative or dictatorial, but in their experience this does not work in an agile environment since the project structure is less hierarchical, allowing the implementation team members to by-pass the project manager by, for example, speaking directly to business. This is in fact aligned with the notion of self-organising, autonomous teams as advocated in an agile approach (Schiel 2010). Project managers should realise that in an agile environment and specifically where the scrum methodology is used, it is expected of individual team members to be autonomous and self-organising (Augustine et al. 2005). As a result, some of the typical PM tasks are shared by the team members (Hoda & Murugesan 2016), and they should, therefore, become one of the team members instead of elevating themselves above the team. This approach can be achieved by project managers attending daily check-in sessions with the implementation team to show interest and to keep up to date with what is happening in the team (I-4). I-8 felt that project managers have the responsibility to win the trust of the teams so that the team chooses to listen to them:
‘It is not all about you sitting there and doing the mantra and going on trying to get everyone to listen to you, it is about being able to be bigger than the room, and if you are not, you’re going to struggle. Agile works where you have very high trust between the development organisation and the client or the management group.’ [I-8; male; developer]
Developing and sustaining a sense of trust has been shown to be at the root of agile success (Schwaber 2004). Furthermore, trust may lead to balanced decision-making that could potentially shift the balance of power from management to the development teams (Nerur et al. 2005). Trust also encourages continuous learning, spontaneity and creativity and working together towards a single goal (Moe, Dingsøyr & Dybå 2009).
I-4 makes a strong case for why command and control by project managers in an agile environment is not a good idea. I-4 believes that each team member has enough authority to make decisions on what should happen in their teams. If the team is unable to think for themselves, it will not be able to ‘catch some of the things that the project manager drops’, which will ultimately impact the ability of the project manager to deliver on project expectations. Learning and growth is also stunted through command and control management style:
‘…if the team does only what the project manager tells them to do, the role of management or lead can never be any better in such a team.’ [I-4; male; test manager]
This sentiment is echoed by Cockburn and Highsmith (2001), who emphasise the importance of collaborative decision-making to affect agility within business, and also speaks to the notion of autonomous, self-management teams (Hoda & Murugesan 2016).
This tension that seems to exist between the view of the management team and that of the implementation team on the level of control that a PM should exert in an agile environment can perhaps be ascribed to the difficulty of letting go of power. Nerur et al. (2005) warn that the shift from authoritative manager would challenge those attitudes and culture of people who enjoy authority, making implementing agile difficult.
If project managers could step back from the command and control paradigm and allow agile teams to self-organise, there could be benefits:
‘If one allows the team to sort themselves out, they realise that they have to work extra as a team and that they do not need to worry that much, because they do not feel forced to do it, or they do not have to do it all the time.’ [M-4; male; methodology lead]
Schiel (2010) and Dybå & Dingsøyr (2008) support this view, stating that self-organising teams are empowered to organise work tasks in a way that give them common ownership. However, Lalsing, Kishnah and Pudaruth (2012) and Goodpasture (2015) highlight the fact that self-organisation is an advanced skill and that it may be difficult to recruit staff capable of forming self-organising teams. In addition, agile practitioners may encounter team-level and organisational-level barriers to self-organisation. On a team-level, these barriers include lack of individual commitment and leadership as well as failure to learn, while pressure to work on multiple projects in parallel, organisational control and organisational insistence on specialists feature account for the organisational-level barriers. These barriers can be overcome by organising cross-training to create generalists, collocating teams in the same room, building trust and commitment and assigning people to one project at a time (Moe et al. 2009).
Ultimately, it seems that a balance is needed between the need for an agile environment and the realities of a large corporate (Vinekar et al. 2006). I-5 sums up why there is still a need for a project manager in agile environments in large corporates:
…pure agile from its original definition, particularly the scrum, cannot really work in agile environments, and this is the reason why there is disciplined agile development which is much more suited for a corporate environment.
They see the role of a project manager as someone who ensures that the team:
‘sticks to some of the culture that exists in project management.’ [I-5; male; IT architect]
Serving as a coach and facilitator
If command and control is not appropriate in an agile environment, then what are the alternatives? The implementation team articulated the need for a project manager to act more like a coach and facilitator. I-7 stated that in an agile environment, a project manager must be a people’s person and relationship driven. It is not about trying to build friendships, but rather about motivating people to work together (I-7). This is in line with research that shows that project managers need to actively target the development of trust through activities that will build it (Sauer & Reich 2009).
This type of involvement starts with the project manager being more present:
‘Project managers should be involved. Our team has seen some who are not, where they throw things over the wall and instruct developers or analysts to do their work, and return after the allocated time to report on the progress. The project managers must be involved daily to know what is going on.’ [M-3; male; head of PMO]
Closer involvement could pose a challenge however. Sauer and Reich (2009) state that the complexity involved in contemporary IS projects implies that project managers may not be sufficiently knowledgeable in all the relevant aspects of the project. On top of this, project managers typically have a heavy workload and may not have the time to be closely involved.
Project managers must act as facilitators and must acquire facilitation skills (I-1; I-8). Facilitation skills would assist project managers in their mediation role when, for example, they need to negotiate overtime work with both the people who have to conduct the work and the sponsors who have to pay them (I-8). This is in line with the notion that project managers must increasingly take ownership of business goals and identify with the business issues instead of merely accepting that business goals are owned by a sponsor (Sauer & Reich 2009). They have to alter their behaviour to that of a facilitator, someone who does not direct but coordinates individuals in a team (Nerur et al. 2005). Contrary to what most organisations believe, project success does not depend only on aspects such as project schedules, budgets and deliverables. Knowledge sharing and cooperation through facilitation play an important role in project knowledge management, which in turn has a positive bearing on project success (Srikantaiah et al. 2010).
In addition to being a skilled facilitator, I-3 saw the PM role as a humble and serving one, able to work collaboratively with the team and stakeholders to get the job done. I-8 illustrated this type of leadership style by referring to examples of leaders such as Clem Sunter, the Dalai Lama and Nelson Mandela, and referring to them as the kind of individuals who had the characteristics required of a leader of an agile project. Kniberg and Skarin (2010) state that agile teams require coaching rather than management. This is supported by Goodpasture (2015), who agrees that coaching skills are important for project managers.
Not all management participants agreed. M-4 argued to the contrary, pointing out that in an agile environment, the role of servant to the team should be fulfilled by the scrum master and not the project manager. Whether serving or not, I-8 believed that project managers should in any case instil energy and stimulate interest in people, all the while keeping their eye on the project plan to ensure that scope is delivered within the planned timelines and in accordance with the relevant quality assurance processes.
Not everyone was convinced that project managers need to change their behaviour in an agile environment. M-1 argued that the traditional project manager role in the waterfall environment also required coaching and facilitation skills. M-1 believed that the same PM style could work in both waterfall and agile environments. I-4 tended to agree, but stressed that ‘one could probably more easily get away with certain styles in waterfall that would not do so well in agile’.
Perhaps the reason for the apparent conflict in expectations from project managers is that ‘project managers apply traditional methods on projects for which they are not suited because they must align their efforts with broader organisational expectations’ (Sheffield et al. 2013:469). It may also be the case that agile software development drives agility in PM (Stettina & Horz 2015) and that with time, adjustments will be made.
Managerial implications and recommendations
From the findings above, the following recommendations are made:
- Be cognisant of the level of agile maturity in the organisation to gauge the balance between traditional PM and APM needs. This can be achieved by using one of the available agile maturity frameworks to assess the current level of agile maturity and by putting in place improvement initiatives.
- Facilitate open conversations between project managers and their stakeholders to create understanding of what is expected from the project manager role. This can be achieved through facilitated workshops as well as informal discussions initiated by management.
- Train project managers in the art of coaching and facilitation to improve their ability to lead agile teams. Numerous coaching and facilitation courses are available through professional services providers and could be formally incorporated into career development and training programmes.
Conclusion
Knowledge is created through the creation of software during IS implementation projects; however, IS project implementation success is low (Bailin 1997; Savolainen et al. 2012; Shongwe 2015). In an attempt to address the disappointing track-record of successful IS implementation projects, organisations are moving towards agile project implementation methodologies, where reduced formality and increased individual autonomy and self-organising teams are advocated. This shift encroaches on the territory of the traditional project manager role and raises questions about how project managers should adapt in order to remain relevant.
This case study provided insights into the desired behaviours of an agile project manager by exploring the different needs of the management and implementation teams. It would appear that project managers are stuck between a rock and hard place when it comes to fulfilling management and implementation teams’ expectations. On the one hand, they are required to fulfil the traditional PM role: both the management and implementation teams require project managers to adhere to classic PM governance functions such as project delivery, risk management, reporting and budgeting. On the other hand, when it comes to the management of the implementation team, the management team preferred a more traditional command and control style project manager. The implementation teams, however, favoured a more agile approach where they expect a project manager to earn their trust, refrain from micromanagement, allow the team to self-organise and act as coach and facilitator.
The conclusion drawn from these findings is that, for project managers to remain relevant in the move towards a more agile IS implementation environment, they must become aware of the different expectations of their various stakeholders and adapt their behaviour accordingly. They need to engage openly with their stakeholders to understand their needs, acquire new skills required in the agile environment such as coaching and facilitation, and strike a balance between employing traditional and APM skills depending on the agile maturity of the organisation.
Limitations and recommendations for future research
This case study was limited to one IS department of a large South African insurance company. Future research should consider expanding the sample to include the views of more stakeholders in both the management and implementation teams and across various industries. It may also be beneficial to specifically obtain the views of project managers on how they see their role in an agile environment. Of the 13 research participants, 8 were from the implementation team and 5 from business. A more equal participant distribution would help ensure that the findings are not potentially distorted. To help address the issue of agile maturity, future research could develop an agility transition framework to help guide and monitor the move from traditional to agile.
Acknowledgements
Competing interests
The authors declare that they have no financial or personal relationship(s) that may have inappropriately influenced them in writing this article.
Authors’ contributions
S.N. conducted the research as part of his MBA research project and co-wrote this article. N.T. was his research supervisor and co-wrote this article.
References
Adler, P.S. & Shenhar, A., 1990, ‘Adapting your technological base: The organizational challenge’, Sloan Management Review 32(1), 25–37.
Arikpo, I.I. & Osofisan, A.O., 2010, ‘Migrating from traditional software development processes to agile software development: The role of organizational culture’, CIS Journal 14(2), 17–27.
Augustine, S., Payne, B., Sencindiver, F. & Woodcock, S., 2005, ‘Agile project management: Steering from the edges’, Communications of the ACM 48(12), 85–89. https://doi.org/10.1145/1101779.1101781
Bailin, S., 1997, ‘Software development as knowledge creation’, International Journal of Applied Software Technology 3, 75–89.
Barkema, H., Baum, J. & Mannix, E., 2002, ‘Management challenges in a new time’, Academy of Management Journal 45(5), 916–930. https://doi.org/10.2307/3069322
Barriball, K. & While, A., 1994, ‘Collecting data using a semi-structured interview: A discussion paper’, Journal of Advanced Nursing 19(2), 328–335. https://doi.org/10.1111/j.1365-2648.1994.tb01088.x
Barros, M.O., Werner, C.M.L. & Travassos, G.H., 2004, ‘Supporting risks in software project management’, Journal of Systems and Software 70(2), 21–35. https://doi.org/10.1016/S0164-1212(02)00155-3
Baskerville, R., Ramesh, B., Levine, L., Pries-Heje, J. & Slaughter, S., 2003, ‘Is “Internet-speed” software development different?’, IEEE Software 20(6), 70–77. https://doi.org/10.1109/MS.2003.1241369
Charette, R.N., 2005, ‘Why software fails’, IEEE Spectrum 42(9), 42–49. https://doi.org/10.1109/MSPEC.2005.1502528
Charmaz, K., 2014, Constructing grounded theory, Sage, Thousand Oaks, CA.
Chin, G., 2004, Agile project management: How to succeed in the face of changing project requirements, AMACOM Division of American Management Association, New York, NY.
Cho, J.Y. & Lee, E.H., 2014, ‘Reducing confusion about grounded theory and qualitative content analysis: Similarities and differences’, The Qualitative Report 19(64), 1–20.
Cockburn, A. & Highsmith, J., 2001, ‘Agile software development, the people factor’, Computer 34(11), 131–133. https://doi.org/10.1109/2.963450
Cohn, M., 2004, User stories applied: For agile software development, Pearson Education: Addison-Wesley Professional, Boston, MA.
Conforto, E.C. & Amaral, D.C., 2016, ‘Agile project management and stage-gate model – A hybrid framework for technology-based companies’, Journal of Engineering and Technology Management 40, 1–14. https://doi.org/10.1016/j.jengtecman.2016.02.003
Cooke, J.L., 2014, Agile productivity unleashed: Proven approaches for achieving real productivity gains in any organization, 2nd edn., IT Governance Publishing, Cambridge.
Cooper, L.P., 2003, ‘A research agenda to reduce risk in new product development through knowledge management: A practitioner perspective’, Journal of Engineering and Technology Management 20(2), 117–140. https://doi.org/10.1016/S0923-4748(03)00007-9
Corbin, J.M. & Strauss, A., 1990, ‘Grounded theory research: Procedures, canons and evaluative criteria’, Qualitative Sociology 13(1), 3–21. https://doi.org/10.1007/BF00988593
Darke, P., Shanks, G. & Broadbent, M., 1998, ‘Successfully completing case study research: Combining rigour, relevance and pragmatism’, Information Systems Journal 8(4), 273–289. https://doi.org/10.1046/j.1365-2575.1998.00040.x
Dybå, T. & Dingsøyr, T., 2008, ‘Empirical studies of agile software development: A systematic review’, Information and Software Technology 50(9–10), 833–859. https://doi.org/10.1016/j.infsof.2008.01.006
Fowler, M. & Highsmith, J., 2001, ‘The agile manifesto’, Software Development 9(8), 28–35.
Goodpasture, J.C., 2015, Project management the agile way: Making it work in the enterprise, 2nd edn., J. Ross Publishing, Fort Lauderdale, FL.
Highsmith, J., 2003, ‘Agile project management: Principles and tools’, Cutter Consortium 4, 1–37.
Hoda, R. & Murugesan, L.K., 2016, ‘Multi-level agile project management challenges: A self-organizing team perspective’, Journal of Systems and Software 117, 245–257. https://doi.org/10.1016/j.jss.2016.02.049
Hoda, R., Noble, J. & Marshall, S., 2008, ‘Agile project management’, New Zealand computer science research student conference 6, 218–221.
Hong, W., Thong, J.Y.L., Chasalow, L.C. & Dhillon, G., 2011, ‘User acceptance of agile information systems: A model and empirical test’, Journal of Management Information Systems 28(1), 235–272. https://doi.org/10.2753/MIS0742-1222280108
Hsieh, H.F. & Shannon, S.E., 2005, ‘Three approaches to qualitative content analysis’, Qualitative Health Research 15(9), 1277–1288. https://doi.org/10.1177/1049732305276687
Karleskey, M., & Voord, M.V., 2008, ‘Agile project management (or, Burning Your Gantt Charts)’, Embedded Systems Conference Boston, Boston, MA, October 26-30, 2008, n.p.
Kniberg, H. & Skarin, M., 2010, Kanban and Scrum-making the most of both, C4Media, New York, NY.
Lalsing, V., Kishnah, S. & Pudaruth, S., 2012, ‘People factors in agile software development and project management’, International Journal of Software Engineering & Applications 3(1), 117. https://doi.org/10.5121/ijsea.2012.3109
Lee, S. & Yong, H.S., 2010, ‘Distributed agile: Project management in a global environment’, Empirical Software Engineering 15(2), 204–217. https://doi.org/10.1007/s10664-009-9119-7
Lindvall, M., Muthig, D., Dagnino, A., Wallin, C., Stupperich, M., Kiefer, D., 2004, ‘Agile software development in large organizations’, Computer 37(12), 26–34. https://doi.org/10.1109/MC.2004.231
Merriam, S.B. & Tisdell, E.J., 2015, Qualitative research: A guide to design and implementation, John Wiley & Sons, Hoboken, NJ.
Mitchell, R. & Boyle, B., 2010, ‘Knowledge creation measurement methods’, Journal of Knowledge Management 14(1), 67–82. https://doi.org/10.1108/13673271011015570
Moe, N.B., Dingsøyr, T. & Dybå, T., 2009, ‘Overcoming barriers to self-management in software teams’, IEEE Software 26(6), 20–26. https://doi.org/10.1109/MS.2009.182
Nagel, R.N. & Dove, R., 1991, 21st century manufacturing enterprise strategy: An industry-led view, Diane Publishing, Collingdale, PA.
Neef, D., 2005, ‘Managing corporate risk through better knowledge management’, The Learning Organization 12(2), 112–124. https://doi.org/10.1108/09696470510583502
Nerur, S., Mahapatra, R. & Mangalaraj, G., 2005, ‘Challenges of migrating to agile methodologies’, Communications of the ACM 48(5), 72–78. https://doi.org/10.1145/1060710.1060712
Patel, C. & Ramachandran, M., 2009, ‘Agile maturity model (AMM): A software process improvement framework for agile software development practices’, International Journal of Software Engineering 2(1), 3–28.
Persson, J.S., Mathiassen, L. & Aaen, I., 2012, ‘Agile distributed software development: Enacting control through media and context’, Information Systems Journal 22(6), 411–433. https://doi.org/10.1111/j.1365-2575.2011.00390.x
Rao, K.N., Naidu, G.K. & Chakka, P., 2011, ‘A study of the agile software development methods, applicability and implications in industry’, International Journal of Software Engineering and Its Applications 5(2), 35–45.
Sauer, C. & Reich, B.H., 2009, ‘Rethinking IT project management: Evidence of a new mindset and its implications’, International Journal of Project Management 27, 182–193. https://doi.org/10.1016/j.ijproman.2008.08.003
Savolainen, P., Ahonen, J.J. & Richardson, I., 2012, ‘Software development project success and failure from the supplier’s perspective: A systematic literature review’, International Journal of Project Management 30(4), 458–469. https://doi.org/10.1016/j.ijproman.2011.07.002
Schiel, J., 2010, Enterprise-scale agile software development, CRC Press, Boca Raton, FL.
Schwaber, K., 2004, Agile project management with Scrum, Microsoft Press, Redmond, WA.
Sheffield, J. & Lemétayer J., 2013, ‘Factors associated with the software development agility of successful projects’, International Journal of Project Management 31, 459–472. https://doi.org/10.1016/j.ijproman.2012.09.011
Shongwe, M.M., 2015, ‘Knowledge-creation in student software-development teams’, South African Journal of Information Management 17(1), 1–8. https://doi.org/10.4102/sajim.v17i1.613
Sidky, A., Arthur, J. & Bohner, S., 2007, ‘A disciplined approach to adopting agile practices: The agile adoption framework’, Innovations in Systems and Software Engineering : A NASA Journal 3(3), 203–216. https://doi.org/10.1007/s11334-007-0026-z
Srikantaiah, T.K., Koenig, M.E. & Al-Hawamdeh, S., 2010, Convergence of project management and knowledge management, Scarecrow Press, Lanham, MD.
Stavru, S., 2014, ‘A critical examination of recent industrial surveys on agile method usage’, Journal of Systems and Software 94, 87–97. https://doi.org/10.1016/j.jss.2014.03.041
Stettina, C.J. & Hörz J., 2015, ‘Agile portfolio management: An empirical perspective on the practice in use’, International Journal of Project Management 33, 140–152. https://doi.org/10.1016/j.ijproman.2014.03.008
Stoica, M., Mircea, M. & Ghilic-Micu, B., 2013, ‘Software development: Agile vs. traditional’, Informatica Economica 17(4), 64. https://doi.org/10.12948/issn14531305/17.4.2013.06
Terlizzi, M.A., De Souza Meirelles, F. & De Moraes, H.R.O.C., 2016, ‘Barriers to the use of an IT project management methodology in a large financial institution’, International Journal of Project Management 34(3), 467–479. https://doi.org/10.1016/j.ijproman.2015.12.005
The Standish Group International, 2015, Chaos Manifesto, viewed 10 November 2016, from https://www.infoq.com/articles/standish-chaos-2015
Vinekar, V., Slinkman, C.W. & Nerur, S., 2006, ‘Can agile and traditional systems development approaches coexist? An ambidextrous view’, Information Systems Management 23(3), 31–42. https://doi.org/10.1201/1078.10580530/46108.23.3.20060601/93705.4
Wilmot, A., 2005, ‘Designing sampling strategies for qualitative social research: With particular reference to the Office for National Statistics’ Qualitative Respondent Register’, Survey Methodology Bulletin-Office For National Statistics 56, 53.
Yeo, K.Y., 2002, ‘Critical failure factors in information system projects’, International Journal of Project Management 20, 241–246. https://doi.org/10.1016/S0263-7863(01)00075-8
Zainal, Z., 2007, ‘Case study as a research method’, Jurnal Kemanusiaan 9, 1–6.
|
Hide
Show all
Email this article (Login required)
