Combining Traditional and Agile Project Management Methodologies
An empirical case study at ZiggoJelmer Knuivers
MSc.BA Business Development June 2013
Combining Traditional and Agile Project Management Methodologies
An empirical case study at ZiggoAuthor
Jelmer Knuivers
MSc.BA in Business Development S2247380 jdknuivers@student.rug.nl Supervisor Mr. C. Reezigt Organizations University of Groningen Ziggo Date June 19th, 2013
Abstract
Given the high failure rate of projects, many organizations around the world appear to struggle with managing their projects successfully. Even within literature there is no consensus on how to best manage projects, especially those that are considered complex and have strict time constraints. In reaction, the ‘Agile movement’ evolved and has established a new way of project management. Today, many papers and books have been written on traditional [TPM] and agile [APM] project management methodologies. However, the typical approach is to favor one methodology or stream in particular. Consequently, they are perceived as distinctive and mutually exclusive.
This thesis contributes to the literature by providing insights in, and practical implications about possible combinations of both methodologies. This research is done in close collaboration with a Dutch Telecom company, Ziggo.
For this study, six projects were researched through project documentation, interviews and questionnaires. Each project was evaluated according to three project characteristics: 1) recently finished 2) the level of complexity and 3) its success or failure. Using single-case and cross-case analyses, qualitative results were obtained on the way the projects were executed and how they dealt with complexity challenges.
Results from the empirical study indicate that the two methodological streams are not mutual exclusive and combinations are conceivable both on project and operational level. Findings suggest that serially executing TPM and APM methodologies on a project level is especially beneficial in situations that require fast product improvements and are characterized by sudden increases in dynamics. On an operational level, evidence suggests that obtaining components from APM, while retaining the overall process structure of TPM, is most beneficial to counter challenges due to a project’s complexity. Further results suggest that these combinations are most effective in projects with either a high uncertainty or level of dynamics. Results also suggest that elements of APM can often be used in TPM methodologies to counter complexity challenges when necessary.
In conclusion, this study demonstrates that each unique project requires a dedicated project management approach; either TPM, APM or a combination of both. This implies that managers should be aware of the criteria to optimally choose the appropriate methodological approach and the risks that are involved in applying them or not.
Acknowledgements
After many years of studying, finally things have come to an end. This thesis is the culmination of my study Business Development at the University of Groningen, which I could not have finished without the support of a number of people, whom I would like to thank.
I would like to express my thanks to my parents Ike and Edith, my brother Eelko, and my sister Sigrid, for always supporting and encouraging me. Throughout my study time, they have helped me to get the best out of myself. Also, I would like to thank my grandparents; Tineke and Edgar Stapelveld and Henk Knuivers. I hope I can show you many more mile-stones.
Moreover, I would like to thank my girlfriend Marieke Wit for always believing in me and encouraging me, and the rest of my friends who have always supported me.
Furthermore, I would like to give a special mention to Dena Konneker for her help in correcting my thesis as a native speaker. Also I would like to express my thanks to my supervisor Cees Reezigt for his support and constructive feedback.
Lastly, special thanks to Hans Geurtsen, Heleen Elferink, Peter Kassies and Cees Schuilenburg for providing me the opportunity to do my research at Ziggo, and for supporting me throughout my time at Ziggo. Also I would like to thank all others at Ziggo, whom I really considered to be my colleagues.
Table of contents
1. Introduction ... 1
2. Theory ... 3
2.1 Characterizing elements of TPM and APM methodologies ... 3
2.2 Dealing with complexity ... 5
2.3 Combinations of TPM and APM methodologies ... 8
3. Empirical case study at Ziggo ... 13
3.1 Case selection ... 13 3.2 Research methodology ... 14 3.3 Reliability ... 15 3.4 Validity ... 16 4. Results ... 17 4.1 Within-case analysis ... 17 4.2 Cross-case analysis ... 28
5. Conclusion and discussion ... 31
5.1 Managerial implications ... 32
5.2 Limitations and further research ... 33
6. References ... 35
7. Appendices ... 39 7.1 Appendix A: Prepared interview questions
7.2 Appendix B: Filled-out questionnaires
1.
Introduction
Project management has been a field of research by both academics and practitioners for decades (Pellegrinelli, 2011), yet most business organizations around the world still struggle with managing their projects. Also within literature there is no consensus on how to successfully manage projects, with increasing complexity and strict time constraints.
In the last decade, the agile movement has appeared and has established a new way of project management (Cockburn & Highsmith, 2001a). While traditional project management (TPM) is characterized by predetermining a project’s plan of approach and end-result, agile project management (APM) is characterized by an iterative development methodology and the absence of a pre- or well-defined planning and end-result.
Today, many papers and books have been written about TPM and APM methodologies. However, the majority is focused on just one particular project management methodology or stream. Mainly the advantages and the disadvantages are compared to one another. For instance, the ‘agilists’, as they call themselves (Highsmith J. A., 2002a, p. xxxi), particularly emphasize the way APM is able to handle uncertainty and dynamics, while diminishing or even neglecting the importance and necessity of upfront detailing a product design (Cockburn & Highsmith, 2001a). The latter, on the other hand, is the main focus area of TPM methodologies. These conflicting focus points have resulted in a perception that the two streams are distinct and therefore are mutually exclusive (Boehm, 2002). Since not much has been written about the possibility of combining both methodologies, this thesis will provide insights and practical implications. Data from both literature and practice is gathered and combined, to provide a broad perspective on the subject at hand. This is done in collaboration with a Dutch telecom company, Ziggo, which gave approval to study recently finished projects for the benefit of this thesis.
The main research question for this study is:
“Is it possible to make a combination of traditional and agile project management methodologies which is more favorable than its components in specific situations?”
In order to substantiate an answer to this question, the following sub-questions will be evaluated in this thesis:
a) “Are the two methodological streams truly mutually exclusive?” b) “If not, what types of combinations could exist?”
c) “In what circumstances would particular combinations of project management methodologies be favorable?”
The content of this study is structured as follows. Firstly, the theory of both TPM and APM is discussed, and the differences between the two streams are specified. Furthermore, types of possible combinations are presented. Subsequently, by means of an observational study, the feasibility and favorability of possible combinations are explored. Finally, using the results of this empirical study, conclusions and managerial implications are given and discussed with regard to the limitations of this study.
2.
Theory
Although many academics and practitioners already have put their thoughts in developing efficient methods and processes for project management, the success rate of projects at the start of the millennium was very low. According to the Standish Group (1999), only 26% of all projects succeed within time and costs and could therefore be considered as successful. In reaction, a new form of project management appeared: agile project management (APM), which sets itself apart from the traditional project management (TPM) methodologies, by using an iterative development approach for creating value in dynamic environments. This chapter will focus on the main differences between the traditional project management methodology and the agile project management approach, the way they handle complexity and which possible combination could exist.
In the Manifesto for Agile Software Development (The Agile Alliance, 2001), the core Agile values and principles are defined, as presented below. This manifesto was written in an early stage by the founders of the agile movement and virtually all APM methodologies represent these values, among which the most common methodologies: eXtreme Programming (Beck, 1999), Scrum (Schwaber & Beedle, 2002), Adaptive Software Development (Highsmith J. A., 2000) and Crystal (Cockburn A. , 2001). Notion of these values is key for understanding the differentiation of TPM and APM methodologies as the APM values are in firm contradiction to those of TPM. The next section will further elaborate on the different elements that characterize the two methodological streams. Individuals and interactions over processes and tools
Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
Figure 1: Core Agile Values from the Agile Manifest (The Agile Alliance, 2001)
2.1
Characterizing elements of TPM and APM methodologies
Both TPM and APM have distinctive characteristics. To provide useful insights in why the two methodological streams are perceived as distinct and mutually exclusive, four key elements of the project management methodologies are evaluated: the project execution forms, team compositions, communication forms and prioritization strategies.
2.1.1 Project execution: waterfall vs. iterations
The first element to differentiate APM from TPM methodologies is the project execution. TPM processes are characterized by a linear execution, which is often referred to as a waterfall (Hamilton-Whitaker, 2009). This implies that the success of this approach is dependent upon correct specification of the goal during project definition and the initial scoping (Wysocki, 2007). TPM methodologies anticipate on unforeseen situations, by attempting “to foresee and analyze future constraints and opportunities and to freeze the fundamental decisions regarding the product and the production process” (Biazzo, 2009). Therefore TPM methodologies entail an early and sharp product definition (Kalyanaram & Krishnan, 1997).
APM methodologies on the other hand, are characterized by an iterative project execution in which planning, building and testing activities are performed simultaneously and dynamically (Highsmith J. A., 2000); (Highsmith & Cockburn, 2001); (Cockburn A. , 2001). In other words, rather than ‘freezing’ the product definition early and sharp, APM methodologies ‘react’ by benefiting from delaying decisions to downstream phases, wherein information and opportunities are more evident (Verganti,
1999). This also fosters test-driven development in which there is a more active role for the end-user in order to incorporate their expectations (Beck, 2003).
These opposing project approaches lead to risks for both methodologies. One of the major managerial risks in applying TPM methodologies, is the impact (of major) adjustments in a later stage of the products design, when functionalities fail to meet the customer expectations. Hereby, the whole design cycle has to start all over again, back to the plan phase, which can
mean timely delays and costly iterations (Krause, Kimura, Kjeltberg, & Lu, 1993).
Oppositely, APM approach is more flexible. The ability to deal with uncertainty is its core strength. APM is able to react on uncertainty by earlier delaying decisions to downstream phases, where information and opportunities are manifest (Verganti, 1999). By means of delaying this sharp product definition (late freeze), adjustments can be made easier. This gives the opportunity to respond fast and adequately in a volatile environment. Yet, this flexibility comes with a shortcoming. APM is characterized by its lack of disciplined or thorough planning prior to the execution of a project. This could prohibit the projects to be initiated in the first place (Al-Zoabi, 2008). Contrary, this flaw in agile project management is the strength of the traditional methodology, advantaging its discipline and focus on automation (Vinekar et al, 2006).
2.1.2 Team composition: expert vs. multifunctional teams
The second element is the project team composition. In TPM oriented organizations, often a functional team structure is used (Wheelwright & Clark, 1992), which utilizes the strength of the expertise and knowledge of individuals. In TPM oriented organizations, individuals are often grouped by discipline, the primary cause of a project passes from one phase to the next (Wheelwright & Clark, 1992, p. 10). Therefore, it is difficult to identify the whole project team. In total, many individuals may have participated with varying involvement. Also TPM methodologies consider individuals with similar knowledge and experience as equal and may result to an increasing number of team members, as they are seen as interchangeable.
In APM methodologies, on the other hand, a project team can easily be identified as it is usually consistent throughout a project. An APM team consists of few individuals with different backgrounds
and specialisms, also referred to as a multifunctional team. Unlike TPM, team members are often placed outside their field of expertise in order to stimulate discussion of potential solutions and the way they perform their jobs (Hormozi, 2001). This should increase an employee’s flexibility and ultimately lead to products which better satisfy consumer needs (Hormozi, 2001, p. 141).
2.1.3 Communication: documentation vs. physical artifacts
The third element and difference in project management approach is communication. In TPM methodologies, most communication is done through documentation and occasional meetings. At the outset, the entire development process is decomposed into separable and somewhat independent activities (Wheelwright & Clark, 1992); hence, communication is often formalized through documents and records. Only at occasional meetings issues are plenary discussed. Therefore, good documentation and record keeping is key for a successful TPM project. It provides the base for communication between project members and provides understanding and insight into all completed work and the work that remains to be done to all members of a project. It also functions as reference works after a project is finished.
Because of the smaller team sizes in APM methodologies communication is more direct and documentation has a less essential role. Although minimized, documentation is not entirely absent. APM methodologies promote feedback, discipline and close collaboration between all members (Sharp, Robinson, & Petre, 2009). Therefore, these teams rely heavily on face-to-face communication and less on formal documentation. To support and promote interaction between team members, APM methodologies often make use of physical artifacts, such as an active story board. This fosters a shared understanding of the requirements and facilitates the development process itself (Sharp, Robinson, & Petre, 2009).
2.1.4 Value prioritization strategies: global vs. local leverage
The fourth, and last, element is the prioritization strategies used by both methodologies. TPM methodologies characterize themselves by an extensive cost-benefit study in which the complete set of requirements are known and well understood, before the requirements with the highest leverage are determined and an optimal implementation plan is made (Port & Bui, 2009). This is especially beneficial when most requirements can be determined accurately beforehand.
APM methodologies, on the other hand, assume that most important requirements will emerge during the development phase (Beck, 2001). Therefore, no attempt is made to discover a complete set of requirements prior to the start. Rather, these are established iteratively throughout the design phase of the product cycle. The priority of these requirements is reassessed before each iteration. This strategy assumes that local value prioritization leads to global value prioritization (Port & Bui, 2009).
2.2
Dealing with complexity
The way the two methodological streams handle complexity contributes to the perception of exclusion. Emphasizing the differences of handling complexity will contribute to a better understanding of when a certain approach is more beneficial, given its complexity characteristics. The characteristics of a project’s complexity, as defined by Geraldi et al. (2011), are: structural complexity, uncertainty, dynamics, pace and socio-politics.
2.2.1 How TPM and APM manage structural complexity
The first, and most commonly used element to describe complexity, is a project’s structural complexity (Geraldi, Maylor, & Williams, 2011). It relates to indicators frequently used in literature, such as scope, financial scope of the project, team size, interdependence of distinct processes, number of specialists, number of stakeholders, multi-culturally, number of locations, etc. (p. 977). According to Geraldi et al. (2011), these elements can be grouped into three main attributes: size, variety and interdependence.
Examining the TPM methodology, it is characterized by an increasing involvement of project participants respectively to a project’s size. As stated by Boehm and Turner (2003b, p. 59), “TPM methods evolve to handle large products and teams, although they are hard to tailor down to small projects.” This implies that the team size is dependent on the size of the project. APM on the other hand, has limited scalability. Since APM only functions within small and autonomous teams, the project size has to be matched to its team size. In order to manage large projects approached via the APM methodology, the project is split up into smaller components (Boehm & Turner, 2003b).
Variety is formed by the extent to which work is non-repetitive (Maylor, Vidgen, & Carver, 2008). Different people may handle problems differently, especially in complex situations. And where TPM tends to decrease the amount of variety by defining job descriptions and thus making work more repetitive, APM relies on the team’s self-discipline to reduce variety (Boehm & Turner, 2005).
In TMP methodologies interdependences are identified and documented upfront by thorough analyses of the project at hand, contrary to APM, where documentation has a limited contribution in the process and less thought is put upfront (Baccarini, 1996). To minimize the interdependence between elements of a project, in APM methodologies, teams tent to be co-located, multi-disciplinary, and rely on face-to-face communication and seemingly simple physical artifacts to support interaction (Sharp, Robinson, & Petre, 2009). Close collaboration between developers, customers, testers and users is even considered to be essential to a successful agile team (Sharp, Robinson, & Petre, 2009, p. 108), and physical artifacts, such as the story cards on the wall, are recognized by both academics and practitioners to be significantly important for the work being done (Sharp & Robinson, 2008).
2.2.2 How TPM and APM manage uncertainty
Uncertainty is often referred to as the inevitable gap between the amount of information and knowledge ideally required to make decisions and the extent to which it is available (Geraldi, Maylor, & Williams, 2011). APM and TPM apply different approaches in order to cope with uncertainty; TPM methodologies aim to foresee uncertainty, whereas APM methodologies intend to react on it. For TPM methodologies, it is important to gain sufficient information and knowledge at the start of a project to reduce the plausibility of uncertainty. Wysocki (2007) stated: “TPM projects follow a very detailed plan that is built before any work is done on the project.” The plan is based on the assumption that the project’s objective is set and clearly specified at its start. The success of this approach is based on correct specification of the goal during project definition and initial scoping activities.
Whereas TPM tries to clarify all complexity upfront, APM applies an iterative structure to counter uncertainty (Cockburn A. , 2001). “Adaptive Project Framework [APM] projects follow a detailed plan, but the plan is not built at the beginning of the project. Instead the plan is built in stages at the
completion of each cycle that defines the APF project life cycle.” (Wysocki, 2007). APM methodologies tend to embrace uncertainty by regarding it as an inevitable part of each project. Since uncertainty is defined as the possibility for an unforeseen change in scope, APM anticipates by changing the project’s scope within its iterations based on ‘unexpected’ circumstances.
2.2.3 How TPM and APM manage dynamics
Dynamics stands for the volatility of a market or product. It refers to changes in projects, such as changes in specifications, changes in goals due to ambiguity, management team, suppliers, or the environmental context (Geraldi, Maylor, & Williams, 2011). Dynamics are to some extent related to uncertainty, but where uncertainty is the possibility of an unforeseen factor, dynamics represents the changes to both unknown and foreseen factors.
One of the primary weaknesses of the TPM methodology is its inability to handle dynamics. Within this methodology the project’s plan is defined upfront and a detailed description and approach is addressed upfront. Yet, dynamics undermines this approach. In fact, TPM ignores the existence of dynamics in its approach; it anticipates on both foreseen and unforeseen factors, but does not take into account the possibility of significant changes in foreseen factors. Projects dealing with a high amount of dynamics can therefore entail substantial managerial risk when executed by this traditional approach, since alterations (in a later stage of) a project are time consuming and often costly (Bhattacharya, Krishnan, & Mahajan, 1998).
In contradiction, APM methodologies have two ways to deal with dynamics. Firstly, by late freezing the final product design this methodology has the advantage to insert changes at a later stage of the project, without having to forfeit initial considerations. Secondly, APM methodologies involve end users in the design phase in order to identify customer needs and changes upfront and as part of the project’s approach. The customers, thus, have an active role in APM methodologies in expressing their needs and expectations. This is why Vinekar et al. (2006), emphasize the importance of a ‘CRACK’ (Collaborative, Representative, Authorized, Committed and Knowledgeable) customer in APM methodologies. Hence, APM methodologies can cope well with dynamics, as it is tackled similarly to uncertainty.
2.2.4 How TPM and APM manage pace
Pace represents urgency and time criticality of objectives and it refers to the rate at which projects should be delivered relative to some reasonable or optimal measure (Geraldi, Maylor, & Williams, 2011). The iron triangle, presented in figure 2, represents the playing field between the functionality of a product, the resources and time needed for the project to develop it. It shows that time constraints have a direct influence on how a project is managed, or should be managed, since each of the factors are directly influencing one another.
TPM methodologies tent to freeze their product definitions in an early stage, which implies that they fix the functionality of a certain product, while varying with the costs and time needed to develop this product according to this specified functionality. Yet, when a project becomes time-critical, the only alternative is to increase labor and financial resources.
APM methodologies, on the other hand, turn the Iron triangle around. They fix resources and time allocated for a project, while varying with functionality. Because a product definition is not determined upfront, the functionality of a product may evolve at a later stage of a project, depending on uncertainty, available resources and time constraints (Lehman & Sharma, 2011).
2.2.5 How TPM and APM manage socio-politics
The fifth and last dimension of complexity is socio politics. This represents the degree to which different stakeholders have different interests and opinions (Geraldi, Maylor, & Williams, 2011). The extent to which socio politics influences dynamics and projects complexity is the magnitude to which a project receives support; opinions, interests and requirements are aligned; and the transparency of these interests is shared (p. 981).
TPM methodologies are essentially rooted in ‘hard’ system thinking (Winter & Checkland, 2003), in which there is a clear plan of actions and a predefined process. Consequently, a stakeholder analysis can be performed in an early stage, in which the plan plays a central role; all opinions are analyzed in an early stage of the project and are then treated as static.
APM methodologies are closer to ‘soft’ system thinking, in which there is “an ever-changing flux of messy situations” (Winter & Checkland, 2003). These situations are evaluated before any action is decided or performed, placing the action rather than the plan centrally. This allows for changing opinions and creating possibilities to anticipate thereon.
As Winter and Checkland (2003, p. 191) stress in their paper, although these perspectives differ, neither is right with the other being wrong. Hence, it is important to understand the differences between the methodologies, tools and techniques. This understanding can help creating combinations that are more favorable in certain situations.
2.3
Combinations of TPM and APM methodologies
As aforementioned, the two methodological steams differ greatly in what particular actions, operations or approaches are used to handle complexity. Therefore, it is not surprising that TPM and APM methodologies are perceived as distinct and mutually exclusive and a combination of both does not seem to be realistic (Boehm & Turner, 2003a). Yet, benefitting from both methodologies strengths could result in true synergy.
The articles by Vinekar et al. (2006), Boehm and Turner (2003b), and Hass (2007) have proven to give useful insight in determining whether or not a combination of the two methodological steams is
Fixed: Functionality Resources Time
Variable: Resources Time Functionality
TPM methodologies APM methodologies
favorable in specific situations. Each of these articles challenges the idea of an insurmountable difference and proposes useful options and methods to successfully combine the two streams. Vinekar et al. (2006) found that the circumstances of both the APM and TPM ‘home-grounds’ resembles the circumstances of explorative and exploitative strategies in the field of ambidextrous organizations. Boehm and Turner (2003b) challenged the idea of exclusion on a project level, where they use risk as a contingency factor to identify when a combination could be useful. And Hass (2007) identified that APM practices could be used in TPM methodologies on an operational level, in order to improve a project’s performance. Altogether, combinations are plausible on three levels: an organizational, project and operational level.
2.3.1 Combining TPM and APM on an organizational level
Challenges faced for combining the methodological streams on an organizational level, resembles the challenges in the field of the recent ambidexterity literature. An ambidextrous organization is defined as an organization that uses both exploitation and exploration techniques to be successful (O'Reilly & Tushman, 2004). Although this literature stream may hold useful insights for using both methodologies in one organization, it promotes separating both activities, often done by dividing them into separate organizational units (Benner & Tushman, 2003). Hence, losing potential synergy of combining both methodological streams.
One aspect of being ambidextrous is using the appropriate processes for both exploitative and explorative activities. As Vinekar et al. (2006, p. 40) state in their article, on an organizational level “there is a consensus among academics and practitioners that agile systems development [APM] needs a suitable organizational culture to sustain it, one that is very different than the organizational culture needed for traditional system development [TPM].” They also argue that these opposing cultures cannot coexist within the same organizational structure. Those clashing cultures are the main reason why the two methodologies do not fit well together in one organizational structure (Vinekar et al., 2006).
The solution proposed in most ambidexterity literature, and also by Vinekar et al., is to separate the structure into two, preferably unconnected, units of the organization (Trushman & O'Reilly, 1996); (Gibson & Birkinshaw, 2004). This ensures that cultures that are needed for explorative and exploitative innovation do not clash (Jansen, Van Den Bosch, & Volberda, 2006).
Although there is consensus of separating organizational units is beneficial for being ambidextrous, there are authors who propose there are other ways to achieve ambidexterity (Birkinshaw & Gibson, 2004); (Kortmann, 2012). They suggest that contextual ambidexterity can arise from individual employees who divide their time between exploitative and explorative activities. Thus, suggesting that these activities can be combined on a lower level in which synergy between the two streams can be created.
2.3.2 Combining TPM and APM on a project level
On a project level, a contingency approach is needed to assess whether a TPM methodology or an APM methodology should be used (Boehm & Turner, 2003b). Boehm and Turner (2003b) have developed an approach in which projects and organization characteristics could be assessed before assigning a project management methodology. They propose a contingency approach to assess the risks of executing a project according to either a TPM or an APM methodology, based on five characteristics of a project or organization: criticality, personnel, size, culture and dynamism (p. 59).
Figure 4: Home-ground chart with five dimensions (Boehm & Turner, 2003b)
Boehm and Turner (2003b), take into account culture as differentiating factor between APM en TPM project management approaches. Since TPM and APM need a suitable culture for optimal project management, thriving on order and chaos respectively. Thus, they agree a risk is involved applying a methodology that is the opposite of an organizational culture. Yet, what this approach proposes is that the organization culture does not have a decisive influence. For instance, if a culture is ‘thriving on order’, a project does not necessarily have to be managed according TPM methodologies. Whenever a specific project demands a more agile approach on the other four dimensions, it may be wise to consider an APM approach, or to incorporate some APM aspects on an operational level, even when the culture is indicating otherwise.
Proposed by Boehm and Turner (2003b), the methodologies could be customized to fit the characteristics of the project. Although they do not give clear managerial implications, there are multiple ways imaginable to combine the two methodologies, but in essence there are only three general possibilities: simultaneously executing a TPM or an APM methodology, sequential execution, or on an operational level, using elements from either TPM or APM to support the opposing methodology.
The first type of combination is simultaneous execution. In the article of Beck and Boehm (2003), they present the two PM methodologies as two distinct entities with different characteristics and capabilities, but together can tackle a complex problem more effectively. This is exactly what simultaneous execution is all about: using both methodologies side-by-side to be able to benefit from both. This type of combination can is illustrated by Boehm by comparing APM with a monkey and TPM with an elephant. To be able to reach for food on the other side of the river, the elephant could cross the river with the monkey on its back, and the monkey in turn able to get enough fruit from the trees for both.
This solution could especially benefit projects that can be split up into smaller sub-projects. For each sub-project the most appropriate methodology could be assigned using the risk-analysis proposed by Boehm and Turner (2003b).
Figure 5: Summary of the risk-based method (Boehm & Turner, 2003b)
Another possibility is sequential executing TPM and APM methodologies. TPM and APM methodologies are often referred to as plan-driven and feature-driven development methodologies, respectively (Highsmith J. A., 2002b). Where TPM methodologies focus on the process to build a product, APM methodologies focus on realizing the most value-adding feature of a product.
In both methodological steams, risks are involved. In TPM methodologies, over-analyzing products constraints, opportunities and interdependencies, could result in an over-stabilized base. APM on the other hand, could focus too much on features, which may hinder a products development if the underlying structure is not stable enough to support all these features. Adjustments in a later stage is often time consuming and costly.
The differences in risks that the methodologies entail could be compared with a tree, as illustrated in figure 5. TPM methodologies secure a strong trunk, through thoroughly analyzing all constraints, opportunities and interdependencies in order to create a well-established project management planning. APM methodologies, on the other hand, focus more on the creation of branches and leaves (being the features).
Sequentially combining the two methodologies, starting with an TPM methodology to secure a strong base and finishing with an APM methodology to flexibly create new features and resolving issues, could offer a more suitable approach for projects that find themselves in uncertain and volatile environments.
Figure 6: Potential risks of using solely one methodology versus a serially executed form
2.3.3 Combining TPM and APM on an operational level
This combination is made by obtaining some components from one methodology, while retaining the overall process structure of the other. This type resembles the possible combination given by Hass (2007), Port and Bui (2009), and Manhart and Schneider (2004). Hass (2007) states that several key elements provide the basis to incorporate APM. She proposes that the APM principles should be incorporated in TPM when one or more components or practices support this approach to achieve a focus on the benefits of each feature (p. 6). So when in search of efficiency, a project manager does not necessarily have to stick to what a certain methodology has to offer.
This is equal to the findings of both Port and Bui (2009), and Manhart and Schneider (2004). They also found that using elements from both methodologies could offer more successful results. Port and Bui (2009) used a simulation which showed that using prioritization strategies from both methodologies yield better results than using only one strategy. Manhart and Schneider (2004) used empirical data to support this type of combination, by successfully including APM practices into a TPM methodology.
Conclusively to say, APM and TPM practices can almost certainly coexist. It is up to the project managers to decide whether or not they want to apply practices from one or the other. Yet, this does imply that these managers should have knowledge of the applicability of these practices and the effects they entail. For instance, Vinekar et al. (2006, p. 40) stressed the importance of the availability of a ‘CRACK’ customer, a collaborative, representative, authorized, committed and knowledgeable customer, when end-users are included in the development process. Whenever there is no ‘CRACK’ customer, using end-users in the development process could mean increased delays or costs, while the functionality may still deviate from the market needs. To be able to offer more insights in which combinations are possible in practice and what circumstances influence the favorability of these combinations, an empirical case study is executed at Ziggo in the Netherlands. In the next section this empirical case study will be elaborated further.
Risk of TPM: Risk of APM: Ideal form:
Over dimensioning trunk Under dimensioning trunk/ Balancing dimensions Over dimensioning tranches trunk and branches
3.
Empirical case study at Ziggo
This empirical study is carried out in the telecom industry, currently one of the most volatile and fast-moving industries. Customer needs and expectations change rapidly and the technology advances fast. Yet, this industry is also characterized by the need for stability and reliability of services provided. Hence, this industry has characteristics of both traditional and agile home-grounds and is therefore ideally suited to provide managerial implications for combining project management approaches.
Since synergies between the two methodological streams are primarily sought on a project and operational level, a total of six projects are analyzed within Ziggo. Ziggo is a cable network Internet Service Provider (ISP) that operates in the telecom industry and offers internet, telephony and television services to three million households in the Netherlands. This organization strives to be innovative by being a pioneer in providing value added services to its customers. Examples are free Wi-Fi roaming, additional television channel packages and applications as live television on phones and tablets. Given its innovative drive and the need for reliable services, Ziggo could provide managerial implications for managing projects in this dynamic environment.
3.1
Case selection
Ziggo offered access to a project base of over 550 finished projects and over 350 projects that are currently running. Since the number of projects within Ziggo is extensive, it is possible for this study to be selective.
Projects were selected based on three criteria, being timing, complexity and the degree of successfulness. In order to obtain detailed managerial implications, the selected projects should be recently or nearly ended, preferably within one year before July 2012, the initiation of this empirical study. Secondly, the projects should meet the criterion of being complex, based on their characteristics. Lastly, the projects were clearly considered successful or unsuccessful, based on the scores on their performance metrics; time, costs and functionality.
In literature, successful projects are defined as those that were completed within bounds of the initial anticipation on the projects metrics, while most unsuccessful projects are often prematurely killed (Cooper & Kleinschmidt, 1990). Since Ziggo has a tendency to finish all started projects the definition of an unsuccessful project was slightly adjusted. Projects were considered unsuccessful if the characteristics were strongly adjusted from a managerial perspective, affecting all projects metrics; time, costs and functionality.
In consultation with the manager Development Programs and the director of Network and System Development of Ziggo, six projects were selected, three of which could be considered successful and three that are considered unsuccessful. These projects are:
1. TV2011
The TV2011 project was initiated to limit the amount of different consumer contracts, resulting from the merger. This project was considered to be the largest project since the founding of Ziggo. It concerned over 65 different systems and all, nearly three million, customers. Its objective was to provide a consistent service towards its customers in the Netherlands. This project was considered to be successful, started in November 2010 and finished in July 2011.
2. Modem/Router Swap The Modem/Router Swap (MRS) project was responsible for replacing the modems at all households for a modem with a newly included Wi-Fi-router. This offered a Wi-Fi service to customers of Ziggo and made future services possible. This project was considered to be successful. started in September 2010 and finished in August 2011.
3. HBO
HBO is a company that provides TV content on their own channel. Ziggo was the first company in the Netherlands to offer this channel and for Ziggo this was the first time a third party could broadcast using Ziggo’s network. Also was Ziggo the first company to engage in a partnership with HBO in the Netherlands. This project was considered successful, started in October 2011 and finished in February 2012.
4. Back-up Online
Back-up Online was intended to offer an online back-up service to the customers of Ziggo. Customers could then make a back-up of all their files stored locally on their PC into the cloud. This project was considered to be unsuccessful, started in February 2010 and finished in November 2010.
5. Real-time Installation Appointment
This project was intended to offer customers a possibility to schedule in an installer. To offer this service, the schedules of mechanics should be visible in real-time on both the website and systems used by the call-center employees. Because of many delays, this project was considered to be unsuccessful. It was started in April 2011 and was still running, but in its ending phase, at the time of the interviews, because of unexpected delays.
6. SIP Multi-line Telephony
The SIP Multiline project was initiated to offer a service to Ziggo’s business customers to be able to use multiple telephone lines, in order to create a small call-center. This projects was considered to be unsuccessful. It stared in August 2009 and finished in July 2012.
3.2
Research methodology
For this study, three data sources were used. Firstly, existing project documentation was analyzed. Secondly, semi-structured interviews were conducted, and thirdly, questionnaires were provided to the informants after they were interviewed.
For the first data source, project documents, access to all dossiers was granted by Ziggo and all relevant documents were extracted. Some proved to provide more useful information than others since many project related documents were used solely to communicate between members of a project. Much relevant and data was extracted from the project initiation documents and project end reports.
The second data collecting method, semi-structured interviews, is the most valuable for this study and is used to gain in-depth information about the conduct and execution. As stated by Eisenhardt and Greabner (2007), “Interviews are a highly efficient way to gather rich, empirical data, especially when the phenomenon of interest is highly episodic and infrequent.” For each project, at least three
project members from different hierarchal levels were interviewed, providing a more complete picture of the project. The interviews were semi-structured. A number of questions and topics were prepared to serve as guidance during the interviews. The prepared questions and topics are included in appendix A.
The third data gathering method was gaining data through questionnaires. After the interviews, the informants filled out a questionnaire, which contained a number of opposing terms. They were asked to put a cross on a five-point likert-scale, depending on what term they thought to be most applicable to the project. The opposing terms are based on literature and represent the opposing values between traditional and agile methodologies. The questionnaire and the results given by the informants are included in appendix B.
3.2.1 Data analyses
To generate insights from the large amount of data, a researcher should become familiar with each case as a stand-alone entity Eisenhardt (1989). Therefore, data has been codified in a program called ‘Kwalitan’. By assigning short descriptive terms to interview passages, overviews of projects were easily accessible and to ensure data is objectively analyzed and interpreted on causality and consistency between project members.
Within-case analyses were used to gain detailed insight in the degree of complexity of a project, the challenges that were faced, how these challenges were approached and the result of these actions. By using ratings given by informants, the performance of the project could be analyzed from different perspectives. Also by reviewing the documents, actual figures could be derived to indicate the performance. These within-case analyses will indicate whether combinations of traditional and agile methodologies are possible and how these could be achieved.
Cross-case patterns were sought between the projects to specify the circumstances in which combinations might be appropriate. Using the complexity dimensions provided by Geraldi et al. (2011), home-grounds can be defined which determine the corresponding methodology. The cross-case analyses can, accordingly, verify or falsify this theorem by providing evidence that a combination could be more favorable for a particular situation. By cross-case searching for methods used to improve a project’s performance, independent of its complexity characteristics, a combinations of methodology methods can be found on an operational level as well.
3.3
Reliability
For results to be reliable, a study has to satisfy four dimensions of reliability: researchers reliability, respondents reliability, instruments reliability, and circumstances reliability (Van Aken et al., 2007). To ensure researcher reliability, a number of Business Analysts, who worked at Ziggo over the last years, were asked to give a shortlist of projects they considered to be complex, according to the five dimensions, as defined by Geraldi et al. (2011). The resulting shortlists of projects were then verified by a manager Development Programs and the director of Network and System Development. Also the documented interviews were sent to the interviewees for final approval. The manager Development Programs was asked to identify for each project a technician and a product owner who had participated for an important part. This was then verified by the overall project or program managers.
Respondent reliability was ensured by interviewing at least three highly knowledgeable informants – a project or program manager, a technician and a product owner – who viewed the focal phenomena from different perspectives. Another way respondent reliability was ensured was by randomly alternating the terms in the questionnaires, so not one particular side represented solely traditional or agile terms. Also, informants were asked to substantiate their choices, to clarify their reasoning. Furthermore, the questionnaire was given after each interview.
To be sure of instuments reliability, it is common to use a strategy that makes use of multiple data sources. If different research strategies are used for studying the same phenomenon, the results of these different strategies should be in line. Reliable results are gained by triangulating the data, i.e. combining multiple research methods for the study of the same phenomenon (Yin, 2003). Therefore, for each data analysis, at least two sources were used.
The circumstances reliability was ensured by conducting interviews in separate rooms and on moments the informants could reserve time for the interviews.
3.4
Validity
Validity is the third criterion for the evaluation of research results. Van Aken et al. (2007) describe three types of validity which are elaborated further: construct validity, internal validity and external validity.
Construct validity is the extent to which an instrument measures what it is intended to measure (Van Aken et al., 2007, p. 164). This study uses multiple data sources. Construct validity is achieved through corroboration, by including additional evidence to strengthening an argument (Andrade, 2009).
The second type of validity, internal validity, concerns establishing causal relationships distinguished from spurious relationships (Yin, 2003). By pattern matching, a comparison between the observation and theory is made and causal relationships between phenomena and their effects can be withdrawn. Using existent theory, predicted patterns can be compared with the patterns derived from the interviews, documentation and questionnaires. Also rival explanations are sought to provide rigorousness to the study.
Finally, external validity relates to the generalizability of the research results and conclusions (Andrade, 2009). Additionally, the generalizability of causal relationships between a phenomenon and its effects is dependent on both its reoccurrence and the circumstances in which it occurred. The generalizability is limited by the lack of true contrasting results at Ziggo, all projects that were considered to be unsuccessful did eventually finish, which implies that even these projects were to some extend successfully.
4.
Results
This chapter shows the results of the empirical study. The data collected for this research was obtained through project documentation, qualitative questionnaires and semi-structured interviews. In total eighteen people were interviewed and eighteen questioners were conducted. Because of the quantity, the complete interview transcriptions are not included in this thesis, but can be acquired on request. An aggregation of the filled-out questionnaires for each project can be found in appendix B. First the projects will be elaborated in the within-case analysis. After that, relationships between a project’s characteristics and circumstances and the preferred project methodology are presented in the cross-case analysis.
4.1
Within-case analysis
The results from the within-case analysis show how the individual projects were conducted. For each project, a detailed background is presented, after which the actual performance on the selection criteria of this study is presented; being recently finished, complex, and (un)successful. Finally an evaluation for each project is given, in which the research questions are addressed, stressing the favorability of a combination of the methodologies, given the project’s circumstances.
4.1.1 Results case 1: TV2011
The first project is TV2011. In this project, all TV subscriptions of Ziggo have been migrated into a new system. Ziggo was formed by a merger of multiple cable internet service providers, each having different contract forms with their customers. In order to provide a uniform service experience to all customers, each contract was merged into one of the three standardized product offerings: ‘basic’, ‘plus’ or ‘extra’. This implied restructuring all contract forms, pricing systems, changes in the television channels, etc. In total, 65 systems had to be changed to complete this project. This project was started in November 2010 and was completed late July 2011, twelve months before the interviews for this study were conducted.
The primary reason why this project was complex was its structural complexity: its size and connectivity between departments and customers. This project concerned all departments of the company and all three million customers. According to the program manager this was the largest project since the merger of Ziggo. “Both from a technical and commercial point of view, this project was challenging, because it changed the whole product structure on which everything depends. We had to inform all three million people that there would be changes in channels and costs, also affecting contact program councils of many regions, etcetera.” TV2011 was also complex because of socio politics, since it concerned multiple stakeholders with different interests. Furthermore, the timing combined with socio politics, led to complexity. A technical engineer responded during the interview: “the challenge was to get the technical changes done in one weekend.” The impact of this project was significant with a very short implementation time, creating challenges for planning and communication between each department. Table 1 summarizes the complexity characteristics.
Complexity characteristic Contribution to project complexity
Structural complexity High
Socio politics High
Pace Mediocre
Uncertainty Low
Dynamics Low
For TV2011, a traditional PRINCEII project management methodology was followed. The program manager carefully considered the program structure, the governance and the way the program was compiled upfront. Within the interview of this study, he indicated that planning was based on trials, providing crucial information on what to be done, how it should be done and the timing involved. All steps were documented and each department and process manager was informed about the objectives, timing and resources upfront.
Yet, this project was characterized by a few elements that are closer to APM. To increase the pace of this project, for Ziggo unusual methods were applied. For instance, team members were physically re-allocated, multifunctional teams were formed based on features of the project and skills of the employees, and the progress and importance was broadcasted throughout the company. Methods closer to the characteristics of an APM methodology turned out to be crucial for the success of the project. Acknowledging the importance of the project by broadcasting results pace was accelerated, employees were inspired and became more committed. The product manager indicated: “there was a kind of winners-mentality within the project. […] you could see that project teams were well-attuned and employees from different disciplines spent all day sitting together.
However, some of the anticipated discounts could not be provided due to technical limitations. This was not foreseen upfront and became only apparent in a late stage of the project, impacting several project’ parts. There was simply no time for rethinking the discount structure and redesigning system implementation. All taken actions are summarized in the table below.
Complexity characteristic
Methods used to counter complexity challenges
Effect on
time/costs/functionality*
Structural complexity Initial project structuration
Weekly meetings
Positive: +/+/+ Positive: +/+/+
Socio politics Stakeholder analysis Positive: +/+/+
Pace
Physical allocation project team Forming multifunctional teams Enlarge commitment
Positive: +/+/+ Positive: +/+/+ Positive: +/+/+
Uncertainty Trials Positive: +/+/+
Dynamics Re-design discount structure
Adding resources
Ambiguous: -/-/+ Ambiguous: -/-/+
Table 2: Summary of challenges faced by TV2011, the counter methods and their effects * Used symbols: ‘+’ positive effect, ‘-‘ negative effect
The detailed and structured planning provided by the traditional PRINCEII project management methodology was one of the reasons for success. According to the respondents and the Project End Report the project did not exceed timing, costs and no significantly different functionality was added to the scope, as presented in table 3.
Metric Score questionnaires Actual (PER)
Time 4/5 0% over time
Costs 4,3/5 0% over budget
Functionality 4,3/5 7/10
Given the project’s circumstances and apparent end-deliverable from the start and successful outcome, a TPM proved to be the right approach. As a result a thorough planning could be made, leading to an accurate forecasted budget, timing and needed resources
Yet, some challenges were tackled applying an APM approach. A collocated multifunctional team was created to increase speed and quality, and also system implementations, in the example of discounts, were redesigned and realized iteratively. Correspondingly this indicates that TPM and APM methodological streams are not mutually exclusive. A combination could exist whereby the structure and circumstances imply a traditional methodology, yet some project elements are tackled by more dynamic and iterative methods.
This project clearly illustrated that TPM is successful in a controlled environment, where objectives and challenges can be indicated upfront. The methods of APM used during this project, driven by the need for increased implementation speed, on the other hand, indicate that methods from both methodologies are complementary and illustrate a natural way of combining TPM with APM on an operational level.
4.1.2 Results case 2: Modem/Router Swap
The second project is the Modem/Router Swap (MRS). It consisted of two parts. One part concerned the design definition and certification of a new modem/router that would replace all current modems. The other part concerned the actual swapping of the existing modems with new ones. The intention was to offer a more complete internet service experience to the customers and to provide a base for extending future services. This project was initiated in September 2010, and completed in August 2011, eleven months before the interviews for this study were conducted.
Solely taken into account its structural complexity, this project would not been qualified as being complex; fifteen to twenty people were involved, within a limited number of departments and with a limited budget. However, the combination of the complexity of the three remaining factors: implementation time, uncertainty and dynamics, caused this project to be complex and therefore qualified for this study.
This project had to be delivered in a tight time-schedule. According to the interviewee, Ziggo set a swap deadline six months after the initiation of this project. Yet, the delivery of all necessary modem/routers typically takes up four to five months, leaving just over one month for implementation. Moreover, Ziggo did not have any previous experience with Wi-Fi. Consequently, the gap between the available and required knowledge was large. Finally, this project was marked by a high degree of dynamics and iterations. Exemplified by a technical architect: “what also made this project complex was [the changing] requirements half-way through the project.” In table 4 a summary of the complexity characteristics is given.
Complexity characteristic Contribution to project complexity
Structural complexity Low
Socio politics Mediocre
Pace High
Uncertainty High
Dynamics High
The challenges implied by these characteristics were countered on an ad-hoc base, representing an APM approach on a multitude of aspects. The primary reason to deviate from the standardized process was the throughput time. According to the project manager the certification process had to be finished within a very short time. “Since the delivery usually takes four to five months, and we had to swap within a half a year, we just bought the modem and began to certificate. Normally you start with a high-level design and eventual a low-level design, before you begin to certify and purchase it. We actually reversed it all.”
In order to deal with the large amount of uncertainty and dynamics, this project was executed with a large degree of iterations. By prioritizing issues based on both their technical and commercial importance and assigning them in the weekly meetings, resources were (re)assigned. Moreover, the amount of uncertainty was reduced by starting with a proof of concept, in which all basic functionalities were tested and by actively involving the suppliers in this process.
In retrospect, most actions had a positive effect on the project metrics. Yet, soon after the first modems were swapped, it became clear that the new modem did not meet the customers’ expectations. To adapt to those standards an after-care team of designers, developers and testers was installed to find the root cause of the problem and were responsible for follow-up and solving the issues. Likewise, this after-care program applied an iterative project management structure. Team members from different functions were put together to resolve all major issues they could find. In table 5 a summary of all actions is provided.
Complexity characteristic Methods used to counter complexity
challenges
Effect on
time/costs/functionality*
Structural complexity Weekly meetings Positive: +/+/+
Socio politics Documentation
Shadowing externals
Positive: +/+/+ Positive: +/+/+
Pace Iterative development
Involving suppliers actively Prioritization based on revenue
Positive: +/+/+ Positive: +/+/+ Positive: +/+/+
Uncertainty Early proof of Concept
Test driven development
Positive: +/+/+ Positive: +/+/+
Dynamics Physical allocation project team
Iterative aftercare program
Positive: +/+/+ Ambiguous: -/-/+
Table 5: Summary of challenges faced by MRS, the counter methods and their effects * Used symbols: ‘+’ positive effect, ‘-‘ negative effect
In order to achieve commercial success, an increase of time and costs on project management level was necessary. Apart from the exceptions in costs and time needed for the after-care program, this project was delivered within budget.
Metric Score questionnaires Actual (PER)
Time 4,3/5 43% over planning
Costs 3,3/5 30% over budget
Functionality 3,3/5 7/10
Table 6: Project metrics by informants of MRS and the Project End Report
Given the short throughput time, the project manager divided from Ziggo’s standard traditional project management methodology. An APM approach was adopted, since this was a more suitable fit
for the pace, uncertainty and dynamics of this project. Yet, it is inconclusive to say if this has been the right approach. Merely objectively assessing the performance metrics, this project should not be classified as successful. It exceeded the planning horizon, costs and the functionality was not fully accepted by the customers. From a managerial perspective however, to conform the requirements derived from the business, the estimated time and costs were sufficient and this project can be seen as successful. Since these requirements provided by the business were not equal to the needs by the customers, a costly and timely after-care program was required.
No evidence could be provided whether a TMP methodology would have been more suitable. Based on the characteristics of this project, an APM approach seemed more favorable. Even so this project did follow an APM approach, an important aspect of the APM approach was omitted that could have improved the performance: the involvement of the end-user. This led to the need of necessity of extra iterations in which an after-care team was appointed to test and increase functionality.
Therefore, the commercially unsuccessful outcome of this project does not indicate that the APM approach failed in this dynamic environment. It solely illustrates the importance of carefully considering all elements of the methodology to be included. It also does not indicate that a combination could have been more appropriate.
4.1.3 Results case 3: HBO
HBO is an American pay television network that provides premium television content, both linear and on-demand. A joint-venture between Ziggo and HBO was established for this project. For the first time, an international television network would broadcast content using Ziggo’s network infrastructure. This project was initiated in October 2011 and was finished in February 2012, six months before the interviews for this study were conducted. However, no Project End Report was yet finished.
The effects of socio politics had a great effect on uncertainty resulting in high complexity. This joint venture had to be approved by the European Commission, which could mean a delay of several months. As a consequence, the initial launch date of October 2011 had to be rescheduled a few times before it was finally launched in February 2012.
Since Ziggo was the first provider in the Netherlands offering HBO to its customers, this was a unique selling point and information about this product and project had to be kept secret and silent until approval from the European Commission. Therefore, no changes could be made on the front-end systems, which increased the project’s complexity. During one of the interviews, the project manager indicated that “at every business release in which many customer facing applications were included, HBO incorporation had to be removed, since no approval of the European Commission was yet received.” Additionally, this project had to deal with the fact that project members were located abroad, had a different working culture and spoke a different language, which complicated the execution.
Complexity characteristic Contribution to project complexity
Structural complexity Low/Mediocre
Socio politics High
Pace High
Uncertainty Mediocre
Dynamics Low
Table 7: Complexity characteristics of HBO
This project was managed according to a standardized TPM methodology. According to the overall project manager, the traditional waterfall approach was best suitable. Rumors in the company or in the market, caused by iterative system changes, could work contra-productive. “Demo’s and time boxes in which you deliver products to the customer, […] was not the intention of this project. It had to be live all at once.” Before the project started, a proof of concept was done, providing information about new technology and insights on how to initiate the project best.
Despite the TPM structure, this project was also characterized by an element that is closer to APM: the ‘improvisation rounds’, as the overall project manager called them. A ‘buzz’ was created to increase demand, by allowing customers to buy the offering before it went life. Yet, the increase in demand was greater than anticipated. In the improvisation rounds, issues were fixed fast and iteratively. Also stressed by the project manager, the operators, designers and developers of the technical cluster worked collaboratively, representing an APM approach. Ultimately, they mitigated the waiting time and were able to provide HBO services to most customers on time.
Complexity characteristic Methods used to counter complexity
challenges
Effect on
time/costs/functionality*
Structural complexity Initial project structuration Positive: +/+/+
Socio politics Reschedule launch date Negative: -/-/?
Pace Releasing back-end systems and prepare
releasing front-end Motivate human resources
Ambiguous: +/-/- Positive: +/+/+
Uncertainty Proof of concept
Appointing an issue manager
Positive: +/+/+ Positive: +/+/+
Dynamics Iterative aftercare program Positive: +/+/+
Table 8: Summary of challenges faced by HBO, the counter methods and their effects * Used symbols: ‘+’ positive effect, ‘-‘ negative effect, ‘?’ uncertain effect
As a result of the delays caused by the European Commission, this project had increased costs and time. Additionally, the functionality had to be slightly adjusted, given the unexpected demand for the new product offering. Since budgeting for these delays and new market offering cannot be foreseen, nor as a result from project management failure, is this project classified as successful. Furthermore, the outcomes of the respondents on these elements were fairly high and consistent, demonstrating project management and commercial success.
Metric Score questionnaires Actual*
Time 4,7/5 80% over planning**
Costs 3,7/5 N.A.
Functionality 3,7/5 N.A.
Table 9: Project metrics by informants of MRS * No PER available
